Modificación de reglas de negocio creadas automáticamente en bases de datos relacionales

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación Departamento de Ciencia de la Computación. Tesis en opción del grado de Máster en Ciencia de la Computación. “Modificación de reglas de negocio creadas automáticamente en bases de datos relacionales”. AUTOR: Lic. Lisandra Díaz De la Paz. TUTORES: M.Sc. Martha Beatriz Boggiano Castillo. M.Sc. Alain Pérez Alonso. CONSULTANTE: Dr. Ramiro Pérez Vázquez.. Santa Clara Diciembre del 2011.

(2) Pensamiento. “El secreto del éxito es dedicarse entero a un fin” José Martí.

(3) Dedicatoria. A mis padres Tana y Omar..

(4) Agradecimientos Debo agradecer:  A mi tutora MSc. Martha Beatriz Boggiano Castillo, por tanta ayuda, impulso, apoyo e ideas. Por sus valiosas revisiones y sus sugerencias. . A mi tutor y amigo MSc. Alain Pérez Alonso, por guiarme, soportarme, darme tanto apoyo y ayuda incondicional..  . Al Dr. Ramiro Pérez Vázquez, por sus valiosas revisiones y sus sugerencias. A la Dra. Luisa González González por sus invaluables sugerencias.. . A la Dra. Zoila Zenaida García Valdivia, gracias por su dedicación y sugerencias.. . Al Lic. Daynel Perdomo por su ayuda incondicional en todas las traducciones que he necesitado.. . A mis padres Tana y Omar por brindarme todo su apoyo y amor.. . A mi amor Dayron por ayudarme, darme apoyo y confianza en todo..  . A mi familia que me ha dado ánimo y confianza, en especial a mis abuelitos, mis hermanos y sobrinas, gracias por confiar en mí. A mis suegros Nancy y Carlos por su apoyo y cariño.. . A mis amigos por estar siempre conmigo en los momentos difíciles.. . A todos mis compañeros de trabajo que día a día comparto con ellos, en especial los miembros del grupo de BD.. . A todos los profesores que a lo largo de estos años han influido en mi formación y madurez profesional. A los que me han ayudado de una forma u otra, gracias.. . Lisandra..

(5) Resumen. RESUMEN El desarrollo de sistemas de información (SI) está necesariamente vinculado a las reglas de negocio (RN). Estas definen el correcto funcionamiento de una organización y constituyen las bases para la toma de decisiones. Generalmente se encuentran descritas en manuales de políticas, que los directivos del negocio deben conocer para desarrollar su gestión cotidiana y los desarrolladores de SI para implementarlas y chequearlas de manera automática. Las RN con el transcurso del tiempo suelen cambiar debido al dinamismo empresarial. Esto provoca el surgimiento de nuevas restricciones que deben ser reflejados en los SI correspondientes. La presente investigación aborda el control de cambios y versiones de las RN tipo restricción en bases de datos (BD) relacionales. Para ello es necesario analizar las operaciones de inserción, eliminación y actualización de las políticas del negocio, considerando su impacto en la BD y las posibles contradicciones entre los datos y las versiones de las reglas. Como resultado, se proponen variantes que soportan el mantenimiento de las RN y se selecciona la más adecuada para reflejar las asociaciones dato-regla según el análisis realizado. Para su implementación se utilizan recursos de BD siguiendo el estándar SQL. Además se expone una secuencia de pasos para modificar una RN tipo restricción..

(6) Abstract. ABSTRACT The information systems (IS) development is closely related to business rules (BR). These rules define the right working of an organization and are the bases for decision making. Such rules are generally described on policy manuals, which should be known by the head of the business in order to run their everyday business adequately. These rules should be also known by developers of the IS upon the score of implementing and checking them automatically. BR are likely to change with the passing of time due to company dynamic. This may cause the rising of new restrictions which must be reflected in the corresponding IS. This investigation deals with the change and version control of the BR type restrictions on relational databases (DB). To accomplish this it is necessary to analyze insertion, elimination and updating operations in BR, always taking into account its impact on the DB and its possible contradictions between data and rule versions. As a result, variants supporting the keeping of BR are proposed and the best of all is selected to reflect data-rule associations according to one previously done analysis. For implementing the best variant database resources are used according to SQL Standards. In addition, a sequence of steps to modify a restriction type rule is presented..

(7) Tabla de Contenidos. TABLA DE CONTENIDOS INTRODUCCIÓN ............................................................................................................................................. 1 CAPÍTULO I: CONSIDERACIONES GENERALES SOBRE REGLAS DE NEGOCIO ................. 6 1.1 Sistemas de información basados en reglas de negocio ..................................................................... 6 1.1.1 Definiciones de reglas de negocio ................................................................................................ 6 1.1.2 Enfoque de reglas de negocio ...................................................................................................... 8 1.1.3 Reglas en sistemas de gestión de base de datos: reglas deductivas y activas ............................. 9 1.1.4 Reglas de negocio involucradas en operaciones sobre la base de datos................................... 10 1.1.5 Reglas de negocio tipo restricción: patrones ............................................................................. 10 1.2 Formas de expresión de las reglas de negocio.................................................................................. 11 1.2.1 Lenguaje de patrones técnicos................................................................................................... 12 1.2.1.1 Notación punto, principales características ........................................................................ 13 1.2.2 Formas modernas de implementación de reglas de negocio .................................................... 14 1.2.3 Recursos de gestores de datos para implementar reglas de negocio ....................................... 15 1.2.4 Modos de implementación de reglas de negocio tipo restricción ............................................. 17 1.3 Influencia de las modificaciones de las reglas en los sistemas de información ................................ 18 1.3.1 Gestión de reglas de negocio ..................................................................................................... 19 1.3.2 Control de cambios y versiones de reglas de negocio ............................................................... 20 1.3.3 Versiones e historial de reglas de negocio ................................................................................. 21 1.4 Conclusiones parciales ...................................................................................................................... 23 CAPÍTULO II: CONTROL DE VERSIONES EN EL REPOSITORIO DE REGLAS Y EN LA BASE DE DATOS DEL NEGOCIO........................................................................................................ 28 2.1 Administración y mantenimiento de reglas de negocio ................................................................... 28 2.1.1 Arquitectura de administración de reglas de negocio en bases de datos relacionales ............. 30 2.1.2 Versiones de las reglas de negocio............................................................................................ 32.

(8) Tabla de Contenidos. 2.1.2.1 Características del nodo raíz ............................................................................................... 36 2.2 Operaciones a realizar con las reglas de negocio en el repositorio .................................................. 36 2.2.1 Insertar una regla de negocio..................................................................................................... 36 2.2.2 Eliminar una regla de negocio .................................................................................................... 40 2.2.3 Actualizar una regla de negocio ................................................................................................. 42 2.3 Patrón de restricción detallado ......................................................................................................... 42 2.3.1 Análisis sobre la modificación de reglas de negocio .................................................................. 43 2.4 Ventajas de guardar el historial de reglas en el repositorio ............................................................ 46 2.4.1 Recuperar una versión o volver a una versión anterior ............................................................. 47 2.5 Conclusiones Parciales ...................................................................................................................... 47 CAPÍTULO III: IMPACTO DEL MANTENIMIENTO DE REGLAS DE NEGOCIO EN LOS DATOS ....................................................................................................................................................... 48 3.1 Variantes que soportan el mantenimiento de reglas de negocio ..................................................... 48 3.1.1 Asociación datos-tiempo ............................................................................................................ 48 3.1.2 Asociación datos-reglas mediante: Una bitácora....................................................................... 49 3.1.3 Asociación datos-reglas mediante: Tablas de relación tupla-regla............................................ 52 3.1.4 Ventajas y desventajas de cada una de las variantes expuestas ............................................... 54 3.1.5 Variante seleccionada ................................................................................................................ 56 3.1.6 Creación de las tablas para el control versiones de regla a partir de la variante seleccionada. 57 3.2 Relación de los datos con las reglas de negocio ............................................................................... 58 3.2.1 Repercusión de insertar una regla de negocio en los datos ...................................................... 58 3.2.1.1 Eliminarlos todos ................................................................................................................. 59 3.2.1.2 Conservarlos en la base de datos ........................................................................................ 59 3.2.1.3 Seleccionar los que desea eliminar y los demás conservarlos en la base de datos ............ 60 3.2.1.4 Reflejar en las tablas de relación tupla-regla la inserción de una regla.............................. 60 3.2.2 Repercusión de eliminar una regla de negocio en los datos...................................................... 61 3.2.2.1 Eliminar la regla de la base de datos y conservarla en el repositorio ................................. 62.

