Modificación de las reglas de negocio tipo restricción y su implementación

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación. “Modificación de las reglas de negocio tipo restricción y su implementación”. Autora: Islemy Marrero Lorenzo Tutores: Msc. Martha Beatriz Boggiano Castillo Lic. Alain Pérez Alonso. ¨Año del 50 Aniversario del Triunfo de la Revolución¨ 3 de Julio del 2009.

(2) Dedicatoria. Dedicatoria.. A mis padres, por todo el orgullo que sienten de mí, a quienes les debo más que un título. A mi hermano y su esposa. A mi sobrina y a mis futuros hijos, para que sigan mi ejemplo. A mi novio. A mi amiga Aylen, por luchar junto a mí todos estos años y ganarse mi amistad. A toda mi familia, Y especialmente a Dios, por ser la fuente que brota amor, sabiduría, esperanza, paz,….. III.

(3) Agradecimientos. Agradecimientos. A mis padres, nunca va ser suficiente lo que pueda hacer por ustedes; realmente agradecer es una palabra muy pequeña para expresar todo lo que les debo. A mi hermano y su esposa, por todo el apoyado y cariño brindado. A mi novio, por haberme dado tanta fuerza cuando creía estar vencida. A mi amiga Aylen, por tu amistad, por soportarme, por haber hecho más placenteros mis momentos en la Universidad,… A mis abuelos, primos y tíos, por creer en mí. A mi madrina Paula, Florita, Lisandra y Lisett, por haberme ayudado tanto en el transcurso de estos cinco años de carrera. A mis tutores MSc. Martha Beatriz Boggiano Castillo y Lic. Alaín Pérez Alonso, por su gran ayuda, orientación y asesoramiento en este trabajo. A todos los profesores que me formaron y contribuyeron en mi transformación de estudiante a profesional. A mis compañeros: Alain, Yaise, Arazay, Anailys, Leydis, Curra, Ernesto y Estopiñales, por haberme ayudado cuando lo necesité. Mencionarlos a todos es difícil pero sepan que están en mi corazón A los chóferes que han sido elemento móvil de mis estudios. A todos los que no he podido mencionar pero de una forma u otra han puesto su granito de arena para la realización de este trabajo, A los que no me ayudaron, porque me demostré que ante las dificultades supe crecer. Y especialmente gracias a Dios, por escucharme, estar siempre a mi lado y por la dicha de contar con todos ustedes. Llegue a todos mis sinceros agradecimientos más allá de las simples palabras. Gracias de todo corazón.. I-IV.

(4) Pensamiento. Pensamiento.. Presta oído a la sabiduría; Entrega tu mente a la inteligencia. Proverbios 2:2. V.

(5) Resumen. Resumen.. Las reglas de negocio son un componente clave en cómo se toman las decisiones en una empresa, estas se encuentran siempre presentes en la actuación de una organización. Con el tiempo las reglas o políticas de un negocio, pueden modificarse o actualizarse, lo que debe ser reflejado en el Sistema de Información correspondiente. En el caso de las reglas de negocio, tipo restricción, cualquiera de estas acciones pudiera ocasionar contradicciones entre la regla modificada y algunos datos existentes en la base de datos. Las ideas descritas anteriormente conducen a que el propósito de este trabajo sea lograr una versión mejorada del editor producido en la investigación “Aplicación para reglas de restricción en negocios” con el fin de modificar las reglas de negocio tipo restricción. Se estudian las reglas de negocio tipo restricción, haciéndose un análisis sobre los tipos de integridad referencial y sobre el uso de los desencadenadores (triggers) en bases de datos. Se hace un análisis detallado sobre la concepción de modificación asumida, usando ejemplos para su mejor comprensión y se analizan las acciones posibles a realizar sobre los datos que violan la regla de negocio modificada. Esta investigación concluye con la implementación de la herramienta Modificar Regla, una versión mejorada del Editor Reglas de Restricción en lenguaje técnico realizado en (Pérez Alonso, 2008). Se logra con la nueva funcionalidad del software, proveer diferentes tratamientos a los datos afectados por la modificación de la regla de negocio tipo restricción, de acuerdo a la decisión del usuario del sistema.. VI.

(6) Abstract. Abstract.. The business rules are a key component in how decisions are taken in a company; these are always found in organization behaviour. Whit time the rules or policies of a business can be changed or updated, which can by reflected in the corresponding information system. In the case of business rules, type restriction, any of these actions could lead to contradictions between the rule changed and some data in the database. The described ideas before hand make the purpose of this work to be a better version of the editor produced in the investigation "Application of restriction on business rules" with the objective to change the business rules type restriction. It is studied the business rules type restriction making an analysis about the kind of referential integrity and the use of triggers in database. It is done a detailed analysis on the conception of modification assumed, using examples for better understanding and it is analyzed the possible actions to be done upon the data that violate the modified business rule as amended. This investigation concludes with the implementation of the “Modify Rule” tool, a better version of the Editor Restriction Rules in technical language made in the investigation of (Pérez Alonso, 2008). It is possible with the new software functionality, providing different treatments to data affected for the modification of the business rule type restriction, according to the decision of the user of the system.. VII.

(7) Tabla de Contenidos. Tabla de Contenidos. INTRODUCCIÓN. ................................................................................................................. 1 CAPÍTULO I : CONSIDERACIONES GENERALES SOBRE REGLAS DE NEGOCIO. I.1. 6. DEFINICIONES DE REGLAS DE NEGOCIO. ...................................................................... 6. I.1.1. Beneficios de usar reglas de negocio.................................................................... 6. I.2. ESTUDIO DE LAS REGLAS DE NEGOCIO EN CUBA.......................................................... 7. I.3. FORMAS MODERNAS DE IMPLEMENTACIÓN DE REGLAS DE NEGOCIO............................. 7. I.3.1 I.4. Gestión y mantenimiento de las reglas de negocio............................................... 8. REGLAS DE NEGOCIO TIPO RESTRICCIÓN ...................................................................... 9. I.4.1. Modificación de Reglas de Negocio tipo Restricción en un Sistema de. Información. ..................................................................................................................... 10 I.5. CLASIFICACIÓN DE REGLAS EN SISTEMA DE GESTIÓN DE BASE DE DATOS ................. 11. I.6. OPERACIÓN DE ACTUALIZACIÓN EN LA BASE DE DATOS.............................................. 12. I.6.1. Consideraciones de Integridad ........................................................................... 12. I.6.2. Análisis de las restricciones de Integridad en bases de datos relacionales ....... 14. I.6.2.1 Integridad de Dominio..................................................................................... 14 I.6.2.2 Integridad referencial....................................................................................... 16 I.6.3. Uso de triggers como recursos de Base de Datos Relacionales......................... 17. I.6.3.1 Trabajo con los triggers. .................................................................................. 18 I.7. CONCLUSIONES PARCIALES. ....................................................................................... 21. CAPÍTULO II : ANÁLISIS DE LAS DIFERENTES OPERACIONES A REALIZAR SOBRE LOS DATOS DE LA BASE DE DATOS ANTE LA MODIFICACIÓN DE UNA REGLA DE NEGOCIO.............................................................................................. 23 II.1. ANÁLISIS SOBRE LA MODIFICACIÓN DE UNA REGLA DE NEGOCIO. ............................... 23. VIII.

