Diferença entre banco de dados relacional e orientado a objetos

Por que eu devo ler este artigo:

Este artigo aborda o tema bancos de dados relacionais, seus conceitos, como funcionam, vantagens e desvantagens, em uma vis�o geral sobre o assunto.

Serve como conte�do introdut�rio sobre o assunto, que � de interesse de todos os profissionais da �rea de banco de dados que desejam se manter por dentro das tecnologias adotadas na pr�tica.

Bancos de dados relacionados s�o os mecanismos de persist�ncia de dados mais adotado por empresas de TI, de forma que os profissionais da �rea devem conhecer esta tecnologia com detalhes.

Um Sistema Gerenciador de Banco de Dados Relacional � um software que controla o armazenamento, recupera��o, exclus�o, seguran�a e integridade dos dados em um banco de dados. Neste contexto, este artigo aborda o tema bancos de dados relacionais, seus conceitos, como funcionam, vantagens e desvantagens, em uma vis�o geral sobre o assunto.

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

  INSERT INTO Seminario
      (idSeminario, idCurso, idProfessor, numeroSeminario, tituloSeminario)
      VALUES (74656, 1234, �DCC1982�, 2, �Banco de Dados Relacional�) 

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

  SELECT * FROM Seminario WHERE SEMINAR_ID = 1701 

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

  UPDATE Seminario 
  SET idProfessor = �PPGI1982�, numeroSeminario = 3 
  WHERE idSeminario = 1701

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

  DELETE FROM Seminario 
  WHERE idSeminario > 1701 AND idProfessor = �THX0001138�

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:

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:

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:

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.

Saiu na DevMedia!

• Levantamento de Requisitos: Exemplo pr�tico de entrevista:
  Neste curso vamos exemplificar como um analista de requisitos conversa com seu cliente para realizar um levantamento de requisitos.
• O que � Levantamento de Requisitos?:
  Neste curso mostraremos que um sistema come�a antes da codifica��o, com o levantamento de requisitos, que veio para ajudar os programadores a compreender melhor quais seriam as necessidades de um cliente, auxiliando-o na classifica��o desses requisitos.
• Hist�rias de Levantamento de Requisitos:
  Somente uma pequena parcela das aplica��es desenvolvidas � de fato utilizada. Dentre os motivos para esse fracasso est� a dist�ncia entre o que � feito e a real solicita��o do cliente. Saiba como o Levantamento de Requisitos resolve esse problema.

Saiba mais sobre Bancos de Dados ;)

• Guias de Banco de Dados:
  Aqui voc� encontra o Guia de estudo ideal para aprimorar seus conhecimentos nos principais Banco de Dados do mercado. Escolha o seu e bons estudos!
• Banco de Dados para Programadores:
  Todo programador deveria entender de banco de dados para ser um profissional mais completo, mas isso n�o � tarefa simples. Nesse guia voc� ir� aprofundar seus conhecimentos em SQL, modelagem, e os principais SGBDs do mercado. Vamos evoluir!
• Guia de SQL:
  Neste Guia de Refer�ncia voc� encontrar� todo o conte�do que precisa para aprender sobre a SQL, linguagem de consulta estruturada utilizada por programadores e DBAs para a execu��o de consultas e comandos nos principais SGBDs do mercado.

Confira outros conte�dos: