REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN

UNIVERSIDAD NACIONAL EXPERIMENTAL DE LA FUERZA ARMADA

UNEFA-CHUAO

MATERIA: SISTEMA AVANZADO DE B.D.

ING. DE SISTEMAS VIII SEMESTRE

TRABAJO N° 1

Profesor: Integrante:

Johanny Hernandez Fernando Sánchez CI: 24.287.666

Caracas, mayo de 2019

 INTRODUCCIÓN

Los sistemas manejadores o de gestión de bases de datos (SMBD/SGBD), son un

tipo de software específico en el que sus servicio esta aplicado a interfaces entre
las bases de datos, el usuario y las aplicaciones que se utilizan. Estos software, son
utilizados para el manejo de forma precisa de nuestras bases de datos. El objetivo
de estas, son la abstracción de la información, la consistencia, seguridad o tiempo
de respuesta de las peticiones que se hagan.

En el entorno del mercado actual, la competitividad y la rapidez de maniobra de una

empresa son imprescindibles para su éxito. Para conseguirlo existe cada vez una
mayor demanda de datos y, por tanto, más necesidad de gestionarlos. Esta
demanda siempre ha estado patente en empresas y sociedades, pero en estos años
se ha disparado debido al acceso multitudinario a las redes integradas en Internet y
a la aparición de los dispositivos móviles que también requieren esa información.
Es aquí donde entran los SMBD para hacer un desempeño óptimo de los datos.
 Trabajo N° 1

Sistema Manejador de Bases de Datos

Un sistema manejador de bases de datos (SGBD, por sus siglas en inglés) o

DataBase Management System (DBMS) es una colección de software muy
específico, cuya función es servir de interfaz entre la base de datos, el usuario y las
distintas aplicaciones utilizadas.

Como su propio nombre indica, el objetivo de los sistemas manejadores de base de

datos es precisamente el de manejar un conjunto de datos para convertirlos en
información relevante para la organización, ya sea a nivel operativo o estratégico.

Lo hace mediante una serie de rutinas de software para permitir su uso de una
manera segura, sencilla y ordenada. Se trata, en suma, de un conjunto de
programas que realizan tareas de forma interrelacionada para facilitar la
construcción y manipulación de bases de datos, adoptando la forma de interfaz
entre éstas, las aplicaciones y los mismos usuarios.

Su uso permite realizar un mejor control a los administradores de sistemas y, por

otro lado, también obtener mejores resultados a la hora de realizar consultas que
ayuden a la gestión empresarial mediante la generación de la tan perseguida
ventaja competitiva.

Objetivos de un SMBD

Abstracción de la información. Los SMBD ahorran a los usuarios detalles acerca

del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa
uno o cientos de archivos, este hecho se hace transparente al usuario.

Independencia. La independencia de los datos consiste en la capacidad de

modificar el esquema (físico o lógico) de una base de datos sin tener que realizar
cambios en las aplicaciones que se sirven de ella.

Consistencia. En aquellos casos en los que no se ha logrado eliminar la

redundancia, será necesario vigilar que aquella información que aparece repetida
se actualice de forma coherente, es decir, que todos los datos repetidos se
actualicen de forma simultánea. La base de datos representa una realidad
determinada que tiene determinadas condiciones, por ejemplo que los menores de
edad no pueden tener licencia de conducir. En los SMBD existen herramientas que
facilitan la programación de este tipo de condiciones.

Seguridad. La información almacenada en una base de datos puede llegar a tener

un gran valor. Los SMBD deben garantizar que esta información se encuentra
segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas
categorías de permisos.

Manejo de Transacciones. Una transacción es un programa que se ejecuta como

una sola operación. Esto quiere decir que luego de una ejecución en la que se
produce una falla es el mismo que se obtendría si el programa no se hubiera
ejecutado. Los SMBD proveen mecanismos para programar las modificaciones de
los datos de una forma mucho más simple que si no se dispusiera de ellos.

Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SMBD

tarda en darnos la información solicitada y en almacenar los cambios realizados.

Funciones del SMBD

Función de descripción (lenguaje DDL)

 Crea las tres estructuras fundamentales (interna, externa y conceptual)

 Trabaja con los metadatos

  Crea, modifica y elimina metadatos

En definitiva:

 Estructura los datos

 Especifica el significado de los datos

 Define las reglas que cumplen

 Relaciona los datos

Función de manipulación (lenguaje DML)

 Añadir datos

 Eliminar datos

 Modificar datos

 Buscar datos Lenguaje DQL

Función de control (lenguaje DCL)

 Permisos de usuario

 Permisos de objeto

 Gestión de seguridad

Niveles de un SMBD

El comité ANSI-SPARC (American National Standard Institute - Standards Planning

and Requirements Committee) propuso una arquitectura de tres niveles para los
SGBD cuyo objetivo principal era el de separar los programas de aplicación de la
BD física. En esta arquitectura el esquema de una BD se define en tres niveles de
abstracción distintos:

 Nivel interno o físico: el más cercano al almacenamiento físico, es decir, tal

y como están almacenados en el ordenador. Describe la estructura física de
la BD mediante un esquema interno. Este esquema se especifica con un
modelo físico y describe los detalles de cómo se almacenan físicamente los
datos: los archivos que contienen la información, su organización, los
métodos de acceso a los registros, los tipos de registros, la longitud, los
campos que los componen, etcétera.

 Nivel externo o de visión: es el más cercano a los usuarios, es decir, es donde

