Características de las Bases de Datos

Este elemento es una expansión del contenido de los cursos y guías de Lawi. Ofrece hechos, comentarios y análisis sobre este tema. [aioseo_breadcrumbs]

Funcionamiento y Características de las Bases de Datos

Los datos a los que están acostumbrados los estudiosos del humanismo -obras literarias, acontecimientos históricos, recensiones textuales, fenómenos lingüísticos- no suelen ser, por supuesto, sencillos.

Puntualización

Sin embargo, haríamos bien en tener en cuenta que lo que podría considerarse una inadecuación fundamental ha resultado ser a menudo el principal atractivo de los sistemas de bases de datos relacionales para los estudiosos del humanismo.Entre las Líneas En lugar de explotar una congruencia natural entre las ontologías relacionales y los datos humanísticos, los estudiosos han buscado a menudo la comprensión de las muchas formas en que la estructura relacional impone un cierto alejamiento de lo natural. Los términos que utilizamos para describir los libros en una librería (autores, obras, editores) y las relaciones entre ellos (publicado por, creado por, publicado en) poseen una estabilidad aparente para la que el modelo relacional es ideal. Los trabajos de bases de datos más apasionantes en la informática de las humanidades se lanzan necesariamente sobre un territorio menos seguro. Donde el profesional de los negocios podría tratar de capturar las ventas de billetes de avión o los datos de los empleados, el erudito humanista busca capturar acontecimientos históricos, encuentros entre personajes, ejemplos de formaciones dialécticas o ediciones de novelas; donde el contable podría expresar las relaciones en términos como “tiene seguro” o “es el supervisor de”, el humanista interpone las sugestivas incertidumbres de “fue influenciado por”, “es simultáneo a”, “se parece a”, “se deriva de”.

Este tipo de relaciones ofrecen la posibilidad no sólo de una mayor capacidad de almacenar y recuperar información, sino de una mayor autoconciencia crítica y metodológica. Si la base de datos permite localizar rápidamente un hecho o una relación, también permite que surja la conexión fortuita. Las bases de datos relacionales en el estudio humanístico son, en este sentido, no tanto mecanismos pre-interpretativos como formaciones para-interpretativas. Como ocurre con tantas actividades similares en las humanidades digitales, el acto de creación es a menudo tan vital para el significado experiencial del esfuerzo académico como el uso del producto final.

Los sistemas de gestión de bases de datos relacionales (RDBMS) representan la forma más popular de crear ontologías con capacidad de búsqueda, tanto entre los humanistas informáticos como entre los profesionales de otras áreas de la investigación y la industria, por lo que este capítulo se ocupará principalmente del diseño y la implementación de sistemas de bases de datos que utilizan el modelo relacional.

Puntualización

Sin embargo, el panorama moderno de las bases de datos sigue evolucionando.

Una Conclusión

Por lo tanto, también es conveniente considerar hacia dónde pueden ir las bases de datos (y hacia dónde pueden ir los humanistas con la tecnología de bases de datos).

El modelo relacional

E (se puede repasar algunas de estas cuestiones en la presente plataforma online de ciencias sociales y humanidades). F. Codd propuso por primera vez el modelo relacional en un artículo de 1970 en Communications of the ACM titulado “A Relational Model of Data for Large Shared Databanks”. La propuesta de Codd pretendía superar las limitaciones de los sistemas anteriores, que adolecían de dificultades relacionadas tanto con un acceso ineficiente (es decir, lento) como con mecanismos de almacenamiento poco manejables, ineficiencias que a menudo se debían a redundancias en la representación de los datos subyacentes. El modelo de Codd supuso un gran avance en ambas áreas, pero su logro es quizá más evidente en la presentación matemática de sus ideas.

Este documento de 1970, quizás el más famoso de toda la historia de la gestión de bases de datos, también fue innovador. La gran idea de Codd fue que una base de datos podía considerarse un conjunto de relaciones, que una relación podía considerarse a su vez un conjunto de proposiciones y que, por lo tanto, todo el aparato de la lógica formal podía aplicarse directamente al problema del acceso a las bases de datos y a otros problemas relacionados.