(8) Tabla de Contenidos. II.2. ACCIONES A TOMAR CON LA REGLA Y LOS DATOS QUE INCUMPLEN LA RESTRICCIÓN. 28. II.2.1. Aplicar siempre y a todos los datos. ................................................................... 30. II.2.1.1 Eliminar los datos que no cumplan con la regla modificada........................... 30 II.2.1.2 Mantener los datos que no cumplen con la regla modificada y no permitir actualización. ................................................................................................................ 30 II.2.1.3 Eliminar los datos seleccionados que no cumplen con la regla modificada y no permitir actualización.................................................................................................... 31 II.2.1.4 Mantener los datos que no cumplen con la regla modificada y permitir actualización aplicando la regla activa. ........................................................................ 31 II.2.1.5 Eliminar los datos seleccionados que no cumplen la regla modificada y al actualizar aplicar la regla activa.................................................................................... 31 II.2.2 II.3. Aplicar a partir de ahora.................................................................................... 32. SECUENCIA DE ACCIONES PARA TRANSFORMAR UNA REGLA DE NEGOCIO TIPO. RESTRICCIÓN. ....................................................................................................................... 33. II.4. ANÁLISIS DE LA NUEVA VERSIÓN DEL SOFTWARE “EDITOR REGLAS DE RESTRICCIÓN”. 34. II.5. CONCLUSIONES PARCIALES. ....................................................................................... 44. CAPÍTULO III...........: IMPLEMENTACIÓN DE LAS TRANSFORMACIONES A LA APLICACIÓN PARA REGLAS DE NEGOCIO TIPO RESTRICCIÓN. ..................... 46 III.1 MODIFICACIONES AL EDITOR REGLAS DE RESTRICCIÓN PARA MODIFICAR UNA REGLA. 46 III.1.1 Cambios realizados al Editor Reglas de Restricción. ........................................ 46 III.1.2 Incorporación de una herramienta al Editor Reglas de Restricción.................. 47 III.2 MANUAL DE USUARIOS. ............................................................................................. 50 III.3 CONCLUSIONES PARCIALES. ....................................................................................... 58 CONCLUSIONES................................................................................................................. 59 RECOMENDACIONES. ..................................................................................................... 60 REFERENCIAS BIBLIOGRÁFICAS................................................................................ 61 ANEXO 1: DIAGRAMA ENTIDAD INTERRELACIÓN DE LA BASE DE DATOS TRANSPLANTE RENAL.................................................................................................... 63. IX.

(9) Tabla de Contenidos. ANEXO 2: FRAGMENTO DEL CÓDIGO FUENTE PARA ELIMINAR EL(LOS) TRIGGER(S) Y FUNCIÓN DEL REPOSITORIO Y DE LA BASE DE DATOS; Y PARA ACTUALIZAR EL REPOSITORIO. ..................................................................... 64 ANEXO 3: FRAGMENTO DEL CÓDIGO FUENTE PARA DESARROLLAR UNA REGLA EN EL REPOSITORIO Y PARA ACTIVARLA EN LA BASE DE DATOS. 66 ANEXO 4: FRAGMENTO DEL CÓDIGO FUENTE PARA ELIMINAR TODAS LAS TUPLAS DE LA BASE DE DATOS................................................................................... 68. X.

(10) Lista de Figuras. Lista de Figuras.. Figura I.1 DBMS Componentes de Integridad ................................................................. 13 Figura I.2 Definición de Esquema: proveedores y partes. ................................................ 15 Figura II.1 Diagrama de casos de uso v1.0....................................................................... 34 Figura II.2 Diagrama de casos de uso v1.1....................................................................... 35 Figura II.3 Diagrama de Estado para el caso de uso Modificar Regla. ............................ 43 Figura III.1 Conexión a la base de datos........................................................................... 51 Figura III.2 Pasos para seleccionar una regla. .................................................................. 51 Figura III.3 Regla seleccionada. ....................................................................................... 52 Figura III.4 Ambiente para modificar la regla seleccionada............................................. 53 Figura III.5 Decisión de desarrollo y activación............................................................... 54 Figura III.6 Mensaje informativo...................................................................................... 54 Figura III.7 Acción con los datos que violan la regla. ...................................................... 55 Figura III.8 Confirmación de eliminación de todas las tuplas .......................................... 55 Figura III.9 Ambiente para eliminar una tupla que viola la regla..................................... 56 Figura III.10 Mensaje al eliminar una tupla...................................................................... 57 Figura III.11 Después de eliminar una tupla..................................................................... 57. XI.

(11) Introducción. Introducción.. El desarrollo de un Sistema de Información está necesariamente vinculado a las reglas de negocio. La principal motivación para insertar automáticamente reglas de negocio en un SI (Sistema de Información) suele ser el rendimiento(Reyes, 2002). Las reglas de negocio son un componente clave en cómo se toman las decisiones en una empresa. En efecto, cada vez que se toma una decisión dentro de una organización es porque se han consultado reglas definidas, las cuales en muchos casos se encuentran escritas en manuales de políticas que los responsables de decisiones deben conocer para desarrollar su gestión cotidiana. Así, las transacciones son completadas por personas basándose en el conocimiento formal o informal (documentado) de las reglas y políticas de negocio de su organización (Cientec). Las reglas de negocio se encuentran siempre presentes en la actuación de una organización, bien de manera explícita (una política de salarios, el horario laboral, el descuento a aplicar en función de las condiciones de la venta, etc.) o de manera implícita no expresada (el trato cortés con los clientes, la responsabilidad del supervisor sobre sus supervisados, etc.) siempre implicando la participación directa o indirecta de personas(AuraPortal, 2008). Sin embargo, el término "Reglas de Negocio" queda reservado aquí únicamente para aquellas reglas que revisten carácter explícito y que pueden ser y son, expresadas de manera entendible, registradas, localizables y modificables en un Sistema de Información(AuraPortal, 2008).. 1.

(12) Introducción. Con la automatización de las reglas de negocio 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, y además pueden contar con una solución que les ayude a hacer más dinámica y sencilla las modificaciones a las reglas de negocio(Cientec). Los requisitos o requerimientos que pueden verse como reglas de negocio de la organización, tradicionalmente han sido realizados o codificados “a mano” por el programador en el código fuente del programa, en los objetos de bases de datos de la aplicación, o en ambos. En (Pérez Alonso, 2008) se estudian los diferentes tipos de reglas de negocio de acuerdo a la clasificación de Morgan. La generación de reglas de negocio, tipo restricción, permite evitar fallas y de este modo lograr importantes reducciones de tiempo y costo. En el trabajo referido anteriormente, se diseñó y creó un editor que permite insertar automáticamente las reglas de restricción en la base de datos del negocio, usando un repositorio para almacenarlas y un compilador para generarlas. Las reglas se representan formalmente mediante triggers y funciones usando lenguaje SQL para los scripts correspondientes en la base de datos. Con el tiempo las restricciones asociadas a un negocio, pueden cambiar, modificarse o eliminarse, lo que debe ser reflejado en el Sistema de Información. En el caso de las reglas de tipo restricción cualquiera de estas acciones pudiera traer modificaciones o eliminaciones en algunos o todos los datos involucrados. Cuando la regla es transformada muchos datos pueden estar en contradicción con la nueva regla que se imponga. Y entonces es necesario diseñar una solución que resuelva este problema.. 2.

(13) Introducción. Problema de investigación: El editor de reglas de negocio, en lenguaje técnico, obtenido en la investigación “Aplicación para Reglas de Restricción en Negocios”, no es capaz de tratar la modificación de una regla de negocio, y los datos que violan la regla después de ser modificada y generada en la base de datos. Objetivo general: Analizar las consecuencias de modificar reglas de negocio de tipo restricción para los datos de una base de datos Relacional afectados por dicha modificación, logrando una versión mejorada del editor producido en la investigación “Aplicación para Reglas de Restricción en Negocios”, que de un tratamiento adecuado a las modificaciones de las reglas de negocio. Objetivos específicos: 1. Analizar las posibles afectaciones que puedan tener los datos de la base de datos de un negocio ante las modificaciones de las reglas de negocio tipo restricción. 2. Establecer los cambios a realizar en el repositorio de reglas y en los recursos de la base de datos (triggers y funciones) para tratar las modificaciones de las reglas de restricción. 3. Establecer las acciones a realizar sobre los datos de la base de datos afectados por la transformación de la regla de negocio, al no cumplirse las nuevas restricciones. 4. Implementar acciones a realizar sobre los datos, los recursos de bases de datos asociados y el repositorio de reglas, ante las modificaciones de la regla. Preguntas de investigación: ¿Qué significa modificar la regla de negocio en términos, del patrón de regla adoptado? ¿Qué consecuencias ocasiona sobre los datos de la base de datos la transformación de una regla de negocio?. 3.