se describen varios esquemas externos o vistas de usuarios. Cada esquema
describe la parte de la BD que interesa a un grupo de usuarios en este nivel
se representa la visión individual de un usuario o de un grupo de usuarios.

 Nivel conceptual: describe la estructura de toda la BD para un grupo de

usuarios mediante un esquema conceptual. Este esquema describe las
entidades, atributos, relaciones, operaciones de los usuarios y restricciones,
ocultando los detalles de las estructuras físicas de almacenamiento.
Representa la información contenida en la BD.

Seguridad en el SMBD

Un SMBD proporciona los siguientes mecanismos para garantizar la seguridad e

integridad de los datos:

 Debe garantizar la protección de los datos contra accesos no

autorizados, tanto intencionados como accidentales. Debe controlar que
sólo los usuarios autorizados accedan a la BD.
  Los SGBD ofrecen mecanismos para implantar restricciones de
integridad en la BD. Estas restricciones van a proteger la BD contra
daños accidentales. Los valores de los datos que se almacenan deben
satisfacer ciertos tipos de restricciones de consistencia y reglas de
integridad, que especificará el administrador de la BD. El SGBD puede
determinar si se produce una violación de la restricción.

 Proporciona herramientas y mecanismos para la planificación y

realización de copias de seguridad y restauración.

 Debe ser capaz de recuperar la BD llevándola a un estado consistente

en caso de ocurrir algún suceso que la dañe.

 Debe asegurar el acceso concurrente y ofrecer mecanismos para

conservar la consistencia de los datos en el caso de que varios usuarios
actualicen la BD de forma concurrente.

Tips para elegir un SMBD

1. Que Sea Fácil De Usar

La primera cosa a tener en cuenta al elegir un sistema de gestión de los

elementos de una base de datos para tu organización es la facilidad de uso.
Asegúrate de que el sistema sea fácil de usar para todos los miembros del
personal que van a necesitar utilizarlo. Por ejemplo, en algunas empresas
tendrán que utilizarlo programadores, resto del personal de IT y la gente de
marketing. Si estos grupos de personas van a tener que acceder al SGBD
deberías comprobar que se trata de un SGBD conveniente y fácil de utilizar
según sus habilidades.

2. Seguridad De Los Datos

La seguridad de datos es un aspecto integral en la implementación de una base
de datos. Toda la información, tanto personal como de negocios, debe tener
carácter confidencial y debe estar almacenada de forma segura, protegida de
robo o pérdida. Por lo tanto, ten en cuenta tanto los riesgos físicos como puede
ser un robo, como los riesgos derivados de errores humanos, como el facilitar
la piratería o la corrupción de datos no intencional, antes de elegir un sistema
de gestión de base de datos si quieres mantener tus datos seguros y protegidos.

3. Funcionalidad

Asegúrate de que todos los módulos que están disponibles en el SGBD

cumplen los requisitos de tu negocio. Al menos debería de tener los siguientes
módulos o funcionalidades:

Gestión del ROI

Planificador de campañas

Consultas y análisis de resultados

Estrategia de predicción

Automatización de datos

Capacidad de modelado y segmentación de datos

Filtrar y extraer datos

4. Capacidad De Integración

Puede que en un futuro quieras integrar tu sistema de gestión de base de datos

con otros sistemas que estéis utilizando. Asegúrate de que tu sistema tiene la
capacidad de integrarse con ellos, por ejemplo, con un sistema de CRM, o de
e-mail marketing.
 5. Soporte y Desarrollo

Piensa en el servicio de soporte que la compañía de software ofrece para su

sistema de gestión de base de datos. ¿Se trata de un servicio que está
disponible durante las horas en las que es probable que necesites ayuda?
¿Proporcionan apoyo a través de correo electrónico, teléfono u otros medios?

Asegúrate de que existe un plan de desarrollo para el software seleccionado de

modo que puedas estar seguro que a medida que aparecen nuevas tecnologías
éste crecerá con ellas. Confirma que vas a recibir las actualizaciones mientras
utilizas el software.

6. Escalabilidad

Asegúrate de que el SGBD seleccionado tiene capacidad para crecer con tus
datos y tu empresa. Recuerda que seguiréis añadiendo datos todo el tiempo,
por lo que a pesar de que tu requisito actual puede no ser enorme, esto puede
cambiar muy rápidamente. Piensa que puedas gestionar millones de registros
de datos para estar seguro.

7. Coste e Idoneidad

El coste es un factor importante pero debes asegurarte que tu decisión está

basada sobre todo en que el SGBD que seleccionas sea el adecuado para tu
empresa. Si escoges uno barato pensando solo en el precio podrías cometer un
error todavía mayor ya que podrías verte obligado a invertir pronto en uno nuevo
asumiendo otra vez los costes del software y su implementación. Tampoco elijas el
más caro si no vas a utilizar la mayor parte de su funcionalidad.

Modelos internos de un SMBD

Contiene la definición del almacenamiento de registros, el método de

representación de datos y el acceso utilizado, expresado por el esquema interno.

Otra definición seria: Descripción de la representación en la memoria externa del

ordenador de los datos del esquema lógico, sus interrelaciones y los instrumentos
para acceder a ellos.

Manejo de Memoria Principal y Memoria Secundaria

Representa un vínculo delicado entre el rendimiento (tiempo de acceso) y la

cantidad (espacio disponible).

Para esto se utilizan técnicas para organizar los datos almacenados en disco de
manera tal que un elemento de información requerido se pueda localizar con un
mínimo de operaciones.

Manejo de Memoria Principal.

