O documento discute a evolução dos sistemas de gerenciamento de banco de dados, desde os SGBDs relacionais até os bancos de dados NoSQL. Também aborda os bancos de dados orientados a objetos e faz uma comparação entre os modelos relacional e NoSQL.

1. Modelo de gestão de
dados para sistemas
colaborativos
Vanessa Martins
Mozart Claret

2. Os SGBDs
 Surgiram no início da década de 70 com o objetivo de facilitar a
programação de aplicações de banco de dados (BD).
 Nessa mesma época, houve um investimento considerável de pesquisa
na área de banco de dados. Esse investimento resultou em um tipo de
SGBD, o SGBD relacional.
 A partir da década de 80 e devido ao barateamento das plataformas de
hardware/software para executar SGBD relacional, este tipo de SGBD
passou a dominar o mercado, tendo se convertido em padrão internacional.

3. Os SGBDs
 Após o surgimento das linguagens de programação orientadas a objeto,
surgiram bancos de dados que usavam este conceito.
 Estes bancos de dados passaram a ser referenciados como ODBMS
(Object Data Base Management Systems) ou OODBMS (Oriented Object
Data Base Management Systems).

4. Os SGBDs
 Com a explosão da WEB 2.0, onde reinam as Redes Sociais virtuais, o
volume de informação armazenada nos sistemas colaborativos chegou a um
volume tão grande que os SGBDs relacionais começaram a ser
questionados quanto ao seu desempenho e escalabilidade.
 Surgiu então uma proposta por um modelo que não estava focado na
estruturação dos dados.
 Estes sistemas que se pareciam mais como os antigos sistemas de arquivos são
conhecidos como bancos de dados NoSQL (Not Only SQL).

5. Os Bancos de Dados Orientados a Objetos
 O paradigma da orientação a objetos começou a aparecer ainda nos anos
60 mas foi a partir dos anos 80 que este conceito realmente ganhou força e
passou a estar presente em quase todas as linguagens de programação.
Existem diversas linguagens de programação orientada a objeto: Objective-C,
C++, CLOS (Common Lisp Object System), Object Pascal, Eiffel, Java, Python,
JavaScript, Ruby, C# entre outras.
Para um modelo ser considerado orientado a objeto ele deve conter alguns
conceitos básicos: abstração, encapsulamento, herança, e polimorfismo.

6. Os Bancos de Dados Orientados a Objetos
 Com todas estas características nativas das linguagens, surgiu a
demanda pelo desenvolvimento de um sistema gerenciador de banco de
dados que seguisse a mesma abordagem.
Em meados dos anos 80, eles começaram a se tornar produtos
comercialmente viáveis. Hoje, eles são mais de 25 produtos no mercado.
Eles tiveram pouco impacto nas principais aplicações comerciais de
processamento de dados, embora sejam utilizados em algumas áreas
especializadas em serviços financeiros.

7. Os Bancos de Dados Orientados a Objetos
O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados
Orientado a Objetos (SGBDOO) teve origem na combinação de idéias dos
modelos de dados tradicionais e de linguagens de programação orientada a
objetos.
No SGBDOO, a noção de objeto é usada no nível lógico e possui
características não encontradas nas linguagens de programação
tradicionais, como operadores de manipulação de estruturas, gerenciamento
de armazenamento, tratamento de integridade e persistência dos dados.

8. Os Bancos de Dados Orientados a Objetos
 Se quase todas as linguagens usadas atualmente usam o conceito de
orientação a objetos, porque o modelo de SGBDs relacionais ainda
prevalece no mercado?
 Um bom OODBMS é muito mais caro que um produto relacional “Top” de
linha.
 O modelo relacional é mais simples e possui mais recursos de
escalabilidade.
 O modelo OO possui dependência de linguagem: Um banco de dados OO
deve ser acessado através de uma API específica, normalmente através de
uma linguagem específica.

9. Os Bancos de Dados Orientados a Objetos
Resumo comparativo das características de cada modelo

10. SGBDs Relacionais
O modelo relacional se baseia no princípio de que todos os dados estão
guardados em tabelas.
Seus elementos básicos são as relações (ou tabelas), as quais são
compostas de linhas (ou tuplas) e colunas(ou atributos).
 Utiliza restrições de integridade para garantir que a integridade dos dados
seja mantida. As restrições de integridade mais comuns são as chaves
primárias e as chaves estrangeiras. A chave primária assegura a
identificação única das tuplas das tabelas. A chave estrangeira tem como
objetivo garantir a integridade dos dados referenciais, torna os valores de
determinado atributo dependentes dos valores existentes em outro atributo,
normalmente de outra tabela.

11. SGBDs Relacionais
 A chave primária assegura a identificação única das tuplas das tabelas. A
chave estrangeira tem como objetivo garantir a integridade dos dados
referenciais, torna os valores de determinado atributo dependentes dos
valores existentes em outro atributo, normalmente de outra tabela.
 A normalização consiste na separação dos dados referentes a elementos
distintos em tabelas distintas, associadas através da utilização das chaves.
 Adotou como linguagem de definição, manipulação e consulta de dados a
SQL (Structured Query Language) que é uma linguagem declarativa para
banco de dados relacionais inspirada na álgebra relacional.

12. SGBDs Relacionais
 Oferecem aos usuários processos de validação, verificação e garantias de
integridade dos dados, controle de concorrência, recuperação de falhas,
segurança, controle de transações, otimização de consultas, dentre outros.
Diagrama Modelo Relacional

13. Banco de Dados NoSQL
 O termo NoSQL surgiu em 1998, a partir de uma solução de banco de
