9.3: Apéndice C - Resolución y codificación de bases de datos

Introducción

La mayoría de los problemas que enfrentarás surgen a través de la variabilidad y ambigüedad que inevitablemente acompaña a la información encontrada en fuentes históricas. Los historiadores rara vez son capaces de predecir con confianza la naturaleza de su información, aunque conozcan íntimamente sus fuentes; casi siempre habrá instancias en las que las fuentes nos confundan. Estos pueden ser en forma de información extra en el material que parece estar fuera del alcance de la fuente, o texto faltante o ilegible, o a través de marginales, eliminaciones, etc.

La cronología, la topografía, la geografía, la ortografía y otros contextos históricos introducen un elemento de “fuzziness” en los datos; la fuzziness es kriptonita, el modelo de base de datos relacional. La irregularidad de la información histórica debe ser manejada a través del diseño de la base de datos para lograr un equilibrio entre mantener el detalle y la riqueza de la fuente en la medida que el proyecto necesite, al mismo tiempo que estandarizar y remodelar la información lo suficiente como para permitir que la base de datos operar con la máxima eficiencia y flexibilidad.

Información problemática

Existen ciertas categorías de información histórica que son habitualmente problemáticas, y desafortunadamente éstas tienden a ser aquellas materias que a menudo constituyen unidades analíticas, a saber, geografía, cronología y ortografía.

Información geográfica

El problema con la información geográfica que se presenta en fuentes históricas es que los límites de las unidades administrativas se superponen y cambian con el tiempo, de manera que la misma ubicación física puede pertenecer a diferentes condados/parroquias/custodias/recintos y así dependiendo de la fecha de la fuente que se esté consultando. Si sus fuentes cubren un amplio rango de tiempo, deberá ser sensible a las implicaciones que los cambios de límites en ese período puedan tener para sus datos. Esto es especialmente cierto si estás registrando datos de manera jerárquica: por ejemplo, si tienes un campo en una tabla para 'Parish', y otro para 'Condado', y a cada registro se le dará un valor en cada campo. Si la parroquia de St Bilbo Bolsón está situada en el condado de Hobbitonshire a principios del ^siglo XVII, entonces los registros relacionados con esta parroquia tendrían estos dos valores ingresados en los campos respectivos de la tabla. Si, sin embargo, los cambios administrativos en el ^siglo XVIII alteran los límites del condado para que St Bilbo Bolsón de repente pertenezca al condado de Breeshire, entonces los registros tendrán los valores de St Bilbo Bolsón en el campo parroquial, y Breeshire en el campo comarcal. Si bien esto es exacto, de repente causa un problema para la base de datos, ya que tendrá varios registros con la misma cadena en el campo 'Parish' —y así será reconocido por la base de datos como que significan exactamente lo mismo— pero que históricamente hablando tienen significados diferentes en diferentes puntos en el tiempo.

En esta instancia existen diversas formas de tratar este tema. Simplemente mantente al tanto del problema, y al ejecutar consultas en las parroquias se toma en cuenta el campo 'Condado' así como el campo 'Parroquia'. Esto te permitirá especificar qué versión de la parroquia de St Bilbo Bolsón estás analizando. En segundo lugar, podrías modificar el valor de Parish para especificar qué versión es, así que en lugar de ingresar a St Bilbo Bolsón, podrías ingresar St Bilbo Bolsón: Hobbitonshire o St Bilbo Bolsón: Breeshire en el campo Parish. Esto simplificaría la complicación de ejecutar consultas en esta situación, pero técnicamente rompería la regla de la base de datos sobre 'atómica.

Este problema es aún más significativo cuando no son solo los límites geográficos los que cambian, sino cuando las propias entidades cambian. Por ejemplo, Londres del ^siglo XVII tenía más de 100 parroquias a principios de siglo, muchas de ellas absolutamente pequeñas en términos de área y población. Después del Gran Incendio, estos se reorganizaron, con el resultado de que muchas se fusionaron o unieron; en algunos casos, la entidad recién creada conservó el nombre de una de las parroquias previas al fuego, mientras que cada parroquia aún mantenía su propia existencia para algunos fines administrativos (ej. St Martin Ironmonger Lane y St Olave Jewry). Aquí el problema no es el de cambiar la jerarquía (qué parroquia pertenece a qué condado), sino uno de sentido (¿a qué área/población se refiere la fuente en esta fecha al referirse a 'San Martín Ironmonger'?). Se utilizan diversos enfoques para resolver esto, entre ellos el del ejemplo anterior. Lo más importante es tener claro en los datos en todo momento precisamente lo que se entiende por los términos geográficos que ingresas a la base de datos.