Esta idea fundamental ha dado lugar a una amplia literatura dedicada a la teoría de las bases de datos, y aunque se han producido varias adiciones importantes al modelo relacional, las bases de datos relacionales de hoy en día siguen funcionando sobre la base de las ideas de Codd.

Diseño de la base de datos

El objetivo de una base de datos es almacenar información sobre un dominio concreto (a veces llamado universo del discurso) y permitir que se hagan preguntas sobre el estado de ese dominio. Supongamos, por ejemplo, que estamos creando una base de datos que contendrá información sobre las ediciones actuales de novelas americanas. Nuestro objetivo será crear un sistema que pueda almacenar información sobre autores, obras y editoriales, y que nos permita hacer preguntas como “¿Qué publicaciones hizo Modern Library en 1992?” y “¿Qué obras de Herman Melville se imprimen actualmente?”. La base de datos más sencilla de todas se limitaría a enumerar los datos en forma de tabla.

Esta base de datos podría ampliarse para incluir una amplia colección de autores y obras. Con la adición de algún mecanismo con el que almacenar y consultar los datos, podemos imaginar fácilmente un sistema capaz de responder a las preguntas que nos gustaría plantear.

Puntualización

Sin embargo, las ineficiencias, que el modelo relacional intenta superar, son evidentes incluso en este sencillo ejemplo. Una búsqueda de “Mark Twain” requerirá que el sistema continúe iterando a través de las filas después de haber encontrado su primer resultado para asegurarse de que se han encontrado las coincidencias pertinentes. Esto se debe a que nuestro modelo de datos permite -y de hecho exige- que se introduzca el nombre del autor en cada fila en la que se introduce una nueva obra. Se producen redundancias similares con las fechas de publicación, los nombres de las editoriales y las direcciones de los editores.

Otros Elementos

Además, un cambio en el nombre de un autor (por ejemplo, la decisión de introducir “Samuel Clemens” en lugar del seudónimo del autor) requerirá que actualicemos todos los campos en los que aparece el nombre original. Incluso si ideamos algún mecanismo para garantizar una cierta vigilancia por parte de la máquina, seguimos teniendo una versión del mismo problema: tener que ir a “lugares en lugar de a uno solo”.Entre las Líneas En nuestro ejemplo, la redundancia no parece problemática: cualquier máquina puede hacer un trabajo rápido con una base de datos de seis elementos”.Entre las Líneas En un sistema que contenga miles o quizá millones de elementos, el tiempo y el espacio extra que requieren los algoritmos de búsqueda pueden convertirse en un grave problema.

El modelado relacional intenta eliminar estas redundancias del sistema. Podemos empezar a modificar nuestro diseño original aislando las entidades individuales del dominio a un nivel más abstracto; es decir, localizando los tipos de información que varían independientemente unos de otros.

Un esquema preliminar podría surgir como una posible representación del dominio, con una entidad concreta con un conjunto de atributos asociados. Hemos conservado toda la información del diseño original, pero hemos aislado las distintas entidades entre sí según ciertas agrupaciones lógicas: autores (que tienen apellidos, nombres y fechas de nacimiento y muerte), obras (que tienen títulos y años de publicación) y editores (que tienen nombres y ciudades donde tienen su sede). A menudo, los sustantivos que utilizamos para describir el dominio y la recurrencia de la palabra “tener” ayudan a establecer estas entidades y sus atributos. A este esquema básico podemos añadir también un conjunto de frases verbales que describen la naturaleza de las relaciones entre las entidades. Por ejemplo, los autores crean obras, y las obras son, a su vez, publicadas por las editoriales. La adición de esta información puede dar lugar a lo que se denomina un diagrama de relaciones entre entidades (ER).

Este diagrama recoge las relaciones básicas que hemos aislado, pero queda por decir cuántas instancias de una misma entidad pueden asociarse con otras entidades del modelo. Por ejemplo, un autor puede contratar con varias editoriales, y una editorial puede ofrecer muchas obras diferentes de varios autores. Hay varias formas de plasmar estas características en un diagrama1. Utilizaremos simplemente el número “1” para indicar una única instancia y una “M” para indicar múltiples instancias. Podemos entonces leer la línea de relación que conecta autores y obras para significar “Un autor tiene muchas obras”.