(14) Introducción. ¿Qué modificaciones se deben realizar sobre los recursos de bases de datos que permiten implementar automáticamente la transformación de la regla? ¿Cuáles acciones se realizarán sobre las tuplas de la base de datos que incumplan la nueva regla? ¿Cómo implementar la transformación de la regla de negocio tipo restricción? Hipótesis de investigación: La transformación de una regla de negocio tipo restricción asociada a la base de datos del negocio, se logra realizando modificaciones en los recursos asociados a la generación de la regla y permitiendo al usuario eliminar o mantener los datos afectados. Los aspectos generales de reglas de negocio, específicamente de tipo restricción, se abordan en el capítulo I; se estudian las acciones de modificación y eliminación así como las diferentes maneras de su implementación. El Capítulo II es dedicado a las consideraciones que se tienen en cuenta para realizar transformaciones en las reglas de negocio. El Capítulo III aborda las modificaciones de implementación al editor de reglas existente incluyendo la opción de modificación.. 4.

(15) CAPÍTULO I.

(16) Capítulo I. CAPÍTULO I : CONSIDERACIONES GENERALES SOBRE REGLAS DE NEGOCIO.. Este capítulo es dedicado a los aspectos generales sobre las reglas de negocio, haciendo énfasis en las reglas de tipo restricción implementadas como mecanismos de bases de datos. Se hace un análisis de las operaciones sobre la base de datos, de las restricciones de integridad y del uso de los triggers para imponer reglas del negocio dentro de las bases de datos.. I.1 Definiciones de Reglas de Negocio. Una regla de negocio es una declaración que define o limita algún aspecto de una empresa. Las reglas de negocio imponen restricciones o limitaciones sobre ciertos aspectos de una base de datos basadas en la manera en que la organización percibe o utiliza sus datos(Reyes, 2002). Se pretende hacer valer la estructura empresarial para controlar o influir en el comportamiento de la empresa(Negocio, 2001). Las reglas de negocio que afectan al proyecto son atómicas es decir, no pueden desglosarse aún más(Negocio, 2001). Una regla de negocio en un Sistema de Información agiliza los frecuentes cambios en las prácticas empresariales, que pueden provenir de dentro de la empresa, o desde fuera, emitidos normalmente por las agencias reguladoras.. I.1.1 Beneficios de usar reglas de negocio. Varios son los beneficios que pueden derivarse del uso de Reglas de Negocio. De todos, según Lowenthal los tres más importantes son (Lowenthal, 2005): Agilidad: respuesta simple y rápida a los requisitos dinámicos.. 6.

(17) Capítulo I. Reducción del Costo: bajo costo para crear o actualizar las partes de aplicaciones que implementan las políticas del negocio. Transparencia: las reglas permiten fácilmente la auditoría que los servicios de software llevan a cabo en sus políticas de negocios correspondientes.. I.2 Estudio de las Reglas de Negocio en Cuba. La revisión bibliográfica realizada arroja que las principales incursiones sobre este tema en nuestro país, específicamente dedicado a la generación automática de reglas de negocio en Sistemas de Información, está concentradas precisamente en el grupo de Investigación de base de datos de la Universidad Central de Las Villas, al cual también está vinculado este trabajo.. I.3 Formas modernas de implementación de reglas de negocio. Las formas modernas de implementación de las reglas del negocio generalmente siguen el enfoque actual de regla de negocio y manipulan estas de una manera explícita. Dentro de este contexto, una regla de negocio representa un meta-elemento importante que necesita ser capturado, formalizado e implementado aparte de los otros elementos que constituyen la arquitectura de aplicación(Bajec). 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 reglas de negocio, se pueden clasificar en(Bajec): Data base-independent tools (Herramientas independientes de bases de datos): las reglas de negocio son implementadas en una base de datos, usando triggers y procedimientos almacenados. Sin embargo estos son generadas automáticamente y manejadas por herramientas que nos son bases de datos. Server-based tools (herramientas basadas en el servidor): las reglas de negocio 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. Rule-based systems (sistemas basados en reglas): En vez de especificar restricciones sobre elementos de datos o tabla, un método orientado a la lógica 7.

(18) Capítulo I. captura la lógica del negocio a un alto nivel y las reglas asociadas. En tiempo de ejecución, motores especiales son usadas para procesar las reglas y generar respuestas apropiadas.. I.3.1 Gestión y mantenimiento de las reglas de negocio. Las reglas de negocio 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 reglas de negocio si no están debidamente tratadas, especialmente si están escondidas en el código del programa. Como plantea (Bajec), se tienen las siguientes consideraciones. Los problemas más comunes que se derivan son: Cada cambio de las reglas del negocio requiere programación. Las reglas de negocio 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 reglas del negocio 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 reglas de negocio no sean entendidas e implementadas correctamente. Es muy difícil controlar las reglas de negocio una vez que no existe un patrón único y común para ello. Las reglas de negocio 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. Desafortunadamente ni las herramientas de desarrollo ni las metodologías más usadas actualmente consideran explícitamente las reglas de negocio, sin embargo tratan estas solamente desde las perspectivas de datos y funciones.. 8.

(19) Capítulo I. Un factor importante de las reglas de negocio 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. Existe un error muy común de clasificar requerimientos que no tengan nada que ver con el proceso del negocio como si fueran reglas de negocio. Un método que permite adicionar flexibilidad y adaptabilidad a una aplicación es parametrizar la aplicación y sus componentes. Estos parámetros pueden darse en un conjunto de ficheros o en una base de datos 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 es técnica es aplicable al manejo de las reglas de negocio. Aunque las reglas de 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 reglas de negocio pueden ser hechas por personas del negocio, si existen herramientas de configuración simples y de fácil manejo(Bajec).. I.4 Reglas de Negocio tipo Restricción Existen varias definiciones para las reglas de negocio tipo Restricción, en dependencia del autor que la defina, se presenta un conjunto de estas definiciones(Pérez Alonso, 2008). Según Solivares las reglas de negocio de tipo restricción es el grupo compuesto por las reglas que restringen los datos contenidos en el sistema. Nótese que este grupo se solapa en cierto modo con las reglas del modelo de datos, pues aquellas también impiden la introducción de datos erróneos. La diferencia estriba en que las reglas de restricción condicionan el valor de los atributos o propiedades de una entidad más allá de las restricciones básicas sobre las mismas existentes.. 9.

(20) Capítulo I. Lowenthal afirma que las reglas de negocio de tipo restricción previenen posibles violaciones, principalmente en su forma o valor. Morgan define dos patrones de reglas de restricción: Restricción Básica y Lista de Restricciones(Morgan, 2002). Restricción Básica es el más común entre los patrones para reglas de negocio, establece una restricción sobre el sujeto de una regla. <determinante><sujeto>[no](debe|tiene)<característica> [(si | a menos que ) <hecho>] . Lista de Restricció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>. I.4.1 Modificación de Reglas de Negocio tipo Restricción en un Sistema de Información. 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 sistemas de información reflejen este cambio o transformación de alguna manera. Las reglas de negocio de 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 Sistema de Información. Cuando estas reglas están tan cerca de los datos en la base de datos, estas acciones pueden involucrar recursos como triggers y funciones. 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 necesitar cumplir la regla antigua, otros acatar la nueva, o asumir la nueva regla producto de la transformación resultante.. 10.

