17.4.05

Procesamiento de Transacciones en Sistemas Distribuidos

Transacción
Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. 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.
Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.

El concepto fundamental aquí es la noción de ?ejecución consistente? o ?procesamiento confiable? asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable.

Ejemplo 3.1: Considere la siguiente consulta en SQL para implementar el 10% del presupuesto del proyecto ?CAD/CAM? de la base de datos ?J?.

J (JNO, JNOMBRE, PRESUPUESTO, LUGAR)

UPDATE J

SETPRESUPUESTO = PRESUPUESTO * 1.1

WHEREJNOMBRE = ?CAD/CAM?

Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre:

Begin_transaction ACTUALIZA_PRESUPUESTO

begin

UPDATE J

SETPRESUPUESTO = PRESUPUESTO * 1.1

WHEREJNOMBRE = ?CAD/CAM?

End.

Ejemplo 3.2: Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones.

FLIGHT (FNO, DATE, SRC, DEST, STSOLD, CAP)

CUST (CNAME, ADDR, BAL)

FC (FNO, DATE, CNAME, SPECIAL)

Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción:

Begin_transaction RESERVACION

begin

input (flight_no, date, customer_name);

EXEC SQL

UPDATE FLIGHT

SETSTSOLD = STSOLD + 1

WHEREFNO = flight_no

ANDDATE = date

EXEC SQL

INSERT

INTO FC (FNO, DATE, CNAME, SPECIAL)

VALUES (flight_no, date, customer_name, null)

Output (?Reservación terminada?)

End.

Mecanismos de recuperación

A fin de soportar una respuesta favorable para la ejecución de transacciones, el DBMS (Sistema Manejador de Bases de Datos) deberá de manejar el procesamiento de transacciones. Esto es, deberá de garantizar que si la transacción ejecuta algunas modificaciones y después se presenta una falla (por cualquier razón), antes de que llegue al termino normal de la transacción, se anularán esas modificaciones. Así, o bien se lleva a cabo la transacción en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo desde un punto de vista externo. El componente del sistema encargado de lograr esta apariencia de atomicidad se conoce como Manejador de transacciones, y las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento.

La operación COMMIT señala el término exitoso de la transacción: le dice al manejador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos esta (o debería estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.

La operación ROLLBACK, en cambio, señala e término no exitoso de la transacción: le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse.

Ejemplo 3.3: Considerando el ejemplo 3.2, veamos el caso cuando no existen asientos disponibles para hacer la reservación.

Begin_transaction RESERVACION2

begin

input (flight_no, date, customer_name);

EXEC SQL

SELECTSTSOLD, CAP

INTOtemp1, temp2

FROMFLIGHT

WHEREFNO = flight_no

ANDDATE = date

If temp1 = temp2 then

Output (?No hay asientos libres?)

Abort

else

EXEC SQL

UPDATEFLIGHT

SETSTSOLD = STSOLD + 1

WHEREFNO = flight_no AND DATE = date

EXEC SQL

INSERT

INTO FC (FNO, DATE, CNAME, SPECIAL)

VALUES (flight_no, date, customer_name, null)

Commit

Output (?Reservación terminada?)

endif

End.

PROPIEDADES ACID (Atomicity, Consistency, Isolation, Durability)

Una transacción posee cuatro propiedades fundamentales

Atomicidad. Una Transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito un fracaso ("todo o nada").
Consistencia. Después de ejecuta una Transacción debe dejar al sistema en estado correcto o debe abortarlo. Si la Transacción no puede alcanzar un estado final debe regresar al sistema a su estado original.
Aislamiento. El comportamiento de una Transacción no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una Transacción no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La Transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.
Durabilidad. Los efectos de una Transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia).
BITÁCORA
La operación ROLLBACKesta basada en el uso de una ?bitacora?. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (mas comúnmente), en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondientede la bitácora para restaurar el valor original del objeto restaurado.
PUNTO DE SINCRONIZACION
Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de una programa. Cuando se establece un punto de sincronización:
    Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.
    Se pierde todo posible posicionamiento en la base de datos.
    Se liberan todos los registros bloqueados.
Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.
TIPOS DE TRANSACCIONES
    Transacciones simples. Todas las operaciones se llevan acabo en el mismo nivel dentro de una T

La Transacción empieza con un begin_transaction y termina ya sea con un commit_transaction o abort_transaction. Toda la transacción es indivisible.