(9) Tabla de Contenidos. 3.2.2.2 Eliminar la regla de la base de datos y del repositorio ....................................................... 63 3.2.3 Repercusión de actualizar una regla de negocio en los datos ................................................... 64 3.2.3.1 Eliminarlos todos ................................................................................................................. 66 3.2.3.2 Conservarlos en la base de datos ........................................................................................ 66 3.2.3.3 Seleccionar cuáles datos eliminar y el resto conservarlos en la base de datos .................. 67 3.3 Recursos de implementación que soportan el mantenimiento de las reglas de negocio ................ 67 3.3.1 Características y estructura de los recursos que implementan la inserción y modificación de reglas ................................................................................................................................................... 69 3.3.2 Modificaciones del lenguaje formal para el control de versiones de reglas .............................. 70 3.4 Secuencia de pasos para modificar una regla tipo restricción .......................................................... 74 3.5 Conclusiones Parciales ...................................................................................................................... 74 CONCLUSIONES ........................................................................................................................................... 77 RECOMENDACIONES ................................................................................................................................... 78 REFERENCIAS BIBLIOGRÁFICAS ................................................................................................................... 79 ANEXOS ....................................................................................................................................................... 81.

(10) Introducción. INTRODUCCIÓN En la actualidad las organizaciones funcionan siguiendo múltiples políticas, protocolos de trabajo que se representan como RN, que están embebidas en procesos, aplicaciones informáticas, documentos (Reyes, 2002). En los últimos años se manifiesta una tendencia a gestionar de forma sistemática y centralizada las RN, de modo que sea fácil y sencillo consultarlas, entenderlas, utilizarlas y cambiarlas. Debido al dinamismo que existe en el sector empresarial y en general en todas las entidades socio-económicas, estas políticas de negocio con el tiempo pueden cambiar. Surgiendo así nuevos requerimientos que deben ser implantados. Se pretende que el sistema que las trata sea capaz de manejar estos cambios de manera automática, o sea debe permitir el mantenimiento de las RN (Díaz De la Paz et al., 2011). Con la automatización de las RN no sólo se puede mejorar la toma de decisiones, sino que también brinda a las organizaciones mayor agilidad en la creación y cambios de la lógica del negocio, la cual se encuentra en constante evolución (Cientec, 2011). Se evitan fallas y, de este modo, se logran importantes reducciones de tiempo y costo con respecto a gestionar las RN manualmente. Las RN reflejan la forma en que las empresas hacen los negocios. Al mismo tiempo actúan como un componente clave en el ciclo de vida de un SI. Si las reglas cambian el SI debe transformarse de alguna manera a través de una mayor independencia entre la inserción de las implementaciones de las reglas y los programadores de los SI. De modo que un cambio en las reglas no implica contratar servicios de mantenimiento de los sistemas (Boggiano Castillo et al., 2007). En el laboratorio de BD del Centro de Estudios Informáticos (CEI) de la UCLV se trabaja en un proyecto para la generación automática de RN y sus modificaciones a partir de las reglas editadas en lenguaje técnico.. 1.

(11) Introducción. De los primeros trabajos obtenidos como resultado de esta investigación están el trabajo “Aplicación de Reglas de Negocio” (Pérez Alonso, 2008), y “Solución al problema de la cardinalidad en la generación automática de reglas de negocio” (Pereira Toledo, 2009) con los cuales se logra una herramienta computacional, para reglas de restricciones. Con el segundo de estos trabajos se logra una independencia de la BD al recopilar la información necesaria para generar las reglas del negocio desde el catálogo del gestor MS SQL Server a través de procedimientos almacenados. Además se crea un algoritmo para lograr el tratamiento de las reglas de restricción cuando involucran varias tablas con relaciones 1: M. Con el trabajo de diploma “Modificación de las reglas de negocio tipo restricción y su implementación” (Marrero Lorenzo, 2009) se analizan las consecuencias de modificar RN tipo restricción en los datos de una BD relacional. En esta investigación se exponen algunas opciones sobre qué hacer con los datos que violan una regla modificada, pero no se analiza en profundidad que sucede con las reglas, ni se explican variantes que soporten el mantenimiento de reglas, ni qué cambios hay que hacer en los recursos de implementación para lograrlo. En el año 2010, como parte de la tesis de maestría “Reglas de Negocio en Bases de Datos Relacionales”(Pérez Alonso, 2010), se definen cuatro patrones de reglas para captar los requerimientos del negocio. Se crea un lenguaje técnico para expresar las reglas de estos patrones. Se implementaron mediante recursos estándares de bases de datos las reglas de los patrones expresadas en su lenguaje técnico y se creó un método de manejo para las reglas implementadas. En el trabajo de diploma “Traductor LPT-SQL para reglas de negocio en bases de datos relacionales” (Calderón Solís, 2011), se describe la sintáctica y semántica del lenguaje LPT para especificar los patrones en lenguaje técnico sobre bases de datos relacionales, se mejora la estructura del repositorio obtenida de trabajos anteriores y se obtiene una versión del traductor que permite convertir los patrones de reglas escritos en un lenguaje técnico, en recursos de bases de datos relacionales, utilizando las ventajas del diseño orientado a objetos, y el lenguaje Java. Las RN deben ser fáciles de acceder, ver, modificar y gestionar por los desarrolladores y usuarios del negocio. De la misma forma que es necesario crearlas, resulta imprescindible 2.

(12) Introducción. contar con una herramienta que permita modificarlas. De esta manera se logra tener sistemas robustos y flexibles al cambio (Díaz De la Paz et al., 2011). Las RN pueden cambiar lo que lleva consigo que haya que actualizarlas en el repositorio de reglas. La inserción automática de RN en forma de recursos de BD relacionales queda incompleta y prácticamente inútil si no se tienen en cuenta las operaciones de modificación y eliminación de las reglas en el repositorio así como la repercusión de estas operaciones sobre los datos. Razones por las que se proponen los siguientes como objetivos de esta investigación. Objetivo general Determinar mecanismos para el control de versiones de las RN tipo restricción, así como los datos relacionados con las mismas; haciendo uso de los recursos de bases de datos relacionales, con vistas a soportar la dinámica de las políticas del negocio. Objetivos específicos 1. Definir modificaciones factibles de las RN tipo restricción a partir de los componentes del patrón. 2. Establecer una estructura para organizar las versiones de reglas que permita obtener un historial de las mismas y las transformaciones en el repositorio. 3. Analizar la repercusión que tienen las operaciones de inserción, eliminación y actualización de reglas en los datos almacenados en la BD. Preguntas de investigación ¿Qué componentes del patrón de restricción pueden ser cambiadas para lograr la modificación de RN? ¿Cómo organizar las reglas y sus versiones para facilitar el análisis de las operaciones sobre estas?. 3.

