Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Análisis comparativo de bases de datos de Código abierto vs. Código cerrado (determinación de índices de comparación) (página 2)



Partes: 1, 2, 3, 4

Partes: 1, , 3, 4

  1. El código abierto en las
    empresas

En el Ecuador el
tema es controversial unos prefieren lo corporativo por que es
seguro,
además existe alguien que puede responder si algo falla,
un punto importante es que las empresas tienen
miedo al cambio. En
fin, es una decisión que tarde o temprano será
evaluada con mayor seriedad.

Una percepción
usual es "Si es libre (o gratis), probablemente no valga gran
cosa
". De hecho, existen diferentes motivaciones para
renunciar al ingreso de las licencias. No lograr el éxito
comercial puede ser una, obtener mayor soporte es
otra.

El principal temor que los usuarios pueden tener es el
tener que confiar en medios
informales tales como grupos de
usuarios para obtener ayuda y soporte. Otra preocupación
puede ser lo imprevisible del desarrollo de
funciones y
características.

Se puede pagar por un sistema operativo
o programa, o
no. Hoy día en la mayoría de casos hay un sistema operativo
o programa, cuando menos equivalente, en los dos sectores tanto
en código abierto como en código cerrado. Por
ejemplo, hoy en día ya hay un gran número de
aplicaciones con licencia GPL que corren sobre varios
sistemas
operativos, tanto propietarios como abiertos.

A nivel laboral, a fin de
cuentas es lo
mismo. Tanto si contratan un ingeniero en sistemas, o en un
negocio propio, para un tipo de producto u
otro no quiere decir que se utilizará el mismo producto
toda la vida.

Un ingeniero de sistemas es un recurso humano que en
particular debe adaptarse a su entorno de trabajo, no
importa el sector, lo importante es mantenerse, puede ser
linux,
unix, windows, pero
lo importante es que el ingeniero este capacitado.

En el caso de las empresas, es una apuesta de negocio.
En esta vida, hay que adaptarse al entorno y necesidades del
mercado, y en el
caso de las empresas, a veces, se tienen que
arriesgar.

Las distribuciones de linux fueron un riesgo, y alto,
ya que el mercado de los sistemas
operativos es muy duro. La inversión de las empresas no fue una
inversión a corto plazo, estaban concientes que iban a
necesitar algunos años. Todas las empresas empiezan de una
manera muy dura, es la ley del mercado,
ni más ni menos.

Es el mercado el que decide quién sigue y
quién no. Pero lo importante es que muchos clientes
mirarán la diferencia entre un precio y otro,
se encantarán por la opción de código
abierto?

Una vez más será el mercado quién
decida. Si el código abierto es igual o más fiable
que el cerrado y se sabe promocionar, por la ley de la oferta y la
demanda, tiene
las de ganar. Aunque hay muchas variables en
el mercado real que hacen que no se tan trivial.

En definitiva, a un profesional de la informática le es igual trabajar en un
sistema abierto o cerrado. A fin de cuentas no tiene importancia.
Si una persona desea
utilizar un sistema u otro en su casa, eso es elección de
cada uno. A nivel de empresa, viene a
ser igual, es inapropiado pensar que las grandes del
código cerrado desaparecerán si se impone el
código abierto. Se adaptaran, o desaparecerán, pero
como las empresas las llevan humanos, y si algo tenemos es
instinto de supervivencia, seguramente se adaptarán al
nuevo modelo de
mercado de nuevas
tecnologías que implica el Open Source.

    1. Procesamiento de
      Transacciones
  1. PRINCIPALES CARATERISTICAS TECNICAS DE LOS
    MOTORES DE
    BASES DE
    DATOS.

Varias de las operaciones que
se realizan sobre la base de datos forman a
menudo una única unidad lógica
de trabajo. Un ejemplo de esto es la acreditación de
cuentas en un banco, en la que
el valor
acreditado se resta en la cuenta (A) y se debe actualizar tanto
el saldo contable como el disponible, a parte de este proceso se
debe insertar un registro en la
tabla de auditoria.

Es esencial que se ejecuten todos los procesos o
ninguno. Este requisito de todo o nada se denomina
atomicidad. Además es fundamental que el valor
restado a los saldos sea preservado, este requisito se conoce
como consistencia. Finalmente tras la ejecución
correcta de la transacción, los nuevos valores de los
saldos debe persistir, a pesar de la posible falla del sistema.
Este requerimiento del sistema se denomina durabilidad.
También es importante y necesario si ocurre algún
error durante la ejecución de cualquiera de los procesos
que forman parte de la transacción se ejecute un roolback
de forma que deje los valores
como estaban al principio, es decir, como estaban antes de la
ejecución.

