Solución al problema de la cardinalidad en la generación automática de reglas de negocio en bases de datos relacionales

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. Trabajo de Diploma. Título: Solución al problema de la cardinalidad en la generación automática de reglas de negocio en bases de datos relacionales. Autor: Alain Pereira Toledo. Tutores: MSc. Martha Beatriz Boggiano Castillo Lic. Alain Pérez Alonso.. Año 2009.

(2) Dictamen. Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. _________________________ Firma del autor Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. _________________________. _________________________. Firma del tutor. Firma del jefe del Laboratorio.

(3) Dedicatoria. A nuestro Señor Jesús, A mi madre y a mi padre, A mi abuela Adelfa, A mi hermana y A mis mansos sobrinos Lizandra y Leo..

(4) Agradecimientos. A Jesús, quien me regaló la paciencia de Job para llegar a feliz término, A mi tutora MSc. Martha Beatriz Boggiano Castillo y A mi también tutor Lic. Alain Pérez Alonso, quien me asesoró en momentos críticos, A todos los profesores que me formaron, A mis hermanos, por sus oraciones, y A todos los que de una forma u otra contribuyeron a la culminación de esta tesis..

(5) Pensamiento. Pues todo es tuyo, Y de lo recibido de tu mano te damos. 1ra de Crónicas 29:14b..

(6) Resumen. Las reglas gobiernan la vida, y en la vida contemporánea ejercen una influencia aún más especial. Las reglas son ahora la clave para cualquier negocio, término que deberá comprenderse más allá de su significado estrecho. Para la comunidad que lo entiende, la palabra clave sigue siendo reglas de negocio. El contexto que ocupa esta investigación sí que está muy relacionado con las reglas de negocio. Un proyecto del Departamento de Bases de Datos de la UCLV desarrolla un proyecto de administración de reglas de negocio para trasplante renal. Parte de él es la Aplicación para reglas de restricción en negocios, un editor y generador automático de restricciones hacia el SQL. La primera versión era incapaz de transformar restricciones con cualquier cardinalidad en sus interrelaciones constituyentes y, en especial, aquellas que contienen interrelaciones muchos a muchos. Se decidió entonces proponer una implementación que superara los límites encontrados. Se supuso que el catálogo de la base de datos sería la fuente de información suficiente para generar la regla en la tabla adecuada, y que la comunicación entre dicho recurso y la Aplicación podría implementarse con recursos ADO y procedimientos almacenados del sistema. Luego, se diseñó un método para, en base a la información del catálogo, transformar restricciones con cardinalidades muchos a muchos y generarlas en las tablas adecuadas. Las modificaciones implementadas validaron al método de resolución que, junto a la obtención de información a partir del catálogo, lograron transformar el subconjunto de restricciones ignoradas..

(7) Abstract. Life is ruled by rules, and they have a great influence in modern life. Rules are the key for every business nowadays, and it is a term that should be understood in a more open manner. For a community that understands it, the key word still being business rules. Context of this investigation is extremely related with the topic of business rules. A project for business rule management of a renal transplant system is being developed by Database Department of UCLV. An Application for Constraint Business Rules, an editor and an automatic generator of SQL constraints, is part of it. First version was unable of transforming a constraint with any cardinality between constitutive terms, specially, a many to many relationship. Therefore, it was necessary an implementation that could brake limitations. Database catalogue was a good candidate as a source of information for generating business rules on the right table. Also, it was suggested stored system procedures and ADO resources as a communication bridge between catalogue and Application. Then, it was designed a method for transforming constraints with many to many relationships and generating them on the right table, based on the catalogue information. Implemented modifications validated the solving method. They both, method and new way of getting information, could transform the ignored rules..

(8) Contenido. INTRODUCCIÓN............................................................................................................................................ 1 ANTECEDENTES .............................................................................................................................................. 1 PLANTEAMIENTO DEL PROBLEMA ................................................................................................................... 3 Objetivo general ....................................................................................................................................... 3 Objetivos específicos................................................................................................................................. 3 Preguntas de investigación ....................................................................................................................... 4 Justificación de la investigación ............................................................................................................... 4 HIPÓTESIS DE INVESTIGACIÓN ........................................................................................................................ 4 ESTRUCTURA DE LA INVESTIGACIÓN .............................................................................................................. 5 CAPÍTULO I MARCO TEÓRICO. DEL MODELO CONCEPTUAL AL MODELO RELACIONAL. IMPLICACIONES EN LA GENERACIÓN DE REGLAS DE NEGOCIO .................. 6 I.1 I.2 I.3 I.4 I.5 I.6. DEFINICIÓN DE REGLA DE NEGOCIO ...................................................................................................... 6 CATEGORÍAS DE REGLAS DE NEGOCIO ................................................................................................... 7 TIPOS DE REGLAS DE NEGOCIO .............................................................................................................. 7 EXPRESIÓN DE LAS REGLAS DE NEGOCIO............................................................................................... 8 REPRESENTACIÓN DE RESTRICCIONES ................................................................................................... 9 LENGUAJES DE ESPECIFICACIÓN DE RESTRICCIONES ........................................................................... 10 I.6.1 El lenguaje OCL ....................................................................................................................... 10 I.6.2 Lenguajes para reglas basados en XML................................................................................... 11 I.6.3 La navegación a través de Dot Notation .................................................................................. 12 I.7 LENGUAJES DE IMPLEMENTACIÓN DE RESTRICCIONES ........................................................................ 12 I.7.1 El lenguaje de implementación SQL......................................................................................... 13 I.8 EL PROBLEMA DE LA CARDINALIDAD EN EL MODELADO DE LOS DATOS CON ENFOQUE DEL NEGOCIO . 14 I.8.1 La notación IDEF1X ................................................................................................................ 14 I.8.2 El problema de la cardinalidad en la etapa del diseño conceptual.......................................... 15 I.8.3 El problema de la cardinalidad en la etapa de implementación .............................................. 16 I.8.4 Otras notaciones y el problema de la cardinalidad.................................................................. 17 I.9 EL CATÁLOGO DE LA BASE DE DATOS: FUENTE DE INFORMACIÓN ....................................................... 17 I.9.1 El catálogo. Definición............................................................................................................. 18 I.9.2 Para consultar el catálogo ....................................................................................................... 18 I.10 CONSIDERACIONES DEL CAPÍTULO ................................................................................................. 19 CAPÍTULO II. PROPUESTA DE IMPLEMENTACIÓN................................................................... 20. II.1 OBTENCIÓN DE LA INFORMACIÓN................................................................................................... 20 II.1.1 Información necesaria .............................................................................................................. 21 II.1.2 Fuente y medio de obtención de la información ....................................................................... 25 II.2 SOLUCIONES ARQUITECTÓNICAS .................................................................................................... 29 II.2.1 Soluciones MDA ....................................................................................................................... 29 II.2.2 Soluciones combinadas con MDA ............................................................................................ 31 II.2.3 Otras soluciones ....................................................................................................................... 32 II.3 MÉTODO PARA LA RESOLUCIÓN DEL PROBLEMA DE LA CARDINALIDAD ......................................... 34 II.3.1 Identificación de la resolution table ......................................................................................... 35.