Lo Primordial que se debe saber en un ambiente de base de datos es que los

tiempos de acceso a disco son mucho más largos que los tiempos de acceso a
memoria principal, ya que los tiempos de acceso a disco representativos van de
cerca de 400 milisegundos o más para un disco flexible en un micro hasta unos 30
milisegundos o menos para un disco rápido en un mainframe; el acceso a la
memoria principal será con toda probabilidad por lo menos cuatro o cinco órdenes
de magnitud más rápido que el acceso a disco en un sistema dado. Por todo esto,
un objetivo prioritario de desempeño en sistemas de bases de datos es reducir al
mínimo el número de accesos a disco.

La memoria principal constituye el medio de almacenamiento para el proceso de los

datos disponibles para las operaciones requeridas por el usuario, aunque esta es
demasiado pequeña para almacenar la base de datos completa

Manejo de Memoria Secundaria

Frecuentemente los datos y programas se graban en la Memoria Secundaria, de

esta forma, cuando se ejecuta varias veces un programa o se utilicen repetidamente
unos datos, no es necesario darlos de nuevo a través del dispositivo de entrada.

El manejo de espacio libre en disco se lleva a cabo de la siguiente manera:

• Vector de bits.

• Lista Ligada (lista libre).

• Por conteo (agrupación).

Organización de Archivos

Se refiere a la estructura física de un archivo sobre el disco.

Existen métodos de organización de archivos los cuales son: secuencial, directo e

indexado.

Organización Secuencial:

En este tipo de organización, los registros son almacenados en la secuencia física

en la que ellos van a ser procesados. Tenemos 2 tipos de organización secuencial.
El primero si los registros son almacenados sin ningún orden específico sino que es
sólo por su orden cronológico de llegada; el archivo correspondiente es una pila. El
segundo tipo de organización secuencial es aplicable en un ambiente de
procesamiento de archivos, donde un gran porcentaje de los registros necesitan ser
accesados frecuentemente.

Organizaciones secuenciales Indexados:

Esta provee acceso eficientes a los registros de ambas formas, tanto

secuencialmente como aleatoriamente; los registros lógicos son almacenados en
un archivo llamado “archivo de datos” y existe otro archivo separado llamado
“archivo índice” que contiene registros formados por el valor clave y la dirección del
registro lógico que tiene ese valor de clave.
Organización de acceso Directo:

La organización directa está basado en un ambiente on-line, donde se requiere

acceso aleatorio. En la organización directa, cada registro es almacenado y
recuperado en una dirección de disco sobre la base de una fórmula que es aplicada
a un valor de un campo del registro. Se podría decir que hay dos tipos de
organización directa, una usando técnicas de direccionamiento en base a una clave
y la otra usando técnicas o métodos hashing.

Técnicas o Métodos Hashing:

Básicamente son similares a las de direccionamiento por clave en que la fórmula es

aplicada a un campo del registro, teniendo como resultado un valor usado como la
dirección en disco para almacenar ese registro. La diferencia es que las técnicas o
métodos de hashing no garantizan una dirección de almacenamiento única. La
fórmula puede producir dos o más registros con el mismo valor resultante.

Esta técnica permite utilizar el disco eficientemente mientras intenta retener la

rapidez del acceso directo.

Indexación:

Un índice es una estructura de datos que permite recuperar las filas de una tabla de
forma más rápida además de proporcionar una ordenación distinta a la natural de la
tabla. Un índice se define sobre una columna o sobre un grupo de columnas, y las
filas se ordenarán según los valores contenidos en esas columnas. Por ejemplo, si
definimos un índice sobre la columna población de la tabla de clientes, el índice
permitirá recuperar los clientes ordenados por orden alfabético de población.

Restauración

Restaurar es cargar a una base de datos uno o varios objetos de una base de datos
desde una copia de seguridad de esa base de datos o de esos objetos. La
restauración sobrescribe cualquier información de la base de datos con la
información de la copia de seguridad. Después de restaurar una base de datos,
deberá recuperarla.

Transacción

Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un

programa de aplicación, que acceden o cambian el contenido de la base de datos.

Ejemplo: Las transacciones representan eventos del mundo real, como:

Las características que se debe recoger de cada transacción son las siguientes:

1. Datos que utiliza la transacción.

2. Características funcionales de la transacción.

3. Salida de la transacción.

4. Importancia para los usuarios.

5. Frecuencia de utilización.

Hay tres tipos de transacciones:

1. En las transacciones de recuperación se accede a los datos para visualizarlos en

la pantalla a modo de informe.

2. En las transacciones de actualización se insertan, borran o actualizan datos de la

base de datos.

3. En las transacciones mixtas se mezclan operaciones de recuperación de datos y

de actualización.

Propiedades De Las Transacciones

Las transacciones deben cumplir cuatro propiedades:

ACID:

1. Atomicidad (Atomicity)

2. Consistencia (Consistency)

3. Aislamiento (Isolation)

4. Permanencia (Durability):

Propiedades de las Transacciones

1. Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha

realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
2. Consistencia (Consistency): es la propiedad que asegura que sólo se empieza
aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no
van a romper la reglas y directrices de integridad de la base de datos.

3. Aislamiento (Isolation): es la propiedad que asegura que una operación no

puede afectar a otras. Esto asegura que la realización de dos transacciones sobre
la misma información nunca generará ningún tipo de error.

4. Permanencia (Durability): es la propiedad que asegura que una vez realizada