En un principio las Transacciones simples fueron suficientes por su sencillez y por su adaptación a operaciones bancarias breves. Actualmente las Transacciones han incursionado en todas las facetas de la computación pero no han resultado lo más adecuado, ya que tienen un comportamiento:

Frágil: En transacciones de negocios que se extienden por períodos largos.
Débil: En procesamiento por lotes.
Nulo:Situaciones que requieren dar marcha atrás.
Una Transacción simple no dura más de dos o tres segundo para evitar monopolizar recursos críticos del sistema como candados sobre la base de datos. Así que los programas OLTP se dividen en transacciones breves ejecutadas una tras otra para producir resultados.
    Transacciones simples distribuidas. Una T simple puede correr en sitios múltiples y actualizar recursos localizados dentro de administradores de recursos múltiples.
    Transacciones encadenadas (syncpoint, encadenadas y sagas). Un syncpoint es un punto de sincronización que permite el guardado periódico del trabajo acumulado dentro de una transacción, permitiendo de esta forma dar marcha atrás al trabajo sin, abortar la transacción. Sin embargo este trabajo no es almacenado permanentemente, por lo que si el sistema se colapsa el trabajo se pierde. Las transacciones encadenadas son una variación de los syncpoint que convierten en durable el trabajo acumulado. Las sagas extienden las transacciones encadenadas a fin de dar marcha atrás a una cadena entera si es necesario.
    Transacciones anidadas. Ofrecen la posibilidad de definir transacciones dentro de otras transacciones. cada subtransacción puede emitir una grabación o retroceso para las piezas de trabajo asignadas.
PROTOCOLO DE BITÁCORA ADELANTADA
Se considera que una transacción es una unidad de recuperación. Pues si una transacción se realiza con éxito, el sistema deberá garantizar el establecimiento permanente de sus modificaciones en la base de datos, aún si el sistemas cayera en el instante siguiente. Es muy posible, por ejemplo, una caída del sistema después de haberse realizado una instrucción COMMIT, pero antes de grabarse físicamente las modificaciones en la base de datos, podrá descubrir los valores que se deben grabar examinando las entradas pertinentes de la bitácora. Para ello la bitácora se deberá haber grabado físicamente antes de que se pueda completar el procesamientode una instrucción COMMIT. Esta importante regla se conoce como Protocolo de Bitácora de Escritura adelantada. De esta forma, el procedimiento de reinicio recuperará todas las transacciones completadas con éxito pero cuyas modificaciones no lograron grabarse físicamente antes de la caída.
TIPOS DE FALLAS
Una falla local sólo afecta a la transacción en la cual se presentó esa falla, como por ejemplo un ?overflow?. Tales fallas son recuperables mediante los mecanismos de soporte de la instrucción COMMIT.
Una falla global afecta a varias transacciones (y con mucha probabilidad a la totalidad) de las transacciones que se estaban efectuando en e momento de la falla. Tales fallas se dividen en dos tipos:
    Fallas del sistema, (por ejemplo interrupciones del suministro de electricidad) las cuales afectan a todas las transacciones que se están realizando pero no dañan físicamente a la base de datos.
    Falla de los medios de almacenamiento (por ejemplo, un aterrizaje de cabezas en el disco), las cuales si causan daños a la base de datos o a una porción de ella, y afectan al menos a las transacciones que están utilizando esa porción.
RECUPERACIÓN A FALLAS EN EL SISTEMA
El método convencional se basa en el establecimiento síncrono de un ?punto de revisión?, lo cual implica:
    Grabar físicamente el contenido de los ?buffers? de datos en la base de datos física (compromete las modificaciones a la base de datos).
    Grabar físicamente un registro de punto de revisión especial en la bitácora físicamente, el cual incluye una lista de todas las transacciones que se estaban realizando en el momento de establecerse el punto de revisión.
Ejemplo:
    Se presentó una falla en el momento tf.
    El punto de verificación mas reciente antes de tf se tomó en el momento tv.
    Las transacciones del tipo T1 se completaron antes del tiempo tv.
    Las transacciones del tipo T2 se iniciaron antes del tiempo tv y se completaron después del tiempo tv y antes del tiempo tf.
    Las transacciones del tipo T3 también se iniciaron antes del tiempo tv pero no se completaron antes del tiempo tf.

    Las transacciones del tipo T4 se iniciaron después del tiempo tv y se completaron antes del tiempo tf.

    Por último, las transacciones del tipo T5 también se iniciaron después del tiempo tv pero no se completaron antes del tiempo tf.