(9) II.3.2 Reconstrucción de la regla ....................................................................................................... 36 II.3.3 Construcción de la lista de eventos .......................................................................................... 37 II.4 ARQUITECTURA PROPUESTA PARA EL EDITOR ................................................................................ 41 II.4.1 Generación de triggers y functions........................................................................................... 43 II.5 EJEMPLO. EL SISTEMA DE TRASPLANTE RENAL .............................................................................. 45 II.5.1 Ejemplo 1. Generación de una regla de negocio...................................................................... 47 II.5.2 Ejemplo 2. Generación de una regla de negocio...................................................................... 48 II.6 CONCLUSIONES DEL CAPÍTULO....................................................................................................... 50 CAPÍTULO III IMPLEMENTACIÓN DE LAS MODIFICACIONES A LA APLICACIÓN PARA REGLAS DE RESTRICCIÓN EN NEGOCIOS ......................................................................................... 52 III.1 IMPLEMENTACIÓN DE LA OBTENCIÓN DE INFORMACIÓN................................................................. 52 III.1.1 Métodos en respuesta a la obtención de información.......................................................... 53 III.1.2 Forma de implementación de los métodos para la obtención de información .................... 55 III.2 IMPLEMENTACIÓN DE LAS MODIFICACIONES AL COMPILADOR ....................................................... 58 III.2.1 Vista de casos de usos. Estructura y función ....................................................................... 59 III.2.2 Vista de implementación. Estructura y función ................................................................... 62 III.3 IMPLEMENTACIÓN DE LAS MODIFICACIONES AL EDITOR DE REGLAS .............................................. 67 III.3.1 Vista de casos de uso. Función ............................................................................................ 67 III.4 ACTUALIZACIÓN DEL MANUAL DE USUARIO ................................................................................... 69 III.4.1 Activar una regla ................................................................................................................. 70 III.5 CONCLUSIONES DEL CAPÍTULO....................................................................................................... 72 CONCLUSIONES .......................................................................................................................................... 73 RECOMENDACIONES ................................................................................................................................ 74 REFERENCIAS BIBLIOGRÁFICAS.......................................................................................................... 75 ANEXO 1. ESQUEMA CONCEPTUAL PARA LA BASE DE DATOS DE EJEMPLO ................... 77. ANEXO 2. DIAGRAMA DE COMPONENTES PARA LA APLICACIÓN........................................ 78. ANEXO 3 CÓDIGO FUENTE PARA EL MÉTODO DE RESOLUCIÓN DEL PROBLEMA DE LA CARDINALIDAD .......................................................................................................................................... 79.

(10) Figuras. FIGURA II-1. CASOS DE USO DEL EDITOR. ......................................................................................................... 21 FIGURA II-2. LAS DECLARACIONES DE REGLAS Y SUS INTERRELACIONES.......................................................... 22 FIGURA II-3. A) DIAGRAMA DE ESTADO PARA CREAR NUEVA REGLA. B) DIAGRAMA DE ESTADO PARA DESARROLLAR REGLA................................................................................................................................ 23 FIGURA II-4. REPRESENTACIÓN DE UNA RELACIÓN M:M EN UN MODELO RELACIONAL...................................... 24 FIGURA II-5. GRAFO DIRIGIDO QUE REPRESENTA LA ESTRUCTURA DE UN MODELO RELACIONAL...................... 25 FIGURA II-6. TRANSFORMACIÓN MDA UTILIZADA EN GENERACIÓN DE CÓDIGO............................................... 30 FIGURA II-7. TRANSFORMACIÓN DE MODELOS UML/OCL HACIA BASES DE DATOS RELACIONALES................. 31 FIGURA II-8. SECUENCIA DE INSERCIÓN EN UNA INTERRELACIÓN M:M.............................................................. 38 FIGURA II-9. SECUENCIA DE INSERCIÓN EN UNA INTERRELACIÓN CUALQUIERA ................................................ 39 FIGURA II-10. PROPUESTA DE ARQUITECTURA PARA EL EDITOR ....................................................................... 42 FIGURA II-11. SECCIÓN DE LA BASE DE DATOS DE EJEMPLO CON LA ADICIÓN SEÑALADA ................................. 46 FIGURA III-1. INTERACCIÓN ENTRE LOS DIAGRAMAS DEL EDITOR Y EL COMPILADOR....................................... 53 FIGURA III-2. DIAGRAMA DE CASOS DE USO DEL COMPILADOR......................................................................... 59 FIGURA III-3. DIAGRAMA DE ESTADOS PARA EL CASO DE USO COMPILAR REGLA. ............................................. 60 FIGURA III-4. DIAGRAMA DE ACTIVIDADES PARA EL CASO DE USO COMPILAR REGLA. ...................................... 61 FIGURA III-5. DIAGRAMA DE COMPONENTES DEL COMPILADOR........................................................................ 63 FIGURA III-6. DIAGRAMA DE ESTADOS PARA EL CASO DE USO ACTIVAR REGLA EN LA VERSIÓN ANTERIOR DEL EDITOR. ................................................................................................................................................... 68 FIGURA III-7. DIAGRAMA DE ESTADOS PARA EL CASO DE USO ACTIVAR REGLA.................................................. 69 FIGURA III-8. PANTALLA INICIAL DEL EDITOR DE REGLAS................................................................................ 70 FIGURA III-9. PRIMER PASO PARA ACTIVAR UNA REGLA. COMPILAR LA REGLA. ............................................... 71 FIGURA III-10. VENTANA DE INFORMACIÓN SOBRE EL RESULTADO DE LA COMPILACIÓN. ................................ 71 FIGURA III-11. SEGUNDO PASO PARA ACTIVAR UNA REGLA. ACTIVARLA PROPIAMENTE. ................................. 71.

(11) Tablas. TABLA II-1. COMPONENTES DBGO DE ADO. .................................................................................................... 29 TABLA II-2. REGLA #1. GENERACIÓN DE CÓDIGO A PARTIR DEL LENGUAJE DE ESPECIFICACIÓN....................... 47 TABLA II-3. REGLA #2. GENERACIÓN DE CÓDIGO A PARTIR DEL LENGUAJE DE ESPECIFICACIÓN....................... 49 TABLA III-1. RELACIÓN ENTRE LA INFORMACIÓN NECESARIA, MÉTODOS QUE LA IMPLEMENTAN Y SU DESCRIPCIÓN. .......................................................................................................................................... 54 TABLA III-2. RELACIÓN ENTRE LA INFORMACIÓN NECESARIA EN FUNCIÓN DEL PROBLEMA DE LA CARDINALIDAD, MÉTODOS QUE LA IMPLEMENTAN Y SU DESCRIPCIÓN. .................................................... 55 TABLA III-3. MÉTODOS DEL MÓDULO UMLCLASSDIAGRAM2 Y SU FORMA DE IMPLEMENTACIÓN. .................. 56 TABLA III-4. RELACIÓN ENTRE INFORMACIÓN NECESARIA Y PROCEDIMIENTOS ALMACENADOS QUE LA PROVEEN.................................................................................................................................................. 57 TABLA III-5. RELACIÓN ENTRE ACTIVIDADES DE LA COMPILACIÓN Y PROCEDIMIENTOS EN EL MÓDULO UCOMPASIST.PAS. .................................................................................................................................... 64.

(12) Introducción. Antecedentes Reglas del negocio o business rules, que es el término anglosajón, se oye por vez primera en la voz de Daniel Appleton, por medio de su artículo The Missing Link. Desde ese 1984, ya hace más de dos décadas, se ha escrito bastante y desde enfoques diversos sobre este “enlace perdido”. En él se reclamaba la formalización de los términos del negocio. Pronto, los científicos de la computación se dieron cuenta de la utilidad que sostenía aplicar recursos de bases de datos para recoger las reglas, tales como la modelación conceptual y recursos de restricción en las bases de datos relacionales. Solo que tales recursos para captar las reglas estaban diluidos en la lógica de implementación. Así, se ideó la utilización de triggers, suerte de artificio del lenguaje procedural del SQL, para implementar la aplicación de reglas del negocio más complejas y cambiantes. Algunos autores dan fe de ello (Morgan, 2002, Fishman, 2003b). Otros avances establecieron la necesidad de separar un subconjunto del dominio de reglas del negocio, aquellas más complejas y cambiantes, de la estructura de la base de datos. Ya existía un repositorio de reglas y, por consiguiente, se adicionaba el trabajo de editarlas y transformarlas para exportarlas a la base de datos y así velar por la integridad de los datos (Morgan, 2002). Enfoques alternativos se manejan a la hora de la transformación y de la creación de plataformas (Casallas et al., 2005, Demuth, 2004, Tedjasukmana, 2006, Zimbrão et al., 2003). Herramientas como el Dresden OCL Toolkit, poseen motores de transformación de reglas de negocio en código de consulta o DQL, del inglés Data Query Language. Pero a diferencia, la transformación se centra en generar de manera automática las reglas concebidas de forma conceptual. Más que concebir un editor de reglas, se construye una plataforma de generación de código para consultas de integridad, para permitir la Ingeniería. 1.

