Exibir código-fonte para Database centrati sul metodo

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

Questa tipologia di database è veloce da strutturare e permette di incentrarsi sullo scopo di una base di dati. Per questo motivo, un database centrato sul metodo necessita di sapere anticipatamente ciò che è destinato a fare.

Un buon esempio di database ''method-centred'' è il sistema “Fichoz”, il quale permette di condurre analisi storiche, elaborando e registrando i dati. Sebbene non consenta la piena incorporazione delle fonti, ha permesso la scomposizione delle interazioni sociali (descritte nelle fonti) in un'ampia varietà di porzioni raggruppabili a seconda delle necessità. Nel caso della base "Fichoz", la possibilità di smantellare le fonti è talmente grande che, a seconda dell'ostinazione del ricercatore, non sarebbe nemmeno così pericoloso fare a meno di queste ultime; sarebbe inoltre relativamente facile riutilizzare la base, vista la sua plasticità a fronte delle numerose metodologie oggi note. Poiché sono un sostenitore dei database incentrati sulla sorgente, temo di raccomandare database incentrati sul metodo, ma capisco che, se fatti bene, questi database possano risultare preziosi. Diamo un'occhiata ad alcuni esempi di metodologie e in cosa consisterebbe la creazione di basi con tali prospettive.

== '''Prosopografia''' ==

Così come è necessario conoscere la fonte per creare una base di dati centrata su di essa, '''è necessario conoscere bene anche la metodologia'''. 

Per la prosopografia, ad esempio, è fortemente consigliata la lettura dell’opera di Lawrence Stone sull'aristocrazia inglese, così come un suo articolo del 1971. Esistono tanti altri contributi importanti, comprese molte collezioni nazionali, ma per comodità prenderemo in considerazione principalmente Stone. 

Con '''prosopografia''' s’intende la '''biografia di un gruppo''', che può essere omogeneo o meno, e quindi la predisposizione di  uno strumento in cui memorizzare i dati biografici in modo tale da consentirci l'analisi '''dagli individui al gruppo e viceversa'''.

Ora domandiamoci, sarebbe il caso di avere almeno due database, una per il gruppo e una per i singoli? Dovremmo avere un "record" per ogni personaggio, con la loro data di nascita, matrimonio, morte, ecc.? Un modello algernativbo interessante per la prosopografia è la stessa base “Fichoz” di Jean-Pierre Dedieu, che non ha record individuali e il suo design è peculiare. L'idea è infatti quella di '''smembrare la vita delle persone in eventi''', in modo da poterle poi raggruppare sotto forma di biografia (o anche seguendo altri criteri). Sulla stessa base di dati sarebbe possibile '''mettere in relazione l'evento con altre persone''', consentendo quindi '''l'analisi delle reti'''. 

Il modello concettuale del database “Fichoz” sembra molto adatto agli studi prosopografici e sarebbe difficile creare un sistema più efficiente e flessibile. Non è necessario avere una copia di questo sistema per riprodurne il concetto, basta conoscerne la descrizione e applicarla con la dovuta attenzione. 