(13) Introducción. ¿Qué transformaciones deben realizarse en el repositorio de reglas y en la BD que permitan controlar las versiones de reglas? ¿Qué políticas deben ser aplicadas a los datos cuando se modifican las reglas de negocio que los gobiernan? Justificación de la investigación La mayoría de las organizaciones se rigen por reglas de negocio dinámicas. Este hecho genera diversos cuestionamientos sobre cómo reflejar en los SI el control de versiones de las reglas y el efecto que esto tiene sobre los datos. Así, se considera trascendente estudiar la relación dato-regla con el propósito de mantener los datos asociados a las reglas con las cuales fueron insertados. El estudio planteado ayuda entre otros aspectos, a conocer el historial de las reglas de negocio, las consecuencias de realizar las operaciones de inserción, eliminación y actualización de estas RN y sus implicaciones en el repositorio de reglas y la BD. En el departamento de BD se dispone de profesores e investigadores con experiencia en el tema de las RN y los recursos tecnológicos para llevar a cabo la investigación. Hipótesis de investigación Modificar el repositorio de RN y añadir tablas a la base de datos permite el mantenimiento de las RN tipo restricción implementadas automáticamente en base de datos relacionales. El presente trabajo está estructurado en tres capítulos: En el Capítulo I se abordan aspectos generales sobre el enfoque de RN, se exploran los diferentes tipos de reglas, clasificadas por distintos autores que se pueden considerar “cercanas a los datos”. Se analizan aspectos fundamentales sobre la gestión, control de versiones y el mantenimiento de las RN. En el Capítulo II se describe la arquitectura del administrador de RN, para hacer énfasis en el módulo de control de versiones. Se explica en qué consisten las versiones de reglas, se detallan los cambios realizados al repositorio de reglas, se muestran ejemplos de la estructura arbórea de estas versiones, sobre la cual se analizan las operaciones de inserción, eliminación 4.

(14) Introducción. y actualización de una RN. Teniendo en cuenta el patrón de Morgan se define lo que se considera una modificación de RN. En el Capítulo III se proponen variantes que soportan el mantenimiento de RN, de las cuales se selecciona la que se considera más adecuada. Se analiza la repercusión que tiene en los datos las operaciones de inserción, eliminación y actualización de las RN. Se brindan opciones para decidir qué hacer con los datos que violan una versión de regla determinada. Se analizan los cambios a realizar en los recursos de implementación. Se propone una secuencia de pasos para modificar las RN tipo restricción implementadas automáticamente en la BD.. 5.

(15) Capítulo I. CAPÍTULO I: CONSIDERACIONES GENERALES SOBRE REGLAS DE NEGOCIO En la última década, las reglas de negocio se han convertido en uno de los artefactos más populares de la comunidad de los SI. Debido a la necesidad de captar las políticas o requerimientos de los negocios de manera más organizada y menos casual, que como se recuperan tradicionalmente. El “enfoque de reglas de negocio” abre un campo de investigación que permite tratar estas reglas como un conjunto de elementos con cierta independencia y automaticidad (Ross, 2003). De este modo se requiere un mecanismo para su captura, expresión, representación, implementación y mantenimiento. En este capítulo se estudian diferentes definiciones y clasificaciones de reglas. Se selecciona un conjunto de tipos de reglas que se pueden considerar “cercanas a los datos” y se analizan aspectos fundamentales sobre la gestión, control de versiones y el mantenimiento de las reglas de negocio. Además, se expone la importancia de reflejar los cambios que se producen en los protocolos de trabajo de los negocios en las bases de datos.. 1.1 Sistemas de información basados en reglas de negocio Las formas de modelado conocidas hoy son utilizadas ampliamente desde hace años. Tiempo atrás las investigaciones se enfocaban en desarrollar lenguajes de modelado conceptual que contaran con algunos conceptos generales y una representación visual. Estos lenguajes se usan por los expertos para crear modelos, y como artefacto facilitador de la comunicación con los especialistas del negocio. Aquí, la comunicación establece una línea divisoria muy fuerte, demarcada por las RN (Martínez Busto, 2011).. 1.1.1 Definiciones de reglas de negocio En la actualidad se cuenta con diversas definiciones de RN, cada autor explica su significado desde su punto de vista, haciendo énfasis en uno u otro aspecto. De acuerdo con Hay (2000) una “regla de negocio es una sentencia que define o restringe algunos aspectos del negocio. Tiene la finalidad de establecer la estructura del negocio, o controlar o influenciar el comportamiento de negocio”. Más adelante, dice:. 6.

(16) Capítulo I. Para nuestros propósitos, esto puede ser visto desde dos perspectivas… Desde la perspectiva de los sistemas de información, está relacionado con los hechos que son grabados como datos y las restricciones sobre los cambios a los valores de tales hechos. […] lo que preocupa es cuándo los datos debieran o no ser grabados por el sistema de información. En consonancia, una regla de negocio expresa restricciones específicas en cuanto a la creación, actualización y eliminación de los datos persistentes en un sistema de información De acuerdo a Morgan (2002), una RN, básicamente, es una declaración compacta sobre un aspecto del negocio, usando un lenguaje simple, inequívoco, accesible a todas las partes interesadas: el dueño del negocio, el analista, el arquitecto técnico y otros. Este autor enumera características deseables en las declaraciones de reglas. Estas características universales se aplican a cualquier lenguaje o dominio de aplicación.  Atómico: no pueden ser descompuestas sin que se pierda información.  No ambiguo: tienen solamente una obvia interpretación  Compacta: típicamente son frases cortas.  Consistente: juntas, proporcionan una única y coherente descripción.  Compatible: usan las mismas condiciones en el resto del modelo de negocio. Por su parte Ross (2003, 2010) se acoge a lo planteado por otros autores, fundamentalmente Bajec (2000) y Morgan (2002). En cuanto a la definición de RN logra ser muy preciso al plantear: “Una regla de negocio es:  Una sentencia que define o restringe algunos aspectos del negocio.  Establece restricciones a la estructura del negocio, controlando o influyendo en el comportamiento del mismo.  No podrá ser fraccionada o descompuesta en reglas de negocio más detalladas.  En caso de ser reducida perdería información importante sobre el negocio.” 7.

(17) Capítulo I. Si bien cada autor define las RN según su punto de vista, la esencia coincide: son políticas del negocio que restringen o influencian procesos del negocio. A los efectos de esta investigación, se toma la definición ofrecida por (2002, Ross, 2003, Ross, 2010) como bases para el desarrollo de esta tesis.. 1.1.2 Enfoque de reglas de negocio El enfoque de RN (ERN) o (BRA, acrónimo del inglés Business Rule Approach), se presenta como una forma efectiva de identificar el núcleo de los requerimientos del negocio (Gottesdiener, 1997). El ERN es un punto de vista que permite el manejo de las RN independiente de las aplicaciones que las hacen cumplir, el término ha sido utilizado por diferentes autores (Bajec et al., 2000, Date, 2000b, Layzell and Loucopoulos, 1988, Ross and Lam, 1999, Weiden, 2000); Bajec (2000) asegura que dicho enfoque “es la combinación de técnicas y tecnologías, nuevas y otras ya existentes”, desde el que se intenta ´[ …] “identificar el conocimiento necesario para administrar una empresa, documentarlo, razonar sobre el mismo, hacerlo operacional de una manera consistente, adaptarlo sistemáticamente a cualquier vaivén del mercado y tratar, en la medida de lo posible, de automatizarlo”. Según Grahm (2006), hay tres escuelas fundamentales del pensamiento en las reglas de negocio, una de estas se fundamenta en la tradición de bases de datos, la más antigua desde el trabajo con la inteligencia artificial, y la más reciente basada en el modelado de objetos y las reglas de negocio en el contexto de especificaciones UML. A la pregunta de cuál punto de vista es mejor, Grahm (2006) plantea que depende de la naturaleza del problema; de todos modos, el propio autor asegura, se puede tratar de superponer los enfoques. En el estudio de las RN se aprecia cómo con el enfoque centrado en datos de Date (2000b), se defiende la idea de que con las RN se asegura que los hechos representados en bases de datos no pueden ser corruptos por actualizaciones que violen las reglas, ya que cuando se realiza una actualización se realiza la regla y se chequea, si es violada, la actualización es abortada. 8.