(13) de Integridad Dirigida por Modelos o MDIE, del inglés Model-Driven Integrity Engineering (Heidenreich et al., 2007). Ambos enfoques necesitan transformar reglas que se expresan con cierto nivel de abstracción, las cuales son elaboradas sobre un esquema conceptual. Las diferencias entre el modelo conceptual, tanto de la base de datos como de las reglas del negocio, y el modelo relacional, enfrentan problemas con respecto a los tipos de interrelaciones y a la persistencia de los conceptos que intervienen en el negocio. Parte de este problema es captado por una modelación de muy alto nivel de abstracción y de allí, una parte es asimilada por los recursos para restricciones de las bases relacionales —dígase restricciones de tabla y de columna, integridad referencial, tipos de datos–, y la otra no encontraría cabida si no fuera gracias a la generación de reglas en lenguaje procedural del SQL (Fishman, 2003b, Zimbrão et al., 2003). Pero aun este último método, paga por las diferencias entre la representación conceptual y la relacional. Cuando surgen interrelaciones muchos a muchos, entonces para el esquema relacional se crean tablas auxiliares desconocidas para la representación conceptual (Davidson et al., 2006, Speelpenning et al., 1999). Como parte de un proyecto del Departamento de Bases de Datos del Centro de Estudios Informáticos (CEI) de la UCLV, se realizó en el año 2008 un trabajo de diploma cuyo resultado desembocó en una Aplicación para reglas de restricción en negocios, así también intitulado por el licenciado Alain Pérez Alonso. El motor para la generación de reglas de negocio tipo restricción, es capaz de transformar aquellas reglas que implican interrelaciones del esquema conceptual con una cardinalidad o de uno a muchos o de muchos a uno —y en ese estricto orden– cuando se ven involucradas más de una entidad del negocio: [1:m, 1:m, ...] o [m:1, m:1, ...] (Pérez Alonso, 2008). La Aplicación tropezó entonces con el aspecto de las cardinalidades muchos a muchos, ignoradas en la transformación. Aunque la Aplicación utiliza los nombres de tablas de las bases de datos para elaborar nuevas reglas, se asume que tales nombres son equivalentes de los términos del negocio. Ello provoca que una regla, aunque en la práctica esté constituida por nombres de tablas, sea vista como construida sobre un modelo conceptual. Aquí hace su entrada el problema de la cardinalidad muchos a muchos, cuando de la regla a ser transformada se desconoce la tabla auxiliar que formará parte de la regla generada. La cardinalidad muchos. 2.

(14) a muchos presenta problemas en dos ámbitos. Como muchas otras, este tipo de cardinalidad no es considerada en la Aplicación. Además, crea efectos colaterales durante la transformación de reglas que la contienen, a causa de la diferencia entre su naturaleza conceptual y su implementación relacional. La idea de la presente investigación asume el trabajo inconcluso y propone superar las barreras encontradas. Y ello implica reconocer que la Aplicación para reglas de restricción en negocios no es capaz de transformar reglas de negocio tipo restricción hacia bases de datos relacionales, si involucran, en general, cualquier tipo de cardinalidad en el esquema conceptual. Así nace el problema y, luego, la solución.. Planteamiento del problema Objetivo general Proponer una implementación para la generación automatizada de reglas de negocio tipo restricción, con origen en el modelo conceptual, con pretensiones de superar las limitaciones hasta ahora existentes sobre la cardinalidad en las interrelaciones involucradas en la regla, a los fines de ampliar las posibilidades del uso de la Aplicación para reglas de restricción en negocios.. Objetivos específicos 1. Describir diferentes formas en que se generan reglas del negocio a partir de lenguajes declarativos para manejar restricciones. 2. Elaborar un método que sea capaz de revelar el tipo de cardinalidad en una interrelación del esquema conceptual del negocio, a través de recursos de bases de datos, y a la vez permita la generación automática de reglas con cualquier cardinalidad en las interrelaciones. 3. Implementar la generación de reglas del negocio tipo restricción con cardinalidad arbitraria en las interrelaciones usando el método elaborado, que utilice los recursos de bases de datos estudiados.. 3.

(15) Preguntas de investigación •. ¿Qué recursos se pueden utilizar a la hora de resolver dinámicamente los tipos de interrelación del esquema conceptual, desde el cual se originó la base de datos del negocio?. •. ¿Cómo implementar la comunicación entre el recurso de base de datos y la Aplicación para luego generar de manera adecuada reglas con cualquier cardinalidad en las interrelaciones?. Justificación de la investigación En esfuerzo conjunto, un equipo del Departamento de Base de Datos del CEI, mueve un proyecto para administrar reglas de negocio para trasplante renal. Con ello se eligió diseñar una herramienta independiente de la base de datos, arquitectura seleccionada entre otras muchas (Bajec et al., 2000). Pero el elemento clave es la generación automática de las reglas en la base de datos del negocio, proceso que evita la demorada metodología para el diseño e implementación más usual en lo que respecta a las tales. Si es ello la pieza principal, entonces es de desear que el proceso de generación sea lo más completo posible. Deberá satisfacer las demandas del negocio. Si se tienen en cuenta las limitaciones reales de la Aplicación creada por Alain Pérez Alonso (2008), entonces se podrá valorar el aporte de esta investigación en su justa medida. En lo adelante, ya no se trabajará sobre una base de datos de ejemplo con un número de tipos de interrelaciones disminuido. Tanto las reglas del negocio, como el modelo sobre el cual se imponen, son de mayor grado de complejidad, de ahí la necesidad de superar la frontera práctica en cuanto al dominio de resolución de la Aplicación. Esta investigación no se ciñe en proponer una vía de implementación que responda al problema planteado, sino que intenta, de hecho, llevarla a cabo por medio de una implementación concreta con fines de validarla.. Hipótesis de investigación Vistos estos acercamientos preliminares al problema y luego de haber hecho la revisión bibliográfica, solo resta plantear formalmente la hipótesis investigativa que se ha ido bosquejando. Sobre el qué información es necesaria, para qué obtenerla y el cómo lograrlo para generar reglas de negocio a partir de relaciones con cardinalidad m:m se tiene:. 4.

(16) El catálogo, recurso de las bases de datos, contiene información suficiente para generar en la tabla adecuada reglas del negocio que impliquen cualquier tipo de interrelación en el esquema conceptual y la comunicación entre dicho recurso y la Aplicación puede ser implementada mediante recursos de ADO y procedimientos almacenados del sistema.. Estructura de la investigación En repuesta a la meta que se pretende alcanzar, se ha diseñado la estructura de la investigación en tres capítulos. El primero de ellos recoge la base teórica sobre la cual está montada la Aplicación. Algunas definiciones y conceptos generales sobre las reglas de negocio y su transformación hacia bases de datos relacionales, son tratadas. También se introducen los fundamentos del problema de la cardinalidad y los acercamientos iniciales a conceptos relacionados con su solución. En el segundo capítulo, se propone el método y la arquitectura que debiera seguir una implementación para solucionar las limitaciones encontradas en la Aplicación. El debate sobre la obtención de información para la resolución del problema de la cardinalidad capta el interés al inicio de esta sección. Por último se muestra cómo funciona el método desarrollado a través de algunos ejemplos. El tercer capítulo y final, recoge la documentación y explicación de los cambios implementados en la Aplicación para reglas de restricción en negocios, construida inicialmente por (Pérez Alonso, 2008). Finalmente se encuentran las conclusiones y recomendaciones. Estas últimas, nacidas de aquellos deseos iniciales que, por razones que los superan incluso antes de la investigación, no llegaron a ser. Anexadas a la investigación, se encontrará el esquema conceptual de una base de datos que sirve de ejemplo, el diagrama de componentes que conforma la Aplicación y el código que implementa el método para la resolución del problema de la cardinalidad.. 5.

