Skip to main content
Tecnologias de Desenvolvimento de Dados: Passado, Presente e Futuro

Por Kraig Brockschmidt e Lorenz Prem, Gerentes de Programa da Microsoft Corporation

Última atualização: setembro de 2010

 

Ao longo dos últimos vinte anos, a Microsoft vem desenvolvendo soluções de acesso a dados cada vez mais poderosas e flexíveis. Algumas são muito especializadas, outras de uso geral, mas todas elas compartilham duas metas comuns: fazer com que as aplicações tenham acesso às informações que eles precisam e ajudar os desenvolvedores a gastar menos tempo com os detalhes ligados ao armazenamento de dados e mais tempo criando softwares sofisticados que utilizam esses dados para proporcionar benefícios reais aos seus clientes.

Nessa visão geral do passado, você verá rapidamente que há muitas tecnologias de desenvolvimento de dados diferentes, assim como há muito tipos diferentes de fontes de dados. Algumas tecnologias deixaram de ser usadas, mas a maioria delas ainda está ativa e muitas continuam sendo desenvolvidas. Por que é assim? Por que a Microsoft continua criando meios adicionais de fazer essencialmente a mesma coisa?

Na verdade, a razão fundamental não diz respeito às particularidades de acesso ou manipulação de dados, nem aos detalhes dos bancos de dados. Essencialmente, refere-se ao fato de que os elementos de mais longa duração em praticamente todos os sistemas de computadores são os dados. Não o hardware, não as arquiteturas de design, não a tecnologia de banco de dados nem as APIs de acesso a dados, e certamente não as aplicações construídas sobre as tecnologias de acesso a dados.

Não, os dados sobrevivem a todos eles, porque são os dados que conservam os fatos da nossa existência – bem como das pessoas, das organizações e das nações – e, sendo assim, tais fatos continuarão a ser fatos para sempre. Com certeza esses dados serão migrados de um sistema para outro (e outro, e outro). E talvez sejam atualizados ocasionalmente, como quando alguém nasce, quando alguém muda o nome, ou quando descobrimos que devíamos ter usado quatro dígitos, em vez de dois, para armazenar um ano. Mas, no que diz respeito aos sistemas de computadores, os dados são efetivamente imortais, e tudo o mais não passa de um invólucro. Os sistemas podem ser atualizados ou ficar obsoletos, e talvez um fornecedor de banco de dados faça uma venda melhor do que a concorrência. Seja qual for o caso, os dados se movem o tempo todo... E ainda assim os dados permanecem os mesmos, esperando para ser acessados e colocados em bom uso.

Assim, cada camada que é construída em torno dos dados é cada vez mais efêmera – ou seja, de curta duração – do que as mais próximas a eles. Os dados possuem mais longevidade que o mecanismo de banco de dados que, por sua vez, geralmente sobrevive às tecnologias de acesso a dados. Por exemplo, à medida que você lê este artigo, observe a constância do Microsoft SQL Server nas ilustrações: ela permanece onde está no canto inferior direito, sobrevivendo às suas tecnologias de acesso a dados originais, bem como provavelmente irá sobreviver às atuais e às que estão neste instante em desenvolvimento.

É óbvio que essas tecnologias de acesso a dados, por sua vez, sobrevivem a aplicações específicas construídas sobre elas. Outra maneira de afirmar isso é que as tecnologias de acesso a dados específicas funcionam como um meio especial de construir aplicações – como um código Win32 não gerenciado ou um código .NET gerenciado – ou um tipo particular de aplicação – como um cliente avançado, um aplicação Web ou uma aplicação para servidores. Portanto, naturalmente possuem uma maior expectativa de vida do que qualquer aplicação (da mesma forma que as aplicações possuem uma maior expectativa de vida do que as formas com que se apresentam ao usuário, que mudam facilmente de uma versão para outra).

As tecnologias de acesso a dados vêm, e ocasionalmente vão, simplesmente porque se adaptam às necessidades de desenvolvimento que cercam os diferentes tipos de aplicações e os diferentes tipos de repositórios de dados. É por esse motivo que há tecnologias para o código (.NET) gerenciado e (Win32) não gerenciado, e tecnologias que servem para aplicações que precisam desconhecer o banco de dados, bem como para aplicações que precisam ser otimizadas para uma fonte especial. É realmente apenas uma questão de descobrir qual método é mais adequado aos seus requisitos em particular. (Para obter um guia conciso de seleção para todas as tecnologias que atualmente possuem suporte, consulte a página Saiba Mais do Data Developer Center.)

