2007/02/24

TRANSACCIONES

Los sistemas que tratan el problema de control de concurrencia permiten que sus usuarios asuman que cada una de sus aplicaciones se ejecutan atómicamente, como si no existieran otras aplicaciones ejecutándose concurrentemente.

Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como una transacción.

Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar la ilusión de que las transacciones se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializables y son correctos ya que soportan la ilusión de la atomicidad de las transacciones.

El concepto principal es el de transacción. Informalmente, una transacción es la ejecución de ciertas instrucciones que accesan 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, en caso contrario no tiene afecto alguno.

Una base de datos está en un estado consistente si obedece todas las restricciones de integridad (significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondientes debe existir) definidas sobre ella.

Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia.

Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente.

El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción.

No hay comentarios:

ANTEPROYECTO S.I.E.D.

ANTEPROYECTO
View SlideShare presentation or Upload your own.

Software Libre



REPRESENTACION DIAGRAMA E-R

REPRESENTACION DIAGRAMA E-R

FRASES DE RELACION DE ESTE MODELO E-R

FRASES DE RELACION DE ESTE MODELO E-R

III. DIAGRAMA ENTIDAD - RELACION

III. DIAGRAMA ENTIDAD - RELACION

DISEÑO DE BASES DE DATOS DISTRIBUIDAS

DISEÑO FISICO

El diseño físico parte del esquema lógico y da como resultado un esquema físico. Es una descripción de cómo está almacenada la base de datos en la memoria secundaria; describe las estructuras de almacenamiento y los métodos usados para tener un acceso efectivo a los datos. Los esquemas lógicos y físicos se expresan haciendo uso del lenguaje de definición de datos del DBMS elegido; la base de datos se crea y se carga, y puede ser probada. Lo mismo, puede probarse las aplicaciones sobre la base de datos y de este modo la base de datos se vuelve operacional.

DISEÑO LÓGICO

Parte del esquema conceptual y da como resultado el esquema lógico. El esquema lógico es una descripción de la estructura de la base de datos que puede procesar el software DBMS. El modelo lógico más usado actualmente, es el modelo relacional que ha sido enriquecido con los modelos orientados por objetos. El modelo lógico no depende del DBMS en particular, sino del modelo de datos usado por el DBMS.

DISEÑO CONCEPTUAL

Parte de la especificación de requerimientos y su resultado es el esquema conceptual, cuyo propósito es describir el contenido de información de la base de datos, más que las estructuras de almacenamiento que se necesitarán para manejar la información. Es una descripción de alto nivel que es completamente independiente del software de DBMS que se use, incluso si se pensara en implementar con archivos tradicionales y con algún lengauje de programación convencional.

Archivo del blog