Un sistema di record individuali è una buona via d'uscita, ma ci sono alcuni '''limiti''' difficili da aggirare. Il primo è la ricostruzione della '''vita della persona'''. Dovremmo procedere cronologicamente, ma sappiamo che non avremo mai un comportamento standard correlato al ciclo di vita, come l'età del matrimonio, l'età per entrare nel mondo del lavoro, o l'età per essere un parlamentare. Un altro limite è che, per ogni campo, avremmo bisogno di un altro correlato per la '''fonte''' che abbiamo usato per riempire quel campo. Un altro limite è legato ai '''“campi vuoti”''', cioè quelle caselle del data base che non possono essere completate per tutti gli individui. Dovremmo avere un campo “professione” anche per chi non ne ha mai avuto una? Un campo relativo allo stato matrimonio anche per chi non si è mai sposato? Un consiglio è quello di inserire il campo per tutti (es. “Sposato” o “Stato Civile”) evitando di lasciare la casella “in bianco”. Si può indicare l’assenza con un valore, come “No” nel caso di “Sposato”, oppure Single/Non sposato se il campo fosse “Stato Civile”.

Esistono poi i dati multipli, molto comuni: ossia il fatto che una persona nel ciclo della sua esistenza può aver avuto più matrimoni e svolto professioni diverse.

== '''Analisi demografica (metodo Henry)''' ==

Creato negli anni ''''50''' come percorso per studi demografici di epoche note come "pre-statistiche", quando non esisteva una registrazione sistematica dei dati delle popolazioni; il '''Metodo Henry''' ha formato generazioni di ricercatori e tante scuole di studi demografici, da Cambridge a Minho. La proposta era relativamente semplice: '''se non disponiamo di statistiche ufficiali dei secoli passati, raccogliamo tutti i registri di battesimo, matrimonio e decessi e cerchiamo di ricostituire le famiglie di tali periodi, incrociando i dati.''' L'idea era estremamente interessante ma si traduceva anche in un lavoro infinito. 

Fu solo nel '''1968''' che venne presentato al mondo il primo grande risultato del metodo: '''la tesi di Pierre Goubert su Beauvais'''. Da allora, sono state apportate molte aggiunte al design originale, variazioni, e creati vari software per applicare il famoso metodo. Per creare un database che utilizzi il metodo Henry, '''l'ideale sarebbe iniziare con una base di dati per ognuna delle tre fonti: una per i battesimi, una per i matrimoni e una per i decessi.''' 

Successivi adattamenti del metodo, fatti dallo stesso Henry per lo studio del Brasile, avrebbero consentito '''una quarta base''', una per le '''liste nominative'''. E questo non significa ignorare l'opzione di coloro che preferiscono lavorare senza basi source-centred '''il metodo stesso prevede, infatti, un trattamento diverso per ciascuna fonte'''. Il passo successivo tiene in considerazione solo approcci incentrati sul metodo: è necessario creare alcune tabelle e numerosi campi per tenere conto di questa metodologia. 

Mi sembra opportuno pensare ad almeno '''tre tabelle''': località, famiglia e individuo: 

*'''località''', perché è comodo pensare che la base possa essere utilizzata per località diverse, forse vicine, o anche molto distanti (per studiare i flussi migratori, ad esempio); 
*'''famiglia''', poiché l'unità domestica è al centro del metodo;
*'''l’individuo''' permetterà di isolare i casi e di catalogare date di nascita, matrimonio e morte. 

Ovviamente non possiamo prevedere quante persone formeranno la famiglia, '''il numero dei componenti sarà quindi sempre “n”'''. 

Se abbiamo tutti i dati opportunamente organizzati sulla base di matrimonio, morte e battesimo, '''sarà sufficiente isolare tutte le coppie di padri e madri''', nel caso di battesimi, e di sposi novelli, nei matrimoni. Fatto ciò, elimineremo i duplicati e avremo tutte le coppie disponibili in quel campione. 

Facciamo un esempio di database per i battesimi, per i matrimoni e per i decessi.

<ins>Database Battesimi</ins>

[[Arquivo:InRosiMetodo1.png|800px]]

<ins>Database Matrimoni</ins>

[[Arquivo:InRosiMetodo2.png|800px]]

<ins>Database Decessi</ins>

[[Arquivo:InRosiMetodo3.png|800px]]

I campi sono incompleti per motivi di spazio, ad esempio manca “Data” oppure i nomi di padrini/madrine/testimoni. Inoltre, spesso si trova “Data di nascita” al posto di “Età”, ma per il nostro esempio è indifferente.

Come si può notare, gli individui sono collegati. Ad esempio, i genitori di Mario Rossi sono anche gli sposi presenti nel database Matrimoni. Possiamo anche dire che la donna che è morta ha una figlia, Carla Spina, ed era sposata. 

Relazionando i database, si possono capire molte informazioni di un individuo, di una famiglia e i relativi spostamenti.

In alcuni casi però bisogna fare attenzione ai nomi. Ad esempio, Arianna Betti, sposata con Franco Rossi, potrebbe essere stata trascritta erroneamente come Anna Betti, a causa di una banalizzazione (viene sostituito un termine con uno più semplice). Un buon studio della nostra lista di partenza può portare a molte correzioni necessarie. Con dei dati organizzati e corretti, è sufficiente '''mettere in relazione la nostra nuova tabella con le basi del matrimonio e del battesimo''' in modo che portino informazioni complementari che formeranno il record di ogni famiglia. Questa è una procedura molto meno laboriosa rispetto alla riscrittura di tutti i casi. È meglio dedicare questo tempo alla revisione, cosa che dovrebbe essere fatta comunque. 

Quindi, abbiamo già la tabella delle famiglie, formata da campi come "padre" e "madre", oltre a campi che creano rapporti con le località, con altre famiglie e con i record degli individui. La tabella "località" conterrà i dati dell’aggregazione dei dati ereditati da tutte le famiglie e da tutti gli individui. Resta quindi da creare la tavola "individui", che può essere fatto a partire dai battesimi, esportando separatamente tutti i padri, le madri, i padrini e le madrine, oltre al bambino, ovviamente. 

'''L'esportazione dei dati dei nonni''' è un punto di riflessione, perché nelle giovani comunità, di creazione recente, ad esempio, non sono presenti solitamente. Ma può essere rilevante se considerato dal team. Si consiglia di esportare questi dati insieme ad altre informazioni “strutturanti”, come i nomi della coppia, la data, la posizione e il codice identificativo della fonte. 

