Visualizza wikitesto di Database e il loro potenziale utilizzo nella ricerca storica

{{articolo|
nome=Beatrice|
cognome=Rosi|
testo=

La prima cosa da sapere è che un database non è solo un prodotto tecnico. La sua elaborazione implica un gran numero di decisioni. '''La costruzione di una banca dati obbedisce''', in modo perfetto o imperfetto, '''ai precetti e alle visioni del mondo del ricercatore''' (e, all'interno di questi, al problema della ricerca). La prima posizione teorica è quella di credere che sia possibile ridurre la complessità del sociale al punto da adattarlo sotto forma di tabulati, come gli storici credono sia possibile fare sulle righe di un testo. Le nostre posizioni teoriche possono essere varie, eterogenee, eclettiche, ma sono lì, nel loro angolo, in attesa che il tempo appaia per organizzare il mondo all'interno dei nostri "prodotti". Nel caso della ricerca in Storia, ciò include la scelta di oggetti, insiemi di fonti, metodologie e interlocutori. E la configurazione del database non è diversa.

Possiamo dire che esistono due tipi di basi, quella “analitica” (orientata al '''[[Database centrati sul metodo|metodo]]''', come preferiscono alcuni autori), focalizzata su un problema di ricerca, e quella “empirica” (orientata dalla [[fonte]] ) che cercano di rendere conto di un corpus documentario, come base di registri parrocchiali, battesimi, per esempio. Ciò è legato a una concezione della storia che prevede il lavoro dello storico come un passo importante verso l'accesso alla conoscenza del passato, poiché le basi analitiche sarebbero guidate da un problema di ricerca. Le basi empiriche, a loro volta, avrebbero organizzato il materiale di lavoro, senza un accesso diretto al passato, poiché erano organizzate da uno storico in modo diverso dallo stato originario della fonte.

Dopo aver fatto questi punti salienti, possiamo pensare a molti usi per i database nella storia. Possiamo usare le basi per organizzare i nostri materiali di ricerca, note d'archivio, elenchi di documenti (ora organizzati, con campi che separano le persone coinvolte, date, temi, ecc.) E molte altre cose. Un foglio di calcolo (come Microsoft Excel, ad esempio) può risolvere tutto questo e forse molte persone possono fare la stessa cosa utilizzando un editor di testo (come Microsoft Word, ad esempio). Può essere, ma è molto più facile quando possiamo cercare due cose contemporaneamente, ad esempio, tutti i riferimenti al tema "salute", tra il 1850 e il 1870, per esempio. E diventa ancora più interessante se possiamo fare la stessa ricerca all'interno di un'area specifica (una città o una regione, ad esempio). Questo editor di testo non lo consente. Riguardo ai fogli di calcolo, sono già nell'universo dei database...

In questa sezione vediamo come e quanto un database possa essere utile nella ricerca storica. Si prenderanno in considerazione alcuni concetti importanti che lo storico ha bisogno di sapere prima di imbarcarsi nella progettazione di un database, e si cercheranno di fornire una serie di punti di partenza per superare certi problemi di progettazione che colpiscono specificamente gli storici quando arrivano a mettere le loro fonti in un database. 

È necessario avere una buona comprensione della complessa relazione tra fonti storiche, informazioni e dati, ed essere consapevoli dei processi di traduzione che sono necessari quando si passa dall'uno all'altro. I contenuti informativi delle fonti storiche devono essere convertiti (spesso in più modi) prima di poter essere usati come dati, e bisogna prendere numerose decisioni metodologiche. A differenza degli aspetti più meccanici dell'uso dei database nella ricerca storica, come la costruzione di tabelle, il collegamento di record o l'esecuzione di analisi aggregate, questo processo di traduzione non solo è difficile da imparare (serve esperienza), ma è anche probabile che sia un processo sostanzialmente soggettivo, cioè diverso per ogni storico che lo applica. Ciascuno studioso della storia ha materiali, progetti ed obiettivi di ricerca diversi, quindi i database che costruisce si rivolgono (o dovrebbero rivolgersi) a questi nel modo che meglio si adatta al suo scopo specifico. Questa "modellazione" dei dati storici non è un processo semplice, ma fortunatamente le difficoltà che sorgono sono quelle che in generale gli storici affrontano nel loro lavoro quotidiano, non legato ai database. 

Gli esempi proposti in questo portale non sono gli unici modi per progettare un database, dato che non esiste un modo giusto o sbagliato, ma tentano di percorrere la via più “utile” per uno storico.

La parte difficile del processo di utilizzo dei database nella ricerca storica sta nella “forma” delle informazioni che si trovano all’interno delle fonti. I database hanno regole molto rigide sul tipo di informazione che deve essere scritta, utilizzata e su come viene rappresentata per fare in modo che diventi un dato. Infatti, esiste una differenza tra "informazioni" e "dati": le prime sono quello che le fonti forniscono, i secondi ciò di cui i database hanno bisogno.

Il problema che gli storici devono affrontare è che l'informazione può assumere molte forme nelle fonti, anche se si sta considerando solo un singolo tipo di fonte relativamente semplice. Le fonti che hanno una “forma” irregolare (come quelle testuali con lunghi resoconti narrativi scritti in paragrafi, capitoli, ecc., o i database di raccolte di immagini/suoni/video) risultano essere problematiche quando si tratta di convertire le loro informazioni in dati. Tuttavia, il problema sorgerà anche nelle fonti più strutturate (come gli elenchi dei censimenti o le valutazioni fiscali), che non sono mai così semplici come potrebbero sembrare.

Cosa s’intende con “forma”? Il concetto di “forma” è importante per capire come funzionano i database e per inserirvi le fonti. Una regola fondamentale è che tutti i dati nel database stanno in tabelle. Questo significa che le informazioni prese dalle fonti dovranno essere inserite in una struttura tabellare, cioè disposte per righe e colonne. 

Le informazioni delle fonti sono ciò che ci interessa. Rappresentano ciò che useremo per eseguire le analisi e costituiscono la materia prima della ricerca dello storico. Indipendentemente dal database, quando si guardano le fonti con una necessità metodologica, estraiamo informazioni da esse e le registriamo come note (a volte come trascrizioni).  La registrazione delle informazioni, in questo modo, permette di accedere a ciò di cui abbiamo bisogno senza dover consultare la fonte originale in futuro. Inoltre, nel prendere appunti assimiliamo le variazioni del tipo e della portata dell'informazione registrata, senza preoccuparci della forma di quest’informazione, cosa che non è più possibile in un database.

Per esempio, un manifesto potrebbe fornire allo storico la maggior parte delle informazioni della fonte - informazioni su luoghi, date, tematiche, eventi, ecc.- ma dal punto di vista della progettazione del database è importante notare che esistono altre informazioni interessanti oltre ai contenuti stessi.  È opportuno identificare questi tipi di informazioni non testuali, come dimensioni della pagina, layout, tipi e dimensioni dei caratteri, lingua, timbri d'archivio, colori usati ecc. Le descrizioni della fonte possono essere informazioni utili tanto quanto ciò che la fonte effettivamente dice.

Considerando un manifesto come un elemento candidato per l'inserimento in un database, l'aspetto più ovvio di questa particolare fonte è che non assomiglia molto a una tabella: non è "rettangolare" in termini di forma, ovvero il testo non è organizzato in colonne e righe. Questo rende difficile accertare la portata delle informazioni (di cosa trattano) senza leggere effettivamente l'intera fonte.

Immediatamente quindi diventa evidente che se volessimo includere queste informazioni nel nostro database, dovremmo pensare attentamente a come inserirle. In che modo si possono riordinare le informazioni in colonne e righe? Come dovrebbero essere le colonne? Come si potrebbero dividere le informazioni in istanze di qualcosa (righe)? Le nostre fonti, sebbene possano essere molto utili, spesso non sono effettivamente adatte ai database.

D'altra parte, però, esistono anche fonti che a prima vista sono più promettenti in termini di idoneità all'inclusione in un database. Prendiamo per esempio i censimenti che invece hanno una forma più "rettangolare". Qui le informazioni sono convenientemente organizzate in colonne e righe: ogni colonna riguarda un particolare tipo di informazione (nome, età, occupazione e così via), e ogni riga corrisponde a informazioni su un singolo individuo. Questa è una fonte che si "adatta" alla struttura del database senza bisogno di troppe conversioni, poiché la sua forma intrinseca si avvicina molto a quella richiesta dal database.

Bisogna comunque sottolineare che anche in questo caso il processo di conversione da informazioni della fonte a dati del database non sarà privo di problemi, anche se alcuni di essi si potrebbero risolvere facendo una selezione. Lo storico, infatti, dovrà scegliere un metodo di scelta delle informazioni relativo allo scopo della sua ricerca.

Il primo passo è quindi quello di decidere quale scopo (o scopi) il database dovrà raggiungere. Ciò non è così ovvio o diretto come ci si potrebbe aspettare, dato che i database in astratto possono effettivamente servire ad uno o più tipi di funzioni. In sostanza, comunque, ci sono tre tipi di funzioni a cui lo storico è probabilmente interessato:

# Gestione dei dati
# Collegamento dei record
# Definizione del modello/analisi aggregativa

Ciascuna di queste funzioni è un obiettivo che può essere raggiunto attraverso il modellamento del database nel processo di progettazione, e ognuna richiederà che alcuni passaggi nella formazione del database siano condotti in modi specifici, sebbene non si escludano affatto a vicenda. Quest'ultimo punto è importante, dato che la maggior parte degli storici vorrà avere accesso all'intera gamma di funzionalità offerte dal database, e probabilmente si impegnerà in ricerche che richiederanno tutti e tre i tipi di attività elencati. In altre parole, è raro che gli storici sappiano esattamente cosa vogliono fare con il loro database all'inizio del processo di progettazione, cioè quando queste decisioni dovrebbero essere prese. Questo è il motivo per cui molti storici sono inclini a progettare database che massimizzino la flessibilità per poterli usare in seguito nel progetto.

# L'aspetto della gestione dei dati del database è in molti casi una specie di sottoprodotto di come funziona il database ed è anche una delle sue funzioni più potenti e utili. È molto importante per uno storico essere in grado di tenere grandi quantità di informazioni (provenienti da diverse fonti) sia in un’unica struttura sia in una forma che renda possibile trovare qualsiasi informazione e vederla in relazione ad altre informazioni. Molti storici usano il database per l'organizzazione bibliografica, che permette loro di collegare le note delle letture secondarie alle informazioni prese dalle fonti primarie e di poter risalire alla fonte di entrambe. Gli strumenti più semplici dei database possono essere usati per trovare le informazioni rapidamente e facilmente, rendendolo un buon contenitore di informazioni da recuperare.
# Il collegamento dei record è il punto in cui il database, e in particolare il database relazionale, entra in gioco. Collegare persone, luoghi, date, eventi e temi attraverso fonti, periodi e confini geografici o amministrativi è chiaramente un compito incredibilmente utile da svolgere.
# Infine, una volta che le informazioni sono state convertite in dati, il database può essere impiegato per raggrupparle. Una volta che i record sono aggregati, allora diventa possibile contarli, il che significa poter eseguire le analisi statistiche e definire i modelli strutturali all'interno delle informazioni.

A proposito della progettazione dei database, esistono due modelli concettuali: quello “analitico” (orientato al '''[[Database centrati sul metodo|metodo]]''', come preferiscono alcuni autori), focalizzato su un problema di ricerca, e quello “empirico” (orientato dalla [[fonte]]) che cerca di rendere conto del corpus documentario, come base di registri parrocchiali o di battesimi, per esempio. 

In sintesi, il modello di database orientato alle fonti riguarda la progettazione del database storico orientato alla registrazione di ogni singola informazione dalle fonti, senza omettere nulla. Una specie di surrogato digitale delle fonti. Le informazioni e la loro forma strutturano completamente il modo in cui il database deve essere costruito.

Questo approccio alla progettazione di un database attira molto uno storico, poiché pone le fonti al centro del progetto. Richiede tempo per l’inserimento dei dati e, se applicato rigidamente, può portare ad un progetto ingombrante, poiché si cerca di raccogliere ogni singola informazione della fonte. Dal lato opposto, però, permette di adottare in seguito approcci analitici più ampi, in modo che le potenziali query non dipendano dal programma di ricerca iniziale. In questo modo non si devono anticipare tutte le domande di ricerca, al contrario del modello orientato al metodo. 

Detto in altre parole, questo primo modello trasferisce la fonte (con tutte le sue peculiarità e irregolarità) nel database senza perdita di informazioni: tutto (o quasi) viene registrato e se successivamente si nota qualcosa d’interessante, non sarà necessario tornare alla fonte per inserire altre informazioni che all’inizio non erano sembrate utili.

Il database orientato al metodo, invece, è basato su ciò che è destinato a fare, piuttosto che sulla natura delle informazioni che contiene. Di conseguenza, se si vuole adottare questo modello per la progettazione, è necessario sapere, prima di iniziare, lo scopo del database (incluse le ''query'').

I database orientati al metodo sono più veloci da creare e da “riempire”, ma è molto difficile deviare successivamente dalla funzione progettata del database, al fine di (ad esempio) perseguire nuove linee di indagine.

In definitiva, gli storici potrebbero spesso decidere di seguire una via di mezzo tra le due possibilità, dimostrando forse una maggiore propensione per l'approccio orientato alle fonti. Quando si decide di quali informazioni si ha bisogno, è importante tener conto del fatto che le esigenze possono cambiare nel corso di un progetto e che potrebbe durare diversi anni. Se si vuole essere in grado di mantenere la massima flessibilità nel programma di ricerca, allora c’è bisogno di inserire più informazioni nella progettazione del database. Se non si sa se le esigenze di ricerca cambieranno, è sconsigliato inserire più informazioni.

Al contrario se si conosce la fonte (o le fonti) molto bene in anticipo, se sono state definite le esigenze di ricerca predeterminate, se non si cercherà di recuperare tutte le informazioni dalla fonte, e se si è già a conoscenza di come trattare e quali ''query'' porre sui dati, allora è consigliabile un approccio orientato al metodo.

In conclusione, per progettare un database serve tempo, specialmente se si è adottato il primo approccio e si sta lavorando con una serie di fonti diverse, ricche e complesse. Tuttavia, il tempo speso a lavorare sulla progettazione sarà più che ripagato quando si arriverà alle fasi di inserimento e analisi dei dati del progetto del database. Le fonti storiche daranno origine a tutti i tipi di complicazioni e più si riesce ad anticiparli/accomodarli nella progettazione, maggiormente efficiente sarà l'uso del database in seguito.

Nessun database è perfetto, e l'unico indicatore di qualità (o di successo) quando si tratta di progettare un database è se serve o meno alle varie funzioni prefissate. Se si riesce a gestire le informazioni nel modo che serve, a eseguire le analisi e ad essere flessibili in entrambe quest’aree, allora il modello è buono. L’importante è non valutare la qualità del database solo alla fine e costruire (ad esempio) un prototipo strutturale del database (cioè con solo le tabelle e le relazioni, senza preoccuparsi troppo degli altri strumenti che vanno nella creazione dell'applicazione del database): un “mini-database” in cui inserire alcuni dati per vedere le carenze nel progetto. 

A questo punto è probabile che si possono trovare queste situazioni:

[[Arquivo:InRosi1.png|800px|center]]

Una volta inseriti i dati, si possono progettare ed eseguire alcune query per testare se le domande di ricerca possano essere effettivamente soddisfatte dal progetto attuale. L'esecuzione delle ''query'' è il test definitivo per verificare se il progetto del database funziona o meno, ed è probabile che si debbano riorganizzare i campi.
 
Una volta terminati questi test, è sufficiente progettare e ricostruire il database sistemando i problemi riscontrati. Sarà difficile e lungo all'inizio, ma alla fine ne varrà la pena!




}}