Al reiniciarse el sistema deberán de anularse las transacciones del los tipos T3, T5 y deberán realizarse de nuevo las transacciones de los tipos T2 y T4. Note que las transacciones de tipo T1 no entran en el proceso de reinicio, ya que sus modificaciones se grabaron físicamente en la base de datos en el momento tv como parte del proceso de punto de revisión.
En el momento de reinicio del sistema se efectúa el siguiente procedimiento a fin de identificar las transacciones de los tipos T2-T5.
    Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR. Igualar la lista ANULAR a la lista de todas las transacciones incluidas en el registro de punto de revisión. Dejar vacía la lista REPETIR.
    Examinar la bitácora hacia delante a partir del registro de punto de revisión.
    Si se encuentra una entrada de bitácora de ?iniciar transacción? para la transacción T, añadir T a la lista ANULAR.
    Si se encuentra una entrada de bitácora de ?comprometer? para la transacción T, pasar esa transacción de la lista ANULAR a la lista REPETIR.
    Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR identificarán respectivamente, las transacciones de los tipos T3 y T5 y las de los tipos T2 y T4.
A continuación el sistema revisará la bitácora hacia atrás, anulando todas las transacciones de la lista ANULAR. A continuación la revisará otra vez hacia delante, realizando de nuevo todas las transacciones en la lista REPETIR, los cual finalízale proceso de recuperación.
RECUPERACIÓN A FALLAS EN LOS MEDIOS DE ALMACENAMIENTO
Una falla en los medios de almacenamiento es un percance en el cual se destruye físicamente alguna porción de la base de datos. La recuperación de una falla semejante implica en esencia cargar de nuevo la base de datos a partir de una copia de respaldo y utilizar después la bitácora (tanto la porción activa como la de archivo en general) para realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia de respaldo.
MONITORES TP (Transaction Processing)
Un monitor de TP es un sistema operativo de procesamiento de transacciones que tiene como funciones principales:

Administración de procesos:

    Poner en marcha los procesos del servidor
    Canalizar el trabajo en dirección a ellos
    Vigilar su correcta ejecución
    Equilibrar cargas de trabajo
Administrador de transacciones
    Garantiza las propiedades ACID para todo los programas bajo su protección
Los monitores se especializan en la administración de transacciones desde su punto de origen (por lo general en el cliente), ya través de uno o más servidores, para luego volver al cliente originario. Cuando una T llega a su fin, el monitor de TP debe cerciorarse de que todos los sistemas involucrados en ella queden en estado consistente. De esta forma un monitor de TP sabe como correr T, enrutarlas entre diferentes sistemas, equilibrar las cargas de ejecución y ponerlas nuevamente en marcha después de una falla. Todo esto sin importar los sistemas, ni los administradores de recursos.
Surgen de la necesidad de correr aplicaciones capaces de atender a cientos o miles de clientes, ya que los monitores permiten conectar en tiempo real a miles de clientes que esperan un servicio, sin necesidad de consumir tantos recursos.
Ejemplo: si un cliente necesita para ser atendido de los siguientes recursos: 1 proceso, 1 conexión, ½Mb de RAM y una docena de archivos abiertos; y además si se atienden 1000 clientes al mismo tiempo tendríamos las siguientes situaciones:
a). Sin monitor TP

1000 clientes 1000 conexiones

1000 procesos

500 Mb de RAM

10000 archivos abiertos

SO de bajodesempeño

b). Con monitor TP

1000 clientes MONITOR TP 50 conexiones

50 procesos

25 Mb de RAM

500 archivos abiertos

SO de buen desempeño

Generalmente en los entornos de PC el servidor suele tener sus aplicaciones de procesamiento de transacciones en línea (OLTP: On Une Transaction Processing) empaquetadas en calidad de librerías de enlace dinámico (DLL Dinamic Link Library). El monitor de TP, entonces, asigna la ejecución de las funciones DLL a clases de servidor, a procesos de fondo o a hilos preiniciados en espera de un trabajo.

Cómo realiza el monitor de TP su acto de canalización

Cuando un cliente solicita un servicio, el monitor TP la destina aun proceso, el cual se enlaza con la función DLL llamada por el cliente, la invoca, supervisa su ejecución y regresa los resultados al cliente. Una vez concluido el trabajo el proceso servidor regresa los resultados y el proceso puede ser reutilizado por otro cliente. El SO conserva en memoria las DLL para que puedan ser compartidas por otros procesos.