(18) Capítulo I. Date (2000b), ofrece en su clasificación de reglas las restricciones, dos tipos de derivación: el cálculo y la inferencia. Este autor insiste en la visión declarativa de las reglas, sin embargo Grahm (2006) explica que no hay razones para que una especificación ejecutable no pueda ser descrita proceduralmente. En este trabajo se tiene en cuenta lo planteado por Grahm (2006). Para este autor es mejor eliminar las distinción entre reglas de inferencia y restricción, de modo que el centro del trabajo sea la diferencia entre lo que plantea la regla. Se hace referencia a restricciones simples sobre atributos, así como restricciones que se refieren a más de un atributo. Por otra parte, mientras Date (2000b) estudia las reglas de computación como descripciones declarativas con especificaciones ejecutables, Grahm (2006) ve las reglas de cálculo como inherentemente procedurales. Ambos autores están de acuerdo que lo más importante de las reglas de negocio es tratar de hacer la vida más fácil al usuario final.. 1.1.3 Reglas en sistemas de gestión de base de datos: reglas deductivas y activas Se puede considerar que algunas RN pueden estar vinculadas directamente a los datos. En (Ceri and Fraternali, 1997) se clasifican las reglas en el sistema de gestión de base de datos (SGBD) en dos familias reglas deductivas y reglas activas: Reglas deductivas: brindan la habilidad para derivar nueva información de la información ya existente o para testar la consistencia de la información almacenada en la BD. Por ello este tipo de regla puede ser usada para: derivar información compleja de datos extensivamente almacenados; indicar en qué medida un objeto está en un estado consistente o muchos objetos relacionados son mutuamente consistentes. Las reglas deductivas que testan la consistencia de BD son llamadas restricciones de integridad. Estas no pueden causar un cambio en el contenido de la BD por tanto son también llamadas reglas pasivas. Reglas activas: brindan un comportamiento reactivo motivado por la ocurrencia de algún evento, generalmente una operación sobre la base de datos, y ejecuta una reacción a este estímulo. Las reglas activas pueden poseer consultas a la base de datos para sacar información sobre eventos y objetos de base de datos. Deciden en qué medida los eventos realmente 9.

(19) Capítulo I. requieren una acción; entonces ellos pueden ejecutar acciones, normalmente cualquier secuencia de operaciones de base de datos y/o activaciones de programas externos. Así contrariamente a las reglas deductivas, las reglas activas pueden tener efectos secundarios y cambiar el contenido de la base de datos. Este tipo de reglas muchas veces es implementado mediante disparadores en sistemas relacionales. Algunos ejemplos de aplicaciones típicas de reglas activas son: alerta de que cierta situación ha ocurrido, el registro de violaciones a las reglas de integridad, el mantenimiento de datos replicados a través de propagación de actualización, entre otras (Ceri and Fraternali, 1997).. 1.1.4 Reglas de negocio involucradas en operaciones sobre la base de datos Date (2000b, 2001), manifiesta sus criterios a favor que las RN y las restricciones de rangos deben ser parte de las BD, ya que estas inicialmente garantizan la integridad de la BD. Sin embargo, defiende las ventajas de mantener las reglas separadas del motor de la BD. O sea las reglas pueden ser aplicadas a los datos almacenados por gestores de bases de datos como DB2, Oracle, SYbase y otros. Lo más importante es que las reglas se mantienen almacenadas en un repositorio central, lo que significa que estas pueden ser mantenidas independientemente de los datos, aplicaciones e infraestructura (Calderón Solís, 2011). Con este principio es que se trabaja en la presente investigación. Según Gottesdiener (1997), las RN centradas en los datos pueden tener contacto más directo con los mismos y resulta conveniente utilizar aquellas que tienen que ver con las funcionalidades CRUD (Create, Read, Update, Delete). Estos mecanismos son comunes a todos los servicios de los gestores de datos. Por simplicidad se puede asumir que los modelos de datos y las estructuras de BD tienen adecuada correspondencia (Morgan, 2002).. 1.1.5 Reglas de negocio tipo restricción: patrones En este trabajo se estudia la clasificación de RN tipo restricción de acuerdo con Morgan (2002). Restricción básica: es el más común entre los patrones para RN, establece una restricción sobre el sujeto de una regla. <determinante> <sujeto> [no] (debe | tiene) <característica> 10.

(20) Capítulo I. [ (si | a menos que ) <hecho>]. Lista de Restricción: este patrón también restringe al sujeto, delimitando la cantidad de hechos verdaderos tomados de una lista. <determinante> <sujeto> [no] (debe | tiene) <característica> (si | a menos que ) como mínimo <m> [no más de <n>] de las siguientes es verdadera: <lista de hechos>. Las reglas de restricción son útiles para satisfacer requisitos del negocio, solo con reglas de este tipo puede hacerse cumplir políticas prohibitorias en el sistema del negocio. Al patrón de restricción de Morgan (2002) se le hacen algunos cambios respetando los convenios definidos por este autor. El patrón toma la siguiente forma: <determinante> <sujeto> (no puede tener <características>) | (puede tener <características> solo si <hechos>). Con este patrón se trabaja en la presente investigación.. 1.2 Formas de expresión de las reglas de negocio De acuerdo con Morgan (2002) las RN pueden expresarse de diversas formas, principalmente, según su especificación en el desarrollo de un SI o incluso de acuerdo a la manera en que se introduzcan a este. Se definen tres niveles de expresión de las RN:  Informal: este nivel proporciona una sentencia en lenguaje natural, sin un rango limitado de parámetros, tal y como el cliente del negocio desee.  Técnico: este nivel combina referencias a datos estructurados, operadores y restricciones con el lenguaje natural, es un nivel intermedio entre la entrada de la regla y su implementación.  Formal: este nivel proporciona sentencias conforme a una sintaxis definida y proporciona la funcionalidad automática de la regla.. 11.

(21) Capítulo I. 1.2.1 Lenguaje de patrones técnicos Las RN expresadas en un nivel técnico deben ser escritas en un lenguaje capaz de asimilar una regla en un lenguaje formal, y sencillo de implementar. Esta idea es planteada por varios autores (Ashwell, 2006, Demuth, 2005, Heidenreich et al., 2005, Zimbrão et al., 2002). OCL (acrónimo del inglés: ObjectConstraintLanguage) es un lenguaje formalizado con el que se pueden expresar reglas de negocio. Es creado por el OMG (acrónimo del inglés: Object Manager Group) (OMG, 2010) y surge para completar las especificaciones de los diagramas UML (acrónimo del inglés: Unified Model Language), en la etapa de diseño conceptual, para expresar todos los aspectos relevantes de una especificación que con el uso exclusivo de UML no es permitido. OCL es un lenguaje para definir restricciones de objetos a nivel conceptual para el diseño de clases con UML. Puede ser usado para diferentes propósitos:  como lenguaje de consulta  para especificar invariantes de tipo para estereotipos,  para describir pre y post condiciones de operaciones y métodos,  para describir alertas,  para especificar conjuntos de destinos para mensajes y acciones  para especificar restricciones sobre operaciones, y  para especificar reglas de derivación para atributos para cualquier expresión sobre un modelo UML. Contando con el OCL parece innecesario definir un lenguaje de nivel técnico para especificar RN en el diseño conceptual. Sin embargo esto no excluye la necesidad de un lenguaje técnico para expresar RN, sobre la BD física. En Calderón Solís (2011) se propone un lenguaje técnico para expresar RN, en función de las tablas, sus atributos y las interrelaciones para bases de datos relacionales basado en los 12.