Hasta ahora, hemos perseguido el diseño lógico de nuestra base de datos, un diseño totalmente independiente tanto de la eventual representación de los datos por parte de la máquina como de la visión del usuario final de la información contenida en ella. Llegados a este punto, haríamos bien en imaginar cómo podría poblarse esta estructura lógica con las instancias particulares del primer modelo. Para ello, tenemos que hacer un sutil cambio mental en la forma de ver el diagrama entidad relación. Podríamos tener la tentación de ver las distintas cajas como áreas de almacenamiento que pueden contener instancias de apellidos de autores, títulos de obras, etc.

Puntualización

Sin embargo, en realidad hemos estado modelando la forma genérica que adoptarán las instancias particulares de datos. La base de datos poblada se concibe adecuadamente como un conjunto de tablas con filas y columnas, en las que cada fila corresponde a las entidades y cada columna a los atributos del diagrama ER. Estas filas suelen denominarse registros y la intersección de filas y columnas, campos.

Esta visión más concreta de nuestra base de datos capta las entidades, pero no menciona las relaciones. Para representar las relaciones entre los registros, necesitamos introducir alguna variable que pueda contener estas conexiones.

Nuestra capacidad para hacerlo mejorará significativamente si podemos idear alguna forma de referirnos a cada instancia individual de una entidad concreta como un dato único. Al fin y al cabo, la base de datos final no se limitará a relacionar los autores con las obras de forma genérica, sino que reflejará el hecho de que, por ejemplo, el autor Mark Twain creó tanto Huckleberry Finn como Tom Sawyer. El método habitual para establecer esta unicidad es crear una clave primaria para cada registro: un valor único asociado (véase qué es, su concepto jurídico; y también su definición como “associate” en derecho anglo-sajón, en inglés) a cada registro individual de una tabla2. Este valor es simplemente un nuevo atributo que se puede añadir a nuestro diagrama ER, y por extensión, una nueva columna en la base de datos final para cada tipo de registro. La entidad autor, por ejemplo, puede ser modificada.

Existe otro tipo de relación en este ámbito que no está representado; se trata de la relación muchos-a-muchos (M:M). Esta situación podría darse fácilmente si varios editores publican ediciones de la misma obra. Naturalmente, describiríamos esta relación como si fuera, al igual que todas las relaciones del diseño actual, de uno a muchos, pero en este caso, ya existe una relación de uno a muchos que va en sentido contrario (de “Editores” a “Obras”). Uno podría verse tentado a introducir simplemente una clave foránea que apunte a “Obras” desde “Editores” para complementar la clave foránea que apunta de “Editores” a “Obras”.

Puntualización

Sin embargo, la solución más adecuada es abstraer la relación en una nueva entidad llamada asociación (o tabla de unión). Una asociación es simplemente una nueva tabla que contiene las dos claves foráneas relacionadas (véase la tabla 15.6). Esta asociación captura el hecho de que Penguin USA (Pub ID 1) publica Las aventuras de Huckleberry Finn (Work ID 1) y una edición de Tom Sawyer (Work ID 2).

A cada registro de una asociación se le puede asignar una clave primaria, pero en este caso (y en el de la mayoría de las asociaciones) se entiende que la combinación de las dos claves primarias representa una combinación única.

Una Conclusión

Por lo tanto, la mayoría de los SGBDR permiten declarar que el par de valores es la clave primaria de ese registro (la creación de estas claves compuestas se tratará en la siguiente sección).

Ahora hemos analizado nuestro dominio con el modelado entidad-relación y hemos empezado a factorizar las principales redundancias del modelo. Los lectores interesados en la explicación formal de estas metodologías encontrarán abundantes recursos en la literatura académica del campo, y aunque no es necesario entrar en estos asuntos aquí, al menos un aspecto de la discusión más técnica merece ser mencionado incluso en un contexto introductorio.