(17) Capítulo I Marco teórico. Del modelo conceptual al modelo relacional. Implicaciones en la generación de reglas de negocio. La Aplicación desarrollada por Alain Pérez Alonso en su trabajo de diploma, presenta limitaciones en cuanto al tipo de interrelaciones que es capaz de soportar en la generación de reglas del negocio. A partir de tal limitante, nace la presente investigación. Ello demanda explicar los rudimentos teóricos que sostienen tal aplicación, y más en profundidad aquellos que se relacionan con las implicaciones de generar reglas de negocio para base de datos relacionales a partir de un modelo conceptual. Hacia allí se orienta este bosquejo inicial.. I.1 Definición de regla de negocio Como sucede con todas las definiciones, no existe solo una. De acuerdo a cada autor se enfatiza en uno u otro aspecto, no obstante existe un consenso bastante generalizado. De acuerdo a (Hay et al., 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” 1 . Pero esta definición es todavía poco precisa y quizás su horma es demasiado ancha. Más adelante, dice: 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. Esto es, lo que preocupa es cuándo los datos debieran o no ser grabados por el sistema de información.. 1. Traducciones propias a partir de los textos presentes en: HAY, D., HEALY, K. A. & HALL, J. (2000) Defining Business Rules. What Are They Really? , Business Rules Group... 6.

(18) 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 (Hay et al., 2000). Una definición similar puede ser encontrada en (Morgan, 2002) en su capítulo 3.. I.2 Categorías de reglas de negocio En (Hay et al., 2000) se asegura que las reglas de negocio pueden caer en alguna de las cuatro categorías siguientes: •. Términos del negocio: un término es una palabra o frase que tiene un significado específico para el negocio. Los términos de interés son los términos del negocio y los términos comunes. Un término del negocio es una palabra o frase que tiene un significado específico para el negocio en un contexto determinado. Un término del negocio debe ser usado en al menos un contexto, y cada contexto debe ser el uso de algún término del negocio. Los términos comunes son palabras en el lenguaje cotidiano, que usan su significado comúnmente aceptado.. •. Hechos: un hecho declara una asociación entre dos o más términos. Es decir, un hecho expresa una relación entre términos. Nótese que un hecho no está limitado a un par de términos, sino que a menudo se expresa a través de más de dos.. •. Restricciones 2 : es una sentencia que concierne a algún aspecto dinámico del negocio. Especifica una restricción sobre el resultado que las acciones pueden producir. Cada empresa restringe su comportamiento de alguna forma y esto está íntimamente relacionado con la restricción de qué datos deben o no ser actualizados. Prevenir un registro es prevenir que una acción se lleve a cabo.. •. Derivaciones 3 : es un algoritmo usado para calcular o inferir un hecho derivado, el cual se define como un hecho cuyo valor es inferido o matemáticamente calculado a partir de términos, hechos, otras derivaciones o afirmaciones de acción.. I.3 Tipos de reglas de negocio Aunque existen varias clasificaciones, aquí será referida la expuesta en (Hay et al., 2000):. 2 3. También afirmaciones de acción, del inglés action assertions. Del inglés derivations.. 7.

(19) •. Afirmaciones estructurales 4 : es una declaración de que algo significativo para el negocio existe como un concepto de interés o como una relación con alguna otra cosa del negocio. Los términos y hechos son los que conforman este tipo de regla. Por lo general, estas reglas son captadas por medio de un modelo conceptual.. •. Afirmaciones acción: es una declaración de restricción o condición, que limita o controla las acciones de una empresa. Se les puede llamar restricciones, al igual que a la categoría, incluso la diferencia en la definición es solo una cuestión de matiz. Las restricciones se describen de manera no procedural, en términos de otras reglas de negocio atómicas.. •. Derivaciones: es una declaración de un conocimiento que es derivado de otro conocimiento en el negocio.. Clasificar es un trabajo de sistematización que ayuda mucho en la etapa de análisis durante el modelado de las reglas de negocio. Conocer con qué tipo de regla se está lidiando provee de mayor definición de sus características y, por tanto, de cómo expresarlas con mayor precisión.. I.4 Expresión de las reglas de negocio No todos los autores coinciden, quizás por razón de caer o no en detalles, en las formas en que las reglas de negocio pueden ser expresadas. No obstante, en lo que todos coinciden es en que, en efecto, las reglas de negocio se expresan de diferentes maneras. Como es de esperarse, la expresión comienza por el lenguaje natural. Ello también es un punto de coincidencia. Según (Von Halle, 2002) son cuatro las formas de expresar las reglas de negocio, cada una para una audiencia diferente: 1. Conversación informal del negocio 2. Versión en lenguaje natural 3. Versión en lenguaje de especificación de reglas 4. Versión en lenguaje de implementación de reglas Una regla comienza su vida en la conversación informal de las personas del negocio, luego se realiza una versión más disciplinada en lenguaje natural cuya audiencia es la comunidad. 4. Del inglés structural assertion.. 8.

(20) del negocio. El lenguaje natural presenta algunas insuficiencias, tales como falta de precisión y redundancia, por lo que se requiere que se expresen las reglas en un lenguaje que ya reúne todas las cualidades requeridas. Tal lenguaje es el de especificación de reglas. Es declarativo y disciplinado, y está dirigido tanto al personal del negocio como al técnico. Pero este lenguaje solo nos dice qué acometerse según la regla, no cómo. Por ello las reglas se mudan del lenguaje de especificación al lenguaje de implementación, el cual tiene todo el potencial para ser ejecutado. En (Morgan, 2002), se distinguen solo tres formas de expresión de reglas de negocio: 1. Informal: representación en lenguaje natural dentro de una rango limitado de patrones. 2. Técnico: combina referencias a datos estructurados, operadores y lenguaje natural controlado. 3. Formal: proporciona sentencias conforme a una sintaxis definida con propiedades matemáticas particulares. Ha de notarse algunas similitudes entre estos dos criterios expuestos. Aunque la investigación desarrollada por (Pérez Alonso, 2008) utiliza la clasificación de Tony Morgan, se ha creído conveniente utilizar la primera clasificación. Es mucho más clara, según criterio propio, con respecto a los estados de desarrollo de un sistema para el manejo de reglas de negocio.. I.5 Representación de restricciones Los modelos conceptuales pueden representar muchos tipos de reglas de negocio. Pero existen algunas que por su naturaleza o complejidad, no deben o no pueden ser representadas a través de diagramas (Speelpenning et al., 1999, Fishman, 2003b). Por ello, podría diferenciarse las reglas que pueden ser modeladas, de las que no, y luego mencionar los recursos de las bases de datos relacionales que permiten expresar ambos grupos. No obstante, existen tentativas para crear lenguajes gráficos de representación de restricciones que no pueden ser capturadas por los modelos de la estructura del negocio, tal es la intención de (Ivanov, 2004). Pero si se deja a un lado las buenas intenciones, lo más común es la expresión de tal tipo de reglas de negocio a través de lenguajes declarativos de representación de restricciones, o al menos este es el clamor de algunos autores (Zimbrão et al., 2003, Fishman, 2003a).. 9.

(21) I.6 Lenguajes de especificación de restricciones Varios son los lenguajes declarativos ya creados para expresar las reglas del negocio. Estos lenguajes recogen los conceptos del negocio y los convierten en expresiones más o menos inteligibles para un especialista técnico. Por ello, su función se limita a crear un punto intermedio de expresión de las reglas del negocio; pues es el lenguaje natural, y no el técnico o el formal, el objetivo en la definición de las reglas. El propietario del negocio no puede lidiar con tal tipo de expresión, pero al diseñador se le humaniza el trabajo (Morgan, 2002).. I.6.1 El lenguaje OCL El OCL (Object Constraint Language), facilidad poco conocida del UML, ha crecido gradualmente en importancia en el campo de la representación de restricciones en aplicaciones reales. Aunque (Morgan, 2002) minimiza este aspecto, ya existen varias herramientas que utilizan el OCL para la representación de restricciones —herramientas CASE, sobre todo– (Invernizzi and Santos, 2004), y en la transformación de reglas del negocio en base de datos relacionales (Zimbrão et al., 2003, Demuth, 2004, Tedjasukmana, 2006). Es de destacar no la herramienta, sino el paquete de herramientas desarrollado por la Universidad de Dresden, denominado OCL Toolkit (Demuth, 2004, Heidenreich et al., 2007, Konermann, 2005). Esta herramienta y sus paradigmas serán analizados en capítulos posteriores. Pese a la opinión de Tony Morgan (2002), el OCL se creó para llenar un vacío entre las capacidades de modelador del negocio o sistema, y la complejidad de los lenguajes formales. El OCL es fácil de escribir y fácil de leer. A diferencia del lenguaje natural, no es ambiguo. Es puramente un lenguaje declarativo, por lo cual no tiene efectos colaterales. Cuando una expresión en OCL es evaluada, el estado del sistema no cambia y, no obstante, puede ser usada para describir un cambio de estado. Hay que notar de igual manera, que el OCL desconoce la forma de implementación de las restricciones que especifica, pues es un lenguaje para el modelado (Object Management Group, 1999). El OCL puede ser usado con varios propósitos. Según (Object Management Group, 1999), algunos de ellos son: •. Especificación de invariants —regla tipo restricción, según OCL– para clases y tipos del modelo de clases.. 10.

(22) •. Como lenguaje de navegación.. •. Especificación de restricciones en operaciones.. Como se puede fácilmente notar el OCL, como lenguaje de especificación de reglas, es una joya para el desarrollo de sistemas con enfoque de negocio. Igualmente bondadoso es el hecho de que el Object Management Group publica periódicamente las especificaciones para OCL y con ellas, la gramática íntegra para el posterior desarrollo de un analizador sintáctico. Por ello, su utilización en la generación de reglas tipo restricción en bases de datos, tema del trabajo que antecede al presente, no debiera permanecer tan lejos. Pero tal análisis viola las expectativas al alcance de este trabajo de diploma.. I.6.2 Lenguajes para reglas basados en XML A diferencia del OCL, los lenguajes para reglas basados en XML, están más enfocados en el concepto reactivo de las bases de datos activas. Cada sintaxis descrita por un esquema o un DTD del XML para tales lenguajes, describe una acción que, bajo ciertas condiciones cumplidas, produjo cierto evento en el sistema (Daum and Merten, 2003). Esto es básicamente lo que en el campo de las bases de datos activas se ha dado en llamar como ECA rules 5 (Paton and Díaz, 1999). Otro rasgo distintivo proviene del objetivo que persigue este enfoque. Más allá de expresar de manera más inteligible y sin ambigüedades, los lenguajes para reglas basados en XML responden a la necesidad de separar los datos y la estructura del modelo del negocio, de las reglas que los rigen. Con tal bondad en mente, las reglas pueden ser guardadas aparte de los datos y, por tanto, fácilmente administradas. La aplicación desarrollada por (Pérez Alonso, 2008), posee un repositorio para la administración de reglas. El enfoque de su repositorio parte en gran medida del propuesto por (Morgan, 2002). Aunque tiene una estructura en XML, no es lo que se llamaría un estándar. Sería útil la adopción de algunas de las especificaciones salidas del esfuerzo de comunidades de desarrollo reconocidas, pues la difusión debe ser más amplia que el modelo teórico de Morgan. Esto último, no obstante, está por comprobarse y sobrepasa los objetivos del presente trabajo. Como de interés para futuras investigaciones, se mencionan algunos de estos lenguajes: 5. ECA son las letras iniciales de Event, Action y Condition; las tres partes de una regla según se define en las bases de datos activas.. 11.

(23) •. BRML: Business Rules Markup Language.. •. RuleML: Rule Markup Language.. •. SRML: Simple Rule Markup Language.. Estas referencias pueden encontrarse en la obra de (Daum and Merten, 2003), con breves descripciones e indicaciones sobre dónde encontrar más.. I.6.3 La navegación a través de Dot Notation La notación punto —del inglés Dot Notation– es un estilo más que un lenguaje formal. La programación orientada a objetos, por ejemplo, la utiliza en la cualificación de los objetos. En (Morgan, 2002) se propone el uso de tal notación para eliminar la ambigüedad del lenguaje natural a la hora de expresar las reglas del negocio. También, según lo prescrito por este autor, debe ayudar en la navegación a través de las clases del modelo del negocio. Ello deriva en una mejor claridad en la expresión de reglas más complejas 6 . La aplicación desarrollada por (Pérez Alonso, 2008) recoge este enfoque, por ello la continua referencia al libro de Tony Morgan, Business Rules and Information Systems: Aligning IT with Business Goals.. I.7 Lenguajes de implementación de restricciones Para implementar restricciones se reconocen varios lenguajes según (Morgan, 2002). Ellos encuentran cabida, aunque sin pretensión de ser exhaustivos, en algunas de las clases siguientes: •. Lenguajes de programación de alto nivel: es la forma más común de implementación de reglas de negocio. Las construcciones condicionales y los ciclos pueden ser usados con este fin.. •. Scripts: como el JavaScript, es un paso adelante en el manejo de las reglas, pues las separa en scripts. El uso del script se ha tornado familiar en el desarrollo de páginas webs.. •. SQL: es un lenguaje para bases de datos relacionales. Tanto el estándar como las diferentes implementaciones propietarias, implementan recursos para el manejo de reglas de negocio de diferentes tipos. Algunos de estos recursos son:. 6. ¿No eran estos y muchos más los objetivos del OCL?. 12.

(24) o Constraints: están orientadas a restringir el valor de los datos con el objetivo de mantener la integridad referencial. o Stored procedures: son los procedimientos almacenados o módulo de código procedural. Cubren la funcionalidad de una regla de negocio de una manera muy similar a como se utiliza el script. o Triggers: un trigger o desencadenador, es un tipo especial de procedimiento almacenado. El procedimiento almacenado es invocado explícitamente, en cambio el trigger se ejecuta automáticamente cuando ocurre cierto condición es detectada. Pero no se ejecuta bajo cualquier circunstancia, sino que está atado a un evento en una tabla específica. Aunque son muchos los lenguajes, se pondrá especial atención al SQL. Téngase en cuenta que la aplicación sujeta a modificaciones en esta investigación, automatiza la generación restricciones hacia una base de datos relacional.. I.7.1 El lenguaje de implementación SQL Varios son, según se ha visto, los mecanismos y recursos del SQL y las bases de datos para capturar las diferentes reglas del negocio. No obstante, la aplicación desarrollada por (Pérez Alonso, 2008) solo utiliza los triggers. En su reporte anota cómo las restricciones de una columna son más eficientes si se implementan con un check constraint, pero no las materializa en la aplicación. La presente investigación tampoco pretende hacerse eco de tal recomendación, por lo que solo se abordará el trigger. Unos de los problemas que acarrea la implementación (ver epígrafe 1.8.3) de interrelaciones m:m entre los términos de las reglas, es la aparente indeterminación de dónde ocurre el evento que desencadena el trigger. De la misma forma tampoco la aplicación actual es capaz de elaborar triggers y functions, que respondan a cardinalidades en las interrelaciones de los términos, diferentes a los ya especificados por (Pérez Alonso, 2008). A saber: interrelaciones consecutivas [1:m, 1:m, ...] y las [m:1, m:1, ...] Los triggers son entonces el objeto de exposición para un mejor entendimiento en el posterior análisis y solución del problema. Aunque se ha mencionado en qué consiste un trigger, es de gran ayuda contar con la definición formal. En (Microsoft SQL Server, 2004) se expresa como:. 13.

(25) […] una clase especial de procedimiento almacenado que se define para que se ejecute automáticamente cuando se emita una instrucción UPDATE, INSERT o DELETE en una tabla o una vista. Los triggers amplían la lógica de comprobación de integridad de restricciones. Son utilizados para implementar aquellas restricciones que no pueden ser captadas por otros recursos de las bases de datos. Como se ha mencionado, los triggers se crean en tablas o vistas. Parte de la sintaxis de la creación es la siguiente: CREATE TRIGGER trigger_name ON { table | view } Según se aprecia, es obligatorio especificar el lugar donde ocurre el evento, lo cual es uno de los objetos de análisis. Nótese otra vez que este es uno de los problemas que acarrea las interrelaciones m:m. Abordar otros elementos sintácticos es innecesario en relación con los objetivos que persigue la presente investigación.. I.8 El problema de la cardinalidad en el modelado de los datos con enfoque del negocio No es el propósito resumir los diferentes métodos y recursos de modelado que, hasta el momento, son utilizados en empresas y medios científicos. Tan solo se quiere mostrar, a partir de los recursos de modelado conceptual más populares, cómo surge el problema de la cardinalidad; y, a fin de cuentas, describir en qué consiste el mencionado problema. Con anterioridad se ha apuntado sobre las formas o niveles en que las políticas y reglas del negocio son recogidas. Con generalidad, se llegó a la conclusión, a partir de la afirmación de algunos autores, de que puede dividirse a las reglas de negocio en dos grupos: las reglas que pueden ser modeladas y las que no. El linde entre ambos grupos no es tan preciso como se quisiera. Según el recurso de modelado conceptual, puede que ciertas reglas puedan o no ser modeladas. Un caso interesante es precisamente las reglas que apuntan a interrelaciones muchos a muchos.. I.8.1 La notación IDEF1X Varios son los lenguajes de modelado disponibles en la actualidad. De ellos sobresale por su amplio uso y simplicidad la notación IDEF1X. Este lenguaje es un estándar público desarrollado inicialmente por la US Air Force, en 1985. Muchas son las herramientas 14.

(26) CASE que utilizan este tipo de notación (Davidson et al., 2006). Por tal razón, se ha elegido en el presente trabajo como uno de los medios para mostrar la génesis del problema de la cardinalidad. No obstante, otras notaciones también serán abordadas. No es raro encontrar en un modelo conceptual interrelaciones m:m. Pero no menos cierto es el hecho de que, cuanto más se haya refinado el modelo, más lejos estará el resultado final de poseer tal tipo de interrelaciones 7 . También debe tenerse en cuenta que existen interrelaciones m:m genuinas, es decir, que al final del modelado tienden a mantener su naturaleza (Speelpenning et al., 1999). ¿Cuándo surge el problema de la cardinalidad en este tipo de interrelaciones? ¿Es posible siempre transformar el modelo para eliminar estas interrelaciones? Estas son interrogantes que ameritan responderse. El problema del la cardinalidad surge en dos etapas: diseño conceptual e implementación. Así lo se muestra a continuación.. I.8.2 El problema de la cardinalidad en la etapa del diseño conceptual A menudo, una interrelación m:m exige que algunos atributos estén más cercanos a la relación que a las entidades (Davidson et al., 2006, Speelpenning et al., 1999). En un diagrama de Chen esto no es problema, pues es capaz de representar atributos desde una interrelación. Pero este tipo de diagrama pertenece más al mundo académico que al comercial (Davidson et al., 2006). ¿Cómo se representan entonces los atributos? Pues la solución está en crear una entidad intermedia, llamada associative entity o resolution entity por (Davidson et al., 2006). Ahora las llaves primarias de cada entidad en la interrelación original migran hacia la resolution entity, y en ella se sitúan los atributos que causaban la confusión 8 (Davidson et al., 2006, Speelpenning et al., 1999).. 7. En la opinión de DAVIDSON, L., KLINE, K. & WINDISCH, K. (2006) Pro SQL Server 2005 Database Design and Optimization, Berkeley, USA, Publicado por Apress., ocurre exactamente lo contrario. A medida que se avanza en el refinamiento del modelo, más interrelaciones m:m se identifican. Como simple curiosidad le cito: “It is common to have many-to-many relationships in the data model. In fact, the closer you get to your final database model, the more you’ll find that quite a few of your relationships will be of the many-tomany type”. Y para completar el asombro, en lo siguiente se cita a SPEELPENNING, J., DAUX, P. & GALLUS, J. (1999) Data Modeling and Relational Database Design. 1ra ed., Oracle Corporation.: “The various types of m:m relationships are common in a first version of an ER Model. In later stages of the model most m:m relationships, and possibly all, will disappear”. 8 Un buen ejemplo de expresión y solución de las cardinalidades m:m se logra con el ORM y el método que se apunta en HALPIN, T. (2003) Verbalizing Business Rules (part 2). Business Rules Journal, Vol. 4.. 15.

(27) Se nota con facilidad que siempre es posible transformar una interrelación m:m. Pero, ¿debieran ser siempre transformadas? Según (Speelpenning et al., 1999), la respuesta es sí y no. Desde el punto de vista puramente conceptual la respuesta es terminantemente no. Después de refinar el modelo y transformar aquellas que poseen atributos, solo quedarán algunas interrelaciones m:m genuinas, que no tienen por qué transformarse. Desde un punto de vista funcional del modelado, siempre debe resolverse. Después de todo, en una base datos objeto relacional no hay cabida a este tipo de interrelación, pues las llaves no pueden migrar de una a otra tabla. Esta demanda está más de acuerdo con la etapa de implementación que con la del diseño. Es aquí donde verdaderamente surge el problema de cardinalidad en la generación automática de reglas de negocio en una base de datos relacional.. I.8.3 El problema de la cardinalidad en la etapa de implementación Según lo apuntado, siempre pueden quedar interrelaciones m:m que son genuinas. Es la diferencia entre el modelo conceptual y el modelo objeto relacional la piedra de tropiezo en la generación de las reglas. Tanto OCL como Dot Notation utilizan para la navegación las entidades del esquema conceptual, es decir, los términos del negocio. Esto no es obligatorio, pues toda interrelación m:m del modelo conceptual puede transformarse para su eliminación, pero ello no sería tan conceptual. Además, difícilmente el analista, actor del negocio que define las reglas en lenguaje natural (Morgan, 2002), pueda tener en cuenta los efectos colaterales de la transformación de reglas vinculadas a interrelaciones m:m. Si se tiene en cuenta la diferencia ya mencionada, aparece entonces el mayor problema. Si el evento que genera la violación de la regla descrita en OCL o Dot Notation parece surgir en la entity resolution, o tabla intermedia, ¿cómo se distingue esta regla de las demás restricciones para luego posicionar el trigger en el lugar correcto? Este problema es descrito ya por (Pérez Alonso, 2008). En capítulos posteriores se le propondrá la debida solución.. 16.

(28) I.8.4 Otras notaciones y el problema de la cardinalidad Notaciones como el UML y el ORM no presentan, en el nivel puramente conceptual este tipo de problema. Ambos lenguajes soportan la objetificación 9 de las interrelaciones m:m. Ello posibilita al diseñador del modelo mantener la interrelación original al tiempo que apunta atributos a la interrelación. En (Halpin, 2003) se analizan ejemplos en los que esto sucede y la forma de expresión en los lenguajes de modelado más populares. Pero el problema durante la implementación, y sus consecuencias en la generación de reglas de negocio de forma automática, subyace irresoluto, aún clamando por una solución.. I.9 El catálogo de la base de datos: fuente de información Durante la etapa de implementación es que surge el problema de la cardinalidad m:m que nos atañe. La Dot Notation y el OCL no especifican la cardinalidad entre las entidades que relacionan. Así, Entidad1.Entidad2.[…].Entidadn.Atributo causa la incertidumbre sobre en cuál tabla correspondiente a una entidad deberá almacenarse la regla en forma de trigger. Una fuente de información acerca de la estructura de la base de datos podría ser la solución al problema planteado en el presente trabajo. En (Pérez Alonso, 2008) se utiliza un módulo llamado UMLClassDiagram.pas en el cual, de forma estática, se registra la información necesaria para averiguar la estructura de la base de datos. En él se ofrece la información sobre las tablas, las llaves primarias y las foráneas. En una base de datos relacional, las llaves foráneas indican aquellas entidades que muestran cardinalidad m ó 1 (Davidson et al., 2006). Y, según (Pérez Alonso, 2008), es en estas tablas en las cuales debe generarse el trigger. Claro está, de la misma manera que establece la regla, también menciona la excepción. No queda claro, según apunta, dónde generar el trigger en la cardinalidad m:m. La violación de la regla no ocurre en ninguna de las dos entidades, sino tan solo parece que la violación de la restricción surge en la tabla auxiliar generada, la entity resolution antes mencionada. Por ello, el averiguar la correcta estructura de la tabla para luego decidir dónde generar el trigger adquiere relevancia prioritaria. Ahora, qué información se necesita queda bastante claro. Solo resta cuestionarse cómo se necesita. Si la Aplicación para reglas de negocio a la cual este trabajo le sirve de continuación, resolvía de forma temporal el problema con un módulo, es ahora menester 9. Objetificación: calco del inglés objectification, que aparece en Ibid.. 17.

(29) utilizar un recurso más informativo y dinámico que ofrezca la información estructural deseada.. I.9.1 El catálogo. Definición Sobre el catálogo se manejan dos términos. El primero es catálogo del sistema, y el segundo, catálogo de la base de datos. El primero se define como: Conjunto de tablas del sistema que describe todas las características de una instancia de SQL Server. El catálogo del sistema registra metadatos, como las definiciones de todos los usuarios, bases de datos, objetos de cada base de datos e información de configuración del sistema, como la configuración de opciones del servidor y de bases de datos (Microsoft SQL Server, 2004). Del catálogo de la base de datos se dice: Parte de una base de datos que contiene la definición de todos los objetos de la base de datos así como la definición de la base de datos (Microsoft SQL Server, 2004). De aquí que sea una tentativa bastante estimulante ante la pregunta de qué recurso utilizar para obtener información acerca de la estructura de la base de datos.. I.9.2 Para consultar el catálogo El catálogo puede ser consultado de varias formas, o al menos así se afirma en (Microsoft SQL Server, 2004). Ellas se enumeran a continuación: •. Vistas de esquema de información. •. Conjuntos de filas de esquemas OLE DB. •. Funciones del catálogo de ODBC. •. Procedimientos almacenados y funciones del sistema. Aunque se pudiera, las tablas del catálogo del sistema no deben ser consultadas directamente. La arquitectura de tales tablas depende íntimamente de la versión de SQL Server que se utilice. Por tal razón se prefiere un método que nos aísle de la arquitectura. Los métodos anteriores emulan por su elección (Microsoft SQL Server, 2004). En próximos capítulos se analizarán un poco más a fondo los métodos del catálogo para obtención de información. De la misma forma se analizará cuál de ellos utilizar, la información específica que brindan y en qué manera incorporarlos a la aplicación.. 18.

(30) I.10 Consideraciones del capítulo En estos preliminares fue posible acercarse al problema, al contexto teórico en el que se desarrolla y a los posibles recursos que podría darle solución. Solo resta plantear la propuesta de implementación que tome en cuenta al catálogo como recurso de información suficiente para, con ayuda de algún método nacido del análisis de otras implementaciones, ayude a solucionar las limitaciones encontradas en el Editor de reglas de negocio. Algunos resultados concretos del capítulo que recién termina proponen que: •. El problema de la cardinalidad parece surgir ya en una etapa tan temprana como lo es el diseño conceptual.. •. La base del problema de la cardinalidad está en las diferencias entre el esquema conceptual y el esquema relacional con respecto a las reglas del negocio.. •. El problema de la cardinalidad parece dividirse en: o Cómo se distingue una regla que posea al menos una interrelación m:m entre sus términos constituyentes. o Dónde ocurre el evento desencadenado por la violación de una restricción.. •. El catálogo, recurso de base de datos, es una tentativa ante la pregunta de qué recurso utilizar para obtener información acerca de la estructura de la base de datos.. 19.

(31) Capítulo II Propuesta de implementación. Con base en la hipótesis de que el catálogo tiene información suficiente para una posible implementación 10 de un sistema que supere el problema de la cardinalidad en la generación de reglas, salta a la vista algunas inquietudes. Quizás sea válido preguntarse acerca de la “información” que se menciona, así como por las formas más usuales —o encontradas en esta investigación, si se ha de ser preciso– de generación de reglas. Ello, por supuesto, debe desembocar en un método y propuesta de implementación consecuentes con la resolución del problema de la cardinalidad. ¿Cuál es la arquitectura y el método que debe seguir tal implementación? Esta es la pregunta fundamental a la que da respuesta el desarrollo del presente capítulo.. II.1 Obtención de la información El problema que nos afecta, mucho tiene que ver con cierta información adicional. Una regla se expresa por medio de términos del negocio, los cuales se pueden encontrar en un diagrama EI —de Entidad-Interrelación–, según se afirma en (Hay et al., 2000). Por ello es imposible elaborar una regla si se carece de tal información. Pero ¿cuál es esa información específicamente?, ¿para qué es necesaria?, ¿cómo se obtiene?; son interrogantes que ameritan una pronta respuesta si se quiere elaborar en el futuro algún método de implementación.. 10. Impulsado por las numerosas ocasiones en que se utilizará el término implementación, conviene para clarificar su uso la definición: “una implementación es una especificación que provee toda la información necesaria para construir un sistema y ponerlo en operación”, en OBJECT MANAGEMENT GROUP (2003) MDA Guide. IN OMG (Ed.) Versión 1.0.1 ed., Object Management Group. Como se aprecia, una implementación es una especificación y no el sistema en sí.. 20.

(32) II.1.1 Información necesaria Se apuntó antes el carácter imprescindible de cierta información para la creación de una nueva regla. De hecho, esto se aprecia en uno de los casos de uso que implementa el Editor de reglas (ver Figura II-1).. Figura II-1. Casos de uso del Editor (Pérez Alonso, 2008).. Términos y hechos son los componentes fundamentales a la hora de la elaboración de las reglas. Según (Morgan, 2002) las reglas de negocio se construyen sobre un conjunto de hechos descritos en un modelo. Para él un modelo de hechos muestra objetos, sus relaciones y atributos, de manera que un diagrama UML cumple con el rol de modelo de hechos. No obstante, para aclarar la confusión que en ocasiones crea la diversidad en la terminología y definiciones que aparece en la literatura, conviene exponer otros criterios. En (Von Halle, 2002) se hace referencia a un modelo de término/hecho, como expresión de que en tal modelo están presentes también los términos. Así, un modelo de término/hecho abarca el vocabulario del negocio. Pues, ¿cuál es esta información que se necesita? Son los términos y hechos del negocio cuales, según (Von Halle, 2002), se pueden encontrar en un: •. diagrama UML de clases (modelo de objetos del negocio). •. diagrama EI (modelo lógico de datos 11 ). •. diagrama ORM (Object Role Model). Debe advertirse que expresar el modelo término/hecho por medio de un diagrama UML de clases o de un diagrama EI es igualmente válido, aunque los dos diagramas tienen diferentes propósitos. Un diagrama UML de clases se escoge principalmente para el diseño y generación de código ejecutable, en cambio, un diagrama EI es un proyecto por el cual se diseña bases de datos (Von Halle, 2002). 11. “The logical data model is logical because it is unbiased by implementation target technology. That is, a database designer can adapt the logical data model to any target database technology solution” VON HALLE, B. (2002) Business rules applied: building better systems using the business rules approach, New York, Publicado por John Wiley & Sons.. 21.

(33) Pero en la presente arquitectura no es posible obtener los términos y hechos del negocio a partir de ninguno de los modelos anteriores. Ello sería lo deseable, pero a falta de un módulo con el cual el Editor de reglas pueda contar para establecer una interfaz de conexión con los términos y hechos, se ha decidido buscar esta información en otra fuente específica a una plataforma. En la presente implementación son los metadatos de una base de datos los que suplirán la necesidad de información. Pero aquí surge un problema. ¿Mantienen los objetos de una base de datos la pureza de los términos y hechos de un negocio? En una base de datos se encuentran tablas, atributos, llaves primarias y foráneas. Este modelo de los datos no es todo lo fiel que se quisiera a los términos y hechos del negocio. En el proceso de transformación del esquema conceptual —lógico o de objetos– al esquema relacional, aparecen o son reagrupadas nuevas tablas. Tal es el caso de la transformación de las relaciones m:m, la cual es objeto de nuestro análisis, y de las relaciones de tipo-supertipo (Davidson et al., 2006, Speelpenning et al., 1999). Por otro lado es posible que el nombre de la tabla sea igual al término, pero ello no puede asegurarse si se desconoce el método seguido para la transformación de un modelo a otro. No obstante, si se asume la recomendación de (Morgan, 2002), las clases deberán tener igual nombre que el término, y por tanto las tablas de las bases de datos podrán conservar, en cuanto a nombres se refiere, la estructura original de modelo de término/hecho. Por ello la presente implementación no encuentra problemas en depender de una plataforma específica y asimismo recomendar que en futuros trabajos se trate de implementar la arquitectura que se sugiere en (Morgan, 2002) a través de la Figura II-2:. Figura II-2. Las declaraciones de reglas y sus interrelaciones (Morgan, 2002).. 22.

(34) Otro caso de uso del Editor es desarrollo de una regla (ver Figura II-1). El secreto detrás de este caso de uso y el de Crear Regla, como se muestra en la Figura II-3, es la compilación como una transición obligada en el diagrama de estado que implementan. Ello es lo que obliga a buscar las llaves primarias y foráneas de las tablas que componen una regla. En (Pérez Alonso, 2008) se destaca que: El compilador toma la llave primaria de las tablas en la unit UMLClassDiagram, con las cuales se realizarán las relaciones entre entidades, toma además la llave foránea de una tabla con respecto a otra. Se asume en esta versión que sólo existe una llave primaria para cada entidad. 12. a). b) Figura II-3. a) Diagrama de estado para Crear nueva regla. b) Diagrama de estado para Desarrollar regla (Pérez Alonso, 2008).. El caso de uso restante es activar regla, para el cual el compilar es una condición. La regla compilada es activada propiamente, es decir, se envía al servidor, en forma de. 12. Nótese que en la versión anterior del editor de reglas la información se busca en una unit (módulo de Object Pascal), mientras que en la presente será el catálogo de la base de datos. No obstante, la información necesaria es básicamente la misma.. 23.