(22) Capítulo I. patrones de reglas y en el lenguaje LRT definido en (Pérez Alonso, 2010). Se especifica con mayor precisión el lenguaje que se propone, nombrado lenguaje de patrones técnicos (LPT), logrando una versión extendida del mismo. 1.2.1.1 Notación punto, principales características En LPT se usa la notación punto como estilo para establecer el medio de acceso a los atributos de tablas y posibilitar la navegación, lo cual refiere Zimbrão (2002). Esta notación le brinda consistencia al lenguaje. Hay similitud entre la manera de usar la notación punto de LPT y la forma en que se usa en OCL. En esencia, LPT se basa en OCL lo que propone una manera más simple de expresión para restricciones y otras reglas de negocio en función de una base de datos física. Por ejemplo: Acceso simple a un atributo: Tabla 1 [. Atributo] Camino de navegación entre tablas: Tabla 1. Tabla 2. (…) . Tabla N [. Atributo] En ambos casos es necesario destacar la opción de terminar o no con un atributo en la última tabla (para LPT) o clases (para OCL). En (Pérez Alonso, 2008) se analiza el caso que el camino de navegación finalice con un atributo. Pero si concluyera solamente con el nombre de una tabla entonces se está haciendo referencia a las instancias resultantes, específicamente a su(s) atributo(s) identificador(es). En esta notación es admisible emplear como tabla la palabra reservada sujeto, la cual no pertenece realmente a ninguna tabla específica, su utilización referencia a la tabla que se refiere al <sujeto> de la regla. Esta constante de la notación punto es similar al this de los diferentes lenguajes de programación (Horstmann, 2009). En el patrón de restricción visto por la precedente investigación (Pérez Alonso, 2008) existe una variante similar utilizada en sus <hechos>, aunque bastante limitada: @idSujeto. Esta constante (sujeto) es aplicada igualmente a otros patrones de reglas, siempre y cuando contengan al <sujeto>. 13.

(23) Capítulo I. En (Calderón Solís, 2011) se extienden las posibilidades de expresión del camino de navegación de manera que hace posible restringir el resultado a partir del valor de algún atributo perteneciente a cualquier tabla que pertenezca al camino. Un ejemplo de lo anterior es que para expresar “el nombre del Paciente con carnet de identidad. 87032215468”. puede. ser. representado. en. LPT. como:. Paciente. (CI=’87032215468’).nombre. En caso de querer restringir a partir de la llave primaria (si no es compuesta), solo sería necesario escribir la sentencia: Paciente („87032215468‟). Esto no es aplicable si la llave primaria es compuesta. Igualmente es permisible utilizar otro camino de navegación para restringir el valor de un atributo (equivalente a sub-consultas en SQL).. 1.2.2 Formas modernas de implementación de reglas de negocio Las formas modernas de implementación de las RN generalmente siguen el enfoque actual de RN y manipulan estas de una manera explícita. Dentro de este contexto, una RN representa un meta-elemento importante que necesita ser capturado, formalizado e implementado separado de otros elementos que constituyen la arquitectura de aplicación (Bajec et al., 2000). Actualmente, se han desarrollado algunas herramientas que están disponibles, basadas en tecnologías orientadas a reglas. Teniendo en cuenta como estas herramientas representan, implementan y ejecutan las RN, se pueden clasificar en (Bajec et al., 2000):  Herramientas independientes de bases de datos: las RN son implementadas en una BD, usando disparadores y procedimientos almacenados. Sin embargo estos son generadas automáticamente y manejadas por herramientas que no son gestores de bases de datos.  Herramientas basadas en el servidor: las RN son creadas por herramientas de desarrollo que se convierten en una capa intermedia de servicios de aplicación y residen sobre un servicio de aplicación.  Sistemas basados en reglas: En vez de especificar restricciones sobre elementos de datos o tabla, un método orientado a la lógica captura la lógica del negocio a un alto. 14.

(24) Capítulo I. nivel y las reglas asociadas. En tiempo de ejecución, motores especiales son usadas para procesar las reglas y generar respuestas apropiadas. De estas tres formas de implementación de RN, se elige la primera: herramientas independientes de bases de datos pues sigue el enfoque de reglas de negocio centradas en datos argumentado anteriormente. En trabajos anteriores como (Calderón Solís, 2011, Marrero Lorenzo, 2009, Pereira Toledo, 2009, Pérez Alonso, 2008, Pérez Alonso, 2010) la implementación de las reglas se hace mediante recursos de bases de datos y la información referente a las reglas se almacenan en repositorios independientes a la base de datos que puede ser usado por un SI.. 1.2.3 Recursos de gestores de datos para implementar reglas de negocio El lenguaje SQL estándar, en sus múltiples revisiones y particularmente la implementación para SQL Server 2005, ofrece varios recursos de manejo de datos que se analizan en esta sección, ello permite la posterior selección de los más convenientes para la implementación de RN. Vistas: Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al igual que una tabla real, una vista consta de un conjunto de columnas y filas de datos con un nombre. Suelen utilizarse para centrar, simplificar y personalizar la percepción de la BD para cada usuario (Melton and Simon, 2002). Las vistas se pueden utilizar para realizar particiones de datos y para mejorar el rendimiento cuando estos se copian. Además, permiten a los usuarios centrarse en datos de su interés y en tareas específicas de las que son responsables. Los datos innecesarios pueden quedar fuera de la vista; de ese modo, también es mayor su seguridad, dado que los usuarios solo pueden ver los definidos en la vista y no los que hay en la tabla subyacente (MSDN, 2008). Disparadores: Un disparador es una pieza de código ejecutable, que consiste de instrucciones declarativas y procedurales y que se almacenan en el catálogo del SGBD (González, 2010). Son tipos 15.

(25) Capítulo I. especiales de procedimientos almacenados para la ejecución automática al emitirse una instrucción UPDATE, INSERT o DELETE en una tabla o una vista. Constituyen herramientas eficaces que pueden utilizar los sitios para exigir automáticamente las reglas comerciales cuando se modifican los datos. Amplían la lógica de comprobación de integridad, valores predeterminados y reglas del estándar SQL, aunque se deben utilizar las restricciones y los valores predeterminados siempre que estos aporten toda la funcionalidad necesaria (Melton and Simon, 2002). Los desencadenadores pueden consultar las tablas y usar instrucciones SQL complejas. Son muy útiles para exigir reglas o requisitos complejos; también para exigir la integridad referencial, que conserva las relaciones definidas entre tablas (MSDN, 2008). Según se plantea en (Healy, 2000), utilizar desencadenadores en un manejador de BD puede traer como resultado:  Rapidez de desarrollo de las aplicaciones: porque al estar los disparadores almacenados en las BD relacionales, las acciones llevadas a cabo por ellos no tienen que ser codificadas en cada aplicación.  Ejecución global de las RN: ya que un disparador sólo tiene que ser definido una vez, y entonces puede ser usado por cualquier aplicación que modifique la tabla.  Facilidad de mantenimiento: si una política de negocio cambia, sólo el disparador correspondiente necesita cambiar en lugar de cada programa de la aplicación Otros recursos de BD que se analizan en (Calderón Solís, 2011, Pérez Alonso, 2010), y que resultan útiles para el manejo de datos y la implementación de reglas de negocio son los siguientes:  Restricciones check.  Procedimientos Almacenados.  Funciones definidas por el usuario.  Aserciones. 16.

(26) Capítulo I.  Transacciones.. 1.2.4 Modos de implementación de reglas de negocio tipo restricción En (Calderón Solís, 2011), cuando se hace referencia a los modos de implementación de RN sobre BD se está diferenciando la manera en que un SI chequea el cumplimiento de la regla luego de una operación que trata de cambiar el estado de la base de datos provocado por una operación de inserción, modificación o actualización. El modo de implementación inmediato consiste en que inmediatamente después de finalizada una operación, se chequea si se infringe cada regla involucrada. Cuando una regla es violada se lanza un mensaje de error y se deshace la operación. Este método de chequeo inmediato es abordado por Date (2001) y en general pertenece a vías tradicionales de implementación de reglas de negocio (Bajec et al., 2000). Zimbrão (2002), declara utilizar disparadores para implementar este modo. En (Pérez Alonso, 2010) se recomienda usar disparadores y vistas. En algunas ocasiones cuando se buscan violaciones de RN se necesita analizar más allá de una operación en particular y verlas como ilegalidades de un conjunto de operaciones (Date, 2001, Choi et al., 2006 ). El método de chequeo mediato ocurre cuando no se toman acciones inmediatamente después de ser violada la regla, sino que estas reglas son consideradas como “posibles reglas infringidas”. Luego de concluido el conjunto de operaciones se extraen las reglas que realmente han sido violadas de entre las “posibles reglas infringidas” y con esta lista el sistema del negocio puede decidir qué hacer, si deshacer todas las operaciones, analizar las reglas que han sido violadas y de cada una cuáles son los objetos causantes de la infracción. Con esta información se puede hacer un análisis profundo antes de tomar una medida, e incluso en casos extremos buscar más detalles. La decisión a tomar puede ser que el SI le pregunte directamente al cliente ¿qué desea hacer? o realizar acciones automáticas predefinidas (Calderón Solís, 2011). La presente investigación se basa en el mantenimiento de RN tipo restricción en bases de datos relacionales, bajo el modo de implementación inmediato.. 17.

