Ladeira Livros

Como se faz um banco

de dados em História
Tiago Gil
Laboratório de História Social
Universidade de Brasília

2021
Copyright © Tiago Luís Gil
Capa: Joaquim Nina
Preparação dos originais: Amanda do Couto
Revisão: Vinícius Maluly

Ladeira Livros
Rua General Câmara, 385
Centro
Porto Alegre

ISBN: 978-85-69621-04-1

Conselho Editorial
Massimiliano Grava (Università di Pisa)
Martha Hameister (UFPR)
Tiago Bernardon de Oliveira (UFPB)
Índice

Nota introdutória desta edição 6

Introdução 7

Algumas questões teóricas e metodológicas 11

Um artesanato, uma operação 14

Desmontando as coisas “em ordem” 22

Em ombros de gigantes 33
A experiência do Padre Busa em 1949 33

O Colóquio da École Normale Supérieure de Saint-Cloud de 1965 36

Lawrence Stone, no início dos anos 1970 40

O primeiro Manual de Computação para historiadores 44

“Reconstructing historical Communities”: um projeto pioneiro 47

Manfred Thaller e o kleio 50

O sistema Fichoz 52

Algumas questões próprias da informática 55

Sobre granularidade 55

Tabelas simples 60

Modelos Hierárquicos 62

Bancos de dados Gráficos 63

 Key-value 65

Document-oriented 66

Bancos de dados relacionais 68

Bases relacionais 74

Modelos conceituais, lógicos e físicos 83

Modelo conceitual 83

Modelo lógico 85

Modelo físico 86

Dicionários de dados 87

Aspectos visuais sobre as bases 88

Formas diferentes de visualizar dados 89

Cores 93

Formas 94

Entre a técnica e a teoria: problemas cotidianos e decisões

práticas 97
Homônimos 97

Atualizar, normatizar ou manter o original? 101

Formatos de data 104

Texto integral ou fragmentos? 106

Reutilização de dados 106

Fuzzy information 108

Os campos “Observações”, “comentários” e “notas” 110

Engenharia de pesquisa 112

Levantamento inicial 112

Montagem de equipes 113

Treinamento 115

Coletando os dados e abastecendo a base 116

Estratégias de coleta 117

O preenchimento manual da base 121

Importando dados (digitais) 122

Importando dados (analógicos) 125

Administração da base 125

Checagem de dados 126

Problemas e perigos em bases de dados mal feitas 128

Montando bases: alguns exemplos concretos 133

Bases centradas na fonte 135

Registros de batismo 136

Escrituras públicas 147

Correspondências 153

Fontes dialógicas 156

Bases centradas no método 159

Prosopografia 159

Análise demográfica (“Método Henry”) 162

Análise de redes sociais 165

 Seriais 167

Bases de dados multitarefas: o sistema Malta 169

Bibliografia 174
Nota introdutória desta edição

Esta é uma versão ampliada e corrigida da edição anterior.

Foram feitas muitas adições na parte técnica (Capítulo 2), onde
outros modelos de bancos de dados foram apresentados e
discutidos, além de uma longa discussão sobre o conceito de
granularidade. Novos exemplos de tratamento de fontes foram
adicionais ao Capítulo 4 e o Capítulo 1 foi corrigido e
incrementado com novos trechos. Espero que seja útil ao leitor.
Introdução

Este é um livro voltado para estudantes de História e para quem

quer informatizar sua pesquisa desde o começo. Por
“informatizar” quero dizer criar uma base de dados. Seu objetivo
é de ajudar o leitor a incrementar sua pesquisa em História, com
algumas aplicações possíveis para as ciências sociais em geral.
Não se trata de um manual técnico. A proposta aqui é contribuir
para o leitor pensar como alguns recursos próprios do universo
das bases de dados e da informática podem melhorar a
investigação, desde a proposição do problema até a escrita do
trabalho, passando pela coleta e análise das informações que
darão suporte às conclusões. A atenção, contudo, ficará nas
formas de organizar os materiais.

É temerário escrever um livro como este. Tratando-se de

informática, ele estará datado em poucos anos. Todavia, tentei
escrevê-lo pensando em questões “clássicas”, de longo prazo,
inclusive tomando auxílio de debates entre História e
Informática que existem desde os anos 1960. Estes debates
apresentam alguns problemas estruturais na organização das
informações que é própria do trabalho do historiador, com a
chegada cada vez mais avassaladora das máquinas. E, como
defensor do planejamento, tentei pensar o texto para além do
seu consumo imediato, de modo a prolongar seu uso no tempo,
no tema e no espaço. Veremos que é conveniente fazer a mesma
coisa com as bases de dados.

O perigo da rápida obsolescência desse tipo de publicação se

agrava em consequência da necessidade quase direta de
referência ao uso de certos programas. Amanhã os programas
deixarão de existir e outros (melhores ou não) serão lançados.
 8

Para tentar amenizar isso, o texto todo foi escrito levando em

conta aspectos mais gerais dos programas, sem referência a um
pacote específico. Fiz isso não apenas pelo problema da
obsolescência. Geralmente as pessoas acham que construir
bancos de dados ou fazer análise de redes sociais, para dar um
exemplo, resume-se a usar um programa, minimizando a mão do
historiador em seu trabalho. Aqui quero o trabalho humano,
para o bem e para o mal, mostrando as opções por trás desse
personagem que faz pesquisa usando (ou não) bases de dados.

Muitas vezes, utilizarei metáforas relacionadas ao universo da

cozinha, não apenas por uma questão didática, mas também por
acreditar que, de fato, são campos que têm alguma semelhança.
E vou começar com um exemplo claro. A proposta aqui não é de
criar sistemas que façam todo o trabalho, com uma completa
mecanização. Não quero propor uma “máquina” onde você
coloca todos os produtos, como leite, batatas, manteiga, alho e
sal, para na ponta dela sair um belo purê. É preciso conhecer as
“engrenagens” da base de dados. Nesse caso, a ideia é de um
meio-termo entre o artesanato simples, amassando as batatas
com a mão, e aquela nefasta máquina que faz tudo sozinha.
Garfos, facas, descascadores e multiprocessadores podem ser
úteis. Proponho, assim, um “artesanato automatizado”, com o
uso pontual e deliberado de recursos informáticos. E como
artesanato que é, convém ao historiador saber construir suas
próprias ferramentas ou saber adaptá-las para usos inusitados,
como é quase tudo em História.

Ao leitor cético ou desconfiado das bases de dados ou das

possibilidades que a informática oferece na produção do
conhecimento histórico, já aviso que este será um livro de
História. Vamos falar de alguns problemas próprios do universo
 9

da pesquisa, desde a proposição do problema até a redação

final. Ao leitor que acredita que as bases de dados são um
problema exclusivamente técnico, lembro que existem milhares
de bases de dados tecnicamente perfeitas, mas que se tornaram
obsoletas e inutilizáveis diante de problemas próprios do
universo do historiador. Há bases que foram feitas para um tipo
de uso e, por opções mal feitas na sua origem, não permitem
nada além e há aquelas que nem sequer conseguiram responder
à pergunta original. Sim, porque as bases têm relação direta com
nossas perguntas (ou deveriam ter). É preciso planejar para tirar
proveito delas. Quanto mais planejadas, por mais tempo serão
úteis.

Um banco de dados pode servir para escancarar nossas posições

teóricas mais ocultas e até algumas indesejadas. Quando somos
obrigados a racionalizar nosso objeto a ponto de fazê-lo caber
em registros de uma tabela, precisamos expor mais as nossas
posições. Não há espaço para um pensamento como “nosso
tema é muito complexo” (como se alguns temas fossem
simples). É preciso saber como dar vazão a essa complexidade e
precisamos fazer isso de modo claro, de tal maneira que até um
computador entenda. Só tiramos da máquina aquilo que
colocamos lá dentro.1

Em 1996, um livro interessante, do qual pretendi tirar bastante

proveito, foi lançado na Inglaterra. Databases in historical
research, de Harvey e Press, tinha tudo para ser uma obra de
referência entre os historiadores. Pensava a história no meio da
evidente encruzilhada a que a humanidade estava chegando,

1
CHARLE, Christophe, Problemes de traitement informatique d’une enquete
sur trois élites en 1901, in: MILLET, Hélène (Org.), Informatique et
prosopographie, [s.l.]: CNRS, 1985.
 10

representada pela informática. O livro parece antever que, no

futuro próximo, cada vez mais os historiadores utilizariam as
bases de dados para incrementar suas pesquisas, mas não foi
assim e nem Harvey e Press foram os primeiros a errar com essa
mesma previsão. Contudo, o caso deles é especial. Quando
escreveram sua obra, as databases estavam se consolidando na
informática, em todos os campos do conhecimento e pareciam
mesmo estar tornando-se um tema hegemônico na relação
entre história e informática.2

Este livro não pretende rememorar os velhos tempos em que as

bases de dados podiam ser vistas como o futuro da história.
Entendo que, desde meados dos anos 1990, os historiadores
que dialogavam com a tecnologia da informação já não são os
mesmos que constroem bancos de dados para suas pesquisas.
Estes últimos me parecem o público mais direto dessas linhas.
Se não é a maioria dos historiadores, este é lá outro problema. O
nosso, aqui, consiste em discutir sobre boas formas de fazer
pesquisa histórica centrada em bancos de dados, como diziam
Harvey e Press em meados dos 1990. Então, convido o leitor a
uma breve aventura pela tecnologia, mas sem sair do nosso
chão de historiador.

2
HARVEY, Charles; PRESS, Jon, Databases in Historical Research. Theory,
Methods and Applications, London: Macmillan Press, 1996.
 11

Algumas questões teóricas e metodológicas

Um banco de dados é quase uma forma de narrativa histórica.3

Ele obedece, perfeita ou imperfeitamente, aos preceitos e às
concepções de mundo (e, dentro desses, das opiniões sobre o
problema de pesquisa) do investigador. A primeira posição
teórica é acreditar que seja possível reduzir a complexidade do
social a ponto de fazê-la caber na forma de registros de uma
tabela, tal como os historiadores acreditam ser possível fazer nas
linhas de um texto. No entanto, essa não é a única posição
teórica possível no trabalho com bases de dados. Não quero
dizer que marxistas vão produzir bases de um tipo e que os
liberais produzirão, necessariamente, de outro, ainda que isso
seja perceptível e bastante provável. Nossas posições teóricas
podem ser variadas, heterogêneas, ecléticas, mas estão lá, no
cantinho delas, esperando a hora de aparecer para organizar o
mundo dentro dos nossos “produtos”. No caso da pesquisa em
História, isso inclui a escolha de objetos, de conjuntos de fontes,
de metodologias e de interlocutores. Na montagem da base de
dados não é diferente.

Para ser mais claro, apresentarei aqui diversas formas de

abordar o problema. Posso dizer que existem dois tipos de
bases: as “analíticas” (orientadas pelo método, como preferem

3
Não pretendo discutir o significado teórico de “narrativa histórica”, já
exaustivamente abordado por centenas de historiadores ao longo dos últimos
40 anos. Apenas para tomar um referencial, apresentarei aqui uma definição
retirada de Lawrence Stone, que ao apontar a volta à narrativa, destaca
algumas de suas características no discurso histórico: ser descritiva, focada
mais ao homem do que às circunstâncias, atenta mais ao particular e ao
específico que aos conjuntos e marcada pela retórica. STONE, Lawrence, The
revival of narrative: reflections on a new old history, Past and Present, n. 85,
p. 3–24, 1979.
 12

alguns autores), voltadas para um problema de pesquisa, e as

“empíricas” (orientadas pela fonte), que procuram dar conta de
um corpus documental, como uma base de registros paroquiais,
de batismos, por exemplo. Isso tem relação com uma concepção
de história que prevê o trabalho do historiador como um passo
importante para o acesso ao conhecimento do passado, uma vez
que as bases analíticas estariam orientadas por um problema de
pesquisa. As bases empíricas, por seu turno, organizariam o
material de trabalho, sem um acesso direto ao passado,
porquanto foram organizadas por um historiador de modo
diverso ao estado original da fonte.

Também poderia dizer que há dois tipos de bases de dados: as

anônimas e as com referência nominal. Existem as pesquisas que
demandam atenção às histórias pessoais e aquelas para as quais
isso não afeta o resultado. Poderia colocar, de um lado, as bases
de dados dos micro-historiadores, dos demógrafos historiadores
de Cambridge e de algumas “cepas” de demógrafos franceses.
No outro extremo, colocaríamos os cliometristas e dezenas de
demógrafos franceses tão tributários de Louis Henry como os
primeiros, mais interessados, contudo, em calcular o intervalo
intergenésico dos camponeses do Século XVII do que mapear as
opções de casamento de um núcleo familiar específico ao longo
do mesmo século.

Entre aqueles que fazem bases não anônimas, dando ênfase aos
agentes históricos e aos seus nomes, podemos apontar outra
divisão: os que fazem bases individuais (biográficas), os que
fazem bases “ação-por-ação” e aqueles que criam sistemas para
recolher, em outras bases, informações sobre os agentes. Não há
aqui uma hierarquia de qualidade de base nem “o melhor jeito”
de fazer o trabalho. Há três ideias de como deve ser feito o
 13

trabalho do historiador.

A primeira enfatiza as trajetórias individuais, atomizando os

personagens e dando pouco espaço para dinâmicas sociais e
situações inusitadas. Por exemplo, se criamos um campo para
“profissão”, teremos que colocar ali toda a informação de uma
vida de atividades ou escolher uma mais importante, varrendo
debaixo do tapete outras informações que poderiam se revelar
fundamentais no andamento da pesquisa. Porém, podemos
inserir vários campos de profissão: “profissão1”, “profissão2”,
etc. Quantos seriam necessários? Depende do personagem. E
qual seria a “profissão1” quando nosso herói mantém duas
paralelas? Estamos sempre fazendo opções, orientados por
nossos problemas de pesquisa. Até aí, tudo
epistemologicamente ótimo. O problema é que nossos
problemas de pesquisa mudam ao longo da pesquisa.

A segunda opção, registrar em tabelas “ação-por-ação” parece

muito melhor nesse sentido. Ao invés de registrarmos “pessoas”,
registraríamos "atos". Ela elimina os problemas apresentados
acima, mas não é nada neutra. Faz parte de uma concepção de
história muito em voga no atual estágio dos estudos, que
enfatiza a interação social e as redes de relacionamento. Talvez
não seja indicada para outros temas de pesquisa. Por outro lado,
o que são “ações” ou “atos”? Um espirro e um homicídio têm o
mesmo significado? Uma conversa tem semelhante estatuto e
deve ser desmembrada no mesmo formulário de um arranjo
matrimonial? Esse arranjo matrimonial significaria apenas um
registro na tabela ou dezenas deles (considerando a cerimônia
oficial, as testemunhas, a festa)?

A terceira alternativa pode ser tomada em diferentes contextos.

 14

Pode ter sido uma opção segura, em virtude da incerteza sobre

qual procedimento metodológico seria mais adequado para o
problema de pesquisa adotado,mas pode ser igualmente uma
solução de conveniência, diante de informações de fontes
diversas e desorganizadas. De modo geral, todas envolvem
aspectos teóricos, metodológicos e técnicos e fazem isso ao
mesmo tempo, de tal maneira que não podemos dissociar esses
três elementos durante o trabalho.

Um artesanato, uma operação

Já vimos que há muito do historiador por trás dessa aparente

decisão técnica de construir um banco de dados, mas isso não
ocorre por causa dos bancos. O mesmo poderia ser dito do
trabalho do historiador com seus recortes, suas notas, seus
instrumentos de organização dos materiais diários de trabalho,
fichas, cadernos, canetas ou laptops. Em texto clássico de 1974,
Michel de Certeau dizia:

Em história, tudo começa com o gesto de selecionar, de

reunir, de, dessa forma, transformar em "documentos"
determinados objetos distribuídos de outra forma. Essa
nova repartição cultural é o primeiro trabalho. Na
realidade ela consiste em produzir tais documentos, pelo
fato de recopiar, transcrever ou fotografar esses objetos,
mudando, ao mesmo tempo, seu lugar e seu estatuto.
Esse gesto consiste em "isolar" um corpo, como se faz
em física. Forma a "coleção". [...] O material é criado por
ações combinadas que o repartem no universo do uso,
que também vão procurá-lo fora das fronteiras do uso e
que fazem com que seja destinado a um reemprego
coerente. É a marca dos atos que modificam uma ordem
recebida e uma visão social. Instauradora de signos
oferecidos a tratamentos específicos, essa ruptura não é,
 15

portanto, nem apenas, nem à primeira vista, o efeito de

um "olhar". É necessária uma operação técnica.4

A técnica, geralmente desprezada pelos historiadores, assume

um lugar fundamental no texto de Certeau: “Se é verdade que a
organização da história é relativa a um lugar e a um tempo,
inicialmente o é por suas técnicas de produção [...] a história é
mediada pela técnica.”5 Isso significa exatamente aquele
conjunto de operações que começa com o gesto de selecionar e
de reunir, para em seguida criar o “material” por “ações
combinadas” que vão reparti-lo no “universo do uso” para um
“reemprego coerente”. Graficamente, poderíamos apresentar o
raciocínio da seguinte forma:

Figura 1 - Esquema ilustrativo de uma afirmação de Michel de Certeau

Em um texto de 1986, Jean-Phillipe Genet apresenta um modelo

aproximado do de Certeau, numa tentativa de produzir

4
DE CERTEAU, Michel, A operação histórica, in: LE GOFF, Jacques; NORA, Pierre
(Orgs.), História: novos problemas, São Paulo: Livraria Francisco Alves Editora,
1978, p. 30.
5
Ibid., p. 28.
 16

conhecimento histórico com o uso de bancos de dados.6 Para

ele, tudo começa com o Real Passado, um abstrato “mundo
real” do qual não temos todos os indícios, decorrente da perda
ou do desconhecimento desses traços, ou seja, por um déficit
“positivo”. Com um processo de seleção e busca, montamos um
Real Histórico, composto pelas fontes conhecidas. Uma vez
coletadas e interpretadas, elas se transformam em uma coleção
(palavra que também é utilizada e reforçada por Certeau) de
dados que Genet denominou de metasources (metafontes).
Graficamente, o argumento do autor poderia ser expresso da
seguinte maneira.

Figura 2 - Esquema ilustrativo de uma afirmação de Jean-Phillipe Genet

Poderíamos antepor um elemento diante desses dois modelos:

um problema de pesquisa. A seleção das fontes, mencionada
por Certeau, só faz sentido diante de um problema/questão que
oriente essa seleção. É bem verdade que o problema pode se
apresentar no contato com alguma documentação e não apenas
com a leitura de outros estudos (muito menos por um cérebro
genial ou pela intercessão divina). Não importa de onde surgiu a
ideia. Importa é que, colocado um problema, mesmo que frágil,
6
GENET, Jean-Philippe. Histoire, informatique, mesure. Histoire &
Mesure, v. 01, n. 01, p. 07–18, 1986.
 17

ele demanda o passo seguinte - a seleção das fontes. O esquema

ficaria um pouco alterado, mas coerente com as posições acima
apresentadas, começando com um problema, que tem origem
na experiência do historiador, seja com fontes, com sua vida
pessoal, com suas leituras. O historiador seleciona e reúne suas
fontes para desmontá-las com “ações combinadas”. Cria-se um
“material” ou "metafontes" que serão reordenadas na análise e
descritas em um texto, mediado pelas opções teóricas e
metodológicas do autor e pelo problema de pesquisa original.

Figura 3 - Esquema das etapas da produção do conhecimento histórico

Essa descrição de procedimentos, que enfatiza as técnicas

próprias do historiador, é, agora, nosso foco no debate sobre a
informatização. Há décadas os historiadores buscam
automatizar seus procedimentos e, como foi dito antes, não há
como criar um software em que, utilizando as técnicas do
conhecimento histórico, coloquemos o problema e obtenhamos
a resposta. O que é possível (e bastante viável) é automatizar
alguns procedimentos do historiador em cada uma dessas
etapas para que o pesquisador possa fazer tantas “ações
combinadas” quanto pretenda, de modo eficiente, e criar uma
 18

ferramenta com a qual ele possa reunir os materiais, os dados,

ou as "metafontes", em um ambiente que permita seleções,
buscas e ordenamentos variados sem a perda da informação
original. Em suma, trata-se de organizar o trabalho de modo a
permitir experiências. Como disse o mesmo Certeau:

A utilização de técnicas atuais de informação conduz o

historiador a separar o que até agora se encontrava em
seu trabalho: a construção dos objetos de pesquisa e,
portanto, também as unidades de compreensão; a
acumulação de "dados" (informação secundária, ou
material refinado) e seu arranjo em lugares onde possam
ser classificados e deslocados; a exploração tornada
possível pelas diversas operações a que esse material é
suscetível.7

Ressalte-se, contudo que esta tarefa tem suas dificuldades. Se

for correto que podemos “administrar” muito melhor nossos
dados com o uso de uma boa base, é igualmente certo que uma
base mal feita vai gerar problemas de toda ordem. Criar uma
tabela para coletar os dados de uma fonte pode parecer muito
simples em alguns casos, mas não o é. Novamente Genet nos
apresenta um problema crucial: a necessidade de conhecer
profundamente as fontes que utilizamos antes de montar um
banco de dados com elas. Conforme o autor:

O dado [...] é um artefato, no sentido que os

arqueólogos empregam este termo, um objeto
construído em função de alguns objetivos bem precisos.
De uma mesma fonte dois historiadores extraem dados
completamente diferentes. A operação de constituição e
de estabelecimento do dado depende, assim, de três

7
Ibid., p. 34.
 19

parâmetros complementares. O primeiro, que é preciso

manter no seu devido lugar é a crítica das fontes [...]
justamente por causa das imensas possibilidades
oferecidas pelo computador, me parece que a crítica das
fontes sobre todas as suas formas se impõe com um
rigor maior...8

É preciso saber o modo como a fonte foi construída, seu público,

seus autores, seus limites, seus objetivos e quais interesses
agiram para que aquele documento chegasse àquela forma (que
finalmente teve, mas que diferentes projetos desejavam alterar).
Além dessa erudição documental, Genet destaca a importância
do conhecimento técnico sobre as bases e seu diálogo com o
fazer histórico e com a erudição das fontes. Ao escolher campos
que acolherão nossos dados, estaremos escolhendo quais
informações vamos privilegiar e quais as que serão consideradas
menos importantes ou que serão menos “desdobradas”.

Podemos criar um campo data, mas também preparar um para

dia, outro para mês e finalmente um para o ano. Se a opção for
pelo primeiro, importa elaborar um campo do tipo “data” (como
veremos adiante). Caso contrário, podemos estabelecer campos
numéricos para dias, meses e anos. Interessa, no entanto, fazer
esse desdobramento? Nossa pergunta demanda padrões que
envolvam atividades regulares dentro de um mês (como o
pagamento de aluguéis)? Ou dentro de um ano (aniversários ou
safras)? E se nossas atividades tiverem uma regularidade
semestral ou quinquenal? Saber escolher os campos certos é
tecnicamente importante, não somente pela técnica da

8
GENET, Jean-Philippe, Histoire, informatique, mesure, Histoire & Mesure,
v. 01, n. 01, p. 07–18, 1986, p. 10 e 11(Tradução nossa. O original está em
francês).
 20

informática, mas também por nossas técnicas de historiador.

O mesmo Certeau que discutia sobre o que faz o historiador

quando faz História falava, naquele ano de 1974, do uso do
computador em nossa disciplina. Não o fazia com a maestria do
programador, mas com a do estudioso do tempo e , ao fazer
isso, ressaltava exatamente a mão do pesquisador nesta
empreitada e seu lugar no tempo. Na página 33, ele afirma:

A especificação de seu papel [da história] não é

determinada pelo próprio aparelho (o computador, por
exemplo) que coloca a história no conjunto de opressões
e possibilidades nascidas da instituição científica
presente. A elucidação do próprio da história é
descentrada em relação a esse aparelho: reflui no tempo
preparatório de programação que a passagem pelo
aparelho torna necessária, e é rejeitada [no sentido de
um resultado, expelida] no outro extremo, no tempo de
exploração aberto pelos resultados obtidos. Elabora-se,
em função dos interditos fixados pela máquina, por
objetos de pesquisa a serem construídos, e, em função
do que permite essa máquina, por uma maneira de
tratar os produtos standart da informática.9

Novamente, aqui o foco está nas decisões do historiador, ao

planejar a programação sobre os materiais que utiliza. Ele
também enfoca os limites da máquina, que acabam entrando no
que é possível obter de resposta. Como já dissemos, isso pode
ser matizado através do conhecimento técnico de informática.
Veremos isso mais adiante.

9
DE CERTEAU, A operação histórica, p. 33. Grifo nosso.
 21

Nos anos de 1960 e 1970, o desejo pela informatização era

justificado pela dificuldade de contar grandes séries e de
analisar regularidades de longos textos. Na França, na Inglaterra,
na Alemanha e nos Estados Unidos, o foco do uso destas
máquinas se justificava na contagem de grandes massas
documentais de fontes “homogêneas”. Era o momento de
concepção de muitos trabalhos que ficariam prontos nos anos
de 1970 e 1980. Esse interesse profundo pelas séries não foi
apenas um modismo ou febre, mas fruto de uma mudança de
concepções que teve consequências profundas na forma de
fazer história. As séries se tornaram importantes diante da
crescente preocupação com a definição de modelos.

As séries agora abriam o flanco de um debate até então

interdito, dada a impossibilidade física de observar grandes
regularidades sociais e, consequentemente, seus limites, suas
rupturas e seus casos excepcionais. Foi nesse contexto em que
certos objetos se tornaram possíveis, encontrados nas margens
daquilo que se encaixava nos modelos de muitos historiadores.
Igualmente, foi nesse contexto que a inclusão do computador
como uma ferramenta do historiador se tornou relevante e isso,
especialmente para a constituição de grandes bancos de dados
de séries manejáveis e não apenas para flutuações demográficas
e econômicas, mas igualmente para o estudo de regularidades
nos textos, além das hierarquias sociais - o que é visível na
preocupação com os estudos das categorias sócio-profissionais.

Se for correto que nós historiadores temos nossa forma e nossas

técnicas de organizar a informação que nos são tão caras em
virtude das especificidades do conhecimento histórico, nada nos
impede de dialogar com nossos vizinhos da informática, para
observar como organizam as informações, como dispõem de
 22

meios eficazes e criativos de organizar o mundo entre tabelas e

registros. Uma das demandas fundamentais desse esforço passa
pelo desafio de classificar as coisas, no caso da informática,
atribuindo-lhe uma codificação. Classificar é parte do trabalho
do historiador. Pode-se perguntar se é possível fazer história sem
classificar. Chamar um ser humano de agente histórico já é uma
classificação, assim como chamá-lo de ser humano. Do ponto de
vista da Química, é um amontoado de átomos, maiormente de
carbono. Ademais, posso dividir esses amontoados de carbono
entre os que detêm os meios de produção e os que vendem sua
força de trabalho; ou entre o príncipe e o povo.

Trata-se não apenas de fazer uso de instrumentos de

comparação, mas de formalizar nossos critérios (na escolha dos
campos, por exemplo) com a clareza necessária para o
processamento. Se estudo uma obra literária, como sei se o
gênero que tenho em mãos (romance, poesia, etc) era comum
na época ou um formato marginal? As coisas só são o que são
em sua relação com as outras. Digo que é uma obra de ficção
pois sei que existem outras disponíveis que não o são. É certo
que posso definir o contexto a partir do texto, como sugerem os
contextualistas ingleses, e que isso me ajuda a compreender
diversos aspectos daquela sociedade que gerou o texto, mas
sem comparar, classificar ou contar, ficarei privado de qualquer
afirmação que inclua expressões como “a maioria”, “a menor
parte”, “um bom número”, “poucos”, “melhores” e “piores”.
Nesse sentido, formalizar nossos critérios em um banco de
dados facilita a comparação e permite uma clareza maior do
universo que estamos estudando.
 23

Desmontando as coisas “em ordem”

Colocar a história dentro de um banco de dados é uma

simplificação, mas nosso trabalho é sempre uma simplificação. A
complexidade da vida social não cabe no texto, tanto que
precisamos de conceitos para nos aproximar dela, como
tampouco cabe nos campos de uma base. Resta simplificar
menos ou, como disse Jean-Philippe Genet, admitir a obrigação
de consentir um empobrecimento fundamentado que estabelece
o trabalho científico.10

A criação de base de dados tem como pressuposto a

possibilidade de tomar um papel velho11, que a pesquisa
transformará em fonte, de modo a produzir um “desmonte”. Em
outras palavras, vamos tomar um documento e desfazê-lo em
pedacinhos. Porém, esse procedimento só terá sentido se os
pedacinhos forem reorganizáveis depois, se pudermos
apresentar diferentes problemas para transformar aquele
conjunto de pedacinhos em uma narrativa clara. E o mais
importante: nesse processo todo de desmonte, é o historiador
que deve estar coordenando tudo, decidindo, optando e
remontando as coisas segundo critérios do nosso métier. É
preciso muito planejamento para que as bases sejam úteis nesse
processo.

Há diferentes formas de construir bases de dados, como já

argumentei, e cada uma delas é fruto de uma forma de pensar a
história. Da mesma maneira, cada uma dessas opções vai
10
GENET, Histoire, informatique, mesure(Grifo nosso. O original está em
francês).
11
Faz referência aos documentos, que podem ser orais, imagéticos ou de
qualquer outra natureza.
 24

envolver formas diferentes de “desmontar” os materiais, tanto

os empíricos como com os interlocutores (bibliografia). Contudo,
a construção de bancos de dados não é tão subjetiva como pode
parecer. Há certos procedimentos que são importantes e
regulares em qualquer pesquisa. Adiante, veremos que as partes
integrantes de uma base são as tabelas, compostas por campos
e registros. Criamos campos como “caixinhas” onde colocamos
certas informações que nos parecem iguais. Essa simplificação, é
importante dizer, não é privilégio de quem usa bases de dados.
Dizemos que todas as datas são datas, tanto o dia de hoje
quanto o 14/07/1789, mesmo que tenham significados
simbólicos muito diferentes. Dizemos que João e Pedro são
nomes de pessoas e não simples conjuntos de letras.

Faz-se o mesmo em bases de dados. Contudo, dependendo do

problema de pesquisa e das características de cada fonte,
podemos dizer que para fins de criação de bancos de dados, há
dois tipos de fontes: aquelas para as quais a forma é muito
importante e aquelas em que a forma não é tão importante.12
Por forma, estou entendendo aqui a regularidade linear de
certos fragmentos dentro de um documento. Na frase “Eu sou
professor de História”, há uma ordem linear importante, sujeito,
verbo e complemento. Se eu alterar os fragmentos, o sentido
será igualmente alterado. Algo semelhante acontece, por
exemplo, com registros de batismo. Desde que começaram a ser
feitos de modo sistemático (e preservados), na Itália do Século
XIV,13 eles seguem um modelo muito particular, como no

12
Agradeço ao Professor Jean-Pierre Dedieu por chamar a atenção para este
ponto.
13
DE VRIES, Jan, Population, in: BRADY JR., Thomas; OBERMAN, Heiko; TRACY,
James (Orgs.), Handbook of European History 1400-1600. Late Middle Ages,
Renaissance and Reformation., Leiden / New York / Koln: E. J. Brill, 1994.
 25

exemplo abaixo:

Aos quatro do mês de novembro de mil oitocentos e

dezoito anos, nessa Igreja Matriz do Patrocínio de São
José, batizei e pus os santos óleos ao inocente Francisco
filho de Manoel Roberto, e Maria Izabel, naturais dessa
freguesia. Padrinhos o Capitão Francisco da Silva, e
Leucadia Maria, sua mulher, todos fregueses dessa
freguesia. Fiz e assinei. O Vigário Colado, Theodoro José
de Freitas Costa14

A forma é importantíssima em um registro de batismo que,

dificilmente, começará com o nome dos padrinhos. Esse modelo
será igual, na ordem dos fatores, em milhões de registros no
mundo todo: data; local; ato (batismo e óleos); nome do
batizando; pais e padrinhos (com as respectivas informações
pessoais); assinatura. É claro que há muitíssimas nuances e
variações e já falaremos delas, mas há uma longa e constante
regularidade para a maior parte dos casos ou, melhor, há uma
expectativa, da época e nossa, de que essas informações
apareçam. Deveriam aparecer.

O outro tipo de fonte é aquela em que a forma, no sentido já

expresso, de sequência linear de informações, não é importante
e nem esperada. Para um texto ficcional, por exemplo, não há
expectativa de formato, salvo uma ligeira ideia de que eles são,
geralmente, divididos em capítulos, mas nem isso é tão sério. O
mesmo ocorre com as correspondências. Elas têm algumas
regularidades, como os livros têm suas editoras e autores:
remetente, destinatário, data e local, mas seu conteúdo interno,
a carta propriamente dita, não é formalizável. Podemos criar

14
Livro de Batismos 02, São José. 1818. Arquivo da Cúria de São José dos
Pinhais.
 26

campos para destacar as pessoas e os locais mencionados, mas

essas informações não são partes necessárias de uma carta, nem
são esperadas pelo leitor ou pelo pesquisador.

Se for correto que é preciso planejar para criar uma boa base de
dados, é igualmente importante ter uma boa quantidade de
informações prévias para iniciar o planejamento. Saber
diferenciar as potencialidades diversas de cada conjunto
documental é fundamental para iniciar os trabalhos. E o caráter
mais ou menos “formal” dos documentos é um bom critério de
avaliação. É preciso conhecer a fonte para prever problemas.
Eles sempre estarão presentes, os problemas, mas o
planejamento nos livrará daqueles mais estúpidos, dos quais
crítico nenhum nos poupará.

Saber identificar a forma em um documento não é algo simples.

Continuemos planejando a informatização dos nossos registros
de batismo. Para eles basta uma tabela que tenha poucos
campos:

Figura 4 - Modelo de tabela para batismos

 27

Já temos pronto nosso banco de dados. Vamos começar a

preenchê-lo. O próximo registro que vamos incluir será este:

Aos vinte de março de mil oitocentos e dezoito anos

nesta Igreja Matriz do Patrocínio de São José, batizei e
pus os santos óleos ao inocente João, filho legitimo de
Joaquim Álvares e Maria dos Anjos, naturais dessa
freguesia. Padrinhos, João de Bastos e Ana Álvares, sua
mulher, todos fregueses dessa freguesia. Fiz e assinei O
Vigário Colado Theodoro José de Freitas Costa

Vamos preenchendo tudo: data, local, nome do batizando, e...

filho “legítimo”? Essa informação não estava no registro
anterior, que orientou meu modelo, por essa razão a
"legitimidade" não foi incluída na minha base. Que tipo de
campo devo criar para dar conta disso? Que variáveis posso
encontrar nesta observação antes do nome dos pais que trata da
legitimidade da criança? E por que alguns registros
simplesmente omitem esse dado? Como dizia Certeau, “a
formalização da pesquisa tem precisamente por objetivo a
produção de "erros" - insuficiências, faltas - cientificamente
utilizáveis”. No nosso caso, a simples tentativa de organizar a
informação já nos trouxe questões fundamentais para
compreender a fonte e o universo cultural que estamos
observando. Criar um campo pode parecer absolutamente
técnico, e é, mas é muito mais do que isso. Segundo Dedieu,15 é,
ao encontrar o inesperado, que produzimos conhecimento e
formalizar dados em uma base pode ser um meio para isso.

Poderíamos encontrar outros tantos exemplos que nos

mostrariam que criar uma base de dados para registros de

15
JEAN-PIERRE DEDIEU, Entrevista.
 28

batismo não é tarefa fácil. A afirmação inicial de que bastaria

uma única tabela tampouco é correta (é possível, mas seria
melhor desdobrar em várias). Podemos falar, apenas para dar
algum exemplo, dos avós sobre os quais frequentemente há
informação. Também podemos lembrar o que normalmente
aparece sobre cada um dos participantes, dos pais e padrinhos:
sua origem, residência, condição social, posição política e suas
relações sociais. No mesmo livro de onde retirei aqueles
registros, é comum, por exemplo, encontrar que o padrinho é
filho de um capitão. Então devemos inserir um campo “posição
militar do pai do padrinho”?

Em sua tese de doutorado, Martha Hameister16 nos conta de um

registro de batismo singular. No batizado de Felícia, filha de
escravos alforriada na pia batismal (do que se esperava a
liberdade sem interferência do senhor, já que o valor dela fora
entregue no ato do batismo, segundo o costume da época),
havia, além dos dados do batismo, um longo texto explicativo
que narrava uma tentativa de interferência do senhor da mãe
sobre a liberdade da menina, que fora inibida pelo pároco, que
justificava, detalhadamente, as motivações que orientaram sua
ação. É certo que tal documento é único, mas qual deveria ser o
tratamento dado para ele? Ignoraríamos tal maravilha por falta
de um campo “justificativa da insistência do padre em alforriar o
batizando”? Certamente não. Tampouco me parece boa a ideia
de apenas mencioná-lo no famoso campo “Observações”, onde
costuma cair tudo aquilo que não fomos capazes de planejar. Há
muitas formas de contar uma história, assim como há muitas
formas de montar uma base de dados. Mas a proposta aqui não

16
HAMEISTER, Martha Daisson, Para dar calor à nova povoação: Estudo sobre
estratégias sociais e familiares a partir dos registros batismais da Vila do Rio
Grande (1738-1763), UFRJ, Rio de Janeiro, 2006.
 29

é de apresentar uma base voltada para batismos. Não nesse

momento.

Os registros de batismo parecem muito mais complexos do que

o primeiro olhar nos permite supor. Ainda assim, há uma
regularidade em sua produção. No Século XX, encontraremos
até mesmo formulários previamente prontos, feitos em gráfica
para o registro de batizados pelos padres. Outro tipo de fonte
bastante regular são os inventários post-mortem, feitos para
identificar os bens dos falecidos para promover a partilha entre
os herdeiros. Difusos por boa parte do Ocidente, eles têm uma
estrutura bastante semelhante.17 Embora muitos dos disponíveis
pelo mundo não correspondam ao esperado, há certa lógica da
fonte que permite, entre outras coisas, a comparação. E se,
algumas vezes, encontrarmos inventários completamente “fora
da curva”, que nos trarão muitas dúvidas sobre como devem ser
inseridos na base de dados, o simples questionamento de suas
diferenças em relação ao padrão de sua feitura (que é inclusive
regulado por Lei) já nos dá muitas ideias sobre a sociedade que
o criou. A simples constatação da diferença já nos ajuda a fazer
boa História.

Talvez o mais interessante ao trabalhar com inventários seja

perceber seu caráter “plural”, digamos assim. Eles têm uma
sequência linear para a sua produção: abertura, avaliação dos
bens, apresentação dos documentos comprobatórios e partilha.

17
VAN DER WOUDE, A.M.; SCHUURMAN, A., Probate inventories: a new
source for the historical study of wealth, material culture, and agricultural
development : papers presented at the Leeuwenborch conference
(Wageningen, 5-7 May 1980), [s.l.]: Hes, 1980.
 30

18
É comum encontrar dados da família do falecido, assim como
informações sobre as famílias dos escravos que eram
propriedade do falecido, quando em sociedades escravistas.
Contudo, é possível encontrar uma diversidade de fontes não
previstas, como recibos de compra de medicamentos e
atendimento médico (geralmente em decorrência de alguma
doença que levou à morte o inventariado), assim como
testamentos e comprovantes de pagamento de serviços
fúnebres. Esses papéis eram incluídos, pois tudo deveria ser
pago antes da partilha.

Eis a sua “pluralidade”, que se aguça quando pensamos que a

abertura, a avaliação, os documentos e a partilha são,
igualmente, quatro fontes com estruturas muito diversas. Se
pensarmos em incluir os testamentos, teremos mais elementos
para estruturar dentro de uma base de inventários. Isso porque
os testamentos, apesar de lembrarem as cartas por sua
aparência (narrativa linear e o tamanho), são documentos
absolutamente estruturados, seguindo um cânone que pouco se
alterou em séculos.19 Havia uma fórmula, que informava sobre o
contexto da redação do documento, geralmente uma
enfermidade aliada a dúvidas sobre o que deus guardava para o
testador. Pedia-se clemência à Santíssima Trindade, aos santos e
às santas da corte dos céus, ao santo do nome da pessoa e ao(s)
santo(s) de devoção, em especial, e ao seu anjo da guarda. Na
sequência, uma lista dos últimos desejos.

Todas essas fontes têm uma forma importante, uma sequência

18
FRAGOSO, João; PITZER, Renato Rocha, Barões, homens livres pobres e
escravos - notas sobre uma fonte múltipla. Os Inventários Post-mortem,
Revista Arrabaldes, v. 1, n. 2, p. 29–52, 1988.
19
VOVELLE, Michel, Ideologias e mentalidades, São Paulo: Brasiliense, 1987.
 31

de fragmentos esperada tanto por nós quanto por seus

criadores. Isso não faz delas objetos fáceis de informatizar. Como
vimos, há sempre espaço para surpresas e isso é muito positivo
para a produção do conhecimento histórico. Contudo, grande
parte dessas “surpresas” não é exatamente surpreendente. É
muito normal, nas fontes que possuo, encontrar descrições
sobre a naturalidade dos avós do batizando, mas não é
surpreendente que sejam omitidas em muitos casos. Da mesma
forma, será comum encontrar informações as mais diversas
sobre os padrinhos. O padre não tinha em mente apontar a
patente militar de todos os padrinhos, mas mencionava a de
alguns. Será melhor colocar um campo “patente militar” para os
padrinhos ou criar uma tabela associada em que colocaremos
todas as informações que surgirem, as mais diversas e
imprevisíveis, sobre os participantes do acontecimento?

A solução não é simples e devemos pensar ainda mais longe.

Uma vez abastecida a base, devemos ter acesso fácil e
possibilidade de fazer buscas complexas nos nossos dados. Isso
será mais ou menos possível de acordo com a base que
montamos, da forma como dispomos os dados uns em relação
aos outros. O sistema de busca varia de software para software,
mas ele será mais ou menos eficaz de acordo com a estrutura de
campos que criarmos para acolher os dados. Da mesma forma, é
conveniente pensar na longevidade da nossa base. Para além de
usar sistemas que sejam fáceis de converter para formatos
futuros, fazendo essa migração de tempos em tempos, já que a
rápida obsolescência é algo comum no universo digital,
precisamos pensar em bases que atendam a mais de uma
pesquisa ou que estejam preparadas para pesquisas futuras. Os
debates sobre a reusability, ou “reusabilidade”, numa
desaconselhada tradução para o português, são bastante
 32

comuns e ainda não bem resolvidos.20 Contudo, manter o foco

na estrutura da fonte ainda é a saída mais conveniente e isso
requer alguma erudição, habilidade importante no Século XIX e
que ainda tem sua importância na programação do Século XXI.

20
SCHÜRER, Kevin, Historical demography, social structure and the computer,
in: DENLEY, Peter; HOPKIN, Deian (Orgs.), History and Computing, Manchester:
Manchester University Press, 1987; THALLER, Manfred, Methods and
techniques of historical computation, in: DENLEY, Peter; HOPKIN, Deian (Orgs.),
History and Computing, Manchester: Manchester University Press, 1987.
 33

Em ombros de gigantes

Fazer bases de dados em história tem sua própria história e ela

não é pequena. Vamos apresentar um levantamento seletivo de
experiências com esta perspectiva. Ele não apresenta todas as
experiências com bases que foram centenas no campo da
história, mas traz algumas que podem ajudar a pensar
problemas crônicos deste tipo de abordagem. Muitas das
questões que nos colocamos hoje já foram muito discutidas
antes por grandes nomes da historiografia. Vamos conhecer suas
experiências e aproveitar a viagem para apresentar alguns
problemas importantes no desenvolvimento das bases de dados.

A experiência do Padre Busa em 1949

Quando, em 1946, o padre jesuíta italiano Roberto Busa acabou

sua tese sobre o conceito de “presença” em S. Tomás de Aquino,
ele deu-se conta que as expressões geralmente tomadas na obra
do santo, “praesens” e “praesentia”, não eram as melhores para
o seu estudo. Aquele conceito se manifestava melhor na forma
da partícula “in”, que nunca fora organizada nos índices de que
dispunha para o estudo. Busa não acovardou-se e começou um
lento trabalho de organização dos textos tomísticos em fichas de
frases e de palavras. Neste momento surgiu a ideia de
“mecanizar” o trabalho. Anos depois, em 1949, em uma viagem
aos Estados Unidos, ele investigou as possibilidades existentes
em dezenas de universidades, encontrando diálogo junto à IBM.
Como ele mesmo conta, a primeira resposta foi negativa: não
seria possível fazer um índice daquele porte com os
equipamentos da IBM. Diante da negativa, Busa teria invocado o
 34

próprio slogan da companhia na época: The difficult we do right

away; the impossible takes a little longer (“O difícil nós fazemos
agora; o impossível demora um pouco mais”). Ganhou o apoio
da IBM, mesmo sem ter dinheiro.21
Toda a preocupação de Busa, naquele momento, estava no
processamento da informação e não nas formas de estocagem
dos dados. A forma de fazer isso já estava definida de antemão e
seguia os mesmos pressupostos usados por ele na confecção de
fichas manuais, que continham palavras, frases e suas
localizações nos textos tomistas. A palavra database (base de
dados) não aparece no seu texto, ainda que a expressão data
bank (banco de dados) seja utilizada uma única vez, justamente
quando ele narra as dúvidas que surgiram no momento de
publicar os resultados, se seriam publicados em um livro, na
forma de um enorme catálogo ou se somente seria oferecido o
banco gerado no processo. A opção final foi pela publicação de
quinhentos exemplares de um grande catálogo, possível graças
ao uso da linguagem binária em cartões e fitas magnéticas.
A primeira questão que me parece pertinente com este caso é a
forma com Busa criou uma demanda de pesquisa e foi em busca
da técnica para solucioná-la. E mesmo uma saída cara e que
levaria anos (neste caso, 30 anos), envolvendo o treinamento de
dezenas de ajudantes no processamento dos cartões perfurados
e fitas, foi pacientemente aceita tendo em vista o ganho maior
ao longo prazo. Esta é a segunda conclusão que podemos tirar
desta empreitada: o custo de desenvolvimento e abastecimento
de bancos de dados parece alto e certamente o é. Contudo, a
capacidade de recuperar os registros de forma automática,
rápida e fácil após a conclusão do trabalho é bastante

21
BUSA, Roberto, The Annals of Humanities Computing: The Index Thomisticus,
Computers and the Humanities, v. 14, p. 83–90, 1980.
 35

compensadora. Os materiais organizados por Busa ficaram

disponíveis para os pesquisadores da obra de Santo Tomás, que
poderiam agora, com qualquer problema de pesquisa, atingir
seus objetivos com grande velocidade.22
Por fim, temos o ausente presente, o conceito de banco de
dados, não apresentado por Busa em seu texto por ser
demasiado evidente para quem passou décadas criando um -
justamente naquilo que o projeto de Busa tinha de melhor:
armazenar conhecimento de modo organizado, de modo a
permitir rápida consulta posterior. Sendo assim, podemos definir
um banco de dados como um lugar onde podemos estocar a
integralidade das informações relativas a um assunto23,
entendendo que este último pode ser um tema ou um problema
de pesquisa. Outros acrescentariam que as informações de um
database deveriam estar estruturadas e interligadas entre si a
partir de um modelo lógico específico. Enfim, podemos resumir
dizendo tratar-se de uma coleção organizada de dados.24 Toda
esta discussão, contudo, passava longe da cabeça de Busa e só
se tornou central a partir dos anos 1970. Até então, a grande
promessa da informática não estava no armazenamento, mas no
seu grande potencial de processamento das informações. Por
outro lado, um data bank seria o conjunto dos cartões,
simplesmente.

22
Disponível na web no endereço: Index Thomisticus, disponível em:
<http://www.corpusthomisticum.org/it/index.age>, acesso em: 27 set. 2013.
23
Base de données - Wikipédia, disponível em:
<http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es>, acesso em:
27 set. 2013.
24
Database - Wikipedia, disponível em:
<http://it.wikipedia.org/wiki/Database>, acesso em: 27 set. 2013; Database -
Wikipedia, the free encyclopedia, disponível em:
<http://en.wikipedia.org/wiki/Database>, acesso em: 27 set. 2013.
 36

O Colóquio da École Normale Supérieure de Saint-Cloud de

1965

Em 1965, um grupo de historiadores também deixava registrado

seu debate sobre o uso de máquinas IBM e Bull. Não tratava-se
de um debate técnico, ainda que estas questões estivessem
sendo discutidas. Foi durante um colóquio realizado na École
Normale Supérieure de Saint-Cloud, em maio de 1965. O evento
reunia alguns dos nomes mais expressivos da historiografia
francesa de então, como Ernest Labrousse e Adeline Daumard.
Ainda estávamos no tempo do cartão perfurado e das fitas
magnéticas e estes foram alguns dos pontos tratados na
apresentação de Robert Faure, “Machines et programmes.
Quelques vues sur l'utilisation des machines à traiter
l'information en histoire sociale“.25 A intervenção de Faure indica
qual era o pensamento da época: a automatização das fontes,
ou seja, as passagens dos dados dos documentos históricos para
cartões ou fitas magnéticas que seria possível através do uso de
codificações bem feitas, a partir de um vocabulário ou
thesaurus.
Apesar do tom predominantemente técnico da apresentação de
Faure, bem como do debate subsequente26, entre cartões
perfurados e fitas magnéticas, ali já estavam colocadas algumas
questões importantes do ponto de vista do historiador e que

25
FAURE, Robert, Machines et programmes. Quelques vues sur l’utilisation des
machines à traiter l’information en histoire sociale, in: L’histoire sociale:
sources et méthodes, Paris: Presses Universitaires de France, 1967; FAURE,
Robert, Máquinas e programas. Pontos de vista sobre a utilização das
máquinas destinadas a elaborar a informação em história social, in: A História
Social: problemas, fontes e métodos, Lisboa: Edições Cosmos, 1973.
26
Os debates e comentários posteriores às apresentações foram todos
publicados na versão original francesa, bem como na edição lusa de 1973.
 37

tem relação direta com a mesma questão técnica. Em primeiro

lugar, o uso de um vocabulário é um elemento que vai seguir
atual para a construção de bancos de dados. Hoje os
programadores chamam isso de “Dicionário de dados”. Veremos
sobre isso mais adiante, não há pressa.
Outro ponto, este ainda mais fundamental, é introduzido na
apresentação de Faure e discutido com maior profundidade em
outra comunicação, de Jacques Dupaquier: o problema da
classificação e, consequente, uso de codificações. Faure
ingenuamente acreditava na possibilidade de uma codificação
perfeita que mantivesse as características da fonte. Contudo, um
dos comentaristas, Claude Mazauric, destacava que:

...a determinação do código é a questão mais delicada

para o historiador [...] pois de acordo com as datas, de
acordo com as épocas, com os tipos de documentos, as
informações não são equivalentes.27

Dupaquier, neste mesmo evento, apresenta o texto Problèmes

de la codification socio-professionelle.28 Sua apresentação volta
ao tema das classificações, mas de modo sutil. É no comentário
de Adeline Daumard que o tema ressurge de modo expressivo.
Daumard respondia aos críticos de seu trabalho sobre as
classificações sócio-profissionais, que era acusado de
estabelecer uma grade a priori. Concordando com seus críticos,
ela dizia que
...estabelecer esta classificação, estabelecer claramente

27
Mazauric, em comentário ao texto de FAURE, Machines et programmes.
Quelques vues sur l’utilisation des machines à traiter l’information en histoire
sociale(Tradução nossa. O original está em francês).
28
JACQUES DUPAQUIER, Problèmes de la codification socio-professionelle, in:
L’histoire sociale: sources et méthodes, Paris: Presses Universitaires de France,
1967.
 38

uma hierarquia, é quase, no fundo, resolver o problema.

Tratava-se de um problema clássico em história. Ao propor uma

pergunta, estamos enquadrando agentes e processos dentro de
certos parâmetros que nos parecem certos, mas, ao chegar ao
final da pesquisa, descobrimos os limites de nossos conceitos:

Se tivéssemos um código perfeito seria quase inútil de

estudar o que quero, a burguesia, pois saberíamos de
imediato o que ela é. Diante deste paradoxo é que está o
paradoxo da história: precisamos de uma classificação
para poder trabalhar; mas ao mesmo tempo, precisamos
nos resguardar de prejulgar o resultado. Esta é a razão
pela qual, na minha opinião, a solução deve ser a busca
de modo empírico, a fim de traduzir a realidade.29

Neste debate, classificação e codificação eram sinônimos e

codificar significava transferir as classificações para dentro da
lógica da computação da época. Codificar era a forma disponível
de manifestar formalmente as concepções
teórico-metodológicas do pesquisador, por meio de
procedimentos claros e transparentes. A partir de um estudo
preliminar, foi elaborada uma lista de classificações próprias
para as sociedades francesas do século XVIII, XIX e XX, dividindo
as pessoas entre agrupações profissionais, de renda e de
hierarquia social.
Em 1962, Daumard publicou um artigo com seu “projeto” de
classificação sócio-profissional.30 Era uma proposta de

29
Ibid.
30
ADELINE DAUMARD, Une référence pour l’étude des sociétés urbaines en
France aux XVIIIe et XIXe siècles projet de code socio-professionnel, Revue
d’Histoire Moderne et contemporaine, v. X, p. 185–210, 1963; ADELINE
DAUMARD, Structures sociales et classement socio-professionnel. L’apport des
 39

concepção, uma forma de entender a hierarquia social naquela

sociedade. Podemos dizer que tal texto correspondia ao que os
programadores chamam hoje de “Modelo conceitual”.
Era isso que fazia Daumard ao criar uma lista de identificadores
possíveis para o universo que estudava. E isso não era um
privilégio do tipo de história que ela fazia; é próprio do trabalho
do historiador. Estamos sempre escolhendo palavras que
identificam e caracterizam nossos objetos. Um banco de dados
exige isso na hora de seu desenvolvimento. A complexidade do
mundo social será sempre maior que nossa capacidade de
compreendê-la. Ou melhor, compreender demanda
simplificação. Resta-nos simplificar com a maior complexidade
possível. E, para isso, devemos estar atentos no
desenvolvimento destes modelos conceituais. A máquina não
vai entender coisas como “meu agentes se comportam de um
modo difícil de entender”. É preciso incluir esta complexidade no
modelo de modo claro.

Ao longo da década de 1960, muitos dos trabalhos que

enfatizavam a quantificação ou a classificação começaram a
trabalhar com a computação. Uma noção bastante difundida na
época era a de “homogeneidade”, conceito que achatava as
diferenças de potencial encontradas nas fontes, ignorando-as ou
tratando-as como pequenas anomalias. Foi um conceito que
norteou a pesquisa histórica e foi apoiado no trabalho com
computadores, uma vez que a máquina possuía regras que
deveriam ser seguidas, aparentemente sem questionamento ou
criatividade. Muitos dos pesquisadores discutindo as interseções
da história e da tecnologia da informação tinham pouco ou

archives notariales au XVIIIe et au XIXe siècle., Revue Historique, v. 86,

n. CCXXVII, 1962.
 40

nenhum conhecimento de computação. Podemos ver essa falta

em seus textos.

Era comum ignorar o debate técnico com frases de otimismo

sobre a máquina, sugerindo que, uma vez inseridos os dados na
máquina, caberia a ela “digeri-los”. Essa metáfora, utilizada por
diversos autores, foi fruto de um entendimento coletivo,
compartilhado por pesquisadores que preferiram utilizar outras
imagens, como um motor de carro, como veremos adiante. Essa
visão não era apenas tecnicamente difícil, mas continha um
certo desprezo pelo conhecimento computacional. Isso foi
claramente expresso em muitos textos, como na própria
contribuição de Faure. Segundo ele, o trabalho do historiador
com a fonte envolveu três partes: o estabelecimento dos
registros; contar e preparar tabelas; reflexão e escrita. E
concluiu: “Aparentemente, apenas este último terço constitui
atividade nobre; os dois primeiros se enquadram na categoria de
31
tempos mal utilizados. ”

Lawrence Stone, no início dos anos 1970

Vejamos agora um diagnóstico, feito em 1971, por Lawrence

Stone, em seu célebre Prosopography, publicado naquele
inverno na revista Daedalus. Em um texto direto, ele
apresentava a metodologia que havia consagrado seu clássico
livro The Crisis of the Aristocracy.32 O uso do computador era

31
No original: “Apparemment, seul ce dernier tiers constitue l'activité noble;
les deux premiers ressortissent à la catégorie des temps mal employés.”.
FAURE, Machines et programmes. Quelques vues sur l’utilisation des
machines à traiter l’information en histoire sociale
32
STONE, Lawrence, The Crisis of the Aristocracy, 1558-1641, Oxford: Oxford
University Press, 1965.
 41

ainda considerado uma novidade, uma vez que os

historiadores...

lenta e timidamente começam a explorar as

potencialidades da nova ferramenta tecnológica, eles
começam a perceber sua quase ilimitada capacidade de
lidar precisamente com o tipo de material que a
prosopografia apura.33

Stone nos apresenta o cenário do uso destes equipamentos no

meio acadêmico anglo-saxão da época. Apesar de considerar a
Inglaterra e os Estados Unidos como o primeiro e o segundo
centros de pesquisa em história do mundo, ele admite que seus
colegas americanos e franceses estavam na frente no mundo da
informática:

...há fortes traços nacionais para essa divisão de

perspectivas - pois os estadunidenses e os franceses têm
muito mais acesso e confiança nos computadores que
seus colegas ingleses -, fortes traços culturais - com
ameaças de uma nova guerra entre os antigos e os
modernos, entre as humanidades e as ciências...34

Havia motivos para tanto receio. O próprio Stone apontava

alguns dos problemas advindos com o uso do computador. Ao
comentar uma possível tendência de separação entre a
prosopografia “das massas” (foco nos grupos) com a das “elites”
(foco nos grandes homens), ele destacava o papel do
computador neste perigo:

O perigo foi bastante aumentado pelo advento do

computador, que foi adotado pelos pesquisadores mais
estatisticamente orientados com todo o entusiasmo

33
STONE, Lawrence, Prosopografia, Revista de Sociologia e Política,
v. 19, n. 39, p. 115–137, 2011.
34
Ibid.
 42

indiscriminado dos ninfomaníacos e rejeitado pelos

menos científicos, em parte devido a melindres
intelectuais, em parte devido a uma complacência
ignorante dos prazeres que estão perdendo. 35

O uso de grandes computadores, dentro das humanidades,

ainda era privilégio dos cientistas políticos. Naquele contexto,
eram os estudos de eleições uma das principais aplicações das
novas tecnologias. Para Stone, o maior trunfo do computador
era...

A correlação de numerosas variáveis afetando grandes

massas de dados, reunidas em uma base uniforme, é
precisamente o que o computador pode fazer melhor; é
também o que há de mais laborioso e, em vários casos,
virtualmente impossível de trabalhar sem auxílios
eletrônicos, mesmo para os historiadores com
orientação mais matemática. É doloroso admitir que o
advento de um aparato técnico poderia ditar o tipo de
questões históricas formuladas e os métodos utilizados
para solucioná-los36

Mas Stone era otimista ao considerar que:

A disponibilidade do computador crescentemente

seduzirá os historiadores a concentrar suas energias nos
problemas que podem ser solucionados pela
quantificação, problemas que às vezes - mas de maneira
nenhuma sempre - são os mais importantes ou
interessantes.37

Tal como para Busa e Faure, era o processamento de grandes

quantidades de registros que importava. Ainda não estava claro
o uso de bancos de dados que permitissem consultas

35
Ibid.
36
Ibid.
37
Ibid.
 43

sistemáticas, mas algo mais fica sugerido no texto de Stone. É a

demanda por materiais “uniformes”. Tanto Faure como Busa
estão, o tempo todo, pensando em processar uma única fonte.
Para Busa, é o texto de Santo Tomás; para Faure, as fontes
devem ser transferidas para fitas magnéticas. No caso de Stone,
parece haver espaço para combinar dados de diferentes origens
dentro de bases “uniformes”.

Por outro lado, ele retoma o debate sobre as classificações,

reforçando aquilo que Daumard e Dupaquier já salientavam.
Stone falava dos erros frequentes nos estudos prosopográficos,
dando ênfase aos erros nas classificações dos conteúdos.

Classificações significativas são essenciais para o sucesso

de qualquer pesquisa, mas infelizmente para o
historiador cada indivíduo desempenha muitos papéis,
alguns dos quais estão em conflito com outros. 38

No entanto, o problema não estava na natureza dos agentes

históricos, mas na mão dos historiadores:

...se uma subdivisão que depois se revela de importância

crítica não for notada a tempo, usualmente é tarde
demais para voltar e realizar todo o trabalho de novo -
uma dificuldade que é particularmente aguda em
pesquisas auxiliadas por computadores, pois os códigos
determinam as questões que podem ser depois
formuladas.39

Com isso, tornamos ao problema apresentado por Daumard,

alguns anos antes. Preciso de uma boa classificação para
conhecer o passado e devo conhecer o passado para ter uma
boa classificação. No entanto, o conhecimento prévio do

38
Ibid.
39
Ibid.
 44

passado pode comprometer os resultados da investigação, uma

vez que aplico aos dados o pré-conceito que já tinha, sem
atentar para elementos novos surgidos no andar da pesquisa.
Para isso, há necessidade de repensar as classificações todo o
tempo e este problema pode ser complexo, como pensava
Daumard, ou ser uma escolha estúpida, como parece prever
Stone, que já propõe fazer tudo novamente. A classificação não
apenas é uma pré-explicação, como ela também limita as
perguntas possíveis para os dados processados. Neste sentido, o
dano causado pelo processamento veloz dos computadores
pode alertar o historiador para a importância de pensar sobre
suas classificações.

Por fim, parece interessante notar como Stone, já naquela

época, identificava uma postura que parece ter sido hegemônica
entre os historiadores nos últimos 40 anos, ao tratar do advento
do computador na pesquisa em história:

...seria adotar a postura do avestruz fingir que isso não

está acontecendo agora e que não acontecerá em uma
escala ainda maior nos anos vindouros40

E os anos vindouros prometiam muito.

O primeiro Manual de Computação para historiadores

Em 1971, o historiador Edward Shorter lançava The historian and

the Computer. A practical guide.41 Era a primeira vez que surgia
um manual voltado diretamente para o público da disciplina.
Seu foco principal era ensinar os historiadores interessados em

40
Ibid.
41
SHORTER, Edward, The historian and the Computer. A practical guide, New
Jersey: Prentice-Hall, 1971.
 45

estudos quantitativos como preparar sua pesquisa para um bom

processamento com o uso de cartões perfurados. A tarefa era
fácil: aprender a usar um IBM 360 seria tão simples quanto
entender o funcionamento do motor de um automóvel! Após
algumas páginas sem conseguir explicar o funcionamento do
computador, mas decifrando os assustadores nomes das partes
que o compunham, ele enfim nos fala que não é fundamental
entender o funcionamento completo da máquina: bastava o
mínimo para perder o medo.

Shorter foi audaz e pioneiro, mas criou um livro absolutamente

datado. Apesar de ter servido por aproximadamente dez anos,
sua obra ficou muito presa à tecnologia disponível nos anos
1960 e 70, como os lendários softwares Fortran e Cobol (que
ainda são usados hoje, mas não por historiadores). Porém, não
podemos compreender Shorter como alguém fora de seu
tempo. Todo o contrário. No mesmo ano em que era lançado
The historian and the computer, surgia a revista Computers and
medieval data processing, uma publicação canadense voltada
para a “informatização” dos estudos sobre Idade Média. A
publicação não trazia artigos, mas notícias sobre publicações,
projetos e outras informações interessantes para o medievalista
moderno.

Ao longo de sua existência (durou entre 1971 e 1987),

Computers trazia em cada edição uma lista dos projetos sobre
história medieval que lançavam mão da informática. Ao todo,
foram mencionados 354 projetos, a grande maioria nos Estados
Unidos, seguidos de Canadá e França. Era um público que
compreendia muito bem as palavras de Shorter: os
equipamentos mais utilizados foram, de longe, os IBM 360 e
370, rodando, na maioria dos casos, o Fortran IV, além de outros
 46

como PL/1 e Snobol.42 O foco temático de Shorter, contudo, era

um tanto distante daqueles projetos da Computers and medieval
data processing. A maior parte daquelas empreitadas visava o
processamento de textos e sua lematização automática. Shorter
estava dirigido para os estudos quantitativos, dentro do mesmo
contexto que trazia os computadores como ferramentas
incontornáveis.

Por outro lado, seu objetivo central é “domesticar” aquilo que

considerava o aparente mistério das máquinas. Buscando a
vulgarização e a ruptura com a postura do avestruz, Shorter
ficou mais próximo do “entusiasmo indiscriminado dos
ninfomaníacos”, como dizia Stone.

Uma grande mudança ocorreu ao longo dos anos 1970 que dizia
respeito à própria profissão do historiador. É a passagem de um
tipo de história que buscava a homogeneidade (de casos, de
fontes) para uma história com maior preocupação com a
diversidade e a heterogeneidade (basta lembrar a coleção “Faire
l'Histoire”, organizada por Le Goff e Nora em meados da década
de 1970, em busca de novos objetos, novos problemas e novas
abordagens). Essa mudança também é perceptível na relação
dos historiadores com o computador. Cada vez mais as
ferramentas são buscadas para permitir o tratamento cuidadoso
das especificidades encontradas. A técnica agora deve ser feita
de acordo com essa demanda. Os trabalhos de Macfarlane,
43
Thaller e Dedieu serão sintomáticos dessa tendência.

42
UNIVERSITÉ DE MONTRÉAL INSTITUT D’ÉTUDES MÉDIÉVALES, Computers
and Medieval Data Processing: Informatique Et Etudes Medievales, [s.l.]:
Université de Montreal, Institut d’études medievales., 1971.
43
Le Goff & Nora. História: novos problemas. São Paulo: Livraria Francisco
Alves Editora, 1978
 47

“Reconstructing historical Communities”: um projeto pioneiro

Em 1979, Alan Marcfarlane publicava, em colaboração com

Charles Jardine, um breve texto no 7º Congresso Internacional
de História Econômica.44 Apesar de breve, o texto continha a
essência das reflexões iniciadas em 1972, quando se iniciara a
aventura de Macfarlane e Sarah Harrison na tentativa de
informatizar fontes para o estudo de história local na Inglaterra.
45
O resultado da pesquisa tornou-se livro um pouco antes, com
o nome de Reconstructing historical Communities.46 Destaco isso
tudo, pois me parece que esta comunicação trazia elementos
realmente inovadores para aquele momento e que são
questões-chave ainda hoje.

Jardine e Macfarlane pareciam extremamente insatisfeitos com

o que a tecnologia oferecia naquele momento. Os programas
não se adequavam às necessidades de pesquisa do grupo e por
várias razões. A primeira era conceitual: os programas de
gerenciamento de bancos de dados disponíveis na época eram
problem-oriented (orientados a partir de um problema, algo que
também se pode chamar de method-oriented, orientado pelo
método) e não pela fonte. A programação dava conta de tarefas
a cumprir e não havia condições para, por exemplo, aplicar as
proposições metodológicas de Louis Henry e Wrigley no que diz
respeito, respectivamente, ao chamado método de
reconstituição de famílias e aos Record-linkage methods. Isso se

44
MACFARLANE, Alan, Computer input of Historical Records for multi-source
record linkage, in: Proceedings of the Seventh International Economic History
Conference, Edinburgh: [s.n.], 1979.
45
MACFARLANE, Alan, The computer revolution and local history.
46
MACFARLANE, Alan, Reconstructing historical Communities, Cambridge:
Cambridge University Press, 1977.
 48

dava pelo fato de que estes métodos empregavam o uso de

qualidades diferentes de dados, a partir de fontes, de modo
relacional.

Para ilustrar o tamanho do problema, ele apresentou um

exemplo usando o longevo pacote SPSS (ainda hoje hegemônico
nas Ciências Sociais). Seu argumento era de que o programa era
adequado para os surveys criados pelos sociólogos, mas
identificou seu limite: se ele dispunha de uma tabela com dados
sobre a educação infantil e de outra com as informações sobre
as famílias e quisesse cruzar os registros, não seria possível por
conta do modelo conceitual próprio do pacote. Além disso, os
pacotes da época, incluindo SPSS, não dispunham de elementos
para incluir documentos inteiros, o que forçava a perda de dados
involuntária, sem falar na incapacidade dos aplicativos em
processar conteúdos incertos, imprecisos ou confusos (fuzzy
data).

É na constatação dos limites do que era praticado na época por

seus colegas que Macfarlane vai explorar dois caminhos até
então desconhecidos pelos historiadores (e diria, também, pelos
programadores). O primeiro e mais importante elemento é a
adoção de um modelo de dados sourced-oriented (orientado
pela fonte). Ao invés de extrair dos documentos os dados
necessários para “cumprir” as exigências do programa em
campos possíveis, a fonte seria colocada integralmente dentro
do programa sem cortes. Isso seria possível graças à pré-edição
dos textos, já que não haveria utilidade em simplesmente ter os
textos integrais no computador. Seria importante contá-los,
cruzá-los e aplicar outras metodologias de acordo com a
necessidade. Deste modo, se um registro de batismo dizia que
John, filho de Henry Abbott, foi batizado em 5 de maio de 1607,
 49

o documento seria assim transcrito para o entendimento da

máquina da seguinte maneira:

(P (N John) (K the son of (P (N Henry Abbott))) (E was baptized.

(D 5th May 1607)))

[explicação: P = person (pessoa); N = name (nome); K = kinship

(parentesco, indicando o tipo em “linguagem natural”, no caso, o
inglês); E = event (evento); D = date (data)).

Com o uso destes códigos e parênteses, um historiador

explicaria à máquina o significado de cada coisa: datas, nomes,
relacionamentos, etc. Demandava algo importante e válido
debatido até os dias de hoje: a normatização de nomes e a
atualização da língua. No caso, inclusive textos em latim foram
traduzidos para tornar o cálculo possível. O uso do recurso de
pré-edição foi adotado, pouco tempo depois, no
desenvolvimento do kleio, por Manfred Thaller, sobre o qual
falaremos mais adiante.47 Recentemente esta prática tornou-se
modelo nas linguagens da internet, com a chamada web
semântica, onde as palavras em um site não são mais
amontoados de letras organizados pelo formato (texto grande
ou pequeno, com negrito ou em itálico, etc). É semelhante ao
que se utiliza com a linguagem XML, para dar um exemplo
disponível na internet.

Além da programação orientada pela fonte histórica estruturada

47
ROWLAND, Robert, L`informatica e il mestiere dello storico, Quaderni Storici,
v. 78, n. 03, p. 693 – 720, 1991.
 50

de modo legível pelo computador, Macfarlane e Jardine foram

pioneiros no uso de uma tecnologia ainda muito pouco
conhecida na época: o modelo relacional de dados, hoje
hegemônico a ponto de ser tomado quase como norma. Na
época, utilizaram um manual sobre databases feito por C. J.
Date, famoso não apenas pela didática na explicação dos
recursos técnicos, mas igualmente por ter pertencido ao grupo
que criou, dentro da IBM, a linguagem SQL. O uso desta
tecnologia tornava possível cruzar dados de diferentes tabelas,
que conteriam informações de fontes diversas, as quais
permitiriam o emprego de análises como as de Henry e Wrigley.

Manfred Thaller e o kleio

No final dos anos 1970, a equipe de Manfred Thaller, no Max

Plank Institute, começou a desenvolver uma ferramenta para o
processamento de dados em história. Chama-se kleio. Os
primeiros resultados só começaram a surgir em meados da
década seguinte. O kleio era um programa feito sob medida para
a pesquisa histórica e orientado pela fonte: implicava na
transcrição controlada da fonte para uma linguagem
compreensível pelo computador, atribuindo códigos
pré-definidos ao texto. Em boa medida, ele seguia de perto as
formulações de Macfarlane e há quem associe as duas
iniciativas.48

O sistema de Thaller, influenciado ou não por Macfarlane, previa

a criação de um programa que poderia ser instalado em outras
máquinas, coisa que não fora considerada em Cambridge. Com o
tempo, o kleio passou de uma linguagem que tratava dados de

48
Ibid.
 51

fontes para uma historical Workstation, na qual qualquer

historiador, sem grande conhecimento de informática, poderia
trabalhar sem dependência de um programador, o que geraria
uma grande economia de tempo na pesquisa. A ferramenta
dispunha de conexões com outros sistemas de análise, como o
SPSS. Neste sentido, kleio sempre foi um organizador de
informação, próximo de uma base de dados de historiador, mais
do que um software completo.

O trabalho de abastecimento era feito seguindo a ordem da

fonte e não segundo demandas de formulários pré-definidos.
Neste sentido, havia igualmente uma economia de trabalho no
preenchimento das fontes. O grande mérito de kleio era
exatamente o fato de ser orientado pela fonte, a ponto de não
interferir, ou de interferir muito pouco, na estrutura original da
fonte. Segundo Thaller:

Dados são administrados na forma de coleções de

pedaços de texto, sem qualquer suposição sobre seu
significado. Todas as suposições (o status social derivado
de uma dada ocupação; o significado cronológico da data
apontada para dias diferentes no calendário de várias
dioceses; a taxa de câmbio de duas moedas diferentes)
são geridos em tabelas completamente independentes
dos dados originais.49

Kleio foi um dos primeiros programas (e talvez um dos únicos) a

criar sistema de identificação de dados incertos e imprecisos
(fuzzy). Fora desenvolvida uma codificação especial para indicar
incertezas e imprecisões, o que dava uma grande vantagem
comparativa entre este programa e os softwares comerciais da

49
THALLER, Methods and techniques of historical computation.
 52

época, contra os quais Thaller se manifestava preocupado,

precisamente pela falta deste tipo de recurso.50 Neste sentido,
novamente há uma proximidade com Macfarlane.

O sistema Fichoz

Em um artigo de 2004, Jean Pierre Dedieu apresentava um

banco de dados que já tinha alguns anos de existência: o sistema
Fichoz.51 Trata-se de uma base centrada no método na qual há
uma metodologia de trabalho prévia ao tratamento dos dados. A
ideia principal é a de que é possível decompor a vida dos
agentes históricos em “eventos”. Neste sentido, para cada ato
seria criado um registro com informações como a data, o local, a
interação com outro agente e um campo de detalhamento. A
interação e a análise detalhada de cada ato são os pontos fortes
desta forma de coletar e organizar os dados. Deste modo, seriam
possíveis buscas por indivíduos (biografias), por grupos de
indivíduos (prosopografias), por pessoas conectadas com outras
por algum motivo (análise de redes sociais) e por séries, de
acordo com a necessidade. Isto seria possível, pois cada registro
colocaria dois ou mais agentes históricos em relação uns com os
outros:

A nova concepção do trabalho em história social nos dá a

solução. É preciso tratar cada dado como um evento
dentro da vida de um ator. A documentação deve ser lida
como um conjunto de sequencias que descrevem as
ações efetuadas ou sofridas por um ator individual. Cada
50
THOMAS, William, Computing and the Historical Imagination, in:
SCHREIBMAN, Susan; SIEMENS, Ray; UNSWORTH, John (Orgs.), A Companion
to Digital Humanities, Oxford: Blackwell, 2004.
51
DEDIEU, Jean Pierre, Les grandes bases de données: une nouvelle approche
de l’histoire sociale. Le système Fichoz, Revista da Faculdade de Letras-
História, v. 05, 2004.
 53

uma destas ações deve corresponder a um registro

dentro da base de dados contendo todos os elementos
necessários a sua interpretação: natureza e descrição da
ação, identificação do ator, data, referência, elementos
de contexto, etc. A conversão dos documentos em atos é
da responsabilidade do pesquisador que o faz a partir de
sua margem de interpretação.52

O traço marcante deste sistema é sua versatilidade. As buscas e

os cruzamentos de informação seriam feitas no mesmo
formulário criado para o abastecimento, permitindo escolher
muitos campos simultaneamente, inclusive de tabelas
relacionadas. Isso era relativamente fácil graças ao software
utilizado, o Filemaker. Porém, o grande mérito da base está na
sua estrutura: ela é ao mesmo tempo robusta e versátil, ao
utilizar poucos campos e tirar proveito da possibilidade,
ilimitada, em qualquer sistema, de criar registros. E como cada
ato seria um registro, bastaria gerar tantos registros quantos
fossem necessários para desmontar um processo histórico,
reagrupando o mesmo por pessoas, datas, localidades ou
metodologias. Esta estrutura permitiria receber dados de
qualquer tipo de fonte:

Tal esquema se prova extraordinariamente robusto e

permite de cobrir o conjunto dos casos possíveis,
qualquer que seja a fonte – crônica, arquivos
administrativos ou judiciários, correspondências, atos
notariais, registros paroquiais, literatura de segunda mão
ou outro. Isso permite claramente uma contagem
extremamente veloz dos instrumentos públicos –
registros paroquiais, estado civil, atos notariais – que são
em última análise instrumentos para criar relações
interindividuais. E posiciona de maneira imediata o

52
Ibid.(Tradução nossa. O original está em francês).
 54

assunto dentro do contexto da carreira de cada um dos

atores.53

A base Fichoz ainda é utilizada por um grupo de pesquisadores e

para diversas pesquisas.

* * *

A proposta neste capítulo não foi a de esgotar as iniciativas de

uso de bancos de dados na produção do conhecimento histórico,
assunto para o qual seria necessária uma enciclopédia. Mas
vimos, com a ajuda de algumas experiências pontuais, alguns
temas relevantes que serão retomados ao longo das próximas
páginas. E mais importante, vimos que o uso do computador em
história tem uma longa data e que não há motivo para
reinventar a roda.

A época de ouro das bases de dados na pesquisa em história foi

a década de 1980, quando houve um amplo debate sobre o
assunto, além de conferências e publicações voltadas para o
tema. Isso durou até o início dos anos 1990. Depois da
disseminação da internet e da época áurea da multimídia em CD
e DVD, o assunto acabou assumindo um lugar secundário, talvez
em razão da disseminação dos programas enlatados.

53
Ibid.
 55

Algumas questões próprias da informática

Sobre granularidade

Muitos pratos podem ser feitos com ovos. O mais simples é o

ovo cozido: mergulhe o ovo em uma panela com água fervente e
espere alguns minutos. Uma omelete é feita com os ovos
batidos colocados na frigideira e temperados a gosto. Em ambas
as receitas, não foi necessário, e seria inapropriado, separar as
partes visíveis do ovo: a clara e a gema. Em muitas receitas,
porém, é essencial separá-los. Um delicioso tiramisu, por
exemplo, precisa das duas partes, mas em diferentes estágios de
seu preparo. No caso do tiramisu, separamos a gema das claras
para um posterior reencontro. Em muitas outras receitas,
usamos apenas a gema ou somente a clara. Na cozinha, a gema
e a clara são as menores partes possíveis de um ovo. É
interessante usar este exemplo para falar sobre algo
fundamental para bancos de dados: granularidade. Cada projeto
de pesquisa, como cada receita, exigirá que quebremos as
informações ou ingredientes em pedaços, às vezes nas menores
partes. Em uma cozinha, não é possível separar a gema em
pedaços identificáveis. Para um biólogo ou físico, é possível
separá-los ainda mais, mas isso é outra história. Como
Harrington observou, no contexto de um projeto de dados,
“Granularidade é o nível de detalhe no qual os dados são
54
armazenados em um banco de dados”.

54
Harrington, Jan L. Relational Database Design and Implementation.
Morgan Kaufmann, 2016
 56

Como os dados estão em um ponto muito baixo de

granularidade, eles podem ser categorizados e
quantificados de muitas maneiras. Do ponto de vista
analógico, os dados em um estado normalizado são
semelhantes aos grãos de silício. Os grãos crus de silício
podem ser recombinados e remanufaturados em muitas
formas diferentes, como vidro, chips de computador e
implantes corporais. Da mesma forma, os dados
normalizados podem ser retrabalhados em muitas
formas diferentes de análise.55

O leitor atento vai se lembrar que, no capítulo anterior, falamos

sobre como desmontar as coisas de forma organizada. Bem,
desmontar coisas, no vocabulário de um banco de dados, é
granulá-las. Para realizar estudos históricos de forma coerente,
levando em consideração as características das fontes, é
essencial granular os dados e atribuir a cada partícula um
significado distinto. Isso significa dividir as informações em
pequenos pedaços, separando o nome e o sobrenome - ao invés
do nome completo: “nome = Camile”, “sobrenome = Espanaye”,
- e desagregando o nome e o número da rua - “rua = Morgue”, “
número da rua = 41 ”. Nesse caso, nome, sobrenome, rua e
número da rua são coisas às quais podemos atribuir significado
ao classificá-los. De acordo com o sistema de banco de dados
com o qual você está trabalhando, essas classificações são
expressas de maneiras diferentes. Em bancos de dados
relacionais, criamos campos para separar dados: um campo para
nomes, outro para sobrenomes e assim por diante. Em bancos
de dados orientados a documentos, usamos “etiquetas” (ou
“tags”) para identificar nomes e sobrenomes. A granulação é

55
INMON, W. H.; LINSTEDT, Daniel. Data Architecture: A Primer for the Data
Scientist: Big Data, Data Warehouse and Data Vault. Elsevier. 2015.
 57

expressa no número de campos ou tags que usamos para

manter os dados organizados.

Figura 5 - Descrição do conceito de granularidade

Com base nessa granulação, podemos pesquisar todas as

pessoas com o mesmo sobrenome ou todas as pessoas que
moram em uma determinada rua. Se mantivéssemos todas as
partes juntas, seria difícil fazer buscas, pois nomes e
sobrenomes de pessoas poderiam ser confundidos com nomes
de ruas, tornando nossa busca de pouca utilidade. No entanto,
embora essa granulação seja importante, também é
 58

fundamental que a maneira como separamos, organizamos e

marcamos nossos dados permita uma fácil reorganização como
um conjunto completo. Esta recuperação permite-nos perceber
que Camile L’Espanaye vive na Rue Morgue, como vimos no
exemplo da imagem acima.

Existem diferentes tipos de sistemas de banco de dados, mas

essa lógica é essencial em todos eles. As chamadas bases de
dados relacionais podem ser desenvolvidas, criando diferentes
tabelas e associando-as de modo organizado, a partir de certos
elementos tidos em comum, como um nome ou, melhor ainda,
um campo de identificação (campo “id”). O campo "id"
identificará inequivocamente a pessoa que leva esse nome e não
outra pessoa com o mesmo nome. Em um banco de dados
relacional, o caso Camile l'Espanaye seria inserido em uma
tabela denominada "personagens", com os campos “id”,
“nome”, “sobrenome”, “nome da rua” e “número da rua”, entre
outros. O “id” único seria a só maneira de associar “Espanaye” e
“Morgue” facilmente. Em bancos de dados não relacionais, em
vez de criar uma tabela, você precisaria criar tags para classificar
as partículas e atribuir um significado específico a elas.

Tomemos, por exemplo, um registro de casamento criado no

século XIX. Normalmente, esperamos ver os mesmos dados
básicos, como os nomes dos noivos, em todos os registros.
Graças à natureza padronizada de nossa fonte, é improvável que
sejamos confrontados com dados inesperados (e, se formos, isso
seria uma descoberta única) e, portanto, podemos criar dois
campos: "noiva" e "noivo". Nesse sentido, alguns dados são
únicos: esperamos um noivo e uma noiva. No entanto, o número
de testemunhas do casamento é imprevisível. Normalmente,
existem dois, mas quatro não seria nada descomunal. Como
 59

podemos lidar com esses dados imprevisíveis? Encontramos o

mesmo problema ao criar uma tabela para analisar as biografias
de um indivíduo. Temos apenas uma data de batismo e apenas
uma mãe biológica e, portanto, esses dados são fáceis de
manusear. No entanto, como lidamos com os dados que temos
sobre as diferentes ocupações que um sujeito teve ao longo de
sua vida? Se ele tivesse apenas um emprego, sem problemas,
mas e se tivermos casos de pessoas que exerceram oito
profissões diferentes, algumas simultaneamente?

Quando se fala de questões técnicas, os historiadores costumam

correr para as montanhas. É difícil saber os motivos da longeva
aversão de nossos colegas ao universo da informática. Alguns
apresentam justificativas epistemológicas, outros optam por
expor seu desprezo pela técnica (a respeito do que já discutimos
antes) e muitos se consideram incapazes de aprender. Mas
acredito que, quem aprendeu a usar um aparelho celular ou o
e-mail, poderá facilmente aprender alguns dos elementos
básicos que caracterizam as bases de dados.

Veremos que não é tão complicado. O problema é grande dada a

falta de didática ou de paciência dos programadores.
Tentaremos ser didáticos aqui. Tudo é bastante lógico. Se formos
capazes de discutir sobre as representações do poder no Antigo
Regime, seremos capazes de aprender alguns procedimentos da
informática.

Existem dezenas de softwares de bancos de dados comerciais

disponíveis e escolher um para demonstrar o raciocínio por trás
da construção de um banco de dados de pesquisa histórica seria
quase contraproducente. O software de banco de dados
escolhido pode ser descontinuado em alguns anos. No entanto,
o segundo, e mais significativo motivo pelo qual não vamos nos
 60

concentrar em um único programa, é que nosso foco deve estar

na organização da pesquisa histórica de forma lógica e não no
aprendizado de uma ferramenta. A capacidade de organizar
dados históricos permitirá ao pesquisador criar um banco de
dados em qualquer software que escolher com muito mais
precisão do que apenas aceitar regras e padrões do programa.

Existem vários tipos de bancos de dados. Os mais comuns são os

relacionais, também conhecidos como “SQL” (linguagem de
consulta estruturada). Mas também existem modelos key-value,
graph, modelos orientados a documentos, hierárquicos e de
rede. As bases de dados relacionais são as mais difundidas,
como vem acontecendo há décadas. A predominância de bancos
de dados relacionais não os torna necessariamente melhores,
56
apenas mais populares. Recentemente, essa hegemonia foi
desafiada por outros tipos, e mesmo os softwares mais comuns
já são multimodais, ou seja, utilizam mais de um tipo de modelo.
Diferentes necessidades de pesquisa requerem diferentes
modelos e é aconselhável conhecer, pelo menos
superficialmente, as principais diferenças, pois esse
conhecimento acaba sendo valioso para o desenvolvimento de
bancos de dados complexos para a pesquisa em história.

Tabelas simples
Começaremos com o modelo mais básico: as tabelas simples.
São tabelas que organizam os dados em linhas e colunas, como
em uma planilha, onde as linhas geralmente indicam os registros

56
Bruchez, Rudi. Les bases de données NoSQL et le BigData: Comprendre et
mettre en oeuvre. Editions Eyrolles, 2015.
 61

e as colunas os campos. A forma como os dados são organizados

e pesquisados depende do software, mas a maioria deles
classifica e filtra os dados por colunas. Organizar os dados de
forma lógica permite a recuperação das informações de uma
forma muito eficiente e complexa, mesmo neste tipo de arquivo
simples. Um exemplo desse tipo de arquivo é o modelo CSV
(valores separados por vírgula). São modelos em que os nomes
dos campos são definidos na primeira linha (cabeçalho) dos
dados e são separados por vírgulas. Da segunda linha em diante,
já temos os registros, separados por vírgulas, na ordem
correspondente à linha de abertura. Observe o exemplo abaixo:

Figura 6 - Exemplo de arquivo CSV

Esses sistemas de armazenamento de dados também podem

funcionar com ponto-e-vírgula ou outro tipo de marca. No
entanto, é obrigatório usar sempre o mesmo separador
escolhido, de forma consistente e regular em todo o arquivo.
Também é comum usar aspas para longos textos
(frequentemente os textos são chamados de "strings" pelos
programas) para indicar quando o trecho de texto começa e
termina. Dados numéricos são mais simples, desde que não
usem vírgula como separador decimal, caso seja a vírgula o
 62

separador de campos. Se for assim, também precisarão de

aspas.

Modelos Hierárquicos

O modelo hierárquico é bem mais complexo do que arquivos

simples. Ele pressupõe diferentes camadas de informações e
uma hierarquia entre elas. Certos dados podem ter subpartes,
como “pais” ter “filhos” e os “filhos”, “netos”. Por exemplo, uma
coleção de documentos em uma Biblioteca (um “pai”) pode
conter muitos documentos (“filhos”), que não terão outro “pai”
(ou seja, este documento não faz parte de outra coleção). Este
documento, por sua vez, pode conter várias subpartes (“netos”).
Digamos que nosso caso seja um livro contendo várias cartas.
Cada carta seria então uma “filha” daquele documento original,
assim como no modelo abaixo:

Figura 7 - Exemplo de modelo Hierárquico

 63

Além de documentos em uma coleção de um Arquivo, há muitas

variedades de dados que podem ser classificados: meses em um
ano, dias em uma semana ou cadeias de decisão em sistemas
políticos ou de negócios, além de muitas outras possibilidades, o
que ilustra a ampla capacidade deste tipo de modelo. Apesar de
ser um dos primeiros modelos de banco de dados, os sistemas
hierárquicos perderam espaço com o surgimento dos modelos
relacionais, mas ainda têm utilidade para pesquisas históricas.
Eles são visíveis nos arquivos xml, por exemplo, uma vez que
certas informações podem ser aninhadas em outras ou
classificadas.

Bancos de dados Gráficos

Os bancos de dados gráficos (Graph Databases) são construídos
a partir de redes de informações. Os dados são representados
por nódulos conectados por laços. Os nódulos representam as
informações e os laços são as linhas que representam os
vínculos entre essas informações. Tanto os nódulos quanto os
laços podem ser marcados com informações adicionais. Nenhum
campo é obrigatório para novas informações: eles podem ser
anexados aos dados anteriores, conforme necessário, com o uso
de etiquetas, que podem também adotar a forma de nódulos.
Os modelos gráficos são muito interessantes para a pesquisa
histórica porque, ao contrário dos modelos tradicionais,
hierárquicos (exceção para XML), relacionais (como veremos) e
tabelas simples, eles são extremamente flexíveis e permitem a
inclusão de informações inesperadas. Os nódulos e laços
permitem igualmente a agregação e quantificação de dados.
Para a pesquisa histórica, quando o mesmo ator histórico pode
ter múltiplas identidades ou profissões, por exemplo, esse
 64

recurso é extraordinário e o sistema de etiquetas pode permitir

que os historiadores capturem essa complexidade de uma forma
que os modelos hierárquicos simplesmente não conseguem.

Figura 8 - Modelo de Graph Database

Os bancos de dados gráficos são classificados como “sem

esquema” (schemaless), pois não se baseiam em campos
previamente definidos, mas em “etiquetas” (tags) que podem
ser criadas e utilizadas a qualquer momento. No entanto, essa
enorme versatilidade pode causar problemas, principalmente na
integração de bancos de dados de gráficos com outras bases já
prontos. Isso pode ser um problema quando temos tabelas em
formatos diferentes com dados relacionados de outras fontes,
especialmente se as outras bases de dados são feitas por colegas
ou compartilhadas por centros de pesquisa. A multiplicidade de
etiquetas pode tornar-se complicada e dificultar a integração de
 65

qualquer sistema. Além disso, duas etiquetas diferentes podem

acabar sendo utilizadas para o mesmo processo ou objeto. No
entanto, alguns programas específicos já possuem soluções para
esses problemas de consistência, evitando duas tags diferentes
para a mesma coisa.

Key-value

Os bancos de dados de Key-Value (Chave-valor ou categoria e

conteúdo) são caracterizados por etiquetas associadas a
informações organizadas em pares de rótulos e dados. Cada
informação é rotulada por categoria. Dessa forma, não há
necessidade de campos específicos (como ocorre em tabelas
simples e bancos de dados relacionais) e uma categoria (ou
“chave”) é atribuída a uma informação específica. Muitas fontes
e problemas de pesquisa na história podem se beneficiar deste
modelo, pois diversas fontes históricas são caracterizadas pela
possibilidade de informações inesperadas.

Veja o exemplo dos anúncios de jornal. Eles podem ter

informações padrão, como o tamanho do anúncio (isso
geralmente é muito importante), a posição do anúncio na
página, o número da página e a quantidade de caracteres no
anúncio. No entanto, existem várias outras informações que são
difíceis de categorizar. Por exemplo, um anúncio pode incluir
uma dose de humor ou ironia, enquanto a grande maioria, não.
Devemos criar um campo exclusivamente para isso? Certamente
que não. Uma tabela que permita todas as idiossincrasias
encontradas em anúncios de jornal seria estranha e inutilizável.
Nesse caso, a possibilidade de inserir certas informações
(quando for o caso) torna o sistema key-value muito prático.
 66

Além disso, ele guarda certa proximidade com o conceito de

tabela, o que permite, em certa medida, a conexão com outras
bases, como as relacionais.

pessoa-Pedro012: nome = “Pedro Páramo”;

pessoa-Pedro012: matricula = “D0235”;
pessoa-Pedro012: idade= “18”

O fato de os sistemas de key-value serem flexíveis o suficiente

para permitir que uma grande variedade de informações sejam
granuladas em pequenos pedaços pesquisáveis e quantificáveis
faz deste um modelo extremamente versátil. Há um problema,
entretanto, para todos os sistemas que usam campos ou
etiquetas ad hoc para informações inesperadas: é necessário
saber quais etiquetas foram usadas para classificar as
informações. Quando uma etiqueta é usada em apenas alguns
casos, isso pode praticamente ocultá-los do sistema. Este
também é um problema para modelos de gráficos e sistemas
orientados a documentos (que veremos em seguida). Os
modelos relacionais, embora mais rígidos, permitem maior
clareza quanto ao material disponível.

Document-oriented
Um banco de dados orientado a documentos é um modelo
baseado em registros (ao contrário do Graph que é baseado em
nódulos e laços), mas sem campos obrigatórios (que são
necessários para modelos relacionais e tabelas simples). Em vez
 67

disso, ele usa etiquetas estruturadas, potencialmente regulares,

para rotular certos valores (textos, números, etc.) que podem
ser hierarquizados dentro de outros valores de rótulo. O
exemplo a seguir é uma descrição visual desse tipo de base:

"estudante": {

"id" : "00032",

"data_de_criacao" : "2019-12-21T11:11:11",

"data_atualizacao" : "2019-12-23T12:12:12"

},

"tipo": "Perfil_Estudante",

"pessoal": {

"Nome" : "Pedro Páramo",

"Matricula" : "D0653",

"Idade": "20"

},

Neste exemplo, podemos observar os dados “Nome”,

“Matrícula” e “Idade” como nos sistemas anteriores, mas
também é possível utilizar outras etiquetas que não
necessariamente serão utilizadas em todos os registros. Nesse
modelo, é possível pesquisar o agregado de dados regulares ou
apenas uma única nota de um registro, conforme necessário. É,
 68

portanto, um sistema muito flexível e não requer a criação

prévia de um conjunto definido de campos.

Ao contrário dos modelos Graph, os modelos orientados a

documentos permitem apenas uma etiqueta para cada valor. É
excelente para textos não padronizados, como
correspondências, e permite a recuperação de dados das
etiquetas utilizadas, tanto para pesquisa quanto para
quantificação.

Bancos de dados relacionais

Os modelos relacionais são os mais usados desde a década de
1980. Recentemente, essa hegemonia foi desafiada por outros
modelos (gráficos e valor-chave, por exemplo), à medida que um
movimento para criar software multimodal integrando formatos
diferentes cresceu nos últimos anos. Em meados da década de
2010, os bancos de dados relacionais começaram a perder sua
predominância na área. Apesar dos desafios de outros modelos,
no entanto, em virtude de sua flexibilidade, os modelos
relacionais continuam sendo uma ferramenta importante.
Considerando a proeminência dos modelos relacionais no
passado e no presente, daremos a eles um pouco mais de ênfase
em nossa discussão.

A primeira coisa que precisamos saber é a estrutura, os

elementos que compõem um banco de dados. Um banco de
dados relacional é um conjunto de TABELAS articuladas. Muitos
programadores usam a palavra "entidade" no lugarde tabelas.
Essas tabelas podem conter diferentes tipos de informações:
pessoas, casas, terras, endereços, etc. Em uma investigação
sobre motins no século XVIII, poderíamos criar uma tabela das
 69

datas dos motins, uma segunda tabela para os participantes do

motim e um terceiro para a localização deles. Criamos o banco
de dados de tal forma porque motins, pessoas e lugares são
coisas diferentes.

Como saber quando criar uma tabela? Como acabamos de ver,

as tabelas são usadas para associar coisas semelhantes com as
mesmas características, como tumultos. Criar tabelas também é
uma forma de granular dados. Um evento histórico pode ser
descrito com campos, mas as tabelas nos permitem agrupar
esses campos. Vejamos novamente o exemplo dos distúrbios:
podemos ter uma tabela para a localização dos distúrbios e
outra para inserir os endereços das pessoas que participaram
dos distúrbios. Eles eram todos vizinhos? Eles iriam se revoltar
perto de casa ou em outro lugar? É tudo uma questão de
localizações, mas de tipos diferentes. Devemos criar tabelas
diferentes? Acredito que sim, um para cada tipo de local. Essa
decisão depende dos problemas de conhecimento histórico, que
discutiremos mais tarde quando lermos sobre a montagem de
bancos de dados. Por enquanto, continuemos com nossas
tabelas.

Figura 9 - Ilustra a estrutura de um banco de dados relacional

Uma tabela é formada por campos e registros (também

 70

conhecidos como "colunas" e "linhas"). Nas colunas, indicam-se

os “campos” do banco de dados (também chamados por alguns
de “atributos”), como geralmente aparece em formulários, por
exemplo: “nome”, “endereço” e “estado civil”. As linhas
correspondem aos registros. No caso de uma tabela feita para
organizar e gerenciar uma turma escolar, figurativamente, a
tabela poderia ser composta por campos como “nome”,
“matrícula” e “idade”. Os registros seriam tantos quantos fossem
os alunos matriculados na turma.

A ideia de uma tabela evoca linhas horizontais e verticais onde

as informações são colocadas. Esta imagem está correta. No
entanto, em bancos de dados relacionais, uma "tabela" é um
conjunto de campos abstratos, com ou sem registros. Abstratos?
Sim, porque, quando criamos uma tabela, precisamos criar os
campos, mas ainda estamos em fase de desenvolvimento. Este
conjunto de campos terá seus registros oportunamente e
formará aquela tabela com as linhas horizontais e verticais que
mencionamos. Para falar especificamente do conjunto abstrato
de campos, usarei o termo "modelo de tabela", quase sempre
associado ao termo "conceitual" para reforçar que se trata de
um plano em andamento. Vejamos um exemplo:

Figura 10 - Modelo de tabela Figura 11 - Modelo de tabela (como

(conceitual) em um formulário)
 71

Figura 12 - Tabela “visual” do modelo conceitual acima disposto

Como pudemos ver, é algo bem mais simples que entender

Lévi-Strauss. Agora que já dominamos essa informação,
podemos avançar um pouco mais. Cada um dos campos (ou
atributos, é a mesma coisa) da nossa base deve ter sua própria
personalidade, ou seja, devem ser qualificados. Ele pode ser um
campo de “texto” (curto ou longo), de “número”, de “data”, de
“imagem”, de “cálculo”, entre outras possibilidades. Devo prever
que tipo de informação vai entrar ali. Cada software utiliza suas
tipologias, mas texto, número e data sempre aparecem e são os
mais importantes para nossos bancos. Além de definir que tipo
de campo será, podemos também definir o tamanho máximo
desse campo, quantas “casas” ele terá. Por exemplo, um campo
como “nome” certamente será do tipo “texto” e seria
recomendável permitir até 150 caracteres para seu
preenchimento, ainda que possamos deixar esse campo com
tamanho ilimitado. Na maior parte das vezes, essa última
decisão é inócua. Mas, para as bases de dados online, costuma
fazer a diferença ter campos “enxutos” para acelerar as buscas.

Nada impede que escolhamos um campo de “texto” ou de

“número” para colocar datas, utilizando no preenchimento o
formato AAAA-MM-DD (ano-mês-dia, 1654-02-04). No momento
de colocar os registros em ordem, tendo como critério a
cronologia, será absolutamente fácil de obter resultados, pois,
tanto para “número” quanto para “texto”, o retorno será igual,
em ordem. Se usarmos o formato DD-MM-AAAA (dia-mês-ano,
04-02-1654, ou com barras no lugar do traço), só conseguiremos
 72

ordenar pelo dia, depois, pelo mês, e, finalmente, pelo ano.

Dessa forma, não será respeitada a cronologia, mas somente o
dia do mês que corresponde ao registro, o que não costuma ser
útil na maioria das pesquisas em História, ainda que possa ser
objeto de análise (para acontecimentos com regularidade
mensal, como pagamento de aluguéis no Século XX, por
exemplo). Uma decisão dessas, mal feita, gera problemas ao
longo de todo o trabalho. Para esse último estudo, bastaria criar
outro campo chamado “dia do mês”, do tipo “cálculo”, que
capturasse do campo “data” apenas os últimos dois dígitos que
corresponderiam ao dia (1678-12-03 = “03”), desde que o dia
fosse sempre escrito com duas casas, mesmo para os primeiros
nove dias (01, 02, 03...). Caso contrário, o campo de cálculo
tomaria o traço junto (1678-12-3 = “-3”) e nossa pesquisa ficaria
novamente comprometida.

Figura 13 - Modelo de preenchimento de data, com a “captura” do dia do

mês a partir de um cálculo

Há uma diferença grande entre o que fazem os programadores e

o que querem os historiadores. Os programadores são formados
dentro de uma lógica de resolver problemas. Para os
historiadores, isso parece ótimo, pois nosso trabalho consiste
em criar problemas. Aparentemente, o casamento seria perfeito.
 73

Contudo, não é essa a rotina destas famílias/projetos de

pesquisa. As bases de dados criadas pelos programadores são
sempre method-oriented, orientadas pelo método, pelo desafio
a resolver, pelo “plano de negócios” do cliente. Enquanto isso,
os historiadores geralmente preferem trabalhar com bases
source-oriented, ou seja, aquelas cujas fontes, as evidências
empíricas, sejam o centro das atenções, de tal maneira que a
base fique o mais próximo possível da fonte, mas sem perder a
capacidade de ser automatizada. Vimos isso quando lemos
sobre os modelos de Macfarlane e Thaller.57

Esses historiadores resolveram o problema usando uma

linguagem de “pré-edição” das fontes, informando que certos
números não eram apenas números, mas datas, um amontoado
de letras era o nome de um agente histórico e outro conjunto
era o nome de uma instituição. Esse tipo de “marcação” ou
rotulação segue um princípio semelhante ao que foi adotado,
recentemente, com a chamada web semântica, com a atribuição
de tags, rótulos, aos textos, de modo a indicar o que cada coisa
é dentro do texto.

Outro problema frequente é a constante preocupação dos

programadores com o tamanho das bases e como devem ser
feitas com o mínimo de texto. Para os historiadores isso é
frustrante. Não há, contudo, um lado certo. Os programadores
foram ensinados a enxugar as bases para garantir a eficiência,
enquanto os historiadores são formados com uma preocupação
de guardar grandes quantidades de texto e seus metadados.

57
THALLER, Manfred, Can we afford to use the computer; can we afford not to
use it?, in: MILLET, Hélène (Org.), Informatique et prosopographie, [s.l.]: CNRS,
1985; MACFARLANE, Computer input of Historical Records for multi-source
record linkage; THALLER, Methods and techniques of historical computation.
 74

Gostamos de guardar tudo, mas não adianta guardar tudo fora

de ordem, pois é o mesmo que não guardar.

Bases relacionais

Alan Macfarlane destacou a insuficiência dos modelos de bases

de dados disponíveis naquele momento (como o pacote SPSS) e
chamou, pela primeira vez entre os historiadores, a atenção para
os bancos de dados relacionais.58 Segundo ele, seria o único
modo de testar os dados com duas das metodologias que ele
pretendia usar: o método de reconstituição de famílias, criado
por Louis Henry nos anos 1950, e os métodos de record linkage,
propostos por Wrigley poucos anos antes. Ele tinha razão. Para
realizar esse tipo de estudo de modo eficiente e tendo em conta
as características das fontes, é fundamental criar diferentes
tabelas e associar seus dados de modo organizado, a partir de
certos elementos em comum como, por exemplo, o nome (ou
melhor, uma matrícula que identifique univocamente a pessoa
que portava aquele nome e que talvez tenha um homônimo).

Isto se dá porque, na fonte, alguns dados são únicos. O normal

para um registro de casamento no ocidente é que haja um noivo
e uma noiva. Podemos criar o campo "noivo" e o "noiva".
Contudo, o número de testemunhas do casamento é
imprevisível. É comum que seja composto de duas pessoas,
porém, pode ter quatro. Como lidar com esses dados que são
sabidamente imprevisíveis? A mesma coisa ocorre ao elaborar
uma tabela para biografias. Temos apenas uma data de batismo,
apenas uma mãe biológica. E como lidamos quando um

58
MACFARLANE, Computer input of Historical Records for multi-source record
linkage; MACFARLANE, Reconstructing historical Communities.
 75

esportista, por exemplo, participou de muitos campeonatos?

Um RELACIONAMENTO (nunca confundir com as análises de

redes sociais) é uma ligação entre duas tabelas, como o próprio
nome já indica. Podemos, por exemplo, ter uma tabela com os
nomes dos alunos matriculados e outra com as notas que
obtiveram nas avaliações. As notas têm um formato e os alunos
têm outro. São objetos com características diferentes, mas
relacionados na ação, pois os alunos têm as notas. Se as duas
tabelas apresentarem o número de matrícula dos alunos,
podemos criar o relacionamento usando a matrícula como elo.
Desse modo, teremos as informações das notas dentro da tabela
dos alunos matriculados, inclusive, as médias.

Figura 14 - Relacionamento entre duas tabelas

A partir do conjunto de dados disponível no exemplo acima,

podemos ver que Auguste Dupin tem uma única nota 9.5,
enquanto Anna Blume tem três: 10.0, 8.5, 9.0. A média de Anna
 76

Blume é 9.166. A tabela com as notas não inclui os nomes dos

alunos. No entanto, podemos vincular o nome à sua série, pois
cada aluno tem um número de inscrição exclusivo.

Outro exemplo pode ilustrar melhor a utilidade dos

relacionamentos. Se tivermos uma lista de trabalhadores de
uma fábrica (com suas carteiras de trabalho) e uma lista de
todos os setores da empresa, que podem variar entre um e n
(não sabemos quantos departamentos a empresa pode ter),
podemos criar um relacionamento utilizando o número da
carteira de trabalho como elo. Esse relacionamento nos dirá em
quais setores cada funcionário trabalhou e poderá indicar, até
mesmo o período em que isso ocorreu. Podemos saber também
quais funcionários trabalharam em quais setores, adotando a
perspectiva oposta. Esta informação estaria disponível nos
campos "setores de emprego" e "período". Podemos criar uma
"junção" entre o campo "Nome do Setor" da tabela "Setores" e
o campo "Setores de Emprego" da tabela "Portfólio". Com isso, é
possível recuperar as informações de cada equipe de cada
departamento desta empresa ao longo do tempo. Isso seria
interessante para estudos da classe trabalhadora baseados nas
idéias de "experiência" de Edward Thompson, por exemplo, mas
pode ser empregado em um grande número de assuntos.

As relações entre as tabelas podem ser múltiplas e diversas,

considerando a complexidade de nossas questões de pesquisa.
Como vimos no exemplo das notas dos alunos, um número de
matrícula pode ter relacionamentos com vários registros na
tabela relacionada. No caso de Anna Blumes, eram três (figura
14). Essa é a virtude dos relacionamentos de banco de dados:
eles nos permitem trabalhar com objetos de pesquisa que
possuem, simultaneamente, dados para algumas características
 77

e múltiplas informações para outras características. O dado

único requer apenas um registro, enquanto que a informação
múltipla requer muitos. Uma única pessoa pode ter apenas um
nome em toda a sua vida. Enquanto isso, a mesma pessoa de
nome exclusivo pode ter muitos empregos.

Figura 15 - Relacionamento 1 para n

Vamos agora imaginar a conta bancária de alguém. Uma única

conta bancária pode receber depósitos de diferentes fontes e
enviar dinheiro para muitos outros destinos. Alguns
destinatários também podem enviar dinheiro em diferentes
momentos (devolvendo um empréstimo, por exemplo).
Portanto, quando criamos um banco de dados para organizar a
conta bancária de alguém, é possível considerar débito e crédito
como tabelas diferentes. Neste exemplo, a mesma pessoa pode
estar nas duas tabelas, às vezes enviando dinheiro e, outras
vezes, recebendo pagamentos.
 78

Figura 16 - Relacionamento 1 para n entre 3 tabelas

Se criarmos uma relação entre a tabela "débito" e a tabela

"crédito", podemos ter um número variável de registros de
"débitos" disponíveis na tabela "crédito" e vice-versa.

Figura 17 - Relacionamento entre 3 tabelas

 79

Um relacionamento permite ver, em uma tabela, dados de

outra, organizados em torno de um determinado critério. No
caso acima, como Melquíades aparece em ambas as tabelas,
temos os registros da tabela "créditos" à sua disposição em
todos os registros da tabela "débitos" em que seu nome
apareça. Ursula não aparece como saída, pois seu nome não
constava na tabela de "créditos". Existem várias relações em
termos do número de ligações possíveis entre as tabelas. Uma
única pessoa pode ter vários empregos (1 a vários ou “n”). Uma
conta bancária pode ter vários débitos e créditos das mesmas
pessoas ao longo do tempo (vários para vários ou “n” para “n”).
Essa variação é chamada de "cardinalidade" e, com base nela,
podemos classificar os bancos de dados em três categorias:

● Um para um, 1:1;

● Um para vários, 1:n (primeiro exemplo, pois um aluno pode ter
muitas notas);
● Vários para vários, n:n (segundo exemplo, porque um operário
pode trabalhar em vários departamentos e um departamento
pode ter vários empregados).

Vejamos mais um exemplo. Um livro pode ser dividido em

diferentes partes, como em capítulos, por exemplo. Vamos
imaginar um livro hipotético composto de 5 capítulos. A
cardinalidade seria 1: 5, isto é, um livro para cinco capítulos.
Agora vamos dividir os capítulos em partes, tomando os
parágrafos como uma unidade básica. Estamos granulando o
livro em partes menores. E quanto à cardinalidade de que
 80

precisamos para organizar os parágrafos de um capítulo? Esse

número é imprevisível. Nesse caso, consideramos “n” como
nossa resposta. Poderíamos dividir ainda mais, distinguindo
entre as frases de cada parágrafo e, como mostra a visualização
a seguir, as palavras de cada frase. Essa granularidade varia de
acordo com nossos objetivos de pesquisa, mas, tecnicamente,
pode ser descrita assim:

Figura 18 - Exemplo de modelo de dados com múltiplos

relacionamentos
 81

No modelo acima, a cardinalidade “1: n” (um para muitos) indica

que o livro pode ter vários capítulos (5 é apenas uma
possibilidade). Um capítulo pode ter muitos parágrafos, assim
como um parágrafo pode ter muitas linhas e as linhas, por sua
vez, um número variável de palavras. Na imagem acima,
podemos ver diferentes camadas de dados tabulares
estruturados, desde o livro inteiro até a menor parte, a palavra.
Isso é semelhante aos bancos de dados hierárquicos que já
vimos. Deste ponto de vista, é como se a tabela "livro" fosse o
pai de "capítulos", "capítulos" fosse o pai de "parágrafos",
"parágrafos" fosse o pai de "frases" e as “frases”, o pai de
"palavras".

As características de cada tabela, pensada para coisas diferentes,

são respeitadas, mas sem perder a possibilidade de cruzar os
dados. Em História, podemos respeitar as características de cada
fonte, sem perder a possibilidade de as comparar e cruzar. Ao
construir bancos de dados em História, podemos usar
relacionamentos de várias maneiras. Eles podem ser usados
para formar hierarquias entre as informações, como no exemplo
da biblioteca. Isso é bom para organizar as informações, como
no caso dos alunos e das notas, simplesmente porque estão
inseridas em tabelas diferentes.

O exemplo do livro é uma ilustração de como trabalhar com

cardinalidade. Não é uma sugestão sobre como criar um banco
de dados para organizar o conteúdo de algum livro. No entanto,
este exemplo enfatiza dois recursos essenciais da organização do
banco de dados: granularidade e codificação. Seria interessante
separar um livro apenas em capítulos? Sim, mas isso dependeria
dos requisitos e objetivos da pesquisa. Apesar disso, o leitor
provavelmente percebeu na figura 18 que os IDs usados para
 82

identificar todos os registros acabaram reunindo informações

das tabelas anteriores, das tabelas pai.

L1_C01_P01_F2_p1
Onde:

L1 = Livro

C01 = Capítulo 01

P01 = Primeiro parágrafo

F2 = Segunda frase

p1 = primeira palavra

Em português, esta visualização significa: "Primeira palavra da

segunda frase do primeiro parágrafo do capítulo 1 do livro". A
codificação é quase como um sistema de coordenadas. Com
base nisso, utilizamos qualquer tipo de filtro ou pesquisa. Na
tabela “palavras”, podemos filtrar todas as palavras de um
capítulo ou a primeira palavra do segundo parágrafo de todos os
capítulos. Granularidade e codificação explícita permitem uma
infinidade de pesquisas diferentes.Chamamos isso de
cardinalidade.

Os relacionamentos e a cardinalidade podem ser fundamentais

numa pesquisa em História porquanto é possível colocar em
diálogo tabelas com informações de natureza diferente (tipos
diferentes de fontes, por exemplo) que tenham algo em comum
(um mesmo personagem, uma mesma data, um mesmo lugar,
etc.).
 83

Modelos conceituais, lógicos e físicos

Continuamos com o vocabulário dos programadores. Vale a

pena, pois desdobra em etapas o planejamento das bases. Cada
minuto gasto com planejamento, nesse mundo da computação,
é uma economia de horas ao longo da pesquisa (ou a perda de
horas de correções e adaptações). Planejar uma base de dados é
criar modelos. Não são os mesmos modelos que criamos em
História, mas devem estar diretamente associados, como já
vimos. A modelagem dos bancos de dados é feita, então, em três
etapas: o modelo conceitual, o modelo lógico e o modelo físico.
Essa forma de organização já é antiga na informática e conta já
algumas décadas de vida.

Modelo conceitual

Tudo começa com uma folha de papel onde vamos anotar uma
“lista de desejos”. A base deve tratar de tal assunto, portanto
precisa ter informações sobre x, y e z, campos específicos para
essas informações e, talvez, algum relacionamento. Tudo isso
deve ser listado. O passo seguinte é, em outra folha de papel
(essa é uma recomendação pessoal, dá mais liberdade),
desenhar um quadrado (de bom tamanho) para cada tabela,
cujo interior contenha uma lista dos campos que formarão essa
entidade. Estamos criando um esboço do futuro banco de
dados, semelhante aos feitos por um arquiteto ou designer de
roupas. Nesse caso, nossos esboços ficarão feios, quadrados e
cheios de rabiscos, mas, eles serão importantes! Sempre que
possível, seria bom fazer esse planejamento com outros colegas.
 84

Com todo o esquema exposto diante de nossos olhos, é crucial

refletir sobre suas possibilidades e limites. É fundamental
conhecer as fontes e seus limites e, como apontam Genet e
Luzzati, ter a erudição histórica para fazê-lo. Com todo o
esquema exposto diante de nós, é o momento oportuno para
fazer alguns exercícios mentais para verificar a viabilidade do
banco de dados. A figura abaixo ilustra esse esforço sem propor
um modelo de processo criminal porque seria muito mais
complexo. É apenas uma ilustração desse estágio de
desenvolvimento do banco de dados.

Figura 19 - Ilustração da etapa conhecida como "modelo conceitual".

 85

Acusados e processos são “objetos” diferentes, com naturezas

diferentes e, consequentemente, com dados possíveis diversos.
Por isso, devem estar em tabelas diferentes, mas relacionados.
Testemunhas e juízes são seres humanos iguais aos acusados,
mas com características diferentes dentro de um processo. Por
essa razão, são separados em tabelas distintas, com campos
específicos para cada um. Não se espera o testemunho de um
juiz, assim como não se espera saber a qual tribunal pertencia o
acusado.

Modelo lógico

O passo seguinte é o modelo. Nesse momento, vamos apenas

aperfeiçoar nosso esquema. Dessa vez, vamos inserir
informações detalhadas para cada um dos campos e em cada
uma das tabelas, respeitando suas particularidades(e ainda nem
vimos nada sobre o visual que terá o formulário de
preenchimento e a tabela, que será assunto mais adiante).

Nessa fase também indicaremos quais campos serão

responsáveis por criar “relacionamentos” com outras tabelas e
qual será a cardinalidade desses relacionamentos; se um para
um, um para muitos ou muitos para muitos. Devemos tomar o
mesmo cuidado da etapa anterior, prevendo necessidades e
testando mentalmente nosso modelo com alguns casos das
nossas fontes. Vejamos novamente o exemplo da base para
estudar processos-crime, que teria agora a seguinte
configuração:
 86

Figura 20 - Exemplo de Modelo Lógico

Temos o mesmo modelo anterior, mas agora mais detalhado e

claro, apontando quais os relacionamentos estão previstos com
o uso de setas.

Modelo físico

O modelo físico representa a base de dados já montada, com

todas as tabelas, campos e relacionamentos e funcionando
dentro de um disco rígido de computador, fisicamente. É a base
pronta para usar, seguindo tudo o que foi planejado. Não há
muito que dizer em termos de informática. Mas há muito para
ser dito no que toca à História. Parece-me importante, tendo
pronto o nosso modelo físico, gastar mais algumas horas em
 87

planejamento. Importa tomar um conjunto de fontes para testar

o modelo. Não é preciso ter muitas. Eu diria que uma amostra
de 1% dos casos, se forem milhares e longos, já ajuda. Se forem
milhares e curtos, eu recomendaria testar com 3% dos casos. Se
forem centenas e longos, recomendaria 5% ou 10% se forem
curtos. Mas não tome esses valores como receitas de bolo. Esses
testes devem ajudar a deixar sua base de dados flexível na
medida certa e não para criar confusão.

Qual é a ideia? É de que, quando confrontamos nossa massa

documental com a base criada, mesmo tendo pensando muito
no assunto e conhecendo bem a documentação, esse
“encontro” certamente apontará problemas e limites da nossa
base. É certo que esses problemas podem surgir quando
estamos no final do preenchimento. Esse é um problema crônico
da pesquisa e do uso de bases de dados, segundo nos ensinou
Adeline Daumard. Mas podemos evitar alguns incômodos mais
simples, antes de começar a preencher a base de modo
sistemático. Feito esse teste, é recomendável descartar o que foi
preenchido, salvo se nenhum erro foi detectado (o que seria
muito estranho). A tarefa seguinte é criar um pequeno manual
de preenchimento e um treinamento com os abastecedores, se
forem muitos. Treinar as pessoas e só depois descobrir que a
base precisará de mudanças seria uma grande perda de tempo e
trabalho. Melhor fazer as coisas na ordem.

Dicionários de dados

O termo “dicionário de dados” é um conceito da informática

utilizado com frequência pelos programadores. Trata-se de um
“relatório”, um documento no qual a base de dados é descrita
de modo claro e sintético. Ele pode ser feito num documento de
 88

texto, numa planilha eletrônica, em outro banco de dados ou

numa folha de papel. No entanto, precisa ser útil para explicar
como a base funciona para que qualquer pessoa possa
entendê-la e deve informar quais são as tabelas que compõem a
base e quais campos compõem cada tabela, descrevendo os
seguintes itens:

● Domínio: se é um campo de texto, número, data, boleano,

etc;
● Tamanho: número de caracteres previstos;
● Descrição: nota sobre detalhes do campo, se tem algum
formato especial, variáveis prévias, etc.

O dicionário de dados deve servir como uma descrição completa

do funcionamento da base, destacando como são inseridos os
dados e como serão extraídos. Tendo em vista a produção do
conhecimento histórico, seria conveniente especificar também
detalhes sobre a origem dos dados, como cada informação é
obtida na fonte e colocada dentro dos campos ou, pelo menos,
como isso deveria ser feito. O dicionário pode ser o resultado
formal dos modelos, mas não é a mesma coisa. É uma descrição
desses modelos. Uma metabase!

Aspectos visuais sobre as bases

Uma base não precisa ser bonita, mas deve ser visualmente
clara. É recomendável que ela tenha algum equilíbrio estético,
pois vamos trabalhar muitas horas e dias com ela e isso pode
afetar nossa visão e nosso humor, o que não é pouca coisa. Não
 89

é simples discutir sobre os aspectos visuais de bases de dados

sem fazer referência a um programa específico, já que isso varia
conforme o software. Em pacotes comerciais, como Filemaker e
Microsoft Access, essas opções são bastante acessíveis e o leque
de cores, de formas, de contornos e de outros detalhes é muito
grande. A situação é diferente para quem usa bases SQL. Ou o
utilizador usa as formas normais da maioria dos programas,
geralmente muito simples, ou precisa criar um formulário em
linguagem de programação (PHP, CSS) que permite praticamente
tudo, mas com um custo de tempo e esforço enorme.

Mesmo com as dificuldades apontadas acima, atrevo-me a

apresentar algumas sugestões para quem vai criar sua base,
independentemente da plataforma escolhida. Vamos começar
com as diferentes formas de ver os dados, passando para as
cores, as formas e outros elementos.

Formas diferentes de visualizar dados

Ainda que isso varie de acordo com o programa utilizado, é

muito comum diferenciarmos tabelas, formulários e listas.
Atenção, caro leitor, para não ter dúvidas! Tabela aqui é
diferente do que usamos até agora. Não é sinônimo de
“entidade”, como aquele lugar onde guardamos conteúdos de
diferentes tipos através de campos. É a imagem comum da
tabela, uma forma de ver dados em que se usam linhas e
colunas. Eles podem ter (e geralmente têm) relação direta com
aquela outra tabela - a das entidades, mas podem NÃO ter.
Podemos criar uma tabela-visual para apresentar dados de
diferentes tabelas-entidades, usando um relacionamento. Por
 90

isso, vou usar a expressão “tabela-visual”, como usarei

formulário-visual e lista-visual, para ficar claro que estou falando
das formas de exibir os conteúdos na tela do computador (ou na
impressora) e não o conjunto completo de dados.

Figura 21– Exemplo de diferenciação entre tabelas "entidade" e

tabelas "visuais"

Na imagem acima, vemos que foram usadas três diferentes

tabelas-entidade, cada uma com seus dados, para criar uma
única tabela-visual. Porém, nem todos os dados de cada
tabela-entidade foram usados, apenas alguns. Isso mostra a
diferença entre as duas.

Se estivermos consultando uma base de dados, geralmente o

que vemos são os registros dispostos na forma de uma
tabela-visual ou de uma lista-visual. Eles podem (mas não
precisam) exibir todos os dados da tabela-entidade. Outros
podem ficar ocultos, disponíveis somente quando observarmos
a ficha de um registro. Se estivermos abastecendo uma base
com dados, temos o cenário oposto: geralmente começamos
com o formulário-visual em branco, preenchemos os campos e,
só então, poderemos ver esse registro em uma tabela-visual.
 91

Usamos esses recursos para facilitar nosso uso. Se todos os

dados aparecerem em todos os registros de uma tabela-visual, a
imagem será caótica e confusa, salvo se nosso banco tiver
pouquíssimos campos, entre dois e dez, por exemplo, e nenhum
deles for mais comprido que 50 caracteres. Se algum for maior,
ocupará muito espaço e será visualmente condenável.

Figura 22- Exemplo de formulário Figura 23- Exemplo de tabela

Assim, podemos estabelecer esta regra: na tabela-visual,

exibimos apenas os dados que permitem identificar as coisas e
separar os registros entre si. Deixamos os detalhes para os
formulários-visuais, que também são usados para o
preenchimento das fichas. Isso talvez não se aplique a
tabelas-visuais com menos de oito campos curtos. Nesse caso,
talvez seja mais fácil nem usar formulários: a tabela já exibe
tudo o que importa. Se você gosta de imprimir, lembre-se das
florestas, do lixo e das grandes corporações por trás das
poluentes fábricas de celulose que destroem rios para clarear o
papel. Se ainda assim quiser imprimir, talvez o mais inteligente
seja criar listas-visuais, que apresentam poucos campos, apenas
os essenciais para alguma finalidade. Vimos, pois, que convém
 92

elaborar tantos visuais quantos forem necessários para facilitar a

consulta dos dados. Como a tabela-visual é diferente da
tabela-entidade, poderemos ver seus dados de múltiplas
maneiras. Essa é uma das grandes vantagens do modelo
relacional.

Em alguns programas, as tabelas-visuais têm conteúdos

distribuídos de modo mais complexo, de tal maneira que
possamos ter campos à direita e à esquerda de outros, como já
esperávamos, mas também acima e abaixo de outros, como se
tivéssemos “andares” de campos. Esse recurso pode ser útil em
alguns visuais. Podemos, por exemplo, colocar os nomes dos
pais do noivo acima do campo “noivo” e os nomes dos pais da
noiva acima do campo “noiva”, em um registro que informa
casamentos. Também podemos ter um registro com três
“andares”, de tal modo que tenhamos de cima para baixo, em
um registro de batismo, a data do batismo, a data do
nascimento e o número de dias entre a primeira e a segunda,
como se fosse uma subtração matemática mesmo, apresentada
com clareza. Se você achar exagerado que as linhas de sua
tabela tenham “andares”, pode guardar essas funcionalidades
para os formulários, mas pode ser vantajoso.
 93

Figura 24- Exemplo de tabela-visual com "andares"

Cores

Prefira cores claras e agradáveis para separar os conteúdos de

sua base. Para ser mais preciso, eu usaria um tom claro de azul,
com a medida RGB 244,244,255.59 Essa cor tem algumas
qualidades: quebra o fundo branco, que pode ofuscar quem
trabalha por muitas horas, especialmente em monitores muito
iluminados, mas não é escura o suficiente para atrapalhar a
leitura. É uma cor associada à tranquilidade, ao mar, à vastidão
do céu, entre outras coisas que você não verá durante seu
trabalho na base. Testei muito com outras cores e não tive
resultados melhores.

Convém usar as cores como aliadas na criação dos visuais, tanto

formulários quanto tabelas. Se usarmos aquele azul clarinho,

59
O sistema RGB indica a mistura de R (red, vermelho), G (green, verde) e B
(blue, azul) numa ordem que vai de 0 a 255. No caso, um 244, 244, 255, indica
um azul, já que o B tem o maior valor. O fato de todos estarem com valores
bem altos indica que a cor é clara, já que o branco é 255, 255, 255 e o preto 0,
0, 0.
 94

que indiquei acima para uma tabela, devemos intercalar as

linhas das tabelas usando outra cor - eu diria o branco - para
facilitar a observação. Isso é melhor do que usar contornos que
poluem tanto quanto o excesso de campos visíveis. Da mesma
forma, nos formulários, convém usar diferentes tons de azul,
como aquele, e o mesmo branco para certos campos. Isso ajuda
a “disciplinar o olho” na tela de tal maneira que podemos
acelerar a identificação de dados e, até, encontrar coisas fora do
lugar com maior facilidade.

Como queremos usar as cores como aliadas nesse processo de

disciplinar o olho, podemos usar outras gamas,
preferencialmente se forem claras. Não convém usar amarelo;
tem efeito pior do que o branco. Recomendo usar rosa-claro,
verde-claro (RGB 244,255,244), laranja-claro e marrom-claro.
Mas é importante ter cuidado para não abusar e transformar a
base num programa infantil. Isso vai criar um efeito de confusão
e pode atrapalhar a observação dos dados. Parece mais
prudente usar as cores somente em campos muito específicos
para destacar certas informações. De resto, um fundo azul-claro,
com campos com a cor branca, usando um contorno
cinza-escuro parece uma pedida melhor. Quem quiser
experimentar, recomenda-se reflexão sobre as horas que ficará
na frente da tela. Quem não quiser, já tem aí uma sugestão bem
clara.

Formas

Há dois problemas que envolvem as formas. O primeiro diz

respeito ao tamanho da tela do computador. Poucos softwares
permitem o ajuste automático da tela e disso desdobram-se dois
outros problemas: a conveniência de ter uma tela grande para
 95

poder ver mais coisas ao mesmo tempo (o que é ótimo) e a

inconveniência causada pelo fato de os outros usuários terem
outro tamanho de tela. É difícil agradar a todos nesse quesito.
Todavia, é importante pensar no universo de monitores
disponíveis e nos formatos de tela utilizados (1280 x 800; 800 x
600; etc). Este último dado é o que mais interessa, pois é o
tamanho real em pixels que importa na maioria dos programas e
não em polegadas (como são medidos os monitores). Convém
deixar uma margem para evitar diferenças muito grandes, tal
como uma base que não pode ser vista em alguns monitores por
falta de tela.

O outro problema é a organização dos campos dentro da tela.

Aqui vale a mesma coisa dita sobre as cores: convém usar, mas
não convém abusar. É importante distribuir os campos como
quem desenha a planta de uma casa. Os moradores precisam
achar as coisas e os usuários precisam encontrar os campos que
procuram. É importante distribuir os campos por critérios claros,
temáticos, por exemplo, ou por tipo de dado. Se criamos uma
base source-oriented, baseada na fonte, então o melhor, me
parece, é tentar reproduzir o melhor possível a própria ordem
da fonte. Vejamos como ficaria isso em um formulário-visual
quase anedótico, mas igualmente válido:

Figura 25 - Exemplo de formulário baseado na ordem da fonte

 96

É certo que o texto varia e que não precisamos exagerar na

adequação do formulário à fonte, mas convém colocar os
campos na ordem das informações, pelo menos na coleta dos
dados. Para a análise, podemos criar outros visuais, feitos
segundo outros critérios.
 97

Entre a técnica e a teoria: problemas cotidianos e

decisões práticas

Não me parece prudente discutir sobre bases de dados em

História pensando no uso de softwares. Aliás, parece que essas
duas coisas têm completa relação, o que não é verdade.
Podemos fazer bases sem software algum, apenas com fichas,
inclusive bases relacionais (o trabalho será intenso, mas
possível). O que precisamos sempre é de programação, no
sentido amplo da palavra: o de fazer um programa de tarefas,
uma ordem de ações. Ademais, na hora de planejar, convém
estar atento a certos pontos que nem sempre são objetos de
reflexão. Há quem fale em “boas práticas” nas bases de dados.60
Prefiro não adotar esse vocabulário, mas vou criar uma lista de
problemas com algumas ideias de como resolvê-los, justificando,
com argumentos teóricos e técnicos, meus motivos.

Homônimos

Identificar pessoas é algo tão complexo que já foi tema de um

livro clássico: Identifying people in the past, de E. Wrigley. A obra
foca em pesquisas voltadas para o cruzamento de fontes e o uso
sistemático do nome como base do trabalho.61 Ele não foi o
único. Carlo Ginzburg disse a mesma coisa em artigo dos anos
1980 em que destacava o nome como o “fio de ariana” pelo qual

60
MANDEMAKERS, Kees; DILLON, Lisa, Best practices with large databases on
historical populations, Historical Methods, v. 37, n. 01, 2004.
61
WRIGLEY, E. A., Identifying people in the past, London: Edward Arnold,
1973.
 98

o historiador construiria seu caminho.62 Há outras metodologias

para as quais a identificação dos nomes das pessoas é
fundamental, mesmo em estudos demográficos. Análises
genealógicas, estudos de onomástica, tudo depende do bom
preenchimento desse campo.

Um espectro, contudo, ronda os investigadores do nome: o

espectro da homonímia. É relativamente comum que algumas
pessoas tenham o mesmo nome de outras. Eu, por exemplo, sei
de pelo menos quatro outros “Tiago Gil” e pelo menos outro
“Tiago Luís Gil” e não precisei gastar tempo para encontrá-los.
Como podemos saber quem é quem? Como distinguir os atos de
pessoas potencialmente diferentes que tenham o mesmo nome,
vivam na mesma época e, talvez, na mesma região? Não é tarefa
simples e a solução vai depender dos tipos de fontes que temos
e de certas características de cada sociedade. Com isso,
podemos, por exemplo, verificar elementos próprios do ciclo de
vida das pessoas: há idade para casar, para abrir negócio, para
várias coisas. Isso pode ajudar na identificação. Afora isso, há
elementos que diminuem a incerteza, como os nomes de
pessoas próximas mencionadas na fonte: pais, filhos e cônjuges;
a idade; a profissão; a região específica.

A identificação bem feita de homônimos (ou o contrário,

dizendo que duas pessoas, até então tidas como diferentes, são,
na verdade, uma única) é fruto de um artesanato e, muitas
vezes, não teremos como separar ou juntar as pessoas por falta
de informação. Para facilitar este procedimento, a melhor coisa
é criar uma tabela para “matricular” todas as pessoas que façam

62
GINZBURG, Carlo, O nome e o como: troca desigual e mercado
historiográfico, in: GINZBURG, Carlo (Org.), Micro-história e outros ensaios,
Lisboa/Rio de Janeiro: DIFEL/Bertrand Brasil, 1989.
 99

parte do meu universo de análise. Isso significa atribuir um

número para cada agente histórico que estudamos. Esse número
será sempre usado junto ao nome, em um campo separado, ao
lado, preferencialmente. Com as duas possibilidades - a de busca
pelo nome e pela matrícula - poderei checar, de tanto em tanto,
as possibilidades de juntar ou separar as pessoas, tendo em
conta suas ações e referências cruzadas. Porém, só podemos
fazer bem esse artesanato de encontrar pessoas quando
cruzamos muitas fontes diversas.

Usar apenas as matrículas vai diminuir as chances de juntarmos

os pedaços da mesma pessoa que estavam separados em razão
de algumas dúvidas que tínhamos. Usar somente o nome vai
confundir, manter todas as informações juntas e não será
possível realizar certas análises automáticas que só podemos
fazer quando já estamos convencidos da integridade dos nossos
agentes, como as análises de redes sociais. É possível
automatizar isso, mas somente depois de um longo artesanato
de preparação de dados. Com uma tabela de nomes
“matriculados”, podemos centralizar várias informações que
permitam a identificação correta das pessoas: cônjuges, pais,
filhos, data e local de nascimento, apelidos, variações
conhecidas do nome, etc.

Há, ainda, um agravante: algumas pessoas têm variações de

nome e não estou falando de Antonio com ou sem acento no
“o”. Estou pensando em possibilidades como Alencastro,
AlencastrE, LencastrO e LencastrE. Todos estão corretos e
podem fazer referência ao mesmo sujeito. É certo que podemos
normatizar, como veremos adiante, mas fontes diferentes
podem trazer variações do mesmo nome. Nesse caso, seria
importante criar, se o programa permitir, formas automáticas de
 100

tomar o primeiro nome com as últimas letras do último (o que

faria coincidir “José Lencastre” com “José Alencastre”) ou o
primeiro nome com as primeiras do último (o que faria coincidir
“José Alencastro” com “José Alencastre”). Com esse
procedimento, poderíamos minimizar um problema que já
sabemos crônico em nosso trabalho.

Esforços assim poderiam também ajudar a encontrar um sujeito

que se chama “João Pedro da Silva”, mas que costuma aparecer
na documentação apenas como “João Pedro”. Conclusão parcial:
devemos ter um sistema de controle dos nossos agentes e que
deve ser feito de modo a permitir a descoberta de homônimos.

A criação de meios eficientes de identificação depende

amplamente de um conhecimento profundo sobre a composição
de nomes em cada contexto. Estou acostumado a lidar com
pessoas que têm 3 ou 4 nomes, dois nomes próprios e dois
sobrenomes, por exemplo, mas isso não é aplicável em todos os
contextos. Conhecer essas diferenças é essencial para saber
como você cria seu banco de dados, sabendocomo enquadrar a
automação. Esforços como este também poderiam ajudar a
encontrar um sujeito denominado "João Pedro da Silva", mas
que habitualmente aparece na documentação tal como "João
Pedro".

A título de conclusão parcial, diria que devemos ter um sistema

de organização das informações sobre os nossos agentes e deve
ser feito de forma a permitir a descoberta de homónimos. O
mesmo é verdadeiro para qualquer nome de atores históricos:
empresas, navios, edifícios e muitas outras coisas.
 101

Atualizar, normatizar ou manter o original?

O melhor é normatizar os nomes e atualizar a linguagem.

Sempre. E tenho bons companheiros que comungam dessa
opinião, como o próprio Alan Macfarlane.63 Reconheço que isso
tem um custo: é preciso ter pessoas capacitadas para
transcrever, que não leiam algo diverso do que está no original e
saibam desdobrar corretamente as tradicionais abreviaturas. É
mais demorado e trabalhoso, mas, feitas a atualização e a
normatização dentro do banco de dados, o material já estará
pronto para análise e será possível submeter os dados a muitas
metodologias e perguntas com resultados rápidos. Ou seja,
depois de um longo esforço, os ganhos serão imediatos e
poderão ser utilizados por muito tempo. Gasta-se de um lado,
economiza-se de outro, sem perder o principal.

Manter os textos no original é quase como não tê-los em uma

base. É quase como ter apenas a foto do documento. Não
adianta ter dados assim. Entendo os argumentos de quem
prefere manter o original: o de que, com isso, será possível
encontrar erros de atualização e de desdobramento de
abreviações. Porém, é preciso um trabalho duplo, para o qual,
muitas vezes, não temos tempo ou recursos e transcrever, por si
só, já demanda muito tempo. Tendo em mente essa opção, a de
manter no original, vou apresentar algumas ideias que podem
automatizar o artesanato da paleografia.

A proposta começa assim: ter um campo “texto original” para

cada excerto informatizável da fonte, para cada pedaço de texto

63
MACFARLANE, Computer input of Historical Records for multi-source record
linkage.
 102

do documento original que possa virar um registro dentro de

uma tabela. Por exemplo, os livros de batismo têm páginas e
páginas de descrições daquele ritual, um atrás do outro.
Podemos ter um registro para cada batizado anotado pelo
padre. Esses serão nossos excertos informatizáveis: são pedaços,
excertos, e são informatizáveis, porquanto possam ser
desmontados em campos de um database. Este campo “texto
original” vai receber, durante a transcrição, o conteúdo tal como
está na fonte, anotado, em campos separados, de qual livro,
qual página e a ordem do excerto na página (se era o primeiro
registro de batismo, o segundo ou terceiro, etc.).

Então, teremos uma base de batismos composta apenas por

trechos inteiros de registros. O passo seguinte, e aí entra a
“astúcia”, será o de criar um campo “texto atualizado", que vai
conter os mesmos dados do “texto original”, mas de modo
atualizado. A forma mais simples (e mais trabalhosa) seria
repetir o trabalho de digitação com a atualização, mas não a
recomendo. Utilizando recursos disponíveis apenas nos
modernos bancos de dados, seria possível criar um campo de
cálculo que repetisse o conteúdo do campo, mas substituindo
valores antigos por atuais. Um cálculo que repetisse e
atualizasse ao mesmo tempo, substituindo “Joseph” por “José”,
sem que fosse necessária a intervenção humana. Ela teria
ocorrido antes, na criação de uma tabela (longa) de
substituições programadas.

Outra saída possível seria a de copiar o conteúdo do original

para o atualizado e mandar substituir, palavra por palavra, as
palavras velhas pelas atuais. Isso tem um grande risco: uma vez
cometido um erro, ele será propagado por todos os registros,
demandando um novo esforço. No caso da utilização do código,
 103

bastaria acertar o cálculo e nada se perderia. Assim, teríamos

duas versões, sem perder dados originais e com conteúdos
homogeneizados e normatizados prontos para uso. Vejamos:

Original Visão do campo com cálculo

Aos treis dias do mês de agosto do
ano de mil setessentos e secenta e
seis annos nesta paroquial igreja
de São Bento baptizei e pus os
sanctos óleos a innocente
Benedicta, filha legítima de Joseph
dos Sanctos e de Benedicta da
Conceiçam...
Aos três dias do mês de
agosto do ano de mil setecentos e
sessenta e seis anos nesta
paroquial igreja de São Bento
batizei e pus os santos óleos a
inocente Benedita, filha legítima de
José dos Santos e de
Benedita da Conceição...

Cálculo utilizado:
Substituir:
treis = três
setessentos = setecentos
Secenta = sessenta
nn = n
pti = ti
ncto = nto
ict = it
Joseph = José
Conceiçam = Conceição

Se rodássemos este comando por completo, a lista seria muito

maior, mas este é apenas um exemplo ilustrativo. Este campo de
cálculo, no entanto, requer algum aprendizado sobre comandos
que podem assustar muitas pessoas. Por isso, existem
alternativas para lidar com o texto original e padronizado. Uma
delas é permitir o acesso às imagens dos documentos (se
disponíveis). Um relacionamento entre uma tabela para as
 104

imagens e a tabela que criamos para organizar o documento

pode ser suficiente para isso. Desta forma, é possível comparar
sempre os dados da base de dados com os originais, de forma
visual e sem complicar a base de dados.

Nesse momento, quem estava convencido pela normatização e

atualização já deve estar se perguntando: não é mais vantagem
deixar no original e usar aqueles recursos? Minha resposta
continua sendo “não” e vou apresentar uma nova sugestão:
associar cada ficha, através de um campo, com o endereço
(digital, url) do arquivo de imagem (png, jpg, tif, etc) que contém
o documento original fotografado. Desse modo, será possível
cotejar sempre os dados na base com os originais, sem risco
para o trabalho e de modo auditável.

Formatos de data

A melhor opção, no meu ponto de vista, é usar o sistema

AAAA-MM-DD, 1798-07-14. Independentemente do software
que escolhermos, esse sistema vai funcionar. Se for preciso
exportar os dados para análise, o programa pode não entender
o formato 'data', mas entenderá o formato 'número' e será
possível colocar em ordem. Igualmente, será possível usar
campos de cálculo para “tomar” o dia, o mês e o ano
isoladamente - se for conveniente por alguma razão. Com o
campo do tipo 'data' é diferente, pois nem sempre dá certo.
Além disso, há o risco de confundirmos o sistema americano
com o do resto do mundo, que troca o mês pelo dia. Há certos
programas que são capazes de calcular a diferença de tempo
entre duas datas, medida em número de dias. Para isso, é
 105

necessário usar o formato de data. Assim, nossa defesa do

padrão AAAA-MM-DD estaria em xeque. Convém saber se o
mesmo programa não permite “tomar” partes desse último
formato e isolar ano, mês e dia e reuni-los no formato de data
tradicional. Se permitir, ótimo. Caso contrário, resta saber se
essa funcionalidade é necessária e se vale a pena optar por esse
ou aquele caminho. Se tudo deu errado, não se preocupe:
planilhas eletrônicas são capazes de resolver esse problema para
qualquer das opções. Basta saber usar bem os cálculos
disponíveis.

Muitos programas (como Excel, Filemaker, MySQL, entre

outros) podem calcular a diferença de tempo entre duas
datas, medida em número de dias. Para isso, é necessário
utilizar o formato de data. É útil saber se o programa
permite a "captura" de partes do AAAA-MM-DD, isolando
ano, mês e dia e reunindo-os no formato tradicional de
data.

Data = 1958-12-29

Dia = (Data, capturando os 2 últimos caracteres) = 29

Mês = (Data, capturando entre o primeiro e o segundo “-”) = 12

Ano = (Data, primeiros 4 caracteres) = 1958

NovoCampoData = (Dia + “-” + Mês + “-” + Ano) = 29-12-1958

*O traço (“-”) no campo NovoCampoData é somente para melhor

visualização.
 106

É sempre útil aprender um pouco sobre cálculos (ou funções)

em softwares de banco de dados e planilhas. Se o software
permitir, ótimo, caso contrário, resta saber se essa
funcionalidade é necessária e se vale a pena escolher esse
caminho ou outro alternativo. Se tudo deu errado, não se
preocupe: planilhas eletrônicas podem resolver esse problema
para qualquer uma das opções.

Texto integral ou fragmentos?

Manter os textos na íntegra é sempre a melhor opção. Se não

for possível, é bom estabelecer um critério claro de seleção e
informar isso no “Dicionário de dados” ou no diário da pesquisa
(sobre o qual falaremos depois). A integralidade dos textos
permite a longevidade do uso da base. Se, em algum momento,
percebermos (e será inevitável) que deixamos de lado trechos
relevantes, por algum fator que não podíamos prever (o que é
igualmente crônico), teremos que refazer tudo ou abandonar a
base. Outra opção é a de preparar a base para acréscimos
futuros, diante de uma realidade que impida a coleta total das
fontes. Mas, para isso, é necessário planejamento.

Reutilização de dados

Um dos grandes desafios das bases de dados é a possibilidade

de usar a base por longo tempo. Isso implica em duas questões:
uma técnica e outra teórico-metodológica. A técnica é simples: é
preciso planejar contínuas mudanças de formato para os dados,
migrando de sistema conforme os antigos vão sendo
 107

substituídos e os padrões forem sendo alterados. Isso

geralmente acontece com rapidez em informática, mas nem
tanto. O modelo de dados SQL, relacional, atualmente o mais
utilizado, data de meados dos anos 1970 e o modelo anterior,
hierárquico, foi utilizado desde os anos de 1950 até os de 1990.
Programas mudam, mas é relativamente fácil migrar entre os
sistemas, porém é preciso estar atento. O sistema criado pelo
Padre Roberto Busa, no início dos anos 1950, existe até hoje e
passou de cartões perfurados para uma base SQL na internet.

O problema teórico-metodológico é mais complexo. Tem relação

com o modelo conceitual que escolhemos para nossa base. Esse
modelo pode prever uma longevidade para a proposta ou
ignorar essa etapa. Isso acontece em razão da mudança nos
problemas de pesquisa em História, na mudança de temas,
objetos e até de paradigmas, ainda que em outro ritmo. Um
exemplo simples pode ilustrar isso: criamos uma base de dados
para inventários post-mortem e, por escolhas próprias da nossa
realidade de pesquisa (as hipóteses apontavam outro caminho,
tínhamos pouco tempo, poucos recursos, demanda por artigos,
etc.), optamos por não incluir dados sobre os herdeiros
apontados logo no início do documento. No meio da
investigação, percebemos que as informações sobre os herdeiros
eram fundamentais. Essa situação, absolutamente possível no
cotidiano da pesquisa, teria duas saídas possíveis: voltar às
fontes e corrigir o banco de dados com muito trabalho (teríamos
que deslocar pessoal para o arquivo duas vezes, com gastos de
transporte, de tempo e, talvez, de pagamentos) ou abdicar da
resposta que agora parecia ser a melhor, informando ao leitor
que há um elemento não considerado que poderia ter sido
 108

importante.64

O exemplo dado é simples, mas ilustrativo. A mesma dificuldade

pode ter uma manifestação mais fina. A opção que defendo, de
atualizar a grafia e normatizar os nomes, inviabiliza qualquer uso
da base para estudos de linguística de grafias arcaicas. Nesse
caso particular, parece-me que vale a pena pagar o preço,
quando não temos condições de criar um campo de cálculo
chamado “texto atualizado”. Concordo com Kevin Schürer65
quando argumenta que é impossível prever todos os usos
futuros de uma base. No entanto, seria conveniente, pelo
menos, pensar em certas metodologias mais próprias do tipo de
história que cada um faz, avaliando se podemos planejar a base
tendo em conta algumas possibilidades reais. Não podemos
prever o futuro, mas seria constrangedor esquecer algumas
demandas do presente por falta de planejamento.

Fuzzy information

Talvez seja a maior especificidade da relação entre História e

Informática: os dados dos historiadores, diferentemente do que
geralmente se demanda da informática, são geralmente
imprecisos, incertos e escorregadios. Como posso preencher o
campo “idade” de uma base feita para coletar "listas
nominativas de habitantes" se a fonte me diz que Fulano de Tal
“disse ter 50 anos mais ou menos”? E como preencho o campo
“data” se o ano está borrado e só tenho dia e mês? No primeiro

64
PRATESI, Alessandro, Limiti e difficoltà dell’uso dell’informatica per lo studio
della forma diplomatica e giuridica dei documenti medievali, in: FOSSIER, Lucie;
VAUCHEZ, André; VIOLANTE, Cinzio (Orgs.), Informatique et histoire
médiévale, Roma: École Française de Rome, 1977, p. 187–190.
65
SCHÜRER, Historical demography, social structure and the computer.
 109

caso, não basta colocar 50 no campo “idade” e “perder” o “mais

ou menos” no poço do esquecimento chamado de campo
“Observações”. Feito isso, estaremos dando por exata uma coisa
que os coevos, os nativos do tempo, consideravam imprecisa e
eles nem sonhavam com a precisão dos nossos dias.

A solução desse problema pode ser fácil para alguns casos e

complicada para outros. Para mencionar uma data da qual não
temos os dados completos, utilizando o sistema AAAA-MM-DD,
basta preencher usando um coringa, como o “0” no lugar da
informação perdida: 1789-00-00. Assim, é possível aproveitar os
conteúdos disponíveis, sem “forçar” o restante. Podemos usar
sinais indicadores quando temos condições de detalhar mais.
Sabendo, por exemplo, o ano do acontecido e que foi depois de
agosto, podemos usar a seguinte norma: 1789>08-00. O sinal de
maior indica que foi depois de agosto, embora não saibamos o
dia. Se não sabemos o ano, podemos inserir o mesmo sinal na
frente do conjunto: >1789-00-00. Na hora de processar dados
em série, basta mandar eliminar os registros com datas
“imprecisas”, o que não seria possível colocando a informação
sobre precisão no famigerado campo “Observações”.

O outro exemplo que dei, da idade, pode ter uma solução

semelhante, ainda que me pareça mais difícil. Um sinal gráfico
pode indicar a dúvida como estava na fonte (por exemplo, um
“*” para “mais ou menos”, um > para “mais de” etc.). Contudo,
isso seria igualmente perigoso, pois, em alguns casos, as fontes
informam as dúvidas dos contemporâneos com a própria idade,
em outros não, mesmo quando tinham. Nesse caso, não
colocaríamos o * por falta da própria fonte. Essa é uma das suas
características que deve ser considerada na hora do planejar o
 110

banco.

Outra saída seria deixar na tabela “lista nominativa” um campo

“idade dita” sobre cuja irregularidade não teríamos dúvida. Se
essas informações fossem realmente relevantes para nossa
pesquisa, penso que pareceria válido criar outra tabela que
juntasse os dados cruzados da mesma fonte na série, além de
outras, com os quais se poderiam comparar vários documentos,
com o objetivo de saber as variações disponíveis para cada
sujeito. Isso nos ajudaria, inclusive, a estimar o grau de
imprecisão da época e seus desdobramentos, como um possível
envelhecimento rápido ou a “idade social” das pessoas, expressa
numericamente por falta de outra medida.

Por fim, não deixa de ser interessante, se o planejamento julgar

conveniente, criar campos de avaliação da qualidade da
informação, inclusive para cada campo, se parecer adequado. Eu
não faria isso para todos os campos, mas, dependendo da fonte
e do caso, pode ser uma solução.

Os campos “Observações”, “comentários” e “notas”

O leitor atento já percebeu a antipatia desse que escreve pelo

campo “observações”. É isso mesmo. Geralmente usado como
um “saco de gatos”, o campo “observações” e seus amigos
“comentários” e “notas” mais atrapalham do que ajudam. Eles,
comumente, são a vala comum onde todas as falhas do projeto
vão parar e muitas dessas falhas poderiam ter rendido grandes
ideias e conclusões. Nosso foco precisa estar em evitar o campo
“observações”. Antes de preenchê-lo, seria melhor discutir com
a equipe ou pensar sozinho, se for o caso, na possibilidade de
criar algum campo ou solução que resolva aquele problema e
 111

outros potenciais, vindouros, da mesma natureza.

Esse campo, contudo, é indispensável. Ele pode ser importante

para anotações temporárias. Nesse caso, sua utilidade é bem
grande, mas eu não o chamaria de “observações”, nome
convidativo para procedimentos preguiçosos de trabalho, e
criaria um campo chamado de “notas temporárias de pesquisa”,
mais apropriado para sua real e valorosa função.
 112

Engenharia de pesquisa

O engenheiro recebe uma tarefa, avalia, projeta, calcula, executa

e entrega. Nesse meio tempo, o historiador continua
polemizando sobre a arbitrariedade da tarefa. Eu entendo e
compartilho os “poréns” dos historiadores. Mas é também fato
que não sabemos organizar grandes projetos ou pesquisas que
exijam mais fôlego. Digo isso em comparação com o que fazem
os pesquisadores das ciências “duras” (mas não só eles), em que
procedimentos de pesquisa e de autoria coletiva e domínio de
recursos de financiamento são, há muito tempo, normatizados e
domesticados. Não pretendo seguir com a reclamação, mas acho
que o desenvolvimento de uma base de dados bem feita envolve
um grande planejamento. Por isso, vou apresentar alguns
problemas e sugestões para conduzir trabalhos individuais e
coletivos, dando ênfase a estes últimos. O leitor saberá adaptar
os conceitos para os casos particulares.

Levantamento inicial

Convém sempre fazer um levantamento amplo da

documentação total que será analisada, incluindo variáveis de
resposta de campos, nomes e lugares, bem como a variação
mínima e máxima de páginas por documento.66 Por exemplo, se
pretendo trabalhar com processo-crime de uma localidade ao
longo de 20 anos, é importante saber, de antemão, de quantos
processos estou falando. O conhecimento do conjunto vai ajudar
66
AUTRAND, Françoise, Le personnel du parlement de Paris: traitement
automatique d’une prosopographie en vue d’une étude sociale, in: FOSSIER,
Lucie; VAUCHEZ, André; VIOLANTE, Cinzio (Orgs.), Informatique et histoire
médiévale, Roma: École Française de Rome, 1977, p. 239–243.
 113

a selecionar a amostra que utilizarei ou a demanda de recursos e

pessoal que terei para levantar todos os documentos. Por outro
lado, saber o volume estimado dos processos ajuda a decidir
sobre seu uso integral ou parcial. Para a maior parte desse
levantamento, há catálogos e índices de arquivos, mas, nem
sempre, é assim e, não raras vezes, nós mesmos precisaremos
fazer nossos instrumentos de consulta.

É difícil fazer o próprio catálogo, ainda mais com as demandas

que salientei aqui, que incluem, além da informação sobre o
número total de processos, dados sobre seu volume estimado.
Convém tomar amostras para facilitar. É impreciso, mas é
alguma informação. Aqui convém avaliar o custo e o benefício.
Caso a documentação ultrapasse certo volume, mais de 100, por
exemplo, tomam-se umas vinte amostras. Se for mais de 1000,
tomam-se 50 amostras. Menos de 50, nem convém tomar
amostras, pois é melhor já levantar todas. Mesmo que você não
utilize todos esses documentos, é importante, inclusive para sua
pesquisa, saber o universo particular do qual fazem parte. Isso
nos ajuda a saber que aquilo que julgamos “incrível” era, na
verdade, algo comum. Poupa-nos de dizer besteiras. Sempre
diremos, mas é melhor evitar as mais ingênuas e deixar somente
as melhores para os críticos.

Montagem de equipes

A seleção dos membros da equipe é importante, mas não vou

entrar nesse mérito. Cada um saberá como selecionar seus
colegas, conforme puder, pois geralmente isso não está
disponível. Escolhendo ou não, resta organizar a equipe de
modo eficaz, a fim de que todos entendam perfeitamente os
objetivos da pesquisa e o funcionamento da base, se possível,
 114

participando do seu desenvolvimento. É importante criar um

clima de colaboração e de debate sobre o desenvolvimento da
pesquisa. Certas incongruências entre a documentação e a base
podem ser percebidas com perspicácia pelo mais novato dos
auxiliares. É importante que ele se sinta livre para discutir com
colegas e coordenadores. Da mesma forma, podem conceber
eventuais funcionalidades que agilizem o trabalho, sem
prejudicar a qualidade do abastecimento.

Uma vez pronta, é hora de testar a base, como já vimos. Passado

o período de treinamento, vamos começar o abastecimento dos
dados. Nesse momento, é importante medir a produtividade
média dos abastecedores. Com essa informação, podemos ter
uma ideia mais precisa sobre como será o futuro do trabalho. No
projeto que resultou em Reconstructing historical Communities,
Macfarlane já falava do planejamento dos trabalhos e usava uma
medida particular para avaliar a demanda por trabalho. Segundo
ele, o projeto acabou em 1983 com uma média de 30
pessoas-ano. Era a produtividade estimada de um auxiliar de
pesquisa ao longo de um ano.

A montagem de uma equipe passa por esse tipo de cálculo. É

bem verdade que não podemos contratar as pessoas sem
dinheiro, mas é importante saber a demanda real de mão de
obra científica qualificada para o projeto. Com isso, saberemos
se o projeto durará poucos ou muitos anos, se terá reais
condições de ser finalizado ou se precisará de cortes na
proposta. Sabendo do que a equipe é capaz, podemos estimar o
término do período de abastecimento, identificando, inclusive,
certos excessos, como aquele auxiliar que preenche muito
rápido, talvez com erros, e o que é muito lento e que poderia
 115

melhorar.

Acho que uma boa equipe não precisa ser hierarquizada, salvo
se houver um coordenador que distribua as tarefas e administre
a base de dados, inclusive na implementação de melhorias. A
experiência me indica que, se criado um clima de colaboração,
os membros da equipe serão capazes de se engajar de modo
pleno. Se isso vale para a qualidade da pesquisa, já não estou
certo se vale para a gestão do tempo de trabalho e da
produtividade, que não podem ser esquecidos. Para isso, há o
coordenador. 67

Treinamento

O treinamento é fundamental. Sua realização, contudo, vai

depender de cada projeto. Parece que o melhor meio de treinar
a equipe é criar uma base paralela, cópia da original, que
funcionará como um simulador de voo. Os dados inseridos serão
perdidos, propositalmente, mas haverá diferença grande com a
prática, salvo o fato de não ser “de verdade”. Há algumas coisas
que podem ajudar. Criar um manual específico para uma base
não me parece uma boa ideia. Ele pode ser consultado por uns,
mas por outros não, que vão “tocar de ouvido” no
preenchimento. Ele pode ser usado algumas vezes, mas não
todas, e isso vai comprometer a qualidade do preenchimento da
base. O melhor é criar bases autoexplicativas e, se for
necessário, inserir certas regras de procedimentos ao lado do

67
Dupaquier já falava, em 1968, de importância de um “animateur” da equipe,
que faria aquilo que apresentei como responsabilidade do coordenador. Ver:
DUPAQUIER, Jacques, Suggestions pour l’organisation du travail d’équipe en
histoire sociale, in: L’histoire sociale: sources et méthodes, Paris: Presses
Universitaires de France, 1967.
 116

campo específico. Além disso, pode ser útil a criação de vídeos

demonstrativos. Eles têm grande vantagem em relação aos
manuais: mostram onde o sujeito deve clicar exatamente, sem
obrigá-lo a procurar um mitológico botão “Salvar” (que, nesse
momento, já poderia ter sido renomeado para “Enviar”, para
piorar tudo...)

Coletando os dados e abastecendo a base

Considerando que construímos uma base tendo uma boa noção

do conjunto das fontes que vamos usar, que previmos seu uso
com variada e conhecida metodologia e que já a testamos com
uma boa amostra das fontes, corrigindo suas imperfeições, é
chegado o momento de iniciar o abastecimento. Essa é a fase
que mais demanda “engenharia”. É preciso decidir qual o melhor
(ou possível) meio de coletar os dados e colocá-los na base. É
uma pergunta muito antiga nesse métier. Thaller já apresentava
essa preocupação em 1985.68 Geralmente, os arquivos estão
longe dos computadores, ainda que isso tenha mudado muito
desde a invenção e popularização de laptops e câmaras digitais.
Mas nem todos os arquivos permitem estes equipamentos e há,
inclusive, arquivos que não têm tomada disponível para
pesquisadores.

Outra questão que se coloca é a “hospedagem” do banco de

dados, sobre onde ele deve estar armazenado. Se for uma
pesquisa individual, a solução é fácil: no computador dessa
pessoa. Mas quando temos dois, a pergunta já é qualificada.
Devemos criar duas cópias do arquivo e juntar tudo depois?
Devemos colocar o arquivo num servidor da internet? Só um

68
THALLER, Can we afford to use the computer; can we afford not to use it?.
 117

abastece a base?, etc. Essas são questões que se complicam

quando trabalhamos com grupos maiores e se complicam ainda
mais quando dependemos de informações adicionais para tomar
decisões (identificar um sujeito, por exemplo, que pode estar
sendo registrado, ao mesmo tempo, por outro colega). Nesses
casos, é importante ter sincronia no trabalho para evitar perda
de tempo e redundância de informação.

Antes de iniciar, creio que dois pontos devem ser ressaltados: é

importante ter sincronia no abastecimento, com uma única
base, que deve ser preenchida ao mesmo tempo, e a coleta deve
ser a mais completa possível, de tal modo que não haja
necessidade de voltar ao arquivo. Mas como fazer isso? As
soluções para esses problemas são vastas, mas devo advertir o
leitor de que minha resposta estará, inevitavelmente, datada em
poucos anos. Não há questões de fôlego por trás, nem
perspectiva teórica alguma que nos ajude a dar longevidade
para essas soluções. Logo surgirão soluções melhores e isso é
muito bom.

Estratégias de coleta

As opções técnicas para a coleta de dados variam amplamente,

dependendo do contexto de cada pesquisa. No entanto,
podemos considerar diferentes níveis de dificuldade de acesso
às fontes e pensar em formas alternativas de resolver os
problemas. A maneira mais simples é digitalizar as fontes de
acordo com os padrões de conservação. Muitos arquivos
oferecem esses documentos digitalizados online, mas nem
todos. Alguns escaneiam esses documentos e os mantêm por
segurança, sendo necessário solicitá-los. Em qualquer caso, este
é o melhor de todos os mundos. Assim como há uma história de
 118

grandes homens e eventos significativos, há também a pesquisa

de arquivos proeminentes, aquelas instituições que são ricas e
podem fornecer fontes históricas online. Mas há toda uma
história a ser descoberta nos arquivos menos famosos. Vejamos
as circunstâncias menos afortunadas.

Fotografar os originais com câmeras digitais é o melhor

caminho. Boas fotos são, geralmente, para o historiador,
melhores do que o original, e por uma razão muito simples:
podemos tratar as imagens, mudar o contraste e ler melhor
aquela tinta apagada ou tentar ver algo além do borrão. Se a
tinta está esmaecida, a fotografia digital ajuda. Hoje, qualquer
pessoa tem acesso a programas gratuitos de edição de imagem,
fáceis de usar. Com a fotografia digital é possível, inclusive, ver a
marca d’água do papel, se isso parecer importante (e às vezes o
é).

Vejamos o caso de quem não pode usar uma câmera digital em

Arquivo. Não há motivo para desânimo. Se for uma pesquisa
individual, o problema é menor. Basta fazer um bom
planejamento da base, estimar bem o volume de informação
que será tratado e começar o trabalho. Nesse caso, vou começar
considerando que um laptop (ou outro equipamento portátil
com teclado) esteja disponível para a tarefa. É fundamental
transcrever o texto todo dos documentos para evitar a volta ao
arquivo, que é sempre mais custosa. Se a base já foi feita
prevendo a transcrição de partes, tudo estará resolvido. O
importante é ter o controle da informação e pensar tudo de tal
modo a evitar o retorno constante aos arquivos.

Tratando-se de uma pesquisa coletiva, com um banco de dados

utilizado por várias pessoas, convém pensar melhor. É muito
arriscado trabalhar com vários abastecimentos simultâneos e
 119

independentes, salvo se houver uma divisão muito clara de

trabalhos, com fontes muito diferentes ou épocas muito claras. É
possível também criar um sistema que importe as diversas
“versões” da base, checando se há repetição. Isso pode ser
muito simples se a base for orientada pela fonte, pois cada um
cuidará da sua fonte, que geralmente é única. O perigo
apresenta-se quando a fonte não é única, como jornais, livros,
fotos e panfletos. Diferentes caixas do mesmo acervo podem
conter cópias que serão duplicadas na base e podem ser
classificadas de modo diferente, gerando redundância.

Há um perigo maior quando as bases são orientadas pelo

método. Para as biografias, por exemplo, o mesmo personagem
pode aparecer várias vezes e com informações diferentes em
cada uma. Unificar isso tudo demandaria um trabalho manual
muito grande. Um sistema de importação poderia resolver, mas,
se for feito com algum erro, pode embaralhar tudo. A melhor
solução, no atual estado da tecnologia, é evitar bases múltiplas
(divididas para vários pesquisadores abastecerem
separadamente). Considerando a popularização dos aparelhos
de internet móvel e dos servidor de dados “nas nuvens”,
parece-me mais fácil investir nisso do que em correções e
importações sem fim. Além disso, com uma base única, todos
poderão saber o que os outros já recolheram (ou estão
recolhendo) e essa informação pode ajudar, inclusive, no
abastecimento de novos dados. Por fim, qualquer alteração nos
campos ou na estrutura da base será automaticamente
disponível para todos, sem que seja preciso corrigir todas as
bases paralelas.

A situação de não dispor de um equipamento (laptop, tablet,

etc) no Arquivo é uma situação cada vez mais rara, mas pode
 120

ocorrer. É sempre bom ter um caderninho, mas a melhor saída é

imprimir o formulário da base numa folha A4 e levar muitas
cópias. Usar canetas de cores diferentes e marcadores de texto,
dando significado para as cores, pode ser importante. Era assim
que os historiadores que aplicavam o método Henry faziam
antes da vulgarização dos computadores pessoais e foi no auge
do uso dessa metodologia que a companhia francesa BIC lançou,
em 1970, sua versão de quatro cores. Até onde sei, não há
nenhuma relação, mas deve ter feito a alegria dos historiadores
demógrafos.

Vejamos, agora, uma solução bem mais cômoda e que eu sequer

supus no início do texto: as fontes disponíveis na internet. Não
há muito para dizer, mas não poderia esquecê-las. É claro que há
materiais digitalizados com qualidades muito variadas, algumas
delas duvidosas, mas diversos acervos digitalizam seus
documentos e a maioria utiliza scanners planetários, o que é
excelente. Sobre esses últimos, é tão válido quanto estar no
arquivo e, em termos de praticidade, até melhor. Há que se ter o
cuidado de não esquecer outros documentos que estejam no
mesmo arquivo e que ainda não foram digitalizados, se forem
importantes.

Há documentos online de qualidade duvidosa: fotos de baixa

resolução, textos transcritos suspeitos e árvores genealógicas
feitas por descendentes dos nossos agentes, por fãs ou curiosos.
Sobre isso tudo, entendo que devemos agir com aquilo que mais
trabalhamos ao longo de um curso de História: a crítica. Não
descarto nenhuma informação de antemão - nem as do arquivo,
nem as do pior site da internet. De algum modo, todos estão
errados e todos são pistas que podem ou não fazer sentido
diante de um número muito maior de material empírico, de uma
 121

boa metodologia e de muita reflexão teórica. Resta, contudo,

tratar fontes de tipos e origens diferentes, tal como fazemos
com as fontes dos arquivos, separando cada uma delas e dando
um tratamento adequado.

O preenchimento manual da base

O preenchimento manual, com digitação, ainda é o sistema mais

comum e deve continuar sendo por muitos anos. Sabendo disso,
e tendo em conta o custo elevado desse tipo de mão de obra,
convém otimizar ao máximo esse trabalho, automatizando
algumas coisas e reduzindo o tempo que poderia ser gasto na
leitura dos manuscritos e na escrita, simplesmente. Neste
sentido, bases muito complexas, difíceis de preencher, devem
ser evitadas. Por exemplo, aquelas que demandam que os
nomes dos agentes históricos sejam cadastrados antes de serem
citados na transcrição de um documento. É melhor inventar um
sistema de cadastro automático que será checado
posteriormente, com o acumulado dos dados, e que permitirá
comparações e acertos. Mas há outras táticas, especialmente
nos programas atuais de gerenciamento de bases de dados.

Um recurso bastante prático, que deve ser usado com algum

cuidado, é o autocompletar. Muitos programas têm isso. O lado
bom é que poupa tempo e o ruim é que podem errar a sugestão
e o digitador não perceber, dada a quantidade de repetições que
deve fazer. Melhor do que o autocompletar é o campo de
opções múltiplas, do qual o digitador pode escolher uma ou
várias. Convém não deixar nada pré-marcado e dificultar um
pouco a escolha, de tal modo que ela tenha sido fruto de uma
decisão clara e não de um descuido. Outra opção pode ser a
criação de avisos de alerta. Se um campo numérico é preenchido
 122

com texto, o computador avisa ao digitador e questiona se está

certo disso.

Alguns programas mais elaborados permitem manobras mais

ousadas. É possível, por exemplo, criar certas programações,
também conhecidas como “macros”, que vão realizar tarefas
repetitivas previstas pelos usuários a partir do acionar de um
botão ou de um comando de teclado (tecla F4, por exemplo). Em
uma base de batismos, implementei um sistema assim para
casos comuns com aquela documentação, como “padrinho é
filho do capitão...”, “madrinha é casada com...”, de tal maneira
que bastava completar com a informação faltante. Esse
procedimento agilizou o trabalho sem prejudicar a qualidade.
Reforçamos a ideia de que é preciso automatizar o artesanato,
pois ainda realizamos todo o trabalho, mas usando facilidades
aportadas pelo computador.

Importando dados (digitais)

Muitas vezes, temos materiais produzidos para outras pesquisas

ou, simplesmente, transcritos no editor de texto e que
gostaríamos de importar para uma base de dados. Nem sempre
é fácil, mas, quase sempre, é possível. Com um pouco de
engenhosidade, é possível fazer manobras incríveis. Para tanto,
importa conhecer algumas coisas. A primeira é o sistema de
importação dos softwares de planilha eletrônica, por meio dos
quais se pode importar dados de texto para tabelas, com cada
coisa em seu lugar. Para fazer isso, devemos colocar o texto que
queremos em um arquivo com extensão ".txt". Contudo, isso
não basta. O computador faz coisas incríveis, mas não é
adivinho. Ele precisa saber onde começa uma informação e
onde acaba a anterior. Para tal, é necessário colocar alguns
 123

marcos indicadores, como a vírgula ou o ponto e vírgula, tal com

já vimos ao longo da leitura com os arquivo de tipo CSV.
Geralmente, esta última é melhor, pois é muito comum usarmos
vírgulas em textos. Fazendo isso, basta seguir um guia do próprio
software e importar todos os dados.

Essa facilidade está disponível em vários programas e pode ser

incrementada com o uso de campos de cálculo. Se o texto que
estamos importando já é um pouco estruturado, fica mais fácil.
Temos, por exemplo, uma lista de nomes, com o telefone e o
endereço. Podemos separar esses três tipos de informação em
campos distintos sem precisar de muito esforço. Se os telefones
estiverem com o prefixo, fica ainda mais fácil. Isso porque vamos
verificar que nosso documento tem a seguinte estrutura: texto,
número, texto. Vejamos um exemplo:

Nome;telefone;endereço
Pedro Paramo;36243452;Calle Directa - Comala
Eduviges Dyada;52622352;Calle Trocha -Comala

A importação de arquivos CSV está disponível em muitos

programas e pode ser aumentada pelo uso de campos de tipo de
cálculo, que podem ser projetados para capturar algumas partes
específicas de outro campo. Se o texto que estamos importando
já estiver um pouco estruturado, fica mais fácil. Por exemplo, se
tivermos uma lista de nomes, com seus telefones e endereços,
podemos separar esses três tipos de informações em campos
distintos sem muito esforço. Se os telefones forem prefixados, é
ainda mais fácil. Isso porque podemos verificar que nosso
 124

documento possui a seguinte estrutura: texto, número, texto.

Vamos ver um exemplo:

Joaquim Nina. (21) 3624-3452. Rua das Graças, 72

Severino. (21) 5262-2352. Rua Haddock Lobo, 23

Se usarmos um campo de cálculo, podemos fazer com que o

campo capture tudo entre o primeiro e o segundo pontos
(observe que, neste exemplo, o número sempre termina com
um ponto). O que vem antes do primeiro ponto é um nome e o
que vem depois é um endereço. Nem sempre temos muitos
pontos para facilitar a vida, mas é comum encontrarmos alguns
elementos que podem nos ajudar a estabelecer as regras
(delimitadores) do nosso campo de cálculo. Se tivermos apenas
duas linhas, não vale a pena. No entanto, quando temos
centenas de linhas, isso economiza muitas horas de trabalho.

Esses procedimentos estão associados ao REGEX, uma sigla para

“expressões regulares”. REGEX são sequências de caracteres que
podem ser identificados como padrões de texto, conforme visto
no exemplo anterior. Reconhecer como um texto é estruturado
torna possível encontrar os melhores delimitadores para
granular os dados, tanto quanto possível. Técnicas de análise
podem ser empregadas para otimizar a extração de dados. Em
uma seqüência 1958-12-29, por exemplo, podemos estabelecer
a primeira seqüência de quatro caracteres enquanto o ano,
como vimos no subcapítulo “Formatos de Data”.
 125

Importando dados (analógicos)

Podemos fazer algo semelhante com documentos impressos (e

sem manchas ou imperfeições gráficas). Basta usar o scanner e
um programa de OCR (Optical character recognition ou
reconhecimento óptico de caracteres). O mesmo pode ser dito
para os mais recentes HTR (Handwritten Text Recognition ou
reconhecimento de textos manuscritos), que usam inteligência
artificial para transcrever documentos manuscritos. Esses
programas vão reconhecer o texto, com algumas imperfeições,
mas bem no conjunto. Se os dados estiverem estruturados no
original, como uma tabela, uma lista ou pontuados de modo
coerente, como no exemplo que apresentamos acima, serão
facilmente importados para um banco de dados. Depois de
escaneados e reconhecidos, basta aplicar as mesmas regras que
apresentei para capturar as informações.

Administração da base

Uma base coletiva, em um projeto de pesquisa maior, deve ter

um sistema de administração, tanto se for única, na internet,
quanto se for uma base múltipla (com várias cópias sendo
abastecidas simultaneamente). As duas demandam atenção,
mas cada uma de modo particular. Uma base múltipla demanda
grande cuidado com respeito à importação dos dados e à
sincronização dessas informações. É preciso distribuir as tarefas
e coordenar quem ficou responsável pelo quê, tendo em conta o
levantamento prévio do conjunto da documentação. Por seu
turno, uma base única, online, demanda o cadastro de usuários,
 126

atribuição de poderes para cada participante (do que pode ou

não fazer) e a distribuição de tarefas. No caso de uma base
única, é preciso criar campos para registrar quem preencheu a
ficha e quando. Isso ajuda a identificar erros e a controlar o
trabalho.

Independentemente do tipo de base escolhida, é interessante

criar um “diário de campo”, um espaço para que todos os
membros da equipe descrevam diariamente o trabalho. É
preferível que ele seja público e que todos possam ler os diários
dos colegas, acompanhando o andamento dos trabalhos. Isso dá
unidade ao grupo e unifica as decisões, ressaltando, de
imediato, práticas mais individualizadas (o famoso "fiz do meu
jeito"). Além disso, esse diário pode servir como base para um
relatório ou ser usado como um memorial do trabalho realizado,
permitindo uma auditagem em qualquer tempo. Se a base for
online, é conveniente que o diário também o seja. Para isso, há
diversos blogs disponíveis.

Checagem de dados

Trabalhar com equipes demanda cuidado com a qualidade dos

registros, não somente por causa da falta de cuidado potencial
de algum dos colegas, como também da potencial falta de
homogeneidade na tomada de decisão no momento do
preenchimento. Informações inesperadas aparecem o tempo
todo e cada um as classifica como quer. Assim, é importante
criar dispositivos e protocolos de checagem de dados. Há formas
tradicionais de fazer isso, como conferir uma amostra da base
com os dados originais, mas há erros simples e frequentes que
podem ser resolvidos de modo automatizado. Um deles consiste
em exibir os registros em forma de uma tabela e verificar,
 127

visualmente, se as informações de cada campo são coerentes

com o esperado. Isso pode ser feito com grandes quantidades de
registro e essa simples verificação visual já destaca muitos
problemas.

Outra saída possível é hierarquizar os registros, campo por

campo. Erros de data, por exemplo, são rapidamente visíveis
com esse tipo de procedimento. Espaços antes de texto também
são ressaltados. Isso tudo pode ser amplificado exportando-se
os dados para uma planilha eletrônica. Informações fora do lugar
ou muito discrepantes podem ser identificadas com facilidade. É
claro que algumas podem virar grandes descobertas, digamos
assim, mas podem ser um simples erro de digitação. Com os
dados exportados para uma planilha eletrônica, podemos
mandar eliminar (apenas na planilha) os elementos repetidos e
obter apenas as variações disponíveis. Isso permite verificar
pequenos erros, como “Terça-feira” e “Terca_feira”. Esse
pequeno detalhe geraria duas informações diferentes. Os
campos de cálculo podem ser igualmente úteis para essa tarefa,
assim como o uso das tabelas dinâmicas. Tudo isso sem perder o
nosso artesanato.

Existem maneiras automatizadas de identificar erros. Há vários

algoritmos (além de outros que podem ser criados) para
destacar os problemas de preenchimento. O fuzzywuzzy é um
bom exemplo, disponível para código 'Python' e ‘R’. É um
algoritmo de "reconciliação" que fornece correspondência de
texto. Ele pode identificar erros de digitação usando uma
biblioteca de certas palavras e alternativas sugeridas com uma
porcentagem de possibilidade para cada erro. Outra ferramenta
interessante e mais simples de usar é o software “openrefine”
que é capaz de diferentes tipos de correções e limpeza de dados
 128

de problemas, reconciliação, substituição e transposição de

formatos. Você não está limitado a essas duas opções, uma vez
que existem outras opções de processamento automatizado de
dados e muitos algoritmos em vários formatos.

Problemas e perigos em bases de dados mal feitas

Talvez a melhor forma de demonstrar a importância de se criar

bancos de dados bem feitos venha de exemplos de fracasso.
Bases de dados bem feitas acabam por não mostrar seus
méritos: elas apenas cumprem sua função de organizar os
dados. Por outro lado, bases mal feitas são muito eloquentes ao
não permitir qualquer observação, qualquer conclusão. Vamos
apresentar alguns casos de bases feitas de modos
completamente equivocados ou que permitiam seu
preenchimento de modo caótico, gerando dados diferentes que
não autorizam qualquer afirmação. Uma curiosidade: todos os
casos são baseados em experiências reais. Os nomes dos
pesquisadores, das instituições e mesmo as datas de realização
destes projetos foram alterados para não expor seus autores.
Muitos leitores encontrarão casos semelhantes em suas
memórias, já que erros como estes dificilmente são esquecidos.

Nos anos 1970, a North Coast University desenvolveu um

ambicioso projeto que envolvia diversas outras universidades,
de vários continentes, buscando o estudo de elites políticas na
época moderna. As reuniões de debates foram muitas, com
amplo financiamento. Uma base de dados para unificar os
projetos foi considerada fundamental. A ideia era simples: cada
pesquisador definiria um caso para estudar, dentro do mesmo
 129

recorte de tempo e espaço, de tal modo que, ao final, todos

pudessem comparar seus casos. A base de dados comum traria
dados sobre personagens históricas presentes nas pesquisas, as
quais, em boa medida, poderiam ser estudadas por mais de um
pesquisador. Isso permitiria o compartilhamento de fontes e
dados em diferentes pesquisas.

Uma base de dados foi criada de tal modo que as buscas

poderiam se dar por agente histórico, lugar ou tipo de fonte. O
problema, neste caso, foi no abastecimento. Cada pesquisador
inseriu dados os mais diversos e aleatórios, de tal maneira que o
uso comum do sistema foi prejudicado. Não havia um único
agente histórico que aparecesse em mais de uma fonte e todos
os documentos inseridos eram relativamente pobres em
informação. A explicação é simples: cada qual julgou que o
trabalho de abastecer a base com muita informação não
compensaria seu uso, sem considerar o fato de que, se todos
inserissem muitos dados, a base seria útil para diversas
pesquisas. De modo geral, a falta de clareza sobre o uso de
bases de dados impediu que os pesquisadores soubessem o que
exatamente poderiam extrair do sistema criado.

Em outro caso, na Central Lake University, um projeto

coordenado pelo professor Alistar S. tinha por objetivo utilizar
Registros Paroquiais de Batismo para entender as relações
sociais em uma pequena comunidade da Itália no século XVII.
Um sistema bastante complexo de bancos de dados integrados
foi criado, permitindo a inserção de diversos tipos de
informação, tendo em conta a variedade de dados presentes em
fontes do século XVII. Havia campos para informar o pai, a mãe,
o marido da mãe, se diferente do pai, e a esposa do pai, se
diferente da mãe. Havia previsão para informar se os padrinhos
 130

eram casados entre si ou com outras pessoas e sobre quem

seriam essas pessoas.

A base começou a ser preenchida e tudo ia muito bem. Em um

certo momento, contudo, a fonte informava que a madrinha era
filha - e não esposa, como previa a base - de alguém. Mais
interessante, a madrinha era "filha do General...". Diante desse
cenário, dois campos novos foram criados: "paternidade da
madrinha" e "patente militar do pai da madrinha". A solução
pareceu boa pois muitos registros seguintes usaram destes
campos. Contudo, em algum momento, perceberam que os
primeiros registros inseridos também tinham esta informação,
que fora ignorada pela falta de um campo apropriado. Neste
caso, todo o trabalho precisou ser revisto, custando muitas
horas de trabalho e uma sensação eterna de que alguma coisa
continuava errada.

Por outro lado, outras variações sobre parentesco dos padrinhos

foram surgindo, inclusive que o padrinho era "sobrinho do
capitão...". Isso tudo gerou uma grande quantidade de campos
adicionais que deixavam o preenchimento da base muito difícil e
as possibilidades de erro ou falta de preenchimento
aumentaram muito.

Outro ambicioso projeto dos anos 1980 foi desenvolvido por um

grupo de pesquisadores de diferentes Universidades,
especialmente Mountain College e South Coast University. A
proposta era recolher registros de reuniões de conselhos
políticos locais, identificando as pessoas que participavam das
reuniões e os assuntos tratados. Com isso, seria possível
comparar casos de lugares muito diferentes, no mesmo período
de tempo, observando quais eram os assuntos que mais
 131

inquietavam os conselhos locais e se suas preocupações

ultrapassavam o interesse regional ou não.

A base de dados era muito simples, com campos para: data,

local da reunião, listas dos participantes, assuntos tratados,
resumo da reunião, transcrição completa do texto da reunião.
Com uma ficha simples como essa, não seria possível encontrar
problemas. Isso ocorreu, novamente, por conta do
preenchimento. Cada pesquisador que participava do projeto
ficou encarregado de um lugar diferente. Alguns membros da
equipe entenderam que bastava colocar os assuntos tratados e a
comparação com os outros lugares seria possível. E, nisso,
tinham alguma razão. Faltou combinar com os outros, que
entenderam que, se havia uma transcrição completa do texto da
reunião, não era necessário nem colocar os assuntos tratados e
muito menos preparar um resumo. Por fim, havia também
aqueles que, colocando o resumo, não viam necessidade da
transcrição completa, ainda que julgassem relevante informar a
lista de assuntos tratados.

Cada um destes pesquisadores fez isso com um judicioso critério

científico. Quem optou apenas pela lista de assuntos o fez
sabendo que o volume de dados disponíveis em sua localidade
era muito grande e seria impossível fazer resumos ou
transcrições completas das atas. Quem optou por enfatizar os
resumos entendeu que o volume de dados da sua região
permitia isso e que um bom resumo poderia substituir, em
termos de comparação, a transcrição dos originais. Quem
transcreveu os textos completos entendeu que ter os
documentos originais era fundamental para qualquer análise
textual e, dada sua relevância, e também pelo volume de dados,
não haveria tempo para preencher uma lista de assuntos. O
 132

resultado foi claro: nenhuma comparação era possível. As

conclusões obtidas dispensavam qualquer base de dados,
bastando passar os olhos nos documentos e verificar as
preocupações mais evidentes de cada região.
 133

Montando bases: alguns exemplos

concretos

Muitos historiadores que vimos defendem que as bases, em

História, deveriam ser source-oriented, ou seja, feitas a partir da
estrutura das fontes. Essa afirmação - que defendo - pode ser
polêmica por dois motivos. O primeiro é que ela tem cheiro de
positivismo. Aprendemos na universidade “a não nos deixarmos
levar pelas fontes” ou que “toda a fonte é enganadora” ou que é
a “teoria que abre a caixa-preta das fontes”. Tudo isso me parece
correto e não vou divergir. O problema é que, para fazer a nossa
“virada epistemológica” e ver além do que diz a nossa empiria, é
preciso conhecê-la. É preciso, ainda, conhecer os informantes:
saber como as fontes foram construídas, por quem, com que
propósito, que interesses estavam em jogo. Enfim, é preciso
saber como “arrancar a informação” de quem pretendia falar de
outra coisa ou, como dizia Certeau, "transformar em
'documentos' determinados objetos distribuídos de outra
forma."69 É certo que partimos de um problema de pesquisa,
mas o caminho inclui uma parada para um longo contato com a
empiria.

O segundo motivo para a polêmica é que muitas pessoas já

usam ou pretendem construir bases direcionadas para certos
objetivos, sem um grande desmonte da empiria ou sem um foco
maior nesse esforço. Para ajudar o argumento dessas pessoas,
vou até citar um bom exemplo de base de dados desse tipo: o
projeto The Trans-Atlantic Slave Trade Database.70 Trata-se de

69
DE CERTEAU, A operação histórica, p. 30.
70
Voyages Database. 2009., Voyages: The Trans-Atlantic Slave Trade Database.,
disponível em: <http://www.slavevoyages.org>, acesso em: 4 jan. 2014.
 134

um banco de dados com mais de 35.000 viagens de navios

negreiros na época moderna. Um projeto que não pretende a
precisão exata do número de viagens e de seres humanos
transportados. Ele pretende estimar o volume total ou, para
empregar o conceito correto, a grandeza daquela prática (que
não tinha nenhuma grandeza, mas contava com dezenas de
milhares de viagens com mais de uma dezena de milhão de
almas conduzidas para o trabalho escravo). A exatidão aqui não
é o objetivo e nem o poderia ser. A crítica documental foi pouco
considerada e há motivos para isso. Se fosse bem feita, como
quem faz uma tese usando uma única fonte, o projeto jamais
seria concluído e uma crítica bem feita pode mudar o número
exato de navios e escravos que cruzaram o Oceano Atlântico,
mas não a grandeza. Por outro lado, o “número exato” seria uma
esperança assaz ingênua.

A pouca preocupação relativa com a crítica da fonte no The

Trans-Atlantic Slave Trade Database justifica-se pela dimensão
do projeto. Poucas vezes ela está tão bem amparada. Não vou
criar aqui uma regra ou mesmo dar uma sugestão que proponha
os limites desse expediente. Isso depende das características de
cada pesquisa, mas deve ser levado em conta. Em geral, eu
recomendaria sempre conhecer bem as fontes, especialmente
as que são centrais para nossa pesquisa.

Convém enfatizar que não é apenas com uma pergunta ou

problema que conduzimos uma pesquisa sem ter a fonte como
eixo central. Há certas metodologias que podem valer-se de um
leque muito amplo de fontes, como os estudos prosopográficos
e de análise de redes sociais. Em ambos os casos, podemos
compor um mosaico de informações sobre cada um dos
personagens que fazem parte do nosso estudo, tendo como
 135

fonte dezenas ou centenas de fragmentos com as mais diversas

origens. E seria quase impossível fazer a crítica completa de
todas. Veremos, agora, algumas aplicações possíveis de bases de
dados tomando exemplos elaborados a partir de fontes diversas,
metodologias e temáticas.

Antes de continuar, gostaria de insistir em algo que me parece

fundamental: as bases de dados podem ser usadas em qualquer
pesquisa e não apenas em estudos quantitativos ou seriais. É
certo que estes últimos dependem de bases para ser realizados,
mas a recíproca não é verdadeira. Podemos usar bases para
qualquer tipo de estudo. É claro que nem todos os estudos ou
abordagens precisam desse tipo de ferramenta, mas o simples
fato de organizar as informações, mesmo notas de pesquisa,
torna as bases de dados úteis para qualquer situação.

Bases centradas na fonte

Este é o tipo preferido de grandes nomes, como Manfred Thaller

e Alan Macfarlane. Ambos adotaram como padrão de trabalho
uma espécie de transcrição estruturada, através da qual o
documento era transcrito normalmente, mas certos fragmentos,
palavras, números e datas eram rotulados para que o
computador pudesse processá-los. O mesmo também é
defendido por Carvalho que disse que "os melhores métodos de
entrada de dados oriundos de fontes históricas são aqueles que
preservam a estrutura original da informação".71 Usando desse

71
CARVALHO, Joaquim, Soluzioni informatiche per microstorici, Quaderni
Storici, v. XXVI, n. 03, 1991(Tradução nossa. O original está em italiano).
 136

recurso ou não, precisamos criar tabelas e campos para

transformar nossos papéis velhos em bytes. Vejamos alguns
exemplos.

Registros de batismo

Comecemos com uma fonte bastante tradicional nas aplicações

informatizadas: os registros de batismo. Sei que os mais antigos
conservados são de algumas cidades italianas e que podemos
encontrá-los em toda a Europa, na África e na América. Como
vou trabalhar com essa fonte, li vários artigos e livros sobre o
uso que fizeram dela e das variações possíveis (ou, pelo, menos
as mais comuns) em seu formato. Sei que há vasta metodologia
desenvolvida para sua análise e que elas podem revelar-se úteis
em algum momento da pesquisa, pois minha pergunta inicial
pode mostrar-se insuficiente e demandar outras abordagens não
previstas inicialmente. Para tanto, precisarei adequar a pesquisa.
Quando isso acontecer, será bom ter preparado a base de
maneira a prever algumas possibilidades. Isso não significa criar
uma base para tudo, mas desmontar de tal modo que os dados
dos batismos possam ser remontados de diversos modos e não
apenas da forma originalmente pensada.

Vamos pensar na forma como os registros estão dispostos.

Sempre serão na forma de livros, não apenas pelo fato disso ser
comum, mas porque há uma demanda oficial através de
normativas internas da Igreja que não vou explorar aqui. Todos
os arquivos têm volumes onde ficam registrados os batismos
que couberam ali. O número de registros de batismo possível
em cada tomo é n. Não há mínimo ou máximo. Eles não têm
divisão interna estabelecida. Os batismos geralmente são
listados na ordem cronológica, um após o outro. É possível
 137

encontrar divisões em alguns casos, como metade do livro para

pessoas livres e a outra metade para escravos, em sociedades
escravistas. Há, igualmente, separação para indígenas, mas são
especificidades de alguns exemplares e não regras da fonte.
Precisamos, contudo, considerar esta possibilidade e saber
incluir isso no nosso modelo conceitual.

Mesmo que os registros estejam dentro de livros, eles se

constituem em uma série. Os livros são o suporte para que a
série exista e fique organizada, mas, se fosse possível ter um
livro infinito, ele teria todos os registros. Assim, o livro é
importante, mas não é central. O centro das atenções está no
registro propriamente dito que tem uma estrutura interna
relativamente regular. É comum que comece com a data, que
fale imediatamente o nome do batizando com sua legitimidade
e os responsáveis por ela, seus pais. Pode mencionar os avós,
mas nem sempre isso ocorre. Ele informa os padrinhos e
encerra-se com a assinatura do padre. É comum que sejam
acrescidas observações sobre cada um dos participantes,
especialmente sobre o estatuto das pessoas, a residência, a
naturalidade e o local do batizado.

Observando a descrição acima, sabemos que há elementos

constantes e esperados, como o nome do batizando, dos pais e
dos padrinhos. Seria igualmente esperada a informação sobre os
avós, mas ela não é tão regular. Há, ainda, conteúdos
completamente irregulares, que podem ou não ser mencionados
para alguns (e não para todos) dentro de um mesmo registro.
Pode haver duas informações de qualidade diferente ("filho do
capitão" nos diz de quem é filho e que o pai é capitão) para um
único participante e nenhuma para os demais. Por ter visto
muitos registros, sei que é possível que os batizados aconteçam
 138

em um lugar diferente da Igreja Matriz, como em uma

propriedade agrária ou na casa de alguém. Da mesma maneira,
a criança pode ter sido batizada in extremis, por temor de sua
morte, mas sobrevivido para ter com o padre e receber os
santos óleos posteriormente. O padre pode ser um e a pessoa
que batiza outra, assim como o batismo pode ser dado por um
padre e o registro ser feito por outro.

Assim, podemos começar nosso trabalho. Tomamos o papel e

anotamos todas essas observações. Sabemos também o volume
que vamos abordar - se um, dois ou três livros, por exemplo.
Contamos que cada página tem, em média, quatro registros e
que os três volumes que vamos usar tem, somados, 650 páginas.
Isso nos permite estimar a grandeza do número de registros: uns
2600. Tendo isso apontado, podemos seguir em frente. O passo
seguinte é pensar sobre quantas tabelas serão necessárias. Pelo
que foi dito até aqui, quantas você, leitor, pensaria? Eu diria que,
pelos menos, três: uma para registrar os livros, outra, a mais
importante, para registrar os batismos, e uma terceira para
registrar as informações irregulares sobre os participantes do
batismo - sua condição social, seu estatuto, sua residência, etc.
Elas merecem, em minha opinião, uma tabela separada e
relacionada com a dos batismos. Vejamos:
 139

Figura 26 - Modelo Conceitual de uma base para registros de batismos

Criamos tabelas quando os fragmentos que identificamos em

nossos materiais têm relevância e especificidades suficientes
para ganhar um espaço exclusivo feito sob medida. Vamos
pensar, agora, nos campos de cada uma das tabelas, começando
pela de “livros”. O primeiro campo que sempre devemos criar é
o “código”, um campo que vai identificar inequivocamente cada
registro, nesse caso, cada livro. Alguns usam a expressão
“Identificador” ou “ID”. Há quem use “Matrícula”. Eu prefiro
chamar de “código”, especialmente pelo fato de que ali será
inserido um código alfanumérico que será facilmente
identificado como uma fonte. No caso dos batismos, eu faria
algo como “SAnt_bat_001” para identificar o livro de batismos
número 1 da Paróquia de Santo Antônio. Os programadores
chamam esse tipo de campo de “chave primária”. Depois,
veremos que os registros de batismos desse mesmo livro terão
também esse rótulo, acrescido da página e da ordem do registro
dentro dela. O campo seguinte é o nome da paróquia, um
campo de texto; o próximo é o número do volume e o seguinte
um campo de texto para informar o ano inicial e o final do tomo.
É também importante fazer um campo para informar o número
de registros total desse livro, assim como o de páginas. Eu ainda
faria um campo para a abertura do livro (isso é feito, quase
 140

sempre, na primeira folha) e outro para seu “fechamento” (fica

na última). Acabaria com um campo de observações. Talvez seja
o caso de criar um campo para o nome do volume, pois, em
algumas vezes, são identificados com um título como “Livros dos
Pretos da Candelária”. Assim, temos:

TABELA “LIVROS”

CAMPO TIPO OBS

Código_livro* Texto (chave Máximo de 12 caracteres
primária)
Paróquia Texto Livre
Número do livro Número Máximo de 3 caracteres
Data inicial Data (ou texto) AAAA
Data final Data (ou texto) AAAA
Total de registros Número Máximo de 5 caracteres
Total de páginas Número Máximo de 4 caracteres
Abertura Texto Livre
Fechamento Texto Livre
Observações Texto Livre
* Indica que o campo terá um relacionamento com outra tabela.

Agora precisamos dar conta da tabela “Batismos” propriamente

dita, que requer mais trabalho. Começamos novamente com o
campo “código_livro”, que vai receber o código do livro em
todos os registros, de modo a permitir seu relacionamento. É
como se carimbássemos o código do livro em cada registro para
associá-los. Com isso, não precisamos digitar nenhum dado do
livro no registro, que já herdará todos do seu “pai”. Essa filiação
é tão marcante que muitos programadores costumam chamar os
 141

campos de “ID” (identificador) e “ID_parent” (identificado do

pai) para enfatizar isso. Pode ser uma opção. Eu prefiro utilizar a
palavra “código”, seguida de outra que indica o que está sendo
codificado e, nesse caso particular, é importante usar o mesmo
nome, pois logo criaremos outro campo “código” para outro
relacionamento que a base terá, agora, com os detalhes
relativos aos participantes do batismo. Esse campo será
chamado de “código_registro”. O próximo campo pode ser o de
“transcrição”, que receberá o texto do batismo na íntegra. É uma
alternativa, ainda que não seja necessário, mas possa ser útil
para evitar novas viagens ao arquivo. Eu o usaria pensando no
problema apresentado na página 27, quando falei que Martha
Hameister encontrou um registro de batismo excepcional. Não é
preciso criar um campo para o texto inesperado, mas não vamos
perder essa preciosidade. Ele ficará junto com as outras
informações seriáveis, mas integralmente transcrito. Vejamos
quais outros campos seriam necessários:
TABELA “BATISMOS”

CAMPO TIPO OBS

Código_livro* Texto Máximo 12 carac.
Código_registro* Texto Máximo 19 carac.
Transcrição Texto Livre
Local de nascimento Texto Livre
Local do batizado Texto Livre
Padre celebrante Texto Caixa de escolha
Quem redigiu Texto Caixa de escolha
Data do batismo Data ou Livre
Texto
Data do nascimento Data ou Livre
Texto
Nome do batizando Texto Livre
Sexo Texto Caixa de escolha (M, F)
 142

Legitimidade Texto Caixa de escolha (L, N)

Pai Texto Livre
Mãe Texto Livre
Padrinho Texto Livre
Madrinha Texto Livre
Avô paterno Texto Livre
Avó paterna Texto Livre
Avô materno Texto Livre
Avó materna Texto Livre
Observações Texto Livre
* Indica que o campo terá um relacionamento com outra tabela.

Comecemos observando o campo “Código_registro” que deve

ter até 19 caracteres para que possa receber o “código_livro”
integralmente e ser acrescido de números que indiquem a
página e a ordem do batismo na dita mesma. Ficará algo como
SAnt_bat_001_023v_3. Nesse caso, vai significar: Paróquia de
Santo Antônio, 1º livro de Batismos na página 23 verso, 3o
registro na ordem da folha, de cima para baixo. Com isso, cada
registro terá seu endereço completo no arquivo da igreja de uma
forma compacta e fácil de entender (e de citar, pois pode ser
usada como referência nos textos que forem feitos com o
registro. Basta copiar e colar).

O sexo não é dito, mas pode ser uma informação fácil de se

obter, tendo em conta apenas o nome. Uma opção, já usada e
aprovada pelo autor, é criar um pequeno aplicativo que faça
uma varredura pelos registros para procurar nomes masculinos e
femininos e preencher automaticamente o sexo. Para isso, é
preciso ter uma lista prévia dos nomes para cada sexo. Dá
trabalho e deve ser feita para cada contexto, região e época,
pois muda bastante, mas, depois, basta aplicar para qualquer
 143

outra fonte ou registro novo. Essa aplicação depende do

programa e da habilidade do usuário em criá-la. Não vamos
ensinar aqui, pois depende de cada software.

Por fim, temos a terceira tabela, “Detalhes”, que será muito

enxuta para permitir alguma maleabilidade, para que possamos
receber qualquer tipo de dado adicional. Comecemos com nosso
velho amigo “código”, nesse caso, “código_registro”, que
associará todos os detalhes com os batismos respectivos. O
seguinte é um campo que classifique o tipo de informação que
será incluída e que vai depender dos critérios que cada equipe
ou pesquisador adotar. Eu criaria opções como “Batizado em”,
“Casado com”, “Filho de”, “Qualificativo”, etc, tendo em conta o
que aparece na fonte, mas de modo minimamente estruturado.
Depois poderemos reagrupar esses rótulos em outras categorias
e analisar como quisermos. Uma postura mais indutiva permite
isso. O campo seguinte nos diz sobre de qual dos participantes
será a informação - se do pai, da mãe, dos padrinhos ou dos
avós. O quarto campo será para indicar o nome do referido para
associar o detalhe à pessoa. O quinto, que chamarei de
“informação”, permitirá detalhar de modo descritivo o que está
sendo registrado. Vejamos:

TABELA “DETALHES”

CAMPO TIPO OBS

Código_registro* Texto Máximo 12 carac.
Tipo de informação Texto Caixa de opções
Qual posição Texto Caixa de opções
Quem Texto Livre
Informação Texto Livre
Observações Texto Livre
* Indica que o campo terá um relacionamento com outra tabela.
 144

Com isso, já temos o modelo conceitual de nossa base e

elementos para construir os modelos lógico e físico. A
construção desses dois vai depender do software escolhido, mas
será apenas uma tarefa mecânica depois de todas estas
decisões. Contudo, com isso, temos apenas uma base
“individual”, para um único usuário. Se quiséssemos gerar um
sistema com controle de usuários, distribuição de tarefas e
auditoria, precisaríamos fazer outra tabela, para cadastrar os
usuários e criar os campos “usuário” e “data de criação” em
cada uma das outras tabelas, para que se registrasse quem fez o
que e quando. Vale a mesma lógica apresentada até aqui.

Com essa estrutura, podemos fazer coisas muito complexas com

essa fonte. Podemos, por exemplo, selecionar apenas os livros
que contenham registros nos quais o padrinho era filho de
capitão. Com isso quero dizer que, resguardando as
especificidades de cada tipo de informação ao criar três tabelas,
podemos ainda fazer buscas cruzadas considerando que as três
tabelas estão relacionadas. Respeitamos a estrutura da fonte e
ainda temos como recuperar dados com rapidez e
complexidade. Se fizéssemos apenas uma tabela, teríamos muita
dificuldade de guardar esses dados como “padrinho era filho de
capitão” e tenderíamos a perder a informação, colocando-a em
um campo muito específico ou, simplesmente, ignorando-a. O
planejamento permitiu, como vimos, um uso amplo dos dados.
Mais adiante, veremos como essa base poderia integrar-se com
outras, de batismo e de óbitos, para a aplicação do método
Henry.
 145

O exemplo acima é válido para Modelos Relacionais, mas

existem outros modelos, como vimos. Há um forte argumento
para usar o modelo Relacional ao trabalhar com Registros de
Batismo porque é uma fonte muito regular, com valores
esperados na maioria dos casos. Nesse sentido, utilizar uma
tabela com campos pré-definidos é algo mais próximo do
documento que também possui sua regra pré-definida. Porém,
vimos que era necessário criar uma tabela adicional chamada
“Detalhes” para dar conta das informações imprevisíveis,
mesmo em uma fonte tão regular. Não teria sido melhor, talvez,
usar um modelo Graph ao pensar nos Registros de Batismo, pelo
menos na parte “Detalhes”? Em certo sentido, a tabela
“Detalhes” que incluímos no modelo Relacional procura imitar a
experiência dos modelos não relacionais (conhecidos como
NoSql).

Um modelo que funciona muito bem para registros de batismo é

o key-value. Com ele podemos criar uma grande lista onde as
diferentes características de cada pessoa que participou do
batismo são mencionadas à medida que aparecem e com os
detalhes que vão surgindo. Isso permitirá que as consultas
capturem apenas os dados de um determinado participante, por
exemplo, ou busquem todas as mães. Podemos marcar sua
posição no batismo, conforme mostrado abaixo:

pessoa_pai: nome = “Pedro Paramo”;

pessoa_pai: idade= 43;
pessoa_pai: profissao= “fazendeiro”;
pessoa_mae: nome =”Dolores Preciado”;
 146

pessoa_mae: idade=22;
pessoa_avoM: nome=”Isabel”;
pessoa_avoM: residencia=”vive na segunda rua depois do
açougue”;
pessoa_avoM: profissao=”ajudante do padre”;
pessoa_avoM: parentesco=”irmã de Eduviges Dyada”

...

O sistema key-value (assim como o Graph) é muito mais flexível

e permite qualquer informação adicional. Nesse sentido, o
preenchimento parece mais adaptado a variações do que nos
modelos relacionais. Há um problema importante que merece
atenção: a liberdade de modelagem e preenchimento se
misturam durante o abastecimento dos dados. A liberdade de
design é boa para incluir dados inesperados, mas pode ser
perigosa. Informações semelhantes podem ser agrupadas em
etiquetas diferentes e informações diferentes no mesmo rótulo.
E isso pode ser feito por pesquisadores diferentes ou mesmo
pelos mesmos, em momentos diferentes, já que se trata de uma
classificação.

Esse fator pode não ser tão problemático se você quiser

reconstruir a vida de um agente social, mas dificulta agregar
dados seriais e pode gerar séries confusas. As etiquetas podem
ser usadas apenas uma vez para vários valores semelhantes. O
mesmo pode ser dito para um Modelo Graph, pois certos
nódulos podem ser criados para “perder” a informação ao invés
de organizá-la. Nesse sentido, talvez o melhor sistema seja
híbrido: uma tabela de campos regulares para dados regulares e
 147

um banco de dados auxiliar para dados inesperados feitos em

um modelo Graph ou key-value. O sistema de “Detalhe”,
adotado no modelo relacional apresentado acima, buscava
parcialmente a flexibilidade que somente modelos sem
esquema fixo podiam oferecer.

O problema central ao pensar em um banco de dados, quer você

use rótulos ou campos, é como distribuir informações dentro de
certas classes. O desenvolvedor do banco de dados deve pensar
em todas essas questões e, como pode ser visto, elas exigem um
grande conhecimento das fontes e da metodologia da história. A
criação de uma base de dados envolve a associação de
conhecimentos técnicos, teóricos e metodológicos; em suma,
pura ação de pesquisa histórica.

Escrituras públicas

Como vimos, os registros de batismo são um tipo de fonte que

possui dados previsíveis e imprevisíveis. Trataremos, agora, de
uma fonte que possui uma estrutura diferente: a Escritura
Pública. Tal como acontece com os batismos, também se
organizam em livros e esta é uma das regras de produção desta
fonte, uma vez que (supostamente) impediria a alteração da
ordem dos autos, o que teria suscitado dúvidas sobre os
contratos aí lavrados, entre outros problemas potenciais.

As Escrituras Públicas servem para atestar publicamente uma

situação, um acordo, um negócio, etc., em suma, para
documentar algo publicamente. Estruturalmente, as ações
públicas são registradas em sequência dentro de um livro. Isso é
 148

absolutamente rígido e regular. O problema é a natureza de cada

ação. Podem ser de vários tipos: compra e venda, crédito, fiança,
procuração, entre tantos outros que, na verdade, não têm fim,
pois qualquer documento pode ser apresentado em cartório.
Enquanto há alguns tipos que aparecem mais frequentemente,
tudo depende do contexto, período de tempo e local.

Entre alguns dos tipos mais comuns de Escrituras Públicas estão

as procurações, os contratos de compra e venda e as hipotecas.
Agora cabe a nós pensarmos na estrutura interna de cada um
desses documentos, pois são completamente diferentes um do
outro. As “Procurações”, por exemplo, caracterizam-se por
relacionar as pessoas (procurador ou outorgado) com poderes
para atuar em nome de quem solicitou o documento, o
“outorgante”. Este documento poderia assumir várias formas,
embora em geral o mesmo notário usasse e repetisse um
determinado padrão. Começaram com a data e o local da
escritura, informando que o representado se apresentara ao
notário e fora por ele reconhecido e identificado e que
livremente anunciava que pretendia nomear determinadas
pessoas para serem procuradoras. Em seguida, foram listados o
nome ou nomes dos outorgados (com algumas observações
contextuais), muitas vezes sua localização, uma vez que era
razoável atribuir poderes a pessoas que pudessem atuar em
nome do outorgante em outro lugar. Também foi especificado
quais eram os poderes, totais ou parciais, e se eram para todos
ou se cada pessoa tinha poderes diferentes.

Vejamos o caso de procurações, tendo em mente uma estrutura

de banco de dados relacional. A tabela “Procurações” ficaria
subordinada à tabela “Livro” que conteria os dados do livro e
 149

estaria vinculada a outras tabelas, conforme o tipo de escritura.

Os campos da tabela “Livros_de_notas” seriam estes:

TABELA "LIVROS_DE_NOTAS"

CAMPO TIPO OBS

Código_registro* Texto Máximo 12 carac.
Notário Texto Livre
Número do livro Texto Livre
Página Texto Livre
Observações Texto Livre

Os campos da tabela “Procurações” seriam estes:

TABELA "PROCURAÇÕES"

CAMPO TIPO OBS

Código_registro* Texto Máximo 12 carac.
Data Texto Livre
Lugar Texto Livre
Outorgante Texto Livre
Outorgado Texto Livre
Poderes concedidos Texto Livre

Agora, consideremos um contrato de compra e venda.

Geralmente, iniciam-se de forma semelhante aos registros de
Procuração, pois é um registro público que registra a hora e o
local e deve ser feito de forma voluntária pelas partes que
procuram o cartório para se manifestarem. Depois, temos as
partes, comprador e vendedor, que podem ser indivíduos ou
 150

pequenos grupos (muitas vezes casais). A propriedade em

transição é descrita e o preço acordado é registrado. Dado este
cenário, um modelo relacional para este tipo de documento
seria assim:

TABELA “CONTRATOS”
CAMPO TIPO OBS
Código_registro* Texto Máximo 12 carac.
Data Texto Livre
Lugar Texto Livre
Parte 1 Texto Livre
Parte 1 - papel Texto Opção (comprador ou
vendedor
Parte 2 Texto Livre
Parte 2 - papel Texto Opção (comprador ou
vendedor
Descrição Texto Livre
Preço Número Livre

Embora esses sejam apenas dois exemplos dos documentos

encontrados nos livros de Escrituras, eles são indicativos das
outras fontes registradas nesses livros. Usando essas fontes
como exemplo, é possível entender como um modelo relacional
funcionaria para este tipo de documentação. De acordo com a
lógica SQL (relacional), as numerosas variações dos documentos
seriam classificadas em diferentes tabelas moldadas de acordo
com a morfologia de cada fonte.

As bases de dados relacionais parecem caracterizadas para lidar

com essas fontes, pois respeitam o fato das fontes possuírem
especificidade e idiossincrasias. Porém, para poder observar, por
exemplo, o mesmo personagem fazendo negócios diferentes nas
 151

fontes, seria necessária uma série de relações entre as tabelas

que seriam muito difíceis de criar e, uma vez criadas, para serem
compreendidas por outros usuários e talvez até mesmo pelo
criador do banco de dados, porque envolve uma grande
quantidade de relacionamentos. Do ponto de vista do cartório,
são todos “Escrituras”, mas são, na verdade, completamente
diferentes entre si. Diante desse cenário, o modelo relacional
seria o mais adequado para essas fontes?

A resposta a esta pergunta dependerá do pesquisador, da

pesquisa e da maneira como ele a concebe. Talvez usar um
banco de dados relacional seja produtivo, já que ele tem outros
bancos de dados com os quais sua base pode se conectar e isso
seria um bom motivo para continuar usando o design relacional.
No entanto, talvez a melhor maneira de pensar sobre essa
origem seja por meio de modelos como o key-value, graph ou
orientado a documento.

Talvez o modelo orientado a documentos seja o mais adequado.

O mais importante é que é feito à medida para documentos de
natureza diversa, respeitando as suas especificidades. Os
poderes e contratos de compra e venda têm um alto grau de
regularidade e podem até caber em uma tabela relacional, mas
há uma grande chance de que informações inesperadas possam
surgir e serem ignoradas. Alternativamente, exigiria a criação de
novos campos.

No caso de modelos orientados a documentos, a criação de

novos campos seria muito mais simples e podia ser mais
facilmente adaptada às necessidades do pesquisador. Claro, isso
traria riscos, como vimos acima, mas o historiador deve estar
ciente disso. A capacidade de criação de campos é
imprescindível no caso de Escrituras Públicas, visto que existem
 152

inúmeros documentos potenciais que poderiam ser registrados

em cartórios, que seriam menos estruturados do que
procurações e contratos e, portanto, dependeriam de campos
ou etiquetas inesperadas.

"escrituraPublica": {
"id" : "00731",
"create_time" : "2019-12-21T11:11:11Z",
"last_update" : "2019-12-23T12:12:12Z"
},
"tipo": "Compra e venda de terras",
"pessoa": {
"Nome" : "August Dupin",
"Papel" : "Comprador",
},
"pessoa": {
"Nome" : "Anna Blume",
"Papel" : "Vendedor",
},
"propriedade": {
"Tipo" : "Fazenda",
"Preço" : "50000,00",
“Moeda” : “maravedis”,
"Descrição" : "Uma bela fazenda de produção de sorgo",
"Localização" : "Entre o Rio Amarelo e o Oceano Índico",

},

As vantagens do modelo orientado a documentos, neste caso,

são várias, considerando este tipo de fonte. É preciso estar
muito atento ao design e pensar muito sobre as maneiras de
recuperar as informações posteriormente. Neste caso, a opção
 153

acima foi criar uma etiqueta “pessoal” para indicar todos os

participantes que estivesse vinculada à sua função, seja o
comprador ou o vendedor. Uma alternativa seria criar a etiqueta
"vendedor" e "comprador", criando outro "papel" para cada
tipo. Isso poderia ser interessante e enfatizaria os papéis
desempenhados. No entanto, tudo depende do problema de
pesquisa e da forma como o pesquisador pretende fazer as
perguntas. Todos os modelos envolvem opções e decisões e os
critérios para isso devem partir das opções teóricas e
metodológicas (em história) e das capacidades técnicas dos
modelos escolhidos, bem como da forma como os dados foram
estruturados.

Correspondências

Vimos que as correspondências podem ser entendidas como um

tipo de fonte sem estrutura, diferentemente dos batismos. Isso
não quer dizer que não possamos fazer bases delas. O que não
podemos é forçar uma estruturação onde não há. As
correspondências sequer têm uma forma padronizada de
preservação, como os livros, no caso dos batismos. A única coisa
que garante a especificidade do gênero é sua ampla utilização
nos últimos séculos, ainda que seja imemorial. Há alguma
bibliografia sobre esse tipo de fonte, ainda que não seja tão
vasta quanto aquela dedicada aos registros paroquiais e há
inúmeros estudos que usam este tipo de fonte, mas sempre
dando um tratamento semelhante a livros, inclusive com a
publicação de séries de correspondências.

O que é realmente regular ou esperado são informações como

“remetente”, “destinatário”, “data”, “local do remetente”, “local
do destinatário” e o “texto da carta”. Com isso faremos nossa
 154

base. Poderíamos acrescentar outros campos por capricho para

aproveitar bem mais a fonte: “pessoas citadas”, “locais citados”
e “temas”. São três campos que evidenciam a intervenção direta
do historiador, mas sem perturbar a fonte. Poderíamos também
acrescentar um campo para incluir o período que a carta cobre,
se faz referência a coisas passadas ou expectativas futuras,
campos para resumo, recortes e outro para identificar recursos
discursivos utilizados. Assim, estaríamos desmontando de forma
mais adequada a fonte, como devemos fazer. Vejamos:

TABELA “CORRESPONDÊNCIAS”

CAMPO TIPO OBS

Remetente Texto Livre
Local do remetente Texto Livre
Destinatário Texto Livre
Local do destinatário Texto Livre
Data Data ou texto AAAA-MM-DD
Texto da carta Texto Livre
Código_carta Texto Livre

Campos opcionais que podem ser úteis:

CAMPO TIPO OBS

Pessoas citadas Texto Livre
Locais citados Texto Livre
Temas Texto Livre ou caixa de
opções
Período abarcado Texto Livre
Resumo Texto Livre
Recortes Texto Livre
Recursos discursivos Texto Livre

Haveria, ainda, outra possibilidade: a de criar um campo

 155

adicional para recolher dados sobre outras cartas mencionadas

na própria carta. Isso seria interessante porque, muitas vezes, as
cartas são respostas a outras anteriores, que por sua vez foram
respostas de outras mais e isso é freqüentemente mencionado
(“Respondo por esta a sua do dia...” ou fórmulas semelhantes).
Com esse controle, podemos ver o tempo de resposta entre uma
carta e outra e observar uma série delas. Quase uma conversa
entre duas pessoas. Para isso, bastaria o campo “em resposta à
carta de” e, talvez, um campo de cálculo que medisse a
diferença entre as duas datas, ainda que possa ser feito em uma
planilha, uma vez exportados esses dados, o que já facilitaria a
preparação de um gráfico. Contudo, nem sempre a carta
responde a apenas uma original. Pode ser o caso de, analisando
a documentação, percebermos que há missivas que respondem
a duas ou três anteriores que são claramente mencionadas.
Neste caso, não basta um campo de "em resposta à carta de...".
É preciso criar outra tabela que contenha aquele campo e as
datas das originais e da atual.

Até agora, a ênfase tem sido na catalogação das cartas e não em

seu conteúdo. Para o conteúdo, as bases relacionais são
claramente insuficientes. As possibilidades contidas em uma
carta são infinitas e sem qualquer estrutura previsível. Elas
podem usar metáforas, ou não; podem ser curtas ou longas;
podem ser confusas ou claras; podem citar agentes sociais ou
não; podem conter ideias ou questioná-las. É impossível criar
um único esquema que possa capturar todas essas
possibilidades. Mesmo para o modelo orientado a documentos,
é difícil lidar com correspondências. Isso ocorre porque uma
deficiência desse modelo está no fato de que não podemos
atribuir dois rótulos ao mesmo valor. Se encontrarmos um
trecho de texto ambivalente, por exemplo, que permita
 156

interpretações divergentes ou várias classificações, não seremos

capazes de resolver isso no modelo orientado a documentos.
Nesse caso, os melhores modelos são o Graph e key-value, pois
poderíamos desmontar completamente o texto, palavra por
palavra, dando múltiplos significados a cada fragmento.

Fontes dialógicas

Tomei a expressão "dialógicas" do texto “O inquisidor como

antropólogo” de Carlo Ginzburg.72 Serve para designar as fontes
que foram produzidas a partir de um diálogo, como
interrogatórios da igreja ou da polícia. É claro que são frutos de
épocas muito diferentes, mas o que faz Ginzburg aproximá-las é
que elas têm uma estrutura semelhante e tendem a formar corpi
documentais mais organizados do que as correspondências e
formar séries completas, tanto nos locais onde são produzidas
quanto nos Arquivos. Há muitos estudos sobre esse tipo de
fonte, ainda que a maioria dos trabalhos que as utilizem não
faça nenhuma reflexão sobre sua produção. A produção dessas
fontes segue um ritual semelhante, com a instauração do
processo, que é transcrito do início ao fim (com ausências,
talvez, mas com um início e um final). É regular também o fato
de haver depoimentos em série e, para cada caso particular,
uma lista de perguntas que foram feitas aos interrogados. Ou
seja, temos duas camadas de regularidades: uma própria da
fonte, com o processo, os depoimentos e as listas de perguntas;
outra, própria de cada conjunto, com a lógica própria das
perguntas, de acordo com a dinâmica do processo, com o

72
GINZBURG, Carlo, O inquisidor como antropólogo: uma analogia e as suas
implicações, in: Micro-história e outros ensaios, [s.l.: s.n.], 1989.
 157

momento de sua produção e com o caso em questão.

Precisamos, então, de uma tabela para o processo na qual

haverá campos como “data inicial” e “data final”, além de uma
súmula do caso, de uma lista de acusados e de testemunhas. É
certo que dados mais básicos serão necessários, como o local do
inquérito e os nomes dos investigadores e dos juízes. Nesse
caso, seria importante ter informações sobre cada uma das
instâncias pelas quais passou, sabendo que é recorrente que
haja hierarquias na Justiça desde longo tempo. É bem verdade
que nosso processo pode ter sido arquivado na origem, numa
delegacia de interior, mas o simples fato de pensarmos que
poderia ter tido uma longa trajetória, mas que não teve, já nos
faz aprimorar nossa reflexão sobre a fonte e o problema
histórico em si. Era normal ser arquivado ou foi uma decisão
arbitrária? Quais os trâmites mais recorrentes? São questões
que colocamos diante da demanda por organizar nosso material
em caixinhas (campos) de uma tabela.

A primeira coisa a descobrir é o fluxograma possível do

processo, o caminho do inquérito do início ao final. Isso varia de
acordo com o contexto. É preciso também saber se há diferenças
entre essas instâncias, no que toca ao processamento dos casos.
Se não houver, basta uma tabela “Processos”, na qual podemos
marcar com um campo “sim ou não” todo o caminho possível de
um caso. Isto resolveria. Deste modo, cada interrogatório seria
colocado em uma tabela relacionada chamada “interrogatórios”,
uma vez que cada processo pode ter n sessões de perguntas, ou
diálogos, para manter o vocabulário. E como o número de
perguntas também é sempre n, seria importante criar uma
tabela “Perguntas”, que teria, além do campo “código”, os
 158

campos “pergunta” e “resposta”.

A organização de processos pode beneficiar-se de uma estrutura

relacional ou mesmo hierárquica, uma vez que as respostas
estão relacionadas a uma pergunta e ambas estão em diálogo.
Dentro de um processo, o mesmo não pode se dizer do
conteúdo das respostas, que podem ter incontáveis variações.
Neste caso, entramos na mesma lógica das cartas, quando o
número de campos e/ou etiquetas potenciais necessários para
classificar o conteúdo escrito ou transcrito é imprevisível.

Novamente, os modelos graph e key-value mostram-se

interessantes, embora o design da base de dados orientada a
documentos não seja de todo descartável no caso de fontes
dialógicas. Embora seu conteúdo seja imponderável, existem
certos tópicos e temas que dizem respeito ao crime em questão
e, presume-se, devem ser repetidos entre os depoimentos.
Espera-se que certos assuntos apareçam e, embora as
explicações possam variar muito, os temas possam se repetir.
Neste caso, o sistema de etiquetas dos modelos orientados a
documentos pode ser bastante interessante.

Parece-me não ser preciso repetir as tabelas com os dados

organizados, como fiz com o exemplo dos batismos e das cartas.
Neste momento, o leitor já pode bolar o próprio esquema a
partir das reflexões iniciais aqui apontadas. O importante é não
simplificar aquilo que merece desdobramentos. Nosso trabalho
de historiador já é uma simplificação. Colocar em bases de
dados, idem, mas é uma simplificação que organiza. Não
precisamos simplificar mais e nem temos motivo para isso,
porquanto temos ferramentas que nos permitem tratar as fontes
com cuidado.
 159

Bases centradas no método

No capítulo 1 vimos algo sobre o sistema "Fichoz". Trata-se de

um bom exemplo de base de dados method-centred que, apesar
de não permitir a incorporação integral de fontes, permitia o
desdobramento de interações sociais (descritas nas fontes) em
uma grande diversidade de pedaços reagrupáveis conforme a
necessidade. No caso da base "Fichoz", a possibilidade de
desmontar as fontes é tão grande que, dependendo da
obstinação do pesquisador, nem seria tão perigoso ficar sem
elas. Seria, ainda, relativamente fácil reutilizar a base, tendo em
vista sua plasticidade diante de inúmeras metodologias
conhecidas na atualidade. Como sou um defensor das bases
source-centred, tenho receio de recomendar bases centradas no
método, mas entendo que, quando bem feitos, esses bancos de
dados são preciosos. Vejamos alguns exemplos de metodologias
e como seria a criação de bases com essa perspectiva.

Prosopografia

Assim como é preciso conhecer a fonte para fazer uma base

centrada nelas, é preciso conhecer bem a metodologia. Para a
prosopografia, por exemplo, é fundamental conhecer o clássico
de Lawrence Stone sobre a aristocracia inglesa73, assim como
seu artigo de 1971, que já apresentamos no início desta obra. Há
outros livros importantes, inclusive muitas coletâneas nacionais,
mas seria muito longo apresentar todas aqui. Isso é uma tarefa
do “desenvolvedor” da base, que deverá tomar essas referências

73
STONE, The Crisis of the Aristocracy, 1558-1641.
 160

em conta.

Sabemos que prosopografia é a biografia de um grupo, que pode

ou não ser homogêneo, e que é preciso ter uma ferramenta com
a qual possamos armazenar os dados de tal maneira que
consigamos utilizar a base circulando entre os indivíduos e o
grupo. A prosopografia já previa uma variação de escala (pelo
menos duas) muito antes de esse assunto entrar com força no
debate historiográfico a partir da micro-história. Será o caso de
termos duas bases, uma para o grupo e outra para os agentes?
Devemos ter uma “ficha” para cada personagem, com sua data
de nascimento, de casamento, de morte, etc.?

Já vimos um modelo interessante para a prosopografia, a mesma

base “Fichoz”, de Jean-Pierre Dedieu. Ela não tinha fichas
individuais e sua concepção era totalmente oposta a esse
sistema. A ideia, como já vimos, era de desmembrar a vida das
pessoas em eventos para que pudessem ser reagrupados depois
em forma de uma biografia (numa busca pelo sujeito) ou por
meio de algum outro critério. Com a mesma base, seria possível
relacionar o acontecimento com outras pessoas, permitindo
análises de redes. Isso foi possível porque, mesmo sem
demandar inicialmente este tipo de análise, tal possibilidade foi
pensada no início da construção da base. O modelo conceitual
da base “Fichoz” parece-me muito adequado aos estudos
prosopográficos e seria difícil criar um sistema mais eficiente e
flexível. Não é preciso ter uma cópia desse sistema para
reproduzir seu conceito. Basta conhecer sua descrição e aplicá-la
com os devidos créditos.74

74
DEDIEU, Les grandes bases de données: une nouvelle approche de l’histoire
sociale. Le système Fichoz.
 161

Um sistema de fichas individuais poderia ser uma boa saída, mas

possui limites difíceis de contornar. O primeiro é a montagem da
história de vida da pessoa. Como desdobrá-la de modo
cronológico? Mesmo que não nos agrade a cronologia, será que
nunca precisaremos dela? Nunca teremos algum
comportamento humano marcado pelo ciclo de vida, como
idade para casar, idade para entrar no mundo do trabalho, idade
para ser deputado, etc.? Outro limite é que, para cada campo,
precisaríamos de outro correlato para a fonte que usamos para
preencher aquele campo. Por fim, deveríamos ter um campo
“profissão” até para aqueles que nunca tiveram uma? Um
campo de matrimônio mesmo para quem nunca se casou? É
verdade que importa perceber as ausências, o que só seria
possível sem um campo que exigisse isso de todos.

No caso das bases de dados prosopográficos, qual seria o melhor

modelo? Relacional? Graph? key-value? Vou propor uma
sugestão muito mais singela: tabelas simples. Como já vimos, é
um sistema muito primitivo, composto apenas por uma tabela
com registros e campos. No entanto, se tomarmos outros
modelos como inspiração, conseguimos criar uma base muito
complexa, que pode permitir consultas muito interessantes.
Podemos criar uma tabela baseada no sistema Fichoz, criando
registros para cada evento em uma vida individual. Esses
eventos teriam uma data, um local, um agente social e um papel
atribuído a esse mesmo agente. Da mesma forma, cada registro
também teria um segundo agente social, com o qual o primeiro
estaria interagindo. Se o evento envolve vários personagens,
devemos “desmontar” o acontecimento em vários registros, aos
pares.
 162

Análise demográfica (“Método Henry”)

Criado ao longo dos anos 1950 como um caminho para os

estudos demográficos de épocas conhecidas como
“pré-estatísticas”, quando não havia o registro sistemático de
dados sobre as populações, o Método Henry formou gerações
de pesquisadores e outras tantas escolas de estudos
demográficos, de Cambridge ao Minho. A proposta era
relativamente simples: se não dispomos de estatísticas oficiais
para os séculos passados, juntemos todos os registros de
batismo, casamento e óbito e tentemos reconstituir as famílias
dessas épocas por meiodo cruzamento dos dados. Trabalho sem
fim! E tudo isso usando fichas de papel. O tempo passou e
somente em 1968 surgiu o primeiro grande resultado da
proposta: a tese de Pierre Goubert sobre Beauvais.75 Desde
então, foram feitos muitíssimos acréscimos à concepção original,
variações, inclusive, softwares variados para aplicar o famoso
método.76

Para criar uma base de dados em que se utilize o Método Henry,

o ideal seria começar com três bases de fontes: uma para os
batismos, uma para os casamentos e outra para os óbitos.
Adaptações posteriores do método, feito pelo próprio Henry
para o caso do Brasil, permitiriam uma quarta base, para as listas
nominativas.77 E isso não significa ignorar a opção de quem

75
GOUBERT, Pierre, Cent Mille Provinciaux au XVIIe Siècle. Beauvais et le
Beauvaisis de 1600 à 1730, Paris: Flammarion, 1968.
76
Na Universidade do Minho (NEPS), por exemplo, foi criado o MRP, baseado
nas variações desenvolvidas por Maria Norberta Amorim. AMORIM, Maria
Norberta et al, Reconstituição de paróquias e formação de uma base de dados
central, in: , Castelo Branco: [s.n.], 2001.
77
HENRY, Louis, Técnicas de análise em demografia histórica, Curitiba: UFPR,
1977.
 163

prefere trabalhar sem bases source-centred. A questão é que o

próprio método prevê o tratamento diferenciado para cada
fonte. O passo seguinte envolve unicamente abordagens
method-centred.

É preciso criar algumas tabelas e muitos campos para dar conta

dessa metodologia. Parece-me adequado pensar em pelo menos
três tabelas: localidade, família e indivíduo. Localidade, porque
convém pensar que a base poderá ser utilizada para diferentes
localidades, vizinhas, talvez, ou mesmo muito distantes (para
estudar migração, por exemplo); família, por ser a unidade
doméstica o centro do método e indivíduo permitirá isolar os
casos e informar suas datas de nascimento, casamento e morte.
Da mesma forma, não podemos prever quantas pessoas
formarão a família. O número de membros é, logo, sempre n.

Se temos todos os dados organizados adequadamente nas bases

de casamento, óbito e batismo, basta exportar todos os pares de
pai e mãe, no caso dos batismos, e de noivos, nos casamentos.
Feito isso, basta eliminar os duplicados e teremos todos os
casais disponíveis naquela amostra. Convém fazer uma
varredura para encontrar problemas com nomes. Por exemplo, a
Rita Maria de Oliveira, casada com Raimundo da Silva, pode ter
sido incorretamente transcrita como Rosa Maria de Oliveira, por
conta de um nome borrado. Um bom estudo da nossa lista
resultante da exportação pode resultar em muitas correções
necessárias.

Como nossos dados estavam organizados e já foram corrigidos,

basta relacionar nossa nova tabela com as bases de casamento e
de batismo para que tragam informações complementares que
formarão a ficha de cada uma das famílias. Esse é um
 164

procedimento bem menos trabalhoso do que digitar novamente

todos os casos. É melhor gastar esse tempo revisando, o que
deveria ser feito de qualquer jeito. Assim, já temos a tabela das
famílias, formada por campos como “pai” e “mãe”, basicamente,
além de campos que criem relacionamento com as localidades,
com as famílias e com as fichas individuais. A tabela
“localidades” terá os dados do conjunto que serão herdados por
todas as famílias e todos os indivíduos.

Assim, resta criar a tabela “indivíduos”, o que poderá ser feito a

partir dos batismos, exportando separadamente todos os pais,
mães, padrinhos e madrinhas, além da criança, claro. A
exportação dos dados dos avós é ponto de reflexão, pois em
comunidades jovens, recém-criadas, por exemplo, eles não
costumam estar presentes. Porém, pode ser relevante se assim
for acordado pela equipe. Convém exportar esses dados junto
com outros “estruturantes” da informação, como o nome do
casal, a data, localidade e o código-fonte. No caso dos
batizandos, deve-se exportar também a data de nascimento, se
disponível, além da do batismo. Deste modo, cada indivíduo será
associado a um casal, mas também a uma localidade, dadas as
outras relações, como o compadrio. Para relacionar os óbitos,
será preciso criar o relacionamento a partir do nome.

Com esses procedimentos, teremos um sistema complexo de

análise de famílias que permitirá diversos outros cruzamentos,
de tal maneira que possamos saber o intervalo intergenésico e
os compadrios, as famílias sem pai, entre uma multiplicidade de
outros fenômenos sociais. No entanto, é preciso que fique claro
que isso só será possível com boas bases de fontes que darão
algum trabalho, mas que valerão a pena. Feito isso, teremos
condições de automatizar um bocado nosso esforço, de tal
 165

maneira que muito do que será necessário já estará feito. A

automação e a criação de tabelas de família ajudarão a revisar o
material previamente abastecido. Gasta-se tempo na
preparação, mas, no momento da análise, os dados estarão
disponíveis em poucos cliques.

Análise de redes sociais

Os estudos de análise de redes sociais surgiram entre os anos de

1950 e 1960 com o trabalho pioneiro de Elizabeth Bott e as
pesquisas de Mitchell, Boissevain e Barnes. É uma metodologia
que enfatiza as interações humanas como objeto primordial de
análise e destaca os tipos e as formas dos laços criados e
mantidos por determinadas unidades de análise (que podem ser
pessoas, empresas, cidades ou palavras) e como estas relações
podem interferir no comportamento e nas escolhas dessas
unidades.78
Talvez a maior justificativa para o uso dessa metodologia, além
das questões epistemológicas atinentes, seja a possibilidade de
visualizar matrizes e gráficos que destacam com clareza os
vínculos entre as partes e observar aspectos não perceptíveis
por outros caminhos. Cada matriz e seu gráfico correspondente
apresentam um instantâneo dos vínculos de um grupo. O gráfico

78
MITCHELL, J. Clyde; BOISSEVAIN, Jeremy, Network analysis. Studies in
Human Interaction, The Hague/Paris: Mouton, 1973; MITCHELL, J. Clyde, Social
Networks, Annual Review of Anthropology, v. 03, p. 279–299, 1974; BARNES,
J. A., Networks and political process, in: MITCHELL, J. Clyde (Org.), Social
Networks in urban situations: Analysis of personal relationships in Central
Africa Towns, Manchester: The University Press, 1969; BOTT, Elizabeth, Família
e rede social. Papéis, normas e relacionamentos externos em famílias
urbanas comuns, Rio de Janeiro: Francisco Alves, 1976.
 166

é formado por nós (que representam as unidades), linhas (que

simbolizam as relações) e setas (que indicam os sentidos das
ligações). De acordo com as informações sobre esses elementos,
os desenhos e as cores do conjunto podem variar, indicando
agrupações ou especificidades de certas unidades ou laços. Para
a criação desses gráficos, existem softwares interessantes e
práticos como o Gephi e o Ucinet.
Preparar bases de dados para esse tipo de estudo demanda
tabelas com as quais se possam destacar as relações entre as
partes, ou seja, coletar dados sobre os personagens associados
"em duplas" por tipo de relação. É certo que, muitas vezes,
temos grupos que ultrapassam as duplas, mas eles devem ser
desmontados aos pares, até que todos tenha relação com todos,
pois, somente assim, será possível destacar esses vínculos
dentro de uma matriz. No caso hipotético de um grupo de
pessoas, temos um cenário onde quase todos se conhecem.
Paulinho, por exemplo, conhece todos, mas a forma de
representar isso nas análises de redes sociais requer que eu
apresente os dados destacando com 1 ou 0 (1 = conhece; 0 =
não conhece), quem é amigo de quem, ou seja, dupla por dupla.

Figura 27 - Matriz matemática das relações de um grupo

 167

Figura 28 - Gráfico de rede criado com a matriz acima indicada

Assim, basta criar uma tabela em que se organizem os dados

com essa estrutura e tudo ficará resolvido. No caso de registros
de batismos, por exemplo, seria preciso decompor as relações
de compadrio aos pares: pai com padrinho, pai com madrinha,
mãe com padrinho, mãe com madrinha. Mas não basta só
exportar os dados de uma base paroquial para um programa de
análise de redes, porquanto as interações se repitam (um
mesmo sujeito pode ser compadre de outro por várias vezes,
por exemplo) e é preciso ter esse controle e certificar a
qualidade dessas relações. Com isso, podemos colocar, ao invés
de 1 ou 0, vários números, para indicar a repetição dos laços ou
a qualidade deles - se de compadrio, de amizade, de vizinhança,
etc. Quase todos os programas permitem apresentar isso
visualmente.

Seriais

Um sistema para fontes seriais ou seriáveis já seria, por si só,

source-centred, pois, na maioria das vezes, quantificamos uma
fonte única. Somente bens de inventários, por exemplo, ou
 168

apenas os registros de compra e venda de alguma localidade.

Contudo, algumas bases não são feitas com uma fonte única.
Não significa que sejam ruins. A base Slave Voyages, da Emory
University, é um bom exemplo. Ela foi realizada com fontes
bastante diversas que mereceriam amplas críticas. Mas, fazendo
isso, a base não ficaria pronta nunca e jamais teríamos ideia do
volume de pessoas forçadas a cruzar o Atlântico.

Em alguns casos - e isso vai depender do planejamento da

equipe - pode ser preciso criar uma base serial que não esteja
vinculada a uma única fonte primária. Que seja um mosaico
deformado, mas que nos apresente uma imagem, ao menos
borrada do que queremos saber. Para esse tipo de abordagem,
valem alguns aspectos que já pontuamos: planejamento,
discussão, experiência com a base e testes. Isso pode garantir
um bom desenvolvimento. Contudo, é preciso fazer como os
coordenadores do Slave Voyages e como nos diria Marc Bloch: é
preciso ter critério. Não há bom senso em História. Se
definirmos bons critérios, nossa base terá coerência e será útil.
Mas o problema não se resolve aí. Lembremos-nos do debate
iniciado em 1965 com Adeline Daumart: nossas hipóteses
mudam ao longo da pesquisa (e, muitas vezes, elas devem
mudar) em virtude das próprias descobertas feitas no seu
desenrolar. Essas são questões sobre as quais a equipe deverá
refletir.

Qual seria o modelo mais apropriado para a história

quantitativa? Planilhas geralmente são suficientes e permitem
vários cálculos e análises, dada a forma como os dados são
organizados. Muitos software preferidos pelos profissionais
quantitativos usam arquivos simples ou modelos relacionais,
como os pacotes "SPSS" e "R", apenas para citar um software
 169

tradicional e um pacote de ferramentas novo e bem-sucedido.

Outros modelos, como key-value e graph, embora cada vez mais
tenham recursos de agregação, não foram projetados para isso.

Bases de dados multitarefas: o sistema Malta

Até agora, vimos bancos de dados que se concentram em

métodos muito específicos. Em geral, a realidade da pesquisa
não pressupõe a aplicação de técnicas específicas, mas a
combinação de diferentes metodologias. Pretendo agora
apresentar um modelo de banco de dados que buscou integrar
várias abordagens para responder a uma questão de pesquisa
sobre as relações de crédito no final do século XVIII em uma
economia colonial periférica, com práticas de Ancien Régime.
Este exemplo nos ajuda a entender algumas das opções teóricas
que nortearam a construção do banco de dados. Em primeiro
lugar, entendemos que as relações pessoais, familiares e
políticas foram importantes na consolidação dos processos
econômicos. Nesse sentido, a trajetória dos agentes sociais, suas
interações anteriores e sua rede de relacionamento foram
fundamentais para o entendimento de suas decisões
empresariais.

A base de dados principal, denominada MALTA, foi construída

levando em consideração a proposta de Jean Pierre Dedieu, de
fragmentar a vida em acontecimentos para, então, agrupá-los de
diferentes maneiras. A ideia era que também fosse possível
inserir dados quantitativos de diferentes fontes que pudessem
ser agrupados, mas também tomados como fragmentos das
histórias de vida das pessoas que os elaboraram. Da mesma
forma, era importante ter fontes específicas e eventos únicos ao
lado de processos reiterativos. Falando mais claramente, o
 170

objetivo era observar eventos únicos (uma briga de bar, por

exemplo) e eventos regulares (casamentos, acordos de compra e
venda, etc.) na mesma consulta, na busca por um determinado
personagem e para sua interação com outros.

Para possibilitar o entendimento, foi criado um campo

denominado “evento”, que classifica cada ato de forma que seja
possível realizar diferentes questionamentos, como vimos acima
no exemplo da prosopografia, mas com maior versatilidade, pois
poderia integrar dados quantitativos. O mesmo evento pode ser
descrito duas ou mais vezes. Para incluir registros com vistas à
classificação, indicamos no campo “evento” o tipo de fenômeno
reiterativo de que estamos tratando. Assim, os dados mais
interpretativos são combinados com os dados mais
quantificáveis, mas sujeitos à separação pelos critérios de
“rotulagem” utilizados.

Além de criar um campo “evento”, em descompasso com a

proposta da Dedier, também foram criados os campos “papel do
agente'' e “papel do interlocutor”, onde atribuímos exatamente
um “papel ”a cada agente em cada agir. Como o mesmo evento
pode ser repetido mais de uma vez, cada ação é duplicada de
forma a atribuir a cada participante uma determinada agência,
partindo do pressuposto de que um evento não tem o mesmo
significado para todos os seus participantes. Assim, cada evento
é visto de pelo menos duas maneiras diferentes e, em alguns
casos, pode ter várias versões. O formato do banco de dados foi
construído para permitir essas manobras. Existem também
outros dois campos, criados para coletar informações sobre
como os agentes foram qualificados em seu tempo (como
Capitão, forro negro, proprietário): os campos
"qualificação_agente" e "qualificação_interlocutor".
 171

Definir a qualificação do agente social foi fundamental, pois a

forma como as pessoas eram descritas (e publicamente
avaliadas) era uma das variáveis que vinha sendo investigadas e
sua variação no tempo era objeto de grande atenção. Da mesma
forma, as interações com diferentes agentes sociais forneceram
material organizado para diferentes análises, quantitativas,
agregadoras ou qualitativas. O mesmo pode ser dito sobre o
papel de cada agente em cada ato, pois as posições de credor e
devedor podem (e devem) variar ao longo do tempo e as formas
desse fenômeno podem ser muito significativas em termos de
processos sociais ao longo do tempo.

O banco de dados de Malta usa várias formas de visualização.

Por se tratar de um banco de dados relacional, é possível, por
exemplo, visualizar todos os fatos de um sujeito em um canto da
tela, enquanto, ao mesmo tempo, é possível verificar todos os
eventos e atos que envolveram seus interlocutores, um a um.
Este mecanismo é possível graças à relação que a base de dados
mantém consigo mesma, que permite múltiplas referências
cruzadas. Também é possível obter a biografia simples de um
assunto, decomposta em registros, ou série específica de
determinado evento, acordos de compra e venda, casamentos,
entre outros.
 172

Figura 29 – Base de dados “Malta”

Outra tabela que faz parte do sistema é denominada “AGENTES”.

Trata-se uma lista de todos os assuntos mencionados na base de
dados principal. Para vincular as duas bases de dados de modo a
permitir buscas rápidas, foi criado um cadastro para cada
personagem. Dessa forma, é possível separar os homônimos e
organizar melhor os dados de cada ator. Além do nome e do
número do registro, existem os campos “sexo”, “data de
nascimento” e “observações” que servem para melhor
identificar os agentes. O campo “data de nascimento” está
diretamente vinculado à base principal para que possamos saber
a idade de cada agente em cada ato, diretamente.

Toda a discussão que tivemos até agora é uma questão básica de

pesquisa histórica: uso de diferentes metodologias, organização
sistemática de informações, dados de referência cruzada, etc. O
mais interessante que foi exposto até agora é pensar sobre a
articulação de diferentes metodologias de forma orgânica, em
 173

que as diferentes abordagens possam utilizar uma única recolha

e organização de dados, de forma a evitar discrepâncias. Em
geral, cada método requer uma organização diferente dos
dados. Neste trabalho, boa parte da riqueza de cada informação
é perdida, quando não desfigurada. Nesse sentido, um sistema
que mantenha forte controle sobre esse manejo pode contribuir
muito para o desenvolvimento geral da pesquisa.
 174

Bibliografia
ADELINE DAUMARD. Structures sociales et classement
socio-professionnel. L’apport des archives notariales au XVIIIe et
au XIXe siècle. Revue Historique, v. 86, n. CCXXVII, 1962.

ADELINE DAUMARD. Une référence pour l’étude des sociétés urbaines

en France aux XVIIIe et XIXe siècles projet de code
socio-professionnel. Revue d’Histoire Moderne et
contemporaine, v. X, p. 185–210, 1963.

AMORIM, Maria Norberta; FERREIRA, Antero; RODRIGUES, Fátima; et

al. Reconstituição de paróquias e formação de uma base de dados
central. In: Castelo Branco: [s.n.], 2001.

AUTRAND, Françoise. Le personnel du parlement de Paris: traitement

automatique d’une prosopographie en vue d’une étude sociale.
In: FOSSIER, Lucie; VAUCHEZ, André; VIOLANTE, Cinzio (Orgs.).
Informatique et histoire médiévale. Roma: École Française de
Rome, 1977, p. 239–243.

BARNES, J. A. Networks and political process. In: MITCHELL, J. Clyde

(Org.). Social Networks in urban situations: Analysis of personal
relationships in Central Africa Towns. Manchester: The University
Press, 1969.

BOTT, Elizabeth. Família e rede social. Papéis, normas e

relacionamentos externos em famílias urbanas comuns. Rio de
Janeiro: Francisco Alves, 1976.

BRUCHEZ, Rudi. Les bases de données NoSQL et le

BigData: Comprendre et mettre en oeuvre. Editions
Eyrolles, 2015

BUSA, Roberto. The Annals of Humanities Computing: The Index

Thomisticus. Computers and the Humanities, v. 14, p. 83–90,
1980.

CARVALHO, Joaquim. Soluzioni informatiche per microstorici. Quaderni

Storici, v. XXVI, n. 03, 1991.
 175

CHARLE, Christophe. Problèmes de traitement informatique d’une

enquête sur trois élites en 1901. In: MILLET, Hélène (Org.).
Informatique et prosopographie. [s.l.]: CNRS, 1985.

DE CERTEAU, Michel. A operação histórica. In: LE GOFF, Jacques; NORA,

Pierre (Orgs.). História: novos problemas. São Paulo: Livraria
Francisco Alves Editora, 1978.

DE VRIES, Jan. Population. In: BRADY JR., Thomas; OBERMAN, Heiko;

TRACY, James (Orgs.). Handbook of European History 1400-1600.
Late Middle Ages, Renaissance and Reformation. Leiden / New
York / Koln: E. J. Brill, 1994.

DEDIEU, Jean Pierre. Les grandes bases de données: une nouvelle

approche de l’histoire sociale. Le système Fichoz. Revista da
Faculdade de Letras- História, v. 05, 2004.

DUPAQUIER, Jacques. Suggestions pour l’organisation du travail

d’équipe en histoire sociale. In: L’histoire sociale: sources et
méthodes. Paris: Presses Universitaires de France, 1967.

FAURE, Robert. Machines et programmes. Quelques vues sur

l’utilisation des machines à traiter l’information en histoire
sociale. In: L’histoire sociale: sources et méthodes. Paris: Presses
Universitaires de France, 1967.

FAURE, Robert. Máquinas e programas. Pontos de vista sobre a

utilização das máquinas destinadas a elaborar a informação em
história social. In: A História Social: problemas, fontes e
métodos. Lisboa: Edições Cosmos, 1973.

FRAGOSO, João; PITZER, Renato Rocha. Barões, homens livres pobres e

escravos - notas sobre uma fonte múltipla. Os Inventários
Post-mortem. Revista Arrabaldes, v. 1, n. 2, p. 29–52, 1988.

GENET, Jean-Philippe. Histoire, informatique, mesure. Histoire &

Mesure, v. 01, n. 01, p. 07–18, 1986.

GINZBURG, Carlo. O inquisidor como antropólogo: uma analogia e as

suas implicações. In: Micro-história e outros ensaios. [s.l.: s.n.],
 176

1989.

GINZBURG, Carlo. O nome e o como: troca desigual e mercado

historiográfico. In: GINZBURG, Carlo (Org.). Micro-história e
outros ensaios. Lisboa/Rio de Janeiro: DIFEL/Bertrand Brasil,
1989.

GOUBERT, Pierre. Cent Mille Provinciaux au XVIIe Siècle. Beauvais et

le Beauvaisis de 1600 à 1730. Paris: Flammarion, 1968.

HAMEISTER, Martha Daisson. Para dar calor à nova povoação: Estudo

sobre estratégias sociais e familiares a partir dos registros
batismais da Vila do Rio Grande (1738-1763). UFRJ, Rio de
Janeiro, 2006.

HARRINGTON, Jan L. Relational Database Design and Implementation.

Morgan Kaufmann, 2016

HARVEY, Charles; PRESS, Jon. Databases in Historical Research. Theory,

Methods and Applications. London: Macmillan Press, 1996.

HENRY, Louis. Técnicas de análise em demografia histórica. Curitiba:

UFPR, 1977.

INMON, W. H.; LINSTEDT, Daniel. Data Architecture: A Primer for the

Data Scientist: Big Data, Data Warehouse and Data Vault.
Elsevier. 2015

DUPAQUIER J. Problèmes de la codification socio-professionnelle. In:

L’histoire sociale: sources et méthodes. Paris: Presses
Universitaires de France, 1967.

JEAN-PIERRE DEDIEU. Entrevista, realizada em outubro de 2013. ENS,

Lyon.

LUZZATI, Michele. La reconstruction nominative et prosopographique

de la population d’une ville médiévale: projet de constitution
d’une banque de données pour l’histoire de Pise au XVe siècle. In:
MILLET, Hélène (Org.). Informatique et prosopographie. [s.l.]:
CNRS, 1985.
 177

MACFARLANE, Alan. Computer input of Historical Records for

multi-source record linkage. In: Proceedings of the Seventh
International Economic History Conference. Edinburgh: [s.n.],
1979.

MACFARLANE, Alan. Reconstructing historical Communities.

Cambridge: Cambridge University Press, 1977.

MACFARLANE, Alan. The computer revolution and local history.

Disponível em:
<http://www.alanmacfarlane.com/FILES/local.htm>.

MANDEMAKERS, Kees; DILLON, Lisa. Best practices with large

databases on historical populations. Historical Methods, v. 37,
n. 01, 2004.

MITCHELL, J. Clyde. Social Networks. Annual Review of Anthropology,

v. 03, p. 279–299, 1974.

MITCHELL, J. Clyde; BOISSEVAIN, Jeremy. Network analysis. Studies in

Human Interaction. The Hague/Paris: Mouton, 1973.

PRATESI, Alessandro. Limiti e difficoltà dell’uso dell’informatica per lo

studio della forma diplomática e giuridica dei documenti
medievali. In: FOSSIER, Lucie; VAUCHEZ, André; VIOLANTE, Cinzio
(Orgs.). Informatique et histoire médiévale. Roma: École
Française de Rome, 1977, p. 187–190.

ROWLAND, Robert. L`informatica e il mestiere dello storico. Quaderni

Storici, v. 78, n. 03, p. 693 – 720, 1991.

SCHÜRER, Kevin. Historical demography, social structure and the

computer. In: DENLEY, Peter; HOPKIN, Deian (Orgs.). History and
Computing. Manchester: Manchester University Press, 1987.

SHORTER, Edward. The historian and the Computer. A practical guide.

New Jersey: Prentice-Hall, 1971.

STONE, Lawrence. Prosopografia. Revista de Sociologia e Política,

v. 19, n. 39, p. 115–137, 2011.
 178

STONE, Lawrence. The Crisis of the Aristocracy, 1558-1641. Oxford:

Oxford University Press, 1965.

STONE, Lawrence. The revival of narrative: reflections on a new old

history. Past and Present, n. 85, p. 3–24, 1979.

THALLER, Manfred. Can we afford to use the computer; can we afford

not to use it? In: MILLET, Hélène (Org.). Informatique et
prosopographie. [s.l.]: CNRS, 1985.

THALLER, Manfred. Methods and techniques of historical computation.

In: DENLEY, Peter; HOPKIN, Deian (Orgs.). History and Computing.
Manchester: Manchester University Press, 1987.

THOMAS, William. Computing and the Historical Imagination. In:

SCHREIBMAN, Susan; SIEMENS, Ray; UNSWORTH, John (Orgs.). A
Companion to Digital Humanities. Oxford: Blackwell, 2004.

UNIVERSITÉ DE MONTRÉAL INSTITUT D’ÉTUDES MÉDIÉVALES.

Computers and Medieval Data Processing: Informatique Et
Etudes Médiévales. [s.l.]: Université de Montreal, Institut
d’études médiévales., 1971.

VAN DER WOUDE, A.M.; SCHUURMAN, A. Probate inventories: a new

source for the historical study of wealth, material culture, and
agricultural development : papers presented at the
Leeuwenborch conference (Wageningen, 5-7 May 1980). [s.l.]:
Hes, 1980. (A.A.G. bijdragen).

VOVELLE, Michel. Ideologias e mentalidades. São Paulo: Brasiliense,

1987.

WRIGLEY, E. A. Identifying people in the past. London: Edward Arnold,

1973.

Base de données - Wikipédia. Disponível em:

<http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es>. Acesso
em: 27 set. 2013.

Database - Wikipedia. Disponível em:

 179

<http://it.wikipedia.org/wiki/Database>. Acesso em: 27 set. 2013.

Database - Wikipedia, the free encyclopedia. Disponível em:

<http://en.wikipedia.org/wiki/Database>. Acesso em:
27 set. 2013.

Index Thomisticus. Disponível em:

<http://www.corpusthomisticum.org/it/index.age>. Acesso em:
27 set. 2013.

Voyages Database. 2009. Voyages: The Trans-Atlantic Slave Trade

Database. Disponível em: <http://www.slavevoyages.org>. Acesso
em: 4 jan. 2014.