MySql - Introduccion a las Bases de Datos

  

Sean bienvenidos y bienvenidas al mundo de los motores de las bases de datos, uno de los pilares de las ciencias informáticas, ¿por qué?, pues porque en la gran mayoría de las ocasiones, los datos que utilizamos o insertamos o modificamos o borramos, necesitan estar "guardados" en algún lugar. ¿Un ejemplo?, claro, los juegos de vídeo,... ¿no lo creen?, cómo creen entonces que guardan las puntuaciones más altas, los nombres de los jugadores, etc., etc.

Las bases de datos están por todos lados a nivel informático, están cuando pasan un código de barra por la lectora de códigos en el supermercado; están en nuestros carnés de empleado que retienen nuestra información gracias a un número de empleado o un código de barra; están en internet cuando entramos a comprar algo en línea; están en el departamento de tránsito cuando debemos pagar una multa (dolor, dolor, muchísimo dolor).

 Uno de los motores de bases de datos más famosos, MySQL. Una de las razones de dicha fama, es el hecho de que es de código abierto bajo licencia GNU. Dicho en palabras mortales: es GRATIS (de fondo deben escucharse aplausos y gritos de aleluya, por favor)

MySQL es un software creado por MySQL AB y es un software multiusuario, multihilos y un servidor SQL (Structured Query Language). SQL es el lenguaje estándar utilizado para manejar las bases de datos.

  

En un principio no existían las bases de datos relacionales existín dos modelos arcaicos de bases de datos: el jerárquico y el de redes, de los cuales el de redes era el que más se adaptaba a las necesidades reales de almacenamiento y clasificación.

   En fin, el modelo de redes podía tener registros, en los cuales se alojaran otra cantidad de registros, y dichos registros podían pertenecer a más de un conjunto. Sin embargo, el problema de este modelo consistía en la dificultad de la aplicación de búsquedas o modificaciones. Era necesario ser un cuasi ingeniero informático para poder hacer una búsqueda.

Posteriormente, aparecieron las bases de datos relacionales, en las cuales los datos se relacionaban unos a otros con base en tablas y pequeños vínculos que servían de puente conector entre una tabla y otra, logrando de esta manera la "descomposición" de la información en partes, con la posibilidad de reconstruir dicha información y presentarla con todos los agregados respectivos.

De esta forma resumimos (por favor puristas de la informática, no se revuelvan en sus tumbas) la historia de las bases de datos, y podemos decir que estamos listos para iniciar la explicación de lo que implica construir una base de datos del tipo relacional.
   Las bases de datos relacionales, como ya explicamos en nuestro encuentro anterior las bases de datos relacionales tienen la ventaja de "relacionarse" entre sí sin la necesidad de duplicar una gran cantidad de información, con base a un lenguaje estándar llamado SQL (Structured Query Language), el cual es, podríamos decir, la razón para que las bases de datos relacionales tengan un éxito tan arrollador.

De tal manera, las bases de datos relacionales utilizan "punteros disfrazados" para poder tener relación entre ellas (para los que conocen un poquitín de C o C++, esto de los punteros debe sonar como oir llover), ahora bien, esto de los punteros y de las relaciones, a nivel SQL se conoce en realidad como llaves o keys.

Pero no nos adelantemos, expliquemos cómo se compone una base de datos (de ahora en adelante, una base de datos relacional, será simplemente la base de datos o la base, pues, para abreviar). Podríamos pensar en las bases de datos como en cajas, dentro de las cuales hay celdas, cada una guardando algo.

Bien, las bases de datos están conformadas por TABLAS, que son las contenedoras de la información. Es decir, la base de datos sería el cuarto conteniendo las cajas (que serían las tablas). Las tablas contienen campos, formados por filas y columnas.

Imaginemos una tabla dentro de una base que contenga dos columnas: Nombre y Apellido. Las columnas representan la información genérica de la tabla, que es en donde se guardará la información específica, es decir, en las filas.

Así pues, si tenemos un par de datos que guardar, es decir un nombre y un apellido, digamos: Ernesto Chávez; estos datos formarían una fila, pues corresponden a una persona específica, sin embargo, Ernesto se guardaría en la columna Nombre y Chávez se guardaría en la columna apellido.

De esta manera, las tablas mantienen comunicación entre columnas, para extraer la información específica de las filas.

Pero también hay comunicación entre tablas (incluso entre bases de datos).

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.

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.

Fuente: http://www.aulafacil.com/mysql/curso