Información cronológica/de citas

Todos los posibles problemas creados por el cambio de terminología geográfica se aplican a la identificación de fechas en los datos históricos. Este es claramente un tema más grave cuanto más atrás en la historia se generaron tus fuentes, cuando los calendarios y los sistemas de datación eran más variados y abundantes, y los guardianes de registros tenían más opciones en qué sistema de citas podían elegir. Lo importante que hay que recordar aquí, como con la geografía (y de hecho todo lo demás ingresado a la base de datos), es que la base de datos no reconoce significado. La base de datos no interpreta cuándo fue el 'Martes después de la Fiesta de la Santísima Asunción en el tercer año de Ricardo II'. Esa fecha, como valor, no se puede almacenar, ordenar o consultar como tipo de datos de fecha. Los años de reinado, los años de alcaldía, los días de fiesta, los días de ferias y mercados, etc., necesitan ser convertidos en un valor que utilice un formato de fecha moderno real. Además, está el tema del cambio de calendarios julianos a gregorianos. Dependiendo del lapso de tiempo y de la fuente geopolítica de los registros, tal vez sea necesario considerar este hecho. Esto no necesariamente significa literalmente 'convertir': sería completamente razonable si tu investigación requiriera que tuviera dos campos para ingresar información de fecha, uno que contuviera la fecha textualmente de la fuente, y el segundo en el que se pudiera ingresar la renderización moderna. La consulta y la clasificación podrían realizarse usando este último campo

No olvide el tipo de datos del campo en el que se ingresará la información de datación, teniendo en cuenta que los campos de tipo de datos 'Texto' ordenarán las fechas alfabéticamente mientras que los campos de tipo de datos 'Fecha/Hora' las ordenarán cronológicamente.

Ortografía/formas variantes

Esta es la área realmente grande en la que las fuentes históricas proporcionan información problemática para la base de datos: ¿cómo se maneja la información que aparece con muchas ortografías diferentes o en formas completamente diferentes cuando en realidad significa lo mismo (o al menos desea tratarla como lo mismo)? ¿Cómo va a lidiar con las contracciones y abreviaturas, particularmente cuando no son consistentes en la fuente? ¿Cómo acomodará la información que está incompleta, o es difícil de leer o entender donde no está seguro de su significado? Es prácticamente seguro que todos estos temas surgirán en algún momento del proceso de entrada de datos, y todos ellos deberán abordarse en cierta medida para evitar problemas e inexactitudes que surjan durante el análisis de sus datos.

Normalización, clasificación y codificación