la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema. Nota:
Si la transacción no se puede finalizar por cualquier motivo, el SGBD garantiza que
los cambios realizados por esta transacción son deshechos.

Estados De Una Transacción

En cualquier momento una transacción sólo puede estar en uno de los siguientes
estados.

1. Activa (Active): el estado inicial; la transacción permanece en este estado

 durante su ejecución.

2. Parcialmente comprometida (Uncommited): Después de ejecutarse la

última transacción.

3. Fallida (Failed): tras descubrir que no se puede continuar la ejecución

normal.

4. Abortada (Rolled Back): después de haber retrocedido la transacción y

restablecido la base de datos a su estado anterior al comienzo de la
transacción.

5. Comprometida (Commited): tras completarse con éxito.

Recuperación de transacciones:

Las transacciones se inician con BEGIN TRANSACTION y se terminan con un

COMMIT o un ROLLBACK que sirven de punto de confirmación de la transacción.
En caso de que un COMMIT sea dado de mala manera, la base de datos debe forzar
un ROLLBACK.

El ROLLBACK vuelve a la base de datos al estado anterior del BEGIN

TRANSACTION. Para poder deshacer (o rehacer) actualizaciones del sistema
mantiene una bitácora de recuperación. Además, los registros de bitácora para una
transacción deben ser escritos en la bitácora física antes de terminar el
procesamiento del COMMIT para esa transacción (la regla de la escritura anticipada
de la bitácora).

Las Propiedades ACID:

Las transacciones tiene 4 propiedades importantes: Atomicidad, consistencia,

aislamiento y durabilidad.

Atomicidad: las transacciones son atómicas (todo o nada).

Consistencia: las transacciones conservan la consistencia de la base de datos en
otro igual, sin necesidad de conservar la consistencia en todos los puntos
intermedios.

Aislamiento: Las transacciones están aisladas entre sí.

Durabilidad: una vez que la transacción es confirmada, sus actualizaciones

sobreviven en la base de datos aun cuando haya una caída posterior del sistema.

Recuperación del sistema:

El sistema debe estar preparado para recuperarse no solo de las fallas locales, sino
también de las fallas “globales”, como por ejemplo: una falla al suministro eléctrico.

Las fallas por las que puede pasar un sistema caen en dos categorías:

Las Fallas del Sistema: afectan a todas las transacciones que están actualmente en
proceso, pero que no dañan físicamente a la base de datos. A la falla de sistema se
le conoce a veces como una caída blanda.

Las Fallas del Medio: causan daño a la base de datos o alguna parte de ella, y
afectan a las transacciones que están utilizando esa parte dañada.

Fallas del Sistema:

El punto central con las fallas del sistema es que se pierde el contenido de la
memoria principal. Por tanto las transacciones que se estaban ejecutando deben
ser desechas. Las transacciones que completaron satisfactoriamente antes de la
falla pero que no actualizaron deben ser reiniciadas.

Como el sistema determina las que pueden ser reiniciadas y cuales desechadas?

El sistema hace un punto de verificación y escribe un registro de punto de

verificación en la bitácora física. El registro de punto de verificación da una lista de
todas las transacciones que estaban en progreso en ese momento que se hizo el
punto de verificación. Este lo que hace es que analiza las transacciones, las que se
iniciaron antes del proceso de verificación y terminaron antes de la verificación, las
que iniciaron y mientras corrían se verifico y terminaron, las que iniciaron después
de la verificación y terminaron, las que iniciaron con la verificación y terminaron, las
que no terminaron al producirse la falla, etc. Las que no terminaron al producirse la
falla son las que hay que desechar, las demás solo se reinician para poder
actualizar. El sistema prepara una lista de DESHACER Y REHACER.

Recuperación Del Medio

Cuando ocurre un fallo del medio, físicamente se a dañado alguna parte o

totalmente la base de datos. Para recuperarse de este tipo de falla, se debe
restaurar cargando la última copia de seguridad y luego utilizar la bitácora para
volver hacer las transacciones que estaban en progreso al momento de la falla.

Confirmación De Dos Fases

Existe un componente llamado coordinador que se encarga de garantizar que los

administradores que reciben información de una transacción confirmen o deshagan
al unísono las actualizaciones de las que son responsables, y además proporcionar
esa garantía aunque el sistema falle a mitad del proceso. Es el protocolo de
confirmación de dos fases que permite que el coordinador proporcione esta
garantía.

Cuando una transacción finaliza satisfactoriamente, se ejecuta un COMMIT, esto

produce lo siguiente:

El coordinador da instrucciones a los administradores de recursos para que estén

listos para manejar la transacción. Cada participante debe forzar la bitácora para
que esté disponible para la transacción. Si la escrituras a la bitácora es forzada
satisfactoriamente, entonces el administrador de recursos da un OK al coordinador.

El coordinador recibe todas las respuestas, si todas fueron OK, entonces la decisión
es confirmar, si no todas fueron OK, la decisión es deshacer. El coordinador fuerza
una entrada en su bitácora.

Comandos utilizados para el control de transacciones

Commit

Este comando da por concluida la transacción actual y hace definitivos los cambios
realizados liberando las filas bloqueadas. Sólo después de que se ejecute commit
tendremos acceso a los datos modificados.

Rollback

Este comando da por concluida la transacción actual y deshace los cambios que se
pudiesen haber producido en la misma, liberando las filas bloqueadas. Se utiliza
especialmente cuando no se puede concluir una transacción porque se han
levantado excepciones.

Savepoint

Se utiliza para poner marcas o puntos de salvaguarda al procesar transacciones.

