I

Seguramente en algún momento de la vida puede que usted -estimado lector- haya sentido la necesidad de escribir o dejar plasmado algún tipo de transacción de la que se quiere conservar información por un tiempo. Por ejemplo, si se es emprendedor y se gerencia algún tipo de comercio o empresa, puede que se haya vendido algún producto o servicio y se quiere dejar anotado a quién se vendió, a qué precio, qué cantidad, etc.

Por otro lado, si se es un investigador, puede que se requiera llevar un registro de todas las observaciones que se han realizado en el transcurso de una investigación, y esa investigación está asociada a un proyecto en particular, quizá en el marco de una institución.

Otro ejemplo sería llevar el control de citas médicas. Para ello, se puede trazar un esquema de tabla con la información al respecto, tal como se muestra a continuación (véase imagen 1).

En este último ejemplo, si se quiere tener un poco más de información de los pacientes, podría ser necesario registrar la cédula (número de identificación), fecha de nacimiento, dirección de habitación, número(s) telefónico(s), correo electrónico, etc. Por lo tanto, se crea otro esquema (tabla) similar (véase imagen 2):

Como se puede observar, ambas “tablas” están relacionadas entre sí. Mientras que la primera registra detalles concretos de la cita, la siguiente tabla registra la información de cada paciente que posee y puede poseer una eventual cita.

En este mismo ejemplo, es probable que en el futuro se requiera almacenar un poco más de información que también esté relacionada, como puede ser: tipo de consulta médica, con qué especialidad, estado de la cita, etc. También podría ser necesario mantener el registro de cuántos y cuáles médicos hay en el centro clínico, cuántos están disponibles, cuántos no y mucha más metadata acerca de la cita; todo lo cual puede dar origen N-cantidad de tablas.

A este conjunto de tablas es a lo que generalmente se asocia a una base de datos. Puede ser un poco más complejo, pero el concepto básico de base de datos es ese: un conjunto de datos almacenados y con determinada afinidad entre ellos. Por ello es que las bases de datos también son conocidas como “bancos de datos”, en el sentido de compilar y resguardar unidades de información.

Aunque en la experiencia física diaria hay objetos y situaciones que conceptualmente pueden considerarse una base de datos (como un archivador, una biblioteca, etc.), este término actualmente se asocia más a lo informático y digital. De hecho, la creación y administración de base de datos es objeto de estudio y aplicación dentro de la ingeniería informática, ingeniería de sistemas y otras afines, y son la base de interminables servicios que funcionan actualmente.

En este último caso, para ilustrar la magnitud de los usos de las bases de datos, piénsese que toda la información puesta a la disposición de sus usuarios por parte de los motores de búsqueda, como Google. ¿Dónde está alojada toda esa información? Lo mismo aplica a todas las transacciones y movimientos financieros que ocurren a diario en los bancos y empresas. ¿Dónde se almacenan?

Prácticamente, casi cualquier sitio web o servicio en línea que se consulte seguramente posee bases de datos donde almacena toda su información. En ocasiones, existe la posibilidad de interactuar con bases de datos que funcionan como repositorios, como pasa con los repositorios de contenidos académicos y científicos puestos a disposición por universidades y otras organizaciones. Hasta la blockchain resulta ser un tipo concreto de base de datos distribuida, y muchos steemianos saben bastante bien de qué trata esto.

II

En cuanto al funcionamiento e interacción con las bases de datos relacionales y otras, esto “generalmente” se lleva a cabo tras bambalinas con dos los tipos esenciales de programas: 1) los servidores y/o gestores de bases de datos DBMS (DataBase Management System), que se encargan del almacenamiento y custodia de la información, y 2) las aplicaciones cliente, que son programas que se comunican con el gestor a través de un lenguaje que ambos puedan entender.

Hay infinidad de aplicaciones cliente, por lo que es probable que se haya escuchado decir que un sistema trabaja con el gestor MySQL, PostgreSQL, ORACLE, MSSQL, entre otros. En las imágenes 3 y 4 (véanse) se muestran algunas marcas de populares DBMS en software libre y la ejecución de un cliente particular. Seguramente se hablará sobre la comparación entre estos en próximas entregas.