Los teóricos de las bases de datos (y los diseñadores serios) suelen hablar de las bases de datos como de una de las cinco formas normales. Las formas normales pueden expresarse en términos de teoría de conjuntos, pero también pueden expresarse más sencillamente como criterios de diseño para juzgar la solidez del propio diseño. Por ejemplo, en cada intersección de fila y columna, debe haber uno y sólo un valor, y ese valor debe ser atómico: no puede haber grupos repetidos en una tabla que satisfaga la primera forma normal.

Cuando una base de datos está en quinta forma normal, se ha eliminado toda la redundancia; las tablas normalizadas hasta este punto consisten en poco más que claves primarias. Esto tiene la ventaja de facilitar al RDBMS la garantía de la integridad general de los datos, pero se puede encontrar que las consultas sobre esos datos se vuelven bastante confusas de componer. Como en la mayoría de los asuntos relacionados con la programación informática, hay que equilibrar los objetivos de corrección con las exigencias prácticas del sistema y sus usuarios.

Diseño de esquemas

Hasta ahora, nuestras reflexiones sobre el diseño de bases de datos se han limitado a lo que normalmente se hace en la pizarra. La implementación real del diseño es mucho más parecida a la programación. Afortunadamente, en la fase de implementación hay poco que requiera nuevos conceptos; en su mayor parte, sólo tenemos que traducir nuestro diseño en una representación inteligible para la máquina. Esta representación suele denominarse esquema de base de datos, y se crea utilizando el lenguaje de consulta estructurado (SQL).

Hay una serie de excelentes RDBMS compatibles con SQL disponibles para los académicos humanistas. La mayoría de los proyectos informáticos de humanidades que utilizan bases de datos emplean sistemas libres (de código abierto), de los cuales los más populares son MySQL, mSQL y Post-greSQL. También se utilizan varios sistemas comerciales (Oracle, Microsoft Access, IBM DB2). Los sistemas difieren un poco en sus características y en la cantidad de documentación disponible, pero todos ofrecen implementaciones eficientes y ricas en características del modelo relacional con funciones avanzadas de seguridad y gestión. Para nuestra base de datos, utilizaremos PostgreSQL, un RDBMS gratuito y bien soportado para sistemas tipo Unix que puede descargarse a través de Internet.

El esquema de la base de datos no es más que una representación legible por la máquina del diagrama ER. Podemos empezar por exponer las distintas entidades y sus atributos, pero como ahora estamos dando instrucciones a la máquina, tenemos que ser más específicos sobre la naturaleza precisa de los datos que hay que introducir.

Como la mayoría de los lenguajes de programación, SQL incluye la noción de tipo de datos. Las declaraciones de tipos de datos ayudan a la máquina a utilizar el espacio de forma más eficiente y también proporcionan una capa de verificación para cuando se introducen los datos reales (de forma que, por ejemplo, un usuario no puede introducir datos de caracteres en un campo de fecha).Entre las Líneas En este ejemplo, hemos especificado que los campos apellido, nombre, título, ciudad y nombre contendrán datos de caracteres de longitud variable (que no deben exceder los 80 caracteres), y que los campos año_de_nacimiento, año_de_cuna y año_público contendrán datos enteros. Otros tipos de datos posibles son DATE (para datos de día, mes y año), TEXT (para grandes bloques de texto de longitud indeterminada) y BOOLEAN (para valores verdadero/falso). La mayoría de estos tipos se pueden especificar para tener en cuenta diferentes formatos de fecha, bases numéricas, etc. PostgreSQL, en particular, soporta una amplia gama de tipos de datos, incluyendo tipos para formas geométricas, direcciones de Internet y cadenas binarias.

Las bases de datos a menudo difieren en la forma en que representan (y aseguran la integridad de) las claves primarias.Entre las Líneas En PostgreSQL, el método habitual es crear un mecanismo separado para generar y mantener un registro de valores numéricos únicos, y hacer que las tablas que contienen las entidades recuperen un valor de ese mecanismo cada vez que se crea un nuevo registro.

