História dos sistemas gerenciadores de banco de dados

Os primeiros bancos de dados tinham um papel bastante restritivo no contexto da aplicação: eles apenas armazenavam dados.

Todo o controle e a manipulação desses dados deveria ser implementado pela aplicação que estava sendo escrita sobre eles, o que, além de tornar o desenvolvimento do aplicativo mais lento, tornava o sistema mais sujeito a erros e poderia facilmente levar a uma inconsistência nos dados.

Aos sistemas gerenciadores de bancos de dados, não bastaria apenas armazenar os dados. Seria necessário uma linguagem que permitisse a manipulação e a navegação por esses dados. A partir dessa necessidade, surgiu a linguagem SQL - Structured Query Language, ou linguagem estruturada de consultas, em português.

A partir da SQL, surgiram diversos dialetos, que são linguagens derivadas a partir da original. No Microsoft SQL Server, banco de dados que será tratado ao longo destas postagens, é adotado o dialeto T-SQL, onde o T significa "Transact".

Agregada à linguagem de consultas, estão parsers, que são responsáveis por interpretar a correta escrita da linguagem, assim como possíveis otimizadores de consultas, que fazem com que o objetivo a ser alcançado com o código escrito pelo usuário seja alcançado da maneira mais eficaz possível. No Microsoft SQL Server, existe o Query Optimizer.

Estruturas dos aplicativos de bancos de dados

Nos primeiros aplicativos com acesso a dados, todos os dados necessários eram codificados juntamente com o próprio aplicativo. Assim sendo, a cada vez que os dados fossem alterados, seria necessário recompilar o aplicativo inteiro. Por conseqüência, o grau de compartilhamento dos dados era muito pequeno, sendo restrito apenas ao próprio aplicativo que os acessava. Estes aplicativos são conhecidos como monolíticos com dados embutidos no código do aplicativo.

Na seqüência, foi possível extrair os dados do código-fonte da aplicação e colocá-los em um arquivo separado. A partir deste momento, os dados eram independentes e qualquer alteração não demandava a recompilação de todo o programa. Caso este arquivo de dados fosse armazenado em uma localidade acessada por vários usuários, estes poderiam compartilhar estes dados. Todavia, nenhum mecanismo gerenciava o acesso a estes dados, o que tornava o compartilhamento muito arriscado em relação à corrupção destes dados pelo seu uso concorrente.

Como solução para este problema de compartilhamento, foram desenvolvidos aplicativos em que o controle do acesso aos dados era feito por um aplicativo servidor. Assim, caso todos os aplicativos que necessitassem acessar os dados o fizessem através do servidor, este gerenciaria o acesso concorrente e garantiria a correta manipulação desses dados.

Porém, caso fosse necessário alterar o tipo de servidor de banco de dados, seria necessário reescrever grande parte da aplicação, cujo propósito era se conectar apenas a um sistema de banco de dados específico. Diante disso, após acordos na indústria de software, surgiram interfaces específicas que poderiam oferecer à aplicação um acesso genérico aos dados, independentemente de qual sistema gerenciador de banco de dados fosse utilizado. Alguns desses padrões são:
ODBC = Open Database Connectivity;
OLE DB = Object-Linking Embedding Database
ADO.NET = Provedor de dados gerenciados

Por exemplo, para um provedor de dados como o OLE DB, cada aplicativo pode ser conectar ao provedor de forma idêntica, independentemente do sistema gerenciador de banco de dados que é utilizado. Todavia, o cada sistema gerenciador de banco de dados requer do OLE DB um provedor específico para a conexão.

Por outro lado, o padrão ADO.NET oferece em alguns sistemas gerenciadores de bancos de dados uma interface nativa que dispensa o uso de drivers externos.

No Microsoft SQL Server 2005, o recurso SQL Server Native Client possibilita uma conexão direta com o banco de dados, oferecendo interfaces ODBC e OLE DB.