Bancos de Dados Relacionais

Para início de discussão, um banco de dados relacional é um mecanismo de armazenamento que permite a persistência de dados e opcionalmente implementar funcionalidades. Neste contexto, o objetivo deste artigo é apresentar uma visão geral de tecnologias de sistemas de gerenciamento de banco de dados relacionais (SGBDR) e explorar questões práticas aplicáveis ao seu uso em organizações modernas. Sendo assim, o objetivo deste artigo não é discutir a teoria relacional.

SGBDRs são usados para armazenar a informação requerida por aplicações construídas usando tecnologias procedurais, tais como COBOL ou FORTRAN, tecnologias orientadas a objeto tais como Java e C# e tecnologias baseadas em componentes como Visual Basic. Como SGBDRs são as tecnologias de armazenamento de persistência dominantes, é importante que todos os profissionais de TI entendam ao menos os conceitos básicos dos SGBDRs, os desafios por trás da tecnologia e quando seu uso é apropriado.

Conhecendo um sistema gerenciador de banco de dados relacional

Vamos iniciar este tópico pela definição de algumas terminologias comuns. Um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) é um software que controla o armazenamento, recuperação, exclusão, segurança e integridade dos dados em um banco de dados. Um banco de dados relacional armazena dados em tabelas. Tabelas são organizadas em colunas, e cada coluna armazena um tipo de dados (inteiro, números reais, strings de caracteres, data, etc.). Os dados de uma simples “instância” de uma tabela são armazenados como uma linha. Por exemplo, a tabela Cliente teria colunas como numeroCliente, primeiroNome e sobrenome, e uma linha na tabela teria algo como {123, “Arilo”, “Dias”}.

Tabelas tipicamente possuem chaves, uma ou mais colunas que unicamente identificam uma linha na tabela. No caso da tabela Cliente a chave seria a coluna numeroCliente. Para melhorar o tempo de acesso aos dados de uma tabela, são definidos índices. Um índice provê uma forma rápida para buscar dados em uma ou mais colunas em uma tabela, da mesma forma que o índice de um livro permite que nós encontremos uma informação específica rapidamente.

Funcionalidades básicas de SGBDRs

O uso mais comum de SGBDRs é para implementar funcionalidades simples do tipo CRUD (do inglês Create, Read, Update e Delete – que significa as operações de Inserção, Leitura, Atualização e Exclusão de dados). Por exemplo, uma aplicação pode criar uma nova compra e inseri-la no banco de dados. Ela pode ler uma compra, trabalhar com seus dados e então atualizar o banco de dados com a nova informação. Ela pode ainda optar por excluir uma compra existente, talvez porque o cliente a cancelou. A grande maioria das interações com um banco de dados provavelmente implementará as funcionalidades básicas de CRUD.

A forma mais fácil de manipular um banco de dados relacional é submeter declarações escritas na linguagem SQL a ele. A Figura 1 descreve um simples modelo de dados usando a notação de modelagem de dados proposta pela UML. Para criar uma nova linha na tabela Seminario devemos criar uma declaração de INSERT, como exemplificado no código da Listagem 1. Similarmente, o código da Listagem 2 apresenta um exemplo de como ler uma linha da tabela usando a declaração SELECT. A Listagem 3 apresenta um código para atualizar uma linha existente através da declaração do tipo UPDATE e, finalmente, a Listagem 4 descreve como excluir uma linha da tabela usando a declaração DELETE.

Listagem 1. Declaração SQL para inserir uma linha na tabela Seminario

Listagem 2. Declaração SQL para consultar uma linha na tabela Seminario

Listagem 3. Declaração SQL para atualizar uma linha na tabela Seminario

Listagem 4. Declaração SQL para excluir uma linha na tabela Seminario

Uso avançado de SGBDRs

Existem várias funcionalidades avançadas de SGBDRs que desenvolvedores aprendem uma vez que eles estão familiarizados com as funcionalidades básicas de CRUD. Cada uma dessas funcionalidades é muito importante, e às vezes bastante complexa, fazendo com que tivéssemos que escrever um artigo próprio para cobri-las. Por isso, iremos aqui apenas introduzir os conceitos e então detalhes podem ser encontrados em outros artigos. Essas funcionalidades incluem:

1. Armazenamento de Objeto

