Como se faz um banco de dados em História (2ª edição revisada)

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

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

Índice Prefácio .............................................................................................. 7 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. Para tanto, li centenas de artigos, livros e capítulos sobre o tema, além de dezenas de manuais de informática. Os resultados desta 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 nesta pesquisa 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, 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.

[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. Tratandose 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 1 colocamos lá dentro. 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 2 hegemônico na relação entre história e informática. 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 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. 3

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. O problema é que nossos problemas de pesquisa mudam ao longo da pesquisa. A segunda opção, registrar em tabelas “ação-poraçã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 4 um "olhar". É necessária uma operação técnica.

A

4

técnica,

geralmente

desprezada

pelos

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 5 técnicas de produção [...] a história é mediada pela técnica.” 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 7 maior...

É 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 8 produtos standart da informática.

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. 9 É certo que posso definir o contexto a partir do texto e que isso me ajuda a compreender diversos aspectos daquela sociedade que gerou o texto. Mas sem comparar, classificar ou contar, ficarei privado de qualquer afirmação que inclua expressões como “a maioria”, “a menor parte”, “um bom número”, “poucos”, “melhores” e “piores”. Nesse sentido, formalizar nossos critérios em um banco de dados facilita a comparação e permite uma clareza maior do universo que estamos estudando.

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 11 possibilidade de tomar um papel velho , que a pesquisa 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 13 XIV, eles seguem um modelo muito particular, como no 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] de Freitas Costa

14

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. 15 Segundo Dedieu, é ao encontrar o inesperado que produzimos conhecimento, e formalizar dados em uma base pode ser um meio para isso. Poderíamos encontrar outros tantos exemplos que nos mostrariam que criar uma base de dados para registros de 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 15

16

nos

JEAN-PIERRE DEDIEU, Entrevista. 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. 16

[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 postmortem, 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 18 comprobatórios e partilha. É comum encontrar dados da família do falecido, assim como informações sobre as famílias dos escravos que eram propriedade do falecido, quando em sociedades escravistas. Contudo, é possível encontrar uma diversidade de fontes não previstas, como recibos de compra de medicamentos e atendimento médico (geralmente 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 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. 19

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 20 comuns e ainda não bem resolvidos. Contudo, manter o foco 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, 21 mesmo sem ter dinheiro. Toda a preocupação de Busa, naquele momento, estava no processamento da informação e não nas formas de estocagem dos dados. A forma de fazer isso já estava definida de antemão e seguia os mesmos pressupostos usados por ele na confecção de fichas manuais, que continham palavras, frases e suas localizações nos textos tomistas. A palavra database (base de dados) não aparece no seu texto, ainda que a expressão data bank (banco de dados) seja utilizada uma única vez, justamente quando ele narra as dúvidas que surgiram no momento de publicar os resultados, se seriam publicados em um livro, na forma de um enorme catálogo, ou se somente seria oferecido o banco gerado no processo. A opção final foi pela publicação de quinhentos exemplares de um grande catálogo, possível graças ao uso da linguagem binária em cartões e fitas magnéticas. A primeira questão que me parece pertinente com este caso é a forma com Busa criou uma demanda de pesquisa e foi em busca da técnica para solucioná-la. E mesmo uma saída cara e que levaria anos (neste caso, 30 anos), envolvendo o treinamento de dezenas de ajudantes no processamento dos cartões perfurados e fitas, foi pacientemente aceita tendo em vista o ganho maior ao longo prazo. Esta é a segunda conclusão que podemos tirar desta empreitada: o custo de desenvolvimento e abastecimento de bancos de dados parece alto, e certamente é. 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

21

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

[33] pesquisa, atingir seus objetivos com grande velocidade. 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 23 integralidade das informações relativas a um assunto , 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 24 dizendo tratar-se de uma coleção organizada de dados. Toda esta discussão, contudo, passava longe da cabeça de Busa e só se tornou central a partir dos anos 1970. Até então, a grande promessa da informática não estava no armazenamento, mas no seu grande potencial de processamento das informações. Por outro lado, um data bank seria o conjunto dos cartões, simplesmente. 22

O Colóquio da École Normale Supérieure de Saint-Cloud, de 1965 Em 1965 um grupo de historiadores também

22

Disponível na web no endereço: Index Thomisticus, disponível em: , acesso em: 27 set. 2013. 23 Base de données Wikipédia, disponível em: , acesso em: 27 set. 2013. 24 Database Wikipedia, disponível em: , acesso em: 27 set. 2013; Database Wikipedia, the free encyclopedia, disponível em: , acesso em: 27 set. 2013.

[34] 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 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 26 apresentação de Faure, bem como do debate subsequente , 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 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] profundidade em outra comunicação, de Jacques Dupaquier: o problema da classificação e consequente uso de codificações. Faure ingenuamente acreditava na possibilidade de uma codificação perfeita, que mantivesse as características da fonte. Contudo, um dos comentaristas, Claude Mazauric, destacava que: ...a determinação do código é a questão mais delicada para o historiador [...] pois de acordo com as datas, de acordo com as épocas, com os tipos de documentos, as 27 informações não são equivalentes.

Dupaquier, neste mesmo evento, apresenta o texto 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

Problèmes

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

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] Se tivéssemos um código perfeito seria quase inútil de estudar o que quero, a burguesia, pois saberíamos de imediato o que ela é. Diante deste paradoxo é que está o paradoxo da história: precisamos de uma classificação para poder trabalhar; mas ao mesmo tempo, precisamos nos resguardar de prejulgar o resultado. Esta é a razão pela qual, na minha opinião, a solução deve ser a busca de modo empírico, a fim de traduzir a realidade.29