(27) Capítulo I. 1.3 Influencia de las modificaciones de las reglas en los sistemas de información Las RN son una categoría del negocio importante ya que describen cómo están haciendo los negocios las empresas. Su valor en desarrollar aplicaciones que son flexibles y sensibles al cambio también las ha hecho atractivas dentro del dominio de los SI. Los cambios en el entorno empresarial de una organización casi nunca suceden de manera espontánea, sin ningún tipo de la razón, estos suelen ser impulsados tanto desde las decisiones internas de la gestión de la organización o de fuerzas externas, como las leyes y regulaciones del gobierno. Estos cambios casi siempre llevan a la adaptación de los procesos de negocio existentes y con frecuencia requieren reflejarlo en los sistemas nuevos o modificados (Bajec et al., 2005). Generalmente los cambios en los procesos de negocio y en los sistemas de apoyo están en las RN y sus implementaciones, que son revisados y modificados de acuerdo a los nuevos objetivos, metas y políticas. Esto requiere que los cambios sean coordinados a nivel de empresa. Una RN en particular puede estar involucrada en los procesos de negocio de varios sistemas y apoyada por un conjunto de subsistemas. Además, en un subsistema particular, cada Estado podrá llevarse a cabo una serie de formas diferentes (por ejemplo, como una BD con disparadores, procedimientos almacenados, etc.) Con el fin de ser capaz de mantener el apoyo a los sistemas en consonancia con los requerimientos del negocio, debe tenerse documentación de cómo las RN evolucionan a partir de su origen en el entorno empresarial para su aplicación en el SI (Bajec et al., 2005). En cualquier organización las restricciones o requerimientos del problema pueden cambiar a través del tiempo, a un nivel conceptual, del especialista. Por tanto es necesario que los SI reflejen este cambio o transformación de alguna manera. Las RN tipo restricción pueden tornarse en otra similar o en una regla totalmente diferente, entonces se deben considerar un conjunto de acciones que garanticen la consistencia del SI. Cuando estas reglas están tan cerca de los datos, estas acciones pueden involucrar recursos como disparadores y vistas. Los datos afectados por la transformación de una regla pueden ser tratados en dependencia de los intereses de los usuarios del negocio: algunos datos pueden 18.

(28) Capítulo I. necesitar cumplir la regla anterior, otros acatar la nueva, o asumir la nueva regla producto de la transformación resultante (Marrero Lorenzo, 2009).. 1.3.1 Gestión de reglas de negocio Las RN tienen un efecto significativo en la escalabilidad de la aplicación del negocio. Mientras se define el ambiente del negocio se encuentra mucha dificultad para gestionar y mantener las RN si no están debidamente tratadas, especialmente si están escondidas en el código del programa (Marrero Lorenzo, 2009). Como plantea Bajec (2000), se tienen las siguientes consideraciones. Los problemas más comunes que se derivan son:  Cada cambio de las RN requiere programación.  Las RN son distribuidas a través de una aplicación lógica; así el lugar donde hay que hacer el cambio es difícil de encontrar.  Las RN son un grupo lógico dependientes e interrelacionadas. Por tanto ellas deben ser modificadas cuidadosamente considerando los posibles efectos en otras reglas.  Los requerimientos para el cambio primario se alejan de las necesidades del negocio con las cuales los desarrolladores no están familiarizados, y corren el riesgo de que las RN no sean entendidas e implementadas correctamente.  Es muy difícil controlar las RN una vez que no existe un patrón único y común para ello. Las RN deben ser fáciles de acceder, ver, modificar y gestionar por ambas partes, desarrolladores y usuarios del negocio. Logrando estas metas resultarían mejores aplicaciones haciéndolas mucho más fácil de modificar y mantener. Un factor importante de las RN es que estas son declarativas y no procedurales, describen el estado posible: requerido o prohibido. Pero no describen los pasos que se siguen para lograr la transición de un estado a otro o los pasos a seguir para prohibir una transición.. 19.

(29) Capítulo I. Existe un error muy común de clasificar requerimientos que no tengan nada que ver con el proceso del negocio como si fueran RN. Un método que permite adicionar flexibilidad y adaptabilidad a una aplicación es adicionar parámetros a la aplicación y sus componentes. Estos parámetros pueden darse en un conjunto de ficheros o en una BD y pueden ser administrados a través de un utilitario de configuración. De modo que la aplicación pueda ser adaptada a diferentes ambientes y situaciones sin ningún esfuerzo de programación. Se ha demostrado que esta técnica es aplicable al manejo de las RN. Aunque las políticas del negocio se quedan escondidas en la lógica de la aplicación, pueden ser modificadas a través de parámetros sin ninguna necesidad de cambiar el código del programa. La adición de las modificaciones a las RN pueden ser hechas por personas del negocio, si existen herramientas de configuración simples y de fácil manejo (Bajec et al., 2000).. 1.3.2 Control de cambios y versiones de reglas de negocio Según Bajec (2005), además de las actividades que se realizan durante el modelado de la empresa (ME) y el desarrollo de SI, el escenario manejador de RN prescribe tareas adicionales que se ocupan de los cambios de RN a través de su ciclo de vida. Estas actividades se pueden realizar a nivel de empresa o SI. Ellos incluyen:  Control de cambios: El propósito de esta actividad es coordinar los cambios de RN. En general, el motivo de cambios en las RN siempre se plantea desde el entorno de negocio de la empresa. Si parece que una RN ha cambiado debido a algún problema técnico o a causa de algún nuevo requisito del SI, y desde el punto de vista comercial no es necesario para el cambio, entonces esto no es realmente una RN. Las RN son propiedad de los negocios y siempre están estrechamente relacionadas con el entorno empresarial. En consecuencia, por cada cambio en el modelo de RN debe haber una explicación a nivel empresarial, describiendo por qué el cambio es necesario. Además, para ser capaz de controlar los cambios, la información tiene que ser dirigida sobre quién ha solicitado los cambios, quién los ha aprobado y cuando serán implementados.  El control de versiones: Debido a su naturaleza dinámica, las RN pueden tener varias versiones sobre el tiempo. En algunos casos, incluso pueden existir varias versiones de 20.

(30) Capítulo I. la misma RN en uso del SI de la empresa. Por ejemplo, una versión de la regla puede ser utilizada en un subsistema, mientras que otros subsistemas están utilizando una versión diferente. A fin de conocer las versiones que se utilizan en un determinado sistema, este último debe ser capaz de realizar evaluaciones de diferentes versiones de regla y darle seguimiento a la historia de las RN.  Control de impacto: Las RN rara vez son independientes, lo que significa que un cambio en una regla en particular pueden causar cambios en otras reglas. Para gestionar los cambios, todas las dependencias entre las reglas y otros componentes se debe conocer las interdependencias, o sea darle seguimiento. Antes que una RN sea cambiada, se debe hacer un análisis de impacto para averiguar si existe algún obstáculo en el cambio de la regla.. 1.3.3 Versiones e historial de reglas de negocio Una versión es una instantánea significativa de un objeto de diseño creado en un momento del tiempo. Aparte de la semántica atribuida al concepto de versión, una versión de un objeto dado se crea a partir de las modificaciones hechas en el tiempo a las versiones previas, partiendo de una versión inicial (García Pérez, 1997). El versionamiento, aún en su forma más simple, requiere que se mantenga una historia de los cambios para permitir la retención de la definición de reglas pasadas. Según (García Pérez, 1997) la historia de versiones puede ser lineal (en forma de backup) pero un versionamiento más poderoso debe suministrar la posibilidad de manejar versiones alternativas, y por ello la historia de versiones se convierte en un árbol. El versionamiento incluye que no se pierda información valiosa si por ejemplo, cambia el dominio de un atributo. Para ello es preciso definir reglas de integridad y mecanismos que controlen la evolución. Los negocios se encuentran en constante evolución, por lo que las políticas prohibitorias sobre las que se basan también están propensas al cambio. Esto provoca que sea esencial investigar sobre las versiones de reglas en el enfoque de RN. Del estudio realizado sobre este tema la Dra. Silvie Spreeuwenberg tiene experiencia con la modelación de RN, lo cual ha sustentado el desarrollo de herramientas y técnicas para aumentar la calidad de las mismas. Silvie expresa, "Creemos que uno debe concentrarse en la calidad de la gestión de reglas de negocio 21.

