Antes do ODBCEdit
A introdução da base de dados relacional baseada no mainframe durante a década de 1970 levou a uma proliferação de métodos de acesso aos dados. Geralmente estes sistemas funcionavam em conjunto com um processador de comando simples que permitia aos utilizadores digitar comandos semelhantes aos ingleses, e receber saída. Os exemplos mais conhecidos são SQL da IBM e QUEL do projecto Ingres. Estes sistemas podem ou não permitir que outras aplicações acedam directamente aos dados, e as que utilizaram uma grande variedade de metodologias. A introdução de SQL visava resolver o problema da padronização da linguagem, embora subsistissem diferenças substanciais na implementação.
Desde que a linguagem SQL tinha apenas características de programação rudimentares, os utilizadores queriam frequentemente utilizar SQL dentro de um programa escrito noutra linguagem, digamos Fortran ou C. Isto levou ao conceito de SQL Embutida, que permitiu que o código SQL fosse incorporado noutra linguagem. Por exemplo, uma instrução SQL como SELECT * FROM city
poderia ser inserida como texto dentro do código fonte C, e durante a compilação seria convertida num formato personalizado que chamava directamente uma função dentro de uma biblioteca que passaria a instrução para o sistema SQL. Os resultados retornados das declarações seriam interpretados de volta para formatos de dados em C como char *
usando código de biblioteca semelhante.
Existiram vários problemas com a abordagem SQL Embutida. Como as diferentes variedades de SQL, os SQLs Embutidos que os utilizavam variavam muito, não só de plataforma para plataforma, mas mesmo entre linguagens numa só plataforma – um sistema que permitisse chamadas para o DB2 da IBM teria um aspecto muito diferente de um sistema que chamasse para o seu próprio SQL/DS. Outro problema chave para o conceito de SQL incorporado era que o código SQL só podia ser alterado no código fonte do programa, pelo que mesmo pequenas alterações à consulta exigiam um esforço considerável do programador para a modificar. O mercado SQL referia-se a isto como SQL estática, versus SQL dinâmica que podia ser alterada a qualquer momento, como as interfaces de linha de comando que eram fornecidas com quase todos os sistemas SQL, ou uma interface de programação que deixava a SQL como texto simples até ser chamada. Os sistemas SQL dinâmicos tornaram-se um foco principal para os fornecedores de SQL durante os anos 80.
Bases de dados mainframe mais antigas, e os mais recentes sistemas baseados em microcomputadores que se baseavam neles, geralmente não tinham um processador de comando do tipo SQL entre o utilizador e o motor da base de dados. Em vez disso, os dados eram acedidos directamente pelo programa – uma biblioteca de programação no caso de grandes sistemas mainframe, ou uma interface de linha de comando ou sistema de formulários interactivos no caso de dBASE e aplicações semelhantes. Os dados do dBASE não podiam geralmente ser acedidos directamente por outros programas em execução na máquina. A esses programas pode ser dada uma forma de aceder a esses dados, muitas vezes através de bibliotecas, mas não funcionaria com qualquer outro motor de base de dados, ou mesmo diferentes bases de dados no mesmo motor. Com efeito, todos esses sistemas eram estáticos, o que apresentava problemas consideráveis.
Early effortsEdit
Em meados dos anos 80, a rápida melhoria dos microcomputadores, e especialmente a introdução da interface gráfica do utilizador e programas de aplicação ricos em dados como o Lotus 1-2-3 levou a um interesse crescente na utilização de computadores pessoais como a plataforma cliente-servidor de escolha na computação cliente-servidor. Sob este modelo, grandes mainframes e minicomputadores seriam utilizados principalmente para servir dados através de redes locais a microcomputadores que interpretariam, mostrariam e manipulariam esses dados. Para este modelo funcionar, uma norma de acesso aos dados era um requisito – no campo do mainframe era altamente provável que todos os computadores de uma loja fossem de um fornecedor e os clientes fossem terminais de computador a falar directamente com eles, mas no campo do micro não existia tal normalização e qualquer cliente podia aceder a qualquer servidor utilizando qualquer sistema de rede.
No final dos anos 80, havia vários esforços em curso para fornecer uma camada de abstracção para este fim. Alguns destes estavam relacionados com mainframe, concebidos para permitir que programas em execução nessas máquinas traduzissem entre a variedade de SQL’s e fornecessem uma única interface comum que poderia então ser chamada por outros programas mainframe ou microcomputador. Estas soluções incluíam a Arquitectura de Base de Dados Relacionais Distribuídos da IBM (DRDA) e a Linguagem de Acesso a Dados da Apple Computer. Muito mais comuns, contudo, eram sistemas que funcionavam inteiramente em microcomputadores, incluindo uma pilha de protocolos completa que incluía qualquer rede necessária ou suporte de tradução de ficheiros.
Um dos primeiros exemplos de tal sistema foi o DataLens da Lotus Development, inicialmente conhecido como Blueprint. Blueprint, desenvolvido para 1-2-3, suportava uma variedade de fontes de dados, incluindo SQL/DS, DB2, FOCUS e uma variedade de sistemas de mainframe semelhantes, bem como sistemas microcomputadores como dBase e os primeiros esforços da Microsoft/Ashton-Tate que acabariam por se desenvolver para o Microsoft SQL Server. Ao contrário do ODBC posterior, o Blueprint era um sistema puramente baseado em código, faltando qualquer coisa que se aproximasse de uma linguagem de comando como SQL. Em vez disso, os programadores utilizavam estruturas de dados para armazenar a informação da consulta, construindo uma consulta ligando muitas destas estruturas entre si. Lotus referia-se a estas estruturas compostas como árvores de consulta.
Ao mesmo tempo, uma equipa da indústria incluindo membros da Sybase (Tom Haggin), Tandem Computers (Jim Gray & Rao Yendluri) e Microsoft (Kyle G) estavam a trabalhar num conceito SQL dinâmico padronizado. Grande parte do sistema baseava-se no sistema DB-Library da Sybase, com as secções específicas da Sybase-specificamente removidas e várias adições para suportar outras plataformas. A DB-Library foi ajudada por uma mudança de sistemas de bibliotecas que estavam estreitamente ligados a uma linguagem específica, para sistemas de bibliotecas que eram fornecidos pelo sistema operativo e exigiam que as linguagens dessa plataforma estivessem em conformidade com as suas normas. Isto significava que uma única biblioteca podia ser utilizada com (potencialmente) qualquer linguagem de programação numa dada plataforma.
O primeiro rascunho da API de Acesso a Dados da Microsoft foi publicado em Abril de 1989, mais ou menos ao mesmo tempo que o anúncio da Lotus do Projecto. Apesar da grande liderança do projecto Blueprint – estava em execução quando o MSDA ainda era um projecto em papel – a Lotus acabou por se juntar aos esforços do MSDA, uma vez que se tornou claro que o SQL se tornaria o padrão de base de dados de facto. Após um considerável contributo da indústria, no Verão de 1989 a norma tornou-se SQL Connectivity (SQLC).
SAG e CLIEdit
Em 1988 vários fornecedores, na sua maioria das comunidades Unix e base de dados, formaram o SQL Access Group (SAG) num esforço para produzir uma única norma básica para a linguagem SQL. Na primeira reunião, houve um debate considerável sobre se o esforço deveria ou não funcionar apenas na própria linguagem SQL, ou tentar uma padronização mais ampla que incluísse também um sistema dinâmico de linguagem SQL, aquilo a que chamavam uma Call Level Interface (CLI). Enquanto assistia à reunião com um projecto inicial do que então ainda era conhecido como MS Data Access, Kyle Geiger da Microsoft convidou Jeff Balboni e Larry Barnes da Digital Equipment Corporation (DEC) a juntarem-se também às reuniões do SQLC. SQLC era uma solução potencial para a convocatória do CLI, que estava a ser liderada por DEC.
p>O novo “bando de quatro” SQLC, MS, Tandem, DEC e Sybase, trouxe uma versão actualizada do SQLC para a próxima reunião do SAG em Junho de 1990. O SAG respondeu abrindo o esforço padrão a qualquer projecto concorrente, mas das muitas propostas, apenas a Oracle Corp tinha um sistema que apresentava uma concorrência séria. No final, o SQLC ganhou os votos e tornou-se o projecto padrão, mas só depois de grandes partes do API terem sido removidas – o documento padrão foi aparado de 120 páginas para 50 durante este período. Foi também durante este período que o nome Call Level Interface foi formalmente adoptado. Em 1995, SQL/CLI tornou-se parte da norma SQL internacional, ISO/IEC 9075-3. O próprio SAG foi assumido pelo grupo X/Open em 1996, e, com o tempo, tornou-se parte do The Open Group’s Common Application Environment.
MS continuou a trabalhar com a norma SQLC original, mantendo muitas das características avançadas que foram removidas da versão CLI. Estas incluíam funcionalidades como cursores scrollable, e consultas de informação de metadados. Os comandos na API foram divididos em grupos; o grupo Core era idêntico ao CLI, as extensões de Nível 1 eram comandos que seriam fáceis de implementar nos drivers, enquanto que os comandos de Nível 2 continham as características mais avançadas como cursores. Uma norma proposta foi lançada em Dezembro de 1991, e o input da indústria foi recolhido e trabalhado no sistema até 1992, resultando em mais uma mudança de nome para ODBC.
JET e ODBCEdit
Durante este tempo, a Microsoft estava no meio do desenvolvimento do seu sistema de base de dados Jet. Jet combinou três subsistemas primários; um motor de base de dados baseado em ISAM (também chamado Jet, de forma confusa), uma interface baseada em C que permite às aplicações aceder a esses dados, e uma selecção de bibliotecas de ligação dinâmica de controladores (DLL) que permitiu à mesma interface C redireccionar a entrada e saída para outras bases de dados baseadas em ISAM, como Paradox e xBase. Jet permitiu a utilização de um conjunto de chamadas para aceder a bases de dados comuns de microcomputadores de uma forma semelhante à do Blueprint, passando então a designar-se DataLens. Contudo, Jet não utilizava SQL; tal como DataLens, a interface era em C e consistia em estruturas de dados e chamadas de funções.
Os esforços de normalização SAG apresentaram uma oportunidade para a Microsoft adaptar o seu sistema Jet ao novo padrão CLI. Isto não só tornaria o Windows uma plataforma de primeira linha para o desenvolvimento da CLI, como também permitiria aos utilizadores utilizar SQL para aceder tanto a Jet como a outras bases de dados. O que faltava era o analisador SQL que pudesse converter essas chamadas da sua forma de texto para a interface C utilizada no Jet. Para resolver isto, a MS associou-se ao PageAhead Software para utilizar o seu processador de consulta existente, SIMBA. O SIMBA foi utilizado como analisador acima da biblioteca C do Jet, transformando o Jet numa base de dados SQL. E como a Jet podia encaminhar essas chamadas baseadas em C para outras bases de dados, isto também permitiu à SIMBA consultar outros sistemas. A Microsoft incluiu controladores para o Excel para transformar os seus documentos de folha de cálculo em tabelas de base de dados SQL-acessível.
Release and continued developmentEdit
ODBC 1.0 foi lançado em Setembro de 1992. Na altura, havia pouco suporte directo para bases de dados SQL (versus ISAM), e os primeiros drivers foram notados pelo fraco desempenho. Parte disto era inevitável devido ao caminho que as chamadas tomavam através da pilha baseada em Jet; as chamadas ODBC para bases de dados SQL foram primeiro convertidas do dialecto SQL da Simba Technologies para o formato interno baseado em C da Jet, depois passadas para um driver para conversão de volta em chamadas SQL para a base de dados. Tanto a Digital Equipment como a Oracle contrataram a Simba Technologies para desenvolver controladores também para as suas bases de dados.
Mean entretanto, o esforço padrão CLI arrastou-se, e só em Março de 1995 é que a versão definitiva foi finalizada. Até então, a Microsoft já tinha concedido à Visigenic Software uma licença de código fonte para desenvolver ODBC em plataformas não Windows. A Visigenic portou ODBC para uma grande variedade de plataformas Unix, onde ODBC rapidamente se tornou o padrão de facto. O “Real” CLI é hoje em dia raro. Os dois sistemas permanecem semelhantes, e muitas aplicações podem ser portadas de ODBC para CLI com poucas ou nenhumas alterações.
Acima do tempo, os vendedores de bases de dados assumiram as interfaces dos condutores e forneceram ligações directas aos seus produtos. Saltar as conversões intermédias de e para Jet ou invólucros semelhantes resultou frequentemente num desempenho superior. Contudo, nessa altura, a Microsoft tinha mudado o foco para o seu conceito OLE DB (recentemente reintegrado), o que proporcionava acesso directo a uma maior variedade de fontes de dados, desde livros de endereços a ficheiros de texto. Seguiram-se vários sistemas novos que desviaram ainda mais a sua atenção de ODBC, incluindo ActiveX Data Objects (ADO) e ADO.net, que interagiram mais ou menos com ODBC ao longo das suas vidas.
Como a Microsoft desviou a sua atenção de trabalhar directamente em ODBC, o campo Unix estava cada vez mais a abraçá-lo. Isto foi impulsionado por duas mudanças dentro do mercado, a introdução de interfaces gráficas de utilizador (GUIs) como o GNOME, que proporcionava a necessidade de aceder a estas fontes de forma não textual, e o aparecimento de sistemas de base de dados de software aberto como PostgreSQL e MySQL, inicialmente sob Unix. A posterior adopção de ODBC pela Apple para a utilização do pacote iODBC padrão Unix-side Mac OS X 10.2 (Jaguar) (que o OpenLink Software tinha fornecido independentemente para Mac OS X 10.0 e mesmo Mac OS 9 desde 2001) cimentou ainda mais ODBC como padrão para o acesso a dados entre plataformas.
Sun Microsystems utilizou o sistema ODBC como base para o seu próprio padrão aberto, Java Database Connectivity (JDBC). Na maioria das formas, o JDBC pode ser considerado uma versão de ODBC para a linguagem de programação Java em vez de C. As pontes JDBC para ODBC permitem aos programas baseados em Java aceder a fontes de dados através de drivers ODBC em plataformas sem um driver JDBC nativo, embora estes sejam agora relativamente raros. Inversamente, as pontes ODBC para JDBC permitem aos programas baseados em C aceder a fontes de dados através de drivers JDBC em plataformas ou a partir de bases de dados sem drivers ODBC adequados.
ODBC todayEdit
ODBC continua a ser amplamente utilizado hoje em dia, com drivers disponíveis para a maioria das plataformas e a maioria das bases de dados. Não é raro encontrar drivers ODBC para motores de bases de dados que se destinam a ser incorporados, como SQLite, como uma forma de permitir que as ferramentas existentes actuem como front-ends para estes motores para testes e depuração.
No entanto, o aumento da computação em thin client utilizando HTML como formato intermédio reduziu a necessidade de ODBC. Muitas plataformas de desenvolvimento web contêm ligações directas a bases de dados alvo – sendo o MySQL muito comum. Nestes cenários, não há acesso directo ao lado do cliente nem múltiplos sistemas de software cliente a suportar; tudo passa pela aplicação HTML fornecida pelo programador. A virtualização que ODBC oferece já não é uma exigência forte, e o desenvolvimento de ODBC já não é tão activo como era outrora. Mas quando ODBC já não é um forte requisito para a programação cliente-servidor, agora ODBC é mais importante para o acesso a dados e virtualização da integração de dados em cenários de análise de dados e ciência de dados. Estes novos requisitos reflectem-se em novas características ODBC 4.0 tais como dados semi-estruturados e hierárquicos, autenticação web e melhoria de desempenho.
Histórico de versõesEditar
Histórico de versões:
- 1.0: lançado em Setembro de 1992
- 2.0: c. 1994
- 2.5
- 3.0: c. 1995, John Goodson da Intersolv e Frank Pellow e Paul Cotton da IBM forneceram dados significativos ao ODBC 3.0
- 3.5: c. 1997
- 3.8: c. 2009, com Windows 7
- 4.0: Desenvolvimento anunciado em Junho de 2016 com a primeira implementação com SQL Server 2017 lançada em Setembro de 2017 e controladores de ambiente de trabalho adicionais no final de 2018 especificação final no Github