Se utiliza junto con rollback permitiendo deshacer cambios hasta los savepoint.

El número de savepoint está limitado a 5 por sesión pero lo podemos modificar con
la siguiente sentencia:

savepoint numero;

Rollback implícito

Este comando se ejecuta cuando un programa almacenado (procedimiento o

función) falla y no se controla la excepción que produjo el fallo. Pero si en el
programa tenemos un commit estos cambios no serán deshechos.

Rollback to

Deshace el trabajo realizado después del punto indicado. Pero no se confirma el

trabajo hecho hasta el savepoint. La transacción no finaliza hasta que se ejecuta un
comando de control de transacciones o hasta que finaliza la sesión.

Ejemplo bastante completo de lo que sería el control de transacciones:

create or replace procedure prueba (nfilas number)

as

begin

savepoint ninguna;

insert into tmp values ('primera fila');

savepoint una;

insert into tmp values ('segunda fila');

savepoint dos;

if nfilas=1 then

rollback to una;

else if nfilas=2 then

rollback to dos;

else

rollback to ninguna;
 end if;

commit;

exception

when other then

rollback

end prueba;

Falla del sistema:

Por ejemplo interrupción del servicio eléctrico, estas afectan a todas

Las transacciones que se estaban ejecutando pero no afectan a la base de datos.

Las fallas de sistema se conocen también como caídas (crash) suaves.

El problema aquí es que se pierda el contenido de memoria principal, en particular,

las áreas de almacenamiento temporal o buffers.

Si esto ocurre, no se conocerá el estado preciso de la transacción que se estaba

ejecutando en el momento de la falla, esta transacción jamás se podrá completar
con éxito por lo que será preciso anularla cuando se reinicie el sistema.

Además, puede ocurrir que sea necesario volver a ejecutar algunas transacciones
que sí se realizaron con éxito antes de la falla pero cuyas modificaciones no lograron
efectuarse sobre la base de datos porque no lograron ser transferidas de los buffers
de la base de datos a la base de Datos física (en disco).

Fallas en los medios de almacenamiento:

Una falla de los medios de almacenamiento es un percance en el cual se destruye

físicamente alguna porción de la DB. La recuperación de una falla semejante implica
en esencia cargar de nuevo la DB a partir de una copia de respaldo y utilizar
después la bitácora para realizar de nuevo todas las transacciones terminadas
desde que se hizo esa copia de respaldo. No hay necesidad de anular las
transacciones inconclusas en el momento de la falla, porque por definición todas las
modificaciones de esas transacciones ya se anularon de todas maneras.

La parte de restauración de la utilería servirá entonces para recrear la DB después

de una falla de los medios de almacenamiento a partir de una copia de respaldo
especificada.

Por ejemplo una falla en el controlador de disco o un aterrizaje de cabeza en el

disco, estas fallas sí causan daños a la base de datos o a una porción de ella y
afecta, al menos, a las transacciones que están haciendo uso de esa porción.

Las fallas de los medios de almacenamiento se llaman caídas duras. La

Recuperación de una falla semejante implica, en esencia, cargar de nuevo la base
de datos a partir de una copia de respaldo (database backup) y después utilizar la
bitácora, o system log, para realizar de nuevo todas las transacciones terminadas
desde que se hizo esa copia para respaldo.

No hay necesidad de anular todas las transacciones inconclusas en el momento de

la falla, porque por definición esas transacciones ya se anularon (se destruyeron)
de todas maneras.

Fallas por catástrofes:

Por ejemplo terremotos, incendios, inundaciones, etc. Su tratamiento es similar al

de fallas de los medios. La principal técnica para manejar este tipo de fallas es la
del database backup.

Como se mencionó anteriormente, este es un respaldo periódico que se hace de la

base de datos. Después de una caída de esta índole el sistema se restaura
recargando la base de datos con la copia del último respaldo y recreando la base
de datos mediante la bitácora o system log.

Errores del sistema:

Como realizar operaciones que causen un overflow de un entero o la división por

cero, así mismo puede ocurrir que se pasen valores erróneos a algún parámetro o
que se detecte un error en la lógica de un programa, o que sencillamente no se
encuentren los datos del programa.

Además, en algunos ambientes de desarrollo el usuario puede explícitamente

interrumpir una transacción durante su ejecución (por ejemplo: usando el control_C
in VAX/VMS o en UNIX).

Proceso de Restauración: El manejador determina cuales transacciones deben

ser deshechas y cuales rehechas.

Primera Fase (Undo): Se llenan dos listas:

• Lista de transacciones terminadas: Cuando se encuentra el FT se agrega a la lista.

• Lista de transacciones no terminadas: Cuando se encuentra una IA ó ID sin FT.
En vez de hacer esta lista puedo ir deshaciendo los cambios a medida que los
encuentro.

Segunda Fase (Redo): Cuando se llega al comienzo del LOG se van rehaciendo
los cambios de las transacciones terminadas.
Técnica de recuperación no basada en archivos log: doble paginación.

• Se mantiene dos tablas de paginación (usadas para acceder las páginas de la

BD) durante la vida de la transacción: Tabla de paginación actual y Tabla de
paginación doble.

• La Tabla de paginación doble no se modifica en ningún momento durante la

transacción. La tabla de paginación actual se cambia cuando se realiza una
operación de escritura.

• Cuando se realiza una escritura para modificar un dato que originalmente estaba
en la página i, dicha página modificada se almacena en otra página j, libre para ese
momento, a la cual va a apuntar la tabla de paginación actual.