Junto com as tecnologias de acesso a dados, começaram a aparecer os serviços de suporte. Aparentemente, toda empresa precisa de relatórios, análise e outros serviços para dar continuidade aos dados contidos nos bancos de dados implantados em toda a empresa. A princípio, esses recursos de suporte não existiam, ou existiam em uma versão muito limitada. Com o passar do tempo, os recursos melhoraram. Junto com eles, cresceu o valor que podia ser obtido dos dados armazenados nos bancos de dados. Os dados também irão sobreviver a esses serviços, mas os serviços continuarão a agregar cada vez mais valor ao modelo de banco de dados.

Um Breve Aceno ao Microsoft Access

No início da década de 1990, a Microsoft possuía duas ofertas básicas de bancos de dados: o SQL Server e o Access. O Microsoft Access era e continua sendo uma combinação fabulosa de um mecanismo de banco de dados e um ambiente com design front-end, permitindo o rápido desenvolvimento de aplicações de bancos de dados completas sem as tradicionais práticas de codificação. Mas isso é tudo que iremos dizer sobre o Access aqui, porque com uma solução como o Access, você realmente não precisa se preocupar com a mecânica de comunicação com um banco de dados. O Access faz isso sem a necessidade de intervenção do usuário. E mais, como uma solução cliente para desktop, o Access visa apenas uma parcela das aplicações de banco de dados que as pessoas querem criar; muitas aplicações realmente precisam se focar em alcançar os dados diretamente.

Isso era realidade com o SQL Server desde o início, que por si mesmo consistia no acesso a dados de alto desempenho adequado para um grande número de usuários simultâneos. Seu foco era fornecer os dados a quaisquer aplicações que precisassem obtê-los, não importando como tais aplicações fossem escritas. Nesse sentido, pouca coisa mudou ao longo dos anos, exceto que a paisagem das fontes de dados se expandiu muito, os tipos de aplicações de banco de dados são muito mais variados e os meios dessas aplicações se comunicarem com as fontes de dados têm se desenvolvido constantemente, como uma pequena comunidade com poucas casas cresce e se desenvolve até se tornar uma cidade completa. E é essa história especial de crescimento que coloca todas as tecnologias de desenvolvimento de dados da Microsoft em um contexto.

 

Os Fundamentos do Desenvolvimento de Dados: Tecnologias ("Nativas") Win32

Quando a Microsoft introduziu pela primeira vez o SQL Server 1.0 em 1989, havia uma única API programática ou de “nível de chamada” com o nome de DB-Library. Por meio das suas 150 funções, uma aplicação de console MS-DOS ou OS/2 ou uma aplicação gráfica Windows ou OS/2 podia se divertir com os dados por meio de operações do tipo criar-recuperar-atualizar-excluir que ainda hoje conhecemos e adoramos (a que ironicamente nos referimos através do maravilhoso acrônimo CRUD).

Estava disponível também o Embedded SQL for C (ESQL for C, de forma resumida), um pré-compilador que permitia as instruções SQL diretamente no código-fonte, um prenúncio simples do que veríamos mais tarde no LINQ. (Se tiver interesse, um exemplar básico do código ESQL for C pode ser encontrado na documentação do SQL Server 2000.)

Nesse ponto do tempo, outros bancos de dados possuíam suas próprias APIs patenteadas como a DB-Library, mas todas elas estavam completamente separadas, como mostra a Figura 1.

 

Description: History_Win32_1.png

Figura 1: Tecnologias de acesso a dados por volta de 1990; as ofertas da Microsoft eram apenas para o SQL Server.

 

Em setembro de 1992, a Microsoft lançou a especificação Open Database Connectivity ou ODBC. O ODBC, ainda em uso difundido, é uma API de nível de chamada com 50 funções que se comunica por meio de drivers com qualquer quantidade de bancos de dados subjacentes ou repositórios semelhantes a bancos de dados. O ODBC constrói uma abstração de acesso a dados sobre as APIs patenteadas, fornecendo a aplicações um meio único de acesso a uma ampla variedade de fontes de dados, desde o mais antigo dinossauro herdado até a última tecnologia de ponta. Os fornecedores de bancos de dados, se optarem, podem também oferecer um driver ODBC nativo (isto é, não intermediário) para alcançar melhor desempenho (como a Microsoft faz com o SQL Server).

As aplicações, é claro, ainda são livres para usar APIs patenteadas; o ODBC simplesmente proporcionou uma maneira de as aplicações se isolarem de tais APIs, como quando as aplicações precisam operar em vários bancos de dados de fornecedores diferentes.

 

Description: History_Win32_2.png

Figura 2: Tecnologias de acesso a dados em setembro de 1992.

 