(21) Capítulo I. I.5 Clasificación de reglas en Sistema de Gestión de Base de Datos Se puede considerar que algunas reglas de negocio pueden estar vinculadas directamente a los datos, de aquí que se tienen en cuenta la clasificación de reglas en bases de datos. Stefano Ceri y Piero Fraternali clasifican las reglas en el sistema de gestión de Base de datos en dos familias Reglas Deductivas y Reglas Activas(Ceri): 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 base de datos. Así la regla deductiva puede ser usada para derivar información compleja de datos extensivamente almacenados; o indicar en que medida un objeto está en un estado consistente o en que medida muchos objetos relacionados son mutuamente consistentes. Las reglas deductivas que testan la consistencia de base de datos son llamadas restricciones de integridad (integrity constraint). En cualquier caso, las reglas deductivas no pueden causar un cambio en el contenido de la base de datos por tanto son también llamadas reglas pasivas. Reglas Activas: brindan un comportamiento reactivo el cual es motivado por la ocurrencia de algún evento, típicamente una operación de base de datos y ejecuta una reacción a este estímulo. Reglas activas pueden poseer consultas a la base de datos para sacar información sobre eventos y objetos de base de datos y deciden en que medida los eventos realmente 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 tienen efectos secundarios; pueden cambiar el contenido de la base de datos. Estas reglas son muchas veces llamadas triggers en productos relacionales. 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.. 11.

(22) Capítulo I. I.6 Operación de actualización en la base de datos. La operación de actualización (o modificar) se utiliza para cambiar el valor de uno o más atributos en una tupla (o tuplas) de alguna relación R. Es necesario especificar una condición en el atributo de la relación para seleccionar la tupla (o tuplas) a ser modificada. La actualización de un atributo que no es ni una llave primaria ni una llave foránea generalmente no causa problemas; el DBMS (Sistemas de administración de Bases de Datos) solo necesita confirmar el nuevo valor de tipo de datos correctos y de dominio. La Modificación del valor de una llave primaria es similar a eliminar una tupla e insertar otra en su lugar, porque usamos la llave primaria para identificar las tuplas. Si un atributo de llave foránea se modifica, el DBMS debe asegurarse de que el nuevo valor se refiere a una tupla existente en la relación de referencia (o sea nula). Existen opciones similares para hacer frente a las violaciones de integridad referencial causados por actualización como las opciones examinadas para la operación de eliminación. De hecho, cuando una restricción de integridad referencial se especifica en los DDL (Definition Data Language), el DBMS permitirá al usuario elegir las opciones por separado para hacer frente a una violación causada por eliminación y una violación causados por actualización(Elmasri).. I.6.1 Consideraciones de Integridad Como plantea (Ponniah, 2003), se tienen las siguientes consideraciones. La operación de procesamiento de sistema de base de datos está sujeta a los posibles problemas de integridad. El usuario puede estar expuesto a considerar datos incompatibles, incorrectos, y datos no válidos. Las funciones de la integridad en la base de datos pueden llevarse a cabo mediante la realización de las siguientes acciones: Monitorear y examinar todas las transacciones, especialmente aquellas con actualizaciones de base de datos. Detectar cualquier violación de integridad de fecha en las transacciones.. 12.

(23) Capítulo I. Si una violación es detectada, tomar las acciones apropiadas, tales como: •. Rechazo de la operación.. •. Señalamiento de la violación.. •. La corrección de la condición de error es posible.. Componentes específicos existen en el DBMS para preservar la integridad de datos. La Figura I.1 presenta una visión general de componentes de integridad. Cada componente realiza una serie de funciones.. Figura I.1 DBMS Componentes de Integridad. Las fallas de base de datos dan lugar a problemas potenciales de integridad. Cuando un accidente de disco ocurre las transacciones que se están ejecutando quedan inconclusas al no poder realizarse todas las actualizaciones en los datos. En el procesamiento de transacciones concurrente en un entorno de base de datos, las operaciones de diferentes transacciones se intercalan las unas con las otras pero pueden surgir problemas de integridad a causa de tal procesamiento intercalado de transacción.. 13.

(24) Capítulo I. I.6.2 Análisis de las restricciones de Integridad en bases de datos relacionales SQL suministra una variedad de técnicas para expresar restricciones de integridad como parte de un esquema de BD. Existen diferentes tipos de restricciones(Molina; et al., 2002): Restricciones de llaves: Cuando un atributo o conjunto de atributos es declarado para ser llave de una relación. Restricción de llave foránea (es una forma de integridad referencial): son requerimientos que exigen que un valor en un atributo o atributos de una relación, debe también aparecer como valor en un atributo o atributos de otra relación, asimismo para un conjunto de atributos que conformen una llave foránea. Las restricciones se dan sobre (Molina; et al., 2002): a) Atributos b) Tuplas c) Restricciones como un todo.. I.6.2.1 Integridad de Dominio Usando DDL se definen sentencias para un esquema de relación. Cada atributo tiene un dominio subyacente, el atributo puede tomar valores sólo de un dominio específico de valor y sólo puede ser de un tipo de datos particular. Cuando una transacción inserta o actualiza una fila en una tabla particular, actualiza el valor de los atributos, este tiene que conservar su dominio subyacente. Si no lo hacen, entonces los intentos de la transacción violan el dominio de las reglas de integridad. La violación del dominio de las reglas de integridad son muy comunes, su consideración y tratamiento deben ser dirigidos a conservar la integridad de base de datos. En la Figura I.2 se muestran los DDL de un ejemplo, para definir el esquema de base de datos relacional para la base de datos de proveedores y partes (Ponniah, 2003).. 14.

(25) Capítulo I. Figura I.2 Definición de Esquema: proveedores y partes.. Aquí se observa que las reglas de integridad de dominio son tenidas en cuenta como indicaciones en la definición del esquema. El administrador de transacción del DBMS. 15.

(26) Capítulo I. debe detectar cualquier intento de violación y rechazar la operación con un mensaje. En algunos casos, el sistema puede sustituir los valores por defecto y permitir que la transacción se realice(Ponniah, 2003). De acuerdo al ejemplo anterior, se pueden apreciar las siguientes características asociadas a los atributos: Tipo. de. datos.. Cada. atributo. debe. ajustarse al tipo de datos definido.. Valores nulos. Valores nulos no se admitirán para el atributo SupplierName. Valores admisibles. Sólo se permiten ciertos valores para el atributo SupplierStatus. Rango de Valores. Los valores de PartWeight deben caer dentro del rango. Valores por defecto. Sustituir por un determinado color, si el valor de PartColor falta(Ponniah, 2003).. I.6.2.2 Integridad referencial. Existen varias definiciones formales de integridad referencial, aquí se tienen en cuenta las dos definiciones siguientes, que son equivalentes: La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son válidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad(Curso, 2000). La integridad referencial es una propiedad deseable en las bases de datos. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades válidas, es decir, que existen en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas(Wikipedia, 2009). El subsistema de integridad de cualquier DBMS maneja violaciones de integridad referencial(Ponniah, 2003).. 16.

(27) Capítulo I. Se puede describir la integridad referencial en función de que cualquier conjunto de valores para los atributos de la llave foránea, no nulos, debe también aparecer en el atributo correspondiente a la relación referenciada(Molina; et al., 2002).. I.6.3 Uso de triggers como recursos de Base de Datos Relacionales. Como plantea (Bajec), se tienen las siguientes consideraciones. Un trigger o disparador es un recurso de base de datos que sucede cuando un evento ocurre al insertar un registro en la base de datos, cuando es modificado o cuando es eliminado. Las acciones ejecutadas por triggers son escritas en Structured Query Language (SQL) y son almacenadas como cuerpo de trigger o como procedimientos de base de datos. Estas características hacen los triggers convenientes para la implementación de reglas de negocio. Por ejemplo usando el trigger “before-insert” el record puede ser chequeado (y rechazado si viola alguna regla de negocio) antes de que sea realmente insertado. Una vez que la implementación de las reglas de negocio reside en la propia base de datos, las modificaciones son independientes a la aplicación y pueden ser realizadas sin acceder a la lógica de esta, realmente hay algunas ventajas del uso de triggers de base de datos para forzar las reglas de negocio. La representación formal de reglas de negocios está basada en lenguaje SQL que es cercano al lenguaje natural. Las reglas de negocio son independientes de la lógica de aplicación una vez que son almacenadas en la base de datos. Las reglas de negocio residen en el servidor de base de datos. Por tanto estas son dispersadas de acuerdo al número de clientes. Las modificaciones de reglas de negocio pueden ser ejecutadas de forma remota (accesibilidad remota es una de las características más importantes del servidor de base de datos). El lugar donde una regla de negocio particular es implementada es fácil de encontrar cuando se conoce la acción que la inicializa.. 17.