Si el número de solicitudes de clientes recibidas excede el número de procesos en el servidor, el monitor puede iniciar dinámicamente otros nuevos (equilibrio de cargas). Parte del equilibrio de cargas es la administración de prioridades en las solicitudes recibidas, de esta forma solicitudes con prioridad alta se asignan a clases de servidor de alta prioridad. También el monitor de TP puede dividir sus clases de acuerdo al tipo de aplicación, tiempo de respuesta deseado, recursos que administran, requerimientos de tolerancia a fallas, etc.

A un monitor de TP lo podemos ver como una arquitectura cliente / servidor compuesta de tres planos: una interfaz gráfica GUI, la lógica de aplicación y los administradores de recursos.

BENEFICIOS DE UN MONITOR TP

Estructura de desarrollo de aplicaciones cliente/servidor. Los monitores TP proporcionan una estructura preconstruida que ayuda a formar, operar y administrar una aplicación cliente/servidor. Permite. construir aplicaciones cliente/servidor robustas y de alto desempeño.
Muros de protección. Implementan muros de protección entre aplicaciones y administradores de recursos, así como entre las mismas aplicaciones.
Alta disponibilidad. Los monitores TP están diseñados para sortear todo tipo de fallas, permite crear sistemas autoremediables, ya que siempre están al tanto del estado de los recursos de cliente / servidor bajo su control, pueden detectar una falla en el momento mismo que ocurren y decidir si reinicia el proceso fallido o retrocede y conmuta aun proceso en otro nodo. (arquitecturas sin un sólo punto de falla).
Equilibrio de cargas. Los monitores de TP se especializan en la administración de procesos y soportan técnicas de carga tanto estáticas como dinámicas; soportan solicitudes con prioridad y pueden duplicar dinámicamente procesos del servidor en el mismo nodo o en otro diferente.
Facilidad de ampliación de funciones. Los monitores TP alientan la creación de procedimientos modulares reutilizables. Los monitores sólo exportan las funciones y no los datos, así se podría seguir añadiendo nuevas funciones y permitir que el monitor de TP las distribuya entre múltiples servidores. De esta forma se podrían construir aplicaciones distribuidas de alta complejidad con sólo agregar procedimientos.

Costo reducido del sistema. De acuerdo a estudios, si se usan monitores de TP se puede ahorrar más del 30% del costo total del sistema, un 40% en costos de desarrollo y ahorros en la adquisición de recursos.

Generalmente, se recomienda usar un monitor de TP si su aplicación cliente / servidor tiene más de 100 clientes, que procesen cinco o más transacciones por minuto, emplee tres o más servidores y/o haga uso de dos o más BD.
TIPOS DE PROCESAMIENTO DE TRANSACCIONES
Existe una clasificación para el procesamiento de transacciones:
    TP ligero (TP lite) el cual se limita a integrar monitores TP a los administradores de BD.
    TP pesado (TP heavy) en donde los monitores TP extienden la noción de transacción a todos los recursos usados para el procesamiento de transacciones.
Podemos hacer una serie de comparaciones entre ellos:
a) Alcance de la grabación
TP ligero





TP pesado

b) Administración de recursos. Mientras que el TP ligero sólo realiza actualizaciones en BD, los TP pesados realizan actualizaciones AGIO (manteniendo las propiedades de las transacciones) en múltiples administradores de recursos heterogéneos dentro del alcance de una sola transacción.

c) Administración de procesos. Los TP ligeros cargan el procedimiento, lo ejecutan y si acaso lo guardan en la memoria caché para su uso posterior. Los TP pesado cuentan con servidores preiniciados, equilibrio dinámico de carga, planeación de acuerdo a prioridades, muros de protección, redireccionamiento a otros servidores, etc.

d) Invocaciones cliente/servidor. Generalmente los TP ligeros tiene su propia forma de invocar a los RPG del servidor y no cuentan con mecanismos de autenticación, ni están integradas a directorios globales.

e) Desempeño. Los procedimientos en Trligero son mucho más veloces porque reducen en mucho el tráfico en la red y requieren menos hardware.

Fuente: http://www.ittehuacan.edu.mx/ittehuacan/
Fernando A. Mas

14.4.05

Ventajas del enfoque de BD


Disminuir la redundancia

Si hay, debe estar controlado por el DBMS

