Las bases de datos relacionales 2

Dicen por ahí que no hay nada más importante que la comunicación y en cuestión de bases de datos, esto es, en definitiva, un axioma. Ya hablamos de la comunicación entre columnas dentro de una misma tabla, que a su vez está contenida dentro de una base de datos. Ahora bien, hablemos de la comunicación entre tablas dentro de una misma base de datos.

Como seguramente recordarán, hemos hablado ya de las llaves. Las llaves no son más que, para los que saben de C y C++, punteros que, de una tabla, apuntan a otra, teniendo en cuenta un dato común. Dicho en buen cristiano, y explicado con un ejemplo práctico:

Nos han puesto una multa por manejar a excesiva velocidad (nuestra bicicleta iba a 15 en una zona de 7.5 pues nuestra novia nos pidió flores y tuvimos que ir a comprarlas con rapidez) y vamos a pagar dicha multa a las oficinas respectivas. Al llegar a las oficinas, amén claro del clima de culpabilidad, vemos que todo el mundo tiene su licencia en la mano, la cual entregamos a la amabilísima secretaria de la ventanilla; la secretaria toma nuestra licencia de conducir, mira los números y digita en la computadora los números que corresponden al número de nuestra licencia. La computadora, después de algún tiempo, muestra en pantalla la información sobre la persona poseedora de la licencia, es decir, nosotros. Hasta este punto, podríamos asumir que la computadora ha puesto en marcha una consulta a una sola tabla, es decir, la tabla que contiene nuestros datos personales, sin embargo, ¿qué ocurre cuando la siempre sonriente secretaria procesa el pago de nuestra multa? Las multas deberían ser guardadas en otra tabla, para evitar que la información se mezcle y se haga una cantidad innecesaria de información; así pues, el pago de la multa se procesa en otra tabla, pero, de alguna manera debe estar vinculada a nuestra información, sino, habría un verdadero desastre de información en las oficinas de tránsito, ¿cómo imaginan ustedes que dicho vínculo podría llevarse a cabo? Veamos las opciones:

- El nombre de la persona
- El apellido de la persona
- El número de su licencia

Si escogiésemos el nombre habría un problema, cuántas personas existirían con el mismo nombre; la misma historia pasaría si escogiésemos el apellido; por otro lado, escogiendo el número de licencia (que es único) podríamos establecer un vínculo entre la tabla de nombre,… digamos datos_generales, y la tabla de nombre pagos_efectuados. Dicho en términos de bases de datos, la llave entre una tabla y otra sería una columna que contenga el número de licencia, y que debería existir tanto en la tabla datos_generales, como en la tabla pagos_efectuados, de tal forma que nuestro motor de bases de datos sepa que el pago efectuado por una persona, pertenece exclusivamente a un número de licencia, que a su vez, corresponde a una persona con un nombre y un apellido específico.

Por cierto:

Esta es nuestra bicicleta con las flores

Y esta es la siempre sonriente oficinista

Muy bien, hemos cubierto de manera extremadamente global lo que implican las bases de datos relacionales y la forma en la que unas mantienen comunicación con otras. En nuestro siguiente encuentro, empezaremos a conocer el Lenguaje Estructurado de Consultas SQL (Structures Query Language). Por el momento, recuerden: “Un pintor es un hombre que pinta lo que vende, un artista es un hombre que vende lo que pinta” (Pablo Picasso) Seamos artistas de nuestros programas, no pintores de los mismos. Hasta Pronto.