Para armazenar um objeto em um banco de dados relacional precisamos adequá-lo – criar uma representação de dados do objeto em questão – pois bancos de dados relacionais apenas armazenam dados. Para recuperar o objeto, é preciso ler os dados a partir do banco de dados e então criar o objeto, operação normalmente chamada de restauração do objeto, baseado nos dados recuperados. Apesar de o armazenamento em um banco de dados relacional parecer algo simples, na prática não é. Isso porque não existe uma tradução perfeita e automática entre as tecnologias de objeto e relacional, pois essas tecnologias são baseadas em teorias diferentes. Para armazenar objetos com sucesso em bancos de dados relacionais, precisamos aprender como mapear um esquema de objetos para um esquema de banco de dados relacional.

2. Implementar comportamento no banco de dados

Comportamento é implementado em um banco de dados relacional através de stored procedures e/ou stored functions que podem ser invocadas internamente no banco de dados e por aplicações externas. Stored functions e procedures são operações que executam no SGBDR, a diferença entre elas é o que a operação pode retornar e se ela pode ser invocada em uma query. As diferenças não são importantes para nosso objetivo neste artigo, então usaremos o termo stored procedure para se referir a ambas as operações. No passado, stored procedures eram escritas em uma linguagem proprietária, tal como PL/SQL da Oracle, mas agora Java está se tornando rapidamente uma opção de linguagem para programação de banco de dados. Uma stored procedure tipicamente executa algum código SQL, mensagens de dados e então aguarda uma resposta na forma de zero ou mais registros, um código de resposta ou uma mensagem de erro de banco de dados.

3. Controle de concorrência

Considere um sistema de reserva de passagem aéreas. Existe um vôo com um assento e duas pessoas estão tentando reservar este assento ao mesmo tempo. Ambas as pessoas verificam o status do voo e são avisadas que o assento ainda está disponível. Ambos informam seus dados para pagamento do ticket e então clicam no botão de reserva ao mesmo tempo. O que deveria acontecer? Se o sistema está funcionando corretamente, apenas uma pessoa deveria ter acesso ao assento e a outra deveria ser informada que não existe nenhum assento disponível. Controle de concorrência é o que faz isso acontecer. Ele deve ser implementado ao longo do código fonte do objeto no banco de dados.

4. Controle de Transação

Uma transação é uma coleção de ações no banco de dados – tal como salvar, recuperar ou deletar – que formam uma unidade de trabalho. Uma bandeira das transações é uma abordagem que diz “tudo ou nada”, o que significa que todas as ações devem ser executadas com sucesso ou então serem desfeitas (operação de roll back). A transação aninhada é uma abordagem onde algumas das ações são tratadas como suas próprias transações, subdividindo-as. Essas subtransações são comitadas uma vez com sucesso e não são desfeitas se a transação maior falhar. Transações podem ainda ser de curta duração, executando em centésimos de segundo, ou de longa duração, levando horas, dias, semanas e até meses para serem completadas. Controle de transação é um conceito crítico que todos desenvolvedores devem entender.

5. Forçar integridade referencial

Integridade referencial (IR)é a garantia de que uma referência a partir de uma entidade para outra entidade é válida. Por exemplo, se um cliente referencia um endereço, então este endereço deve existir. Se o endereço é deletado, então todas as referências a ele devem também ser removidas, caso contrário o sistema não deve permitir a operação de exclusão. Contrariando a crença popular, IR não é apenas uma questão de banco de dados, mas sim um aspecto a ser tratado no sistema como um todo. Um cliente é implementado como um objeto em uma aplicação Java e como um ou mais registros no banco de dados – endereços são também implementados como objetos e como linhas. Para excluir um endereço, devemos remover o objeto endereço da memória, qualquer referência direta ou indireta a ele (uma referência indireta para um endereço incluiria um objeto cliente que conhece o valor de idEndereco, a chave primária de endereço no banco de dados), a(s) linha(s) de endereço no banco de dados e qualquer referência a ela (através de chaves estrangeiras) no banco de dados. Para complicar ainda mais, se temos outras aplicações acessando o banco de dados, então é possível que elas possuam representações do endereço em memória. Um cenário ainda pior seria se tivéssemos o endereço armazenado em vários locais (ex: bancos de dados diferentes), devemos levar isso em consideração. Todos os desenvolvedores devem entender as estratégias básicas para implementar integridade referencial.