En los sistemas con BD cada aplicación tiene sus propios archivos privados. Esto puede provocar considerablemente redundancia en los datos almacenados. Con el consecuente desperdicio de espacio de almacenamiento. Es posible tener alguna redundancia pero es controlada por el DBMS, y asumir la responsabilidad de “propagar las actualizaciones”.

Evitar la inconsistencia

(hasta cierto punto) Datos erróneos.

Es un corolario del punto anterior. Si se elimina la redundancia, no hay inconsistencia. Si no se elimina la redundancia, aparece la inconsistencia. La redundancia, si es controlada por el DBMS, garantiza la consistencia de la BD desde el punto de vista del usuario asegurándose de aplicar en forma automática a la otra entrada cualquier modificación hecha en alguna de ellas (propagación de actualizaciones). Hoy en día la mayor parte de los productos no permiten la redundancia controlada, excepto en unos pocos casos excepcionales.

Compartir los datos

DBMS se encarga que si se esta actualizando un dato y el otro no pueda acceder.

Es posible satisfacer las necesidades de información de las aplicaciones nuevas sin tener que almacenar datos adicionales. El compartimiento (sharing) también permite poder desarrollar aplicaciones nuevas para trabajar con los mismos datos almacenados.

Hacer cumplir las normas

Al tener control centralizado de la BD, el DBA (siguiendo las indicaciones del DA) puede garantizar la observancia de todas las normas aplicables para la representación de los datos. Es deseable sobre todo como apoyo para el intercambio de información, o migración de datos entre sistemas. Las normas para nombrar y documentar los datos son muy convenientes como ayuda para el compartimiento y comprensibilidad de la información.

Aplicar restricciones de seguridad

Al tener jurisdicción completa sobre la BD, el DBA puede:

a) Asegurar que el acceso a la BD sea sólo a través de los canales apropiados.

b) Definir las verificaciones de seguridad por realizar cuando se intente acceder a información delicada.

Es factible establecer diferentes verificaciones para cada tipo de acceso a cada elemento de información de la BD.

Mantener la integridad

la define y controla el DBMS, DBA le dice al DBMS

Que la información sea correcta. Para no tener información errónea, el administrador de datos define (y el DBA pone en práctica) las verificaciones de integridad que deben realizarse en toda operación de actualización (inserción, borrado y modificación) de los datos. Sin los controles apropiados, un usuario podría modificar en forma incorrecta la BD, generando información errónea e “infectando” así a otros usuarios

Equilibrar requerimientos opuestos

Al conocer los requerimientos generales de una empresa (en contraste con los de cualquier usuario individual), el DBA puede estructurar el sistema con miras a proporcionar un servicio general “óptimo para la empresa”. Por ejemplo es posible escoger una forma de representación de los datos almacenados con la cual las aplicaciones mas importantes puedan tener un acceso rapido aunque el funcionamiento de otras aplicaciones sufra menoscabo.

No es tan evidente pero es contar con la independencia de los datos (objetivo de los sistemas de BD).

INDEPENDENCIA DE LOS DATOS:

- POSIBILIDAD DE MODIFICAR LA ESTRUCTURA DE LOS DATOS Y NO RESCRIBIR O CAMBIAR. EJEMPLO, EL APELLIDO 20 CARACTERES, MODIFICAR LA ESTRUCTURA DEL ALMACENAMIENTO Y NO DEBE INFLUENCIAR EN LOS PROGRAMAS DE APLICACIÓN, NO TOCARLOS.

- SE ASPIRA PERO ES DIFÍCIL.

La independencia puede definirse como la inmunidad de las aplicaciones ante los cambios en la estructura de almacenamiento y en la técnica de acceso, lo cual implica, que las aplicaciones no dependen de una estructura de almacenamiento o una técnica de acceso especificas.

ADMINISTRACIÓN DE DATOS Y ADMINISTRACIÓN DE BD

ADMINISTRACIÓN DE DATOS Y ADMINISTRACIÓN DE BD

Administrador de datos (DA): Conoce la información y las necesidades de la empresa, en un nivel gerencial superior. Su labor es decidir en primer término cuáles datos deben almacenarse en la BD, y establecer políticas para mantener y manejar los datos una vez almacenados (es un gerente no un técnico, aunque sí necesita apreciar las posibilidades de los sistemas de BD en un nivel técnico). Ejemplo una política de seguridad.

