MANUAL
DE MySQL. 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.