Poucos anos depois, como as tecnologias de objetos e linguagens de programação (como COM, C++, e Visual Basic) passaram a predominar, novas camadas de acesso orientadas a objetos foram criadas. Primeiro veio o Data Access Objects (DAO) no Visual Basic 3 (novembro de 1992). Mais tarde ele foi substituído na versão 4 do Visual Basic (agosto de 1995) pelo Remote Data Objects (RDO), uma camada de objeto compatível com VB sobre o ODBC. Um anos depois, em agosto de 1996, a Microsoft lançou a tecnologia muito mais generalizada OLE DB para criar uma camada de acesso orientada a objetos ao lado do ODBC, trabalhando novamente em um modelo de provedor específico para armazenar dados.

O OLE DB, que também ainda tem uso difundido, não supera o nível de abstração de acesso a dados do ODBC; ele simplesmente fornece um modelo de programação adequado para determinados estilos de desenvolvimento. Ainda, na época em que foi lançado, também ajudava a tornar acessíveis cada vez mais repositórios de dados, especificamente aqueles que podiam ser representados como dados tabulados (como planilhas e arquivos de texto). Daquela forma, o OLE DB era um avanço em relação ao OBDC.

 

Description: History_Win32_3.png

Figura 3: Tecnologias de acesso a dados em agosto de 1996.

 

Como se sabe, nessa época a Internet começava sua rápida expansão, e com ela veio a importância das aplicações Web, ao lado das aplicações cliente para desktop. O OLE DB, entretanto, é orientado por linguagens aptas para ponteiros como C e C++, o que significa que linguagens de scripts como VBScript e JavaScript, que não possuem suporte para o conceito de ponteiros, são deixadas para trás. Assim, era necessário introduzir uma tecnologia adequada que permitisse às aplicações Web o acesso à enorme matriz de repositórios de dados para a qual os drivers do OLE DB estavam disponíveis.

O resultado foi o ActiveX Data Object, ou ADO, uma abstração de objeto de nível superior construída sobre o OLE DB, disponível tanto para linguagens de programação aptas para ponteiros como sem ponteiros. O ADO foi lançado pela primeira vez em outubro de 1996 (e, assim, esteve obviamente em desenvolvimento por algum tempo em conjunto com o OLE DB).

 

Description: History_Win32_4.png

Figura 4: Acesso a dados em outubro de 1996.

 

Havia então seis APIs diferentes da Microsoft para acesso a dados, dependendo de como a aplicação tinha sido escrita e dos tipos de repositórios de dados que ela precisava acessar:

Opções em 1996Bancos de dados do SQL ServerBancos de dados com driver do ODBCBancos de dados com driver do OLE DB
Aplicações escritas em C/C++DB-Library, ESQL/C
ODBC, OLE DB, ADO
ODBCOLD DB, ADO
Aplicações escritas em VBRDORDOADO
Aplicações WebADO ADO

 

Desde aquela época, muitas dessas tecnologias continuaram a existir como burros de carga confiáveis que continuam a fornecer suporte para muitos tipos de aplicações que os desenvolvedores precisam criar. Algumas melhorias foram introduzidas e algumas tecnologias mais antigas deixaram de ser usadas, à medida que novas tecnologias surgiram para satisfazer as mesmas necessidades. Por exemplo, o suporte para a DB-Library terminou com o SQL Server 2000, quando uma nova e melhor API direta, o SQL Server Native Client, foi introduzido com o SQL Server 2005. Da mesma forma, o desenvolvimento do Language-Integrated Query (LINQ) deu fim à longa atividade do ESQL for C com o SQL Server 2008.

Paralelamente, o RDO teve suporte através do Visual Basic versão 6, depois do qual o Visual Basic se tornou Visual Basic .NET e o foco se voltou para o ADO.NET (como veremos na próxima seção).

Na verdade, a introdução do .NET Framework (versão 1.0 em fevereiro de 2002 e 1.1 em abril de 2003) transferiu o foco principal da maioria das novas iniciativas de desenvolvimento para o espaço de código gerenciado. Assim, embora as tecnologias ODBC, OLE DB e ADO continuem a envelhecer, permanecem sendo as tecnologias básicas de acesso a dados para aplicações de código não gerenciado (ou seja, Win32). Hoje elas são conhecidas conjuntamente como Microsoft Data Access Components (MDAC) ou Windows Data Access Components (WDAC) e fazem parte do Windows SDK.

Há também, de certa forma, uma evolução continuada nessas tecnologias, como o ADO Multi-Dimensional (ADOMD), o ADO Extensions for DDL and Security (ADOX), o driver do SQL Server Java Database Connectivity (JDBC) e o driver PHP para SQL Server. Veja a Figura 5 e a tabela seguinte. Em resumo, com ou sem .NET Framework, há ainda uma necessidade contínua de acesso direto e otimizado a repositórios de dados como o SQL Server de ambientes de código não gerenciado.

