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

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

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

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

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)

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

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

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

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

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.