In caso di battesimi si consiglia di esportare anche la '''data di nascita''', se disponibile, oltre alla data di battesimo. In questo modo ogni individuo sarà associato ad una coppia, ma anche ad una località, date le altre relazioni, come il padrino e la madrina. Per elencare le morti, sarà necessario creare la '''relazione dal nome'''. Con queste procedure avremo un complesso '''sistema di analisi delle famiglie''' che permetterà diversi altri incroci, in modo tale da poter conoscere l'intervallo tra generazioni, i padrini e madrine, le famiglie senza padre, e una molteplicità di altri fenomeni sociali. Ma deve essere chiaro che questo sarà possibile solo con buone basi di dati di fonti che daranno un po' di lavoro, ma ne varrà la pena. 

Fatto ciò, saremo in grado di automatizzare molto i nostri sforzi, in modo tale che gran parte di ciò che è necessario sarà già fatto. L'automazione e la creazione di tabelle delle famiglie aiuteranno a rivedere il materiale precedentemente compilato. Il tempo è dedicato alla preparazione, ma al momento dell'analisi i dati saranno disponibili in pochi clic.

== '''Analisi dei social network''' ==

Gli studi sull'analisi dei social network sono emersi tra gli anni Cinquanta e Sessanta, con il lavoro pionieristico di '''Elizabeth Bott''' e le ricerche di '''Mitchell, Boissevain e Barnes'''. 

È una metodologia che '''enfatizza le interazioni umane''' come oggetto primario di analisi ed evidenzia i tipi e le forme di legami creati e mantenuti da determinate unità di analisi (che possono essere persone, aziende, città o parole) e come queste relazioni possono interferire con il comportamento e nelle scelte di queste unità. Forse la più grande giustificazione per l'uso di questa metodologia, oltre alle attinenti questioni epistemologiche, è la possibilità di '''visualizzare matrici e grafici''' che evidenziano chiaramente i '''legami tra le parti e osservare aspetti''' che non possono essere percepiti in altro modo. Ogni matrice e il suo corrispettivo grafico rappresentano un'istantanea dei collegamenti e vincoli di un gruppo. 

Il grafico è formato da '''nodi''' (che rappresentano le unità), '''linee''' (che simboleggiano le relazioni) e '''frecce''' (che indicano le direzioni delle connessioni). In base alle informazioni su questi elementi, i disegni e i colori del set possono variare, indicando raggruppamenti o specificità di determinate unità o legami. Per la creazione di questi grafici, esistono software interessanti e pratici come Gephi e Ucinet. 

La predisposizione di basi dati, per questo tipo di studio, richiede tabelle con le quali evidenziare i rapporti tra le parti, ovvero, raccogliere dati sulle unità associate "a coppie" per tipologia di rapporto. È vero che, molte volte, abbiamo gruppi che superano i due membri, ma '''devono essere scomposti a coppie''', fino a quando ciascuno abbia un rapporto con tutti, perché solo così sarà possibile evidenziare questi legami all'interno di una matrice. 

Nel caso ipotetico di un gruppo di persone, abbiamo uno scenario in cui quasi tutti si conoscono. Prendiamo una coppia di sposi e un amico del marito: in questo caso il marito ha rapporti sia l’amico sia con la moglie, risulta essere una sorta di intermediario. Tuttavia, la moglie e l’amico non si conoscono tra di loro, quindi non saranno collegati tra di loro. Il modo di rappresentarlo nell'analisi dei social network mi impone di presentare i dati indicandoli con 1 o 0 (1 = conosce; 0 = non conosce), chi è amico di chi, cioè coppia per coppia. Diamo un'occhiata a un esempio:

[[Arquivo:InRosiMetodo4.png|400px]]

In questo caso, zero (0) significa nessuna relazione e uno (1) significa che vi è relazione, senza dire di che tipo sia.

Graficamente, rappresentiamo la relazione così:

[[Arquivo:InRosiMetodo5.png|800px]]

Per una spiegazione più chiara, il lettore può leggere l'articolo specifico su come preparare i propri materiali per creare analisi di reti sociali.

Quindi, basta creare una tabella in cui i dati siano organizzati con questa struttura e tutto sarà risolto. Nel caso dei documenti di battesimo, ad esempio, sarebbe necessario spezzare i rapporti di compadrio in coppie: padre con padrino, padre con madrina, madre con padrino, madre con madrina. Ma non basta esportare i dati da una base parrocchiale a un programma di analisi di rete, poiché '''le interazioni si ripetono''' (lo stesso soggetto può essere associato ad un altro più volte, ad esempio) ed è necessario eseguire un controllo e certificare la qualità di tali relazioni. Con ciò, possiamo mettere, invece di 1 o 0, '''diversi numeri''', per indicare la ripetizione dei legami o la loro qualità - se si tratta di un amico, amicizia, vicinato - ecc. Quasi tutti i programmi consentono di '''presentare visivamente''' queste caratterizzazioni.

== '''Seriale''' ==

Un sistema per fonti seriali o '''seriali''' sarebbe, di per sé, centrato sulla fonte, poiché, nella maggior parte dei casi, '''quantifichiamo una singola fonte''', ad esempio solo le merci di inventario, o solo i registri di acquisto e vendita di una località. Tuttavia, '''alcune basi non sono realizzate con un'unica fonte'''. Non significa che siano erratamente concepite. 

La base di dati [https://www.slavevoyages.org/voyage/database ''Slave Voyages''] della ''Emory University'' è un buon esempio. È stato realizzato con fonti molto varie che meriterebbero analisi molto diverse. Ma così facendo, la base non sarebbe mai completa e non avremmo mai un'idea del volume di persone costrette ad attraversare l'Atlantico. In alcuni casi - e questo dipenderà dalla pianificazione del team - potrebbe essere necessario '''creare una base seriale che non sia legata ad una sola fonte primaria''', che sia quindi un mosaico deformato, presentandoci pertanto un'immagine, anche se sfocata, di ciò che vogliamo sapere. Per questo tipo di approccio valgono alcuni aspetti che abbiamo già accennato: pianificazione, confronto, esperienza con la fonte di dati e test. Questo può garantire un buon sviluppo. 

}}