Para obter mais informações a esse respeito, visite os links acima, bem como o SQL Server Developer Center e o Roadmap para Tecnologias de Acesso a Dados [até ADO.NET]. Um artigo semelhante a esse último é o Tecnologias de Acesso a Dados, novamente com o foco principal nas tecnologias Win32.

E, com isso, deixamos o território do código não gerenciado e também transferimos nosso foco para os desenvolvimentos no reino do .NET.

Description: History_Win32_5.png

Figura 5: Tecnologias de acesso a dados para código não gerenciado, vigentes até setembro de 2010.

 

Matriz de opções atuais
(código não gerenciado)
Bancos de dados do SQL ServerBancos de dados com driver do ODBCBancos de dados com driver do OLE DB
Aplicações escritas em C/C++ODBC, OLE DB, ADO,
SQL NativeClient
ODBCOLD DB, ADO
Aplicações WebADO, Driver PHP,
Driver do JDBC
Accessível através do Provedor Microsoft OLE DB para ODBC (MSDASQL)ADO

 

Desenvolvimento de Dados Hoje, Parte 1: Acesso Direto a Dados

A introdução do .NET Framework, em toda a sua glória, pode ter mudado a maneira como as aplicações eram desenvolvidas e as ferramentas usadas para desenvolvê-los, mas não mudou a necessidade fundamental das aplicações de acessar dados. Na verdade, a introdução do .NET Framework e o desenvolvimento das tecnologias de acesso a dados .NET demonstraram que nem a longevidade subjacente dos dados nem das tecnologias de banco de dados usadas para armazenar esses dados mudaram com o .NET.

De acordo com o seu design básico, a solução .NET para qualquer necessidade de programação é suprir as classes .NET apropriadas com as APIs desejadas. No caso de acesso a dados, as classes básicas são SqlConnection, SqlCommand, DataReader, DataSet e DataTable (em conjunto com os controles de servidor para aplicações ASP.NET). Tais classes juntas compõem o núcleo do ADO.NET.

O ADO.NET é basicamente o .NET irmão do ADO expondo um modelo conceitual semelhante, embora ofereça também recursos expandidos. Para uma comparação das duas tecnologias, consulte ADO.NET para o Programador ADO. (Mesmo que seu único conhecimento sobre o ADO venha do presente artigo, a comparação ainda fornece uma excelente visão geral do ADO.NET por si próprio.)

Como suas tecnologias anteriores, o ADO.NET trabalha através de uma camada de abstração que oculta os detalhes da tecnologia de armazenamento subjacente. Essa camada é fornecida pelos “provedores de dados” ADO.NET, e a Microsoft fornece um provedor nativo para o SQL Server, bem como provedores para o OLEDB e o ODBC (consulte Provedores de Dados do .NET Framework na documentação .NET 1.1). E mais, o ADO.NET fornece suporte para o acesso transparente a fontes XML da mesma maneira (algo que o ADO não fazia). Essas relações são ilustradas na Figura 6. (Nota: para obter uma versão mais abrangente desse diagrama, leia o artigo Guia da Arquitetura de Acesso a Dados .NET. Observe também que enquanto a classe DataSet faz parte do assembly .NET System.Data, as classes DataReader e DataAdapter são implementadas pelos provedores, como são específicas para provedores as classes SqlConnection e SqlCommand.)

 

Description: History_DotNet_1.png

Figura 6: A introdução do ADO.NET em 2002/2003.

 

Essa visão do acesso a dados através do ADO.NET ainda permanece atual nos dias de hoje, e a maioria das aplicações .NET usa efetivamente a classe DataSet (e as classes relacionadas como DataAdapter e SqlCommand) para se comunicar com seus repositórios de dados subjacentes. (Para obter detalhes sobre as diferenças do ADO.NET nas estruturas .NET versão 1 e 2.0, consulte O Que Há de Novo no ADO.NET [.NET Framework 2.0]).

 

Agora, é importante enfatizar que, como um primeiro passo para as últimas tecnologias, o modelo básico de programação (isto é, consulta) de acesso a dados no ADO.NET é quase o mesmo que conhecemos desde o início dessa história:

  1. Abrir uma conexão com o banco de dados
  2. Executar uma consulta no banco de dados
  3. Recuperar um conjunto de resultados
  4. Processar esses resultados
  5. Liberar os resultados
  6. Fechar a conexão

(Como exemplo, compare a estrutura do código básico da DB-Library na documentação do SQL Server 2000 e a do código básico do ADO.NET disponível em All-In-One Code Framework, especificamente o projeto chamado CSUseADONET e o caminho de código através do método SelectUsingUntypedDataSet).