Neste debate, classificação e codificação eram sinônimos. E codificar significava transferir as classificações para dentro da lógica da computação da época. Codificar era a forma disponível de manifestar formalmente as concepções teóricometodoló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 30 “projeto” de classificação sócio-profissional. Era uma proposta 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 29

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

[37] complexidade do mundo social será sempre maior que nossa capacidade de compreendê-la. Ou melhor, compreender demanda simplificação. Resta-nos simplificar com a maior complexidade possível. E, para isso, devemos estar atentos no desenvolvimento destes modelos conceituais. A máquina não vai entender coisas como “meu agentes se comportam de um modo difícil de entender”. É preciso incluir esta complexidade no modelo, de modo claro. 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 31 livro The Crisis of the Aristocracy. O uso do computador era ainda considerado uma novidade, uma vez que os historiadores... lenta e timidamente potencialidades da nova começam a perceber sua lidar precisamente com prosopografia apura.32

começam a explorar as ferramenta tecnológica, eles quase ilimitada capacidade de o tipo de material que a

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: 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] ...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 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 33 34

Ibid. Ibid.

[39] 35

solucioná-los

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 35

Ibid. Ibid. 37 Ibid. 36

[40] agentes históricos, mas na mão dos historiadores: ...se uma subdivisão que depois se revela de importância crítica não for notada a tempo, usualmente é tarde demais para voltar e realizar todo o trabalho de novo uma dificuldade que é particularmente aguda em pesquisas auxiliadas por computadores, pois os códigos determinam as questões que podem ser depois formuladas.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

38

Ibid.

[41] escala ainda maior nos anos vindouros39

E os anos vindouros prometiam muito. O primeiro Manual de Computação para historiadores Em 1971, o historiador Edward Shorter lançava The historian and the Computer. A practical guide.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 39 40

Ibid.

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

[42] publicações, projetos e outras informações interessantes para o medievalista moderno. Ao longo de sua existência (durou entre 1971 e 1987), Computers trazia em cada edição uma lista dos projetos sobre história medieval que lançavam mão da informática. Ao todo, foram mencionados 354 projetos, a grande maioria nos Estados Unidos, seguidos de Canadá e França. Era um público que compreendia muito bem as palavras de Shorter: os equipamentos mais utilizados foram, de longe, os IBM 360 e 370, rodando, na maioria dos casos, o Fortran IV, além de outros 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º

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.

[43] Congresso Internacional de História Econômica. Apesar de breve, o texto continha a essência das reflexões iniciadas em 1972, quando se iniciara a aventura de Macfarlane e Sarah Harrison na tentativa de informatizar fontes para o estudo de 43 história local na Inglaterra. O resultado da pesquisa tornou-se 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. 42

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 methodoriented, 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 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 MACFARLANE, Alan, The computer revolution and local history. 44 MACFARLANE, Alan, Reconstructing historical Communities, Cambridge: Cambridge University Press, 1977.