Administrador de BD (DBA): Es un profesional en procesamiento de datos. La tarea es crear la BD en sí y poner en vigor los controles técnicos necesarios para apoyar las políticas dictadas por el DA. Se encarga también de garantizar el funcionamiento adecuado del sistema y de proporcionar otros servicios de índole técnica relacionados. Es un equipo de varias personas (programadores asistentes técnicos).

DBA

ESQUEMA CONCEPTUAL

- Fijar las estructuras de todos los almacenamientos del sistema y las relaciones de los almacenamientos.

- Definir si existe el archivo y con qué estructura.

ESQUEMA INTERNO

- En qué medios de almacenamiento estará la BD y que métodos o técnica se accede (Ej. índice).

VINCULARSE CON EL USUARIO

- Solucionar problemas que puedan tener los usuarios.

DEFINE SEGURIDAD

- Del sistema de BD tal usuario puede utilizar tales archivos.

RECUPERACIÓN Y RESPALDO

- Depende de la organización definimos tiempo, tamaño. ejemplos, discos espejos en computadoras paralelas, backup, etc,

SUPERVISAR EL DESEMPEÑO

- Performance e ir ajustándolas, índices grandes cambiar la forma de acceso.

Porque utilizar una BD?

En caso de que sea multiusuario existen muchas ventajas adicionales, donde la BD es con toda probabilidad mucho más grande y compleja. Ofrece control centralizado de su información.

* Es compacto: no hacen falta archivos de papales que pudieran ocupar mucho espacio.

* Es rápido: la máquina puede obtener y modificar con mucha mayor velocidad que un ser humano.

* Es menos laborioso: se elimina gran parte del tedio de mantener archivos a mano.

* Es actual: se dispone en cualquier momento de información precisa y al día.

Tiene aun mas importancia, en un ambiente multiusuario, donde la BD es con toda probabilidad mucho mas grande y compleja que un uno de un solo usuario. El sistema de BD ofrece a la empresa un control centralizado de su información.

ENTIDADES E INTERRELACIONES

· Entidad: se refiere a cualquier objeto distinguible que ha de representarse en la BD del cual deseamos registrar información.

· Interrelaciones: éstas permiten vincular dichas entidades. Se representan por líneas o arcos de conexión. Además, forman parte de la información, tanto como las entidades básicas. Son bidireccionales

PROPIEDADES DE LA ENTIDAD

Se representan en la BD, y son las características propias de una entidad. Una propiedad dada podría ser por naturaleza muy sencilla, o bien poseer una estructura interna de complejidad arbitraria. Los sistemas actuales de BD no son muy adecuados para manejar propiedades complejas como diagramas o textos.

12.4.05

¿QUÉ ES UN SISTEMA DE BD?

¿QUÉ ES UN SISTEMA DE BD?

Es un sistema para archivar en computador; o sea, es un sistema computarizado cuyo propósito gral. Es mantener información y hacer que esté disponible cuando se solicite.

DATOS

ARCHIVOS

REGISTROS

CAMPOS

Diferencia entre dato (valores almacenados en la BD) e Información (se refiere al significado de esos valores desde el punto de vista de algún usuario).

REFERENTES A UNA ORGANIZACIÓN, VAMOS DETECTANDO ENTIDADES FISICAS Y ABSTRACTAS (CUENTA BANCARIA) Y ESTÁS SERÁN DE IMPORTANCIA PARA LA ORGANIZACIÓN QUE VAN A SER ALMACENADAS EN UN MEDIO FÍSICO PARA SER USADAS POR DETERMINADAS PERSONAS (INTERES).

4 Componentes de un sistema de BD

SISTEMA DE BD

DATOS O INFORMACIÓN

COMPARTIDOS

INTEGRADOS

HARDWARE O EQUIPOS

SOFTWARE O PROGRAMAS

DBMS

PROGRAMAS DE APLICACIÓN

HERRAMIENTAS

USUARIOS

1- INFORMACIÓN

Varios usuarios pueden tener acceso a la BD al mismo tiempo, el objetivo es lograr que cada individuo pueda comportarse como si estuviera trabajando con un sistema de un solo usuario.

Conviene suponer que todos los datos almacenados en el sistema se mantienen en una sola base de datos. Pero en la practica pueden existir razones de peso, aun en sistemas pequeños, para repartir la información en varias bases de datos distintas.

La información en la base estará integrada y compartida.

· Integrada: la BD puede considerarse como una unificación de varios archivos de datos, por lo demás distintos, y que elimina del todo o en parte cualquier redundancia entre ellos.