dados que não oferecia uma interface SQL, mas esse sistema ainda era
baseado na arquitetura relacional.
 O termo passou a representar soluções que promoviam uma alternativa
ao Modelo Relacional, tornando-se uma abreviação de Not Only SQL (não
apenas SQL), sendo utilizado principalmente em casos em que o Modelo
Relacional não apresentava performance adequada.
O propósito não é substituir o Modelo Relacional como um todo, mas
apenas em casos nos quais seja necessária uma maior flexibilidade da
estruturação do banco.

14. Banco de Dados NoSQL
 O maior objetivo do NoSQL é resolver o problema de escalabilidade dos
bancos de dados tradicionais.
 Busca atender a demanda de crescimento e alta performance do mercado
WEB 2.0.
 O movimento NOSQL ganhou muita força com a publicação de dois
papers sobre implementações proprietárias: o Amazon Dynamo e o Google
Bigtable.

15. Banco de Dados NoSQL
 O Bigtable é um sistema distribuído de armazenamento de dados em
larga escala usado por muitos projetos da Google.
Não suporta um modelo relacional e provê ao usuário um modelo simples
que suporta controle dinâmico sobre o formato dos dados.
É fácilmente escalável.

16. Banco de Dados NoSQL
 O Dynamo é totalmente gerenciável focado em aplicações que requerem
uma alta demanda de requisições ao banco de dados, fornecendo uma rede
de bancos de dados distribuidos oferecidos de forma transparente ao cliente
de forma que não é necessário se preocupar com hardware, instalação e
configuração do banco de dados.
 É o próprio sistema quem replica os dados em diversos bancos e distribui
o tráfego, provendo um número suficiente de servidores para tratar qualquer
quantidade de requisições, em várias zonas de disponibilidade.

17. Banco de Dados NoSQL
 Em 2008, o Cassandra foi projetado pelo Facebook para ser um sistema
de banco de dados distribuído e de alta disponibilidade, desenvolvido para
lidar com grandes volumes de dados.
No início de 2010, o Cassandra desbancou o MySQL como banco de
dados do Twitter, demonstrando sua importância cada vez mais crescente .
O Cassandra é um banco de dados orientado à coluna, ou seja, para
qualquer linha pode possuir uma ou mais colunas, mas cada linha não
precisa possuir as mesmas colunas de outra linha.

18. Banco de Dados NoSQL
Banco de Dados Orientado a Colunas - Cassandra

19. Banco de Dados NoSQL x SGBDs Relacionais
A principal diferença entre SGDBs Relacionais e o NoSQL está na
estrutura. Enquanto o NoSQL perde para a estrutura do SGDB Relacional, o
mesmo ganha em performance, flexibilizando os sistemas de banco de
dados para as características particulares de cada organização.
Devido a sua natureza estruturada, os desenvolvedores começaram a
perceber a dificuldade em se organizar os dados do Modelo Relacional em
um sistema distribuído trabalhando com particionamento de dados. É
justamente nesse ponto em que o foco das soluções não-relacionais estão
concentradas.

20. Banco de Dados NoSQL x SGBDs Relacionais
Ao analisar a possibilidade de se optar por uma estratégia NoSQL no lugar
de um SGBD tradicional, devemos levar em conta algumas questões
básicas, por exemplo:
 Escalonamento - Nos SGBDs Relacionais é possível, mas é muito
complexa.
 Disponibilidade - Dada a dificuldade em trabalhar de forma
eficiente com a distribuição dos dados, o modelo relacional pode não
suportar a grande demanda de informações do banco.
 Consistência - Este é ponto mais forte do modelo relacional.

21. Banco de Dados NoSQL x SGBDs Relacionais
Diferenças básicas dos comandos utilizadas com NoSQL
usando como referência o Banco de Dados MongoDB

22. Conclusões
 A consistência de dados continua sendo um fator a ser considerado com
atenção e as transações dos SGBDs relacionais ainda são a melhor forma
de se trabalhar com esse problema.
 Antes de optar entre Banco de Dados Orientados a Objetos, NoSQL e
SGBDs Relacionais deve-se realizar essa analise comparativa levando em
conta os três aspectos que citamos: os critérios de escalonamento,
consistência de dados e disponibilidade.
 Não existe, em qualquer abordagem NoSQL, nada que se aproxime da
simplicidade e expressividade oferecida pelo SQL.

23. Conclusões
 Na abordagem NoSQL deixa-se de utilizar a mais simples restrição de
integridade sobre o banco, o que pode tornar a aplicação mais pesada.
 Utilizar uma solução NoSQL para bancos de dados nos quais a
disponibilidade não seja um fator imprescindível ainda é uma abordagem
discutível.
 No caso de sistemas com bases de dados gigantescas como as do
Facebook e Google, que precisem apresentar uma alta performance a
opção pelo modelo NoSQL é a mais indicada.

24. Referências
 DANIEL DA SILVA NAITO E EDER VINÍCIUS ROSA; Utilização de Banco
de Dados em computação em nuvens
 RICARDO W. BRITO; Bancos
Relacionais:Análise Comparativa
de
Dados
NoSQL
x
SGBDs
 FAY CHANG, JEFFREY DEAN, SANJAY GHEMAWAT, WILSON C. HSIEH,
DEBORAH A. WALLACH, MIKE BURROWS, TUSHAR CHANDRA, ANDREW
FIKES, ROBERT E. GRUBER, GOOGLE INC.; Bigtable: A Distributed Storage
System for Structured Data
 TIM O’REILLY; O que é Web 2.0 - Padrões de design e modelos de
negócios para a nova geração de software