El componente encargado de lograr la atomicidad de la
transacción se conoce como administrador de
transacciones y las operaciones COMMIT (comprometer o confirmar)
y ROOLBACK (retroceder) son la clave de su
funcionamiento.

La operación COMMIT indica el
término exitoso de una transacción: le dice al
administrador de transacciones que se ha finalizado con
éxito, que la base de datos
está o debería estar de nuevo en un estado
consistente y que se pude comprometer o hacer permanentes todas
las modificaciones efectuadas.

La operación ROLLBACK, en cambio, nos
indica el término no exitoso de una transacción: le
dice al administrador de transacciones que algo salió mal,
que la base de datos podría estar en un estado no
consistente y que todas las modificaciones realizadas hasta el
momento deben retroceder o anularse.

Una transacción es una colección de
operaciones que se lleva a cabo como una única función
lógica en una aplicación de base de datos. Cada
transacción es una unidad de atomicidad y consistencia.
Así, se requiere que las transacciones no violen ninguna
restricción de consistencia de la base de datos, Es decir,
si la base de datos era consistente cuando la transacción
comenzó, la base de datos debe ser consistente cuando la
transacción termine con éxito. Sin embargo, durante
la ejecución de una transacción puede ser necesario
permitir inconsistencias temporalmente, ya que una de las
operaciones que forma parte de la transacción se debe
realizar una antes de la otra. Esta inconsistencia temporal,
aunque necesaria, puede conducir a dificultades si ocurre un
fallo.

Es responsabilidad del programador definir
adecuadamente las diferentes transacciones, de tal manera que
cada una preserve la consistencia de la base de datos.

Asegurar las propiedades de atomicidad y durabilidad es
responsabilidad del propio sistema de base de datos,
específicamente del componente de gestión
de transacciones
. En ausencia de fallos, toda
transacción completada con éxito y atómica
se archiva fácilmente.

El sistema de base de datos debe realizar la
recuperación de fallos, es decir, detectar los
fallos del sistema y restaurar la base de datos al estado que
existía antes de que ocurriera el fallo.

Finalmente cuando varias transacciones actualizan la
base de datos concurrentemente, la consistencia de los datos
puede no ser preservada, incluso aunque cada transacción
individualmente sea correcta. Es responsabilidad del gestor de
control de
concurrencia
controlar la interacción entre las transacciones
concurrentes para asegurar la consistencia de la base de
datos.

En esencia, lo que se persigue con el procesamiento de
transacciones es, por una parte, obtener una transparencia
adecuada de las acciones
concurrentes a una base de datos y por otra, manejar
adecuadamente las fallas que se puedan presentar en una base de
datos.

La mayoría de medianas y grandes
compañías modernas utilizan el procesamiento de
transacciones para sus sistemas de
producción, y es tan inprescindible que las organizaciones no
pueden funcionar en ausencia de él. El procesamiento de
transacciones representa una enorme y significativa
porción del mercado de los sistemas informáticos
(más de cincuenta billones de dólares al
año) y es, probablemente, la aplicación simple
más amplia de las computadoras.
Además, se ha convertido en el elemento que facilita el
comercio
electrónico.

Como puede percibirse, el procesamiento de transacciones
es una de las tareas más importantes dentro de un sistema
de base de datos, pero a la vez, es una de las más
difíciles de manejar debido a diversos aspectos, tales
como:

  • Confiabilidad.- Puesto que los sistemas de
    base de datos en línea no pueden fallar.
  • Disponibilidad.- Debido a que los sistemas de
    base de datos en línea deben estar actualizados
    correctamente todo el tiempo.
  • Tiempos de Respuesta.- En sistemas de este
    tipo, el tiempo de respuesta de las transacciones no debe ser
    mayor a diez segundos.
  • Throughput.- Los sistemas de base de datos en
    línea requieren procesar miles de transacciones por
    segundo.
  • Atomicidad.- En el procesamiento de
    transacciones no se aceptan resultados parciales.
  • Permanencia.- No se permite la
    eliminación en la base de datos de los efectos de una
    transacción que ha culminado con
    éxito.

Para conseguir anular y recuperar las transacciones, el
método
más usado consiste en utilizar un archivo de log en
el que se va guardando toda la información necesaria para deshacer (en
caso de fracasar) o rehacer (en caso de recuperar) las
transacciones. Este log consta de los siguientes
datos:

  • Identificador de la transacción
  • Hora de modificación
  • Identificador del registro afectado
  • Tipo de acción
  • Valor anterior del registro
  • Nuevo valor del registro
  • Información adicional

Otra alternativa es manejar 2 archivos de log,
uno con la imagen anterior a
las modificaciones y otro con la imagen posterior a las
modificaciones. El archivo log es usualmente una pila que una vez
llena va eliminado registros
según van entrando nuevos.

