De registros y tuplas

Ya no pedimos yogur, pedimos Danone. Hay quien escribe “a parte” cuando debería escribir “aparte” o dice “poneros” cuando debería decir “poneos” y ni vagamente avergonzado se siente. “Pero tú entiendes lo que quiero decir ¿no?”.

Todo esto viene a cuento de lo adecuado o no que es usar el término “registro” cuando hablamos de filas de una tabla, o “campo” si de sus columnas se trata. Registro y campo son propios de la estructura de datos fichero. Relajando la definición, y olvidándonos de sus múltiples organizaciones posibles, un fichero es una secuencia de registros que se definen por los campos que contienen. Los registros, se use o no, están ordenados dentro del fichero. El acceso a un campo de un registro se realiza utilizando su nombre de campo —aunque no necesariamente, hay otras formas de recuperar datos de un fichero y todo es muy relativo dependiendo del lenguaje que se use—.

La teoría del modelo relacional parte del concepto matemático de producto cartesiano de conjuntos cuyo resultado es un conjunto de tuplas de n componentes.  Las tuplas no tienen ordenación alguna entre sí y el acceso a una componente de una tupla se consigue por su posición dentro de la misma. No obstante, añadimos un nombre a cada componente para poder acceder a la información sin la necesidad de conocer su posición relativa. O sea, que al final, utilizamos la tupla como si fuera un registro.

Consultéis donde lo consultéis, todos hacen la siguiente afirmación: “la tupla (también conocida como registro) y sus componentes (también conocidos como atributos o campos)”. Por otra parte, Codd también habla de registros, seguramente en un intento de hacer más asequible el modelo. Entonces, ¿da lo mismo? Sí y no.

¿Una tabla es un fichero? Supongamos que un día necesitamos buscar los registros que están duplicados en dos ficheros diferentes, y supongamos que tienes unos conocimientos mínimos de programación en cualquier lenguaje. A ver, coger el fichero A, registro a registro, y comparar cada uno de ellos con los del fichero B, uno a uno también; si se encuentra, se muestra en pantalla y se pasa al siguiente registro de A; si no, se ha recorrido todo el fichero B hasta llegar a la conclusión de que ése registro no está duplicado. Y así, hasta terminar con todos los registros de A.

En modelo relacional se soluciona con A∩B.

El modelo relacional se propuso como una abstracción de más alto nivel que dejara ocultos los detalles de implementación para que hasta el hijo de vecino más torpe pudiera crear una base de datos y consultarla —vale, exagero—, por eso el orden entre los registros no es relevante, el usuario no programa, simplemente pregunta. El usuario no trabaja con ficheros, accede a tablas, y no lo puede hacer de cualquier manera, debe respetar las reglas del modelo. Cierto, habrá programadores que se empeñen innecesariamente en usar cursores para el problema que hemos contado antes. Añoran los ficheros y la libertad que ofrecen, no son capaces de ver los datos a diferentes niveles de abstracción, y no consiguen aplicar la mejor solución para una tarea concreta por falta de conocimiento o interés.

En resumen, el uso del concepto matemático de tupla no es casual. Al igual que “estar dormido” no es lo mismo que “estar durmiendo”, registro no es lo mismo que tupla, no exactamente, o no del todo. Si hablamos de registros en una base de datos relacional con la precaución debida, no hay problema. Nuestro fundamentalismo como “maestros” de Bases de Datos 1 se ha ido dulcificando durante estos años y ya no colgamos de los pulgares al que nos pregunta por los campos de la tabla.

Many people fail to separate in their minds different levels of abstraction. A specific example of this is the failure to realize that tuples are at a higher level of abstraction than records. E. F. Codd, “Data Models in Database Management”.

Aun así, deberíamos usar estos términos [tupla = registro, ...] con gran cautela. Como Codd advierte (…), el hecho de que las relaciones puedan ser percibidas como tablas, y puesto que una tabla es parecida a un fichero plano, puede crear la falsa ilusión de que la misma libertad de acciones permitida para las tablas o ficheros planos está permitida para la manipulación de relaciones.” Antonio Moreno Ortiz