A estas alturas de curso, con tantas y tantas clases y prácticas a vuestras espaldas, y llegamos nosotros y nos metemos con un tema de base de datos titulado “la perspectiva lógica del modelo relacional”. Y venga fórmulas, y venga “para-todos”, y venga “existes”, y que si el universo de discurso, y que si predicados, y que si…(1)
Desde un punto de vista práctico es difícil justificar el porqué de este tema en un curso básico de bases de datos: “cuando yo tenga jefe, como le hable de cálculo relacional dejo de tener jefe…”. No obstante, el cálculo y el álgebra relacionales forman parte de la historia del modelo relacional. Parece que solo exista SQL como lenguaje de manejo de datos en bases de datos relacionales. Pero pongamos perspectiva al asunto, antes no existía SQL. ¿De dónde salió SQL?
Cuando se propuso el modelo relacional, un aspecto fundamental, claro, era cómo trabajar con él, se tenía que acompañar de un lenguaje concreto. Parece ser que Codd tiró en un principio de álgebra, y que después se le ocurrió, o más bien “le contaron” que se podía, pasarse al cálculo relacional —que después se renombró “de tuplas” porque a otros les gustaba más trabajar con variables-dominio. De hecho, antes que SQL, se propusieron otros lenguajes que no llegaron a implementarse o no han tenido un éxito masivo como sí lo ha tenido SQL. ALPHA, basado en cálculo relacional (de tuplas), fue el precursor de QUEL; QBE (Query by Example) vino a ser la respuesta a la variante en dominios.
Y después llegó SQL. Curiosamente, SQL nació con la intención de no parecerse en nada ni al álgebra relacional ni al cálculo relacional, pero con el paso del tiempo se fue enriqueciendo precisamente con operadores y conceptos de ambos. Por eso dice Date que SQL “se basa parcialmente en ambos (por álgebra y cálculo) y parcialmente en ninguno”.
Hablando de cálculo relacional, decíamos anteriormente que el álgebra es un lenguaje procedimental y el cálculo declarativo. Es decir, una expresión en álgebra tiene una secuencia operativa que define “cómo construir la relación resultado”, mientras que una de cálculo expone “cuál es el problema a resolver”. En todo caso, son dos formas alternativas de manejar datos en una base de datos relacional, cada una tendrá su momento y su oportunidad de ser usado. Algo parecido a la decisión sobre programar en C++ o en Java; pues será el que se considere más apropiado para el problema a resolver. O el que más rabia te dé.
Total, que sí, que parece “poco útil”, pero es fundamental para comprender de donde vienen las herramientas de las que disponemos ahora para “entrar” en una base de datos relacional. Y, además, cae en el examen.
Edición de lo publicado originalmente en bd1blog, el 19 de marzo de 2009.
No hay comentarios:
Publicar un comentario
Los comentarios son revisados antes de su publicación en prevención de usos incorrectos (spam o alusiones insultantes a terceros). Por eso, tu comentario puede tardar un poco, no mucho, en ser visible.