(31) Capítulo I. para lograr el propósito del enfoque de reglas de negocio" (Spreeuwenberg, 2007a, Spreeuwenberg, 2007b, Spreeuwenberg, 2008). Esta autora ha investigado sobre las versiones e historial de las reglas, lo cual resulta de interés en el presente trabajo. En (Spreeuwenberg, 2007a, Spreeuwenberg, 2007b, Spreeuwenberg, 2008), se propone resolver el problema de versiones de reglas de una manera declarativa, partiendo de que todas las reglas están sujetas a ser versionadas y como condición extra se tiene que pueden estar activas en un período de tiempo determinado. Utiliza un atributo de marca de tiempo (markdate) con la fecha de comienzo y fecha fin en que la regla estuvo activa. En (Spreeuwenberg, 2007a) se muestran los siguientes enunciados que describen el problema de versiones de reglas: . Las reglas son sentencias declarativas que son usadas en una o más tareas para determinar un cierto valor para un atributo.. . Algunas reglas solo pueden ser aplicadas en un período de tiempo determinado. Este período puede ser descrito con fecha de inicio y fecha fin.. La fecha fin no es. obligatoria. Las reglas que solo tienen fecha de inicio son aplicables por lo menos hasta la fecha actual. . Las reglas aplicables sobre cierta fecha deben ser consistentes.. . Un caso del pasado puede ser retomado aplicando las reglas que estaban activas en ese período.. . La fecha que se usa para recuperar las reglas correctas pueden ser diferentes de acuerdo con: o. La tarea que se va a llevar a cabo.. o. El caso (situación) sobre el cual las reglas se aplicarán.. o. El evento que produjo la activación de las reglas.. 22.

(32) Capítulo I. En (Spreeuwenberg, 2007b) en aras de la gestión de reglas estas se agrupan en el conjunto de reglas RulesetPostRules, que pueden ser activadas en el mismo período de tiempo. Utiliza algoritmos de encadenamiento hacia adelante y hacia atrás; relacionados con los motores de reglas que tienen un mecanismo de inferencia. La desventaja de esta solución está en el mantenimiento del conjunto de regla. El cual contendrá una buena cantidad de redundancia y reglas cuando hay poca superposición en el período de aplicabilidad de las reglas. En (Spreeuwenberg, 2008) se discute una estrategia para tratar con versiones de reglas, la cual trabaja si hay lotes de diferentes versiones de nuevas reglas. Para versionar reglas complejas recomienda ver las reglas como un objeto con atributos (meta información) y crear un objeto para cada regla. Esto permite especificar una información extra acerca de la regla en su modelo de objeto. Entre los principales atributos se encuentran:  StartDate fecha a partir de la cual la regla es aplicable.  EndDate fecha hasta la cual la regla es aplicable.  PostRule atributo booleano que indica si la regla esta activa o no.  RuleStatement sentencia o referencia de la regla actual.. 1.4 Conclusiones parciales En este capítulo se brinda un marco teórico sobre las RN, haciendo énfasis en las de tipo restricción, de ellas se ofrece un patrón que permite definirlas para su implementación y almacenamiento adecuado. Se explica en qué consiste el lenguaje técnico para expresar reglas de negocio, se analiza la notación punto para navegar por las entidades del negocio y se estudian los recursos de BD que pueden ser empleados para implementar reglas. Se investiga acerca del mantenimiento y gestión de RN dinámicas, teniendo en cuenta la posibilidad que tiene de ser modificadas con el transcurso del tiempo y el surgimiento de nuevos requisitos del negocio. Se estudian variantes existentes para solucionar el problema de versiones e historial de reglas de negocio.. 23.

(33) Capítulo II. CAPÍTULO II: CONTROL DE VERSIONES EN EL REPOSITORIO DE REGLAS Y EN LA BASE DE DATOS DEL NEGOCIO En este capítulo se describe la arquitectura de administración de RN en bases de datos relacionales haciéndose énfasis en el mantenimiento de las reglas. Se explica en qué consiste el versionamiento de RN, se detallan los cambios realizados al repositorio de reglas, se muestran ejemplos de la estructura arbórea de estas versiones, sobre la cual se analizan las operaciones de inserción, eliminación y actualización de una RN. Además se analizan las consideraciones a tener en cuenta para modificar una RN tipo restricción, al ocurrir un cambio en las políticas del negocio a partir del patrón de Morgan detallado y se estudian qué elementos del patrón pueden o no cambiar para considerar una transformación válida.. 2.1 Administración y mantenimiento de reglas de negocio Las RN, al constituir políticas que conducen y monitorean los negocios, deben ser de cumplimiento estricto; desde cualquier aplicación y desde cualquier contexto en una misma aplicación. Esto hace que tengan un peso relativamente independiente y demanden su propia administración (Martínez Busto, 2011). Según (Bajec and Krisper, 2001) las RN son muy dinámicas por naturaleza y cambian constantemente, algunos ejemplos pueden ser: como respuesta a fuerzas externas, regulaciones, las acciones por competidores, cuando la empresa consigue un objetivo y establece uno nuevo. El propósito del mantenimiento de RN es coordinar esos cambios en una manera que el sistema permanezca consistente y alineado con la estrategia del negocio. Es importante que las RN sean mantenidas sobre el nivel de la organización y no dentro de un SI particular. Estos autores proponen un escenario para la administración de RN, véase la figura 2.1, en que se destaca el repositorio de RN dispuesto como un punto de contacto entre el modelado del negocio y el desarrollo de los SI. A nivel del desarrollo de SI se realizan también importantes actividades dedicadas a la administración de las RN, entre ellas están: adquisición, análisis y clasificación, validación de conflictos y consistencia, modelación e implementación. Además, existen otras actividades del 28.

(34) Capítulo II. ciclo de vida de las RN que se ejecutan separadas, tanto del modelado del negocio como del desarrollo de SI, estas son el monitoreo y mantenimiento, en estas últimas se basa la presente investigación.. Figura 2.1: Escenario de administración de RN (Bajec and Krisper, 2001). 29.

(35) Capítulo II. El mantenimiento de RN incluye varias actividades, las más relevantes son el control de versión y el control de cambios.  Control de versión: las RN podrían tener varias versiones a través del tiempo. Se debe guardar la historia de las RN para estar al día con la evolución de regla y llevar a cabo las valoraciones para las diferentes versiones de regla. Al mismo tiempo que una herramienta de software apropiada, la información del repositorio podría bastar para la creación automática de requisitos iníciales sobre un SI particular. La información del repositorio es también crucial para el mantenimiento de las RN porque mantiene el enlace entre el ambiente de negocios y los recursos de implementación.  Control de cambios: las RN en su mayoría son dinámicas lo que significa que están propensas a cambiar a medida que el negocio lo requiera, por tanto se debe analizar cómo controlar eso cambios y las afectaciones que tienen en los recursos de implementación, en los repositorios y en los datos almacenados en la BD del SI.. 2.1.1 Arquitectura de administración de reglas de negocio en bases de datos relacionales En la figura 2.2 se propone un esquema que representa la arquitectura de administración de RN en bases de datos relacionales. La solución de la implementación automática de RN tiene en cuenta las consideraciones correspondientes a generar de manera automática recursos de bases de datos en varios gestores comerciales: SQL Server, MySQL, PostgreSQL.  Representación de las reglas. (Editor de reglas en lenguaje técnico)  Con qué mecanismos de bases de datos formalizarlas. (Recursos activos de BD)  Compilador de las reglas. (Traductor LPT-SQL con el generador de reglas y consultas al repositorio del catálogo)  Almacenar las reglas. (Repositorios de trabajo: reglas y generación)  Mantenimiento de reglas. (Control de versiones, tablas de apoyo). 30.

