El poder de una base de datos

1. ¿Qué es una base de datos?

Una base de datos es una colección de datos que se almacena para un propósito específico y se organiza de manera que permite acceder, administrar y actualizar fácilmente su contenido. Aunque esta definición incluye colecciones de datos almacenados como bibliotecas, archivadores y libretas de direcciones, cuando hablamos de bases de datos casi invariablemente nos referimos a una colección de datos que se almacena en una computadora.

Hay dos categorías básicas de bases de datos. La categoría más común es la base de datos transaccional, que se utiliza para almacenar datos dinámicos, como el contenido del inventario, que está sujeta a cambios de forma continua. La otra categoría es la base de datos analítica, que se utiliza para almacenar datos estáticos, como resultados de pruebas geográficas o químicas, que rara vez se modifican.

Estrictamente hablando, una base de datos es solo los datos almacenados en sí, aunque el término se usa a menudo, erróneamente, para referirse a una base de datos y su sistema de gestión (DBMS).

Breve historia de la base de datos:

Los primeros intentos de crear bases de datos informáticas surgieron a mediados del siglo XX. Las primeras versiones estaban orientadas a archivos. Un archivo de base de datos se conoció como tabla porque su estructura era la misma que una tabla de datos en papel. Por la misma razón, las columnas dentro de una tabla se llamaron campos y las filas se llamaron registros. Las computadoras evolucionaron durante ese mismo período de tiempo y se estaba reconociendo su potencial para el almacenamiento y la recuperación de datos.

Las primeras bases de datos informáticas se basaban en un modelo de archivo plano, en el que los registros se almacenaban en formato de texto. En este modelo, no se definen relaciones entre registros. Sin definir tales relaciones, solo se puede acceder a los registros de forma secuencial. Por ejemplo, si quisiera encontrar el registro del quincuagésimo cliente, primero tendría que revisar los primeros 49 registros de clientes en secuencia. El modelo de archivo plano funciona bien para situaciones en las que desea procesar todos los registros, pero no para situaciones en las que desea encontrar registros específicos dentro de la base de datos.

El modelo jerárquico, ampliamente utilizado en entornos de mainframe, fue diseñado para permitir relaciones estructuradas que facilitarían la recuperación de datos. Dentro de una estructura de árbol invertida, las relaciones en el modelo jerárquico son padre-hijo y uno a muchos. Cada tabla principal puede estar relacionada con varias tablas secundarias, pero cada tabla secundaria solo puede estar relacionada con una única tabla principal. Debido a que las estructuras de las tablas están vinculadas de forma permanente y explícita en este modelo, la recuperación de datos fue rápida. Sin embargo, la estructura rígida del modelo causa algunos problemas. Por ejemplo, no se puede agregar una tabla secundaria que no esté vinculada a una tabla principal: si la tabla principal era "Doctores" y la tabla secundaria era "Pacientes", no podría agregarse un registro de paciente de forma independiente. Eso significaría que, si un nuevo paciente ingresara al sistema de atención médica de una comunidad, bajo este sistema, su registro no podría agregarse hasta que tuviera un médico. La estructura jerárquica también significa que, si se elimina un registro en una tabla principal, también se eliminarán todos los registros vinculados a él en las tablas secundarias.

También basado en una estructura de árbol invertida, el siguiente enfoque para el diseño de la base de datos fue el modelo de red. El modelo de red permitía conexiones más complejas que el modelo jerárquico: varios árboles invertidos podrían compartir ramas, por ejemplo. El modelo conectó tablas en conjuntos, en los que un registro de una tabla de propietario podría vincularse a varios registros de una tabla de miembros. Al igual que el modelo jerárquico, el modelo de red permitió una recuperación de datos muy rápida. Sin embargo, también tuvo varios problemas. Por ejemplo, un usuario necesitaría una comprensión clara de la estructura de la base de datos para poder obtener información de los datos. Además, si se cambiaba una estructura de conjunto, también se tendría que cambiar cualquier referencia a ella desde un programa externo.

En la década de 1970, la base de datos relacional se desarrolló para tratar datos de formas más complejas. El modelo relacional finalmente dominó la industria y ha continuado haciéndolo hasta el día de hoy. Exploraremos la base de datos relacional con cierto detalle en el siguiente segmento.

2. ¿Qué es una base de datos relacional?

En el modelo de base de datos relacional, los datos se almacenan en relaciones, más comúnmente conocidas como tablas. Las tablas, los registros (a veces conocidos como tuplas) y los campos (a veces conocidos como atributos) son los componentes básicos. Cada dato individual, como un apellido o un número de teléfono, se almacena en un campo de tabla y cada registro comprende un conjunto completo de datos de campo para una tabla en particular.

En el siguiente ejemplo, la tabla mantiene la información de la dirección de envío del cliente. Apellido y otros encabezados de columna son los campos. Un registro, o fila, en la tabla comprende el conjunto completo de datos de campo en ese contexto: toda la información de dirección que se requiere para enviar un pedido a un cliente específico. Cada registro se puede identificar y acceder a través de un identificador único llamado clave primaria. En la tabla Envío al cliente, por ejemplo, el campo ID del cliente podría servir como clave principal porque cada registro tiene un valor único para los datos de ese campo.