Un concepto
relacionado con los archivos de log es el CHECKPOINT, que
permite manejar en forma eficiente el contenido de los archivos
log, ya que permiten no tener que recorrer todo el archivo de
log, ante fallas.

Los puntos marcados como checkpoint, permiten la
recuperación de la base de datos en caliente, es decir,
después de la caída del sistema se obtiene la
dirección del registro de
recuperación más reciente y se recorre el archivo
de log desde el punto marcado como checkpoint.

  1. El objetivo
    del concepto de recuperación es proteger la base de
    datos contra fallas lógicas o físicas que
    destruyan los datos en forma total o parcial. Estas fallas
    pueden afectar al correcto almacenamiento de los datos.

    Para asegurar que la base de datos siempre
    esté en un estado consistente, cada base de datos
    tiene un proceso para obtener copias de seguridad, esto ayuda a mantener un registro
    confiable de los datos ante desastres o posibles fallas del
    sistema.

    Por otro lado, las bases de datos crean unidades
    de ejecución llamadas transacciones, que pueden
    definirse como una secuencia de operaciones que se ejecutan
    en forma atómica, es decir, se realizan todas las
    operaciones que comprende la transacción o no se
    realiza ninguna.

    La transacciones, o terminan el proceso con
    éxito y son completadas en la base de datos, o
    fracasan y deben ser restaurado el
    estado anterior de la base de datos.

    La recuperación en frío, consiste en
    disponer de un backup o respaldo de la BD, que
    permitirá junto con los archivos de log, que se han
    ido produciendo desde el ultimo backup, reconstruir la BD,
    para dejarla consistente.

    El error fatal, se produce cuando se pierde el
    archivo de log. En este caso resulta imposible recuperar la
    base. La solución pasa por disponer los archivos de
    log en respaldos.

    El DBA debe definir responsabilidades, procedimientos, situaciones y plazos en los
    que se deben realizar las copias de seguridad y el respaldo
    del archivo de log, especificando a los operadores los
    procedimientos de recuperación ante caídas.
    El principio básico en el que se basa la
    recuperación es la redundancia.

  2. Recuperación
    de la Información
  3. Tipos de
    Datos

En las bases de datos existentes en la actualidad se
sigue una norma SQL que
soporta un conjunto de dominios predefinidos, que incluye los
siguientes:

  • Char. (n) es una cadena de caracteres de
    longitud fija, con una longitud n especificada por el usuario.
    También se puede utilizar la palabra completa
    character.
  • Varchar. (n) es una cadena de caracteres de
    longitud variable, con una longitud n especificada por el
    usuario. También se puede utilizar la forma completa
    character varying.
  • Int. Es un entero (un subconjunto finito de
    los enteros, que es dependiente de la máquina).
    También se puede utilizar la palabra completa
    integer.
  • Smallint. Es un entero pequeño (un
    subconjunto del dominio de los
    enteros, tambien dependiente de la maquina).
  • Numeric. (p,d) es un numero en coma flotante,
    cuya precisión la especifica el usuario. El
    número está formado por p dígitos
    (más el signo), y de esos p dígitos, d pertenecen
    a la parte decimal. Así, numeric(3,1) permite que el
    número 56,5 se almacene exactamente, mientras que los
    números 444,5 y 0,32 no se pueden almacenar exactamente
    en un campo de este tipo.
  • Real, double precision. Son respectivamente
    números en coma flotante y números en coma
    flotante de doble precisión , con precisión
    dependiente de la maquina.
  • Float. (n) es un número en coma
    flotante , cuya precisión es de al menos n
    dígitos.
  • Date es una fecha del calendario, que contiene
    un año (de cuatro dígitos), un mes y un
    día del mes. Ejm: "2004-02-01" La fecha se debe
    especificar en formato aaaa-mm-dd.
  • Time es la hora del día, expresada en
    horas, minutos y segundos. Se puede usar una variante, time
    (p), para especificar el número de dígitos
    decimales para los segundos (el número predeterminado es
    cero). También es posible almacenar la
    información del uso horario junto al tiempo. Ejm:
    "09:30:00".
  • Timestamp es una combinación de date y
    time. Se puede usar una variante, timestamp (p), para
    especificar el número de dígitos decimales para
    los segundos (el número predeterminado es 6). Ejm:
    "2004-02-01 09:30:01.45".

SQL permite incluir en la declaración de dominio
de un atributo la especificación not null de este
modo se prohíbe la inserción de un valor nulo para
ese atributo.

