10. Um contexto de uso
• ISIS ainda é largamente utilizado em bibliotecas,
museus, arquivos públicos, escritórios de advocacia
• BIREME/OPAS/OMS: convênio entre a Escola Paulista
de Medicina (Unifesp), Organização Panamericana da
Saúde e Ministério da Saúde do Brasil, com a missão
de organizar, indexar e disseminar a produção
científica da América Latina e do Caribe
• BIREME usa ISIS há 25 anos, SOLR/Lucene há 5 anos
e CouchDB há alguns meses
11. A missão da nossa equipe
• Renovar os métodos, práticas e as ferramentas de
desenvolvimento
• Práticas ágeis
• Ferramentas e métodos de trabalho Open Source
• Primeiro passo: de PHP sem framework para Python
com Django
12. Projeto piloto
• OpenTrials
• sistema de registro de ensaios clínicos
• testes de medicamentos e procedimentos com
seres humanos
• Registro Brasileiro de Ensaios Clínicos
• Financiado pelo Ministério da Saúde e OPAS
• Operado pela Fiocruz com suporte da BIREME
28. Retrospectiva
• No projeto piloto com Python e Django, optamos por
não inovar no banco de dados, usamos MySQL, que já
era conhecido da instituição
• O ReBEC está em produção desde 2010
• Ganhamos um ótimo contra-exemplo: a aplicação
OpentTrials ficaria muito mais simples usando um
modelos de dados não normalizado
29.
30. Onde a normalização
atrapalhou
• Traduções: para alguns campos, precisamos ter o
texto em n línguas
• Mas nunca vamos querer acessar estes campos fora
do contexto do resto do registro principal, eles são de
fato parte integrante e inseparável dele
• Não queremos que eles possam ser atualizados
indendentemente do registro principal
31. Onde a normalização
atrapalhou 2
• Vários campos repetitivos viraram tabelas auxiliares
• Versionamento
• Quando um registro (ou registro auxiliar) é
atualizado, o registro inteiro (e seus registros
auxliares) precisam ser revalidados pelos revisores
(para verificar inconsistências) e re-publicados
• Mas o histórico não pode ser perdido!
32. Onde a normalização
atrapalhou 3
• Auditoria: precisamos saber sempre que qualquer
dado de um registro (ou registros auxiliares) foi alterado
• Jamais um registro de uma tabela auxiliar pode ser
atualizado independente do registro principal
• Ex: o contato científico que foi registrado
originalmente nunca poderá ser esquecido
• A descrição da metodologia de intervenção é como
um contrato do pesquisador com a sociedade
33. Como resolvemos?
• Criamos uma app chamada django-fossil (no Github)
• O django-fossil cria um fósil de cada registro publicado
• Um fóssil é um registro desnormalizado,
“petrificado”, imutável
• Usa como chave primária uma assinatura digital
(hash) do conteúdo
• Tem uma chave estrangeira que aponta para a
versão anterior
Solução inspirada no
CouchDB e no GIT!
36. Persistência poliglota
• Usar um BD relacional para aproveitar o seu
conhecimento e ferramental existente
• Integrar um BD NoSQL apropriado assim que o
modelo relacional deixa de ser parte da solução e
começa a ser parte do problema
40. Document databases
• Bases de dados documentais
• ISIS é um exemplo antigo dessa categoria
• Modelo de dados semiestruturado, parecido com
JSON (mais simples que XML)
• O esquema é armazenado junto com cada registro
• Exemplos modernos e Open Source:
• CouchDB e MongoDB
41.
42. Para o OpenTrials/ReBEC
• A melhor solução é o CouchDB
• Mas o MongoDB também seria apropriado, com
todas as chaves de durabilidade ligadas
• Motivo fundamental: MVCC (multi-version concurrency
control), garante que a aplicação não consegue
sobrescrever acidentalmente um registro
• Para fazer update, é obrigatório informar o hash da
versão anterior, e assim provar que você não está
fazendo uma atualização com dados vencidos
sem saber
43. Minicurso gratuito em 1 de novembro, 19h00:
OO sem Sotaque em Python
http://python.globalcode.com.br