La técnica de recuperación de doble paginación consiste, cuando hay una caída del
sistema o aborto de la transacción, en almacenar la tabla de paginación doble en el
disco de manera tal que se pueda recuperar el estado anterior de la BD que existía
antes de la caída del sistema. Cuando la transacción termina exitosamente, la tabla
de paginación actual se graba en disco y se convierte en la nueva tabla de
paginación doble para la siguiente transacción.

Cuando se hace el COMMIT de una transacción en el esquema de doble paginación

se hace lo siguiente:

1. Debe asegurarse que todas las páginas del buffer en memoria principal que se
hayan modificado se graben en disco.

2. Grabar en disco la tabla de paginación actual. No escribirla sobre la tabla de

paginación doble, ya que esta se puede necesitar para la recuperación de una
caída.

3. Grabar la dirección en disco de la tabla de paginación actual en la posición de

memoria que contiene la dirección de la tabla de paginación doble.

En el paso 3, se borra la dirección de la tabla de paginación doble anterior à La tabla

de paginación actual se convierte en la tabla de paginación doble y la transacción
esta COMMIT.

Si se presenta una caída antes del paso 3 se volverá al estado que existía antes de
la transacción. Si la caída ocurre después del paso 3, los efectos de la transacción
se conservaran.

Gráficamente: Tabla de paginación doble y actual de una transacción que hace una
grabación en la cuarta página de una BD formada por 10 páginas.
Control de concurrencia en Bases de Datos

El control de transacciones concurrentes en una base de datos brinda un eficiente

desempeño del Sistema de Base de Datos, puesto que permite controlar la
ejecución de transacciones que operan en paralelo, accesando a información
compartida y, por lo tanto, interfiriendo potencialmente unas con otras. El hecho de
reservar un asiento en un avión mediante un sistema basado en aplicaciones web,
cuando decenas de personas en el mundo pueden reservarlo también, nos da una
idea de lo importante y crucial que es el control de concurrencia en un sistema de
base de datos a mediana o gran escala. Otro ejemplo en el que podemos observar
la incidencia del control de concurrencia en el siguiente: en una Base de Datos
bancaria podría ocurrir que se paguen dos cheques en forma simultánea sobre una
cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto es posible
evitarlo si se tiene un control de concurrencia. La Concurrencia en las Bases de
Datos es de suprema importancia en los sistemas de información, ya que evita
errores en el momento de ejecutar las diferentes transacciones.
Varias transacciones introducidas por usuarios, que se ejecutan de manera
concurrente, pueden leer/modificar Introducción a la concurrencia de transacciones
los mismos elementos almacenados en la base de datos

• Razones para permitir la concurrencia:

– Aumentar la productividad: número de transacciones ejecutadas por minuto.

– Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. –

Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan
a las ‘grandes’).

¿Por qué es necesario el control de concurrencia?

•... porque pueden surgir problemas si las transacciones concurrentes se ejecutan

de manera no controlada

• Ejemplo sencillo: sistema de bases de datos que permite hacer y anular reservas
de plazas en vuelos de diferentes compañías aéreas.

– Se almacena un registro por cada vuelo, que incluye, entre otras cosas, el número
de asientos reservados en el vuelo

– Sean dos transacciones T1 y T2 concurrentes:

• T1 transfiere N reservas realizadas en un vuelo X a otro vuelo Y

• T2 reserva M plazas en el vuelo X

Transacción T1

leer_elemento(X);

X: X - N;
escribir_elemento(X);

leer_elemento(Y);

Y:=Y+N;

escribir_elemento(Y);

Transacción T2

leer_elemento(X);

X+M; X:= X+M;

escribir_elemento(X);

• Aunque las transacciones pueden ser perfectamente correctas en sí mismas, la

ejecución concurrente de T1 y T2 puede producir un resultado incorrecto, debido a
la intercalación de sus operaciones, poniendo en cuestión la integridad y la
coherencia de la base de datos.

Correctitud

La integridad de un dato alude a ese atributo o cualidad que es inherente a la

información cuando se considera exacta, completa, homogénea, sólida y coherente
con la intención de los creadores de los datos que la conforman.

Esta cualidad, que va ligada al propio dato y no al lugar donde se almacena, al

contrario de lo que sostienen creencias bastante extendidas; se obtiene cuando se
impide eficazmente que el contenido de una base de datos, de un proceso o de un
sistema se vea, accidental o intencionalmente:

- Modificado, en base a su propio contenido o con ayuda de la inserción de

nuevo.
 - Destruido total o parcialmente.

Serialidad

En las transacciones previamente descritas, se tienen operaciones de lectura-

escritura, y se tienen operaciones aritméticas. Es fácil comprender que si se deja
fija la secuencia de operaciones de lectura escritura (con respecto a la concurrencia)
y se reacomodan las operaciones aritméticas, el resultado no cambia. Por ello, las
operaciones de lectura-escritura son las que deben serializarse cuidadosamente.
Por supuesto, las operaciones aritméticas deben mantener el mismo orden, pero no
importa su serialidad en cuanto a la concurrencia. Hay dos formas de equivalencia
de planificación: secuencialidad en cuanto a conflictos, y secuencialidad en cuanto
a vistas. Secuencialidad en cuanto a conflictos Suponga una planificación P en la
que hay dos instrucciones consecutivas Ii e Ij pertenecientes a las transacciones Ti
y Tj. Si se refieren a diferentes elementos de datos (como por ejemplo, a diferentes
registros), se puede intercambiar su orden sin afectar el resultado. Pero si se
refieren al mismo elemento Q, entonces el orden puede afectar el resultado. Se
deben considerar 4 casos:

1. Ii = leer(Q), Ij = leer(Q). El orden no importa pues leerán el mismo dato.

2. Ii = leer(Q), Ij = escribir(Q). Si Ii ocurre antes, no leerá el dato escrito por Ij. El

orden es importante.

3. Ii = escribir(Q), Ij = leer(Q). Semejante al anterior.

4. Ii = escribir(Q), Ij = escribir(Q). La última operación de escritura es la que

prevalecerá, pues sobrescribirá lo escrito por la primera operación.

Inconsistencia de los datos

Sólo se produce cuando existe redundancia de datos. La inconsistencia consiste en

que no todas las copias redundantes contienen la misma información. Así, si existen
diferentes modos de obtener la misma información, y esas formas pueden conducir
a datos almacenados en distintos sitios. El problema surge al modificar esa
información, si lo sólo cambiamos esos valores en algunos de los lugares en que se
guardan, las consultas que hagamos más tarde podrán dar como resultado
respuestas inconsistentes (es decir, diferentes). Puede darse el caso de que dos
aplicaciones diferentes proporcionen resultados distintos para el mismo dato.

La inconsistencia de los datos se debe manejar de manera independiente para que

no se repitan datos innecesarios ni contradictorios que ocasionen inconsistencia de
los datos.

Actualización de pérdida

En un SGBD en el que varios usuarios acceden a los datos alojados en la base de

datos puede ocurrir que se ejecuten varias transacciones que intenten actualizar los
mismos elementos de datos (filas de datos) de manera que cada transacción realiza
la actualización basándose en el valor seleccionado originalmente. La última
actualización en ejecutarse sobrescribe las actualizaciones realizadas por las
transacciones anteriores, lo que da lugar a la pérdida de datos.

Técnicas de control de concurrencia

Métodos basados en la teoría de la serializabilidad, que definen un conjunto de

reglas (o protocolo) tal que...

– si todas las transacciones las cumplen, o

– el subsistema de control de concurrencia del SGBD las impone

(automáticamente)...se asegura la serializabilidad de toda planificación de
transacciones

• Clasificación

– Métodos de bloqueo
– Métodos de marca de tiempo

– Técnicas de multiversión

– Métodos optimistas

Métodos de bloqueo

• Reglas básicas del bloqueo:

– Bloqueo compartido: si una transacción tiene un bloqueo compartido sobre

un elemento de datos, puede leer el elemento, pero no actualizarlo (escribir)
Varias transacciones pueden mantener a la vez bloqueos compartidos sobre
el mismo elemento

– Bloqueo exclusivo: si una transacción tiene un bloqueo exclusivo sobre un

elemento de datos, puede leer y actualizar (escribir) el elemento.

Optimización de Consultas

El Optimizador de Consultas suele combinar varias técnicas

Las técnicas principales son las siguientes:

Optimización heurística

Ordenar las operaciones de la consulta para incrementar la eficiencia de su

ejecución

Estimación de costes

Estimar sistemáticamente el costo de cada estrategia de ejecución y

Elegir el plan (estrategia) con el menor costo estimado.

El Analizador Sintáctico genera árbol de consulta inicial

– Sin optimización  ejecución ineficiente

– El Optimizador de Consultas transforma el árbol de consulta inicial en

árbol de consulta final equivalente y eficiente

– Aplicación de reglas de transformación guiadas por reglas heurísticas

– Conversión de la consulta en su forma canónica equivalente

Técnicas utilizadas por un DBMS para optimizar y ejecutar consultas de

alto nivel.

El analizador léxico, identifica elementos del lenguaje. El analizador sintético

comprueba la sintaxis de la consulta. La consulta debe ser validada. El
optimizador de consultas se encarga de generar un plan de ejecución. El
generador de Código se encarga de generar un código para ejecutar dicho plan.
El procesador de Base de Datos en tiempo de ejecución tiene la función de
ejecutar el código.

Técnicas De Optimización

El Optimizador tiene un conjunto de técnicas para realizar cada operación

Ejemplo: técnicas para implementar la operación de Restricción 

 Búsqueda Lineal

 Búsqueda Binaria

 Empleo de Índice Primario o Clave de Dispersión

 Empleo de Índice de Agrupamiento

  Empleo de Índice Secundario

Un SGBD debe contar con algoritmos para implementar los distintos tipos de
operaciones relacionales:

 Ordenación

 Selección

 Reunión

 Operaciones de agregación

 Operaciones de conjuntos

Ordenación

El algoritmo de ordenación es básico en el procesamiento de consultas. Se

necesita cuando:

 Resultado ordenador (ORDER BY)

 Se desean eliminar duplicados (DISTINC)

 Operaciones de reunión

 Y operaciones de conjuntos.

El algoritmo habitual para grandes ficheros de datos consiste en la estrategia

ordena-mezcla que va ordenando pequeños ficheros y después los mezcla.

El coste de estos algoritmos corresponde al coste de la ordenación (a*log(a)) y

el coste de la mezcla (a+b).

Restricción:

Métodos de búsqueda para condición simple.

Búsqueda lineal

Empleo de un índice

Métodos de búsqueda para condición compleja .

Condiciones conjuntivas: Selección conjuntiva empleando un índice individual

Selección conjuntiva con un índice compuesto. Selección conjuntiva por
intersección de punteros a registros.

Condiciones disyuntivas: En este caso poco se puede optimizar.