SQL permite realizar operaciones de comparación
sobre todos los dominios que se listan aquí, y permite
realizar operaciones aritméticas y de comparación
sobre los diferentes dominios numéricos. SQL
también proporciona un tipo de datos llamado
interval y permite realizar cálculos basados en
fechas, horas e intervalos.

 

  1. Las restricciones de integridad proporcionan un
    medio de asegurar que las modificaciones hechas a la base
    da datos por los usuarios autorizados no provoquen la
    pérdida de la consistencia de los datos. Por tanto
    las restricciones de integridad protegen a las bases de
    datos de daños accidentales.

    La integridad tiene como función proteger
    la BD contra operaciones que introduzcan inconsistencias en
    los datos. Se habla de integridad en el sentido de
    corrección, validez o precisión de los
    datos.

    El subsistema de integridad de un SGBD debe por
    tanto detectar y corregir, en la medida de lo posible, las
    operaciones incorrectas. En la práctica es el punto
    débil de los SGBD comerciales, ya que casi toda la
    verificación de integridad se realiza mediante
    código de procedimientos escritos por los
    usuarios.

    Habrá operaciones cuya falta de
    corrección no sea detectable, por ejemplo,
    introducir un fecha de nacimiento 25/12/1945 cuando en
    realidad era 25/12/1954.

    En lo que tiene que ver con la seguridad
    también se protege los datos frente al acceso de
    personas no autorizadas y destrucción o
    alteración malintencionada.

    1. Operaciones
      semánticamente inconsistentes
  2. Integridad y
    Seguridad

Son las que transgreden las restricciones que ha
definido el administrador al diseñar la base de datos,
tales como:

  • Restricciones sobre dominios por ejemplo, el dominio
    edad esté comprendido entre 18 y 65
    años.
  • Restricciones sobre los atributos, por ejemplo, la
    edad de los empleados ingenieros debe ser mayor de 21
    años.

Estas restricciones pueden ser estáticas, como
las anteriores o dinámicas por ejemplo, el sueldo de un
empleado no puede disminuir.

Otra forma de clasificar las restricciones es
en:

  • simples: si se aplican a una ocurrencia de un
    atributo con independencia de los demás, por ejemplo,
    el sueldo de un empleado tiene que ser mayor que
    60000.
  • compuestas: si implican más de una
    ocurrencia, como es el caso de las restricciones de
    comparación, por ejemplo, el sueldo de un empleado debe
    ser menor que el de su jefe. O bien , las llamadas de
    globalidad, por ejemplo, el sueldo medio de los empleados de un
    determinado departamento debe ser menor de 250000.

Los SGBD tienen que ofrecer en su lenguaje de
definición, facilidades que permitan describir las
restricciones con una sintaxis adecuada.

Por ejemplo, CREATE DOMAIN, CREATE ASSERTION, CREATE
INTEGRITY RULE

En general, una regla de integridad está
compuesta por tres componentes:

  • La restricción propiamente tal, que establece
    la condición que deben cumplir los datos.
  • La respuesta a la trasgresión, que especifica
    las acciones a tomar, como rechazar las operaciones, informar
    al usuario, corregir el error con acciones complementarias,
    etc.
  • Condición de disparo, que especifica
    cuándo debe desencadenarse la acción especificada en la
    restricción de integridad: antes, después o
    durante cierto evento.

Los triggers, son casos especiales de reglas de
integridad. Un trigger es un procedimiento que
se activa o dispara al ocurrir un evento, que tienen muchas
utilidades.

Las reglas de integridad deben almacenarse en el
diccionario de
datos, como parte integrantes de los datos(control centralizado
de la semántica), de modo que no han de incluirse
en los programas. Esto
trae algunas ventajas:

  • Las reglas de integridad son más sencillas de
    entender y de cambiar, facilitando su mantenimiento.
  • Se detectan mejor las inconsistencias.
  • Se protege mejor la integridad, ya que ningún
    usuario podrá escribir un programa que las transgreda,
    llevando a la BD a estados inconsistentes.

