Antes de abordar el desarrollo pormenorizado de los procedimientos metodológicos de cada una de las tres fases descritas anteriormente, vamos a abordar un apartado dedicado a la construcción de un sistema de información: contenedor sistematizado de los datos y generador de información a través del potencial del lenguaje SQL y PLSQL, y de sus capacidades de geoprocesamiento, tanto las propias como las que un software GIS puede explotar de ese sistema.
Las BBDD son la parte fundamental del engranaje de un sistema de información. La característica fundamental de los sistemas de información es su capacidad de introducir, recuperar, modificar, seleccionar y analizar datos, y como resultará evidente, qué mejor
contenedor que una Base de Datos.
Muchos arqueólogos pasaron ya del papel al formato digital, de las fichas más o menos desarrolladas a la introducción de sus datos en un ordenador. La mayoría de los arqueólogos, aunque no lo sepan y no se lo crean, a pesar del cambio experimentado siguen trabajando en papel, siguen pensando sobre papeles o sobre prodigiosas memorias personales, y siguen interpretando, cuando lo hacen, utilizando una parte del potencial de sus datos, sin aprovechar toda la información que estos pueden ofrecer, simplemente porque no están sistematizados y guardados en simples BBDD.
En realidad pasar de guardar los datos en fichas de papel o cuadernos a hacerlo en un ordenador de manera digital no es muy diferente. La principal ventaja es la capacidad de copia y reproducción de sus listados de datos, tanto en forma de tablas de elementos como en planimetrías.
Los más intrépidos se atreven a dar algunos pasos más de esta simple forma moderna de almacenar los datos. En el caso de la información alfanumérica, es decir de las propiedades y características, aprovechando las funcionalidades mínimas de los programas de gestión de bases de datos, llegan a realizar operaciones de conteo de variables, incluso identificándolas de la totalidad, lo que les abre las puertas de la estadística básica: porcentajes, máximos, mínimos, etc.
Los que buscan más allá, se aventuran con programas más complejos, avanzan más en los aportes de la estadística, y consiguen sacar información más compleja de sus datos, es decir estadísticamente hablando. Los análisis de componentes principales, por ejemplo, tratan de taxonomizar los datos buscando conjuntos formales más o menos diferentes entre sí y en cuyo seno se guarden los ejemplares que habrán de servir de fósiles guía en la interpretación, la cual, y partiendo de estos principios, no va más allá de lo cronológico y/o lo funcional.
Y en ello estamos. Con una BBDD de las que se pueden fabricar con los sistemas de gestión de bases de datos al uso, cuyo potencial está reducido en la mayoría de los casos al almacén de datos más o menos estructurados, que dependerá a su vez de quien modeliza la BBDD, no se puede aspirar a mucho más de lo que consiguen los arqueólogos más aventurados. Para ello necesitamos algo más, por un lado que nuestra BBDD sea de tipo relacional y que tenga capacidades topológicas, es decir, que fabriquemos un Sistema de Información Geográfico para albergar nuestros datos.
Habíamos comentado también acerca de las posibilidades de hacer planimetrías. Normalmente los arqueólogos suelen trabajar con programas CAD (Computer Aided Design) cuya capacidad de fabricar complejas y bonitas planimetrías es evidente y demostrada. Pero más allá de esto, y de la posibilidad de reproducir y copiar de manera rápida y barata sus datos, en cuanto a su vertiente gráfica se refiere, las posibilidades son muy limitadas.
Como mucho se consigue aislar cada dato en un apartado distinto de características formales con respecto a los demás, características definidas a priori por el arqueólogo, basándose en la mayoría de las veces en su intuición y/o experiencia. La conclusión es una nueva taxonomía, esta vez no dirigida a obtener fósiles guía, sino a dividir funcionalmente y/o cronológicamente los datos, para representarlos planimétricamente y para utilizar esa taxonomía como explicación.
Nos estamos perdiendo la posibilidad de relacionar nuestros datos entre sí, tanto a nivel de características como espacialmente. Nos estamos perdiendo la posibilidad de realizar consultas complejas que nos permitan navegar entre nuestros datos filtrando aquella información que queremos obtener, incluso espacialmente. No podemos hacer geoestadística si no tenemos relación entre la parte alfanumérica y la geométrica y además no tenemos está perfectamente georreferenciada y topológicamente correcta. Y lo que es más grave, no
estamos obteniendo toda la información que nuestros datos contienen o son capaces de inferir, porque las herramientas de análisis espacial y geoprocesamiento, cuando existen y las podemos utilizar no sirven porque nuestros datos no están preparados para ser operados por ellas.
3.2.1.- Base de datos relacional vs tablas de almacenamiento
"Una base de datos es la organización de una colección de datos que se interrelacionan, se comparten y se controlan" (Hansen y Hansen, 1997). De la definición anterior extraemos que una BBDD debe:
● albergar datos según una estructura conveniente diseñada de antemano;
● propiciar la interrelación de hechos para producir información;
● tener control sobre la naturaleza y formato de los datos que se incorporan a ella, de manera que se garantice la calidad de los mismos.
De todo ello derivamos el aspecto diferencial entre una BBDD de una simple tabla almacén de datos: su capacidad relacional. Este modelo relacional nace en los años 70, propuesto por E.F. Codd (Codd, 1970) y que podemos resumir en tres puntos:
● los datos se recogen en forma tabular, de forma que cada tabla del sistema recoge una colección de objetos homogéneos en sus propiedades y estructura;
● cada tabla describe los objetos que contiene en base a una colección arbitraria de propiedades, llamadas campos;
● cada colección de objetos (es decir, cada tabla) puede establecer relaciones con otros objetos (es decir, con otras tablas) siempre que se relacionen gracias a sus
propiedades (sus campos).
El uso de un tipo u otro de almacenamiento y gestión de nuestros datos va a incidir directamente en el Sistema de Información que diseñemos para la obtención de información y el desarrollo de análisis espacial. De esta manera podemos establecer las siguientes diferencias entre ambos usos.
Tablas de almacenaje
En las tablas de almacenaje la información sobre hechos concretos se alberga en ficheros independientes. Toda la información relevante para un hecho determinado ha de estar en el mismo fichero. No son sistemas de bases de datos propiamente dichos.
Básicamente no tiene ventajas como sistema ya que no lo es, pero si presenta graves inconvenientes.
Es evidente su inoperancia a la hora de establecer relaciones entre hechos. Las tablas son propensas a la duplicidad de los datos, y por tanto a las inconsistencias entre ellos. La flexibilidad y extensibilidad son nulas y la explotación de los datos es costosa y engorrosa.
Principales obstáculos, por tanto, de este modelo son la redundancia y las inconsistencias, así como la imposibilidad de rastrear relaciones entre datos rápida y cómodamente. Todo es tremendamente artificioso.
Base de datos
Los hechos se recogen en tablas (colecciones) de objetos que tienen columnas (propiedades) homogeneizadas. Se establecen conexiones entre las tablas gracias a la referencia mutua de columna a columna, por lo que las relaciones entre los hechos son establecidas gracias a la propia lógica interna de los datos, de una forma natural y lógica.
Como los hechos se relacionan gracias a su lógica interna, la capacidad de modelado, la flexibilidad y la ampliabilidad están garantizadas. La atomización de los hechos en objetos bien definidos, lógicos y naturales, conlleva una inexistente redundancia en los datos, minimizando las incongruencias y proporcionando una gran estabilidad y control de la calidad de los mismos.
Los sistemas de bases de datos presentan numerosas ventajas que se pueden dividir en dos grupos: las que se deben a la integración de datos y las que se deben a la interfaz común que proporciona el SGBD.
Entre las ventajas por la integración de datos tenemos:
1. Control sobre la redundancia de datos. Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos. En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos, o bien es necesaria para mejorar las prestaciones.
2. Consistencia de datos. Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes. Desgraciadamente, no todos los SGBD de hoy en día se encargan de mantener automáticamente la consistencia.
3. Más información sobre la misma cantidad de datos. Al estar todos los datos integrados, se puede extraer información adicional sobre los mismos.
4. Intercambio de datos. En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos puede ser compartida por todos los usuarios que estén autorizados. Además, las nuevas aplicaciones que se vayan creando pueden utilizar los datos de la base de datos existente.
5. Mejora en la integridad de datos. La integridad de la base de datos se refiere a la validez y la consistencia de los datos almacenados. Normalmente, la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de mantenerlas.
3.2.2.- El modelo relacional
El modelo relacional se basa en las relaciones lógicas entre los datos. Se trata de un modelo donde los datos se representan por tablas. Una tabla es una estructura de dos dimensiones que contiene filas y columnas. Estas últimas son las que se denominan como atributos de la tabla, mientras que las filas son cada uno de los registros de la tabla, es decir, de los elementos diferenciables dentro de una entidad definida. Las dependencias que se establecen entre las tablas son las relaciones.
Para la formalización de una BBDD relacional el modelo más utilizado es el modelo entidad-relación, formado por un conjunto de conceptos que permiten describir la realidad mediante representaciones gráficas y lingüísticas.
Los elementos fundamentales son: la entidad, la relación entre entidades y los atributos de las entidades.
● Entidad: objeto con existencia física (muro, estrato, cerámica, etc) o conceptual (espacio habitacional, cronología, etc)
● Atributo: cada una de las propiedades que describen a una entidad. Dentro de ellos siempre existirá uno que identificará de manera única a cada entidad y que se denominará clave.
● Relación: expresa una conexión bidireccional entre entidades. Es una abstracción de los enlaces que existen entre los objetos.
El procedimiento para que mediante un diseño conceptual realicemos el modelo son las siguientes:
1. Identificar las entidades.
Al margen de su existencia física o conceptual, las entidades serán identificadas teniendo en cuenta la máxima de atomizar el conjunto de datos que se puedan obtener. De esta manera evitaremos cometer errores de normalización de la BBDD y estaremos en disposición de simplificar las búsquedas, consultas, etc.