· Compartida: más de 1 usuario acceda simultáneamente a los mismos datos (acceso concurrente o no).

Otra consecuencia del mismo hecho (la integración de la base de datos) es que por lo regular un usuario determinado solo se ocupara de un subconjunto de la base de datos total. Diferentes usuarios percibirán la BD de varias maneras distintas. De hecho, aun cuando 2 usuarios compartan el mismo subconjunto de la BD, la forma como vean ese subconjunto puede diferir de manera considerable en los detalles.

2- EQUIPO

Computadoras, almacenamiento, volúmenes en red o únicos en un disco.

Los componentes de equipo del sistema que consisten son:

· Los volúmenes de almacenamiento secundario donde se conservan los datos almacenados junto con los dispositivos E/S asociados, controladores de dispositivos, canales de E/S, y demás.

· El procesador o procesadores y la memoria principal asociada que hacen posible la ejecución de programas del sistema de BD.

3- PROGRAMAS

a) Entre la BD física misma y los usuarios del sistema existe un nivel de programas, el sistema de administración de BD (DBMS). El DBMS maneja todas las solicitudes de acceso a la BD formuladas por los usuarios, tanto como la adición o eliminación de archivos (tablas), la obtención y puesta al día de datos de esos archivos. Una de las funciones generales es distanciar a los usuarios de la BD de detalles al nivel del equipo.

El DBMS presenta a los usuarios una vista de la BD en un nivel tanto por encima del nivel del equipo, y hace posibles sus operaciones, es un componente de software más importante pero no el único (utilerías, generadores de informes, herramientas para desarrollar aplicaciones).

Software compuesto por un conjunto de módulos, interfaces que los usuarios ven a los datos de los medios físicos. Almacenado en: un archivo de datos, archivos índices que permiten el acceso más rápido a los archivos almacenados. Mediante apuntadores acceso directo. Y también un Diccionario de Datos que contiene la información de la estructura de los archivos de datos, tipo de dato lógico, booleano, tamaño...(motor de la BD).

El DBMS es definitivamente el componente de software mas importante de todo el sistema, pero no es el único. entre los demás pueden mencionarse las utilerías, las herramientas para desarrollar aplicaciones, las ayudas para el diseño, los generadores de informes, etc.

b) Programas de aplicación: para que un usuario acceda a los datos.

c) Herramientas: p/ generar informes, formularios, p/ programadores y algunos que sepan un poco más.

4- USUARIOS

Se toman en cuenta tres clases de usuarios (personas que interactúan con el sistema):

· Programador de aplicaciones: Se encarga de escribir los programas de aplicación que utilizan la BD. Estos programas operan sobre los datos en todas las formas acostumbradas: recuperación, inserción, modificación o eliminación de datos. Se lleva a cabo solicitudes apropiadas al DBMS. Genera aplicaciones para que otros usuarios con conocimientos mínimos ingresen.

· Usuario final: Quien interactúa con el sistema desde una terminal en línea, puede tener acceso a la BD a través de una de las aplicaciones en línea mencionadas, o utilizar una interfaz incluida como parte integral de los programas del sistema de BD. (ej. SQL).

ü INGENUO: pantalla y nada más.

ü SOFISTICADO: consultas de datos, conoce un poco más, programas de aplicación.

ü ESPECIALIZADO: herramientas con imágenes...

La mayor parte de los sistemas incluyen también interfaces integradas adicionales con las que el usuario no necesita emitir mandatos explícitos como SELECT, sino que funcionan mediante la elección de opciones de un menú o el llenado de una forma. Estas interfaces suelen ser mas fáciles de usar en el caso de personas sin estudios formales de procesamiento de datos. Las interfaces manejadas mediante mandatos (como los lenguajes de consulta) tienden a requerir ciertos conocimientos sobre procesamientos de datos.

· Administrador de BD (DBA): Persona que centraliza la responsabilidad y control de la BD. Técnico responsable de poner en práctica las decisiones del administrador de datos. Trabaja en interacción con el DA, no es considerado un usuario, es quien diseña el sistema, puesto gerencial, conoce las necesidades del usuario, pero lo implementa el DBA. Es un profesional en procesamientos de datos. Su tarea es crear la base de datos en sí y poner en vigor los controles técnicos necesarios para apoyar las políticas dictadas por el administrador de datos. Se encarga también, de garantizar el funcionamiento adecuado del sistema y de proporcionar otros servicios de índole técnica relacionados.