[44] que o programa era adequado para os surveys criados pelos sociólogos, mas identificou seu limite: se ele dispunha de uma tabela com dados sobre a educação infantil e de outra com as informações sobre as famílias e quisesse cruzar os registros, não seria possível por conta do modelo conceitual próprio do pacote. Além disso, os pacotes da época, incluindo SPSS, não dispunham de elementos para incluir documentos inteiros, o que forçava a perda de dados involuntária, sem falar na incapacidade dos aplicativos em processar conteúdos incertos, imprecisos ou confusos, (fuzzy data). É na constatação dos limites do que era praticado na época por seus colegas que Macfarlane vai explorar dois caminhos até então desconhecidos pelos historiadores (e diria, também, pelos programadores). O primeiro e mais importante elemento é a adoção de um modelo de dados sourced-oriented (orientado pela fonte). Ao invés de extrair dos documentos os dados necessários para “cumprir” as exigências do programa, em campos possíveis, a fonte seria colocada integralmente dentro do programa, sem cortes. Isso seria possível graças à pré-edição dos textos, já que não haveria utilidade em simplesmente ter os textos integrais no computador. Seria importante contá-los, cruzá-los e aplicar outras metodologias de acordo com a necessidade. Deste modo, se um registro de batismo dizia que John, filho de Henry Abbott foi batizado em 5 de maio de 1607, 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)))

[45] [explicação: P = person (pessoa); N = name (nome); K = kinship (parentesco, indicando o tipo em “linguagem natural”, no caso, o inglês); E = event (evento); D = date (data)). Com o uso destes códigos e parênteses, um historiador explicaria à máquina o significado de cada coisa: datas, nomes, relacionamentos, etc. Demandava algo importante e válido, 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 45 falaremos mais adiante. Recentemente esta prática tornou-se modelo nas linguagens da internet, com a chamada web semântica, onde as palavras em um site não são mais amontoados de letras organizados pelo formato (texto grande ou pequeno, com negrito ou em itálico, etc). É semelhante ao que se utiliza com a linguagem XML, para dar um exemplo disponível na internet. Além da programação orientada pela fonte histórica estruturada de modo legível pelo computador, Macfarlane e Jardine foram pioneiros no uso de uma tecnologia ainda muito pouco conhecida na época: o modelo relacional de dados, hoje hegemônico a ponto de ser tomado quase como norma. Na época, utilizaram um manual sobre databases feito por C. J. Date, famoso não apenas pela didática na explicação dos recursos técnicos, mas igualmente por ter pertencido ao grupo que criou, dentro da IBM, a linguagem SQL. O uso desta tecnologia tornava possível cruzar dados de diferentes tabelas, que conteriam informações de fontes diversas, as quais permitiriam o emprego de análises como as de Henry e Wrigley. 45

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

[46] Manfred Thaller e o kleio No final dos anos 1970 a equipe de Manfred Thaller, no Max Plank Institute começou a desenvolver uma ferramenta para o processamento de dados em história. Chama-se kleio. Os primeiros resultados só começaram a surgir em meados da década seguinte. O kleio era um programa feito sob medida para a pesquisa histórica e orientado pela fonte: implicava na transcrição controlada da fonte para uma linguagem compreensível pelo computador, atribuindo códigos pré-definidos ao texto. Em boa medida, ele seguia de perto as formulações de 46 Macfarlane e há quem associe as duas iniciativas. 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 fonte e não segundo demandas de formulários prédefinidos. Neste sentido, havia igualmente uma economia de trabalho no preenchimento das fontes. O grande mérito de kleio era exatamente o fato de ser orientado pela fonte, a ponto de não interferir, ou de interferir muito pouco, na estrutura original da fonte. Segundo Thaller: 46

Ibid.

[47] Dados são administrados na forma de coleções de pedaços de texto, sem qualquer suposição sobre seu significado. Todas as suposições (o status social derivado de uma dada ocupação; o significado cronológico da data apontada para dias diferentes no calendário de várias dioceses; a taxa de câmbio de duas moedas diferentes) são geridos em tabelas completamente independentes 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 48 preocupado, precisamente pela falta deste tipo de recurso. 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 49 existência: o sistema Fichoz. Trata-se de uma base centrada no método, na qual há uma metodologia de trabalho prévia ao tratamento dos dados. A ideia principal é a de que é possível decompor a vida dos agentes históricos em “eventos”. Neste sentido, para cada ato seria criado um registro com informações 47

THALLER, Methods and techniques of historical computation. 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 LetrasHistória, v. 05, 2004. 48

[48] como a data, o local, a interação com outro agente e um campo de detalhamento. A interação e a análise detalhada de cada ato são os pontos fortes desta forma de coletar e organizar os dados. Deste modo, seriam possíveis buscas por indivíduos (biografias), por grupos de indivíduos (prosopografias), por pessoas conectadas com outras por algum motivo (análise de redes sociais) e por séries, de acordo com a necessidade. 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

50

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

[49] 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 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 (conceitual)

Figura 7 - Modelo de tabela (como em um formulário)