(36) Capítulo II. Figura 2.2: Diseño general de la Arquitectura de administración de RN en bases de datos relacionales. Las RN se representan mediante el lenguaje natural, técnico y formal, esta representación queda a cargo del Editor de RN en lenguaje técnico. Los mecanismos que se utilizan para formalizar las reglas son los patrones y los recursos de implementación de BD. Para traducir del lenguaje de patrones técnico (LPT) al lenguaje formal SQL estándar, se utiliza un compilador o traductor, cuya entrada es la regla en LPT que se extrae del repositorio 31.

(37) Capítulo II. de reglas. Durante el proceso de traducción se consulta la información del catálogo que está almacenada en el repositorio del catálogo. Este repositorio contiene la información de las tablas, atributos, disparadores y vistas que están implementadas en la BD física del negocio. La información necesaria para generar la regla es almacenada en el repositorio de generación. Para las reglas tipo Restricción, esta información consiste en la consulta SQL base y la lista de eventos, los eventos que posibilitan un cambio de estado relacionado con cierta regla. Vale destacar que dicha información es suficiente para generar la regla tipo restricción desde cualquiera de los dos modos analizados en el Capítulo 1: mediato o inmediato. Finalmente se genera la regla en la BD a partir de la información extraída del repositorio de generación de acuerdo al enfoque que se maneje, y se actualiza el repositorio de reglas con la representación de la regla en lenguaje natural, técnico y formal. La regla es implementada en la BD física a partir de la representación formal como recursos de bases de datos: vistas y disparadores. En cuanto al mantenimiento de reglas, se requiere una herramienta o módulo que maneje el control de versiones de reglas y las relaciones existentes entre los datos y las RN que actúan sobre ellos.. 2.1.2 Versiones de las reglas de negocio Debido a su naturaleza dinámica, las RN pueden tener varias versiones sobre el tiempo. Si la intención del negocio es que los datos sean coherentes con las reglas que estaban activas en el momento que se introdujeron en la BD, debe dársele seguimiento a las versiones e historial de las RN. Para desarrollar esta variante, que garantiza la coherencia de los datos con las RN que condicionaron su creación se debe guardar la versión de cada regla, de manera que se pueda conocer por cuál fue sustituida, o sea el camino de derivación. Se pretende permitir:  Crear varias versiones de las reglas  Recuperar versiones Aparte de la semántica atribuida al concepto de versión, una versión de una RN se crea a partir de las modificaciones hechas en el tiempo a las versiones previas, partiendo de una versión inicial. Un esquema de estas derivaciones puede apreciarse en la historia de versiones de RN, cuya representación gráfica más natural es un árbol (García Pérez, 1997), como se muestra en 32.

(38) Capítulo II. la figura 2.3. Los nodos del árbol identifican las versiones y los arcos representan las interrelaciones de derivación entre las reglas.. Figura 2.3: Historia de versiones de RN. Nótese que el árbol se crea a partir de un único nodo en el nivel cero denominado RN(0), se toma este acuerdo para indicar que todas las reglas nuevas que se creen se van a derivar de este nodo. El cual es una regla abstracta y sirve solo para que sea la raíz del árbol. Como convenio se establece que el valor del atributo versión del nodo raíz toma valor cero y no tiene atributo padre porque él no se deriva de nadie, sino que los demás nodos se van a derivar de él, además este nodo nunca cambia, es por esto que se concibe como un solo árbol. Los nodos que se encuentran en el nivel uno corresponden a las reglas que se van a insertar por primera vez, los que se encuentran en el nivel dos son las distintas versiones de las reglas que se encuentran en el nivel uno y así sucesivamente se tienen tantos niveles como versiones de una misma regla existan. De esta manera se define la relación padre-hijo; por ejemplo en la figura 2.1 la regla RN (2.0) es el padre de las reglas RN (2.1) y RN (2.2) pues estas dos últimas se derivan de dicha regla. Los nodos que no tienen hijos o sea que de ellos no se deriva nadie se denominan hojas. Nótese que este árbol puede tener tantas versiones de reglas como sea necesario. En la figura 2.4 se muestra la estructura arbórea correspondiente a las RN una vez que se han insertado en el repositorio.. 33.

(39) Capítulo II. Figura 2.4: Parte del repositorio de RN. Historia de versiones de reglas. Inicialmente cuando se cree una regla nueva el padre_versión es igual a cero pero cuando esta se modifique tomará el valor del atributo versión de la cual se derivó. Esta estructura de árbol se puede representar en el repositorio de reglas en formato XML. En (Calderón Solís, 2011) se explica detalladamente cada uno de los elementos y atributos que conforman el repositorio de reglas y se muestra el esquema XSD correspondiente; en esta investigación se le realizan algunas modificaciones como se muestra figura 2.5, de manera que este esquema permita representar adecuadamente la estructura de árbol con las versiones de las reglas.. Figura 2.5: Esquema XSD del repositorio de reglas con control de versiones. 34.

(40) Capítulo II. El repositorio está compuesto por RN y sus respectivas versiones, de las que se conocen sus atributos: se mantienen los atributos inherentes a cualquier regla, léase id (identificador), versión representa el número de la versión de la regla, este valor es único para cada regla por ejemplo idversión =1.0, el tipo indica el tipo o clasificación de la regla que puede ser restricción, notificación, clasificación, cómputo, etc., aunque en este trabajo se le da mayor prioridad a las reglas tipo restricción, los atributos idpadre y padre_versión representan el identificador y la versión de la regla de la cual se derivó respectivamente, por ejemplo la regla con id=RN1 y versión =1.0, tiene como padre el nodo raíz, por tanto idpadre =RN0 y padre_versión =0. Las reglas a su vez pueden estar activas en la BD durante uno o varios períodos de tiempo. Puede suceder que se modifique una regla y sea esta nueva versión la que se encuentre activa en etapa de prueba y por determinadas razones no se obtengan los resultados esperados, por consiguiente se le brinda al usuario la posibilidad de volver a una versión anterior. Si se sigue el historial de esa regla se nota que ha estado activa en diferentes intervalos de tiempo, esto suele suceder en varias organizaciones. Por ejemplo el ministerio de educación (MINED) en las enseñanzas primaria y secundaria contaba con un profesor especializado en una asignatura, después por determinadas razones y por la escasez de profesores, el país se vio en la necesidad de encontrar una solución a este problema y se crearon los Profesores Generales Integrales (PGI) de formación general o sea un profesor imparte todas las asignaturas excepto inglés y educación física, esta regla o política estuvo vigente un tiempo, cuando se estabilizó la situación con los profesores, se volvió a aplicar la regla anterior o sea la especialización de los profesores en materias especificas. De esta manera se puede apreciar un ejemplo de aplicación de una regla en diferentes periodos de tiempo. En trabajos anteriores (Calderón Solís, 2011, Pérez Alonso, 2008) se utilizaba el atributo estado para indicar si la regla se encontraba activa o no en la BD. En el esquema propuesto se elimina este atributo y se agrega al repositorio el elemento PeriodosActivación que a su vez tiene atributos como el id (identificador), fecha_inicio y fecha_fin que representan el período de tiempo en que la regla estuvo activa. Estos tres atributos están señalados con líneas discontinuas que indican opcionalidad porque cuando se crea una regla, si no se ha especificado la opción de “Activar Regla”, esta se crea pero no se genera, ni compila, por lo 35.