Ordenes al sistema, GERENTE) sigue la política DA DBA (mantiene el contacto con todos los usuarios, TÉCNICO)

Datos Persistentes

¿QUÉ ES UNA BD?

DATOS PERSISTENTES

Conviene llamar persistente a los datos de una BD. Esto tiene por objetivo sugerir que la información de una BD difiere de otros tipos de datos cuya naturaleza sea hasta cierto punto transitoria.

·Datos de entrada: se refiere a la información que entra al sistema por primera vez. Esta información podría dar pie a una modificación de los datos persistentes (podría convertirse en parte de éstos últimos), pero en principio no forma parte de la BD propiamente dicha.

·Datos de salida: se refiere a mensajes y resultados que emanan del sistema. Ésta información podría derivarse de los datos persistentes, pero no se le considera en sí como parte de la BD.

La distinción de persistente y transitorios no es rígida y nítida, sino que depende del contexto. Si suponemos que tal distinción tiene al menos cierto sentido intuitivo, es posible presentar una definición un tanto mas precisa del termino Base de Datos.

Definición de BD: Una BD está constituida por cierto conjunto de datos persistentes utilizados por los sistemas de aplicaciones de una empresa (cualquier organización) determinada.

El termino “empresa” podría ser una sola persona (con una pequeña BD privada) o una corporación o entidad similar de gran tamaño (como una enorme BD compartida).

Las empresas actuales a menudo mantienen 2 BD distintas, una con datos de operación y otra con datos de apoyo a decisiones. La base de datos de apoyo a las decisiones muchas veces contiene información resumida (totales, promedios), la cual se extrae en forma periódica de la BD operacional.

4.4.05

Estandar SQL ANSI/ ISO

La historia de SQL (que se pronuncia deletreando en inglés las letras que lo componen, es decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en 1974 con la definición, por parte de Donald Chamberlin y de otras personas que trabajaban en los laboratorios de investigación de IBM, de un lenguaje para la especificación de las características de las bases de datos que adoptaban el modelo relacional. Este lenguaje se llamaba SEQUEL (Structured English Query Language) y se implementó en un prototipo llamado SEQUEL-XRM entre 1974 y 1975. Las experimentaciones con ese prototipo condujeron, entre 1976 y 1977, a una revisión del lenguaje (SEQUEL/2), que a partir de ese momento cambió de nombre por motivos legales, convirtiéndose en SQL. El prototipo (System R), basado en este lenguaje, se adoptó y utilizó internamente en IBM y lo adoptaron algunos de sus clientes elegidos. Gracias al éxito de este sistema, que no estaba todavía comercializado, también otras compañías empezaron a desarrollar sus productos relacionales basados en SQL. A partir de 1981, IBM comenzó a entregar sus productos relacionales y en 1983 empezó a vender DB2. En el curso de los años ochenta, numerosas compañías (por ejemplo Oracle y Sybase, sólo por citar algunos) comercializaron productos basados en SQL, que se convierte en el estándar industrial de hecho por lo que respecta a las bases de datos relacionales.
En 1986, el
ANSI adoptó SQL (sustancialmente adoptó el dialecto SQL de IBM) como estándar para los lenguajes relacionales y en 1987 se transfomó en estándar ISO. Esta versión del estándar va con el nombre de SQL/86. En los años siguientes, éste ha sufrido diversas revisiones que han conducido primero a la versión SQL/89 y, posteriormente, a la actual SQL/92.

El hecho de tener un estándar definido por un lenguaje para bases de datos relacionales abre potencialmente el camino a la intercomunicabilidad entre todos los productos que se basan en él. Desde el punto de vista práctico, por desgracia las cosas fueron de otro modo. Efectivamente, en general cada productor adopta e implementa en la propia base de datos sólo el corazón del lenguaje SQL (el así llamado Entry level o al máximo el Intermediate level), extendiéndolo de manera individual según la propia visión que cada cual tenga del mundo de las bases de datos.

Actualmente, está en marcha un proceso de revisión del lenguaje por parte de los comités ANSI e ISO, que debería terminar en la definición de lo que en este momento se conoce como
SQL3. Las características principales de esta nueva encarnación de SQL deberían ser su transformación en un lenguaje stand-alone (mientras ahora se usa como lenguaje hospedado en otros lenguajes) y la introducción de nuevos tipos de datos más complejos que permitan, por ejemplo, el tratamiento de datos multimediales.

Fernando A. Mas