(28) Capítulo I. Añadir una regla de negocio no requiere necesariamente que el código de aplicación sea cambiado. Realmente hay ventajas en usar triggers para forzar las reglas de negocio, pero también desventajas. Con este enfoque las reglas sufren de ser dependiente de datos, así no pueden fácilmente soportarse reglas que deban ser tratadas en aplicaciones con objetos de negocios complejos y procesos de negocio. A pesar de las similitudes entre el lenguaje SQL y expresiones de lenguaje natural, gestionar triggers de base de datos requiere generalmente de un profesional en SQL. Tal como los sistemas de gestión de base de datos realizan el almacenamiento de datos no pueden lograr ellos mismos expresar de manera óptima todas las reglas de negocio.. I.6.3.1 Trabajo con los triggers. Según plantea (Waymire), se tienen las siguientes consideraciones. Los triggers se invocan de manera automática cuando se intenta modificar datos que el trigger está diseñado para proteger. Los triggers ayudan a asegurar la integridad de sus datos evitando que se hagan cambios no autorizados o inconsistentes. Por ejemplo, suponga que tiene una tabla de clientes y una de pedidos. Puede crear un trigger que asegure que al crear un nuevo pedido éste tenga anexo un identificador válido de cliente. En forma similar, puede crear el trigger de modo que si intenta eliminar un cliente de la tabla correspondiente, verifique si hay todavía algún pedido anexado a ese cliente, y si lo hay, detener el proceso de eliminación. Los triggers no tienen parámetros y no se les puede invocar en forma explícita. Los triggers solo funcionan cuando se intenta una modificación de datos que es lo que hace accionar el trigger. También es posible anidar los triggers, en SQL 2000 se permiten hasta 16 niveles. Si se tiene una base de datos con las tablas Clientes, Pedidos y Cuentas por cobrar, donde un cliente puede realizar varios pedidos y cada cliente puede tener cuentas por cobrar, se. 18.

(29) Capítulo I. puede ejemplificar como los triggers anidados funcionan: Un trigger en su tabla de pedidos puede agregar una entrada a su tabla de cuentas por cobrar, que a su vez accionará un trigger para verificar si el cliente tiene cuentas por cobrar vencidas y notificárselo al usuario. Desde el punto de vista del desempeño, los triggers tienen una sobrecarga relativamente baja. La mayor parte del tiempo que emplea en su ejecución un trigger se utiliza en hacer referencia a otras tablas. Estas referencias pueden ser rápidas si las otras tablas están en memoria, o un poco más lentas si deben leerse desde el disco. Los triggers se consideran siempre como parte de la transacción. Si el trigger o cualquier otra parte de la transacción falla, ésta se deshace. Anteriormente, en DBMS como SQL Server 6.0, los triggers eran el único medio de imponer la integridad referencial. Ya desde SQL Server 7.0 se tiene ahora la capacidad de usar la integridad referencial declarativa (DRI), la cual hace innecesarios a los triggers para asegurar la integridad referencial y permite usarlos casi exclusivamente para imponer restricciones del negocio. Los triggers usan las tablas de inserciones y eliminaciones. Estas dos tablas contienen la misma estructura de la tabla base o "tabla del trigger" en donde se creó el trigger. Las tablas de inserciones y eliminaciones residen en RAM debido a que son tablas lógicas. Si se agrega un nuevo registro a la tabla base, el registro se grabará tanto en la tabla base misma como en la tabla de inserciones. Tener disponibles los valores en la tabla de inserciones le permite acceder a la información sin tener que crear variables que la contengan. Cuando un registro es eliminado, éste se almacena en la tabla de eliminaciones. Una actualización es muy similar a una eliminación y una posterior inserción. Si se actualiza un registro, el original se almacena en la tabla de eliminaciones y el registro modificado en la tabla base, así como en la tabla de inserciones.. 19.

(30) Capítulo I. Una tabla puede tener tantos triggers como desee de cualquiera de las tres acciones de trigger definidas: INSERT, UPDATE o DELETE. Cada una de estas acciones puede almacenarse en uno solo o en varios triggers. Si se almacenan en diferentes triggers, cada nombre de trigger debe ser único. Si se desea modificar un trigger debe eliminarse por completo y luego crearse otra vez o usar la instrucción ALTER TRIGGER. Los triggers se crean con la instrucción CREATE TRIGGER. También se aplican otras reglas a la creación de triggers. No se pueden crear triggers sobre vistas o tablas temporales. Sin embargo, sí pueden hacer referencia a vistas y tablas temporales. Los triggers no pueden devolver al usuario conjuntos de resultados. Por lo tanto, se debe tener cuidado al incluir instrucciones SELECT. Es una práctica común usar la cláusula IF EXISTS como parte de una instrucción SELECT en su código de trigger. Se pueden usar triggers para mantener la integridad a nivel de los datos y referencial, y encapsular reglas de negocios. Es posible encriptar los triggers en la tabla syscomments si se especifica la opción WITH ENCRYPTION. Las instrucciones WRITETEXT no activan triggers. WRITETEXT se usa para modificar datos de texto o imagen, y es una transacción no registrada. No se pueden usar en un trigger las siguientes instrucciones de SQL: todas las instrucciones CREATE, todas las instrucciones DROP, ALTER TABLE y ALTER DATABASE, TRUNCATE TABLE, GRANT y REVOKE, RECONFIGURE, LOAD DATABASE O TRANSACTION, UPDATE STATISTICS, SELECT INTO y todas las instrucciones DISK. Si se modifica un trigger con la instrucción ALTER TRIGGER, el trigger anterior será sustituido por completo por el nuevo. Si se elimina una tabla con triggers, se eliminarán éstos en forma automática.. 20.

(31) Capítulo I. I.7 Conclusiones Parciales. En este capítulo se ha brindado un marco teórico sobre las reglas de negocio tipo restricción. Se hizo un análisis sobre los tipos de integridad, haciendo especial referencia a las posiciones de Waymire sobre integridad referencial y también sobre el uso de los triggers en una base de datos. Esto proporciona un conocimiento básico sobre los conceptos que fundamenten este trabajo, y facilita la comprensión de las decisiones a tomar posteriormente.. 21.

(32) CAPÍTULO II.

(33) Capítulo II. CAPÍTULO II : ANÁLISIS DE LAS DIFERENTES OPERACIONES A REALIZAR SOBRE LOS DATOS DE LA BASE DE DATOS ANTE LA MODIFICACIÓN DE UNA REGLA DE NEGOCIO.. En este capítulo se analizarán las consideraciones a tener en cuenta para modificar una regla de negocio, al ocurrir un cambio en las políticas del negocio. A partir del patrón creado en (Pérez Alonso, 2008) con fundamento en los patrones de Morgan para expresar reglas de negocio, se estudian qué elementos del patrón pueden o no cambiar para considerar una modificación válida, y cuáles acciones se pueden realizar ante los datos que incumplan la regla modificada. Además se expone el diseño de los cambios a realizar en el software existente para reflejar las modificaciones que se tratan.. II.1 Análisis sobre la modificación de una regla de negocio. Para realizar un análisis exhaustivo de las posibles transformaciones a realizar en una regla de negocio, se asume la representación de estas en lenguaje técnico usando la notación Punto. (Pérez Alonso, 2008) Cuando una política del negocio se modifica o cambia, la regla asociada también debe modificarse. Para lograr la modificación de una regla, se tienen en cuenta ciertas consideraciones muy importantes: El identificador de la regla no puede ser modificado. El sujeto de la regla no se modifica. 23.

