TINTIN : comprobación incremental de aserciones SQL

TINTIN: Comprobaci´on Incremental de Aserciones SQL Xavier Oriol1, Ernest Teniente1, and Guillem Rull2? 1Universitat Polit`ecnica de Catalunya {xoriol,teniente}@essi.upc.edu 2Universitat De Barcelona [email protected] Abstract. Ninguno de los SGBD actuales implementa aserciones SQL, obligando as´ı a implementar manualmente su comprobaci´on. Por este motivo hemos desarrollado TINTIN: una aplicaci´on que genera autom´aticamente el c´odigo SQL necesario para comprobar aserciones. Dicho c´odigo captura las tuplas insertadas/borradas en una transacci´on, comprueba mediante consultas SQL que ninguna de ellas viole ninguna aserci´on, y materializa los cambios en caso de que esto suceda. La eficiencia del proceso se consigue mediante la comprobaci´on incremental de las aserciones. 1 Introducci´on Todo sistema de informaci´on tiene que poder capturar cualquier estado posible del dominio, y s´olo los estados posibles de ´este. Para conseguir dicho objetivo, los sistemas de informaci´on deben garantizar que sus datos siempre satisfacen ciertas condiciones, llamadas restricciones de integridad [1]. Por ejemplo, una restricci´on de integridad l´ogica en un sistema de informaci´on sobre libros, como el descrito en el diagrama UML de la Figura 1, ser´ıa que la fecha de publicaci´on de toda edici´on de un libro tiene que ser posterior a la fecha de nacimiento de todos sus autores. Edición Libro título:String 1..* 1 Contiene Autor nombre:String 1..* * EscritoPor fechaNacimiento:Date número:Integer fechaPublicación:Date Fig. 1. Sistema de Informaci´on de libros y autores Desde la publicaci´on del est´andar SQL-92, los sistema de informaci´on implementados con tecnolog´ıa relacional pueden especificar sus restricciones de integridad mediante aserciones SQL. Intuitivamente, se puede definir una consulta SQL que recoja los datos que violan la restricci´on y una aserci´on que comprueba ?Este trabajo ha sido parcialmente financiado por el Ministerio de Econom´ıa y Competitividad, bajo el proyecto TIN2014-52938-C2-2-R; y la Secreteria d’Universitats i Recerca de la Generalitat de Catalunya bajo un 2014 SGR 1534 y una beca FI. 2 X. Oriol, E. Teniente, G. Rull que el resultado de la consulta sea vac´ıo. Seg´un esta propusta, la anterior restricci´on se podr´ıa definir como: CRE ATE ASSE RTI ON ‘ Fecha sCorre ctas ’ CHEC K NOT EXISTS ( SELECT * FROM Edicion JOIN EscritoPor JOIN Autor WHERE fec haPublic aci on <= fec haN aci mie nto ) Sin embargo, ninguno de los SGBD relacionales actuales (como por ejemplo Oracle, MySQL, SQL Server, PostgreSQL o DB2) implementa la comprobaci´on autom´atica de aserciones SQL. Por lo tanto, en a la pr´actica, dichas aserciones acaban siendo comprobadas mediante procedimientos programados manualmente, tarea laboriosa y propensa a errores [2]. En aras de superar esta limitaci´on, en este art´ıculo presentamos TINTIN [3]: una herramienta para generar autom´aticamente el c´odigo SQL necesario para comprobar aserciones. 2 El c´odigo generado por TINTIN Supongamos que, en nuestro ejemplo, se a˜nade el autor Auguste Maquet al libro El Conde de Montecristo que ya ten´ıa como autor a Alejandro Dumas. Asumiendo que la aserci´on FechasCorrectas era cierta en el estado previo a esta inserci´on, podemos asegurar que despu´es de ella lo seguir´a siendo si la fecha de nacimiento de Maquet es anterior a la de todas las ediciones de El Conde de Montecristo, sin necesidad de comprobar los datos de otros libros/autores. A esta forma de comprobar aserciones en donde se presume que los datos actuales satisfacen las aserciones y se comprueba su validez ´unicamente con los nuevos datos modificados se le llama comprobaci´on incremental. TINTIN consigue una comprobaci´on incremental mediante triggers que capturan los datos que est´an siendo insertados/borrados durante una transacci´on y los almacenan temporalmente en unas tablas con prefijo ins/del. De este modo, la inserci´on de EscritoPor(’El Conde de Montecristo’,’Auguste Maquet’) ser´ıa capturada y almacenada en la tabla ins EscritoPor con los valores (’El Conde de Montecristo’,’Auguste Maquet’), sin ser f´ısicamente aplicada a la base de datos. Teniendo capturadas las diferentes tuplas a insertar/borrar en las respectivas tablas ins/del, TINTIN puede generar unas consultas SQL que comprueban si estas entran en conflicto con alguna aserci´on. Siguiendo con el anterior ejemplo, TINTIN genera la siguiente consulta (almacenada como vista): CRE ATE VIEW ‘ Chec kFe cha sCo rre cta s ’( SELECT * FROM ins_Edicio n JOIN EscritoPor ANTI JOIN del_EscritoPor JOIN Autor WHERE fec haPublic aci on <= f ech aNa cimiento UNION ALL SELECT * FROM ins_Escri toP or JOIN Edicion ANTI JOIN del_Edicion JOIN Autor WHERE fec haPublic aci on <= f ech aNa cimiento UNION ALL SELECT * FROM ins_Escri toP or JOIN Edicion ANTI JOIN del_Edicion JOIN ins_Autor WHERE fec haPublic aci on <= f ech aNa cimiento UNION ALL SELECT * FROM in s_E scr ito Por JOIN ins_Edicion JOIN Autor WHERE fec haPublic aci on <= f ech aNa cimiento UNION ALL SELECT * FROM in s_E scr ito Por JOIN ins_Edicion JOIN ins_Autor WHERE fec haPublic aci on <= f ech aNa cimiento TINTIN: Comprobaci´on Incremental de Aserciones SQL 3 Intuitivamente, el primer select detecta las violaciones ocasionadas por inserciones de nuevas ediciones sin a˜nadir nuevos autores. Cabe destacar aqu´ı la necesidad de comprobar que el autor con el que se entra en conflicto no est´e siendo borrado tambi´en por la transacci´on, hecho que se comprueba mediante una anti join. De manera similar, el segundo y tercer select detectan las violaciones ocasionadas al insertar nuevos autores a un libro sin a˜nadir nuevas ediciones, y el cuarto y quinto detectan las violaciones ocasionadas por insertar nuevos autores y ediciones a un libro. Una vez se tienen estas consultas almacenadas como vistas, s´olo hace faltar invocarlas para saber si una transacci´on provoca o no la violaci´on de alguna aserci´on. ´ Esta es precisamente la tarea desempe˜nada por el procedimiento safeCommit, tambi´en generado autom´aticamente por TINTIN. En concreto, safeCommit (1) ejecuta las vistas para comprobar si se viola alguna aserci´on, (2) en caso afirmativo, devuelve un mensaje de error al usuario indicando qu´e aserci´on est´a siendo violada y por qu´e datos; alternativamente, ejecuta los cambios almacenados en las tablas ins/del, (3) elimina el contenido almacenado en las tablas ins/del para as´ı iniciar una nueva transacci´on desde cero. De este modo, la simple invocaci´on de safeCommit al final de una transacci´on es suficiente para garantizar que los cambios definidos por dicha transacci´on s´olo se realizar´an si no violan ninguna aserci´on de la base de datos. En la versi´on actual3, TINTIN es capaz de generar el c´odigo para comprobar aserciones descritas en el fragmento de SQL equivalente al ´algebra relacional. 3 Sobre c´omo TINTIN genera el c´odigo Presentamos ahora resumidamente c´omo genera TINTIN las consultas SQL que detectan las violaciones. En primer lugar, TINTIN reescribe las aserciones SQL como denegaciones l´ogicas siguiendo la traducci´on definida en [4]. Una denegaci´on es una f´ormula que establece una condici´on que nunca debe evaluarse a cierto en un estado de la base de datos. Por ejemplo, la anterior aserci´on se reescribir´ıa como: edicion(n,fP,l)∧escritoPor(l,a)∧autor(a,fN)∧fP ≤fN → ⊥ (1) A partir de aqu´ı, TINTIN obtiene las correspondientes Event Dependency Constraints (EDCs) [5]. Cada EDC es una regla l´ogica que identifica una forma particular de violar una denegaci´on mediante inserciones/borrados de tuplas sobre una base de datos D. Para obtener las EDCs, es suficiente con reemplazar cada literal en la denegaci´on por la expresi´on que eval´ua ese mismo literal en el nuevo estado de la base de datos Dn; o sea, el estado de la base de datos despu´es de aplicar la transacci´on. En concreto, se reemplaza cada literal en funci´on de si este es positivo o negativo mediante las siguientes equivalencias: ∀x. pn(x)↔(ιp(x)) ∨(¬δp(x)∧p(x)) (2) ∀x. ¬pn(x)↔(δp(x)) ∨(¬ιp(x)∧ ¬p(x)) (3) 3http://www.essi.upc.edu/~xoriol/tintin/ 4 X. Oriol, E. Teniente, G. Rull donde ιp(x)/δp(x) representa la inserci´on/eliminaci´on de p(x). As´ı, seg´un la regla 2, p(x) es cierto en la nueva base de datos Dnsi se inserta p(x), o si p(x) ya era cierto en Dy no se elimina. La regla 3. define an´alogamente el caso ¬p(x). Utilizando estas sustituciones, en el anterior ejemplo se obtienen las reglas: ins ed(n,f,l)∧ins esc(l,a)∧ins aut(a,fN)∧f≤fN → ⊥ (4) ins ed(n,f,l)∧ins esc(l,a)∧aut(a,fN)∧ ¬del aut(a)∧f≤fN → ⊥ (5) ins ed(n,f,l)∧esc(l,a)∧ ¬del esc(l,a)∧ins aut(a,fN)∧f≤fN → ⊥ (6) ins ed(n,f,l)∧esc(l,a)∧ ¬del esc(l,a)∧aut(a,fN)∧ ¬del aut(a)∧f≤fN → ⊥ (7) ed(n,f,l)∧ ¬del ed(n,l)∧ins esc(l,a)∧ins aut(a,fN)∧f≤fN → ⊥ (8) ed(n,f,l)∧ ¬del ed(n,l)∧ins esc(l,a)∧aut(a,fN)∧ ¬del aut(a)∧f≤fN → ⊥ (9) ed(n,f,l)∧ ¬del ed(n,l)∧esc(l,a)∧ ¬del esc(l,a)∧ins aut(a,fN)∧f≤fN → ⊥ (10) ed(n,f,l)∧ ¬del ed(n,l)∧esc(l,a)∧ ¬del esc(l,a)∧aut(a,fN)∧ ¬del aut(a)∧f≤fN → ⊥ (11) Si bien la cantidad de EDCs generada es exponencial con la longitud de la denegaci´on, TINTIN incorpora ciertas optimizaciones para eliminar parte de estas reglas. As´ı, las EDCs 6 y 10 son eliminadas puesto que, para violarse, la base de datos deber´ıa violar primero la integridad referencial escritoPor(autor) →autor(nombre). Adicionalmente, TINTIN elimina la EDC 11 ya que que ´unicamente se viola en una base de datos que previamente violara la misma denegaci´on. A partir de aqu´ı, TINTIN traduce las EDCs a consultas SQL siguiendo las pautas establecidas en [6]. La validez y completitud de las vistas est´a garantizada puesto que el concepto de EDC se basa en las reglas de eventos [7], las cuales han sido demostradas como v´alidas y completas en bases de datos deductivas. 4 Conclusiones Hemos presentado TINTIN, una herramienta para generar autom´aticamente el c´odigo SQL necesario para comprobar aserciones SQL. En el futuro, pretendemos extender TINTIN para (1) hacer frente a los agregados distributivos, (2) generar un n´umero lineal de vistas extrayendo factor com´un entre las EDCs generadas. Referencias 1. Oliv´e, A.: Conceptual Modeling of Information Systems. Springer, Berlin (2007) 2. Tropashko, V., Burleson, D.: SQL Design Patterns: Expert Guide to SQL Programming. Rampant Techpress (2007) 3. Oriol, X., Teniente, E., Rull, G.: TINTIN: a tool for incremental integrity checking of assertions in SQL server. In: Proceedings of the 19th Int. Conference on Extending Database Technology, EDBT. (2016) 632–635 4. Teniente, E., Farr´e, C., Urp´ı, T., Beltr´an, C., Ga˜n´an, D.: SVT: schema validation tool for microsoft sql-server. In: Proc. of the 30th Int. Conference on Very Large Data Bases. (2004) 1349–1352 5. Oriol, X., Teniente, E., Tort, A.: Computing repairs for constraint violations in UML/OCL conceptual schemas. Data & Knowledge Engineering 99 (2015) 39 – 58 6. Oriol, X., Teniente, E.: Incremental checking of OCL constraints with aggregates through SQL. In: Conceptual Modeling. Volume 9381 of LNCS. Springer (2015) 199–213 7. Oliv´e, A.: Integrity constraints checking in deductive databases. In: Proceedings of the 17th Int. Conference on Very Large Data Bases (VLDB). (1991) 513–523