(35) triggers y function, con objeto de restringir la base de datos. Luego, activar una regla también demanda de compilar, lo que equivale a obtener información. Hasta el momento, se ha visto la información necesaria solo en función de los casos de uso del Editor de reglas. Pero con respecto al problema tratado en la presente investigación, es otro el enfoque que se aborda. Si se asume que se cuenta con los términos y hechos del negocio, solo resta definir cuál es la información que se necesita cuando aparece una declaración de una regla que implica interrelaciones de los términos con cardinalidad m:m. Según se ha planteado en el problema, una regla que implica términos con interrelaciones m:m crea la expectativa de cuál será la tabla que se crea como resultado de la transformación del esquema conceptual al esquema relacional. Supóngase la declaración de una regla cuya característica se expresa como E1.E2.[…].En.Atributo. En el modelo relacional aparecerá la tabla intermedia que no aparece especificada en la característica de la regla 13 . La estructura de una relación m:m implementada en un modelo relacional aparece como en la Figura II-4: Ei. 1. m. 1. Eint. Ei+1. m. Figura II-4. Representación de una relación m:m en un modelo relacional.. A la pregunta de ¿por cuáles tablas es referenciada la tabla Ei o la Ei+1?, la respuesta será un conjunto de tablas que, por medio de las llaves foráneas, apuntan a las tablas Ei o Ei+1. Así, para averiguar por la tabla intermedia solo es necesario contar con: •. Las tablas que componen una regla. •. Un método de búsqueda a través del esquema relacional que dada una tabla sea capaz de devolver todas las tablas que a ella se refieren. 13. Recuérdese que en la presente implementación nombre de tabla y término del negocio, son equivalentes. Se supone que en el proceso de transformación los términos persistentes del negocio fueron conservados en los nombres de las tablas.. 24.