El subsistema de integridad del SGBD debe realizar las
siguientes funciones:

  • Comprobar la coherencia de las reglas que se
    definen.
  • Controlar las distintas transacciones y detectar las
    transgresiones de integridad.
  • Cuando se produce una transgresión, ejecutar
    las acciones pertinentes.
  1. En una base de datos es necesario asegurar que un
    valor x se encuentre en las tablas que determinan una
    relación, a esta condición se le denomina
    integridad referencial.

    1. Restricciones de
      Integridad

    En el mundo real existen ciertas restricciones que
    deben cumplir los elementos en él existentes; por
    ejemplo, una persona sólo puede tener un
    número de identificación y una única
    dirección oficial. Cuando se diseña una base
    de datos se debe reflejar fielmente el
    universo del discurso
    que estamos tratando, lo que es lo mismo, reflejar las
    restricciones existentes en el mundo real.

    Los componentes de una restricción son los
    siguientes:

    La operación de actualización
    (inserción, borrado o eliminación) cuya
    ejecución ha de dar lugar a la comprobación
    del cumplimiento de la restricción.

    La condición que debe cumplirse, la cual es
    en general una proposición lógica, definida
    sobre uno o varios elementos del esquema, que puede tomar
    uno de los valores de verdad (cierto o falso).

    La acción que debe llevarse a cabo
    dependiendo del resultado de la
    condición.

    En general, se puede decir que existen tres tipos
    de integridad:

    Integridad de dominio: restringimos los
    valores que puede tomar un atributo respecto a su dominio,
    por ejemplo EDAD >= 18 – 65.

    Integridad de entidad: la clave primaria de
    una entidad no puede tener valores nulos y siempre
    deberá ser única, por ejemplo la cedula de
    identidad.

  2. Integridad
    Referencial
  3. Disparadores

Un disparador es una orden que se ejecuta de manera
automática como efecto secundario de la
modificación de la base de datos. Para diseñar un
mecanismo disparador se debe tomar en cuenta lo
siguiente:

Especificar las condiciones en las que se va a ejecutar
el disparador. Esto se descompone en un evento que causa la
comprobación del disparador y una condición que de
debe cumplir para ejecutar el disparador.

Especificar las acciones que se va a realizar cuando se
ejecute el disparador.

Este modelo de disparadores se denomina modelo
evento-condición-acción.

Una vez que el disparador es almacenado en la base de
datos, el sistema asume la responsabilidad de ejecutarlo cada vez
que se cumpla el evento especificado y se satisfaga la
condición correspondiente.

Los disparadores son mecanismos útiles para
alertar a los usuarios o para realizar de manera
automática ciertas tareas cuando de cumplen determinadas
condiciones.

Por ejemplo, en el caso de un almacén
que desee mantener un inventario
mínimo por cada producto; cuando el nivel de inventario de
un producto cae por debajo del mínimo, se debe solicitar
un pedido automáticamente. Para la implementación
de este disparador se debe tomar en cuenta cuando se modifique el
nivel de inventario de un producto, el disparador debería
comparar el nivel con el mínimo y si el nivel es inferior
al mínimo se añadiría un nuevo
pedido.

  1. Los datos almacenados en la base de datos deben
    estar protegidos contra accesos no autorizados, de la
    destrucción o alteración malintencionada
    además de la introducción de inconsistencias que
    evitan las restricciones de integridad.

    1. Violaciones de
      la Seguridad
  2. Seguridad y
    autorización

En este grupo
tenemos:

  • Lectura no autorizada de los datos (robo de
    información).
  • Modificación no autorizada de
    datos.
  • Destrucción no autorizada de
    datos.

Un punto muy importante es lograr la seguridad de la
base de datos, aunque no es posible la protección
absoluta, pero se puede elevar lo suficiente para disuadir lo
suficiente la mayor parte, si no la totalidad, de los intentos de
tener acesso a la base de datos sin la debida
autorización.

Para lograr tal nivel de seguridad hay que adoptar
medidas en varios niveles:

  • Sistema de base de datos. Dar acceso a los
    datos a usuarios de acuerdo al tipo de usuario, esto quiere
    decir, que se debe dar los permisos correspondientes a una
    parte limitada de la base. Por ejemplo, a ciertos usuarios de
    la base de datos se les puede dar permiso para consulta pero no
    se les permite la modificación. Es responsabilidad del
    sistema gestor de base de datos asegurarse de que no se violen
    estas restricciones de autorización.
  • Sistema Operativo. La debilidad del sistema
    operativo puede servir como medio de acceso no autorizado a los
    datos. Lo importante aquí es que el sistema operativo
    debe ser seguro para minimizar la posibilidad de que se pueda
    ingresar a la base de datos.
  • Red. Este es un punto muy importante porque
    hoy en día casi todos los sistemas de base de datos
    permiten el acceso remoto desde terminales, la seguridad a
    nivel de red juega un papel muy
    importante.
  • Físico. Los sitios que contienen los
    sistemas informáticos como el lugar donde están
    los servidores por
    ejemplo, deben tener seguridades contra intrusos.
  • Humano. Los usuarios administradores de la
    base de datos deben ser cuidadosamente elegidos para reducir la
    posibilidad de que alguno de ellos dé acceso a personas
    no autorizadas.

Hay que tomar en cuenta que la debilidad de los dos
últimos puntos puede burlar las medidas de seguridad
tomadas para los niveles superiores.

  1. Autorizaciones

