Actualización: Diciembre 2016. Nueva edición ampliada, explicación más detallada del modelo entidad-relación, aplicación a un caso y bibliografía ampliada.
Bases de datos para dar soporte a una investigación
Como parte de un proyecto de investigación podemos necesitar manejar, a la vez de forma dinámica (p.e., mediante búsquedas cruzadas) y sistemática (representando la información del mismo modo), la información que hemos obtenido como parte de nuestros análisis o los que recopilamos de alguna fuente.
Un ejemplo típico sería una investigación que incluyera alguna clase de análisis de contenido para el cual debemos tratar de forma sistemática centenares (o miles) de unidades de análisis (noticias, fotografías, tweets, etc.).
Probablemente, para cada una de estas unidades tendremos que contemplar diversas propiedades y sus valores, generalmente en forma de texto, como título, palabras clave, categorías, etc., pero posiblemente también con imágenes.
Cuando nos encontramos en esta situación guardar los datos en un procesador de textos o en una hoja de cálculo, no resulta eficiente porque ni su forma de representación ni sus posibilidades de consulta y explotación son óptimas.
En tales casos, necesitamos utilizar un sistema de gestión base de datos (SGBD). El uso de estas herramientas es habitual para académicos, pero en este caso no se trata de usar una para consultar una base de datos desarrollada por terceros, como Web of Science o Scopus.
En este caso, se trata de usar un software con el que (1) tendremos que diseñar una base de datos por nuestra cuenta y (2) después poblarla con los contenidos que nos interesen y que también tendremos que entrar nosotros mismos.
En los dos paquetes ofimáticos más importantes del mercado: Office de Microsoft y LibreOffice, disponemos de sistemas de gestión de bases de datos. Aunque no sean los mejores sistemas para usos de tipo documental si vamos a necesitar gestionar mucho texto, es casi seguro que nos servirán para casi cualquier propósito, ya que estas soluciones cada vez son más versátiles. La cuestión es que, además de ser muy accesibles, disponen de buenas herramientas de desarrollo.
Otros programas de gestión de bases de datos, como FileMaker, en cambio, disponen de mayores facilidades para gestionar tanto datos numéricos como textuales, y por tanto en teoría sería la más adecuada para estas necesidades. El único problema es que no está tan disponible como las de tipo ofimático: necesitamos incorporar un paquete de software nuevo, y no es de dominio público como LibreOffice.
Una vez elegido el software, el menor de nuestros problemas será aprender a usarlo; la curva de aprendizaje puede ser más o menos complicada, pero con un poco de motivación (y la impagable ayuda de los numerosos tutoriales que pululan por Internet) al final acabaremos sabiéndolo hacer.
Porqué necesitamos desagregar la información
El verdadero problema consiste en saber cómo debemos articular la información que queremos controlar (por ejemplo, noticias de prensa para hacer un análisis de contenidos) en las estructuras propias de una base de datos, que son los registros. Y también necesitaremos saber qué campos deben tener los registros para que después podamos usar de forma eficiente los datos que, probablemente, tanto nos habrá costado entrar.
Y no se trata de un caso benigno de prueba y error. Si no dedicamos un tiempo al análisis, antes de proceder a la carga de datos, descubriremos el error (en una forma especialmente perversa de la Ley de Murphy) cuando sea demasiado tarde. Esto puede equivaler a un desastre que, o bien comprometa la calidad o bien la completitud de los resultados que podamos ofrecer (o nos obligue a repetirlo todo).
El motivo por el cual necesitamos saber desagregar la información es doble: por un lado, sin tal desagregación acabaremos entrando muchas veces la misma información, lo que conduce a redundancias, y las redundancias conducen a inconsistencias (sin contar el enorme fastidio de entrar muchas veces la misma información).
El segundo motivo es que, cuanto más articulada y más detallada tengamos la información, más posibilidades tendremos luego de explotación, incluso de formas que tal vez no habíamos pensado nunca.
Adicionalmente, a veces tenemos dudas, aparentemente irresolubles, de tan básicas que parecen: un determinado elemento, ¿es una entidad en sí misma o es un atributo de una entidad? O bien, tal vez ese elemento no es ni una cosa ni otra, ¿sino un conjunto de valores?
La cuestión es que, para poder crear una base de datos primero necesitamos diseñar las dos estructuras en las que se representará la información, a saber:
- Registros: equivalentes a las filas de una tabla, y corresponde a la idea intuitiva de una entidad o cosa que queremos controlar en la base de datos.
- Campos: equivalentes a las columnas de una tabla, y corresponde a la idea de aquellas propiedades o atributos que caracterizan a una entidad.
Tal como hemos dicho, los registros y los campos los podemos ver como tablas, o como fichas. En este caso, la imagen que nos podemos hacer es la típica ficha de un libro del catálogo de una biblioteca, o la ficha de un producto en una tienda electrónica o como la ficha de una película en una base de datos de cinematografía. Pero en el modelo entidad-relación que vamos a usar aquí es costumbre hablar de tablas.
Lo que debemos tener en cuenta para lo que sigue es que entidad, registro y tabla son equivalentes. Así campo, atributo y columna lo son también. Otra idea que necesitamos es la diferencia entre:
- Tipo de entidad
- Ocurrencia de entidad
El tipo de entidad se refiere a la clase general, y la ocurrencia al individuo concreto. Por ejemplo, el tipo de entidad film se refiere a la clase de objetos audiovisuales que conocemos por tal nombre, y de los que se producen varios cientos cada año, mientras que 2001 es una ocurrencia o individuo de tal clase, en concreto el film que dirigió Kubrick en 1968.
La cuestión es que, hasta que no tengamos unos modelos de registro para representar tipos de entidades con sus correspondientes campos bien diseñados, no podremos empezar a entrar datos con la seguridad de que nuestras dudas sobre el diseño de la base de datos han quedado bien resueltas.
Diseño de una base de datos
La idea más simple e importante a la vez cuando se trata de acertar con el diseño de una base de datos es la siguiente: una base de datos es un modelo de una parte del mundo real. Si la estructura de registros y campos captura bien esa parte de la realidad que queremos representar, en principio todo irá bien. ¿Pero cómo podemos estar seguros de una cosa así?
Afortunadamente,disponemos de dos instrumentos de validez largamente demostrada para determinar exactamente qué registros necesitamos y qué campos deben tener, y son los siguientes:
- Modelo entidad-relación
- Diccionario de datos
Vamos a ver algo sobre estas dos herramientas en los apartados que siguen.
El modelo entidad-relación
El modelo entidad-relación es un procedimiento de análisis y diseño aparentemente sencillo (aunque podemos complicarlo todo lo que queramos) para determinar cuál debe ser la estructura de una base de datos en relación con:
- Entidades (ítems o unidades) los elementos o cosas que se van a representar en la misma. Serán modelos de registro y por tanto, tipos de entidades, cuando diseñemos la base de datos. En formato de tabla, serían las filas de la misma.
- Propiedades (campos) de las entidades que se van a representar. Serán los campos de cada registro. En formato tabla, serían las columnas de la misma.
- Relaciones entre las entidades de cara a la explotación posterior de la base de datos. En algunos casos, según veremos se transforman en modelos de registro o tablas para poder representar bien la relación.
Repasemos esta relación triple: (1) una entidad es (2) un tipo de registro que a su vez se puede representar en (3) forma de tabla. Igualmente, este triple lo volvemos a tener si consideramos que (1) una propiedad (2) es uno de los campos del registro que a su vez (3) es una de las columnas en una tabla.
Un cuarto elemento, con un papel aparentemente menor, pero imprescindible a la hora de gestionar la base de datos y de poder establecer las relaciones es la noción de:
- Campo clave o clave primaria. Es aquel atributo que sirve para identificar de manera única a cada entidad. Por ejemplo, en el caso de ciudadanos mayores de edad de un país sería el número de seguridad social (o el DNI en España).
Es cierto que, a veces, se necesita la combinación de varios campos para identificar una entidad de forma inequívoca, pero en estos casos siempre podemos asignar nosotros un identificador único a cada entidad si preferimos trabajar con un solo campo clave.
Un poco más de teoría nos ayudará a entender lo anterior: una base de datos es una forma de representar cosas del mundo real. Por tanto, de algún modo, una base de datos es un intento de modelar (representar) una parte del mundo real en un sistema de información que es un mundo simbólico.
La virtud esperada de un modelo es que sea razonablemente fiel a aquello que modela. Por esta misma razón, si el modelo es inadecuado, la base de datos no funcionará bien.
Por ejemplo, una base de datos de noticias se supone que representa eventos (p.e. un accidente, una crisis de gobierno, la revelación de determinadas informaciones, etc.) dados a conocer en medios de comunicación. Las entidades de esa base de datos son por tanto las noticias y los medios que las publican. Si no conseguimos modelar bien esas entidades y sus relaciones, la base de datos no funcionará bien.
Para representar de forma adecuada esas noticias necesitaremos seleccionar propiedades o atributos de las mismas. Por ejemplo, título, fecha, fuente, temas, etc. El conjunto articulado de esas propiedades se llama registro, y cada una de esas propiedades se llama campo. Así que un registro está compuesto por campos, y cada noticia se representa en un registro rellenando los campos correspondientes.
La otra entidad que deberemos representar en esa base de datos serán cabeceras de diario o medios de comunicación, también con sus correspondientes campos o atributos.
Finalmente, tendremos que ser capaces de determinar la relación entre las dos entidades: noticias y medios de comunicación para poder cruzar información y obtener así informaciones nuevas. Por ejemplo, qué medios publican, y en qué porcentajes, noticias neutras, qué medios positivas y cuál negativas sobre los temas X, Y, Z, etc., de nuestro sistema de análisis de contenido.
Cardinalidad o «tres son multitud»
Para poder aplicar el modelo necesitamos otro concepto, el de cardinalidad. Este concepto se refiere al número de elementos que posee un conjunto. Por ejemplo, el conjunto {a, b, c} es de cardinalidad 3 porque tiene 3 elementos. El conjunto de los meses del año tiene cardinalidad 12 porque tiene 12 meses, etc.
Entonces, en el modelo entidad-relación, la cardinalidad es el número de entidades que participa en cada lado de una relación. Afortunadamente, en el modelo entidad-relación la cardinalidad es algo extremadamente simplificado, porque solo hay tres tipos de relación según la cardinalidad, haciendo bueno el famosos dicho de que «dos son compañía y tres son multitud». Se trata de las siguientes:
- Relación 1:1 (uno-a-uno) Es la que se da cuando la cardinalidad de ambas entidades cómo máximo es igual a uno, es decir, cuando una entidad, digamos de tipo A, solamente puede relacionarse con una entidad de tipo B y viceversa. Por ejemplo, un investigador (A) solamente puede tener un número ORCID (B), y cada número ORCID solamente se asigna a un investigador. Vemos que, a cada entidad de tipo A solamente corresponde una entidad de tipo B y viceversa. Otro ejemplo, un ciudadano solamente tiene un número de la seguridad social, y cada número de seguridad social se asigna a un solo ciudadano. Y aún otro ejemplo más, cada estado-nación (p.e. Francia) tiene una capital, y cada capital (p.e. París) lo es de un solo estado-nación
- Relación 1:N (uno-a-muchos) Es la que se da cuando la cardinalidad de una de las entidades cómo máximo es igual a uno y la cardinalidad de otra puede ser igual a cualquier número. Es la que se puede dar, por ejemplo, entre la entidad medio de comunicación y la entidad noticia, ya que un medio (1) publica muchas noticias (N), pero cada noticia la publica un solo medio (estamos pensando en la pieza periodística concreta, no en el hecho noticiable). Otro ejemplo sería la relación entre Facultades o Departamentos de Universidad y los Grados o Títulos que imparte, según la cual una Facultad (por ejemplo, la de Comunicación de la UPF) imparte diversos Grados, pero en cambio cada Grado es impartido por una sola Facultad (hacemos la simplificación de un sistema donde no puede haber grados interuniversitarios).
- Relación N:M (muchos-a-muchos), Es la que aparece cuando la cardinalidad de ambas entidades puede tener cualquier número. Es la relación que podría darse si quisiéramos diseñar una base de datos del mundo del teatro, ya que estaríamos tratando seguramente con la entidad obras de teatro y la entidad autores teatrales. Ahora si intentamos expresar la relación, vemos que es de muchos-a-muchos, ya que cada autor puede escribir varias obras (N) y una obra de teatro puede haber sido escrita por más de un autor (M). Llevado al terreno de la comunicación es la relación que habría si quisiéramos analizar fotografías de prensa, por ejemplo, donde tendríamos la entidad Fotografías y la entidad Medios de comunicación. Entonces tendríamos que cada Fotografías es publicada por diversos Medios (N), y cada Medio publica diversas Fotografías (M).
Lo interesante es que el tipo de relación nos dice cómo se pueden relacionar los diferentes modelos de registros entre sí (mediante campos comunes) o, y esto es realmente lo más importante, si necesitaremos modelos de registros adicionales para conseguir representar de forma adecuada la relación. La siguiente tabla muestra la posible toma de decisiones en función de la clase de relación detectada:
| Relación | Número de tablas |
| Relación 1:1 | Para representar esta relación podemos necesitar una, dos o tres tablas. Pese a su aparente simplicidad, es el caso que tiene mayores variaciones y el que está sujeto a mayores interpretaciones. Si ambas entidades son obligatorias (ninguna puede tener cardinalidad cero), así una de ellas (entidad fuerte) es la condición de la otra (entidad débil), entonces podemos estar hablando en realidad de una sola entidad, con lo cual necesitaremos una sola tabla. Para seguir con el ejemplo anterior, es la que se daría entre la candidata a entidad llamada número ORCID y la candidata a entidad llamada investigador, ya que cada investigador tiene un único número ORCID; y cada número ORCID es para un solo investigador. En este caso, lo más práctico pued ser considerar que el núnero ORCID es un atributo de un investigador (y no un entidad). O la que se puede dar entre vehículos y números de matrícula, etc. En estos casos, podemos suponer que una de las supuestas entidades es un atributo de la otra. Se supone que la entidad débil (la que existe en función de la otra) se convierte en atributo de la entidad fuerte (la que condiciona la relación), y es entonces cuando necesitamos una sola tabla. Pero si la relación no es obligatoria, es decir, podemos tener la entidad A, pero no siempre tenemos la entidad B, entonces no solamente estamos antes dos entidades reales, sino que necesitamos tres tablas (para evitar la pérdida de datos): una por cada entidad y una tercera para la relación, cuyos campos serán las claves primarias de las dos entidades. Si la relación es obligatoria y hay una relación de tipo entidad fuerte-entidad débil, pero necesitamos registrar diversos atributos de cada entidad, como en el caso de estados (p.e. Francia) y sus capitales respectivas (p.e. París), necesitaremos dos tablas para no tener que duplicar la información. En este caso, cuando usamos dos tablas, al menos una de ellas debe tener un campo con la clave primaria de la otra. Lo más eficaz es que haya un intercambio de claves primarias y cada tabla tenga como uno de sus campos, la clave primaria de la otra tabla. |
| Relación 1:N | Necesitamos siempre dos tablas. Una para cada entidad. La entidad con la cardinalidad N debe tener como uno de sus campos, el campo clave de la entidad con la cardinalidad 1. Esto garantiza un campo común con el mismo dominio, evita la repetición de datos y asegura la relación a la hora de hacer búsquedas. |
| Relación N:M | Necesitamos siempre tres tablas. Una para cada entidad y una tercera para la relación, que pasa así a convertirse en otra entidad. La tabla con la relación tendrá como campos, al menos, las claves primarias de cada entidad. Puede tener otros campos si necesitamos controlar propiedades específicas de la relación. Por ejemplo, en el caso de la base de datos de Fotografías y Medios tenemos la relación Publicada_en en la cual tendremos como dos de sus campos las claves primarias de la entidad Fotografía y de la entidad Medio de comunicación, y además, por ejemplo, campos para atributos propios de la relación, como la fecha de publicación, si la fotografía era portada o interior, el tratamiento, qué pie de foto tenía, etc. |
El diccionario de datos
El diccionario de datos es la compilación sistemática de todos los modelos de registro y de sus campos correspondientes debidamente detallado de manera que si fuera necesario, diversos operadores o investigadores podrían entrar datos minimizando los peligros de inconsistencia.
En todo caso es el documento base necesario para empezar a implementar la base de datos en un programa de gestión de bases de datos determinado. En este documento debemos tener la lista de todas las entidades con sus respectivos atributos o campos. También es el documento que asegura la consistencia cuando diversos investigadores trabajan entrando datos en la misma base de datos.
Después, cada campo deberá ser tratado de forma sistemática mediante una ficha donde aparezcan los componentes clave de cada campos, que deberán estar adecuadamente descritos.
Para el caso de una base de datos de noticias, si nos basamos en un caso real llevado a cabo en su momento para tratar contenidos de noticias, el diccionario de datos podría ser como el que mostramos a continuación:
| Etiqueta | Nombre del campo en la base de datos |
| Dominio | Conjunto de valores que puede adoptar el campo. Se puede enunciar por comprensión o por extensión. |
| Tipo de dato | Naturaleza del dato: numérico, textual, fecha, lógico, calculado, binario, etc. |
| Indización | Se debe indicar si es un campo indizado o no, o sea, si sus valores formarán parte de un índice separado y buscable. |
| Control documental | Se debe indicar si los valores de este campo están sujetos a alguna clase de control terminológico, por ejemplo, si solamente pueden entrarse valores de un tesauro o de una lista de descriptores. |
| Control de integridad | ¿Puede quedar vacío? |
| Observaciones | Observaciones si es el caso |
| Ejemplos válidos | Ejemplos de datos válidos para el campo en cuestión. |
En este artículo (de 1999, pero sigue siendo válido para lo que queremos mostrar aquí) se puede ver un modelo de diccionario de datos para noticias: Documentación periodística y bases de datos: elemento para su fundamentación como disciplina y propuesta de conjunto nuclear de diccionario de datos (Codina, Fuentes, 1999).
Fases
A la vista de lo anterior, si ahora consideramos la cuestión desde el punto de las fases, tendríamos las siguientes:
- Análisis mediante el modelo entidad-relación, lo cual nos dará las entidades, sus atributos y las relaciones entre ellas.
- Diseño conceptual mediante la transformación en tablas del resultado del análisis anterior, según el cual los tipos de entidades son tablas, las ocurrencias de entidades son filas, los atributos son columnas, y las relaciones son también tablas cuando son de tipo N:M.
- Implementación en un diccionario de datos primero, y después en un Sistema de Gestión de Bases de Datos como FileMaker, Access de Microsoft o Base de LibreOffice.
- Entrada de una colección-test de datos. Diseño de formularios. Pruebas de acceso y recuperación de información, obtención de informes, etc.
- Modificaciones en el diccionario de datos, si procede, con las pruebas del paso anterior.
- Carga de datos y explotación.
Materiales complementarios para el diseño de bases de datos
Reseñamos ahora (y facilitamos los enlaces) los dos documentos que nos pueden ayudar a tomar buenas decisiones de diseño de nuestra base de datos, a los que nos hemos referido antes. Aprovecho para ello una asignatura del Máster Universitario en Comunicación Social en la que mostramos a nuestros estudiantes cómo llevar a cabo este proceso. Se trata de los dos que siguen.
Fundamentos conceptuales
La presentación siguiente, resume los conceptos y los pasos en el diseño de una base de datos para un proyecto de investigación puede ser una ayuda:
Diseño de Bases de Datos en Proyectos de Investigación
Conceptos, características y diseño de bases de datos documentales
Finalmente, el documento que sigue incluye no solamente los conceptos principales e indicaciones generales para el análisis y el diseño de bases de datos documentales.
Descargar Tutorial:
Sistemas de Gestión de Bases de Datos Documentales
Conclusiones
Hemos presentado una de las tecnologías más presentes en el mundo de la información actual (tan presentes que nos pasa desapercibida). Muchas investigaciones se resuelven actualmente acudiendo a alguna forma de minería de datos a través de aplicaciones como motores de búsqueda, sistemas SEO como Alexa u otros sistemas de análisis de la web social.
Sin embargo, en algunas investigaciones académicas (y de cualquier clase en general) a veces necesitamos controlar y describir un número de entidades con diversas propiedades y facetas y solamente podemos hacerlo si desarrollamos nuestra propia base de datos. Un caso típico, en la investigación en Comunicación, por ejemplo, serían los análisis de contenido, donde podemos necesitar analizar y describir centenares (o miles de piezas) con criterios propios.
En todas estas situaciones realizar un buen diseño es crítico para después poder explotar la información de forma adecuada, incluso de formas no inicialmente previstas. Lo contrario, proceder a una entrada de datos masiva sin las precauciones de análisis necesarias conducirá inevitablemente o bien a perder posibilidades de explotación o a tener que repetir todo el trabajo.
Para saber más
En este mismo sitio podemos encontrar más información así como un Taller sobre el tema en el siguiente enlace:
Métodos – Talleres: Análisis de Sitios Web y Desarrollo de Bases de Datos
Artículo relacionado: uso de tablas y diagramas en investigaciones cualitativas
Bibliografía
- ABADAL, Ernest; CODINA, Lluís (2005). Bases de datos documentales: características, funciones y método. Madrid : Síntesis, 2005, 220 p.
- (1990). Norma UNE 50-106-90. Documentación. Directrices para el establecimiento y desarrollo de tesauros monolingües. Madrid: AENOR, 1990, 47 p.
- ANDERSON, James D.; PÉREZ-CARBALLO, José (2005). Information retrieval design: principles and options for information description, organization, display, and access in information retrieval databases, digital libraries, catalogs, and indexes. St. Petersburg, Fla.: Ometeca Institute, 2005. 617 p.
- AVISON, D. E.; FITZGERALD, Guy (2003). Information systems development: methodologies, techniques and tools. 3rd ed. London [etc.] : McGraw-Hill, cop. 2003.
- BAEZA-YATES, Ricardo; RIBEIRO, Berthier de Araújo Neto (2011). Modern information retrieval: the concepts and technology behind search. 2nd ed. Harlow [etc.]: Addison-Wesley / Pearson, 2011.
- CACHEDA SEIJO, Fidel; FERNÁNDEZ LUNA, Juan Manuel; HUETE GUADIX, Juan Francisco (2011). Recuperación de la información : un enfoque práctico y multidisciplinar. Madrid : Ra-Ma, cop. 2011. XVIII, 232 p.
- CHECKLAND, P. B. (1999). Soft systems methodology: a 30-year retrospective. Chichester [etc.]: John Wiley, cop. 1999. 330 p.
- CHECKLAND, P. B.; HOLWELL, Sue (1998). Information, systems and information systems: making sense of the field. Chichester [etc.]: John Wiley & Sons, cop. 1998. 262 p.
- CHECKLAND, P. B.; POULTER, J. (2006). Learning for action: a short definitive account of soft systems methodology and its use for practitioner, teachers, and students. Hoboken, NJ: Wiley, cop. 2006.
- CHEN, P.P-S. (2002). «Entity-relationship modeling: historical events, future trends, and lessons learned». BROY, M.; DENERT, E. (eds.). Software pioneers: contributions to software engineering. New York: Springer-Verlag, 2002, p. 296-310.
- CODINA, Lluís (1998). «Metodología de análisis de sistemas de información y diseño de bases de datos documentales: aspectos lógicos y funcionales». BARÓ, J.; CID, P. (eds.). Anuario SOCADI de Documentación e Información 1998. Barcelona: SOCADI, 1998, p. 195-210.
- CODINA, Lluís; FUENTES, M. Eulàlia (1999). «Documentación periodística y bases de datos: elemento para su fundamentación como disciplina y propuesta de conjunto nuclear de diccionario de datos». Bibliodoc, 1999. Acceso en la publicacion: http://www.raco.cat/index.php/Bibliodoc/article/view/16613. Acceso al pdf: http://www.raco.cat/index.php/Bibliodoc/article/view/16613/16454
- CODINA, Lluís (2015). Sistemas de gestión de bases de datos documentales: características principales y metodología de diseño. Barcelona: UPF, 2015 Acceso: http://repositori.upf.edu/handle/10230/24625
- GIL LEIVA, Isidoro (2008). Manual de indización : teoría y práctica. Gijón : Trea, 2008. 429 p.
- LAUDON, Kenneth C.; LAUDON, Jane P. Management information systems: managing the digital firm. 12th ed. Global ed. Harlow, Essex; Boston : Pearson Education, 2011. 630 p.
- RUBIO, María. Documentación informativa en el periodismo digital. Madrid: Síntesis, 2007.
- TEOREY, Toby J. (2011). Database modeling and design: logical design [recurso electrónico]. 5th ed. Burlington, MA : Morgan Kaufmann Publishers/Elsevier, cop. 2011.