Como pudemos ver, é algo bem mais simples mais 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, 0402-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 53 quando lemos sobre os modelos de Macfarlane e Thaller. 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 multisource 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 54 historiadores, a atenção para os bancos de dados relacionais. 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 no 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 RELACIONAMENTO (sem dados)

Figura 10 - Exemplo de formulário com 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 55 fazer isso. Convém fazer um exercício mental para checar a 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

[62] fontes para testar o modelo. Não é preciso ter muitas, eu diria que uma amostra de 1% dos casos, se forem milhares e longos, já ajuda. Se forem milhares e curtos, eu recomendaria testar com 3% dos casos. Se forem centenas e longos, recomendaria 5%, 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. Tratase 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

[63] explicar como a base funciona para que qualquer pessoa possa entendê-la e ele deve informar quais são as tabelas que 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

[64] acessíveis e o leque de cores, de formas, de contornos e de outros detalhes é muito grande. A situação é diferente para quem usa bases SQL. Ou o utilizador usa as formas normais da maioria dos programas, geralmente muito simples, ou precisa criar um formulário em linguagem de programação (PHP, CSS) que permite praticamente tudo, mas com um custo de tempo e esforço enorme. Mesmo com as dificuldades apontadas acima, atrevo-me a apresentar algumas sugestões para quem vai criar sua base, independentemente da plataforma escolhida. Vamos começar com as diferentes formas de ver os dados, passando para as cores, as formas e outros elementos.

