1. Interoperabilidade entre
banco de dados
Msc. Mauro C. Pichiliani (mauro@pichiliani.com.br)
@pichiliani
1

2. Sobre mim
• Mestre e doutorando em computação pelo ITA
• Escritor da SQL Magazine, Fórum Access, Java
Magazine, SQLServerCentral.com e outras
• Colaborador do iMasters há 10 anos
• Autor do livro “Conversando sobre banco de
dados” (http://migre.me/ahlSY)
• Co-autor do @databasecast
• Blog: http://pichiliani.com.br
2

3. Roteiro
• Cenário multi-banco
• Conceitos comuns
• Interoperabilidade na administração
• Trocando objetos, dados e instruções
• Conclusão
3

4. Cenário multi-banco (1)
• Ambientes, plataformas e bancos de dados diferentes são uma
realidade
• O banco de dados nunca trabalha sozinho:
– ERP, PDV, CMS, Controle de acesso, IRPF, Intranet
– Sistemas customizados e desenvolvimento interno
– Sistemas multi-banco
• Principais SGBDR: SQL Server, Oracle, MySQL, PostgreSQL e DB2
• Novo talento no pedaço: NoSQL e newSQL
• Não esqueça dos BDs na núvem…
• Profissionais de desenvolvimento, administração e infra devem dominar
individualmente os bancos de dados
• E também saber como eles devem unir forças e trabalhar junto
• Tarefas comuns: montar um ambiente de testes/homologação,
transferir dados, criar uma solução de replicação, analisar, comparar e
estudar o desempenho de tarefas semelhantes em diferentes bancos
de dados, etc 4

5. Cenário multi-banco (2) - Planejamento
• A maioria dos sistemas e aplicações trabalha com apenas um BD
• Suporte a diferentes BDs sub-utiliza recursos do mesmo. Mas fornece algum
tipo de escolha para o cliente
• Geralmente software livre não se preocupa em ser multi-banco. E aplicações
web também não
• Aplicação multi-banco requer desenvolvimento adicional e camadas adicionais
de software
• Há também cenários de dados não estruturados, arquivos texto e bancos de
dados embarcados
• Em cenário multi-plataforma (desktop, web, app. móveis, etc) tendência é
centralizar informações em um único BD
• Planejamento da interoperabilidade:
– Documentação (diagramas, especificação, fluxo de dados, etc)
– Saiba até onde é possível ir
– Avalie com cuidado troca de BDs para consolidar dados
– Mudar banco de dados de aplicação existente tem impacto profundo
5

6. Conceitos comuns (1)
• SGBDR (e alguns NoSQL) sofrem pressão do mercado para suportar
recursos similares: SQL, backup, segurança, tabelas, constraints,
programação, etc
• A execução e suporte de diversas tarefas comuns se torna um
commodity. E o profissional deve saber como fazer a mesma tarefa
com tecnologias diferentes
• Sempre dar atenção aos conceitos básicos e fundamentos
• Há diferenças de conceitos, nomenclaturas, siglas, especificações e
peculiaridades para cada BD. Ex: Log, configurações, opções de
crescimento, etc
• Foco não é comparação entre bancos de dados. Artigo “Comparando a
dificuldade nos bancos de dados” na SQL Magazine 75
http://migre.me/ahnEF
• EULA impede comparações de desempenho com alguns BDs
• Há testes padrões do mercado como o TPC (http://tpc.org)
• Não perca muito tempo discutindo funcionalidades ou comparando.
Conheça suas opções e parta para o trabalho! 6

7. Conceitos comuns (2)
• Alguns fornecedores se preocupam mais com interoperabilidade no BD
do que outros
• Procure por recursos que vão além de importação/exportação
• Procure evitar formatos intermediários
• Há sempre a questão da segurança e confidencialidade
• Geralmente é preciso contar com tecnologias externas para
conectividade: ODBC, JDBC, OLE Db, drivers específicos e conectores
• Dependendo do contexto pode ser interessante recorrer a ferramentas
ETL do próprio fabricante ou de terceiros. Sugestões:
– Microsoft SQL Server Integration Server (SSIS http://migre.me/ahoeL)
– Oracle Database Utilities http://migre.me/ahoiZ
– PDI (antigo Kettle) http://kettle.pentaho.com/
– Talend open Studio http://migre.me/ahooW
7

8. Interoperabilidade na administração (1)
• Todos os BDs possuem ferramentas de console (shell) que permitem
trabalhar com scripts e arquivos individuais
• Fornecem boa produtividade, porém tem péssima usabilidade para
tarefas administrativas. Não há recursos de interoperabilidade além do
que o SO fornece (pipes)
• Tarefas administrativas podem ser realizadas por script, mas há
ferramentas com GUI. Exemplos:
Management Studio Oracle Enterprise Manager
8

9. Interoperabilidade na administração (2)
MySQL Workbench PgAdmin
RockMongo
Futon
9

10. Interoperabilidade na administração (3)
DBArtisan da Embarcadeiro http://migre.me/ahqN9
• Ferramentas com GUI auxiliam muito certas tarefas administrativas
• Porém praticamente não há recursos de interoperabilidade entre dados, objetos
e tarefas administrativas
• Para monitoria: artigo “Monitoramento de Base de Dados” da SQL Mag. 54
http://migre.me/ahqXE.
• Soluções agregadoras: Nagios (http://www.nagios.org/), System Center (
10
http://migre.me/ahr5Y) e FogLight (http://migre.me/ahrgP)

11. Trocando objetos, dados e instruções (1)
• Alguns bancos de dados possuem recursos para acessar objetos entre
diferentes BDs junto com as instruções SQL
• O SQL Server possui o conceito de servidores linkados: requer ODBC, provider
OLE DB ou provider .NET
• O Oracle possui o recurso chamado Database Link Heterogeneous Services
(DB-LINK). Acesso a fontes de dados ODBC. http://migre.me/ahv1o
• Linked servers e DB-Link fornecem algo do tipo:
SELECT * FROM {FONTE_REMOTA}…{OBJETO}
• PostgreSQL também possui DBLink mas apenas entre servidores PostgreSQL. Projetos
alternativos:
– DBLink-ODBC: http://sourceforge.net/projects/dblink-odbc/
– DBLink-TDS: http://pgfoundry.org/projects/dblink-tds/
• O MySQL não possui recurso semelhante. Mas há o Storage Engine FEDERATED que
permite acessar tabelas de outro MySQL remotamente http://migre.me/ahv9e
• Bancos NoSQL e newSQL não possuem recursos de interoperabilidade direta em
instruções
11

12. Trocando objetos, dados e instruções (2)
• Todos os BDs possuem recursos para importar e exportar dados. Geralmente
no formato CSV (Comma-separated values) ou XML
• Replicação heterogência envolve BDs de diferentes fornecedores
• Há recursos para implementar replicação de dados síncrona, assíncrona ou
multi-síncrona entre diferentes BDs
• Cuidado: não confudir replicação com tecnologias para escalabilidade
(sharding), alta disponibilidade (cluster) ou disaster e recovery
• Deve-se planejar muito bem como será a replicação. Aspectos principais:
– Papéis (masters ou slaves) e locais de replicação
– Latência e disponibilidade
– Conversão de tipos de dados
– Fluxo de dados (direção) e forma de replicação
– Conflitos
– Objetos, filtros, índices full-text e outros elementos do banco de dados
• Geralmente a replicação é uma maravilha quando tudo funciona bem
• Mas quando algum problema aparece a situação vira um inferno
• Alguns fornecedores de BD provém replicação heterogênea. Espere apenas recursos
básicos neste contexto
• Há diversas ferramentas de terceiros para replicações heterogêneas
• Importante: replicar dados NÃO faz com que sistemas sejam multi-banco 12

13. Trocando objetos, dados e instruções (3)
• SQL Server (> 2000) pemite replicação nativa apenas para Oracle
• Há como montar solução utilizando servidores linkados+view+triggers
• Oracle possui dois recursos: view materializada e Oracle Streams para
qualquer fonte ODBC
• PostgreSQL, MySQL, DB2, NoSQL e newSQL não possuem recursos para
replicar dados para BD de outros fabricantes. Alternativas de terceiros:
• Código livre:
– Tungsten Replicator (http://migre.me/ahvKy): replicação JDBC em linha de comando
– SymmetricDS (http://migre.me/ahvRw): sincronia de tabelas
– DBReplicator (http://dbreplicator.org/): replicação JDBC com GUI
– Daffodil Replicator (http://migre.me/ahwdR): versão enterprise e open source
• Proprietárias:
– DBMoto (http://migre.me/ahw2g)
– SharePlex for Oracle (http://migre.me/ahw84)
– ObjectMMRS (http://migre.me/ahwnI)
– InfoSphere Data Replication (http://migre.me/ahww6)
• Nota: algumas ferramentas ETL também fazem replicação heterogênea
13

14. Trocando objetos, dados e instruções (4)
• Em muitas situações desejamos converter uma instrução SQL de um banco
para outro
• Formatador on-line de SQL: http://migre.me/ahwIi
• Testadores de SQL: SQLFiddle (http://sqlfiddle.com/) e Ideone (
http://t.co/1VqDRoZs) e Try MongoDB (http://try.mongodb.org/)
• SwisSQL Console (http://migre.me/ahxef) separação e conversão de instruções
14

15. Trocando objetos, dados e instruções (5)
• SQL Translator (http://migre.me/ahxjR) scripts do Linux para conversão de
instruções SQL
• SQL Injection Knowledge Base: http://t.co/Hc6PLWdE
• Tabelas, guias e posters de conversões de sintaxe SQL e NoSQL. Nota:
atualmente há muitas linguagens *QL de acordo com cada produto
• Site com lista de Cheat-Sheets: http://www.cheat-sheets.org/
• Diversas APIs, bibliotecas, frameworks, camadas, components, design patters e
arquiteturas para trabalhar com sistemas multi-banco
• Exemplo: SwisSQL API (http://migre.me/ahxIL)
• Muitos são ORM e servidores de cache também! Cuidado com soluções que
prometem interoperabilidade e na verdade substituiem o seu BD por outro
• Há soluções amálgamas e com alguma compatibilidade entre BDs
– Fyracle (Oracle-mode Firebird) http://migre.me/ahoy0
– DotNetFirebird (Access, MSDE e Firebird) http://migre.me/ahzHG
– SQLite (SQL Server) http://www.sqlite.org/ e SharpHSQL 15
(http://www.codeplex.com/sharphsql)

16. Conclusão
 Ambiente multi-banco e diferentes abordagens (SQL, NoSQL,
newSQL) convivendo junto
 Conceitos e tecnologias comuns x Novas idéias
 Sofware proprietário com mais recursos de interoperabilidade
 Poucos recursos para interoperabilidade de tarefas
administrativas
 Muitos recursos para troca de dados, instruções e objetos
entre BDs diferentes
 Ainda estamos na era da especialização e divergência
 Novas e interessantes possibilidades para avanços nas área
de interoperabilidade, usabilidade, comunicação e
compatibilidade entre BDs diferentes
16