Reunión: es una de las operaciones más costosas.

Reunión de bucle anidado (secuencial)

Reunión por bucle único (cuando existe alguna estructura de acceso

(índice) para extraer los registros coincidentes)
Reunión por ordenación-mezcla. Primero se ordenan las relaciones
implicadas y después se mezclan.

Reunión por dispersión: una de las relaciones operando se dispersa por

el atributo de reunión y después se accede secuencialmente a la otra
relación.

Reunión con índice: es una de las relaciones operando: la relación que no

está indexada se accede secuencialmente y para cada tupla se accede a la
otra relación a través del índice.

Reunión con índice en las dos relaciones: se mezclan los dos índices para
conseguir un conjunto de parejas (TID1,TID2) de tuplas coincidentes. Reunión
por índice de reunión: es un índice especial para la realización de reuniones.

Operaciones de agregación. Cuando los operadores de agregación (MIN,

MAX,COUNT, AVERAGE, SUMA), se pueden calcular mediante un acceso
secuencial o mediante el índice adecuado. Ejemplo:

Operaciones de conjuntos. Estas operaciones tienen implementaciones

costosas (unión, intersección, diferencia de conjuntos y producto cartesiano).

La operación producto cartesiano debe evitarse por su elevado coste.

Las otras tres operaciones en general se implementan mediante la técnica

ordena mezcla.

Optimización de consultas: estimación de costes

 Un optimizador de consultas no depende exclusivamente de reglas heurísticas:
comparan los costos de ejecución de consultas con diferentes estrategias de
ejecución.

Se necesita una función de coste para minimizar.

En general, el coste de ejecución de una consulta incluye los siguientes

componentes:

 Costo de acceso al almacenamiento secundario

 Costo de almacenamiento intermedio

 Costo de cómputo: coste de ejecutar operaciones en la memoria

 Costo de comunicación: coste relacionado con enviar la consulta y sus

resultados.

Optimización semántica de consultas

Existe un enfoque diferente para la optimización de consultas: optimización

semántica de consultas.

Normalmente se utiliza en combinación con lo anteriormente estudiado.

La idea básica consiste en utilizar las restricciones existentes sobre la BD para

descartar ciertas consultas cuyo resultado es vacío.

Ejemplo:
 CONCLUSIÓN

Un Sistema Gestor de Base de datos nos va a permitir el manejo de la información

que contiene una Base de Datos. Los lenguajes que maneja un SGBD son el
lenguaje de definición de datos LDD y el lenguaje de manipulación de datos LMD.

Los Sistemas Gestores de Bases de datos tienen un propósito claro, que es el de

facilitar el manejo de la información, el hecho de manejar una herramienta con tanto
poder nos permite tener el control sobre la organización y acceso de la información,
lo que hace importante conocer, estudiar y manejar estas herramientas.
 BIBLIOGRAFÍA

 PowerData. “¿Qué es el sistema manejador de bases de datos?” .

17 de Agosto de 2015.
 Marquez Diana, Moreno Gustavo, Rodriguez Cinthia. “SMBD
(Sistemas Manejadores de Bases de Datos”. 14 de septiembre
de 2009. Universidad Veracruzana.
https://es.slideshare.net/cinthiaerendida/s-m-b-d-1995721
 S. Velilla. “Bases de Datos y SGBD” Universidad de Zaragoza.
http://webdiis.unizar.es/asignaturas/BD/transparenciasBD/PDF
s_1x1/leccion_2.pdf
 Espinoza, Rene. “Niveles de un SGBD” 25 de noviembre de
2011. https://es.slideshare.net/creneluna/niveles-de-un-sgbd
 Editorial McGraw-Hill. “SGBD. El diccionario de datos.
Seguridad e integridad de datos” 21 de octubre de 2018.
http://www.mailxmail.com/curso-sistemas-bases-datos/sgbd-
diccionario-datos-seguridad-integridad-datos
 Informática para tu negocio. “TIPS PARA ELEGIR UN SISTEMA
DE GESTIÓN DE LOS ELEMENTOS DE UNA BASE DE DATOS”
https://www.informaticaparatunegocio.com/blog/tips-elegir-
sistema-gestion-elementos-base-datos/
 Miguel Torres, Jesús Rojas, Anyelka Avellano. “SISTEMA
GESTOR DE BASE DE DATOS (Modelo Interno)”. Noviembre de
2014. UNEFA Núcleo Maracay.
https://es.scribd.com/document/247859613/Modelo-Interno-de-
SGBD
 CA Technologies Biblioteca Virtual. “Definición de los
conceptos básicos de restauración y recuperación”. 2011.
http://documentation.arcserve.com/Arcserve-
Backup/Available/R16/ESP/Bookshelf_Files/HTML/oraclelx/ind
 ex.htm?toc.htm?ol_ou_rst_n_rec_basics.htm

 Cruz, Daniel. “Transacciones”. 23 de octubre de 2013. Instituto

Tecnologico de Ciudad Madero.

https://es.slideshare.net/dantoniocruz/transacciones-27511077

 Lopez, María. “Administración de Bases de Datos”. UCV

Facultad De Ciencias.

http://www.ciens.ucv.ve:8080/genasig/sites/administracion-de-
bd/archivos/Manejo_de_Memoria.pdf

 Camuña, Jesús. “Lenguajes de definición y modificación de

datos SQL”. 16 de junio de 2015. IC Editorial.

 “Optimización de consultas”
http://informatica.uv.es/iiguia/2000/BD2/BD2Tema7.pdf