A Tabela 1 descreve as funcionalidades técnicas comuns nos principais SGBDRs disponíveis no mercado, as principais formas dos desenvolvedores usá-los e os pontos negativos associados ao seu uso.

Tabela 1. Funcionalidades Técnicas Comuns de SGBDR.

Acoplamento: seu maior inimigo

Acoplamento é uma medida do nível de dependência entre dois itens – quanto mais acoplado são dois elementos, maior a chance de que uma mudança em um deles irá requerer um mudança na outro. Acoplamento é a “raiz de todo mal” quando se fala do desenvolvimento de software, e quanto mais coisas seu banco de dados está acoplado mais difícil é mantê-lo e evoluí-lo. Esquemas de banco de dados relacional podem ser acoplados a:

O código de fonte de sua aplicação:

Quando o esquema do banco de dados é alterado o código fonte da aplicação que acessa a parte modificada no esquema também precisa ser alterado. A Figura 2 descreve o cenário do melhor caso – quando o esquema do banco de dados é acoplado apenas ao esquema do banco de dados. Esses cenários existem e normalmente são encontrados em aplicações stand-alone, apesar de serem raros na prática.

O código fonte de outra aplicação:

A Figura 3 descreve o cenário do pior caso para bancos de dados relacionais – uma grande variedade de sistemas estão acoplados ao esquema do banco de dados, uma situação que é bastante comum na prática.

O código fonte de carga de dados:

Carga de dados de outras fontes, como tabelas externas ou dados de teste, normalmente são acoplados ao esquema do banco de dados.

O código fonte de extração de dados:

Podem existir scripts ou programas de extração de dados que leem dados a partir do banco de dados, talvez para produzir um arquivo de dados em XML ou simplesmente para que seus dados sejam carregados em outro banco de dados.

Camadas/frameworks de persistência:

Um framework de persistência encapsula a lógica para mapear as classes da aplicação para fontes de armazenamento de persistência, como um banco de dados.

O esquema de banco de dados:

Acoplamento pode existir no banco de dados. Uma simples coluna é acoplada a qualquer stored procedure que a referencia, outras tabelas que a usam como chave estrangeira, qualquer view que a referencia, dentre outras coisas. Uma simples mudança pode resultar em várias mudanças no banco de dados.

Scripts de migração dos dados:

Mudanças no esquema do banco de dados irão requerer mudanças no script de migração dos dados.

Código de teste:

Código de teste inclui qualquer código fonte que deixe o banco de dados em um estado conhecido, que realiza transações que afetam o banco de dados e que lê os resultados de um banco de dados e o compara com os resultados esperados. Claramente este código precisa ser atualizado para refletir qualquer mudança feita no esquema do banco de dados.

Documentação:

Quando o esquema do banco de dados muda, a documentação que o descreve deve ser atualizada.

Como podemos ver, acoplamento é um problema sério quando tratamos de refatoração de banco de dados.Por questão de simplicidade, na continuidade deste artigo o termo “aplicação” irá se referir a todos os sistemas externos, bancos de dados, aplicações, programas, ambientes de teste, etc., que são acoplados a um banco de dados.

Desafios adicionais com SGBDRs

Acoplamento não é o único desafio que iremos nos deparar ao usar SGBDRs, apesar dele ser o mais importante. Outras questões que iremos encontrar incluem:

Questões de desempenho são difíceis de predizer:

Quando estamos trabalhando com um banco de dados compartilhado, como a situação da Figura 3, podemos perceber que as características de desempenho do banco de dados são difíceis de predizer porque cada aplicação acessa o banco de dados da sua forma.

Integridade de dados é difícil de garantir com bancos de dados compartilhados:

Como nenhuma aplicação simples possui controle sobre os dados, é muito difícil ter certeza de que todas as aplicações estão funcionando sob as mesmas condições.

Bancos de dados operacionais requerem estratégias de projeto diferentes daquelas aplicadas em bancos de dados para relatórios.

Os esquemas de bancos de dados operacionais refletem as necessidades operacionais das aplicações que o acessam, normalmente resultando em um esquema razoavelmente normalizado com algumas partes dele desnormalizadas por razoes de desempenho.Bancos de dados de relatório, por outro lado, são tipicamente altamente desnormalizados com bastante redundância de dados para apoiar a alta demanda por relatórios.