Formas diferentes de visualizar dados Ainda que isso varie de acordo com o programa utilizado, é muito comum diferenciarmos tabelas, formulários e listas. Atenção, caro leitor, para não ter dúvidas! Tabela aqui é diferente do que usamos até agora. Não é sinônimo de “entidade”, como aquele lugar onde guardamos conteúdos de diferentes tipos através de campos. É a imagem comum da tabela, uma forma de ver dados em que se usam linhas e colunas. Eles podem ter (e geralmente 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 tabelavisual, 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 tabelasvisuais 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 tabelaentidade, 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

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

[68] fundo branco, que pode ofuscar quem trabalha por muitas horas, especialmente em monitores muito iluminados, mas não é escura o suficiente para atrapalhar a leitura. É uma cor associada à tranquilidade, ao mar, à vastidão do céu, entre outras coisas que você não verá durante seu trabalho na base. Testei muito com outras cores e não tive resultados melhores. Convém usar as cores como aliadas na criação dos visuais, tanto formulários quanto tabelas. Se usarmos aquele azul clarinho, que indiquei acima para uma tabela, devemos intercalar as linhas das tabelas usando outra cor - eu diria o branco - para facilitar a observação. Isso é melhor do que usar contornos, que poluem tanto quanto o excesso de campos visíveis. Da mesma forma, nos formulários, convém usar diferentes tons de azul, como aquele, e o mesmo branco para certos campos. Isso ajuda a “disciplinar o olho” na tela, de tal maneira que possamos acelerar a identificação de dados e, até, encontrar coisas fora do lugar com maior facilidade. Como queremos usar as cores como aliadas nesse processo de disciplinar o olho, podemos usar outras gamas, preferencialmente se forem claras. Não convém usar amarelo, tem efeito pior do que o branco. Recomendo usar rosa-claro, verde-claro (RGB 244,255,244), laranja-claro e marrom-claro. Mas é importante ter cuidado para não abusar e transformar a base num programa infantil. Isso vai criar um efeito de confusão e pode atrapalhar a observação dos dados. Parece mais prudente usar as cores somente em campos muito específicos, para destacar certas informações. De resto, um fundo azul-claro, com campos com a cor branca, usando um contorno cinzaescuro parece uma pedida melhor. Quem quiser experimentar, recomenda-se reflexão sobre as horas que ficará na frente da bem altos indica que a cor é clara, já que o branco é 255, 255, 255 e o preto 0, 0, 0.

[69] tela. Quem não quiser, já tem aí uma sugestão bem clara.

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

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

Figura 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. 57 Há quem fale em “boas práticas” nas bases de dados. Prefiro não adotar esse vocabulário, mas vou criar uma lista de problemas com algumas ideias de como resolvê-los, justificando, com argumentos teóricos e técnicos, meus motivos. Homônimos Identificar pessoas é algo tão complexo que já foi tema de um livro clássico: Identifying people in the past, de E. Wrigley. A obra foca em pesquisas voltadas para o cruzamento 58 de fontes e o uso sistemático do nome como base do trabalho. 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 59 ariana” pelo qual o historiador construiria seu caminho. Há 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 60 dessa opinião, como o próprio Alan Macfarlane. Reconheço que isso tem um custo: é preciso ter pessoas capacitadas para transcrever, que não leiam algo diverso do que está no original e saibam desdobrar corretamente as tradicionais abreviaturas. É mais demorado e trabalhoso, mas, feitas a atualização e 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 duas datas, 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 61 importante. 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 62 Kevin Schürer quando argumenta que é impossível prever 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 História 61

e

Talvez seja a maior especificidade da relação entre Informática: os dados dos historiadores,

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

[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 63 mínima e máxima de páginas por documento. Por exemplo, se pretendo trabalhar com processo-crime de uma localidade ao longo de 20 anos, é importante saber, de antemão, de quantos processos estou falando. O conhecimento do conjunto vai ajudar 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 64 esquecidos. Para isso, há o coordenador.

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á 65 apresentava essa preocupação em 1985. Geralmente, os arquivos estão longe dos computadores, ainda que isso tenha mudado muito desde a invenção e popularização de laptops e câmaras digitais. Mas nem todos os arquivos permitem estes equipamentos, e há, inclusive, arquivos que não têm tomada disponível para pesquisadores. Outra questão que se coloca é a “hospedagem” do banco de dados, sobre onde ele deve estar armazenado. Se for uma pesquisa individual, a solução é fácil: no computador dessa pessoa. Mas quando temos dois, a pergunta já é qualificada. Devemos criar duas cópias do arquivo e juntar tudo depois? Devemos colocar o arquivo num servidor da internet? Só um 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 ruim é que podem errar a sugestão, 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 um descuido. Outra opção pode ser

[93] 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". 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 vírgula.

[94] 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 66 objetos distribuídos de outra forma." É certo que partimos de um problema de pesquisa, mas o caminho inclui uma parada para um longo contato com a empiria. O segundo motivo para a polêmica é que muitas pessoas já usam ou pretendem construir bases direcionadas para certos objetivos, sem um grande desmonte da empiria ou sem um foco maior nesse esforço. Para ajudar o argumento dessas pessoas, vou até citar um bom exemplo de base de dados desse 67 tipo: o projeto The Trans-Atlantic Slave Trade Database. Tratase de um banco de dados com mais de 35.000 viagens de navios 66

DE CERTEAU, A operação histórica, p. 30. Voyages Database. 2009., Voyages: The Trans-Atlantic Slave Trade Database., disponível em: , acesso em: 4 jan. 2014. 67

[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 68 que preservam a estrutura original da informação". Usando 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 Código_livro*

TIPO OBS 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 Código_livro* Código_registro* Transcrição Local de nascimento Local do batizado Padre celebrante Quem redigiu Data do batismo Data do nascimento Nome do batizando

TIPO Texto Texto Texto Texto Texto Texto Texto Data Texto Data Texto Texto

ou

OBS Máximo 12 carac. Máximo 19 carac. Livre Livre Livre Caixa de escolha Caixa de escolha Livre

ou

Livre 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 Remetente Local do remetente Destinatário Local do destinatário Data Texto da carta Código_carta

TIPO Texto Texto Texto Texto Data ou texto Texto Texto

OBS Livre Livre Livre Livre AAAA-MM-DD Livre Livre

Campos opcionais que podem ser úteis: CAMPO Pessoas citadas Locais citados

TIPO Texto Texto

OBS Livre Livre

[110] Temas

Texto

Período abarcado Resumo Recortes Recursos discursivos

Texto Texto Texto Texto

Livre ou caixa de opções Livre Livre Livre 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 69 inquisidor como antropólogo”, de Carlo Ginzburg. Serve para 69

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.

[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 70 inglesa , assim como seu artigo de 1971, que já apresentamos no início desta obra. Há outros livros importantes, inclusive muitas coletâneas nacionais, mas seria muito longo apresentar todas aqui. Isso é uma tarefa do “desenvolvedor” da base, que deverá tomar essas referências 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 71 aplicá-la com os devidos créditos. 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, 72 a tese de Pierre Goubert sobre Beauvais. Desde então, foram 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 74 as listas nominativas. E isso não significa ignorar a opção de 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 socioprofessionnel. 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 socioprofessionelle. 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: . 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: . Acesso em: 27 set. 2013. Database Wikipedia. Disponível em: . Acesso em: 27 set. 2013. Database - Wikipedia, the free encyclopedia. Disponível em: . Acesso em: 27 set. 2013. Index Thomisticus. Disponível em: . Acesso em: 27 set. 2013. Voyages Database. 2009. Voyages: The Trans-Atlantic Slave Trade Database. Disponível em: . Acesso em: 4 jan. 2014.