DBMS - Sistemas Distribuidos

Construcción de un sistema de auditoria con "disparadores"

2005-07-16T21:23:00.000-03:00

Este articulo detalla la utilización de diparadores en SQL Server 2000 para la gestión de Auditorias en sistemas de información. Se explican las dos formas de realizar la auditoria mediante las aplicaciones y sobre las tablas de la base de datos.

INDEPENDENCIA DE LOS DATOS

2005-07-04T23:03:00.000-03:00

Las aplicaciones actuales con frecuencia dependen de los datos. Dicho de otro modo, los requerimientos de la aplicación en cuestión determinan la forma de organizar los datos en almacenamiento secundario y la técnica para acceder a ellos.Se dice que una aplicación es dependiente de los datos porque es imposible alterar la estructura de almacenamiento (la organización física de los datos) o la técnica de acceso sin afectar a la aplicación.

En un sistema de BD no es recomendable tener aplicaciones dependientes de los datos, al menos por 2 razones:

1. Cada aplicación requiere una vista diferente de los mismos datos (ejemplo, 2 archivos que trabajen con un saldo en decimal y el otro en binario, el DBMS debe estar preparado y ser capaz de realizar las conversiones). Son las diferencias que pueden existir entre la forma como ve los datos una aplicación dada y la forma como se almacenan físicamente.

2. El DBA debe tener libertad para modificar la estructura de almacenamiento o la técnica de accesos (o las 2 cosas) para adaptarlas a cambios en los requerimientos, sin tener que modificar las aplicaciones ya existentes. Si las aplicaciones dependen de los datos, tales cambios requerirán con toda seguridad modificaciones correspondientes en los programas, lo cual ocuparía un tiempo que los programadores podrían dedicar a la creación de nuevas aplicaciones.

Esta independencia puede definirse como la inmunidad de las aplicaciones ante los cambios en la estructura de almacenamiento y en la técnica de acceso.
Definiremos 3 términos:

· Un campo almacenado es la unidad más pequeña de información almacenada que recibe un nombre. La base de datos incluirá, en la mayor parte de los casos, muchas ocurrencias (o casos) de cada uno de los diversos tipos de campo almacenado.

· Un registro almacenado es un conjunto de campos almacenados relacionados entre sí, que cuenta con su propio nombre. Una vez más se hace la distinción entre “tipo ” y “ocurrencia”. Una ocurrencia de un registro almacenado está formada por un grupo de ocurrencias de campos almacenados entre sí (una ocurrencia para cada tipo distinto de parte).

· Un archivo almacenado es el conjunto (con nombre) de todas las ocurrencias de un tipo de registro almacenado.

En los sistemas sin BD cadi siempre un registro lógico de una aplicación es idéntico a un registro almacenado correspondiente. Esto no tiene por que ser así en un sistema de BD, pues el DBA podría requerir la capacidad de modificar la estructura de almacenamiento sin que cambien las estructuras lógicas correspondientes.

Web Data Administrator

2005-07-01T21:23:00.000-03:00

Web Data Administrator es una aplicación web elaborada por Microsoft enteramente en el Net Framework que permite gestionar y manejar un servidor SQL gracias a un entorno Web.

Correspondencias Niveles

2005-06-21T18:18:00.000-03:00

CORRESPONDENCIAS

Hay 2 niveles de correspondencias, uno entre los niveles externo y conceptual del sistema, y otro entre los niveles conceptual e interno.

1. La correspondencia conceptual / interna es la que existe entre la vista conceptual y la BD almacenada; especifica cómo se representan los registros y campos conceptuales en el nivel interno. Si se modifica la estructura de la BD almacenada deberá modificarse para que no varíe (DBA). Los efectos de las alteraciones deberán aislarse por debajo del nivel conceptual, a fin de conservar la independencia de los datos.