El principal camino a seguir para acomodar datos que contienen este tipo de problemas es aplicar (a menudo de manera bastante generosa) una capa de Normalización en el diseño de la base de datos mediante el uso de Normalización, clasificación y codificación. Estas tres actividades son un paso alejado de simplemente recopilar e ingresar información derivada de las fuentes: aquí es donde agregamos (o posiblemente cambiamos) información para facilitar la recuperación de información y realizar análisis. Utilizamos estas técnicas para superar el problema de la información que significa que lo mismo aparezca de manera diferente en la base de datos, lo que impide que la base de datos se conecte como con like (el prerrequisito fundamental para analizar datos). Para los historiadores este es un paso más importante que para otros tipos de usuarios de bases de datos, porque la variedad de formas y ambigüedad de significado de nuestras fuentes no sienta bien con la exactitud que requiere la base de datos (como con el ejemplo de tratar de encontrar todos nuestros registros sobre John Smith, de manera que más de un La capa de estandarización necesita ser implementada.

La estandarización, clasificación y codificación son tres técnicas distintas que se superponen, y la mayoría de las bases de datos utilizarán una combinación de las tres al agregar una capa de estandarización al diseño:

Estandarización

Este es el proceso de decidir una forma de representar una pieza de información que aparece en la fuente de varias maneras diferentes (por ejemplo, una forma de deletrear los lugares/nombres personales; una forma de registrar fechas, etc.) y luego ingresar esa versión estandarizada en la tabla. Considera usar Estandarización cuando se trata de valores que parecen ligeramente diferentes, pero significan lo mismo — 'Ag Lab' y 'Agricultura Trabajo' ya que los valores serían tratados de manera muy diferente por la base de datos, así que si quisieras que fueran considerados como lo mismo, señalarías esto a la base de datos por dando a cada registro con una variante de esta ocupación el mismo valor estandarizado.

Clasificación

Este es el proceso de agrupar información ('cadenas') de acuerdo con algún esquema teórico, empírico o totalmente arbitrario, a menudo utilizando un sistema jerárquico para mejorar el potencial analítico. La clasificación consiste en identificar grupos y luego asignar sus datos a esos grupos. Estos grupos pueden ser jerárquicos, y la jerarquía le permitirá realizar su análisis en una variedad de niveles. La clasificación se trata menos de capturar la información en sus fuentes y se trata mucho más de atender sus necesidades de investigación.

La clasificación suele ser independiente de la información de origen. Es algo significativo para usted y sus propósitos de investigación y se aplica arbitrariamente para satisfacer sus necesidades y métodos. La aplicación consistente conducirá a un uso más eficiente y a resultados más precisos.

Si estás investigando fuentes que han utilizado historiadores anteriores, puede que ya exista el sistema de clasificación arbitrario ideado por otros. Es posible que desee utilizar el mismo sistema de clasificación para la ventaja de no tener que reinventar ese componente así como para facilitar la comparación con el trabajo de otros. Pero no sientas que no puedes idear tus propias clasificaciones. Estos pueden ser adicionales a la clasificación anterior o pueden ser modificaciones o ampliaciones a esos esquemas anteriores.

Un ejemplo de un sistema de clasificación se puede observar en un proyecto en curso que investiga los aspectos materiales de los primeros hogares modernos; este proyecto utiliza una base de datos para registrar información minuciosamente detallada sobre los objetos materiales. Una de las formas en que trata la información sobre los objetos es clasificar los objetos por tipo, para poder comparar objetos similares a pesar de las diferencias a menudo sustanciales en las formas en que se les hace referencia en las fuentes. Esto funciona agregando un campo en la tabla donde se registran los datos de tipo de elemento en el que se puede agregar un valor de código ItemClass:

Datos sobre objetos materiales que han sido clasificados y codificados

El campo ItemClass aquí está poblado con códigos, y estos códigos registran precisamente de qué tipo de elemento se trata el registro (puede ver cómo llama la fuente el elemento en el campo ItemDescr). [2] El hecho de que el código sea un valor numérico, y el hecho de que el mismo código numérico se aplique al mismo tipo de objeto independientemente de cómo se describa en la fuente, significa que el campo ItemClass actúa como un valor estandarizado. Esta es una clave externa en una tabla de búsqueda o clasificación de soporte.

Adicionalmente, sin embargo, el campo ItemClass permite el uso de un sistema de clasificación jerárquica. La jerarquía opera describiendo objetos en tres niveles cada vez más detallados:

Código I: el nivel más amplio (por ejemplo, Ropa de cama (hogar); Almacenamiento; Herramientas; Ropa — Exterior; Iluminación etc.)

Código II: el nivel medio, ofreciendo subgrupos de Código I (por ejemplo Herramientas > Implementos domésticos; Ropa — Exterior > Calzado)

Código III: el nivel de descripción más detallado (por ejemplo Ropa — Exterior > Calzado > Botas)

Para ilustrar esto podemos tomar el ejemplo de cómo la base de datos clasifica los objetos que se utilizan para asientos:

Sistema de clasificación para objetos en la categoría de 'Asientos'

Cada nivel de código tiene un código numérico de dos o tres dígitos, por lo que el Código I: Asiento tiene el código numérico 05, que para el Código II: Silla es 02, y el de Código III: Silla de mimbre es 006. Estos códigos individuales se convierten en un solo código numérico (en el caso de la silla de mimbre — 0502006) que es el valor que se ingresa en el campo único relevante (ItemClass) en el registro de la silla de mimbre en la base de datos.

Esto puede sonar complicado y lento de implementar, pero el beneficio de hacerlo es considerable. La base de datos se puede diseñar de manera que estos códigos estén disponibles automáticamente como valores de 'búsqueda'. Estos se pueden seleccionar en el momento de la entrada de datos en lugar de tener que ser memorizados. En segundo lugar, una vez codificados los datos, se pueden analizar en tres niveles semánticos diferentes. Se podrían analizar todas las instancias de sillas de mimbre en la base de datos ejecutando consultas en todos los registros que tuvieran el valor ItemClass “0502006”. O bien, si estuvieras interesado en analizar las propiedades de todas las sillas en la base de datos, podrían hacerlo ejecutando consultas en todos los registros con un valor ItemClass que comienza “0502***”. Por último, si el objetivo de la investigación era observar todos los objetos utilizados para el asiento, se podría diseñar una consulta para recuperar todos los registros con un valor ItemClass que comenzara “05*****”. Se trata de una herramienta analítica inmensamente poderosa, que sería difícil de lograr sin el uso de un sistema de clasificación jerárquica: ejecutar una consulta para encontrar todos los objetos utilizados para asientos sin un sistema de clasificación requeriría buscar cada objeto calificativo que el historiador pueda anticipar o recuerde, por su nombre y tomando en cuenta las variantes ortográficas que pudieran aplicarse. [3]

Los sistemas jerárquicos de clasificación también son cosas muy flexibles. Pueden incluir tantos niveles como requiera para analizar sus datos, y no necesitan emplear códigos numéricos cuando el texto simple estandarizado sería más fácil de implementar.

Codificación

La codificación es el proceso de sustituir (no necesariamente literalmente) un valor por otro, con el propósito de registrar una pieza de información compleja y variable a través de un valor corto y consistente. La codificación suele estar estrechamente asociada con la clasificación, y además de ahorrar tiempo en la entrada de datos (es mucho más rápido escribir una palabra de código corta que escribir cinco o seis palabras) los códigos también actúan como Normalización (es decir, se ingresa la misma forma para la misma información sin importar cómo esta última aparece en la fuente). Estas son tablas de consulta de uno a muchos relacionados. Por ejemplo, piense en escribir TX o TN en lugar de Texas o Tex pero la base de datos puede mostrar consistentemente Texas en la salida por medio de la tabla de búsqueda relacionada.

Estas técnicas se implementan para que los datos sean más fácilmente utilizables por la base de datos: los códigos, clasificaciones y formas estandarizadas que se utilizan son simples y a menudo más fáciles de incorporar en un diseño de consulta que las cadenas de texto originales complicadas e incompletas que aparecen en la fuente; pero más lo que es importante, son consistentes, haciéndolos mucho más fáciles de encontrar. Sin embargo hay una serie de cosas a tener en cuenta a la hora de utilizarlas, la más importante de las cuales es que existen dos formas de aplicar estas técnicas:

Sustituyendo los valores originales en la tabla por formularios normalizados/codificados/clasificados

Añadiendo formularios normalizados/codificados/clasificados en la tabla junto con los valores originales

Cada uno de estos enfoques es un compromiso entre mantener la integridad de las fuentes y mejorar la eficiencia del análisis. El primer enfoque para estandarizar, para reemplazar la versión original de la información fuente en cualquier campo o campos elegidos por formas estandarizadas de datos, permite acelerar la entrada de datos a expensas de perder lo que dice la fuente. También sirve como un tipo de control de calidad, ya que ingresar datos estandarizados (especialmente si se controla con una 'lista de búque') es menos propenso a errores de entrada de datos que los formularios originales que aparecen en la fuente.

El segundo enfoque, para ingresar valores estandarizados además de los formularios originales, permite lo mejor de ambos mundos: se logran los beneficios de precisión y eficiencia de la Normalización sin perder la información tal como se presenta en la fuente. Por supuesto, esto sucede a costa de tiempo extra de entrada de datos, ya que ingresas material dos veces.

Al considerar ambos enfoques, tenga en cuenta que solo necesitará estandarizar algunos de los campos en sus tablas, no todos los campos en cada tabla. Los candidatos para estandarizar, clasificar y codificar son aquellos campos que probablemente sean muy utilizados en su vinculación de registros o consultas, donde es importante poder identificar como con valores similares. Los creadores de bases de datos construidas en torno al principio orientado a la fuente deben tener especial precaución al emplear estas técnicas.