Envío al cliente

El término relacional proviene de la teoría de conjuntos, en lugar del concepto de que las relaciones entre los datos impulsan la base de datos. Sin embargo, el modelo, de hecho, funciona definiendo y explotando las relaciones entre los datos de la tabla. Las relaciones de tabla se definen como uno a uno (1:1), uno a varios (1:N) o, con poca frecuencia, muchos a varios (N:M):

• Si un par de tablas tiene una relación de uno a uno, cada registro de la Tabla A se relaciona con un solo registro de la Tabla B. Por ejemplo, en un emparejamiento de tablas que consta de una tabla de direcciones de envío de clientes y una tabla de cuentas de clientes saldos, cada número de identificación de cliente individual estaría relacionado con un identificador único para el registro de saldo de la cuenta de ese cliente. La relación uno a uno refleja el hecho de que cada cliente individual tiene un saldo de cuenta único.
• Si un par de tablas tiene una relación de uno a muchos, cada registro individual en la Tabla A se relaciona con uno o más registros en la Tabla B. Por ejemplo, en una combinación de tablas que consta de una tabla de cursos universitarios (Tabla A) y una tabla de información de contacto de los estudiantes (Tabla B), cada número de curso individual estaría relacionado con varios registros de información de contacto de los estudiantes. La relación de uno a muchos refleja el hecho de que cada curso individual tiene varios estudiantes inscritos en él.
• Si un par de tablas tiene una relación de varios a varios, cada registro individual en la Tabla A se relaciona con uno o más registros en la Tabla B, y cada registro individual en la Tabla B se relaciona con uno o más registros en la Tabla A. Por ejemplo, en una combinación de tablas que consta de una tabla de información de empleados y una tabla de información de proyectos, cada registro de empleado podría estar relacionado con múltiples registros de proyecto y cada registro de proyecto podría estar relacionado con múltiples registros de empleado. La relación de muchos a muchos refleja el hecho de que cada empleado puede estar involucrado en múltiples proyectos y que cada proyecto involucra a múltiples empleados.

3. ¿De dónde vino el modelo relacional?

El modelo de base de datos relacional se desarrolló a partir de las propuestas de "Un modelo relacional de datos para grandes bancos de datos compartidos", un artículo presentado por el Dr. E.F. Codd en 1970. Codd, un científico investigador de IBM, estaba explorando mejores formas de administrar grandes cantidades de datos delas que estaban disponibles. Los modelos jerárquicos y de red de la época tendían a sufrir problemas con la redundancia de datos y la mala integridad de los datos. Al aplicar el cálculo relacional, el álgebra y la lógica al almacenamiento y recuperación de datos, Codd permitió el desarrollo de un modelo más complejo y completamente articulado que el que existía anteriormente.

Uno de los objetivos de Codd era crear un idioma similar al inglés que permitiera a los usuarios no técnicos interactuar con una base de datos. Basado en el artículo de Codd, IBM inició su grupo de investigación System R para desarrollar un sistema de base de datos relacional. El grupo desarrolló SQL/DS, que finalmente se convirtió en DB2. El lenguaje del sistema, SQL, se convirtió en el estándar de facto de la industria. En 1985, el Dr. Codd publicó una lista de doce reglas para una base de datos relacional ideal. Aunque es posible que las reglas nunca se hayan implementado por completo, han proporcionado una guía para los desarrolladores de bases de datos durante las últimas décadas.

Las 12 reglas de Codd:

1. La regla de la información: los datos deben presentarse al usuario en formato de tabla.
2. Regla de acceso garantizado: los datos deben ser accesibles de manera confiable mediante una referencia al nombre de la tabla, la clave principal y el nombre del campo.
3. Tratamiento sistemático de valores nulos: los campos que no son claves primarias deben poder permanecer vacíos (contener un valor nulo).
4. Catálogo dinámico en línea basado en el modelo relacional: La estructura de la base de datos debe ser accesible a través de las mismas herramientas que brindan acceso a los datos.
5. Regla completa de sublenguaje de datos: la base de datos debe admitir un idioma que pueda usarse para todas las interacciones (SQL se desarrolló a partir de las reglas de Codd).
6. Ver regla de actualización: los datos deben estar disponibles en diferentes combinaciones (vistas) que también se pueden actualizar y eliminar.
7. Insertar, actualizar y eliminar de alto nivel: debería ser posible realizar todas estas tareas en cualquier conjunto de datos que se pueda recuperar.
8. Independencia física de los datos: los cambios realizados en la arquitectura subyacente a la base de datos no deberían afectar la interfaz de usuario.
9. Independencia lógica de los datos: si la estructura lógica de una base de datos cambia, eso no debería reflejarse en la forma en que el usuario la ve.
10. Independencia de integridad: El lenguaje utilizado para interactuar con la base de datos debe soportar las limitaciones del usuario que mantendrán la integridad de los datos.
11. Independencia de distribución: si la base de datos está distribuida (ubicada físicamente en varias computadoras), ese hecho no debería ser evidente para el usuario.
12. Regla de no subversión: No debería ser posible alterar la estructura de la base de datos por ningún otro medio que no sea el idioma de la base de datos.