2. La correspondencia externo / conceptual es la que existe entre una determinada vista externa y la vista conceptual. Las diferencias que pueden existir entre éstos 2 niveles son similares a las que pueden existir entre la vista conceptual y la BD almacenada. Puede existir cualquier cantidad de vistas externas; cualquier numero de usuarios puede compartir una determinada vista externa; puede haber traslapos entre vistas externas distintas.

Algunos sistemas permiten expresar la definición de una vista externa en términos de otras a través de una correspondencia externa / externa en vez de requerir siempre una definición explicita de la correspondencia respecto al nivel conceptual, cosa que resulta útil si existe una relación intima entre varias visitas externas. Los sistemas relacionales en particular casi siempre permiten hacer esto.

Administrador de Base de Datos (DBA)

2005-06-21T18:14:00.000-03:00

EL ADMINISTRADOR DE BD (DBA)

Persona que toma las decisiones estratégicas y de política con respecto a la información de la empresa, y el DBA es quién proporciona el apoyo técnico necesario para poner en práctica esas decisiones. Por tanto el DBA esta encargado del control general del sistema en el nivel técnico.

Funciones del DBA

Definir el esquema conceptual	Debe decidir cuál es la información que debe mantenerse en la BD, es decir, identificar las entidades que interesan a la empresa y la información qué debe registrarse acerca de esas entidades. Este proceso se denomina diseño lógico de BD. El DBMS utilizará la versión objeto (compilada) de ese esquema para responder a las solicitudes de acceso. La versión fuente (sin compilar) servirá como documento de referencia para los usuarios del sistema.
Definir el esquema interno	Debe decidir cómo se representará la información en la BD almacenada. A éste proceso se lo denomina diseño físico de la BD. El DBA se vale del DDL interno para crear la definición de estructura de almacenamiento y la correspondencia pertinente entre los esquemas interno y conceptual (tanto en la versión fuente como objeto).
Vincularse con los usuarios	El DBA debe encargarse de la comunicación con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir los esquemas necesarios. Las consultas sobre diseño de aplicaciones, la impartición técnica, la ayuda en la localización y resolución de problemas, y otros servicios profesionales similares relacionados con el sistema.
Definir las verificaciones de seguridad e integridad	Las verificaciones de seguridad e integridad pueden considerarse parte del esquema conceptual.
Definir procedimientos de respaldo y recuperación	Cuando una empresa se decide a utilizar un sistema de BD, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de la BD resulta esencial poder reparar los datos implicados con un mínimo de retraso y afectando lo menos posible al resto del sistema. El DBA debe definir y poner en práctica un plan de recuperación adecuado que incluya, por ejemplo, una descarga o “vaciado” periódico de la BD en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la BD a partir del vaciado más reciente cuando sea necesario.
Supervisar el desempeño y responder a cambios en los requerimientos	Es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeño que sea mejor para la empresa, y realizar los ajustes apropiados cuando cambien los requerimientos.

Arquitectura ANSI/SPARC

2005-06-21T18:08:00.000-03:00

LOS 3 NIVELES DE LA ARQUITECTURA

La arquitectura ANSI / SPARC se divide en 3 niveles denominados:

1. EL NIVEL INTERNO es el más cercano al almacenamiento físico. Es el que se ocupa de la forma como se almacenan físicamente los datos. (DBA)

2. EL NIVEL EXTERNO es el más cercano a los usuarios, es decir, es el que se ocupa de la forma como los usuarios individuales perciben los datos. REPRESENTACIONES, PUEDE HACER TANTAS VISIONES COMO USUARIOS PUEDA TENER UNA BD. (N. VISIÓN)

3. EL NIVEL CONCEPTUAL es un nivel de mediación entre los otros dos. (TRABAJA DEFINIENDO ESTRUCTURAS DE ALMACENAMIENTO EL DBA).

Existirán muchas “vistas externas” distintas, cada una formada por una representación más o menos abstracta de alguna parte de la BD total. Existirá sólo una “vista conceptual” formada por una representación igualmente abstracta de la BD en su totalidad.

