Ahora es el SGBD el que se encarga de la detección y gestión de las situaciones críticas

Los SGBD activos se están convirtiendo en una de las tecnologías de BBDD más utilizadas en determinados entornos donde es necesario traspasar, desde la aplicaciones al SGBD, la responsabilidad de la gestión de la información recibida.

Desde su punto de vista, ¿cuáles han sido los mayores avances experimentados en el campo de las bases de datos en la última década? - Es difícil determinar un área en concreto, ya que la respuesta depende del ámbito de trabajo. Sin embargo, resaltaría la difusión e implantación generalizada del modelo relacional que prácticamente ha desplazado a los modelos precedentes. En este contexto, los adelantos logrados en el área de la optimización y de los lenguajes de interrogación han permitido hacer accesibles las bases de datos a un público mucho más amplio, poco avezado en la informática.

Dada su experiencia en el campo de las bases de datos, querríamos centrar esta entrevista en dicho campo. Para comenzar, ¿podría definir el concepto de SGBD activo? - Un SGBD activo es aquel que puede reaccionar ante determinadas situaciones previamente descritas por el usuario. Estos sistemas han sido propuestos para satisfacer las necesidades de aquellas aplicaciones que requieren una respuesta puntual a situaciones críticas. Como ejemplos se pueden citar la gestión de redes, control de tráfico aéreo, aplicaciones de seguimiento, etc. Este enfoque puede también ser utilizado para soportar varias de las funciones del propio SGBD a saber, control de acceso, mantenimiento de la integridad, soporte para vistas, etc. El factor común a todas estas aplicaciones es la necesidad de responder de manera oportuna a sucesos tanto externos como internos al propio SGBD. Este suceso puede ser, por ejemplo, el acceso al atributo salario, que desencadenaría un proceso de verificación de la autorización del usuario. Como segundo ejemplo, considérese el control de inundaciones. Aquí no hay un suceso específico que determine el paso a una situación de alerta. Es la posible acumulación de una serie de datos junto con otra información histórica o geográfica, la que señalaría la proximidad de una situación crítica. El aspecto destacado es que ahora es el SGBD y no las aplicaciones del usuario, el que permite la definición y se encarga de la detección y gestión de las situaciones críticas y de la reacción correspondiente. En este sentido, los SGBD activos se pueden situar dentro de la tendencia de traspasar al SGBD muchas de las labores que venían realizando las aplicaciones del usuario. Muestra de esta corriente son los sistemas que soportan modelos semánticos de datos, donde abstracciones tales como la generalización o la agregación son ofrecidas como parte del lenguaje de definición de datos, o los SGBD orientados a objetos donde se describen conjuntamente las características estructurales y del comportamiento del dominio.

¿Cuáles son sus ventajas? - En primer lugar, las ventajas que se derivan de traspasar cualquier funcionalidad de las aplicaciones al SGBD. En este caso la funcionalidad es la descripción y gestión del comportamiento activo que se encuentra repartido, distribuido y embebido entre distintos programas de aplicación. Con los SGBD activos esta gestión queda centralizada, garantizando así una mayor coherencia y liberando a las aplicaciones de su mantenimiento. Además, para aquellos casos donde el suceso sea una composición de distintas situaciones detectadas por aplicaciones diferentes, no es posible para una sola aplicación captar la globalidad del suceso y por tanto, reaccionar ante la eventualidad del mismo. Así, en el ejemplo anterior sobre control de inundaciones, distintas aplicaciones aportan distintos datos que tomados conjuntamente pueden señalar una situación de riesgo. Aquí la detección de dicha situación no la puede realizar un sola aplicación. Sólo el propio SGBD como gestor de toda la información, podría hacer un seguimiento global. Otro enfoque utilizado es el de disponer de un software de sondeo (polling) que con cierta frecuencia compruebe el estado de determinados valores en la base de datos. Aquí el problema estriba en determinar la frecuencia del sondeo. Si la frecuencia es baja, se corre el riesgo de no reaccionar con suficiente celeridad. Si la frecuencia es alta el coste del sondeo puede ser muy oneroso. También aquí la solución pasa por traspasar la gestión del comportamiento activo al SGBD que permite responder puntualmente sin un coste excesivo.

¿Qué opinión le merece el soporte de disparadores y/o reglas en los productos relacionales actuales? ¿Qué características les faltan para poder ser verdaderos SGBD activos? - A diferencia de los SGBD relacionales, donde existe un modelo de referencia que define formalmente las propiedades características, para los SGBD activos no existe este modelo. Por tanto no es posible hablar aquí de verdaderos SGBD activos al no existir esta referencia. De manera general se puede decir que un buen sistema activo es aquel con una buena relación entre expresividad y eficiencia en los aspectos relativos a la definición y gestión del comportamiento activo. La expresividad vendría dada por la complejidad de las situaciones a las que se les puede hacer un seguimiento. Cuanto mayor es la complejidad, más laboriosa es la comprobación y mayor el espacio que se requiere para almacenar estados intermedios. En este sentido, los sistemas actuales que soportan disparadores tales como Oracle o Sybase ofrecen una buena relación: las situaciones son simples (en general descritas en términos de una operación o disfunción de operaciones sobre la base de datos) pero donde su manejo conlleva un coste mínimo adicional.

¿Nos podría explicar brevemente el formalismo E-C-A Evento-Condición-Acción? - Las reglas Evento-Condición-Acción son una forma de describir el comportamiento activo. El evento indica cuándo la regla debe ser evaluada; constituye el disparador. La condición describe un estado de los argumentos del disparador o de la base de datos que permite que se ejecute la acción. La acción define las acciones por realizar si la condición se cumple. Por ejemplo en el control de actualización del atributo salario, el evento sería el intento de modificar dicho atributo, la condición podría ser una comprobación sobre si el incremento supera una cierta cantidad o una verificación de que la persona a la que se la aplica el incremento, lleva al menos dos años en la empresa y tiene tres proyectos grandes a su cargo. Por último, la acción podría ser bien rechazar la actualización, propagar el cambio, notificar al jefe, etc.

¿Qué nos puede decir sobre la resolución de conflictos en la activación de reglas? - La resolución de conflictos corresponde al modelo de ejecución es decir, a cómo se gestiona el comportamiento activo. Una vez que se ha detectado una situación de interés, pueden ser varias las reglas capaces de responder a dicha situación. La resolución de conflictos dicta el orden en el que estas reglas deben de ser disparadas.

Dicho orden puede estar basado en la propia regla (por ejemplo su prioridad o la complejidad de su condición) o en factores externos (por ejemplo, la carga actual del sistema o los valores que verifican la condición). La mayor parte de los sistemas resuelven los conflictos basándose únicamente en la prioridad que, en general, es establecida por el diseñador al crear la regla.

¿Cuáles son los principales prototipos o productos que pueden ser catalogados como SGBD activos? - Con la salvedad hecha anteriormente, destacaría entre los prototipos mas prometedores a Starburst, SGBD relacional que soporta disparadores desarrollado por IBM en Almaden; Sentinel, SGBD orientado a objetos con disparadores desarrollado en la Universidad de Florida, y ODE, también dentro de la orientación a objetos y propuesto por AT&T. Sin embargo, dado el interés suscitado por este tem