Los usuarios pueden tener varios tipos de
autorización.

  • Autorización de lectura.- permite la lectura
    de los datos, pero no su modificación.
  • Autorización de inserción.-
    permite la inserción de nuevos datos, pero no la
    modificación de los existentes.
  • Autorización de actualización.-
    permite la modificación de los datos, pero no su
    borrado.
  • Autorización de borrado.- permite el
    borrado de los datos.

Los usuarios pueden recibir todos los tipos de
autorización, ninguno de ellos o una combinación
determinada de los mismos.

Además de estas autorizaciones, los usuarios
pueden recibir autorización para modificar el esquema de
la base de datos:

  • Autorización de índices.-
    permite la creación y borrado de
    índices.
  • Autorización de recursos.-
    permite la creación de relaciones nuevas.
  • Autorización de alteración.-
    permite el añadido o borrado de atributos de las
    relaciones.
  • Autorización de eliminación.-
    permite el borrado de las relaciones.

Las autorizaciones de eliminación y de borrado se
diferencian en que la autorización de borrado sólo
permite el borrado de registros. Si un usuario borra todos los
registros de una relación, la relación sigue
existiendo, pero está vacía. Si se elimina una
relación deja de existir.

La capacidad de crear nuevas relaciones queda regulada
mediante la autorización de recursos. El usuario con la
autorización de recursos que crea una relación
nueva recibe automáticamente todos los privilegios sobre
la misma.

La autorización de índices puede parecer
innecesaria, dado que la creación o borrado de un
índice no afecta a los datos de las relaciones. Más
bien, los índices son una estructura
para la mejora del rendimiento. Sin embargo los índices
también ocupan espacio y se exige que todas las
modificaciones de las bases de datos actualicen los
índices. Si se concediera a todos los usuarios la
autorización de índices, los que llevaran a cabo
actualizaciones estarían tentados a borrar los
índices, mientras que los que formulan consultas
estarían tentados a crear numerosos índices. Para
permitir al administrador de la base de datos que regule el uso
de los recursos del sistema es necesario tratar la
creación de índices como un privilegio.

  1. Muchas aplicaciones de bases de datos seguras
    requieren que se mantenga una traza de auditoria. Una traza
    de auditoria es un registro histórico de todos los
    cambios (inserciones, borrados o actualizaciones) de la
    base de datos, junto con información con el usuario
    que realizo el cambio y en que momento.

    La traza de auditoria ayuda a la seguridad de
    formas diferentes. Por ejemplo, si el saldo de una cuenta
    es incorrecto, el banco desearía revisar todas las
    actualizaciones realizadas sobre la cuenta para encontrar
    las actualizaciones incorrectas (o fraudulentas),
    así como las personas que realizaron los
    cambios.

  2. Trazas de
    Auditoria
  3. Indexación a
    Asociación

Un índice sirve para encontrar datos
específicos en la base de datos se forma rápida y
eficiente. Muchas consultas solamente hacen referencia a una
pequeña porción de los registros de una tabla. Para
reducir el gasto adicional en la búsqueda de estos
registros se puede construir índices.

Tenemos dos tipos básicos de
índices:

  • Indices ordenados. Estos índices
    están basados en una disposición ordenada de los
    valores.
  • Indices asociados. (hash índices).
    Estos índices están basados en una distribución uniforme de los valores a
    través de una serie de cajones (buckets). El valor
    asignado a cada cajón está determinado por una
    función, llamada función de
    asociación.