Existirá una sola “vista interna” la cual representará a toda la BD tal como está almacenada físicamente.

EL NIVEL conceptual con toda certeza será relacional, los objetos visibles serán tablas relacionales (los operadores serán también relacionales).

EL NIVEL externo casi siempre será relacional.

EL NIVEL interno no será “relacional” porque los objetos en ese nivel no serán por lo regular sólo tablas relacionales (almacenadas), sino que serán objetos similares a los encontrados en el nivel interno de otros tipos de sistemas.

Compración PostgreSQL y Mysql

2005-05-06T20:38:00.000-03:00

Compración entre las últimas versiones estables de PostgreSQL y Mysql
http://monstera.man.poznan.pl/wiki/index.php/Mysql_vs_postgres

Procesamiento de Transacciones en Sistemas Distribuidos

2005-04-17T22:23:00.000-03:00

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

Ventajas del enfoque de BD

2005-04-14T19:05:00.000-03:00

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

2005-04-14T18:57:00.000-03:00

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?

2005-04-14T18:52:00.000-03:00

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

2005-04-14T18:43:00.000-03:00

· 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.

¿QUÉ ES UN SISTEMA DE BD?

2005-04-12T21:03:00.000-03:00

¿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

2005-04-12T20:52:00.000-03:00

¿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.

Estandar SQL ANSI/ ISO

2005-04-04T23:43:00.000-03:00

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

Próximos Temas a Tratar

2005-03-31T14:23:00.000-03:00

Ventajas de las Bases de Datos:

Es posible reducir la redundancia.
Es posible evitar la inconsistencia hasta cierto punto.
Es posible compartir Datos.
Es posible hacer cumplir las normas.
Es posible aplicar restricciones de seguridad.
Es posible mantener la integridad.
Es posible equilibrar requerimientos opuestos.

Administrador de Bases de Datos:

Definir el esquema conceptual.
Definir el esquema interno.
Vincularse con los usuarios.
Definir verificaciones de seguridad e integridad.
Definir procedimientos de respaldo y recuperación.
Supervisar el desempeño.

Funciones del DBMS:

Definición de Datos.
Manipulación de Datos.
Una solicitud planeada.
Solicitud no planeada.
Seguridad e Integridad de Datos.
Recuperación y Concurrencia de los Datos.
Diccionario de Datos.
Desempeño.

Problema de los Sistemas Distribuidos:

Procesamiento de consultas.
Administración de Catalogo.
Propagación de Actualizaciones.
Control de Recuperación.
Control de concurrencia.

Algebra Relacional

2005-03-30T21:37:00.000-03:00

Panorama General del Álgebra Relacional:

Consiste en un conjunto de operadores de alto nivel que operan sobre relaciones. Cada uno de estos operadores tomo una o dos relaciones como entrada y produce una nueva relación de salida.

Codd definió un conjunto muy específico de ocho operadores de este tipo, en dos grupo:

Operaciones Tradicionales:

# Unión: construye una relación formada por todas las tuplas que aparecen en cualquiera de las dos relaciones.

# Intersección: Construye una relación formada por aquellas tuplas que aparezcan en las dos relaciones.

# Diferencia: Construye una relación formada por las tuplas que aparecen en la primera relación que no aparezcan en la segunda de las dos relaciones especificadas.

# Producto Cartesiano: A partir de dos relaciones, construye una relación que contiene todas las combinaciones posibles de tuplas.

Operaciones relacionales especiales:

# Restricción: extrae las tuplas especificadas de una relación dada. Extrae aquellas tuplas que satisfacen la condición.

# Proyección: Extrae los atributos especificados de una relación dada.

# Reunión: A partir de dos relaciones, construye una relación que contiene todas las posibles combinaciones de tuplas , una de cada una de las dos relaciones.

# División: Toma dos relaciones, una binaria y otra unaria, y construye una relación formada por todos los valores de un atributo de la relación binaria que concuerdan con todos los valores de la relación unaria.