(36) Nótese que un esquema relacional puede ser representado como un grafo dirigido, en el cual las tablas están representadas por vértices y las relaciones por aristas, de manera que un vértice Eint apunta a un vértice Ei adyacente si en Eint está presente una llave foránea que referencia a tal vértice. Con este modelo se abre la posibilidad de implementar un método de búsqueda que dado un vértice, obtenga todos aquellos vértices que lo apuntan. En la Figura II-5 aparece un grafo dirigido equivalente a la representación anterior. Ei. Ei+1. Eint. Figura II-5. Grafo dirigido que representa la estructura de un modelo relacional.. Por suerte, existen métodos ya implementados en el gestor de bases de datos MS SQL Server que suplen la funcionalidad del método enunciado. Más adelante se detallará este tópico (ver utilización de sp_fkeys en epígrafe III.1.2). En concreto, de la base de datos se necesita: •. Nombre de las tablas. •. Nombre de las llaves primarias y foráneas. •. Nombre de atributos. Visto ya cuál información es necesaria y su objetivo, solo resta sistematizar en la fuente de tal información y el medio de obtenerla.. II.1.2 Fuente y medio de obtención de la información En cómo obtener la información especificada, es necesario distinguir entre fuente de información y medio de obtención de tal información. Como bien se ha mencionado en (Pérez Alonso, 2008), es la unit UMLClassDiagram fuente y sumidero de toda búsqueda de información. La gran desventaja es la poca flexibilidad del software en cuanto al cambio de la base de datos de trabajo. En caso de que se quisiera maneja varias bases de datos con el mismo editor o, simplemente, cambiar la base de datos, sería necesario cambiar en su totalidad el contenido de la unit. Ello no podría ser menos que traumático para el desarrollador de la aplicación, además de generar un gran gasto de tiempo y recursos.. 25.