(34) Capítulo II. Estas limitaciones de no permitirse la modificación del sujeto y el identificador están dados porque, en caso de permitirlo se estaría refiriendo a una nueva regla y no a una modificación. EL identificador de la regla y el sujeto, identifican a la regla que se desea modificar. Para ejemplificar lo anteriormente expuesto se explican a continuación algunos ejemplos para mostrar detalladamente las causas que invalidan las propuestas de modificar el sujeto y el identificador de la regla a transformar; basados en la base de datos del negocio de transplante renal (Ver Anexo 1). Regla 1: Un paciente puede tener un examen físico con resultado mayor que 3 solo si su edad es mayor que 18 años. Esta regla en lenguaje técnico quedaría de la siguiente manera: RN#1 Un Paciente puede tener ExamenFisico.Resultado>3 solo si Paciente.Edad>18 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: ExamenFisico.Resultado>3 <Hecho>:Paciente.Edad>18 Ejemplo 1: Si la regla RN#1, la queremos modificar por la que expresa: Un Donante Potencial puede tener un examen físico con resultado mayor que 3 solo si su edad es mayor que 18 años. En lenguaje técnico: RN#1 DonantesPotenciales puede tener ExamenFisico.Resultado>3 solo si. 24.

(35) Capítulo II. DonantesPotenciales.Edad>18 <idRegla>: RN#1 <Sujeto>: DonantesPotenciales <Caracteristica>: ExamenFisico.Resultado>3 <Hecho>: DonantesPotenciales.Edad>18 Aquí no se estaría hablando de una modificación, ya que al pretender cambiar el sujeto de Paciente a DonantesPotenciales, la regla es nueva, ya que restringe a los Donantes Potenciales y no a los Pacientes. Tienen en común el identificador de la regla (RN#1); pero el sujeto es diferente. Para la regla que se quiere modificar el sujeto es Paciente; y para la que se quiere poner en su lugar, el sujeto es DonantesPotenciales. Por tanto no se estaría hablando de una modificación, sino de una nueva regla. Ejemplo 2: Otro caso sería si queremos modificar la regla RN#1 por la regla: RN#2 Un Paciente puede tener Edad >80 solo si HospitalOrigen.Nombre=HospitalViejo <idRegla>: RN#2 <Sujeto>: Paciente <Caracteristica>: Edad>80 <Hecho>: HospitalOrigen.Nombre=HospitalViejo Para este ejemplo tampoco se aceptaría como una modificación ya que tienen identificador diferente. Para la regla que se quiere modificar el identificador es RN#1; y para la regla que se quiere poner en el lugar de esta el identificador es RN#2. En este caso, si se aceptara la modificación, esta estaría considerando la regla 2 y no 1; por tanto RN#2 sería una nueva regla y no una actualización de la regla RN#1.. 25.

(36) Capítulo II. La modificación de una regla, se considera entonces como la transformación o cambio de los demás elementos de la misma: la característica y/o los hechos. Algunas modificaciones permitidas se ejemplifican a continuación: Ejemplo 3: Si se quiere cambiar la regla RN#1 por otra que plantea: Un paciente puede tener un examen físico con resultado mayor que 3 solo si su edad es mayor que 15 años. RN#1 Un Paciente puede tener ExamenFisico.Resultado>3 solo si Paciente.Edad>15 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: ExamenFisico.Resultado>3 <Hecho>:Paciente.Edad>15 Este caso si es una modificación de la regla; ya que el identificador es RN#1 y el sujeto es Paciente; es el mismo identificador y sujeto de la regla original. Aquí solamente cambia el hecho de la regla. Se tiene en cuenta, además que el hecho puede variar en el valor de comparación de la expresión o en la expresión completa. Ejemplo 4: RN#1 Un Paciente puede tener ExamenFisico.Resultado>3 solo si Paciente.TiempoTerapia<5 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: ExamenFisico.Resultado>3 <Hecho>: Paciente.TiempoTerapia<5. 26.

(37) Capítulo II. Lo mismo sucede con la característica de la regla, se puede mantener el hecho y modificar la misma. Sigamos con el mismo ejemplo, si se quiere modificar por la regla que plantea: Ejemplo 5: Un Paciente puede tener resultado de examen físico >5 solo si su edad es mayor que 18 años. RN#1 Un Paciente puede tener ExamenFisico.Resultado>5 solo si Paciente.Edad>18 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: ExamenFisico.Resultado>5 <Hecho>:Paciente.Edad>18 O bien se puede cambiar la característica completamente, es decir la expresión que la conforme. Ejemplo 6: RN#1 Un Paciente puede tener Paciente.TiempoTerapia>6 solo si Paciente.Edad>18 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: Paciente.TiempoTerapia>6 <Hecho>:Paciente.Edad>18 Otra consideración de modificación de regla de negocio muy importante es cuando se omite el hecho y se mantiene solamente la característica, el ejemplo queda de la siguiente manera: Ejemplo7: Un paciente no puede tener examen físico con resultado mayor que 3.. 27.

(38) Capítulo II. RN#1 Un Paciente no puede tener ExamenFisico.Resultado>3 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: ExamenFisico.Resultado>3 Además de omitir el hecho, se puede modificar la característica tanto su valor como la expresión. Ejemplo 8: RN#1 Un Paciente no puede tener Paciente.TiempoTerapia>5 <idRegla>: RN#1 <Sujeto>: Paciente <Caracteristica>: Paciente.TiempoTerapia>5 Por tanto, modificar una regla de negocio de tipo restricción significa: 1. Modificar la característica en valor o la expresión completa. 2. Modificar el hecho en valor o la expresión completa. 3. Eliminar el hecho y mantener o modificar la característica.. II.2 Acciones a tomar con la regla y los datos que incumplen la restricción. Cuando se aplica una regla de negocio, es porque se necesita que los datos cumplan dicha regla. Con el tiempo las restricciones asociadas al negocio pueden cambiar; y por tanto esto lleva a modificar una regla que está siendo utilizada por la base de datos. La modificación de una regla, puede o no entrar en contradicción con alguna de la información contenida en la base de datos. Si tenemos activa la regla que plantea: Un donante potencial no puede tener edad mayor que 75 años.. 28.

(39) Capítulo II. RN#2 DonantesPotenciales no puede tener DonantesPotenciales.Edad > 75 <idRegla>: RN#2 <Sujeto>: DonantesPotenciales <Caracteristica>: Edad>75 Ningún paciente que hay en la base de datos, tienen edad mayor que 75 años; por tanto cumplen dicha regla, que hasta el momento está siendo aplicada a la base de datos. Ejemplo 9: Si se quiere sustituir por la regla: RN#2 DonantesPotenciales no puede tener DonantesPotenciales.Edad > 70 <idRegla>: RN#2 <Sujeto>: DonantesPotenciales <Caracteristica>: Edad>70 Al cambiar la regla pudiesen existir en la base de datos DonantesPotenciales con más de 70 años, y ninguno tener más de 75. Esto puede ocasionar problemas, entonces se debe determinar qué hacer con aquellos donantes potenciales que tienen edad menor que 75, pero mayor que 70; pues las tuplas correspondientes a estos DonantesPotenciales violan la regla que se ha modificado Es necesario analizar, qué hacer con los datos que cumplen la restricción original de la regla que se propone transformar; pero que entran en contradicción con la modificación que se quiere implantar. Se analizan dos posibles variantes, que pueden aplicarse a la regla que se quiere modificar: 1. Aplicar siempre y a todos los datos. 2. Aplicar a partir de ahora. 29.