Se consideran varias técnicas
de indexación y asociación. Ninguna es la mejor.
Sin embargo, cada técnica es la más apropiada para
una aplicación específica de bases de datos. Cada
técnica debe ser valorada bajo los siguientes
criterios:

  • Tipos de acceso. Los tipos de acceso que se
    soportan eficazmente. Estos tipos podrían incluir la
    búsqueda de registros con un valor concreto en
    un atributo, o buscar los registros cuyos atributos contengan
    valores en un rango especificado.
  • Tiempo de acceso. El tiempo que se tarda en
    buscar un determinado elemento de datos, o conjunto de
    elementos, usando la técnica en
    cuestión.
  • Tiempo de inserción. El tiempo empleado
    en insertar un nuevo elemento de datos. Este valor incluye el
    tiempo utilizado en buscar el lugar apropiado donde insertar el
    nuevo elemento de datos, así como el tiempo empleado en
    actualizar la estructura del índice.
  • Tiempo de borrado. El tiempo empleado en
    borrar un elemento de datos. Este valor incluye el tiempo
    utilizado en buscar el elemento a borrar, así como el
    tiempo empleado en actualizar la estructura del
    índice.
  1. El control de concurrencia en las bases de datos
    permite que la información se maneje en forma
    eficiente, permite además la ejecución de
    transacciones en paralelo, accesando a información
    compartida y, por lo tanto, interfiriendo potencialmente
    unas con otras. El hecho de reservar un pasaje aéreo
    por internet,
    cuando miles de personas pueden reservarlo también,
    nos da la idea de lo importante que es el manejo
    concurrente de la base de datos.

    El procesamiento de transacciones en línea
    es utilizado por entidades como bancos,
    aerolíneas ya que la forma de negocio que este tipo
    de entidades tiene así lo requiere, para que todo
    funcione correctamente, es necesario, que las bases de
    datos estén actualizadas todo el tiempo.

    Es una preocupación del programador que sus
    aplicaciones sean confiables y funcionen apropiadamente,
    pero a pesar de que estas aplicaciones son probadas antes
    de salir a producción, son vulnerables a ciertos
    errores que están fuera de su control. Estos errores
    potenciales surgen debido a dos factores: concurrencia y
    fallas.

    Un algoritmo de control de concurrencia asegura
    que las transacciones se ejecuten atómicamente,
    controlando la intercalación de transacciones
    concurrentes, estas se ejecutan una después de
    otra.

    El concepto principal es el de transacción.
    Informalmente, una transacción es la
    ejecución de ciertas instrucciones que accedan a una
    base de datos compartida. El objetivo del control de
    concurrencia y recuperación es asegurar que dichas
    transacciones se ejecuten atómicamente, es
    decir:

    Cada transacción accede a
    información compartida sin interferir con otras
    transacciones, y si una transacción termina
    normalmente, todos sus efectos son permanentes, caso
    contrario no tiene efecto alguno.

    1. En sistemas multiusuario, es necesario, un
      mecanismo para controlar la concurrencia, se pueden
      producir inconsistencias importantes derivadas del acceso concurrente, como
      por ejemplo, el problema de la operación
      perdida.

      En un sistema de biblioteca por ejemplo, existe un campo
      que almacena el número de copias disponibles de
      cada ejemplar que esta disponible. Este campo debe
      incrementarse en uno cada vez que una persona devuelve
      un libro y disminuye uno cada vez que se
      realiza un préstamo.

      El problema se da cuando existen varias
      bibliotecas, ubicadas en diferentes
      puntos alrededor de la ciudad, una de ellas inicia la
      transacción t1, leyendo la variable
      número de ejemplares (n) que se almacena en la
      variable n1. Tiempo después, otra biblioteca
      podría leer la misma variable
      incrementándola en una unidad,
      transacción t2. Después, la
      transacción t1 añade una unidad a esta
      variable y la actualiza, el resultado es
      erróneo, ya que la variable n debería
      haber aumentado en 2 unidades, y solo ha aumentado en
      una. La transacción t2 se ha perdido.

      1. Técnicas de control de
        concurrencia
    2. El problema del
      control de concurrencia
  2. Control de
    Concurrencia

Existen varias técnicas:

  • Pesimistas: bloqueo y marcas de
    tiempo
  • Optimistas
  1. Es una variable asociada a cada elemento de datos
    que describe el estado de dicho elemento respecto a las
    posibles operaciones (recuperación o
    actualización) que se pueden realizar sobre ellos en
    cada momento.

    Las transacciones pueden llevar a cabo bloqueos,
    impidiendo a otros usuarios la recuperación o
    actualización de los elementos bloqueados, para
    evitar inconsistencias en el acceso concurrente.

    Los SGBD tienen bloqueos (por registro, por tabla)
    para asegurar la consistencia. Los usuarios también
    pueden bloquear explícitamente los objetos,
    impidiendo el acceso por parte de otros
    usuarios.

    1. Tipos de
      Bloqueo
  2. Técnicas de
    bloqueo
  • Exclusivos: cuando una transacción
    mantiene un bloqueo de este tipo, ninguna otra
    transacción puede acceder al objeto bloqueado, ni
    bloquearlo, hasta que sea liberado por la transacción
    que lo había retenido. Se utiliza cuando se quiere
    actualizar datos.
  • Bloqueo compartido: cuando una
    transacción bloquea en este modo, permite que otras
    transacciones retengan también el objeto en bloque
    compartido, pero no exclusivo. Este tipo se utiliza cuando no
    se requiere actualizar datos, pero se desea impedir cualquier
    modificación mientras los datos son
    consultados.

El algoritmo que se utiliza se llama bloqueo de dos
fases (two phase locking).

El problema de las técnicas de bloqueo es que
puede producirse un interbloqueo (deadlock), dos o mas
transacciones están esperando cada una de ellas que la
otra libere algún objeto antes de seguir