Em outras palavras, embora as APIs e outros detalhes tenham mudado ao longo dos anos, a estrutura essencial do código permaneceu a mesma. Isso não é algo ruim, já que o modelo de programação claramente corresponde ao propósito básico dos bancos de dados: fazer perguntas e obter respostas. Seria uma aposta segura, de fato, se a qualquer momento que um novo ambiente de desenvolvimento de uso geral surgisse (por ordem do .NET Framework), houvesse novas tecnologias de acesso a dados que seguissem esse modelo. Enquanto isso, o ADO.NET continuará a ser o meio básico de acesso a dados.

Mas ainda há muitas coisas interessantes a se fazer quando o assunto é o acesso a dados. Na verdade, duas das mais interessantes tecnologias, o Language-Integrated Query (LINQ) e o ADO.NET Entity Framework, foram introduzidas com o .NET Framework versão 3.5 e versão 3.5 SP1, respectivamente. De muitas maneiras, essas tecnologias representam distâncias muito mais significativas do que a transição do ADO para o ADO.NET.

Introduzido em novembro de 2007, o LINQ mantém vivo o fantasma do ESQL for C: a ideia de incorporar consultas diretamente dentro da própria estrutura da linguagem de programação. Como evidenciado em sua visão geral, o LINQ é uma solução muito melhor que o seu ancestral distante, da seguinte forma:

  • O LINQ pode ser usado a partir de qualquer linguagem .NET que forneça suporte para ele (como C# e Visual Basic)
  • O LINQ permite muitas otimizações modernas de desempenho
  • O LINQ pode operar com (isto é, consultar e atualizar) fontes de dados arbitrárias

Essas fontes de dados podem ser qualquer coisa, desde objetos CLR na memória, XML, bancos de dados, DataSets do ADO.NET ou qualquer outra fonte na qual alguém venha a implementar uma classe .NET com as interfaces IEnumerable ou IQueryable. Isso é mostrado na Figura 7.

 

Description: History_DotNet_2.png

Figura 7: A introdução do LINQ em novembro de 2007, incluindo LINQ para Objetos,
LINQ para XML, LINQ para DataSet e LINQ para SQL.

 

Não deveria ser surpreendente, então, que não há nenhum punhado saudável de implementações “LINQ para XYZ” fornecido pela Microsoft, mas há literalmente dezenas de implementações de terceiros, incluindo coisas como LINQ para Flickr, LINQ para Amazon, LINQ para CSV, LINQ para MAPI e LINQ para Twitter. Em resumo, se alguma coisa pode se parecer com um repositório de dados que pode ser consultado, você pode colocar uma interface IQueryable nela e fazê-la trabalhar com o LINQ.

O outro desenvolvimento recente no acesso a dados dá até mesmo um passo à frente do LINQ. Isto é, embora o LINQ introduza um mecanismo de consulta muito simples, ainda que poderoso, especialmente trabalhando com o DataSet e os bancos de dados do SQL Server, ele não muda a natureza essencial de como a aplicação vê os dados relacionais. Na verdade, todas as tecnologias de dados relacionais que vimos até aqui – DB-Library, ESQL for C, OBDC, OLEDB, ADO, ADO.NET e LINQ – estão todas reunidas no fato de que trabalham inerente e diretamente com a estrutura relacional das tabelas dos bancos de dados.

Tudo isso funciona bem para bancos de dados simples e aplicações simples. Entretanto, à medida que um banco de dados se torna mais amplo e uma aplicação mais sofisticada, observamos uma divergência crescente entre o modo como a aplicação precisa analisar os dados – seu modelo “conceitual” ou “de objeto” – e o modo como as informações são estruturadas no banco de dados – o modelo “de armazenamento” ou “relacional”. O sistema de pedidos de um fabricante, por exemplo, pode armazenar as informações sobre os pedidos em várias tabelas relacionadas, ainda que o programador da aplicação realmente queira trabalhar com uma única entidade conceitual – “o pedido” – sem ter que fazer uma JUNÇÃO complexa em cada consulta relacionada a um pedido. (Esse é o caso do que é chamado “object-relational impedance mismatch”, se é que você já ouviu esse termo.)

Por essa razão, os programadores implementaram de forma rotineira suas próprias camadas de mapeamento para criar essas entidades conceituais e exclusivas. Uma camada como essa fornece um único objeto “Pedido”, por exemplo, com métodos como Recuperar e Atualizar que executam internamente as consultas necessárias no nível do banco de dados para transportar as informações entre o objeto Pedido e as tabelas subjacentes.

Em resumo, as camadas de mapeamento isolam convenientemente a aplicação dos detalhes das estruturas lógicas dos bancos de dados. É um padrão muito comum que se possa localizar projetos escritos de DB Library para ADO.NET e de LINQ para SQL. O que não é tão conveniente é que essas camadas são entediantes de se implementar e manter.

Isso muda com o Entity Framework, introduzido em agosto de 2008 com o .NET Framework versão 3.5 SP1 (consulte a visão geral) e amplamente aprimorado com o .NET Framework 4 em abril de 2010. O Entity Framework, como é simplesmente chamado, cria automaticamente uma camada de mapeamento das classes .NET a partir de um banco de dados existente, junto com uma descrição textual concisa do mapeamento entre os níveis conceitual e relacional, que você pode personalizar como quiser. Seja qual for o caso, o Entity Framework fornece acesso completo ao LINQ para as entidades resultantes (LINQ para Entidades), e como é construído sobre o ADO.NET, o Entity Framework aproveita diretamente os provedores do ADO.NET.

Essas representações conceituais e relacionais podem ser facilmente criadas usando os designers do Visual Studio, e o designer do Entity Framework no Visual Studio criará um mapeamento padrão sem qualquer esforço da sua parte. Em outras palavras, não pense que trabalhar com o Entity Framework apresenta mais complexidade que outras soluções – na verdade, ele é mais fácil do que todos os outros para cenários básicos e oferece muito mais flexibilidade além dos conceitos básicos. E o resultado final é que você pode concentrar seus esforços naquilo que realmente interessa – os objetos conceituais e o mapeamento – e não trabalhar em cima do código entediante e sujeito a erros que tradicionalmente é deixado para os estagiários.

Isso nos traz ao patamar tecnológico atual em setembro de 2010, como mostra a Figura 8.

 

Description: History_DotNet_3.png

Figura 8: O Entity Framework, lançado pela primeira vez em agosto de 2008, automatiza o trabalho árduo do mapeamento conceitual. Um Entity Data Model (Modelo de Dados de Entidade) é usado para compilar o tempo gasto para gerar classes para uma camada de mapeamento.

 

Desenvolvimento de Dados Hoje, Parte 2: Dados na Nuvem

Como sutilmente revelado no título da seção anterior, tudo que vimos até este ponto se aplica basicamente a aplicações que podem acessar um banco de dados de algum modo direto, como o sistema de arquivos, pipes nomeados, etc. Isso se aplica a aplicações clientes que acessam bancos de dados em uma intranet, bem como aplicações Web que acessam repositórios de backup em seus servidores Web (e aplicações Web escritas em ASP.NET têm acesso total ao ADO.NET e ao Entity Framework, é claro).

O que não falamos ainda é sobre as aplicações que acessam dados de forma mais indireta, como aplicações Web ou aplicações sofisticadas para internet que desejam criar e consumir serviços de dados baseados em REST.

Para ser honesto, esse assunto começa a nos transportar para o mundo do Windows Communication Foundation (WCF) e dos serviços Web em geral, que vai além do escopo deste artigo. Entretanto, nós o mencionamos para introduzir o WCF Data Services (anteriormente ADO.NET Data Services e codinome “Astoria”), uma estrutura que facilita essa comunicação entre as cenas que vimos explorando até aqui (veja a Figura 9).

Description: History_DotNet_4.png

Figura 9: O WCF Data Services facilita a criação e o consumo de serviços de dados baseados em REST.

 

O objetivo do Data Services é facilitar a criação quase turnkey de serviços de dados flexíveis que estão naturalmente integrados com a Web, usando URIs para apontar para partes de dados (como as entidades em um Entity Data Model) e formatos simples e conhecidos para representar esses dados (como JSON e XML). Outros aplicações Web (e agentes) podem interagir com a coleção de recursos de estilo REST resultante usando os verbos HTTP comuns como GET, POST ou DELETE. Na verdade, as convenções para trabalhar com os serviços de dados são tão universais que foram formalizadas como o Open Data Protocol. Informações sobre ele podem ser encontradas em www.odata.org.

Muitos dos serviços de dados na nuvem da Microsoft, como as tabelas do Windows Azure, o SQL Data Services e o SharePoint, expõem os dados usando o protocolo do Data Services. Isso significa que as bibliotecas cliente do Data Services e as ferramentas dos desenvolvedores podem ser usadas para trabalhar tanto com os serviços hospedados na nuvem como no local.

 

Futuro do Desenvolvimento de Dados

Se pararmos para refletir sobre toda a curva do debate que tivemos neste artigo, poderemos enxergar uma clara tendência para níveis maiores de abstração. As primeiras soluções de acesso a dados para o SQL Server, como o DB-Library e o ESQL for C, eram suficientes, mas completamente rudimentares. Tecnologias como o ODBC criaram uma camada de abstração acima das APIs patenteadas de diferentes bancos de dados, um modelo que o OLE DB, o ADO e o ADO.NET continuam seguindo.

Mais recentemente, o Entity Framework deu um passo adiante ao criar uma camada de abstração adicional não sobre a API de acesso a dados, mas sobre a própria estrutura de um banco de dados relacional. Da mesma forma, o Data Services transforma qualquer quantidade de fontes de dados diversas em algo acessível por meio de um simples protocolo de troca baseado em REST, o Open Data Protocol ou OData (veja em http://www.odata.org). Na verdade, a Microsoft espera que o uso de tais protocolos torne-se cada vez mais difundido, uma vez que permite que os provedores e consumidores de dados se desenvolvam independentemente do seu modelo de programação.

A Microsoft continua a desenvolver o Entity Framework, o WCF Data Services e o Open Data Protocol. Essas são as áreas em que você verá investimento contínuo. Para obter mais informações, consulte futuro do Entity Framework e futuro do Data Services.

 

 

Serviços de Aplicação no Microsoft SQL Server

Logo após o lançamento do primeiro banco de dados, ficou claro que os usuários queriam fazer mais com os dados do que apenas ler e escrever. Os dados possuem a maravilhosa propriedade de ser úteis em muitos cenários além daquele em que foram originalmente criados. Os usuários queriam reuni-los, transformá-los, analisá-los e tomar decisões com base neles. Para atender essas necessidades, a Microsoft iniciou o desenvolvimento de vários serviços de aplicação com valor agregado baseados no SQL Server.

Em primeiro lugar, o Data Transformation Services (DTS) foi introduzido com o SQL Server 7.0 em 1998 como um modelo de aplicação para transformações de dados executados no servidor de banco de dados. Os desenvolvedores podiam definir os pacotes de aplicações que continham a lógica de transformação de dados. Os pacotes eram disparados por eventos no banco de dados. O DTS foi considerado como uma melhoria significativa para o modelo único de cliente para aplicação que existia antes. O DTS é a opção certa para fluxos de trabalho como aplicações que são disparados por mudanças nos bancos de dados.

Como mostra a Figura 11, o SQL Server 7.0 também incluiu outros serviços de dados novos, os serviços Online Analytical Processing (OLAP). A análise OLAP é um método de resposta a consultas multidimensionais, que são uma importante ferramenta na análise de dados. O serviço OLAP marca o início do business intelligence, baseado em dados armazenados em um SQL Server na Microsoft (e é agora conhecido como SQL Server Analysis Services, como indicado abaixo).

Description: C:\work\customers\microsoft\other\KraigB\articles\data_ppf_11.jpg

Figura 11: A primeira introdução dos serviços de suporte para SQL Server no SQL Server 7.0 (1998)

 

O SQL Server 2000 trouxe a adição do SQL Server Replication Services (Figura 12). Esse recurso tornou possível tomar os dados armazenados em um banco de dados e replicá-los em outro. O banco de dados deu um passo a mais para se tornar a fonte de todos os dados da empresa. Desde a versão 2000 o SQL Server pode importar e exportar dados de e para outros bancos de dados. Na maioria dos casos, os dados podem ser mantidos em um estado consistente automaticamente. Os desenvolvedores devem observar que o gerenciamento da consistência dos dados é mais bem realizado com o uso dos serviços de replicação, em vez de executar o trabalho no nível da aplicação.

No SQL Server 2000, o OLAP também foi renomeado para SQL Server Analysis Services, refletindo a adição da data mining e de outros recursos que vão muito além da definição do OLAP. Os dados reunidos pelo serviço podem ser acessados de forma programática. A API SSAS exibe os recursos essenciais de análise de dados.

Em 2000, o banco de dados também se estendeu para dispositivos cliente. O Windows Compact Edition (CE) foi lançado em conjunto com um mecanismo de banco de dados de tamanho reduzido. Atualmente esse mecanismo é conhecido como SQL Server Compact Edition. O banco de dados é executado em dispositivos cliente de tamanho reduzido, como celulares e Pocket PCs. Os desenvolvedores de aplicações móveis podem acessar os benefícios do modelo de programação de banco de dados junto com seu ecossistema de serviços de valor agregado.

Description: C:\work\customers\microsoft\other\KraigB\articles\data_ppf_12.jpg

Figura 12: O Replication Services e o SQL Server Compact Edition foram introduzidos com o SQL Server 2000. O Analysis Services também absorveu o OLAP e adicionou novos recursos como a mineração de dados, levando ao novo nome.

 

Em 2004, o SQL Server Reporting Services (SSRS) foi lançado como um complemento do SQL Server 2000. As empresas exigem recursos de relatórios dos dados e dos eventos relacionados aos dados armazenados em seus bancos de dados. Projetado como uma ferramenta de business intelligence, o SSRS preencheu a lacuna entre os dados criados pelas operações e os dados usados na tomada de decisões. A API SSRS e a linguagem de relatório são a maneira mais rápida de criar e executar relatórios significativos. O desenvolvedor pode gastar o tempo pensando no que vai entrar no relatório. A formatação e a coleta de dados são tratadas pelo serviço.

Description: C:\work\customers\microsoft\other\KraigB\articles\data_ppf_13.jpg

Figura 13: A introdução do SQL Server Reporting Services em 2004.

 

Em nossa mente, os dados são algo em que pensamos de forma etérea. Conceitualmente, eles existem longe de ser removidos do local em que estão armazenados. São puros: nunca inconsistentes nem desatualizados. No mundo físico do hardware, entretanto, alcançar o objetivo dos dados onipresentes não é fácil. Começando no SQL Server 2005, vários serviços novos foram criados para isolar a aplicação das questões sobre armazenamento. Embora ainda não tenhamos verdadeiramente alcançado o estado de dados onipresentes, o SQL Server já deu e continua dando grandes passos nessa direção.

O SQL Server 2005 apresentou o relançamento do DTS como SQL Server Integration Services (SSIS). O novo paradigma de data warehouse exigiu que os dados fossem extraídos, transformados e carregados nos bancos de dados em constante expansão. Embora ainda conservasse os recursos de seu predecessor, o SSIS adicionou novos recursos de transformação e maior desempenho. Como antes, o SSIS é o modelo de aplicação para aplicações de fluxo de trabalho próximos ao banco de dados.

Como mostra a Figura 14, o Microsoft SharePoint entrou em ação com o SQL Server 2005. Desde o primeiro dia, os dados contidos em sites wiki do SharePoint foram armazenados nos bancos de dados do SQL Server, de forma que os dados do SharePoint foram naturalmente integrados. Ou seja, desde 2005 esses dados podem ser acessados diretamente por meio do Reporting Services e do Analysis Services. Essa integração torna a enorme quantidade de dados criada diariamente pelos funcionários dos sites wiki disponível para os recursos de gerenciamento. Para o desenvolvedor, isso significa que os dados do SharePoint tornam-se acessíveis com o uso do modelo de programação do SQL. Um sistema de instalação adequado pode acelerar a programação de aplicações relacionadas ao SharePoint.

O sucesso do SQL Server também trouxe novos problemas. As aplicações se tornaram muito difundidas para que um único banco de dados pudesse dar conta de todo o tráfego. O SQL Server Broker elevou o modelo de programação da criação de aplicações únicas para o desenvolvimento de sistemas completos. A estrutura permite que produtores e consumidores colaborem em um sistema de baixa latência e alta taxa de transferência. A escalabilidade é alcançada por meio do balanceamento de carga entre múltiplas instâncias de um componente do sistema.

Description: C:\work\customers\microsoft\other\KraigB\articles\data_ppf_14.jpg

Figura 14: o DTS foi alterado para SQL Server Integration Services no SQL Server 2005, que também teve a adição do Broker Service e a integração natural com os bancos de dados do SharePoint.

 

Desde 2005, a indústria testemunhou a extraordinária expansão do mercado de dispositivos móveis. O número de dispositivos produzidos e de dados consumidos simplesmente explodiu.

É muito tentador para um desenvolvedor de aplicações para celulares pensar nos dados como acessíveis e atuais, independentemente da localização e do estado do dispositivo. Por essa razão, o Microsoft Sync Framework, introduzido em 2008, abordou as necessidades dos dados inerentes a esse cenário. Ele permite que os dados sejam sincronizados através de uma quantidade variada de dispositivos, usando vários algoritmos diferentes para sincronização e resolução de conflitos.

O SQL Server 2008 também adicionou o SQL Server Master Data Service. O serviço baseia-se na ideia de que alguns dados da empresa são consagrados. Esses dados podem ser acessados por meio de uma única fonte confiável, o Master Data Service, e é conhecido por ser sempre preciso. A aplicação pode usar as mesmas tecnologias de acesso a dados para ter acesso a esses dados que estão disponíveis para o banco de dados.

Em 2009, o banco de dados também migrou para a nuvem com a introdução do SQL Azure. O SQL Azure hospedou o primeiro banco de dados de cliente em datacenters operados pela Microsoft. O modelo de banco de dados na nuvem remove o gerenciamento de hardware da lista de preocupações do operador de banco de dados. Os desenvolvedores agora podem verdadeiramente pensar nos bancos de dados como uma fonte ilimitada de dados que reside em algum lugar do espaço cósmico. A Microsoft assume o comando da maioria das questões associadas à operação de um servidor de banco de dados.

Assim, a visão atual dos serviços de suporte no SQL Server é mostrada na Figura 15.

Description: C:\work\customers\microsoft\other\KraigB\articles\data_ppf_15.jpg

Figura 15: SQL Server e SQL Azure com serviços de suporte em setembro de 2010.

 

 

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site.

Deseja participar?