(40) Capítulo II. Para cada una de estas variantes se analizará que acción ejecutar con los datos que no cumplen la nueva actualización de la regla. Estas opciones se dejan a consideración del usuario; ya que es él quien conoce plenamente, cuáles son los objetivos de la información que está contenida en la base de datos.. II.2.1 Aplicar siempre y a todos los datos. Se puede aplicar la modificación de la regla siempre y a todos los datos involucrados en la base de datos, a los que la satisfacen y a los que no lo hacen. Aplicando esta variante, no se necesitaría la regla antes de la modificación; ya que cuando se quiera actualizar alguna información contenida en la base de datos, debe cumplir la regla después de ser modificada. Y los datos que serán insertados en el futuro, también deben cumplir la regla transformada. Existen varias vías para solucionar este problema, con respecto a que destino tomarán los datos, que no satisfacen la modificación de la regla:. II.2.1.1 Eliminar los datos que no cumplan con la regla modificada. Con esta opción, se eliminarán de la base de datos, todas aquellas tuplas de la tabla sujeto, que no satisfagan la nueva modificación de la regla. Para el ejemplo que estamos analizando; se eliminarían todos los pacientes que tienen edad comprendida entre 70 y 75 años. Esta es la vía más fácil y rápida que se puede seguir; pero corre el riesgo de ocasionar gran pérdida de información en la base de datos.. II.2.1.2 Mantener los datos que no cumplen con la regla modificada y no permitir actualización. Con esta opción se mantiene toda la información de la base de datos; y cuando el usuario quiera modificar uno de estos datos que no cumplen la restricción actual, se le negará el permiso para hacerlo; ya que puede cometer el error de introducir un dato que no es real o válido para esa instancia de sujeto. Cuando se inserte un nuevo dato este cumplirá la regla transformada, es decir la regla activa. Esta vía evita pérdida de información real e histórica en la base de datos.. 30.

(41) Capítulo II. II.2.1.3 Eliminar los datos seleccionados que no cumplen con la regla modificada y no permitir actualización. Esta opción da la posibilidad de seleccionar una o muchas tuplas para eliminar. Esta variante puede ser más efectiva que la anterior ya que el usuario tiene la posibilidad de seleccionar qué instancia de sujeto va a eliminar, es decir, él debe saber si hay alguno de estos que no cumplen objetivo en la base de datos; ya sea por antiguo, o por cualquier otro motivo.. II.2.1.4 Mantener los datos que no cumplen con la regla modificada y permitir actualización aplicando la regla activa. Esta vía deja todos los datos que no cumplen la regla modificada; y cuando se actualice uno de estos, estarán restringidos por la regla activa. Con esta variante, no se perderá ninguna información, ya que todos los datos quedarán como mismo están, pero si se modifica uno de estos que no satisface la regla actual, se obliga a que sí la cumpla; por tanto se puede cambiar el valor real de estas instancias del sujeto, en el negocio; esto puede traer inconsistencia en la información de la base de datos. Un ejemplo sería: Si se desea modificar algún campo de un Donante Potencial que tiene una edad entre 70 y 75 años, al hacerlo no permitirá dejarle su edad real; ya que hay una regla activa que plantea, que un donante potencial no puede tener más de 70 años y habrá que ponerle una edad menor que la que realmente tiene ese donante potencial.. II.2.1.5 Eliminar los datos seleccionados que no cumplen la regla modificada y al actualizar aplicar la regla activa. Permitirá eliminar los datos seleccionados por el usuario que incumplen la regla, y los restantes, se mantienen como están, con la posibilidad de modificarlos, pero cumpliendo la regla activa en ese momento.. 31.

(42) Capítulo II. Esta variante es bastante similar a la anterior, la diferencia está en que el usuario, tiene la posibilidad de seleccionar cuál de las tuplas va a eliminar, para quedarse solamente con las que estime conveniente para su negocio. La eficiencia de cada opción a tomar, depende de la base de datos y del negocio que se esté tratando; es por esto que no podemos generalizar cada caso.. II.2.2 Aplicar a partir de ahora. La regla actualizada se aplicará a partir del momento de la modificación; y a cualquier dato actualizado, se le aplica, la regla activa en el momento en que fue insertado. Esta variante, pudiera considerarse ser mucho más efectiva si existe la intención del negocio que el dato siempre sea coherente con las restricciones activas en el momento que se introdujo en la base de datos. Para desarrollar esta variante se debe guardar la regla antes de su actualización con otro identificador; ya que no puede haber dos reglas con el mismo identificador, pero de manera tal que se pueda conocer por cuál fue sustituida. Siguiendo con el ejemplo RN#2 que estamos trabajando quedaría de la siguiente manera: La regla RN#2 se guardaría como RN#2.1 RN#2.1 DonantesPotenciales no puede tener DonantesPotenciales.Edad > 75 <idRegla>: RN#2.1 <Sujeto>: DonantesPotenciales <Caracteristica>: Edad>75 Y la modificación si quedaría con el identificador original RN#2 DonantesPotenciales no puede tener DonantesPotenciales.Edad > 70 <idRegla>: RN#2 <Sujeto>: DonantesPotenciales <Caracteristica>: Edad>70. 32.

(43) Capítulo II. De esta manera podemos saber que la regla RN#2.1, fue sustituida por la regla RN#2. También se necesitaría guardar la fecha en que fue aplicada dicha regla; y la fecha en que se dejó de aplicar; para el momento en que se actualice alguno de los datos, estos cumplan la regla de negocio activa cuando fueron insertados, que no es la que en este momento está vigente. Se concibe que en el momento que los usuarios quieran ver las reglas que hay activas, no deben visualizar la regla por la cual se modificó (RN#2.1), sino la actualizada (RN#2), ya que la antigua regla solo servirá para que el sistema, haga referencia a esta solamente en el momento en que se modifique un dato que esté regido por ella.. II.3 Secuencia de acciones para transformar una regla de negocio tipo restricción. Para transformar o modificar una regla de negocio, se proponen llevar a cabo los siguientes pasos: Paso 1: Eliminar de la base de datos el(los) trigger(s) (el caso más común es un trigger) y la función correspondientes a esta regla original, en caso que esté activa. Paso 2: Borrar del repositorio de reglas el(los) trigger(s) y la función correspondientes a la regla, en caso que la misma esté desarrollada en el repositorio. Paso 3: Actualizar la regla en el repositorio con la nueva característica y/o hecho. Paso 4: Si existe algún dato que viole la nueva modificación, y el usuario del sistema desea eliminar alguno o todos: Realizar la eliminación. Paso 5: Desarrollar la regla en el repositorio, en caso de ser solicitado Paso 6: Activar la regla en la base de datos, si se indica esta opción.. 33.

(44) Capítulo II. Es válido expresar aquí los conceptos de Desarrollar Regla en el Repositorio y Activar la regla en la base de datos. Desarrollar Regla en el Repositorio consiste en guardar en el repositorio la implementación de los triggers y función. Los triggers son guardados en el campo TTriggers de la Regla, mientras que la implementación de la función queda guardada en el campo Funcion. Activar la regla en la base de datos necesita primeramente desarrollarla en el repositorio, e insertar los scripts correspondientes a los triggers y función en la base de datos, quedando restringido el negocio por la regla que ha sido activada.. II.4 Análisis de la nueva versión del Software “Editor Reglas de Restricción”. En la Figura II.1 se muestra el diagrama de casos de uso perteneciente a la primera versión del software Editor Reglas de Restricción. Mostrando tres casos de uso: Crear Nueva Regla, Desarrollar Regla y Activar Regla que incluyen un caso de uso en común llamado Compilar Regla, el cual incluye Compilar Característica y Compilar Hecho.. Figura II.1 Diagrama de casos de uso v1.0. Después de analizar este diagrama se decidió agregar un caso de uso llamado Modificar Regla, que al igual que los anteriores incluye el caso de uso Compilar Regla (Figura II.2).. 34.

(45) Capítulo II. Se implementa Modificar Regla siendo esta la herramienta de la nueva versión del software Editor Reglas de Restricción.. Figura II.2 Diagrama de casos de uso v1.1. Caso de Uso Modificar Regla Propósito Modificar una regla de negocio determinada. Descripción El usuario selecciona la opción que permite modificar una regla. Se muestra la interfaz Modificar Regla con el identificador y sujeto de la regla fijos, es decir sin la posibilidad de modificarlos, y aparecen de manera editable las características y los hechos. Permite modificar la regla en el repositorio y en la base de datos en caso de ser solicitada esta última operación. Precondiciones Debe existir una regla seleccionada.. 35.

