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

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
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 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.
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:

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.