Apresentação Modelo de Gestão de dados para sistemas Colaborativos

740 views
547 views

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Apresentação Modelo de Gestão de dados para sistemas Colaborativos

  1. 1. Modelo de gestão de dados para sistemas colaborativos Vanessa Martins Mozart Claret
  2. 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. 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. 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. 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. 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. 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. 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. 9. Os Bancos de Dados Orientados a Objetos Resumo comparativo das características de cada modelo
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. Banco de Dados NoSQL Banco de Dados Orientado a Colunas - Cassandra
  19. 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. 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. 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. 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. 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. 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

×