La designación de claves primarias y foráneas es uno de los aspectos más importantes del diseño del esquema, porque ayuda al sistema a conseguir lo que se llama integridad referencial. La integridad referencial se ve comprometida cuando eliminamos un registro que contiene una referencia a otro registro. Así, por ejemplo, si eliminamos un autor de la tabla de autores, podríamos dejar una referencia a ese autor en la tabla de obras sin un referente. Un buen RDBMS utilizará las referencias de clave primaria y foránea para evitar que esto ocurra o para advertir al administrador de la base de datos de que la operación dará lugar a una referencia colgante (a veces llamada puntero nulo).

El método para crear una base de datos vacía e introducir este esquema en el RDBMS varía de un sistema a otro. La mayoría de los RDBMS proporcionan herramientas de línea de comandos para configurar bases de datos y para ejecutar comandos a través de un intérprete de comandos interactivo. La documentación del RDBMS en cuestión tratará estos temas en detalle.

Modelos alternativos

El modelo de base de datos relacional ha tenido un gran éxito. Los modelos anteriores -bases de datos jerárquicas y bases de datos en red- apenas se utilizan hoy en día, y parece claro que el modelo relacional seguirá siendo el dominante durante muchos años11.

Puntualización

Sin embargo, hay una serie de modelos competidores que han sido objeto de investigación activa en los círculos de la informática y la tecnología de la información durante las dos últimas décadas. Aunque ninguno de ellos está tan extendido como el modelo relacional, la habitual propensión a la exploración y a la adopción temprana entre los humanistas de la informática puede servir para que estos modelos adquieran protagonismo en la investigación de las humanidades.

El competidor más activo por la prominencia del modelo relacional es el modelo de base de datos orientado a objetos (OO). El impulso para su creación radica en el uso generalizado del paradigma (un conjunto de principios, doctrinas y teorías relacionadas que ayudan a estructurar el proceso de investigación intelectual) de la programación orientada a objetos entre los ingenieros de software.

Basado en la experiencia de varios autores, mis opiniones, perspectivas y recomendaciones se expresarán a continuación (o en otros lugares de esta plataforma, respecto a las características en 2026 o antes, y el futuro de esta cuestión):

Informaciones

Los detalles de este paradigma (un conjunto de principios, doctrinas y teorías relacionadas que ayudan a estructurar el proceso de investigación intelectual) están fuera del alcance de esta discusión, pero se puede entender el modelo a partir de la observación de que los esquemas relacionales se basan en una concepción más antigua de la programación en la que los datos y los procedimientos para manipular esos datos se mantienen separados entre sí.Entre las Líneas En nuestra base de datos, por ejemplo, los datos relativos a los autores están totalmente separados de las distintas operaciones (consultas) que queremos realizar con esos datos. El modelo orientado a objetos propone que los datos y los procedimientos se refactoricen en objetos discretos. Así, los datos de la tabla de autores y los elementos de las operaciones que pueden realizarse sobre ellos pertenecerían a la misma estructura básica. Los partidarios de la OO argumentan que este modelo facilita el mantenimiento al crear menos dependencias entre los elementos de datos, permite crear módulos de datos reutilizables que pueden trasladarse fácilmente de un contexto de base de datos a otro y crea una cierta riqueza semántica (mediante la creación de jerarquías de herencia) en los datos que no se puede conseguir con métodos más convencionales.

Mientras que los desarrolladores de bases de datos más convencionales se han mostrado reacios a adoptar este modelo por completo, el panorama de las bases de datos relacionales ha comenzado a ver implementaciones que se autodenominan sistemas de gestión de bases de datos objeto-relacionales (ORDBMS). Estas implementaciones no llegan a ser las bases de datos totalmente orientadas a objetos que los investigadores imaginan, pero toman prestadas las nociones de herencia (hacer que una tabla “herede” propiedades de otra sin duplicarlas) y de creación de objetos complejos que suelen asociarse a los sistemas orientados a objetos. Parece claro que la tendencia hacia estos sistemas híbridos continuará.

Las bases de datos y el humanista