(46) Capítulo II. Tabla de Eventos Flujo Básico Acción del Actor. Respuesta del sistema. 1- El usuario selecciona la opción Modificar Regla.. 2-Obtiene la regla seleccionada. Se divide en: identificador, sujeto, característica y hecho. Obtiene las entidades, atributos y operadores del negocio. 3-Muestra la interfaz MODIFICAR REGLA, con características y hechos de forma editable.. 4- Edita la modificación de la regla. 5- El usuario presiona el botón Sustituir.. 6- Compila la regla editada 7- Muestra mensaje de compilación. . Si compiló satisfactoriamente ir a la acción 8. . Si hay error en la compilación ir a la acción 4.. 8- Presionar botón activo Aceptar.. 9- Obtiene la cantidad de tuplas de la tabla sujeto que no cumplen la restricción especificada. 10 – Muestra interfaz GUARDAR REGLA donde se pide la confirmación de guardar la regla mostrando la cantidad de datos que no la cumplen. Y además se pide que seleccione cuál acción tomar con respecto a la activación y desarrollo de la regla.. 11- El usuario selecciona que hacer con la activación y desarrollo de la regla. Las posibles acciones son: .Desarrollar la regla en el repositorio. .Desarrollar la regla en el repositorio y activarla en la BD. . Guardar la regla en el repositorio. 12- Presiona botón Aceptar.. 13- Recorre el repositorio hasta encontrar la regla que se quiere modificar.. 36.

(47) Capítulo II. 14- Verificar si la regla está desarrollada o no. .Si la regla esta desarrollada ir a la acción 15. . Si la regla no está desarrollada ir a la acción 20. 15- Verifica si la regla está activa o no. . Si la regla está activa ir a la acción 16. . Si la regla no está activa ir a la acción 18. 16- Elimina de la BD el(los) trigger(s) correspondiente(s) a la regla que se quiere modificar. 17- Elimina de la BD la función correspondiente a la regla que se quiere modificar. 18- Borra del repositorio el(los) trigger(s) correspondiente(s) a la regla que se quiere modificar. 19- Borra del repositorio la función correspondiente a la regla que se quiere modificar. 20- Actualiza repositorio con la nueva característica y hechos. 21- Chequea la cantidad de datos que violan la regla. . Si hay 0 datos que incumplan la modificación de la regla entonces ir a la sección ‘Datos Satisfactorios’. . Si hay datos que incumplen la modificación de la regla, ir a la sección ‘Datos Insatisfactorios’.. Sección “Datos Satisfactorios “ 22- ir a la acción 52. 37.

(48) Capítulo II. 23- Muestra mensaje informando que se ha modificado satisfactoriamente la regla. 24- Presiona botón activo: Aceptar. 25- Cierra interfaz GUARDAR REGLA 26- Cierra interfaz MODIFICAR REGLA 27- Ir a la acción 1. Sección “Datos Insatisfactorios“ 22- Muestra interfaz TRABAJO CON DATOS 23- El usuario selecciona que destino tomarán los datos que no cumplen la modificación de la regla Las opciones son: - Eliminarlos todos. - Dejarlos como mismo están. - Seleccionar a eliminar. 24- Presiona el botón Aplicar.. 25- Realiza diferentes acciones en dependencia de la selección que hizo el usuario. . Si el usuario seleccionó Eliminarlos Todos ir a la acción 26. .Si el usuario seleccionó Dejarlos como mismo se encuentran ir a la acción 35 .Si el usuario seleccionó Seleccionar a Eliminar ir a la acción 41. 26- Muestra una interfaz con un mensaje de confirmación de ELIMINAR todos los datos que infringen la modificación de la regla.. 27- El usuario presiona el botón Aceptar.. 28- Elimina toda la información que viola la nueva regla. 29- Ir a la acción 52 (Desarrollo Activación) 30- Muestra mensaje, informando que se han eliminado todos los valores que incumplen la nueva regla modificada. 31- Presiona botón activo OK. 32- Cierra la interfaz TRABAJO CON DATOS. 38.

(49) Capítulo II. 33- Cierra la interfaz MODIFICAR REGLA. 34- Regresa a la acción 1 35- ir a la acción 52 36- Cierra la interfaz TRABAJO CON DATOS 37- Cierra la interfaz MODIFICAR REGLA 38- Muestra mensaje informando que se ha modificado satisfactoriamente la regla. 39- Presiona botón OK 40- Regresa a la acción 1 41- Muestra interfaz ELIMINAR TUPLAS donde aparecen las tuplas que violan la nueva restricción, con la opción de seleccionar una a una para ser eliminada. 42- Selecciona una tupla para eliminar. 43- Presiona botón Eliminar. 44- Desactiva botón cancelar, ir a la acción 47. 45- Selecciona una tupla para eliminar 46- Presiona botón Eliminar 47-. Elimina este valor en la BD en la tabla correspondiente. 48- Actualiza las tuplas en la interfaz 49- Muestra mensaje informando que se ha eliminado un valor en la tabla de la BD. 50- Presiona botón Aceptar. 51- Ir a la acción 45.. 39.

(50) Capítulo II. 52- Verifica que opción seleccionó el usuario en la interfaz GUARDAR REGLA. .Si el usuario seleccionó Desarrollar la regla en el repositorio o Desarrollar la regla en el repositorio y activarla en la base de datos, ir a la acción 53. . Si el usuario seleccionó Guardar la regla en el repositorio, ir a la acción 56 53- Desarrolla la regla en el repositorio. 54- .Si el usuario en la interfaz GUARDAR REGLA seleccionó Desarrollar la regla en el repositorio y activarla en la base de datos, ir a la acción 55 . En cualquier otro caso ir a la acción 56 55- Activa la regla en la base de datos. 56- Si hay 0 datos que incumplen la modificación de la regla, ir a la acción 23 de la sección Datos Satisfactorios - Si hay datos que incumplen la modificación de la regla, ir a la acción 57 57- Si el usuario, en la interfaz TRABAJO CON DATOS, seleccionó Eliminarlos todos, ir a la acción 30 . Si el usuario en la interfaz TRABAJO CON DATOS seleccionó Dejarlos como están, ir a la acción 36 .Si el usuario en la interfaz TRABAJO CON DATOS seleccionó Seleccionar a eliminar, ir a la acción 58 58- Ir a la acción 43a.3 Flujo Alterno 27a Botón Cancelar Acción del Actor. Respuesta del Sistema. 27a.1 Selecciona botón Cancelar. 27a.2 Cierra la interfaz del mensaje de confirmación de ELIMINAR todos los datos.. Flujo Alterno 42a No Selecciona. 40.

(51) Capítulo II. Acción del Actor. Respuesta del Sistema. 42a.1 El usuario no selecciona tupla alguna. 42a.2- Ir a la acción 43a.1 Flujo Alterno 42a2a Cancelar Acción del Actor. Respuesta del Sistema. 42a2a1- Ir a la acción 43b.1 Flujo Alterno 45a No Selecciona Acción del Actor. Respuesta del Sistema. 45a 1- El usuario no selecciona tupla alguna. 45a 2- ir a la acción 43a.1 Flujo Alterno 43a Botón Finalizar Acción del Actor. Respuesta del Sistema. 43a.1 El usuario presiona botón Finalizar. 43a.2 - Ir a la acción 52(Desarrollo Activación) 43a.3– Cierra interfaz ELIMINAR TUPLAS 43a.4 - Cierra interfaz MODIFICAR REGLA. 43a.5 - Regresa a la acción 1. Flujo Alterno 43b Botón Cancelar Acción del Actor. Respuesta del Sistema. 43b.1 El usuario presiona botón Cancelar.. 43b.2 Cierra interfaz ELIMINAR TUPLAS.. Flujo Alterno 46a Botón Finalizar Acción del Actor. Respuesta del Sistema. 41.