Tiempo atrás, cada empresa desarrolladora de software tenía sus propias técnicas para almacenar y leer los datos en su propio sistema gestor de base de datos. No obstante, pronto fue necesario estandarizar un poco estas cosas, pues no es posible que existan centenares de formas particulares de hacer las cosas. Es improductivo y limitaba la integración de los sistemas. Por ello, se crea un lenguaje estándar para denotar las instrucciones de trabajo con la base de datos de tipo relacional y es conocido como SQL Structured Query Language (lenguaje estructurado de consulta).

De esta manera, aunque existieran varios programas gestores de bases de datos, los que no eran capaces de reconocer el lenguaje SQL seguramente iban a quedar en el olvido. De hecho, el mundo sigue girando y con el tiempo han ido apareciendo otras necesidades, por lo que algunos gestores incluso rompen el estándar SQL y extienden sus funcionalidades.

En esa misma tónica, la ingeniería que trabaja con base de datos suele encontrarse con problemas y desafíos qué superar, a fin de manejar apropiadamente la complejidad de una base de datos, la integridad de su información, su seguridad, etc. Es así como en ocasiones surge la necesidad de permitir al gestor de base de datos aplicar ciertos controles adicionales en el tratamiento de los datos que tiene bajo su custodia. Para ilustrar estas situaciones, se planteará un ejemplo recapitulando la primera tabla presentada.

Supóngase que el señor Isaac ha decidido no seguir participando como paciente del hospital, por lo que no debe existir más registros asociados a Isaac. Al gestor de base de datos no le importa qué información debe o no registrar, su trabajo es almacenar y servir la información. La consistencia de esa información es responsabilidad de quien ha diseñado la aplicación cliente del gestor.

Sin embargo, algunos gestores de bases de datos permiten agregar ciertas reglas. Así que dependiendo del gestor que se use, se pueden agregar reglas como “no permitir un registro asociado a un consumidor que tiene un valor ‘inactivo’” en la columna ‘estado’. Entonces, aunque el programador que desarrolló la aplicación cliente pueda haberse equivocado, esa imprudencia puede ser filtrada desde el gestor.

Asimismo, luego de muchas lunas, una base de datos puede haber crecido enormemente, conservando mucha información que es muy valiosa para el usuario y quizá para el mundo entero. Por ello, puede que lamentablemente se haga cada vez más difícil y lento acceder a la información. De allí que el gestor de base de datos tenga que evolucionar. Los desarrolladores han tenido que incorporar nuevas técnicas y mejorar otras para reducir los tiempos de espera durante un procedimiento de búsqueda y entrega de resultados para una consulta SQL.

En ese sentido, es posible que en la medida como la información contenida en una base de datos resulta ser muy valiosa, esta tenga alta demanda, es decir, mucha gente y/o servicios quieren acceder a ella, lo que puede llevar a problemas de concurrencia. En este punto, se debe evaluar si el gestor de base de datos utilizado está a la altura de todas estas exigencias.

Esto, a su vez, lleva otro aspecto relevante, a saber, la existencia de diferentes tipos de gestores, cada uno desarrollado para comportarse eficientemente de acuerdo a la explotación que se les realiza. Una analogía para entender esto son los tipos de vehículos:

Existen vehículos de uno o más pasajeros, de pequeño tamaño y ligero, algunos cuentan con compartimiento para carga, otros destinados a dar el máximo confort, etc. ¿Cuál de estos vehículo es mejor? La respuesta es que no son comparables, están diseñados para ser utilizados en entornos diferentes y de manera similar ocurre con los gestores de bases de datos. Claro está, cuando dos gestores están desarrollados para entornos similares, entonces si son comparables. Sería como comparar dos vehículos de carga pero de diferentes fabricantes.

Ahora bien, es comprensible que existan varios gestores de base de datos, algunos muy simples, otros regulares, otros más complejos, etc. En un próximo artículo se dará a conocer un poco más acerca de estos gestores de base de datos y se plantearán escenarios hipotéticos un tanto más complejos, de manera que se pueda visualizar qué tipo de gestor se debe utilizar en cada caso.