Toda tecnologia possui seus pontos positivos e negativos, e a tecnologia de SGBDR não foge à regra. Provavelmente existem formas para mitigarmos alguns desses desafios, e encapsulamento é uma técnica importante para isso.

Encapsulamento: seu grande aliado

Encapsulamento é um recurso de projeto que trata de como uma funcionalidade é compartimentada em um sistema. Não precisamos saber como algo está implementado para usá-lo. A implicação de encapsulamento é que podemos construir qualquer coisa que desejarmos, e então podemos depois mudar a implementação e isso não afetará outros componentes no sistema (considerando que a interface para este componente não mude).

As pessoas normalmente dizem que encapsulamento é o ato de pintar a caixa de preto – estamos definindo algo será feito, mas não estamos dizendo ao resto do mundo como ele está sendo feito. Usando o exemplo de um banco, como eles rastreiam as informações de nossas contas, em um mainframe, um mini ou um PC? Qual banco de dados eles usam? Qual o sistema operacional? Isso não importa, pois o banco encapsulou os detalhes sobre como e eles realizam os serviços nas contas. Nós apenas usamos os terminais e fazemos as operações que desejamos.

Através do acesso encapsulado a um banco de dados, talvez por algo tão simples como objetos de acesso a dados ou algo mais complexo como um framework de persistência, podemos reduzir o acoplamento do banco de dados.

A partir de agora assumimos que é possível esconder detalhes do esquema de banco de dados da maioria dos desenvolvedores na organização enquanto ao mesmo tempo damos a eles acesso ao banco de dados. Algumas pessoas, normalmente apenas DBAs responsáveis por manter o banco de dados, precisarão entender e trabalhar com o esquema de dados para manter e evoluir a estratégia de encapsulamento.

Uma vantagem do acesso encapsulado ao banco de dados é que ele permite aos programadores focar apenas no problema. Vamos assumir que estamos fazendo algo simples tal como objetos de acesso aos dados que implementem código SQL para acessar o esquema de banco de dados. Os programadores trabalharão com essas classes de acesso aos dados, não com o banco de dados. Isso permite ao DBA evoluir o esquema do banco de dados da forma que ele precisar, refatorando-o se necessário, e tudo que ele precisa se preocupar é em manter as classes de acesso aos dados atualizadas. Isso revela uma segunda vantagem desta abordagem – ela provê uma maior liberdade para que o DBA faça seu trabalho.

A Figura 4 descreve o conceito de acesso encapsulado em banco de dados, mostrando como o cenário do melhor caso da Figura 2 e o cenário do pior caso da Figura 3 provavelmente seriam modificados. No cenário do melhor caso, o código fonte das regras de negócio iriam interagir com os objetos de acesso aos dados em vez de interagir com o banco de dados. A principal vantagem seria que todos os códigos relacionados a acesso a dados ficariam em um único lugar, tornando simples o processo de alteração em caso de mudanças no esquema do banco de dados ou para apoiar mudanças relacionadas a ajustes de desempenho. É interessante notar que o código com as regras de negócio que os programadores estão escrevendo estariam acoplados aos objetos de acesso aos dados. Portanto, eles precisariam ser alterados caso a interface do objeto de acesso aos dados mude.

Nós nunca ficaremos livre do acoplamento. No entanto, do ponto de vista dos programadores, é muito mais fácil mudar apenas este código – com a estratégia de encapsulamento de banco de dados eles precisariam lidar apenas com o código fonte da aplicação, e não com o código fonte do programa + código em SQL de acesso aos dados.

As coisas não são assim tão ideais para o cenário do pior caso. Apesar de ser possível que todas as aplicações possam tirar vantagem da estratégia de encapsulamento, a realidade é que apenas um subconjunto estará apto a usá-lo.

Incompatibilidade de plataforma pode ser um problema – talvez os objetos de acesso aos dados são escritos em Java, mas alguns sistemas legados podem ser escritos usando tecnologias que não são tão compatíveis com Java. Talvez você tenha optado por não refazer alguns de seus sistemas legados para simplesmenteusar a estratégia de encapsulamento de dados. Talvez alguns aplicativos játenham uma estratégia de encapsulamento em umlugar(em caso afirmativo, vocêpode querer considerara reutilizaçãoda estratégiaexistenteem vez de construir sua própria).Talvez você queira usar as tecnologias que exigem acesso direto ao banco de dados.