Se puede solucionar:

  • Prevenir el deadlock: obliga a que las
    transacciones bloqueen todos los elementos que necesitan por
    adelantado. En caso de no poder
    conseguir todos esos elementos no bloquea ninguno y se queda en
    espera hasta volver a intentarlo.
  • Detectar el deadlock: Se controla de forma
    periódica si se ha producido un deadlock. Se construye
    un grafo en espera, cada nodo es una transacción en
    ejecución y un arco de una transacción Ti a Tj,
    en caso que Ti esté esperando un elemento que ocupa Tj.
    Si existe un ciclo en el grafo tenemos un deadlock. La
    solución es escoger transacciones víctimas y
    deshacerlas, hasta que desaparezca el deadlock. Cada SGBD tiene
    políticas diferentes para escoger
    víctimas.

Este tema influye notoriamente en el rendimiento de los
sistemas. Los SGBD pueden bloquear:

  • un campo de un registro (un atributo de una
    tabla)
  • un registro (una tupla)
  • un archivo (una tabla)
  • la BD total

Esto se llama granularidad del bloqueo.

Granularidad.- muy gruesa implica gestionar menor
número de bloqueos, pero retrasa la ejecución de
muchas transacciones (los objetos no se van liberando). Una
granularidad muy fina, permite mayor concurrencia, pero aparecen
más situaciones de deadlock que han de ser
resueltas.

  1. Protocolo de bloqueo
    de dos fases

Indica el momento en que una transacción puede
bloquear y desbloquear cada uno de los elementos de
datos.

Un protocolo que
asegura la secuencialidad en cuanto a conflictos es
el protocolo de bloqueo en dos fases. Este protocolo exige que
cada transacción realice las peticiones de bloqueo y
desbloqueo en dos fases:

  1. Fase de crecimiento.- Una transacción
    puede obtener bloqueos pero no puede liberarlos.
  2. Fase de decrecimiento.- Una
    transacción puede liberar bloqueos pero no puede
    obtener ninguno nuevo.
  1. Técnicas de
    marca de
    tiempo (timestamping)

Las marcas de tiempo son identificadores únicos
que se asignan a las transacciones, que se consideran como el
tiempo de inicio de una transacción. Con esta
técnica no existen bloqueos. Ordena las transacciones. Se
retrasan.

  1. Técnicas
    optimistas

Las transacciones acceden libremente a los elementos, y
antes de finalizar se determina si ha habido
interferencias.

Este tipo de técnicas considera que las
transacciones tienen 3 fases:

  • Lectura: las transacciones realizan
    operaciones sobre copias privadas de los objetos (accesibles
    solo por la transacción)
  • Validación : en la que se comprueba si
    el conjunto de objetos modificados por una transacción
    se solapa con el conjunto de objetos modificados por alguna
    otra que haya hecho la validación durante la fase de
    lectura de dicha transacción
  • Grabación: en el caso de no detectar
    interferencias se graban las modificaciones, convirtiendo las
    versiones privadas de los objetos en versiones
    actuales.
  1. Procesamiento de
    consultas

El procesamiento de consultas hace referencia a la serie
de actividades implicadas en la extracción de la
información de la base de datos. Estas actividades
incluyen la traducción de consultas expresadas en
lenguajes de bases de datos de alto nivel en expresiones
implementadas en el nivel físico del sistema, así
como transformaciones de optimización de consultas y la
evaluación real de las mismas.

Los pasos básicos para el procesamiento de una
consulta son:

  • Análisis y traducción
  • Optimización
  • Evaluación

Antes de realizar el procesamiento de la consulta, el
sistema debe traducir la consulta en una utilizable. Un lenguaje
como SQL es adecuado para el uso humano, pero es poco apropiado
para una representación interna en el sistema de la
consulta. Así, una representación más
útil es la basada en el álgebra
relacional extendida.

Entonces, la primera acción que el sistema
realiza es esta traducción de la consulta al formato
interno. Este proceso es similar al que realiza el analizador de
un compilador. Durante este proceso, el analizador comprueba la
sintaxis de la consulta del usuario, verifica que sean nombres de
las relaciones en la base de datos, etc.

Para especificar completamente cómo evaluar una
consulta, no basta con proporcionar la expresión del
álgebra relacional, además hay que anotar en ellas
las instrucciones que especifiquen cómo evaluar cada
operación. Estas anotaciones podrían ser el
algoritmo a usar para una operación específica o el
índice o índices concretos a utilizar. Las
operaciones de álgebra relacional anotadas con
instrucciones sobre la evaluación recibe el nombre de
primitivas de evaluación. Una secuencia de operaciones
primitivas que se pueden utilizar para evaluar una consulta
establecen un plan de
ejecución de la consulta o plan de evaluación de la
consulta.

Gráfico # 4: Pasos en el
procesamiento de una consulta

Fuente: Fundamentos de bases de
datos

Partes: 1, 2, 3, 4
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter