Ladeira Livros

Como se faz um
banco de dados
(em História)

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

2015
Copyright © Tiago Luís Gil
Capa: Durval de Souza Filho
Preparação dos originais: Manoel Rendeiro Neto
Editoração Eletrônica: David da Silva Carvalho

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

ISBN: 978-85-69621-00-3

Conselho Editorial
João Luis Ribeiro Fragoso (UFRJ)
Martha Hameister (UFPR)
Tiago Bernardon de Oliveira (UFPB)
Luis Augusto E. Farinatti (UFSM)
Helen Osório (UFRGS)

Dados Internacionais de Catalogação na Publicação (CIP)

Ficha catalográfica elaborada pelo bibliotecário Miguel Ângelo Bueno Portela, CRB1 –
2756

G463c Gil, Tiago.

Como se faz um banco de dados (em história) [recurso
eletrônico] / Tiago Gil. – Porto Alegre : Ladeira Livros, 2015.
127 p. : il.

Documento em PDF.
Inclui bibliografia.

ISBN 978-85-69621-00-3.

1. História - Metodologia. 2. Banco de dados.

3. Informática. I. Título.

CDU 930:004.652
Conteúdo

PREFÁCIO ............................................................................................................... 5

INTRODUÇÃO ........................................................................................................ 7

ALGUMAS QUESTÕES TEÓRICAS E METODOLÓGICAS .......................................... 11

UM ARTESANATO, UMA OPERAÇÃO ..................................................................................14

DESMONTANDO AS COISAS “EM ORDEM” ..........................................................................21
EM OMBROS DE GIGANTES .............................................................................................31

ALGUMAS QUESTÕES PRÓPRIAS DA INFORMÁTICA ............................................ 50

ESTRUTURA DE DADOS ...................................................................................................50

MODELOS CONCEITUAIS, LÓGICOS E FÍSICOS .......................................................................58
ASPECTOS VISUAIS SOBRE AS BASES ..................................................................................63
ENTRE A TÉCNICA E A TEORIA: PROBLEMAS COTIDIANOS E DECISÕES PRÁTICAS ...........................71

ENGENHARIA DE PESQUISA ................................................................................. 83

LEVANTAMENTO INICIAL.................................................................................................83
COLETANDO OS DADOS E ABASTECENDO A BASE ..................................................................87
ADMINISTRAÇÃO DA BASE ..............................................................................................95

MONTANDO BASES: ALGUNS EXEMPLOS CONCRETOS......................................... 98

BASES CENTRADAS NA FONTE ....................................................................................... 100

BASES CENTRADAS NO MÉTODO ................................................................................... 112

CONCLUSÃO ...................................................................................................... 122

BIBLIOGRAFIA .................................................................................................... 123

Prefácio

Este livro foi fruto de um pós-doutorado realizado na

École des Hautes Études en Sciences Sociales (EHESS) entre
agosto de 2013 e janeiro de 2014, dentro do projeto "O Bom
Governo das Gentes: hierarquias sociais e representação
segundo a política católica do século XVI ao XVIII". Para tanto, li
centenas de artigos, livros e capítulos sobre o tema, além de
dezenas de manuais de informática. Os resultados dessa
pesquisa também foram aproveitados em cursos presenciais
sobre bancos de dados, realizados na UFRJ em outubro de 2014
e na UFRGS em dezembro do mesmo ano, quando as ideias aqui
apresentadas foram alvo de debates. Os dados obtidos foram
utilizados em outras publicações, a saber: “Storici e informatica:
l’uso dei database (1968-2013)”, publicado na revista “Memoria e
ricerca” (Itália, 2015) e "’Our own in-house’ software: una
historia de historiadores programadores” na obra “Historiografía,
giro digital y globalización. Reflexiones teóricas y prácticas
investigativas” de Juan Andrés Bresciano (Uruguay, 2015).
Agradeço aos colegas do Departamento de História da UnB,
Marcelo Balaban, Neuma Brilhante, Teresa Marques, Luiz
Nogueról e Marcos Pereira pela leitura atenta, assim como aos
estudantes do Laboratório de História Social da UnB, que
discutiram animadamente seu conteúdo. Não poderia deixar de
agradecer aos professores João Fragoso, Jonas Moreira Vargas,
Roberto Guedes Ferreira, Antonio Carlos Jucá de Sampaio,
Thiago Krause, Hélida Conceição, Helen Osório e Luís Augusto
Farinatti, que igualmente leram e comentaram o original. O
material também foi avaliado pelo mestre em computação Cássio
Couto, que fez diversas sugestões.

A pesquisa contou com financiamento da CAPES

(Programa Capes/Cofecub) e do CNPq.
 CLIQUE AQUI
PARA ADQUIRIR
A VERSÃO
IMPRESSA DESSE
LIVRO
 [7]

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, ou, como
se diria em inglês to database something. 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 devido à 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.
Para tentar amenizar isso, o texto todo foi escrito levando em
[8]

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
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
 [9]

obsoletas e inutilizáveis diante de problema 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 sequer conseguiram responder à pergunta
original. Sim, porque as bases têm relação direta com nossas
perguntas, ou deveriam ter. E é 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, 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

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]

consolidando na informática, em todos os campos do

conhecimento e pareciam mesmo estar se tornando 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. Esses ú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. Ele obedece, perfeita ou imperfeitamente, aos
3

preceitos e às concepções de mundo (e, dentro desses, das

opiniões sobre o problema de pesquisa) do pesquisador. 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. Mas 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. E 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

3
Não vou 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]

preferem 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
pesquisa 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 trabalho do historiador.

A primeira enfatiza as trajetórias individuais,

 [13]

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.
Mas 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, ajuda em um estudo
prosopográfico. A questão é que nossas perguntas 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. Pode ter sido uma opção segura, devido à
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
[14]

envolvem aspectos teóricos, metodológicos e técnicos e fazem

isso ao mesmo tempo, de tal maneira que não podemos dissociar
estes 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 é,
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

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.
 [15]

historiadores, assume no texto de Certeau, um lugar

fundamental: “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 mais
clara de produzir conhecimento histórico com o uso de bancos
de dados. Para ele, tudo começa com o Real Passado, um
abstrato “mundo real” do qual não temos todos os indícios,
devido à perda ou ao 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 metasoures
(metafontes). Graficamente, o argumento do autor poderia ser
expresso da seguinte maneira.

5
Ibid., p. 28.
[16]

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, 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, ele
seleciona e reúne suas fontes para desmontá-las com “ações
combinadas”, criando 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

 [17]

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
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 é
6
suscetível.

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 vá 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 é. 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:

6
Ibid., p. 34.
[18]

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
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...
7

É preciso saber o modo como a fonte foi construída,

seu público, seus autores, seus limites, seus objetivos e que
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 que 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. Mas
interessa 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

7
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).
 [19]

(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
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.
8

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.

8
DE CERTEAU, A operação histórica, p. 33. Grifo nosso.
[20]

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, devido à 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. 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 devido às 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 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
 [21]

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. E 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.

E não se trata apenas de usar de instrumentos de

comparação, mas de formalizar com a clareza necessária para o
processamento com os nossos critérios de análise manifestos na
escolha dos campos, por exemplo. 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 e que isso
9

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.

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,

9
Como querem os contextualistas ingleses.
[22]

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 velho , que a pesquisa
11

transformará em fonte, de modo a produzir um “desmonte”. Em

outras palavras, vamos tomar um documento e desfazê-lo em
pedacinhos. Mas 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. E é
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 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

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.
 [23]

“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, eles seguem um modelo muito particular, como no
13

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é

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.
[24]
14
de Freitas Costa

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 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

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

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

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
[26]

"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, é ao encontrar o inesperado que produzimos
15

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
batismo não é tarefa fácil. E 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 Hameister nos

16

15
JEAN-PIERRE DEDIEU, Entrevista.
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.
 [27]

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
é de apresentar uma base voltada para batismos. Não nesse
momento.

Se bem que 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
17
Ocidente, eles têm uma estrutura bastante semelhante.
Embora muitos dos disponíveis pelo mundo não correspondam
ao esperado, há certa lógica da fonte que permite, entre outras

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.
[28]

coisas, a comparação. E se, algumas vezes, encontraremos

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 de 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. É comum encontrar dados da família
18

do falecido, assim como informações sobre o parentesco 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 devido a
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

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.
 [29]

alterou em séculos. Havia uma fórmula, que informava sobre o

19

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 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 tenho, 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

19
VOVELLE, Michel, Ideologias e mentalidades, São Paulo: Brasiliense, 1987.
[30]

campos que criamos 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
comuns e ainda não bem resolvidos. Contudo, manter o foco
20

na estrutura da fonte ainda é a saída mais conveniente. E isso

requer alguma erudição, técnica famosa 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.
 [31]

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 se deu 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 se acovardou 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 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
[32]

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.
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 é. Contudo, a capacidade de recuperar os
registros de forma automática, rápida e fácil após a conclusão do
trabalho é bastante 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

21
BUSA, Roberto, The Annals of Humanities Computing: The Index
Thomisticus, Computers and the Humanities, v. 14, p. 83–90, 1980.
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.
 [33]

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 assunto ,
23

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. Toda
24

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.

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 se tratava de um debate técnico, ainda que estas
questões estivessem sendo discutidas. Foi durante um colóquio

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.
[34]

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, a 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 subsequente ,
26

entre cartões perfurados e fitas magnéticas, ali já estavam

colocadas algumas questões importantes do ponto de vista do
historiador e que 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

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.
 [35]

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
27
informações não são equivalentes.

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

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

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.
[36]

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, através 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. Era uma proposta
30

de 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

29
Ibid.
30
ADELINE DAUMARD, Une référence pour l’étude des sociétes 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
archives notariales au XVIIIe et au XIXe siècle., Revue Historique, v. 86,
n. CCXXVII, 1962.
 [37]

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.

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. O uso do computador era
31

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.32

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 a e confiança nos computadores que

31
STONE, Lawrence, The Crisis of the Aristocracy, 1558-1641, Oxford: Oxford
University Press, 1965.
32
STONE, Lawrence, Prosopografia, Revista de Sociologia e Política,
v. 19, n. 39, p. 115–137, 2011.
[38]

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...33

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
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. 34

O uso de grandes computadores ainda era privilégio

dos cientistas políticos, dentro das humanidades. 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
35
solucioná-los

33
Ibid.
34
Ibid.
35
Ibid.
 [39]

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.36

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 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. 37

Mas 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

36
Ibid.
37
Ibid.
[40]

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.38

Com isso tornamos ao problema apresentado por

Daumard, alguns anos antes. Preciso de uma boa classificação
para conhecer o passado e preciso conhecer o passado para ter
uma boa classificação. No entanto, o conhecimento prévio do
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 tratar-se de 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 vindouros39

E os anos vindouros prometiam muito.

38
Ibid.
39
Ibid.
 [41]

O primeiro Manual de Computação para historiadores

Em 1971, o historiador Edward Shorter lançava The

historian and the Computer. A practical guide.40 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 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). Mas 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

40
SHORTER, Edward, The historian and the Computer. A practical guide, New
Jersey: Prentice-Hall, 1971.
[42]

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 como PL/1 e Snobol.41 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.

“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. Apesar de
42

breve, o texto continha a essência das reflexões iniciadas em

1972, quando se iniciara a aventura de Macfarlane e Sarah

41
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.
42
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.
 [43]

Harrison na tentativa de informatizar fontes para o estudo de

história local na Inglaterra. O resultado da pesquisa tornou-se
43

livro um pouco antes, com o nome de Reconstructing historical

Communities.44 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 dava pelo fato de
que estas metodologias 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.

43
MACFARLANE, Alan, The computer revolution and local history.
44
MACFARLANE, Alan, Reconstructing historical Communities, Cambridge:
Cambridge University Press, 1977.
[44]

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,
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))]

Ou seja, uma pessoa chamada John tinha

parentesco (k), no caso, era filho de outra pessoa chamada
Henry Abbott e participou de um evento, um batizado, em uma
data, no caso, no dia 5 de maio de 1607. Com o uso destes
códigos e parênteses, um historiador explicaria à máquina o
 [45]

significado de cada coisa: datas, nomes, relacionamentos, etc.

Demandava algo importante e válido, com debate, até os dias
atuais: 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. Recentemente
45

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 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 dessa
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

45
ROWLAND, Robert, L`informatica e il mestiere dello storico, Quaderni
Storici, v. 78, n. 03, p. 693 – 720, 1991.
[46]

para o processamento de dados em história. Chamava-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 dos documentos 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.
46

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 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 no 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, mais do que um software
completo, próximo de uma base de dados de historiador.

O trabalho de abastecimento era feito seguindo a

ordem da documentação 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 dos documentos. 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

46
Ibid.
 [47]

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
47
dos dados originais.

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 época, contra os quais Thaller se manifestava
preocupado, precisamente pela falta deste tipo de recurso.
48

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. Trata-se de uma base centrada no
49

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

47
THALLER, Methods and techniques of historical computation.
48
THOMAS, William, Computing and the Historical Imagination, in:
SCHREIBMAN, Susan; SIEMENS, Ray; UNSWORTH, John (Orgs.), A Companion
to Digital Humanities, Oxford: Blackwell, 2004.
49
DEDIEU, Jean Pierre, Les grandes bases de données: une nouvelle approche
de l’histoire sociale. Le système Fichoz, Revista da Facultade de Letras-
História, v. 05, 2004.
[48]

pessoas conectadas com outras por algum motivo (análise de

redes sociais) e por séries, de acordo com a necessidade. Isso
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
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
50
margem de interpretação.

O traço marcante deste sistema é sua versatilidade.

As buscas e 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 permitia 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

50
Ibid.(Tradução nossa. O original está em francês).
 [49]

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
assunto dentro do contexto da carreira de cada um dos
51
atores.

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 dentro da 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.

51
Ibid.
[50]

Algumas questões próprias da

informática

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 de
que já discutimos antes) e muitos se consideram incapazes de
aprender. Mas acredito que quem aprendeu a usar um aparelho
celular ou o email poderá facilmente aprender alguns dos
elementos básicos que caracterizam as bases de dados.

Veremos que não é tão complicado. O problema é

grande devido à 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.

Estrutura de dados

A primeira coisa que importa saber é quais são os

elementos que compõem uma base de dados, sua estrutura. É
bem mais simples do que Althusser! Uma base é um conjunto de
TABELAS articuladas. Alguns usam a palavra “entidade” para
designar as tabelas, um nome um tanto sobrenatural. Essas
tabelas podem conter diferentes tipos de informação: sobre
pessoas, casas, terras, por exemplo, endereços, etc. Podemos
criar apenas uma tabela, se for o caso. Sobre essa decisão, que
 [51]

envolve predominantemente problemas próprios do

conhecimento histórico, veremos adiante, quando lermos sobre a
montagem de bases. Continuemos com as nossas tabelas.

Figura 5 - Ilustra a estrutura de um banco de dados

Uma tabela é formada por campos e registros

(também 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, a tabela seria
composta por campos como “nome”, “matrícula” e “idade”, por
exemplo. Os registros seriam tantos quantos fossem os alunos
matriculados na turma.

Figura 6 - Modelo de tabela Figura 7 - Modelo de tabela (como em um

(conceitual) formulário)

Como pudemos ver, é algo bem mais simples que

Lévi-Strauss. Agora, que já dominamos essa informação,
[52]

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, na
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
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
 [53]

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.

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. 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.52 Vimos isso
quando lemos sobre os modelos de Macfarlane e Thaller.
53

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”

52
Há também ocasiões em que os historiadores não sabem o que querem,
mas quanto a isso não há como ajudar.
53
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.
[54]

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. Gostamos de guardar tudo, mas não adianta
guardar tudo fora de ordem, pois é o mesmo que não guardar.
Ter e não encontrar é como não ter.

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.
54

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

54
MACFARLANE, Computer input of Historical Records for multi-source record
linkage; MACFARLANE, Reconstructing historical Communities.
 [55]

univocamente a pessoa que portava aquele nome e que talvez

tenha um homônimo).

É que, na fonte, alguns dados são únicos. O normal

para um registro de casamento no ocidente é que haja um noivo
e uma noiva. Não estão previstos outros cenários (e, se surgir,
será uma descoberta extraordinária). 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 com os
dados que temos sobre as diferentes ocupações exercidas por
um sujeito ao longo da vida? Se ele teve apenas um trabalho, é
fácil. E se temos casos de gente que teve oito diferentes
profissões, algumas simultâneas?

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 apresentam 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.

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
[56]

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é, o
período em que isso ocorreu. Podemos saber também que
funcionários trabalharam em quais setores, adotando a
perspectiva oposta. Assim, podem existir vários tipos de
relacionamentos, a saber:

 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).

Chamamos isso de cardinalidade. Vejamos, abaixo,

algumas ilustrações para explicar bem mais isso tudo. 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.).

Figura 8 - Exemplo de modelo de dados com relacionamento. A cardinalidade indica

que uma biblioteca pode ter vários livros, neste modelo.
 [57]

No modelo acima, há duas tabelas relacionadas,

através dos campos “Nome” e “Biblioteca”. Esses dois campos
dizem respeito à mesma coisa, o nome de uma instituição
específica, que abriga e organiza livros. E como é 1:n (um para
muitos), podemos atribuir tantos livros para a nossa biblioteca
quantos forem necessários. Vejamos abaixo como isso ficaria em
um formulário de preenchimento, em branco, na primeira
imagem e com alguns dados na segunda:

Figura 9 - Exemplo de formulário com Figura 10 - Exemplo de formulário com

RELACIONAMENTO (sem dados) RELACIONAMENTO (com dados)

Como definimos “um para muitos”, podemos incluir

vários livros “dentro” da tabela Bibliotecas, através do
relacionamento. Com isso, as características de cada tabela,
adequadas 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 cruzá-las. Na construção de bases de dados em
História, podemos usar os relacionamentos de diversas maneiras.
Eles podem ser usados para formar hierarquias entre as
informações, como no exemplo da biblioteca; para estabelecer
ligações equilibradas entre informações diferentes, entre
personagens, por amizade, ou lugares, por proximidade, para
dar um exemplo, e apenas para organizar informação, como no
caso dos alunos e das notas, pelo simples fato de serem
incluídos em tabelas diferentes.
[58]

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. E essa modelagem dos bancos de dados é feita
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
vão formar essa entidade. É como se fosse um croquis da futura
base, feito por um arquiteto ou estilista. Nesse caso, nosso
croquis será feio, quadrado e cheio de riscos. Mas será
importante.

Bom mesmo seria fazer esse planejamento

discutindo com outros colegas, mas nem sempre é o caso. Com
todo o esquema diante de nossos olhos, convém pensar
possibilidades e limites. Para isso, no caso do conhecimento
histórico, é fundamental conhecer as fontes e seus limites e,
 [59]

como salientaram Genet e Luzzati, ter erudição histórica para

fazer isso. Convém fazer um exercício mental para checar a
55

viabilidade da base. O desenho abaixo ilustra esse esforço, sem

querer propor um modelo para processos-crime, pois seria bem
mais complexo. É apenas uma ilustração dessa etapa do
desenvolvimento.

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

55
LUZZATI, Michele, La reconstruction nominative et prosopographique de la
population d’une ville médiévale: projet de constituition 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; GENET, Histoire,
informatique, mesure.
[60]

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 lógico. Talvez não seja

lógico chamá-lo assim, mas é o nome. 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 - de que tipo será cada campo, com que
tamanho em número de caracteres (e ainda não vimos nada
sobre o visual que terá o formulário de preenchimento e a
tabela, que será assunto mais adiante).

Nessa fase também vamos indicar que campos vão

ser 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:
 [61]

Figura 12 - 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 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,
[62]

já ajuda. Se forem milhares e curtos, eu recomendaria testar

com 3% dos casos. Se forem centenas e longos, recomendaria
5%, se forem curtos, 10%. Mas não tome esses valores como
receitas de bolo. Esses testes devem ajudar você 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 vai 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 texto, numa planilha eletrônica, em outro banco
de dados ou numa folha de papel. Mas precisa ser útil para
explicar como a base funciona para que qualquer pessoa possa
entendê-la e ele deve informar quais são as tabelas que
 [63]

compõem a base e que 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 é 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
[64]

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 tem) relação direta com
aquela outra tabela - a das entidades. Mas pode NÃO ter.
Podemos criar uma tabela-visual para apresentar dados de
diferentes tabelas-entidades, usando um relacionamento. Por
isso, vou usar a expressão “tabela-visual”, como usarei
formulário-visual e lista-visual, para que fique 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.
 [65]

Figura 13 – 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. 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 é mais longo que 50 caracteres. Se algum for maior,
ocupará muito espaço e será visualmente condenável.
[66]

Figura 14 - Exemplo de formulário Figura 15 - 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
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
 [67]

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.

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

Cores

Mesmo que saibamos que o vermelho é sempre

mais bonito do que o azul, parece-me conveniente escolher esta
última cor para o pano de fundo da base. Para ser mais preciso,
eu usaria um tom claro de azul, com a medida RGB
244,244,255.56 Essa cor tem algumas qualidades: quebra o
fundo branco, que pode ofuscar quem trabalha por muitas horas,

56
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.
[68]

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, que indiquei acima, para uma tabela, devemos
intercalar as linhas das tabelas usando outra cor - eu diria o
branco - para facilitar a observação, especialmente se for uma
tabela com muitas colunas. Isso é melhor do que usar contornos,
que poluem tanto quanto o excesso de campos visíveis. Da
mesma forma, nos formulários-visual, 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 possamos acelerar a identificação de dados e, até, encontrar
coisas fora do lugar com maior facilidade. O cozinheiro precisa
achar seus instrumentos com precisão e rapidez na hora de
preparar seus pratos!

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.
 [69]

Figura 17 - Exemplo do uso de cores e contrastes (o cinza-claro substitui o azul-claro

que recomendei)

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 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
X800; 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

[70]

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 peças 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 mais
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 18 - Exemplo de formulário baseado na ordem da fonte

É 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.
 [71]

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. E 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. Prefiro
57

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.
58

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 o historiador construiria seu caminho. Há
59

outras metodologias para as quais a identificação dos nomes das

57
MANDEMAKERS, Kees; DILLON, Lisa, Best practices with large databases on
historical populations, Historical Methods, v. 37, n. 01, 2004.
58
WRIGLEY, E. A., Identifying people in the past, London: Edward Arnold,
1973.
59
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.
[72]

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 outros quatro “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 têm
o mesmo nome, vivem 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, dizer 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 fazem parte do meu universo de análise. Isso
significa atribuir um número para cada agente histórico que
estudamos. Esse número será usado sempre junto com o 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
 [73]

encontrar pessoas quando cruzamos muitas fontes diferentes.

Usar apenas as matrículas vai diminuir as chances

de juntarmos os pedaços da mesma pessoa que estavam
separados devido a 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 permitem 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 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
[74]

dos nossos agentes e que deve ser feito de modo a permitir a

descoberta de homônimos.

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. Reconheço que
60

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
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. Mas é preciso um trabalho
duplo, para o qual, muitas vezes, não temos tempo ou recursos.
E transcrever, por si só, já demanda muito tempo. Mas 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

60
MACFARLANE, Computer input of Historical Records for multi-source record
linkage.
 [75]

original” para cada excerto informatizável da fonte, para cada

pedaço de texto 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 podem 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 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 seria propagado por todos
os registros, demandando um novo esforço. No caso da
utilização do código, 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
[76]

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

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.
 [77]

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. E há ainda 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 dois momentos, medida
em número de dias. Para isso, é 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.

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
[78]

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 impede 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 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
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 devido à 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
 [79]

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
importante.
61

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ürer quando argumenta que é impossível prever
62

todos os usos futuros de uma base. Mas 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,

61
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.
62
SCHÜRER, Historical demography, social structure and the computer.
[80]

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 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
 [81]

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 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
[82]

aquele problema e 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.

CLIQUE AQUI
PARA ADQUIRIR
A VERSÃO
IMPRESSA DESSE
LIVRO
 [83]

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. Por exemplo, se
63

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
a selecionar a amostra que utilizarei ou a demanda de recursos e

63
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.
[84]

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, devem-se tomar umas vinte amostras. Se
for mais de 1000, eu tomarei 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 só 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,
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
 [85]

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
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
[86]

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.
64

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 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...)

64
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.
 [87]

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 e que
previmos seu uso com variada e conhecida metodologia e 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. Geralmente, os
65

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
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 identificado, 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

65
THALLER, Can we afford to use the computer; can we afford not to use it?.
[88]

uma única base, que deve ser preenchida ao mesmo tempo, e a

coleta deve ser o 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

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 é.
Vou seguir este texto com dois caminhos: o dos que podem usar
a câmera e o dos que não podem. Comecemos pelos primeiros.

Para que as fotos sejam melhores do que os

originais, tendo em conta a pesquisa em História, é preciso
algum cuidado. Não é difícil. Basta lembrar que fotografia é o
registro da luz. É preciso luz. E os Arquivos (acervos) geralmente
não têm uma boa iluminação. Logo, ou conseguimos iluminação
por nossa conta (com autorização do Arquivo) ou usamos uma
ligeira astúcia: regular o diafragma da câmera, deixando-o mais
aberto (para a entrada de mais luz) e aumentando o tempo de
exposição da foto (para que a luz entre por mais tempo). Como
o documento fica parado, será fácil. Só nos resta uma coisa: não
 [89]

tremer. Se tremermos, a imagem ficará sem foco. Ou temos

firmeza nas mãos e nos braços ou usamos um tripé (com
autorização do Arquivo).

O tripé garante estabilidade, mas convém usá-lo

bem. Não há mistério, mas há uma dica: os tripés têm pés
retráteis. Convém expandir apenas um deles, de tal maneira que
fique apoiado no chão, enquanto os outros dois ficam apoiados
na mesa de trabalho. Isso vai dar espaço de trabalho e gerar um
ângulo bom para colocar o documento por baixo da câmera.
Contudo, atenção para o contrapeso! A câmera geralmente é
pesada, e o uso do tripé, nesse ângulo, pode fazer cair o
conjunto. Use um contrapeso. Eu gosto de usar um saco de
moedas amarrado no pé expandido.

Outra dica importante é sempre fotografar a

referência, a cota do documento, antes de capturar o conjunto
para, depois, organizar as fotos em pastas corretamente
identificadas. Como a notação, comumente, é pequena e usamos
programas em que podemos ver as miniaturas das fontes
(gerenciador de arquivo), convém usar um “divisor” adicional,
algo que indique a mudança de documento, além da foto da
cota. Pode ser uma folha em branco ou a mesa do arquivo.
Minha dica é tirar foto da mão bem aberta. Com a certeza de
que um novo documento está naquelas fotos, poderei facilmente
arrastar todos os arquivos para a pasta do computador que lhes
cabe. É tão prosaico quanto prático.

Vejamos, agora, o caso de quem não pode usar

uma câmera digital no 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) está disponível para a tarefa.
[90]

É 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.

Em se tratando 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 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 se
apresenta 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
 [91]

campos ou na estrutura da base será automaticamente

disponível para todos, sem 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 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
[92]

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 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 ser
citadas 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 o sistema
pode sugerir igual próximo, mas não igual, e o digitador não
perceber, devido à 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
 [93]

um descuido. Outra opção pode ser a criação de avisos de alerta.

Se um campo numérico é preenchido 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 que foram 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" ou
“.csv”. 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 marcos indicadores, como a vírgula ou o ponto e
[94]

vírgula. 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:

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

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

Se usarmos um campo de cálculo, podemos mandar

o campo capturar tudo o que houver entre o primeiro e o
segundo ponto (note-se que, nesse exemplo, o número sempre
acaba com um ponto). O que houver até o primeiro ponto é
nome e o que vier depois do segundo, é endereço. Nem sempre,
há tantos pontos para facilitar a vida, mas é comum
encontrarmos algum elemento para estabelecer as regras para
nosso campo de cálculo. Se estivermos com apenas duas linhas,
não vale a pena fazer isso, mas quando temos centenas, poupa
muitas horas de trabalho. O mesmo pode ser feito para catalogar
fotos do computador. Basta escolher a pasta onde estão as
imagens, copiar o endereço delas (o caminho que indica sua
pasta) e colar no navegador de internet, o qual vai apresentar
uma lista de todos os arquivos da pasta. Basta copiar e colar
numa planilha eletrônica. Com isso, teremos um banco de dados
de arquivos da pasta, que pode ser usado para organizar fotos
de documentos, inclusive relacionando as fotos com as
transcrições, com o banco de dados, etc.
 [95]

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). Esse programa vai
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 atenção sobre a importação dos dados e a
sincronização dessas informações. É preciso distribuir as tarefas
e coordenar quem ficou responsável pelo que, 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,
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
[96]

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 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, visualmente, se os 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.
 [97]

Informações fora do lugar ou muito discrepantes podem ser

identificadas com facilidade. É claro que algumas podem virar
grandes descobertas, digamos assim, mas pode 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.
[98]

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." É certo que partimos de
66

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. Trata-
67

se de um banco de dados com mais de 35.000 viagens de navios

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

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 nem 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 se justifica 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 se
valer 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 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
[100]

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

Esse é 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". Usando
68

desse 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

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

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 se
revelar úteis em algum momento da pesquisa, pois minha
pergunta inicial pode se revelar 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 de isso 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
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 é
[102]

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 acaba
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 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.

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
 [103]

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:

Figura 19 - 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
[104]

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 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 AAAA
texto)
Data final Data (ou AAAA
texto)
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
 [105]

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 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, não é necessário, mas
pode 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 que 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
[106]

Sexo Texto Caixa de escolha (M, F)

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 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.
 [107]

Por fim, temos a terceira tabela, “Detalhes” que

será muito enxuta para permitir alguma maleabilidade, para que
possamos receber qualquer tipo de dado adicional. Começamos
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 classifica 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 com a 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.

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. Mas, com isso, temos apenas uma base “individual”,
[108]

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 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 se integrar com outras, de
batismo e de óbitos, para a aplicação do método Henry.

Correspondências

Vimos (na página 24) que as correspondências

podem ser vistas como um tipo de fonte sem estrutura, diferente
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
 [109]

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, previsto

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 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
[110]

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 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. Nesse 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.

Fontes dialógicas

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

inquisidor como antropólogo”, de Carlo Ginzburg. Serve para
69

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

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 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
[112]

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. Isso 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 campos “pergunta” e “resposta”.

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

dados organizados, como fiz com o exemplo dos batismos e das
cartas. Nesse 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, também, mas é uma simplificação que organiza. Não
precisamos simplificar mais nem temos motivo para isso,
porquanto temos ferramentas que nos permitem tratar as fontes
com cuidado.

Bases centradas no método

Na página 47 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,
 [113]

permitia o desdobramento de interações sociais (descritas nas

fontes) em uma grande variedade 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. E seria 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
inglesa , assim como seu artigo de 1971, que já apresentamos
70

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 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 possamos 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

70
STONE, The Crisis of the Aristocracy, 1558-1641.
[114]

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” me parece 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.
71

Um sistema de fichas individuais poderia ser uma

boa saída, mas tem alguns 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

71
DEDIEU, Les grandes bases de données: une nouvelle approche de l’histoire
sociale. Le système Fichoz.
 [115]

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.

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, através
do cruzamento dos dados. Trabalho sem fim! E tudo isso usando
fichas de papel. O tempo passou e somente em 1968 foi
apresentado ao mundo o primeiro grande resultado da proposta,
a tese de Pierre Goubert sobre Beauvais. Desde então, foram
72

feitos muitíssimos acréscimos à concepção original, variações,

inclusive, softwares variados para aplicar o famoso método. 73

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

72
GOUBERT, Pierre, Cent Mille Provinciaux au XVIIe Siècle. Beauvais et le
Beauvaisis de 1600 à 1730, Paris: Flammarion, 1968.
73
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.
[116]

Henry para o caso do Brasil, permitiriam uma quarta base, para

as listas nominativas. E isso não significa ignorar a opção de
74

quem 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. 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 varreadura 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

74
HENRY, Louis, Técnicas de análise em demografia histórica, Curitiba: UFPR,
1977.
 [117]

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 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. Mas pode ser
relevante se assim for considerado 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, convém 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á vários 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. Mas é preciso que
fique claro que isso só será possível com boas bases de fontes
que darão algum trabalho, mas valerão a pena. Feito isso,
[118]

teremos condições de automatizar um bocado nosso esforço, de

tal 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.75
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 é formado por nós (que representam as

75
MITCHELL, J. Clyde; BOISSEVAIN, Jeremy, Network analisys. 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 personel 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.
 [119]

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 20 - Matriz matemática das relações de um grupo

[120]

Figura 21 - 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
repetem (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, só bens de inventários, por
exemplo, ou apenas os registros de compra e venda de alguma
 [121]

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 feita
com fontes muito variadas que mereceriam críticas muito
diversas. 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), devido às próprias descobertas feitas ao longo dela.
Essas são questões sobre as quais a equipe deverá refletir.
[122]

Conclusão

Uma obra como esta não precisaria de conclusão,

porquanto entendo que ela fica por conta do leitor, que fará sua
base, talvez com a nossa ajuda. Acredito, contudo, que muito
mais do que foi dito aqui poderá ser feito e pensado sobre o
assunto, com o foco especificamente direcionado para as
pesquisas na área de História.

Apresentei algumas bases de dados voltadas para

fontes, e outras, para a metodologia, depois de uma breve
reflexão sobre alguns dos problemas próprios da informatização
do conhecimento histórico, mas não falei que seria possível criar
um grande sistema que auxilie todas as etapas do trabalho. Já
há algumas iniciativas em curso, paralelas, em vários países, mas
todas ainda estão em fase de testes. Certamente, em alguns
meses ou anos, este texto será acrescido de algumas novas
experiências e uma nova conclusão. Espero que sim.
 [123]

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étes
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 personel 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.
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.
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.
DE CERTEAU, Michel. A operação histórica. In: LE GOFF, Jacques;
[124]

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 Facultade 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.], 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:
 [125]

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.
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.
JACQUES DUPAQUIER. Problèmes de la codification socio-
professionelle. 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 constituition 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.
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 analisys.
[126]

Studies in Human Interaction. The Hague/Paris: Mouton,

1973.
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.
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.
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
 [127]

Etudes Medievales. [s.l.]: Université de Montreal, Institut

d’études medievales., 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:
<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.