A questão é que parte das aplicações da sua organização será capaz de tirar proveito de sua estratégia de encapsulamento e outras não. Há ainda um benefício de se fazerisso, estaremos reduzindoo acoplamentoe, portanto, reduzindo seus custos de desenvolvimentoe manutenção,oproblemaéqueelenão é um beneficio total realizado.

Outra vantagem do acesso encapsulado para acessar um banco de dados é disponibilizar um lugar único, além do próprio banco de dados, para implementar regras de negócio orientada a dados.

Além dos SGBDRs: você realmente tem opções

Como existem alguns problemas claros com a tecnologia de banco de dados relacional, podemos optar por usar outra tecnologia. Sim, SGBDR é o tipo de mecanismo de persistência mais comumente utilizado, mas ele não é a única opção disponível. Entre as opções, podemos citar:

Bancos de dados objeto/relacional

Bancos de dados objeto/relacional (BDOR), ou mais apropriadamente sistemas gerenciadores de banco de dados objeto/relacional (SGBDORs), adicionam novas capacidades de armazenamento de objeto aos SGBDRs. BDORs adicionam novas facilidades para integrar gerenciamento de dados dos tipos tradicionais aos objetos complexos como séries temporais e dados geoespaciais e mídias binárias diversas, como áudio, vídeo, imagem e applets em Java. BDORs basicamente adicionam aos SGBDRs funcionalidades como tipos de dados, assim como a habilidade de navegar por objetos. Através da implementação de objetos em banco de dados, um SGBDOR pode executar operações analíticas complexas e manipulação de dados para buscar e transformar objetos multimídia e de outros tipos. BDORs suportam transações robustas e funcionalidades de gerenciamento de dados enquanto que ao mesmo tempo oferece uma forma limitada de flexibilidade de bancos de dados orientados a objeto.

Bancos de Dados de Objetos:

Bancos de dados de objetos (BDOs), conhecidos como bancos de dados orientados a objetos (BDOOs), quase perfeitamente adicionam funcionalidades de banco de dados/persistência aos objetos de linguagens de programação. Em outras palavras, eles trazem muito mais que armazenamento de persistência de objetos de linguagem de programação. BDOs estendem a semântica de Java para prover capacidade de programação completa de banco de dados, via novas bibliotecas específicas de classes para os BDOs disponíveis no mercado, mantendo a compatibilidade da linguagem nativa. O principal benefício desta abordagem é a unificação do desenvolvimento da aplicação e do banco de dados em um modelo “sem costura”. Como resultado, a aplicação requer menos código, usa modelagem de persistência mais natural e os códigos são mais fáceis de serem mantidos.

Além dessas opções, podemos citar ainda bancos de dados em XML, arquivos Flat (arquivos texto), bancos de dados hierárquicos e camada de prevalência. Não entraremos em detalhes sobre elas por não ser o foco principal do artigo, mas existem diversas informações disponíveis na Internet sobre estas opções.

A Tabela 2 apresenta uma comparação de vários tipos de mecanismo de persistência. A Tabela 3 apresenta sugestões para quando usar cada tipo de tecnologia.

Tabela 2. Comparando Mecanismos de Persistência.

Considerações finais

A tecnologia de SGBDRs não é perfeita, como nenhuma tecnologia é, mas ela é uma das mais utilizadas em nossa área, então precisamos aprender como ela funciona efetivamente. A razão pela qual discutimos sobre os pontos negativos desta tecnologia é que eles nos permitem conhecer as limitações para usar tal tecnologia em nosso dia-a-dia.

Em geral, alguns autores sempre focam nos benefícios do uso de SGBDRs, e claramente existem muitos, mas ignoram os pontos negativos. Outros autores focam em questões acadêmicas, deixando um pouco de lado questões práticas, que é como de fato aprendemos a usar uma tecnologia.

Acoplamento é uma questão séria para todos profissionais de TI, incluindo desenvolvedores e DBAs. Acesso encapsulado a um banco de dados pode ajudar a minimizar os problemas de acoplamento, mas ele é apenas uma solução parcial. É importante também reconhecer que bancos de dados relacionais são apenas uma das várias escolhas que temos disponíveis para persistência dos dados. Abordagens não-relacionais são soluções viáveis para algumas situações e devem ser levadas em consideração. De qualquer forma, bancos de dados relacionais serão sempre soluções para trabalharmos com persistência de dados.