Ya sea el historiador que trata de localizar las causas de un conflicto militar, el crítico literario que desentraña las implicaciones de una metáfora o el historiador del arte que rastrea el desarrollo del estilo de un artista, la investigación humanística se revela como una actividad fundamentalmente dependiente de la localización de patrones. Tratar con patrones implica necesariamente el cultivo de ciertos hábitos de visión; como ha afirmado un crítico: “Reconocer un patrón implica permanecer abierto a las reuniones, agrupaciones, racimos, repeticiones, y responder a las relaciones internas y externas que establecen” (Hunter 1990). De todas las tecnologías en uso entre los humanistas informáticos, las bases de datos son quizás las más adecuadas para facilitar y explotar dicha apertura. Para construir una base de datos hay que estar dispuesto a pasar del bosque a los árboles y viceversa; utilizar una base de datos es cosechar los beneficios de la visión mejorada que ofrece el sistema.

Los humanistas han utilizado bases de datos relacionales como motores de complejos sistemas de visualización, archivos de texto y obras multimedia.Entre las Líneas En la mayoría de los casos, la intención ha sido simplemente aprovechar las eficiencias del modelo relacional como medio para almacenar y recuperar la información necesaria para poblar un mapa, cargar una lista de aciertos o montar un sitio web.

Puntualización

Sin embargo, incluso en estas aplicaciones relativamente sencillas queda claro que la ontología subyacente tiene un valor intelectual considerable. Una base de datos bien diseñada que contenga información sobre personas, edificios y eventos en la ciudad de Nueva York no contiene información estática, sino todo un conjunto de relaciones ontológicas capaces de generar afirmaciones sobre un dominio. Una base de datos verdaderamente relacional, en otras palabras, no contiene simplemente “México”, “Javier Gonzalez” y “2021”, sino una cadena mucho más sugerente de relaciones lógicas (por ejemplo, “Javier Gonzalez presentó su libro en México durante 2021”).

Una posible vía para el futuro puede ser explotar aún más las implicaciones de la creación de bases de datos colaborativas. Una base de datos, como hemos visto, puede configurarse de forma que permita a múltiples usuarios acceder a los mecanismos de inserción del sistema. Los retos que propone esta posibilidad son importantes, ya que la solidez de un sistema depende en gran medida de su coherencia. Habría que idear mecanismos de reglas aplicables (muy por encima del nivel de la mera gestión de transacciones) para garantizar dicha coherencia.

Puntualización

Sin embargo, el empleo exitoso de tales sistemas en contextos humanísticos ampliaría considerablemente las posibilidades de representación del conocimiento. Dado que los datos entrarían en el sistema a partir de varias fuentes diferentes, las afirmaciones lógicas que surgirían de esa ontología excederían necesariamente el conocimiento de cualquier individuo. El poder de las bases de datos relacionales para permitir la aprehensión serendípica de las relaciones sería mucho mayor.

Hay, por supuesto, amplios precedentes del uso de estructuras de datos complejas y gestionadas en colaboración en la investigación humanística. Las primeras concordancias se elaboraron nominalmente para ayudar a los estudiosos a localizar pasajes en la Biblia, y uno de los primeros usos de los ordenadores en el estudio humanístico fue una concordancia de Tomás de Aquino.Entre las Líneas En ambos casos, el objetivo final no era la recuperación eficiente, sino la comprensión interpretativa. Parece apropiado que después de haber diseñado e implementado sistemas relacionales, y de haber cosechado los beneficios de las eficiencias que conceden, consideremos el papel que pueden desempeñar en las variadas actividades que han descendido de lo que una vez se llamó – apropiadamente – la alta crítica.

Datos verificados por: Brooks

Recursos

Véase También

Bibliografía

Comunicación, control de accesos, control limitado, Datos, Derechos Morales, Privacidad, Información, Información y tratamiento de la información, Informática y tratamiento de datos, Privacidad de Datos Personales, Sistema de comunicación, Telecomunicación, Tratamiento de datos, Videotex

▷ Esperamos que haya sido de utilidad. Si conoces a alguien que pueda estar interesado en este tema, por favor comparte con él/ella este contenido. Es la mejor forma de ayudar al Proyecto Lawi.