curso de pós-graduação lato sensu especialização em

UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
CURSO DE PÓS-GRADUAÇÃO LATO SENSU
ESPECIALIZAÇÃO EM BANCO DE DADOS
UM ESTUDO SOBRE BANCO DE DADOS COMO SERVIÇO
EM COMPUTAÇÃO EM NUVENS
FÁBIO ARRUDA GÓES FERREIRA
CUIABÁ – MT
2011
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
CURSO DE PÓS-GRADUAÇÃO LATO SENSU
ESPECIALIZAÇÃO EM BANCO DE DADOS
UM ESTUDO SOBRE BANCO DE DADOS COMO SERVIÇO
EM COMPUTAÇÃO EM NUVEM
FÁBIO ARRUDA GÓES FERREIRA
Orientador: Prof. Dr. CRISTIANO MACIEL
Projeto de Trabalho de Conclusão de Curso
apresentado ao Curso Lato Sensu de Banco
de Dados da Universidade Federal de Mato
Grosso, como requisito para elaboração da
Monografia do Curso Lato Sensu de banco
de dados.
CUIABÁ – MT
2011
UNIVERSIDADE FEDERAL DE MATO GROSSO
INSTITUTO DE COMPUTAÇÃO
CURSO DE PÓS-GRADUAÇÃO LATO SENSU ESPECIALIZADA
EM BANCO DE DADOS
FOLHA DE APROVAÇÃO
UM ESTUDO SOBRE BANCO DE DADOS COMO SERVIÇO EM
COMPUTAÇÃO EM NUVENS
FÁBIO ARRUDA GÓES FERREIRA
Dissertação defendida e aprovada em 09 de fevereiro de 2011, pela comissão
julgadora:
______________________________
Prof. Dr. Cristiano Maciel
IC-UFMT
______________________________
Prof. Dr. Josiel Maimone de Figueiredo
IC-UFMT
____________________________
Prof. Dr. Alessandro Copetti
IC-UFF
AGRADECIMENTOS
Ao Prof. Dr. Cristiano Maciel, pela orientação, principalmente pela
confiança depositada em mim para entregar e apresentar esse trabalho
dentro das datas estabelecidas, pela paciência, apoio e incentivo no
decorrer da elaboração deste trabalho.
A todo corpo docente do IC-UMFT, professores do curso de banco de
dados que ministraram aulas para a turma.
A minha namorada Kelly que muito paciente me ajudou nos momentos
de stress, e que dispôs de minha presença nos fim de semanas para que
eu pudesse fazer o curso;
A minha família pelo apoio e pela ajuda financeira para realizar este
curso;
A todos os colegas de curso que tornaram as aulas descontraídas.
I
SUMÁRIO
LISTA DE TABELA ............................................................................................................................. III
LISTA DE FIGURAS ........................................................................................................................... IV
LISTA DE SIGLAS E ABREVIATURAS ................................................................................................... V
LISTA DE SIGLAS E ABREVIATURAS ................................................................................................... V
RESUMO ....................................................................................... ERRO! INDICADOR NÃO DEFINIDO.
ABSTRACT ...................................................................................................................................... VII
1. INTRODUÇÃO ............................................................................................................................. 10
1.1 OBJETIVOS ................................................................................................................................. 11
1.1.1 Objetivo Geral ................................................................................................................... 11
1.1.2 Objetivos Específicos ......................................................................................................... 11
1.2 METODOLOGIA ......................................................................................................................... 11
2. SISTEMAS DE BANCO DE DADOS ................................................................................................ 12
2.1. CONCEITO ................................................................................................................................. 12
2.2 VANTAGENS DO BANCO DE DADOS .......................................................................................... 16
2.3 SISTEMA GERENCIADOR DE BANCO DE DADOS – SGBD ........................................................... 17
2.4 OBJETIVOS E FUNÇÕES BÁSICAS DOS SGBD’S ........................................................................... 19
2.5 ARQUITETURA BÁSICA DE UM SGBD ........................................................................................ 20
2.6 PROJETOS DE BANCO DE DADOS .............................................................................................. 22
3 MODELOS DE BANCO DE DADOS ................................................................................................. 23
3.1 MODELOS LÓGICOS BASEADO EM REGISTROS ......................................................................... 23
3.1.1 Modelo de dados relacional ............................................................................................. 23
3.1.2 Modelo de banco de dados de rede ................................................................................. 26
3.1.3 Modelo de dados Hierárquico .......................................................................................... 27
3.2 MODELOS LÓGICOS BASEADOS EM OBJETOS ........................................................................... 28
3.2.1 Modelo entidade-relacionamento.................................................................................... 29
3.2.2 Modelo Orientado a Objeto.............................................................................................. 30
3.3 MODELO DE BANCO DE DADOS DISTRIBUÍDO .......................................................................... 32
3.4 MODELO DE BANCOS DE DADOS CORPORATIVO ..................................................................... 33
4 COMPUTAÇÃO EM NUVENS ........................................................................................................ 34
4.1 CONCEITO .................................................................................................................................. 34
4.2 BENEFÍCIOS DA COMPUTAÇÃO EM NUVENS ............................................................................ 39
4.3 SEGURANÇA E PRIVACIDADE .................................................................................................... 41
4.4 SERVIÇOS OFERECIDOS ............................................................................................................. 42
4.5 APLICAÇÕES ............................................................................................................................... 43
4.6 TIPOS DE NUVENS ..................................................................................................................... 44
4.7 ARQUITETURA EM NUVENS ...................................................................................................... 46
4.7.1 MapReduce ....................................................................................................................... 48
4.7.2 Hadoop .............................................................................................................................. 49
4.7.3 Sharding ............................................................................................................................ 50
5 BANCO DE DADOS NAS NUVENS ................................................................................................. 52
5.2 CONCEITO .................................................................................................................................. 52
5.2 MODELO DE DADOS BASEADO EM SERVIÇOS .......................................................................... 53
II
5.3 LIMITAÇÕES DO MODELO DAAS ............................................................................................... 55
5.4 CONSULTAS ............................................................................................................................... 56
5.5 SEGURANÇA .............................................................................................................................. 57
5.6 ARQUITETURAS UTILIZADAS EM BANCO DE DADOS EM NUVENS ........................................... 59
5.7 SISTEMAS GERENCIADORES DE BANCO DE DADOS PARA NUVENS ......................................... 62
5.7.1 Microsoft SQL Azure .......................................................................................................... 63
5.7.2 BigTable ............................................................................................................................ 65
5.7.3 Cassandra .......................................................................................................................... 67
5.7.4 SimpleDB ........................................................................................................................... 68
5.7.5 Relational Cloud ................................................................................................................ 70
5.7.6 CouchDB ............................................................................................................................ 72
6 ANÁLISE COMPARATIVA DE SGBDS PARA NUVENS ..................................................................... 75
6.1 MICROSOFT SQL AZURE ............................................................................................................ 77
6.2 BIGTABLE ................................................................................................................................... 77
6.3 SIMPLEDB .................................................................................................................................. 78
6.4 CASSANDRA............................................................................................................................... 79
6.5 RELATIONAL CLOUD .................................................................................................................. 79
6.6 COUCHDB .................................................................................................................................. 80
7. CONSIDERAÇÕES FINAIS ............................................................................................................. 84
8. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................... 85
III
LISTA DE TABELA
TABELA 01. REGRAS DE SGSB - DATE (2004, P. 23). -------------------------------------------------- 18
TABELA 02 - REQUISITOS PARA SGBD COMO UM SERVIÇO (CURINO ET AL. 2010) ------ 76
TABELA 03. COMPARAÇÃO DOS SISTEMAS – (SOUSA ET AL. 2010) ---------------------------- 81
IV
LISTA DE FIGURAS
FIGURA 01 - COMPONENTES DE UM SISTEMA DE BANCO DE DADOS (KORTH, 2006) ... 14
FIGURA 02 - NÍVEIS DE ABSTRAÇÃO (KORTH, 2006). ............................................................. 22
FIGURA 03 - MODELO RELACIONAL (MORAIS, 2009) ............................................................ 25
FIGURA 04 - ENTIDADE RELACIONAMENTO (MORAIS, 2009)............................................... 30
FIGURA 05 - MODELO DE COMPUTAÇÃO EM NUVEM (CAVALCANTI, 2010) .................... 36
FIGURA 06 - CAMADA CONCEITUAL DE UMA NUVEM (VOAS E ZHANG, 2009) ............... 37
FIGURA 07 - DATACENTER (SEA SERVER, 2011) ...................................................................... 38
FIGURA 08 - CONEXÕES EM NUVENS. (MENESES E CRUZ, 2009) ......................................... 40
FIGURA 09 - ARQUITETURA DE CLOUD (FOSTER, 2008) ........................................................ 47
FIGURA 10 - PROCESSO DE CONSULTA CRIPTOGRAFADO (TRADUZIDO DE HOLANDA,
2008) ........................................................................................................................................... 58
V
LISTA DE SIGLAS E ABREVIATURAS
SaaS
Software as a Service (Software Baseado em Serviço)
IaaS
Infrastucture as a Service (Infraestrutura Baseada em Serviço)
PaaS
Platform as a Service (Plataforma Baseada em Serviço)
DaaS
Database as a Service (banco de dados como Serviço)
SGBD
Sistema de Gerenciamento de banco de dados
B.I
Business Intelligence (Inteligência do Negócio)
VI
RESUMO
FERREIRA, F. A. G. Um estudo sobre banco de dados como serviço em
computação em nuvens. Cuiabá, 2010. 84p. Pós-Graduação Lato Sensu em Banco
de dados. Instituto de Computação, Universidade Federal de Mato Grosso.
Com a crescente demanda por armazenamento, processamento e disponibilidade de
dados de diversas fontes e formas, grande empresas tem focado em criar novas
formas de oferecer serviços de banco de dados. Com essa nova tendência, vem
também sendo crescente a preocupação em garantir requisitos como segurança,
agilidade, operabilidade, manutenabilidade, e, não menos importante, economizando
recursos financeiros dos clientes. Neste ponto cria-se um novo paradigma para a
gestão de dados em que um prestador de serviço terceirizado (hosts), oferece um
banco de dados como um serviço prestado, proporcionando aos seus clientes
mecanismos para criar, armazenar e acessar seus bancos de dados pela rede internet.
Esses recursos ficam disponíveis sem que os clientes tenham a necessidade de saber
que os dados estão espalhados geograficamente, porém garantindo a eles
principalmente a velocidade do serviço, a flexibilidade de aumentar os recursos em
questão de minutos com um custo de uso por utilização dos serviços. Face ao
exposto, o presente trabalho trata o paradigma de banco de dados voltado para
nuvem computacional, abordando alguns sistemas gerenciadores de banco de dados
conhecidos e usados no meio empresarial, bem como a comparação entre segurança e
armazenamento desses SGDBs. Os SGDBs investigados nesse trabalho são SQL
Azure, Relational Cloud, CouchDB, SimpleDB e BigTable. A metodologia aplicada
nesta pesquisa é exploratória e de forma comparativa, por meio de materiais
bibliográficos e pesquisas em diversas fontes como livros e repositórios da Web.
Palavras Chave: Computação em Nuvem; Banco de dados; Banco de dados como
Serviço.
VII
ABSTRACT
FERREIRA, F. A. G. A study on the database as cloud computing service. Cuiabá,
2010. 84p. Pós-Graduação Lato Sensu em banco de dados. Instituto de computação,
Universidade Federal de Mato Grosso.
As the demand has growing for storage, processing and availability of data from
various sources and forms, big companies have focused on creating new ways to
provide services database. With this new trend comes also a rising concern as to
ensure safety requirements, flexibility, operability, maintainability, and, not less
important, saving financial resources of clients. At this point it comes a
new paradigm for data management as an outsourced service provider (Hosts), offers
a database as a service, providing mechanisms to its customers to create, store and
access your bank Internet data over the network. These resource are available
without customers have to know that the data are scattered geographically, but
guaranteeing them primarily the speed of service, flexibility to increase resources in
minutes at a cost of use by service utilization. In the of her Hans this essay of master
discuss about the paradigm of database oriented for cloud computing, including
some management systems, database known and used throughout business, as well as
the comparison between security and storage of DBMSes. The DBMSes investigated
in this work are Azure SQL, Relational Cloud CouchDB, SimpleDB and
BigTable. The methodology applied in this research is exploratory and comparative
way, by means of bibliographic materials and research from several sources such as
books and web repositories
Keywords: Cloud Computing, Database, Database as a Service.
10
1. INTRODUÇÃO
A grande corrida armamentista das organizações na área de tecnologia tem
aumentado o número de dados disponíveis, e tem uma exigência cada vez maior de
segurança e confiabilidade dos seus dados e serviços gerados por novas aplicações
como WEB 2.0, B.I (Business Intelligence); de maneira que, os métodos
convencionais de armazenamento, processamento e distribuição já não são capazes
de atender a tais demandas.
Com as novas necessidades, grandes indústrias da área tecnológica, como
GOOGLE INC e MICROSOFT, vem cada vez mais investindo em formas de quebrar
paradigmas para compatibilizar o crescimento com a demanda crescente de dados
gerados.
A essa problemática tem se projetado o conceito de “Cloud Computing” ou
computação em nuvem, que é uma forma nova de se construir as camadas de
softwares, infraestrutura e banco de dados, baseados em servidores virtualizados ou
não, disponibilizados para terceiros por fornecedores independentes e distribuídos
geograficamente pelo mundo todo. Desta forma a organização troca seus recursos de
processamento locais, por recursos disponibilizados pela nuvem, sem se preocupar
como e onde está processando ou armazenando seus dados.
A essa nova tendência, surgem também novos problemas para ser
investigado, como o atual modelo de armazenamento e organização dos sistemas
gerenciadores de banco de dados (SGBD).
Os sistemas gerenciadores de banco de dados são em sua maioria relacionais,
com a forma de armazenar, manipular e recuperar dados estruturados unicamente
baseados em tabelas relacionadas por meio de chaves e organizadas por atributos,
dificultando à alta escalonabilidade dos mesmos.
Tornando o processo de construção do banco de dados em Nuvens, ou
baseado em serviços em um trabalho complexo e/ou inatingível muitas das vezes.
Novos SGDB estão introduzindo novas técnicas para adaptar ou resolver os
problemas dos modelos relacionais de banco de dados. Os SGDBs desenvolvidos
para tais soluções, ainda são poucos populares e com tecnologias diversas. As
11
principais serão pesquisados nesse trabalho, a fim de mostrar suas principais funções
e delimitações, e traçar uma pequena amostra de alguns pontos como segurança,
benefícios, armazenamento e outros fatores que venha ser encontrado em sua
estrutura.
1.1 OBJETIVOS
1.1.1 Objetivo Geral
Traçar um comparativo das principais tecnologias envolvendo sistemas
gerenciadores de banco de dados como serviço no modelo de nuvens
computacionais, focando nos aspectos de armazenamento e segurança.
1.1.2 Objetivos Específicos
I.
II.
Abordar a tecnologia de banco de dados em Nuvens.
Traçar pontos fortes e fracos no uso de bancos de dados em Nuvens.
III.
Pesquisar por sistemas gerenciadores de banco de dados focados para nuvem.
IV.
Apresentar os benefícios principais do uso do SGDB para nuvem.
1.2 METODOLOGIA
A metodologia utilizada é de pesquisas exploratórias e métodos
comparativos, por meio de materiais bibliográficos e pesquisas na internet, incluindo
bases de dados especializadas tais como Google acadêmico, Google books e
Asssociation for Computing Machinery (ACM).
12
2. SISTEMAS DE BANCO DE DADOS
Atualmente, as empresas precisam de informações rápidas, seguras e exatas
para sobreviverem num mercado altamente competitivo. As ferramentas de banco de
dados agrupadas na internet vem suprir essas necessidades, oferecendo fácil acesso a
comunicação e manipulação de informações em qualquer parte do mundo. Com isso,
vários fornecedores procuram satisfazer as necessidades do mercado, trazendo para
os bancos de dados os recursos que as empresas e seus clientes necessitam,
melhorando assim seus produtos.
Este capítulo abordará sobre o sistema de banco de dados, demonstrando o
seu conceito, os seus elementos, e as suas vantagens. Aborda ainda o funcionamento
do sistema gerenciador de banco de dados (SGBD), bem como os seus objetivos e
funções. Finalizando, descreve a arquitetura básica de um SGBD e discute o projeto
de banco de dados.
2.1. CONCEITO
O conceito de banco de dados segundo Medeiros (2006, p. 10):
É uma das tecnologias mais poderosas e duradouras do ambiente de
sistemas de informações. Ele inclui uma variedade de questões técnicas e
gerenciais, além de recursos que estão no centro da cena dos sistemas de
informação de hoje.
Conforme vimos, o conceito acima destaca que o sistema de banco de dados
é fundamentalmente um sistema computadorizado de manutenção de registros; em
outras palavras, é um sistema computadorizado cujo objetivo, geral é armazenar
informações e permitir que os usuários busquem e atualizem essas informações
quando as solicitar.
Conforme Biazus (2010):
As informações em questão podem ser qualquer coisa que tenha algum
significado ao individuo ou a organização a que o sistema deve servir, ou
seja, qualquer coisa que seja necessária para auxiliar no processo das
atividades desse individuo ou dessa organização.1
1
http://www.scribd.com/doc/7507097/Introdu-o-a-banco-de-dados-1-Alunos
13
Para Ozsu e Valduriez (2001, p. 14): “Um sistema de banco de dados (SBD)
é basicamente um sistema de manutenção de registros por computador. O objetivo
dos SBDs é manter os registros e disponibilizar quando solicitados”.
Podemos dizer que a tecnologia de banco de dados deve-se especialmente
aos especialistas que desenvolveram os sistemas nas organizações, sentindo eles a
necessidade de um armazenamento de dados mais eficiente que os arquivos
tradicionais,
pois,
estes
apresentavam
poucos
métodos
de
acesso
e
predominantemente seqüencial.
Segundo Korth (2006, p. 10) um banco de dados “é uma coleção de dados
inter-relacionados, representando informações sobre um domínio específico”, ou
seja, sempre que for possível agrupar informações que se relacionam e tratam de um
mesmo assunto, posso dizer que tenho um banco de dados.
Podemos dizer que, a definição de um banco de dados é um conjunto de
informações, estruturadas de forma a organizá-la para facilitar operações como
inserção, busca e remoção sobre estes dados. Estas informações são em regra
manipuladas por um software que gerencia sua estrutura e operações que possam ser
realizadas.
Segundo Melo et al. (1997, p. 3), um sistema de banco de dados pode
ser definido como “um ambiente de hardware e software composto por dados
armazenados em banco de dados (BD), o software que gerencia o banco de dados
(SGBD) e os programas de aplicação”.
Banco de dados é um termo que deve ser aplicado apenas aos dados,
enquanto o termo sistema gerenciador de bancos de dados deve ser aplicado ao
software com a capacidade de manipular bancos de dados de forma geral. Porém, é
comum misturar os dois conceitos.
Ao final, temos que avaliar um sistema de banco de dados como o conjunto
de quatro elementos básicos: dados, hardware, software e usuários.
Date (2004, p. 18) conceituou que “sistema de bancos de dados pode ser
considerado como uma sala de arquivos eletrônica”. A figura 01 ilustra os
componentes de um sistema de banco de dados.
14
FIGURA 01 - Componentes de um sistema de banco de dados (KORTH, 2006)
Segue conceitos dos elementos de um sistema de banco de dados:
Conforme Date (2004, p. 20):
dados (grifo nosso) é um repositório, que pode ser qualificado como
integrado ou compartilhado. O banco de dados integrado visa ao controle
de total eliminação da redundância de dados geralmente encontrada em
sistemas de arquivos comuns (gerenciadores de arquivos); o
compartilhado visa ao acesso de vários usuários a uma mesma parte dos
dados, com finalidades distintas.
A consistência e segurança dos dados são importantes para a computação
em nuvem e acredita-se que futuras aplicações centradas em dados irão alavancar os
serviços de dados em nuvem.
De acordo com Heuser (2009, p. 28):
Hardware (grifo nosso) tendo este como elemento os Volumes de
armazenamento secundário são normalmente, discos magnéticos, que são
usados para manter os dados armazenados, juntamente com os
dispositivos de entrada/saída associados (unidades de discos, etc.),
controladores de dispositivos, canais de entrada/saída e assim por diante.
O Processador de hardware e memória é associado, para dar suporte à
execução do software do sistema de banco de dados.
Além disso, o hardware é a parte física do computador, onde engloba tudo
que pode se visto e/ou tocado no computador, como por exemplo, o gabinete, placas,
memórias e periféricos. Cada máquina física tem as mesmas configurações de
software, mas pode ter variação na capacidade de hardware em termos de CPU,
memória e armazenamento em disco.
Para Korth (2006, p. 25):
Software (grifo nosso) é uma camada no banco de dados físico,
relacionados aos dados fisicamente armazenados e aos usuários do
sistema, conhecida como administrador de banco de dados ou servidor de
bando de dados ou, mais freqüentemente, como sistema gerenciador de
banco de dados (SGBD). Todas as requisições de acesso ao banco de
15
dados são tratadas pelo SGBD; os recursos para acrescentar e remover
arquivos (ou tabelas), buscar dados e atualizar dados em tais arquivos ou
tabelas, e assim por diante, são facilidades fornecidas pelo SGBD.
O sistema gerenciador de banco de dados é o componente de software mais
importante entre todos os sistemas, mas não é o único. Conforme Medeiros (2006, p.
14): “Outros componentes incluem utilitários, ferramentas de desenvolvimento de
aplicações, recursos para auxiliar no projeto, geradores de relatórios e o gerenciador
de transações”. A sigla SGBD também é usada para citar, determinado produto
especifico de um determinado fornecedor em particular.
Date (2004, p. 20-21) afirma que:
Usuários (grifo nosso) são os objetivos primordiais do sistema de banco
de dados, proporcionarem ambiente para a consulta às informações e para
o armazenamento de novas informações no banco de dados. Há diferentes
tipos de usuários de um sistema de banco de dados e são diferenciados
pela maneira que se propões a interagir com o sistema.
Os profissionais de computação que trabalham com o sistema utilizando
comandos de DML, são chamados de programadores de aplicação, os comandos de
DML são programas escritos em linguagens de programação (Cobol, PL/1, Pascal,
C).
De acordo com Mecenas e Oliveira (2005, p. 30) em sua abra, ensina que:
Estes programas são comumente chamados de programas de aplicação.
Exemplos de programas de aplicação em um sistema bancário incluem
um programa que gera cheques de pagamento, debita e credita uma conta,
transfere fundos entre contas, etc.
Os programadores são responsáveis pela escrita de programas de aplicações
de banco de dados em alguma linguagem de programação. Esses programas acessam
o banco de dados emitindo a requisição apropriada ao SGBD.
Conforme Heuser (2009, p. 29):
Usuários ocasionais (grifo nosso) são usuários sofisticados, que
interagem com o sistema sem escrever programas. Em vez disso
formulam requisições escrevendo suas consultas em linguagem de
consulta. Cada uma dessas consultas é submetida a um processador de
consultas, cuja função é quebrar um comando DML em instruções que o
gerenciador do banco de dados entenda;
Portanto, os usuários ocasionais, formulam suas solicitações ao banco de
dados através de linguagens de consultas. Interagem sem escrever programas.
Para Korth (2006 p. 25-26):
16
Usuários simples (grifo nosso) são os usuários que não são sofisticados,
que interagem com o sistema utilizando-se dos programas de aplicação
existentes. Por exemplo, um caixa de banco que necessita transferir
R$150,00 de uma conta A para uma conta B deve invocar um programa
chamado transfer. Este programa deve perguntar ao caixa a quantidade de
dinheiro a ser transferida e a conta para onde o dinheiro deve ser
transferido;
Ademais, o usuário simples interage com o sistema, através de programas de
aplicações.
Conforme Date (2004, p. 21):
Usuários especializados (grifo nosso) entram como usuários sofisticados
que escrevem aplicações de banco de dados não adaptáveis aos padrões
tradicionais de processamento de dados. Entre essas aplicações estão
sistemas de computer-aided design, bases de conhecimento e sistemas
especialistas, que armazenam dados com tipos de dados complexos como
dados gráficos e dados de áudio e sistemas de modelagem de ambiente.
Enfim, o usuário especializado escreve aplicações especializadas de banco
de dados não tradicionais, como as: bases de conhecimentos, sistemas especialistas e
tipos de dados complexos.
2.2 VANTAGENS DO BANCO DE DADOS
O banco de dados armazena os dados em um único local na organização
desta forma, eliminam-se redefinições de dados idênticos e reduz de maneira drástica
a redundância, que anteriormente encontravam duplicadas nas diversas aplicações.
No compartilhamento de dados há facilidade em integrar novas aplicações à
organização, uma vez que não é necessário redefinir o que já existe, nem incluir
dados já presentes no banco de dados.
Conforme demonstra Mecenas e Oliveira (2005, p. 32) em sua obra:
Todos os procedimentos para tratamento de dados são agora realizados
pelo banco de dados causando uma independência dos dados, isto é, os
dados não precisam estar na área de armazenamento onde executa a
aplicação. Além disso, modificações nestes procedimentos não afetam a
aplicação, ou seja, esta não necessita ser recopilada.
O acesso do banco de dados é por meio de linguagens de alto nível.
Anteriormente era necessário programar um procedimento para realizar uma
operação sobre os dados, agora basta apenas escrever um pequeno comando nesta
linguagem de manipulação.
17
2.3 SISTEMA GERENCIADOR DE BANCO DE DADOS
– SGBD
O sistema gerenciador de banco de dados pode ser relacionado a um
conjunto de programas inter-relacionados cujo objetivo principal é equipar um
ambiente que seja adequado e eficiente para recuperar e armazenar informações de
banco de dados, além de gerenciar o acesso e a correta manutenção dos dados
armazenados. O acesso acontece por forma de linguagem onde aceita a comunicação
com aplicação por meio de uma interface amigável ao usuário. Garantindo ao sistema
gerenciador de banco de dados a integridade, segurança e concorrência, de modo a
evitar dados inconsistentes.
De acordo com Medeiros (2006, p. 16) em sua obra, demonstra que o:
Surgimento teve início na década de 70 com o objetivo de facilitar a
programação de aplicação de banco de dados (BD). Os primeiros sistemas
eram caros e difíceis de usar, requerendo especialistas treinados para
utilizar o SGBD específico.
Com o transcorrer dos anos, os SGBD’s foram evoluindo através de
pesquisas e novas tecnologias foram desenvolvidas melhorando as interfaces e,
portanto, facilitando o manuseio dos dados; conseqüentemente os SGBD’s tornaramse mais populares entre as classes de profissionais da área de desenvolvimento.
Conforme Date (2004, p. 22):
O SGBD em regra interage com diversas aplicações de uma organização
através da Linguagem de Manipulação de dados (DML) embutidos no seu
código e a comunicação com os meios de armazenamento de dados
geralmente é efetuada por meio de interface com o sistema operacional do
equipamento, para leitura e gravação de dados.
Podemos dizer que para o gerenciamento de dados, são importantes os itens
como a integridade, segurança, concorrência, acesso e autorização, os quais citados
são responsabilidade do sistema gerenciador de banco de dados. No próximo item
serão apresentadas as principais funções dos SGBD’s.
Conforme o Machado (2008, p. 25) explana em sua obra:
Existem algumas regras básicas e claras para que um sistema de
manipulação de dados possa ser considerado um SGBD. Fica implícito
que se ao menos uma das características abaixo não estiver presente no
nosso "candidato" a SGBD, este poderá ser um Gerenciador de Arquivo
de altíssima qualidade, "quase" um SGBD, mas não um SGBD.
18
No quadro abaixo podemos visualizar melhor as explicações referente às
regras segundo Date (2004, p. 23):
REGRA
EXPLICAÇÃO
Um SGBD não contém apenas os dados em si, mas armazena
completamente toda a descrição dos dados, seus relacionamentos e formas
Auto-Contenção
de acesso. Normalmente esta regra e chamada de Meta-Base de dados.
Quando as aplicações estiverem realmente imunes a mudanças na estrutura
de armazenamento ou na estratégia de acesso aos dados, podemos dizer que
esta regra foi atingida. Portanto, nenhuma definição dos dados devera estar
Independência dos dados
contida nos programas da aplicação.
O chamado Modelo de dados e um tipo de abstração utilizada para fornecer
esta representação conceitual. Neste modelo, um esquema das tabelas, seus
relacionamentos e suas chaves de acesso são exibidas ao usuário, porem
nada e afirmado sobre a criação dos índices, ou como serão mantidos, ou
Abstração dos dados
qual a relação existente entre as tabelas que devera ser mantida integra.
Um SGBD deve permitir que cada usuário visualize os dados de forma
diferente daquela existente previamente no banco de dados. Uma visão
Visões
consiste de um subconjunto de dados do banco de dados, necessariamente
derivados dos existentes no banco de dados.
Um SGBD deve gerenciar completamente a integridade referencial definida
em seu esquema, sem precisar em tempo algum, do auxilio do programa
aplicativo. Desta forma exige-se que o banco de dados tenha ao menos uma
instrução que permita a gravação de uma serie modificações simultâneas e
uma instrução capaz de cancelar uma série modificações. Por exemplo,
Transações
imaginemos que estejamos cadastrando um pedido para um cliente, que
este deseje reservar cinco itens de nosso estoque, que estão disponíveis e,
portanto é reservado, porem existe um bloqueio financeiro (duplicatas em
atraso) que impede a venda. A transação devera ser desfeita com apenas
uma instrução ao banco de dados, sem qualquer modificação suplementares
nos dados.
Em um Gerenciador de Arquivos uma situação típica e o chamado DeadLock, o abraço mortal. Esta situação indesejável pode ocorrer toda vez que
um usuário travou um registro em uma tabela e seu próximo passo será
travar um registro em uma tabela relacionada à primeira, porem se este
registro estiver previamente travado por outro usuário, o primeiro usuário
ficara paralisado, pois, estará esperando o segundo usuário liberar o registro
em uso, para que então possa travá-lo e prosseguir sua tarefa. Se por
hipótese o segundo usuário necessitar travar o registro travado pelo
primeiro usuário, afirmamos que ocorreu um abraço mortal, pois cada
usuário travou um registro e precisa travar outro, justamente o registro
Acesso Automático
anteriormente travado pelo outro. Imaginemos um caso onde o responsável
pelos pedidos acabou de travar o Registro Item de Pedido, e, necessita
travar um registro no Cadastro de Produtos, para indicar uma nova reserva.
Se concomitantemente estiver sendo realizada uma tarefa de atualização de
pendências na Tabela de Itens, e para tanto, previamente este segundo
usuário travou a Tabela de Produtos, temos a ocorrência do abraço mortal.
TABELA 01. REGRAS DE SGSB - DATE (2004, P. 23).
19
2.4 OBJETIVOS E FUNÇÕES BÁSICAS DOS SGBD’S
Descreveremos abaixo os principais objetivos e funções de um sistema
gerenciador de banco de dados.
Segundo Machado (2008, p. 26):
Os objetivos de um sistema de banco de dados são o de isolar o usuário
dos detalhes internos do banco de dados (promover a abstração de dados)
e promover a independência dos dados em relação às aplicações, ou seja,
tornar independente da aplicação, a estratégia de acesso e a forma de
armazenamento.
Nos sistemas gerenciadores de banco de dados os seus acessos devem ser
feitos de forma eficaz, procurando tornar mínimo o número de acessos ao meio de
armazenamento secundário. Eles suportam duas categorias de linguagens, são elas:
Conforme Reis (2000, p. 20):
Linguagem de definição de dados (DDL) (grifo nosso) aceita a
modelagem lógica dos dados, ou seja, entidades com seus atributos e tipos
de dados associados; os relacionamentos entre estas entidades e os índices
de acesso associados aos atributos.
De acordo com Reis (2000, p. 20): “Linguagem de manipulação de dados
DML (grifo nosso) permite as operações usuais de manipulação de dados (inclusão,
alteração, exclusão e consulta), executados pelas aplicações”.
Podemos articular que a independência lógica além de garantir a
modelagem das visões de cada usuário também evolui de uma forma sem interferir
em outras visões onde haja compartilhamento de dados. Não podendo deixar as
evoluções das visões globais interferirem nas visões particulares.
Conforme Date (2004, p. 37): “A independência física garante que
mudanças no armazenamento dos dados, por qualquer razão, não repercutem na
definição conceitual dos dados”.
A sua facilidade de consulta deve ser aceitável especificar apenas o que se
deseja consultar ou manipular e não como fazê-lo. Linguagens declarativas são uma
tendência natural nesta interface, dada sua elegância e clareza semântica.
Sua administração centralizada de dados tem como setor de administração,
através do controle das estruturas de armazenamento e estruturas de dados, visa
garantir a coerência dos dados.
De acordo com Greff (2010, p. 9):
20
A não redundância dos dados é um dos problemas dos sistemas de
arquivos tradicionais era a duplicação desordenada dos dados pelos
diferentes arquivos. Um dos principais objetivos dos SGBD é o de evitar
a redundância dos dados.
Só ocorrerá a não redundância dos dados, por causa da sua estruturação, que
é integrada nos bancos de dados e a sua administração centralizada. Em casos
eventuais (desempenho, decisões de projeto) onde se justifique uma duplicação, os
SGBDs controlarão a redundância mais facilmente que os sistemas convencionais de
gerenciamento de arquivos.
Para Greff (2010, p. 9):
A coerência dos dados provê mecanismos que garantem a coerência dos
bancos de dados, em geral através de restrições de integridade ligadas às
propriedades dos dados. Os SGBD são responsáveis pelo controle destas
restrições (regras).
Através do seu compartilhamento de dados é permitido que vários usuários
tenham a capacidade de acessar aos mesmos dados, de forma simultânea, para
garantir a integração dos dados quando for compartilhado ao mesmo tempo.
Segundo Date (2004, p. 38): “A segurança dos dados está relacionada com a
acessibilidade dos dados. O objetivo é o de garantir acesso ao banco de dados ou
parte deste apenas por pessoas devidamente autorizadas”.
De acordo com Reis (2000, p. 19):
Os SGBD’s, apesar de oferecerem todas estas vantagens para os
desenvolvedores de aplicações, necessitam ser devidamente escolhidos,
de forma a se adequarem com a plataforma computacional onde a
aplicação executará. Muitas vezes, dependendo desta plataforma, os
SGBD’s podem ser mais ou menos poderosos.
2.5 ARQUITETURA BÁSICA DE UM SGBD
O SGBD pode ser notado como um sistema que fornece ao usuário as
informações necessárias nos dados armazenados, isto é, o sistema omite certos
detalhes de como os dados são armazenados e mantidos simplificando a interação do
usuário com os dados.
Conforme Date (2004, p.39):
Pode-se dizer que o SGBD tem um nível interno, onde é descrito a
estrutura de armazenamento físico dos dados, um nível intermediário,
21
onde se tem a descrição lógica dos dados e um nível externo onde são
descritas as visões para grupos de usuários.
O grande objetivo de um sistema de banco de dados é fornecer aos usuários
uma visão abstrata dos dados. Esta abstração se dá em três níveis:
Para Freitas (2000, p.21) o primeiro é o nível físico:
Onde corresponde ao nível menos abstrato, onde se sabe detalhes físicos
da organização de um dado. É uma estruturação de baixo nível, onde é
descrito como os dados estão armazenados, em termos de bytes (tamanho
de registros, tamanho e posição de campos). O módulo de gerenciamento
de arquivos do SGBD lida com este nível de visão dos dados, uma vez
que localiza, lê e grava registros;
Portanto, o nível físico é o mais baixo de abstração descreve como os dados
estão realmente armazenados. Esse nível possui complexas estruturas de dados de
baixo nível sendo descritas em detalhes.
Elencando Freitas (2000, p.21) sobre o nível conceitual:
Este corresponde ao nível intermediário, que suporta uma descrição de
mais alto nível em relação ao nível físico, onde a preocupação está em
descrever quais dados são significativos para uma organização. Neste
caso, se lida com os dados em nível de entidades e relacionamentos, tal
qual está definido no esquema. É similar, por analogia, à descrição de um
registro em uma linguagem de programação, ou seja, se lida com nomes
de arquivos e campos e não com seqüências de bytes;
Dessa forma, o nível conceitual descreve quais dados estão armazenados de
fato no banco de dados e as relações que existem entre eles. Sendo o banco de dados
descrito por inteiro em termos de um pequeno número de estruturas relativamente
simples. Esse nível é usado por administradores de banco de dados, que podem
decidir quais informações devem ser mantidas no sistema.
Segundo Freitas (2000, p.21), sobre o nível de visão: “Que é o nível mais
alto de abstração, sendo particular de cada aplicação que manipula dados do BD.
Este universo de dados pode ser uma porção do esquema global da organização”.
Apesar do uso de estruturas desse nível ser o mais simples do que no nível
conceitual, alguma complexidade perdura devido ao grande tamanho do banco de
dados.
22
FIGURA 02 - Níveis De Abstração (KORTH, 2006).
Para ter um bom suporte de dados o sistema gerenciador de banco de dados
necessita realizar mapeamentos sobre os três níveis, deixando assim de forma
transparente, para o usuário de um nível mais alto, a organização do dado nos níveis
mais baixos.
2.6 PROJETOS DE BANCO DE DADOS
Conforme Heuser (2009, p.31) afirma que:
Todo bom sistema de banco de dados deve apresentar um projeto, que
visa à organização das informações e utilização de técnicas para que o
futuro sistema obtenha boa performance e também facilite infinitamente
as manutenções que venham a acontecer.
O projeto de um novo banco de dados dá-se em três fases:
Conforme Bolzan (2010): “Modelagem Conceitual (grifo nosso) permite
nesta fase inicial e construído um modelo conceitual, na forma de um diagrama
entidade-relacionamento. Este modelo independe da implementação”.
De acordo com Heuser (2009, p.32):
O Projeto Lógico (grifo nosso) tem como objetivo transformar o modelo
conceitual obtido na primeira fase em um modelo lógico. O modelo
lógico define como o banco de dados será implementado em um Sistema
de Gerenciador de banco de dados especifico.
Elenca Date (2004, p. 40):
O Projeto Físico (grifo nosso) nesta etapa o modelo de BD será
enriquecido com detalhes que influenciam no desempenho do BD, mas
não interferem em sua funcionalidade. Alterações neste modelo não
afetam as aplicações que usam o BD.
23
3 MODELOS DE BANCO DE DADOS
Atualmente, os sistemas de banco de dados podem ser agrupados em
modelos, os quais representam claramente os diversos estágios de evolução até
chegar aos padrões atuais. Neste capítulo serão analisados os principais modelos
existentes de banco de dados, sendo esses responsáveis pela sua evolução.
3.1 MODELOS LÓGICOS BASEADO EM REGISTROS
Podemos dizer que os modelos representam estruturas das tabelas de uma
forma próxima à existente fisicamente, usando sua descrição de dados nos níveis
conceitual e visual. A denominação modelos baseados em registros significa que o
banco de dados é estruturado em registros tendo o seu formato fixo de diversos tipos.
Cada tipo de registro define um numero fixo de campos ou atributos e cada campo é
usualmente de um tamanho fixo.
Vamos mencionar três modelos de dados: o relacional, de rede e o
hierárquico, que serão mencionados neste capítulo.
3.1.1 Modelo de dados relacional
Segundo Medeiros (2006, p. 36) a definição clássica de modelo relacional:
“São conjunto de dados visto segundo um conjunto de tabelas e as operações sobre
elas são feitas por linguagem que manipulam a álgebra relacional, não sendo
procedural, ou seja, manipulando conjuntos de uma só vez.”
De acordo com Date (2004, p. 41): “O conceito principal vem da teoria dos
conjuntos da álgebra relacional. Não é relevante ao usuário, saber onde os dados
estão, nem como os dados estão (transparência)”.
Os usuários manejam objetos dispostos em linha e colunas das tabelas.
Tendo na álgebra relacional conjunto de operadores e funções de alto nível.
Conforme Heuser (2009, p. 33):
O banco de dados mais utilizado atualmente e o banco de dados
relacional, principalmente pelas suas fortes características de seguranças,
compartilhamento e integridade dos dados, fatores primordiais para uma
administração eficaz da informação de qualquer empresa. Com o próprio
24
nome diz, esse tipo de banco de dados é composto de relações entre
entidades, denominadas tabelas, seguindo o mesmo conceito matemático
de relação.
Relacionado por meio de chave as tabelas, onde as chaves são chamadas de
estrangeiras, podendo esta ser de forma simples, formando apenas um atributo, ou
compostas, formadas por vários atributos. Já o atributo compreende-se a
representação de um tipo de informação.
Elenca Date (2004, p. 42):
Para que um modelo seja considerado relacional, os dados devem ser
armazenados em tabelas, nenhum ponteiro ou ligação deve ser visível ao
usuário, a linguagem de consulta deve ser relacionalmente completa e as
consultas podem ser expressas sem uso de iterações ou recursões. Cada
linha da tabela, formada por um conjunto de colunas, representa um
registro ou tupla.
Devemos mencionar que os registros não necessitam ter dados em todas as
colunas, porque os seus valores podem ser nulos. Denominando de campos as
colunas de uma tabela. Tendo os campos características que definem o dado que será
armazenado. Os dados do SGBD’s são armazenados por possuírem normas que irão
reger. Podendo existir em um banco de dados uma ou centenas de tabelas.
Conforme Korth (2006, p. 27): “Cada coluna de uma tabela obedece às
regras definidas na sua criação. Cada coluna recebe um tipo de dado, que representa
o conjunto de valores que podem ser armazenados em cada uma das colunas.”
Basicamente, cada coluna representa o tipo de cada dado, ou seja, as regras de
entrada dos dados, evitando a incompatibilidade.
Para Machado (2008, p. 30):
As linhas representam todos os dados cadastrados, ou seja, um conjunto
de colunas ou campos. As linhas representam o numero de registros
cadastrados na tabela e as colunas representam os tipos de dados ou
campos cadastrados. Alguns campos da tabela alem do tipo de dados,
possuem uma propriedade adicional. Esses campos recebem o nome de
chave.
São dois modelos de chaves: a primeira é chamada de chave primária, ela
identifica cada registro, dando-lhe unicidade. Nunca se repetindo a chave primária
dentro da estrutura da tabela, já a segunda é denominada de chave estrangeira, onde é
formada pela chave primária de outra tabela e da chave de um campo da tabela
externa que recebe o relacionamento. Podendo esta chave se repetir várias vezes.
25
Devemos fazer uma busca em tabelas diferentes, para podermos recuperar
informações necessárias estabelecendo sempre um relacionamento entre elas. Esta é
a origem do nome deste paradigma de banco de dados.
De acordo com Couceiro (1984, p. 77):
Muitos bancos de dados Relacionais tem linguagem de alto nível e dá
suporte a uma forma limitada de visões do usuário. Usualmente, os
esquemas conceituais e internos não são distinguíveis e a Linguagem de
Definição de dados (DDL) é utilizada para descrever todos os aspectos de
estrutura do banco de dados. Por exemplo, determinar quais os
correntistas de cada conta-bancária, significa determinar um subconjunto
da união dos conjuntos cliente e conta, onde todos os elementos possuam
uma determinada propriedade.
Enfim, toda a informação de um banco de dados relacional é armazenada
em tabelas, que na linguagem do modelo relacional, podendo também ser
denominada de entidades. Por exemplo, posso ter uma tabela "clientes", onde seriam
armazenadas informações sobre os diversos clientes.
Conforme Freitas (2000, p.25):
Quando o banco de dados precisa montar uma expressão algébrica para
encontrar um resultado, ele deve escolher uma entre várias expressões.
Apesar de apresentarem o mesmo resultado, as expressões são diferentes,
e a diferença fará com que o banco de dados adote um diferente caminho
para resolver cada uma.
Podemos dizer que um grande número de produtos de banco de dados
relacionais está disponível no mercado. Eles incluem entre outros, IBM DB2, Oracle,
Sybase, Informix, Progress e etc.
FIGURA 03 - MODELO RELACIONAL (MORAIS, 2009)
26
A figura 03 mostra as informações sobre as tabelas cliente e conta. Na
tabela cliente, será armazenado seu código, nome, rua e cidade, enquanto na tabela
conta, teremos a informação do numero da conta e do saldo. Podemos perceber que
no final da figura a uma ligação entre o cliente e a conta, obtendo assim informações
de cada tabela.
3.1.2 Modelo de banco de dados de rede
De acordo com Javarotti Filho (2008):
O banco de dados em rede é composto de uma estrutura mais completa,
possui as propriedades básicas de registros, conjuntos e ocorrências, e
utiliza a linguagem de definição de banco de dados (DDL) e a linguagem
de manipulação de dados (DML), alem de permitir uma evolução mais
eficiente do modelo.
A estrutura é formada de entidade (registros), atributos (itens de dados), tipo
de registro e ocorrência do registro.
Segundo Heuser (2009, p. 40) conceitua que:
O modelo rede utiliza como elemento básico de dados a ocorrência de
registro. Um conjunto de ocorrências de registros de um mesmo tipo
determina um tipo de registro. Um conjunto de tipos de registro
relacionados entre si, através de ligações (associação entre dois registros)
especiais, forma uma estrutura de dados em rede que por sua vez podem
ser implementadas sob a forma de ponteiros, listas de ponteiros, etc.
Para Freitas (2000, p.26), “Uma rede é essencialmente um conjunto de
ilimitado de nós (tipos de registros neste caso) e de ramais de ligação, ou bordas. Na
verdade, uma hierarquia é apenas um tipo particular de rede”. Podendo então uma
rede não apresentar o conceito de nó ‘raiz’ e os registros podem ter diversos tipos de
registros-pais, assim como diversos tipos de registros-filhos.
Elencando Freitas (2000, p.26), “As referências ou ligações estão
normalmente inseridas junto com as ocorrências de registro, assim, todo acesso a um
próximo registro utiliza o ponteiro inserido no registro corrente disponível”.
Podemos mencionar neste modelo, o seu elemento distintivo, o registro
base, a partir de então são dispostos os demais registros.
Conforme Javarotti Filho (2008):
A estrutura e formada de entidade (registros), atributos (itens de dados),
tipos de registros e ocorrência do registro. Tanto no modelo hierárquico
quanto o de rede são chamados de sistemas de navegação, pois as
27
aplicações devem ser construídas para atravessar um conjunto de registros
interligados previamente.
A maior vantagem do modelo de rede frente ao hierárquico é um melhor
controle sobre a redundância de dados.
Conforme Couceiro (1984, p. 81): “O modelo de rede difere do modelo
relacional, ao representar os dados através de coleções de registros e os
relacionamentos entre os dados através de ligações”. No modelo relacional, os dados
e os relacionamentos entre os dados são representados por uma coleção de tabelas.
Para Medeiros (2006, p. 38):
Podendo ser descritas como de ordem de entrada e de existência as
restrições impostas pelo Modelo de Redes. Já as de entradas tem a
obrigatoriedade de cada novo registro estar conectado (ou apontado) ao
conjunto indicado. Em relação a restrições de existência pode-se dizer que
um componente de um tipo de registro pode existir de forma
independente de outros desde que esteja conectado a algum outro registro
fazendo parte de algum conjunto, ou sendo base de um novo conjunto.
O modelo de banco de dados de rede tem uma estrutura mais completa,
possui as propriedades básicas de registros, conjuntos e ocorrências, e emprega a
linguagem de definição de banco de dados (DDL) e a linguagem de manipulação de
dados (DML), além de aceitar evolução mais eficiente do modelo.
Conforme Medeiros (2006 p. 38-39):
Uma modalidade especial deste modelo foi apresentada pelo data base
Task Group (DBTG) da Conference on Data Systems and Languages
(Codasyl). Uma crítica feita a este modelo é a inclusão de detalhes que
tem mais a ver com implementação física do que com estrutura lógica.
3.1.3 Modelo de dados Hierárquico
Para Freitas (2000, p.27):
O modelo hierárquico é similar ao modelo de rede, pois os dados e
relacionamentos são representados por registros e ligações,
respectivamente. Cada registro neste modelo é uma coleção de campos,
cada um contendo somente uma informação. Uma ligação é uma
associação entre precisamente dois registros.
Os seus registros são organizados em níveis e subníveis, sendo que cada
nível é o detalhamento das informações do nível imediatamente superior.
Segundo Takai et al. (2005, p. 6):
28
Um diagrama de estrutura de árvore é um esquema para o banco de dados
hierárquico. Um diagrama consiste de dois componentes básicos: caixa,
que corresponde o tipo registro e linha, que corresponde à ligação. Um
diagrama de estrutura de árvore é similar a um diagrama de estrutura de
dados no modelo de rede.
Conforme Heuser (2009, p. 48): “Quando se fala em hierarquia de dados, o
acesso aos dados é feito através do segmento “raiz” em que um campo é escolhido
como campo-chave e os outros são baseados em índices ou acesso aleatório”.
A diferença entre modelo hierárquico do modelo de redes está no sentido
em que os registros são organizados como coleções de árvores composta de
conjuntos de registros interligados descrevendo uma hierarquia.
Para Mecenas e Oliveira (2005, p. 40):
Todos os bancos de dados apresentam vantagens e desvantagens em sua
utilização, e com o banco de dados modelo hierárquico não e diferente.
Ele é um modelo bastante simplificado representa naturalmente sistemas
que possuem uma hierarquia bem definida, não representando sistemas
que não possuem tais características, alem de aumentar os índices de
redundância ou duplicidade, possuir tempos de consulta e processamento
reconhecidamente altos.
São considerados os modelos mais utilizados na área comercial, os três
modelos mencionados anteriormente.
3.2 MODELOS LÓGICOS BASEADOS EM OBJETOS
Os modelos lógicos baseados em objetos são apresentados no nível
conceitual e no nível de visões do usuário.
Para Freitas (2000, p. 28):
São modelos que procuram representar as informações através dos
paradigmas da orientação a objetos, utilizando o conceito de Classes que
irão conter os objetos. Eles se caracterizam pelo fato de fornecerem
capacidades de estruturação flexíveis e admitirem restrições de dados.
Esses modelos são conhecidos por apresentarem uma capacidade de
estruturação flexível, conforme elencado por Freitas.
De acordo com Mecenas e Oliveira (2005, p. 42) ensinam que:
Modelos lógicos baseados em objetos são usados na descrição de dados
nos nível conceitual e visão. Caracterizam-se por proporcionar ampla e
flexível capacidade de estruturação e por permitir a especificação de
restrições de dados de forma explícita.
29
A seguir serão demonstrados dois exemplos de modelos utilizados pelo
modelo lógico baseados em objeto, modelo de entidade-relacionamento e orientado a
objeto, embora existam vários modelos pertencentes a este grupo.
3.2.1 Modelo entidade-relacionamento
Para Greff (2010, p. 06):
Esse modelo baseia-se numa percepção de mundo real que consiste em
uma coleção de objetos básicos chamados entidades, e de
relacionamentos entre esses objetos. Uma entidade é um objeto que existe
e é distinguível de outros objetos.
Para fazer a distinção dos objetos, tem que associar cada entidade em um
conjunto de atributos que os descrevam. Por exemplo, os atributos número e saldo
descrevem uma conta particular bancária.
Segundo Mecenas e Oliveira (2005, p.42), “Um relacionamento é um
associação entre diversas entidades. Por exemplo, um relacionamento cliente-conta
associa um cliente com cada conta que possua”. O conjunto de todas as entidades e
relacionamentos do mesmo tipo é chamado de conjunto de entidades e conjunto de
relacionamentos, respectivamente.
Podemos expressar graficamente a estrutura conceitual global de um banco
de dados através de um diagrama E-R que incide nos seguintes elementos:
•
Retângulos, que representam conjuntos de entidades;
•
Círculos, que representam os atributos;
•
Losangos, que representam relacionamentos entre conjuntos de
entidades;
•
Linhas, que ligam atributos a conjuntos de entidades e conjuntos de
entidades a relacionamentos.
Vamos considerar um modelo de entidade–relacionamento ER, como no
exemplo da figura 04, onde mostra as entidades Cd’s e Faixas. Na figura 04 mostra a
descrição abstrata dos dados armazenados, permitindo construir a sua estrutura lógica
global.
30
FIGURA 04 - Entidade relacionamento (MORAIS, 2009)
3.2.2 Modelo Orientado a Objeto
Este modelo é um sistema onde a sua unidade de armazenamento é vista
pela forma de um objeto, ou seja, ela tem propriedades e não campos.
De certa forma podemos sugerir que orientação a objetos corresponde à
organização de sistemas como uma coleção de objetos que integram estruturas de
dados e comportamento. Diferenciando a abordagem das demais por incluir certos
números de conceitos, princípios e mecanismos.
De acordo com Freitas (2000, p. 29):
Semelhante ao modelo E-R, o modelo orientado a objeto é baseado no
conceito de objeto (dados encapsulados em forma de códigos e métodos)
que operam trocando mensagens entre si, e esses objetos são estruturados
em classes, e as classes estão baseadas em uma hierarquia de subclasse e
superclasse, herdando propriedades e métodos das classes superiores.
No modelo orientado a objeto cada informação sua são armazenadas na
forma de objetos. O trato com a informação no modelo orientado a objetos é mais
coerente. As regras de negócio são mais claras, mais simples de executar e manter
porque tratam com objetos reais, e não com listas abstratas. No modelo orientado a
objeto, o banco é quem acompanha a evolução do modelo e da aplicação, e não o
contrário.
Segundo o pesquisador Heuser (2009, p. 47):
“Os modelos de dados orientados a objetos tem um papel importante nos
SGBD porque, em primeiro lugar, são mais adequados para o tratamento
de objetos complexos (textos, gráficos, imagens) e dinâmicos (programas,
31
simulações). Depois, por possuírem maior naturalidade conceitual e,
finalmente, por estarem em consonância com fortes tendências em
linguagens de programação e engenharia de software. O casamento entre
as linguagens de programação e banco de dados é um dos problemas que
estão sendo tratados de forma mais adequada no contexto de orientação a
objetos”.
Em modelos de dados orientados a objetos um objeto é criado como uma
instância de uma classe, apresentando as propriedades e comportamento desta classe.
Apresentando um identificador único que o distingue dos demais objetos.
Elenca Mecenas e Oliveira (2005, p.43):
Uma vez criado, o objeto pertence a esta classe durante todo o seu tempo
de vida, mesmo se, com o passar do tempo, suas características
comportamentais evoluam de modo a ser identificado com as
características de outra classe.
Um banco de dados orientado a objetos se caracteriza por:
De acordo com Freitas (2000, p. 29):
Ser formado por um conjunto de tipos abstratos de dados, com operações
definidas sobre estes tipos, as quais caracterizam as propriedades ou o
comportamento dos tipos, sendo os objetos instâncias destes tipos; Serem
os objetos acessados e manipulados somente através das operações
definidas para os tipos, ficando a estruturação dos dados e os detalhes da
implementação, totalmente escondidos. Os objetos são definidos,
portanto, somente através de suas propriedades (seus comportamentos).
Nota-se que este modelo apresenta a semântica da aplicação em seu
esquema conceitual e permitindo então modelar entidades do mundo real na forma de
objetos armazenados, se tornando então um dos maiores alvos de interesse em
aplicações complexas de sistemas de informações, tudo por causa da sua facilidade.
Observa-se a necessidade constante de aumento de produtividade, fazendo
com que as equipes de desenvolvedores, procurem criar padrões de programas,
bibliotecas de classes e softwares que gerem aplicações semi-prontas que auxiliem
neste objetivo.
Os desenvolvedores enfrentam uma dificuldade, porque este modelo não
programa sem levar em conta o banco de dados em que os objetos serão
armazenados. Deve existir uma preocupação com o mapeamento entre os diferentes
modelos.
Para Freitas (2000, p. 30): “O desenvolvimento do sistema gerenciador de
banco de dados orientado a objetos (SGBDOO) teve origem na combinação de idéias
32
dos modelos de dados tradicionais e de linguagens de programação orientada a
objetos”.
Conforme Korth (2006, p. 29):
O sistema gerenciador de banco de dados orientado a objeto simplifica
muito a integração com as linguagens de programação deste paradigma
orientada a objetos, porque ele apóia o modelo de dados diretamente.
Existem duas propriedades importantes para a construção de um SGBDOO:
Para Toledo (1994, p. 18): “Extensibilidade (grifo nosso) garante que o
conjunto de tipos oferecidos pelo sistema permite a definição de novos tipos e não há
distinção entre os tipos pré-definidos e os definidos pelo usuário”.
De acordo com Toledo (1994, p. 18): “Completude computacional (grifo
nosso) implica que a linguagem de manipulação de um banco de dados Orientado a
Objetos pode exprimir qualquer função computacional”.
Neste modelo a noção de objeto é empregada no nível lógico possuindo
características não encontradas nas linguagens de programação tradicionais, como no
caso de operadores de manipulação de estruturas, gerenciamento de armazenamento,
tratamento de integridade e persistência dos dados.
3.3 MODELO DE BANCO DE DADOS DISTRIBUÍDO
Conforme Korth (2006, p. 28):
Um banco de dados distribuído é um conjunto de banco de dados
armazenados em diferentes nodos de uma rede de computadores, sendo
esse banco de dados correlacionados logicamente, seja por relações
funcionais, seja porque são no todo ou em parte, cópias múltiplas das
mesmas informações, de modo a constituir em qualquer caso uma única
coleção de dados.
Este modelo permite compartilhar e acessar dados de um modo eficiente e
seguro, fazendo com que este se torne um dos benefícios deste modelo. A forma
utilizada para localização dos seus dados é influenciado pela estrutura de controle
adotada na rede.
Afirma Freitas (2000, p. 30):
Na estrutura hierárquica, os computadores executam tarefas que
interagem de modo mais ou menos estruturado e controlado pelos
membros de mais alto nível na hierarquia. Na estrutura simétrica, todos os
computadores cooperam a um mesmo nível lógico, embora relações
proprietário-usuário possam ser criadas dinamicamente na execução de
algumas tarefas e a tendência é colocar junto a cada nodo os dados mais
33
utilizados. Para dados utilizados com freqüência por dois ou mais nodos,
pode-se criar cópias residentes em cada um desses nodos.
Esse modelo consiste em dois ou mais arquivos de dados logicamente interrelacionados localizados em sites distintos numa rede de computadores.
De acordo com Mecenas e Oliveira (2005, p. 47):
É um problema difícil manter a consistência entre as cópias quando
ocorre uma atualização em um nodo contendo uma das cópias. A
atualização deve atuar corretamente, independentemente da velocidade de
transmissão dos dados, o nodo que vai empreender a atualização deve
notificar a todos os demais que contenham cópias sua intenção de
atualizar o nodo, e se houver algum conflito, este deve ser resolvido nesse
momento.
Uma das grandes desvantagens deste modelo está no seu acréscimo de
complexidade exigida para assegurar coordenação própria entre os locais. Este
aumento de complexidade tem como conseqüência:
•
Custo de desenvolvimento de software mais elevado;
•
Maior potencial para erro, uma vez que os locais que compõem
o sistema distribuído operam em paralelo.
3.4
MODELO
CORPORATIVO
DE
BANCOS
DE
DADOS
Para Freitas (2000, p. 31), “Conceitua-se este modelo como o
armazenamento de todos os arquivos e informações de uma empresa agrupados de
uma forma que seja possível consultá-los com uma maior exatidão e rapidez de
qualquer parte da empresa”.
Para Korth (2006, p. 29):
Esse banco de dados não é uma mudança nas características fundamentais
de um banco de dados, mas sim, a disponibilidade de novas tecnologias
para o seu acesso e armazenamento, ele vai além das fronteiras de um
banco de dados, aonde é aperfeiçoado o acesso aos dados através de uma
melhoria nas tecnologias de processamento com componentes mais
rápidos, terminais remotos, além da aceitação cada vez maior de aceitação
compartilhada, ou seja, os dados podem ser gerenciados como um
recurso.
Esses dados podem ser considerados recursos por possuírem a mesma
informação, sendo esta de grande importância e pode ser requisitada ou necessária
34
para várias partes da empresa, com isso se torna importante gerenciá-los, sendo o
único recurso que mantém a pista dos demais.
Sendo este modelo gerenciado por um departamento, onde as suas
atribuições, em geral, tem a responsabilidade pelo banco de dados, onde essa abrange
o seu projeto, desempenho, segurança e publicidade.
4 COMPUTAÇÃO EM NUVENS
A computação em nuvem é uma tecnologia nova da área de TI, muitos a
usam sem perceber, como é o caso daqueles que utilizam uma conta de e-mail da
Google, por exemplo. Esta tecnologia consiste na interligação de vários servidores
que fornecem aplicativos e espaço de armazenamento de dados. Portanto, neste
capítulo será abordado o conceito da computação em nuvens, seus benefícios, a sua
segurança e privacidade, os serviços oferecidos, aplicação, tipos de nuvens e, por
último, a arquitetura em nuvens.
4.1 CONCEITO
A Computação em nuvem tem objetivo de proporcionar serviços de
tecnologia da informação (TI) sob demanda com pagamento baseado no uso.
Computação em nuvem pretende ser global e prover serviços para as massas que vão
desde o usuário final que hospeda seus documentos pessoais na Internet até empresas
que terceirizam toda infraestrutura de TI para outras empresas.
De acordo com Holanda et al. ( 2009): “Nuvem computacional é um modelo
de computação em que dados, arquivos e aplicações residem em servidores físicos ou
virtuais, acessíveis por meio de uma rede em qualquer dispositivo compatível”.
Segundo Taurion (2009, p. 91):
Em um mundo onde a evolução tecnológica é constante, e a necessidade
de comunicação é grande, mas não só entre pessoas, empresas e
colaboradores, estreita a relação entre o tempo e a velocidade de
comunicação e de conexão.
A computação em nuvem possui inúmeras vantagens, uma delas é a
possibilidade de ampliar os recursos utilizados sempre que necessário.
35
Para Foster (2008, p. 20):
Cloud computing é um paradigma de computação em larga escala que
possui foco em proporcionar economia de escala, em que um conjunto
abstrato, virtualizado, dinamicamente escalável de poder de
processamento, armazenamento, plataformas e serviços são
disponibilizados sob demanda para clientes externos através da Internet.
Na computação em nuvens os nossos arquivos, aplicações e outros, ficam
gravados nos servidores da internet, assim podemos acessá-los de qualquer lugar
através de um dispositivo com acesso à internet.
Conforme Vaquero et al. (2009):
O termo computação em nuvem (do inglês cloud computing) está
associado a um novo paradigma na área de computação. Basicamente,
esse novo paradigma tende a deslocar a localização de toda a
infraestrutura computacional para a rede. Com isso, os custos de software
e principalmente de hardware podem ser consideravelmente reduzidos.
Este novo modelo de computação move todos os dados e as aplicações dos
usuários para grandes centros de armazenamento. Com isso, as aplicações e os
sistemas de hardware são distribuídos na forma de serviços baseados na Internet.
De acordo com Maximiano (2009):
A empresa Katri foi a primeira a desenvolver a tecnologia no Brasil
(2002), batizando-a de IUGU. Aplicada inicialmente no site de busca de
pessoas físicas e jurídicas (fonelista), durante o período que o mesmo
esteve no ar, de 2002 a 2008, seus usuários puderam comprovar a grande
diferença na velocidade em pesquisas proporcionadas pelo processamento
paralelo. Atualizando para 2009, a tecnologia tem evoluído muito e
sistemas funcionais desenvolvidos no início da década, já passam de sua
3ª geração, incorporando funcionalidades e utilizando de tecnologias
como Índices Invertidos (Inverted Index).
A infraestrutura do ambiente de computação em nuvem normalmente é
composta por um grande número, centenas ou milhares de máquinas físicas ou nós
físicos de baixo custo, conectadas por meio de uma rede.
De acordo com Lopes (2008):
A computação em nuvem é um termo usado para descrever um ambiente
de computação baseado em uma rede massiva de servidores,
armazenamento e processos, sejam virtuais ou físicos. Computação nas
nuvens, ou Cloud computing, hospeda as cloud applications, que são as
aplicações que estão residentes nesta nuvem (cloud). Pode ser visto,
ainda, como o estágio mais evoluído do conceito de virtualização.
Podemos notar que, a computação em nuvens tem diversos desafios a serem
solucionados, apesar de ser recente, como a segurança e a interoperabilidade, e a
36
grande quantidade de pesquisas na área admitirá que ela seja amplamente debatida
debatid
por muito tempo.
FIGURA 05 - Modelo de Computação em Nuvem (CAVALCANTI
CAVALCANTI, 2010)
Em relação à figura 05, podemos dizer que o principal objetivo da
computação em nuvem é fornecer serviços de fácil acesso, de menor custo e com
garantias de disponibilidade e escalabilidade para seus clientes.
clientes. Pretendendo assim
facilitar a vida dos usuários, fazendo que seus arquivos fiquem disponíveis em
qualquer plataforma que ele venha a usar.
Cavalcanti demonstra na figura 05 a sua infraestrutura,
infraestrutura sendo estas
compostas por varias máquinas físicas,
físicas ou seja, por vários
rios nós físicos de menor
custo, que são ligados através de uma rede computacional, interligando assim vários
servidores que fornecem aplicativos e espaço de armazenamento de dados para os
seus usuários, desde que esses usuários tenham em suas máquinas
máquinas um sistema
operacional,
ional, um navegador e acesso a internet.
i
Como cita Taurion (2009, p. 10) em sua obra:
A nuvem é um espaço de processamento e armazenamento de dados que
não depende da existência de qualquer máquina específica para existir.
São onde seus usuários armazenam arquivos, ou seja, já não são dados
únicos, pois estão dentro da nuvem, e podem ter a opção
o
de ser
compartilhados. Uma vez que está dentro da nuvem e com acesso a
internet garantida, não há a necessidade de ter o determinado arquivo em
seu computador, porque pode ser acessado de qualquer lugar, basta uma
conexão com a internet.
37
O e-mail é um dos serviços utilizados na computação em nuvens, basta
apenas acessar o provedor para poder visualizar as mensagens. O Youtube, Picasa e
Flickr, são outros tipos de serviços considerados mais populares.
FIGURA 06 - Camada conceitual de uma nuvem (VOAS; ZHANG, 2009)
Na figura 06 mostra um usuário acessando do seu computador informações
armazenadas na camada de uma nuvem. O conceito desta camada é o simples acesso
da internet, que leva o usuário buscar informações que estão armazenadas nos
servidores das empresas que disponibilizam este serviço, podendo os usuários
acessarem a qualquer tempo, a qualquer hora e de qualquer computador que tenha
acesso á internet a informação desejada, por isso o seu computador estará nas
nuvens.
Conforme Lopes (2008):
Na prática a arquitetura cloud é como se uma empresa (ou um conjunto de
empresas) disponibilizasse uma infraestrutura de computadores
interligados, verdadeiros parques computacionais, nem sempre no mesmo
local físico, cujas informações são replicadas, inter-relacionadas e
compartilhadas entre os servidores, de forma que nenhum deles fique
sobrecarregado.
Os Datacenters encontram-se na base da nuvem, sendo salas imensas
lotadas de computadores interligados, podendo funcionar como um só, tendo o seu
foco sempre para a mesma finalidade, ou divididos em grupos, cada um com um
objetivo.
Segundo Kaufman (2009, p.42):
Esse novo modelo de computação, o data center armazena informações
que os usuários tradicionalmente armazenariam em seus próprios
computadores. Além disso, esses usuários desconhecem tanto a
38
localização exata de seus dados quanto à fonte dos dados que estão
armazenados junto aos deles.
De acordo com Terry (2010):
A computação em nuvem promete mudar radicalmente a forma como as
aplicações e serviços de informática são fabricados, entregues e
gerenciados. Grandes datacenters permite a partilha de recursos através
de aplicações hospedadas e levam a economias de escala, tanto a nível de
hardware e software. Os serviços de software podem obter escalabilidade
aparentemente infinita e o crescimento incremental para atender às
demandas dos clientes. O pay-as-you-go é um modelo de
provisionamento rápido e pode resultar em uma utilização mais eficiente
dos recursos e redução de custos.
FIGURA 07 - Datacenter (SEA SERVER, 2011)
A figura 07 mostra a estrutura, que resguarda todos os sistemas de
informações de uma empresa, sendo estas informações armazenadas em servidores.
O seu objetivo é eliminar os pontos de falhas e aumentar a redundância e
confiabilidade das informações da empresa.
Conforme afirma Rydlewski (2009):
A composição da computação nas nuvens é formada por data centers, que
é o nome dado a unidade de processamento física formada pelo
aglomerado de grandes máquinas com alta capacidade de armazenamento
e processamento, semelhantes aos servidores que antes ficavam numa sala
separada, climatizada, com investimentos e atenção especial da empresa.
No data center, as máquinas são dispostas em rede e se unem para atuar
como um gigantesco processador e armazenador de dados. Os data
centers já existiam, em salas frias e incumbidos de determinadas funções,
eles eram mantidos e estruturados pelas grandes corporações como a
Microsoft, Google, Amazon, etc, e localizados em lugares estratégicos. A
fibra ótica e a evolução da internet tornaram irrelevante a localização
destes parques tecnológicos, assim como a obrigação das companhias de
mantê-los e custeá-los. Agora, com a virtualização é possível propor o uso
racional dessas máquinas e de seus recursos com total elasticidade de
demandas.
39
A virtualização é o componente responsável pela qualidade dinâmica dos
data centers. Ou seja, ela admite que os ambientes virtuais de cada usuário sejam
ampliados ou reduzidos dinamicamente, de maneira a atender aos recursos
solicitados.
De acordo com Holanda et al. (2009):
Na computação nas nuvens, os data centers provêem uma rede de
serviços que são utilizados à medida que são requeridos. A virtualização é
o componente responsável pela característica dinâmica dos data centers.
A escalabilidade está diretamente relacionada com essa característica: os
recursos são facilmente escaláveis graças a esse dinamismo.
Vamos destacar três fundamentais aspectos que são novos na computação
em nuvem, em relação aos modelos anteriores.
Conforme Armbrust et al. (2009):
•
A ilusão da disponibilidade de recursos infinitos ilimitados, o
conceito da nuvem sugere que o usuário tem em suas mãos toda a Internet
e os seus serviços;
•
A eliminação de um comprometimento com antecedência por parte
dos usuários, em uma empresa pode começar usando poucos recursos de
hardware, e, à medida que for crescendo, ou seja, à medida que for
necessário, pode ir aumentando a quantidade de recursos usados, sem que
haja um comprometimento anterior em relação a essa quantidade; a
escalabilidade é uma das características responsáveis por esse aspecto;
•
A habilidade de pagar pelo uso dos recursos à medida que eles são
utilizados, o modelo pay-per-use pode usar, por exemplo, uma métrica de
processadores por hora, ou de armazenamento por dia, para cobrar pelos
serviços; isso permite que os recursos sejam liberados caso não sejam
utilizados, evitando um consumo desnecessário.
4.2 BENEFÍCIOS DA COMPUTAÇÃO EM NUVENS
Cada vez mais a computação em nuvem vai evoluindo, trazendo assim
vários benefícios, como no caso dos chips que virão nos objetos, contendo neles
várias informações, sempre detectados pela nuvem, assim os objetos poderão
comunicar-se.
Como por exemplo, a geladeira da Samsung, que possui um chip emitindo
alertas sobre o fim do prazo de validade ou falta de produtos, sendo possível
relacionar os produtos consumidos e também agendar sua reposição, como num
estoque de uma empresa.
De acordo com Meneses e Cruz (2009):
Os benefícios para a vida casual são imensos, mas não são apenas eles
que alavancam o crescimento dessa tecnologia, pois os principais
beneficiados são as empresas que ganham velocidade no acesso e
compartilhamento de dados, e economizam milhões com a possibilidade
40
de hospedar seus arquivos na nuvem, assim não precisam gastar dinheiro
montando sua própria estrutura tecnológica, que fica defasada com o
passar do tempo, então usarão estruturas da Google e IBM.
Os benefícios da computação em nuvens são inúmeros, tanto do ponto de
vista de hardware como de software.
Elenca Meneses e Cruz (2009):
A Computação em Nuvem pode ser considerada como o próximo passo
na evolução da Internet, seu modelo
odelo de fornecimento de serviços traz
benefícios incontestáveis para qualquer modelo de empresa, benefícios
como uma economia grande quanto à questão de investimentos em
hardware e software,, e pode também proporcionar a pequenas empresas
que utilizem amplas
as capacidades informáticas, através da utilização de
serviços, que no caso de outra maneira não estaria ao alcance de muitas
empresas.
Trata-se
se de uma tecnologia que proporciona uma maneira conveniente de
acessar os serviços de computação. Ela alivia a necessidade
ecessidade de guardar informações
informaç
no seu computador, celular, etc. Fazendo que as informações possam ser rapidamente
e facilmente acessadas através da rede.
Conforme Holanda et al. (2009):
As vantagens para os usuários: Na maioria das vezes, o usuário não
precisará mais se “adaptar ao meio”. O software deve ser instalado,
configurado e posteriormente atualizado a cada novo lançamento. Os
dados podem ser acessados de qualquer computador
computado que tenha acesso à
Internet. Não é mais necessário o pagamento por uma licença definitiva
de um determinado programa, já que é viável a tarifação do uso específico
do Software. Para vendedores: Programas são desenvolvidos, testado se
executados na plataforma de escolha
colha do vendedor e não do cliente.
Atualizações e Correções de erro conseguem ser feitos em minutos,
acelerando o processo.
FIGURA 08 - Conexões em Nuvens. (MENESES e CRUZ, 2009)
A figura 08 mostra vários meios para conectar-se
conectar se na internet e adquirir
qualquer informação que esteja armazenada na nuvem, bastando apenas à conexão da
internet para essas informações serem compartilhadas.
41
4.3 SEGURANÇA E PRIVACIDADE
Podemos explanar que na maioria das vezes nas revoluções tecnológicas, o
surgimento da nuvem causa temores e apreensão, e esta ocorrência tem a ver com a
segurança e privacidade dos arquivos hospedados na nuvem. O fato é que
informações armazenadas on-line têm menos segurança do que na prática legal.
Conforme Miller e Veiga (2009, p. 12):
“A nuvem faz uso dos mesmos protocolos de segurança aplicados em
outros servidores. Antigamente os poucos dados disponíveis na nuvem
eram públicos, como sites, músicas, imagens e outros arquivo.”
Na computação em nuvem os dados continuam os mesmos, porém, perdeu
a sua liberdade de acesso, apenas os proprietários, e às vezes nem eles manipulam os
dados quando na rede, como o que ocorre com serviços do tipo Migração entre
Provedores.
De acordo com Terry (2010):
A computação em nuvens requer novas técnicas de gerenciamento de
dados compartilhado na nuvem, computação esta tolerante a falhas, a
composição de serviços, programação, medição e faturamento,
protegendo a privacidade, comunicação e, mais geralmente, a partilha de
recursos entre aplicações sob o controle de diversas organizações. A
comunidade científica está acelerando para enfrentar esses desafios, assim
como uma série de empresas de alta tecnologia. Esta coleção de
documentos destaca alguns esforços iniciais no que é certo ser uma área
produtiva de inovação para os próximos anos.
É aconselhado que antes de contratar um serviço pago de computação em
nuvem, que se pesquise a idoneidade da empresa fornecedora, e ter cuidado com as
garantias explicitas no contrato. A maior parte dos problemas de segurança que
surgem com essa nova forma de usar a internet tem origem no descumprimento do
contrato, ou na inexistência da clausula que garantiria a segurança.
De tal modo, a proteção da privacidade dos usuários e a integridade das
informações devem ser consideradas pelos prestadores de infra-estrutura e de
serviços. De maneira a criar um ambiente seguro mínimo, garantindo assim, a
confidencialidade e a integridade dos dados.
As seguintes capacidades devem ser oferecidas em uma nuvem.
•
Um esquema de criptografia, de forma a assegurar que o ambiente de
armazenamento proteja os dados;
42
•
Um controle de acesso rigoroso, de forma a prevenir o acesso não
autorizado aos dados;
•
Um sistema de gravação de cópias de segurança e um armazenamento
seguro dessas cópias.
Conforme elenca Taurion (2009, p. 79), “Essas três capacidades, contudo,
podem não ser suficientes para proteger os dados nas nuvens”. Em relação à
criptografia, surge à questão de quem fica responsável pelo gerenciamento das
chaves, por exemplo. Com isso, é necessário que novos mecanismos de proteção de
dados sejam investigados, para que a privacidade e a segurança dos usuários sejam
garantidas.
4.4 SERVIÇOS OFERECIDOS
Os serviços oferecidos são de grande variedade e inúmeros deles de forma
disfarçada, tais como o webmail, os que terceirizam a utilização de correio
eletrônico, discos virtuais, e até mesmo sites que executam tarefas predeterminadas,
gastando poder de armazenamento, processamento e consumo apenas no servidor.
A grande procura dos serviços em nuvem em empresas tornou admissível o
surgimento de mais um novo ramo da computação em nuvem, exclusivamente os
serviços de migração (Business to Business). Uma empresa que está fazendo uma
atualização em seu sistema de nuvem, ou mudando de provedor, pode contratar esse
serviço que será feito por uma empresa, que dispõe de armazenamento e segurança
para realizar essa transação, e que fará em menor tempo, pois tem conexões
dedicadas ou até mesmo diretas entre as nuvens.
Conforme Taurion (2009, p. 98):
O google, empresa que iniciou suas atividades como um catalogo de site,
sendo bem modesto na descrição, já disponibiliza um serviço que mais
demonstra o funcionamento da computação em nuvem. Destinada a
programadores e a “hard users” o google app engine, descrito na figura
9, permite criar um programa ou um site usando as tecnologias do google
code, que por enquanto aceita programação em python e java. Esse
serviço oferece gratuitamente até cinco milhões de acessos por dia,
qualquer quantidade acima disso será necessário adquirir o serviço
avançado.
43
4.5 APLICAÇÕES
Há muitas aplicações que empregam as idéias de computação em nuvem
para seu funcionamento. Abaixo, estão relacionadas as mais conhecidas e utilizadas
pela rede.
De acordo com Foster (2008, p. 32):
Google Apps (grifo nosso) é um pacote de serviços onde o google
oferece aplicativos de edição de texto, planilhas e apresentações (google
docs) serviço de agenda (google agenda), comunicador instantâneo
integrado (google talk), e-mail e outros. Todos os serviços são
gerenciados e processados pelos servidores da google e o cliente só
precisa criar as contas de usuário. O google apps oferece pacotes gratuitos
e pagos, de acordo com a quantidade de usuários.
Em resumo, a google esta aperfeiçoando constantemente as suas
ferramentas, para oferecer a melhor tecnologia aos seus usuários.
Para Amazon web service (2011):
Amazon (grifo nosso) é um dos maiores serviços de e-commerce do
mundo. Para suportar o volume de vendas no período do Natal, a empresa
montou uma superestrutura de processamento e armazenamento de dados,
que acabava ficando na maior parte do ano ociosa. Daí surgiu à idéia de
“alugar” esses recursos e surgiram os serviços como o simple storage
solution (S3), para armazenamento de dados, e o elastic compute cloud
(EC2), um serviço que permite aos usuários alugar computadores virtuais
para executar suas aplicações.
A amazon possui um conjunto de web services muito completo, "amazon
web services"(AWS), que permite checar todas as informações relativos a livros, CDs
e DVDs, bem como jogos e tudo mais que é vendido nos sites.
Segundo Dikaiakos et al. (2009, p. 61):
Live Mesh (grifo nosso) é um serviço da Microsoft [...]. Sua proposta
principal é a de permitir que o usuário acesse o seu desktop de qualquer
computador, com a diferença de que todos os seus arquivos ficam na
nuvem, isto é, nos servidores da Microsoft.
O levi mesh permite que arquivos e pastas sejam compartilhados e
sincronizados em vários dispositivos. Consiste esse em um componente, ele é o
sistema de sincronização da Microsoft.
De acordo com Foster (2008, p. 32):
Aprex (grifo nosso) é brasileiro, e oferece um conjunto de ferramentas
para uso profissional, como calendário, gerenciador de contatos, lista de
tarefas, disco virtual, blog, serviço de e-mail marketing, apresentações,
44
entre outros. Tudo é feito pela Web e, no caso de empresas, é possível até
mesmo inserir o logotipo e alterar o padrão de cores das páginas. Há
opções de contas gratuitas e pagas.
O aprex fornece um conjunto de ferramentas e serviços online destinados a
profissionais. Podendo proporcionar a opção de contas gratuitas e pagas. Os serviços
são fornecidos pelo aprex mediante acesso à world wide web, através de dispositivos
próprios do Usuário.
Segundo Dikaiakos et al. (2009, p. 61):
UniCloud (grifo nosso) é a extensão do unicluster, produto líder em
administração de sistemas HPC da empresa Univa UD (empresa privada
que vende software de gerenciamento de cloud computing, data centers e
computação de alto desempenho). Por meio do unicloud, as organizações
podem dispor e escalar recursos dentro de ambientes físicos ou
virtualizados como a amazon EC2, expandindo o recurso computacional
para suprir as necessidades em períodos de pico. O unicloud também é
flexível e opera sob demanda para satisfazer as necessidades de HPC da
empresa com um menor custo.
O unicloud admitiu que as organizações estabelecessem diretrizes de horas
de funcionamento e requisitos de modo dinâmico no setup das máquinas virtuais
dentro do ambiente do EC2. Sendo esse flexível, sob demanda para satisfazer a
necessidade de HPC, reduzindo os custos.
4.6 TIPOS DE NUVENS
As nuvens podem ser classificadas de 04 (quatro) formas básicas, sendo
elas: privada, comunitárias, híbrida e públicas. Elas devem ser escolhidas de acordo
com a necessidade do usuário. A seguir, iremos transcrever a utilidade de cada uma
dessas formas.
Segundo Chirigati (2009):
As nuvens privadas são aquelas construídas exclusivamente para um
único usuário (uma empresa, por exemplo). Diferentemente de um data
center privado virtual, a infra-estrutura utilizada pertence ao usuário, e,
portanto, ele possui total controle sobre como as aplicações são
implementadas na nuvem. Uma nuvem privada é, em geral, construída
sobre um data center privado.
Se o usuário quiser aumentar os recursos utilizados em sua nuvem privada,
terá que adquirir novos equipamentos. As nuvens privadas são aplicáveis para
45
aquelas áreas que exigem níveis específicos de qualidade de serviço e de localização
dos dados.
De acordo Tujal (2010, p.70):
As nuvens comunitárias são a infraestrutura de nuvem sendo esta
compartilhada por diversas organizações e suporta uma comunidade
determinada com preocupações em comum (por exemplo, considerações
sobre compatibilidade, requisitos de segurança, política e finalidade).
Porém, as nuvens comunitárias são compartilhadas por diversas empresas de
uma nuvem, sendo divididos seus interesses. Essas nuvens podem existir local ou
remotamente e, em geral, são administrados por alguma empresa da comunidade ou
por terceiros.
Conforme Souza et al. (2009):
A nuvem hibrida: No modelo de implantação híbrido, existe uma
composição de duas ou mais nuvens, que podem ser privadas,
comunidade ou pública e que permanecem como entidades únicas e
ligadas por uma tecnologia padronizada ou proprietária que permite a
portabilidade de dados e aplicações.
Desta forma, podemos dizer que as nuvens híbridas introduzem a
complexidade de determinar a maneira como as aplicações são distribuídas entre
nuvens públicas e privadas.
Para Taurion (2009, p. 107):
As nuvens públicas são aquelas que são executadas por terceiros. As
aplicações de diversos usuários ficam misturadas nos sistemas de
armazenamento, o que pode parecer ineficiente a princípio. Porém, se a
implementação de uma nuvem pública considera questões fundamentais,
como desempenho e segurança, a existência de outras aplicações sendo
executadas na mesma nuvem permanece transparente tanto para os
prestadores de serviços como para os usuários.
As nuvens públicas têm um grande benefício em relação à nuvem privada, o
poder de ser maior do que uma nuvem privada. Além disso, a possibilidade de
destinar uma determinada porções da nuvem pública para o uso exclusivo de um
único usuário, permitindo que este usuário tenha uma expansão de visibilidade de
toda a infraestrutura, instituindo assim o chamado data center privado virtual.
46
4.7 ARQUITETURA EM NUVENS
A arquitetura de nuvem é responsável pela identificação dos componentes
fundamentais para seus sistemas, indicando as várias interações destes componentes
entre si e especificando o propósito e a função destes componentes.
De acordo com Tujal (2010, p. 88):
Esta arquitetura é ponto de partida para trabalhar o ciclo de vida da
tecnologia de nuvens computacionais. Juntas, tecnologia e arquitetura
podem representar o que comumente se denomina middleware de nuvem,
visto sob a ótica dos serviços necessários para suportar um conjunto de
aplicações num ambiente de rede distribuído.
Arquitetura em nuvem não é apenas um conjunto de servidores interligados.
Conforme Tujal, ela é o ponto de partida para trabalhar a tecnologia das nuvens,
portanto sua infraestrutura requer um grande gerenciamento de dados.
Para Taurion (2009, p. 140):
A natureza da arquitetura de cloud pode ser definida como orientada a
protocolos, os quais governam a interação entre componentes, e não suas
implementações. Do mesmo modo que o advento da web revolucionou a
forma de se compartilhar informações através de uma sintaxe e protocolos
universais (HTTP e HTML), nuvens também necessitam de padrões de
sintaxe e protocolos para poderem funcionar em consonância com os
preceitos de orientação a serviços, promovendo compartilhamentos entre
organizações virtuais, além de se observar os rumos que estão sendo
consolidados sob a égide da Green IT, ou TI verde.
Num ambiente em rede, a adoção de protocolos comuns possibilita a
interoperabilidade, a qual representa o principal aspecto a ser abordado. São de
extrema importância as organizações virtuais em computação em nuvem,
comportando participantes novos dinamicamente, suportando diversas plataformas,
linguagens e ambientes de desenvolvimento.
Afirma Tujal (2010, p. 89):
Complementando o aspecto dos protocolos, destacam-se também as
application programming interfaces (APIs) e os softwar e development
kits (SDKs). Outra orientação importante para a arquitetura de cloud
consiste nos serviços. Deste modo, estabelece-se aqui que um serviço se
encontra definido em função do protocolo que ele usa para se comunicar e
do comportamento que ele implementa.
47
De acordo com Foster (2008, p. 71): “a arquitetura não define os protocolos
a serem usados ou serviços, mas identifica os requisitos para classes de
componentes”.
A figura 10 mostra as camadas de arquitetura da nuvem e seu mapeamento
com o modelo de camadas TCP/IP.
FIGURA 09 - Arquitetura de cloud (FOSTER, 2008)
Passamos agora a transcrever cada camada de arquitetura de cloud conforme
sugere a figura 09:
Conforme Costa (2009, p.04):
Aplicação camada que compreende as aplicações de usuário que
executam num ambiente de organizações virtuais. Estas aplicações em
termos de serviços de quaisquer camadas, assim como também podem
chamar serviços definidos em quaisquer camadas.
Conforme Tujal (2010, p. 90) “Enquanto a camada de recurso tem enfoque
em interações relacionadas a um único recurso, a camada coletiva contém protocolos,
serviços, APIs e SDKs de natureza global e que apreendem interações entre coleções
de recursos”.
Segundo Costa (2009, p. 04):
A camada do recurso se baseia nos protocolos de comunicação e
autenticação para definir protocolos, APIs e SDKs para oferecer formas
seguras de negociar, inicializar, monitorar e controlar as operações
compartilhadas em cada recurso. As implementações dos protocolos da
camada recurso executam funções da camada de tecido para acessar e
controlar os recursos locais.
Ocorrem na conectividade os protocolos de comunicação e autenticação
fundamentais para transações de rede específicas de nuvens. Sendo supridos pelos
48
protocolos da pilha o transporte, roteamento e resolução de nomes, sendo
considerados estes requisitos essenciais para conectividade.
Soluções
de
autenticação
para
organizações
virtuais
devem
ter
características como o single sign on (SSO – que é definido como um único ponto de
entrada, ou seja, um usuário apenas necessita se autenticar uma única vez),
delegação, integração com varias soluções de segurança local e relacionamentos de
confiança baseados em usuários.
Segundo Tujal (2010, p. 90), “o tecido é a camada que fornece recursos para
a mediação do acesso compartilhado pelos protocolos do cloud”. Os componentes da
camada tecido praticam as operações locais específicas de recurso, obtendo o nível
mais alto da pilha da camada. É através de pesquisas que permitem a descoberta de
sua estrutura, estado e capacidades (tais como recursos computacionais, recursos de
armazenamento, recursos de rede, repositórios de código e catálogos) e mecanismos
que provêem o controle da qualidade de serviço.
A seguir, veremos três das principais ferramentas que permitem que o
modelo em nuvem seja possível. O MapReduce, Hadoop e Sharding fazem com que
grandes volumes de dados sejam processados, replicados, divididos e sincronizados
geograficamente espalhados por data centers sem perder o desempenho e garantindo
a sua disponibilidade com um custo reduzido.
4.7.1 MapReduce
MapReduce é um algoritmo patenteado pelo google, que fornece apoio a
computação distribuída para grandes quantidades de dados em clusters. É útil para
operação de agregação e para processamento em lote de dados. Ele representa o que
em SQL seria a operação de GROUP BY.
MapReduce segundo Taurion (2009, p. 101), “é um modelo de programação
e framework introduzido pelo google para suportar computações paralelas em
grandes coleções de dados em clusters de computadores”.
Sendo visto como um novo modelo computacional distribuído, inspirado
pelas funções map e reduce, usadas comumente em programação funcional.
MapReduce é um “data-oriented” que processa dados em duas frases primárias: Map
e Reduce.
49
A sua filosofia por trás do MapReduce, é diversa de data-stores centrais,
como um banco de dados, não pode ser admitido que todos os dados residem em um
lugar central, portanto, não pode executar uma query e esperar obter os resultados em
uma operação síncrona.
De acordo com Almeida (2009):
Neste caso, precisa executar a query em cada fonte de dados
simultaneamente. O processo de mapear a requisição do originador para o
data source é chamado de ‘Map’, e o processo de agregação do resultado
em um resultado consolidado é chamado de ‘Reduce’.
A função Map é aplicada em paralelo a cada item do conjunto de dados de
entrada. Isso produz uma lista de pares para cada chamada. Depois disso, o sistema
MapReduce recolhe todos os pares com a mesma chave de todas as listas e os agrupa,
criando assim um grupo para cada uma das diferentes chaves geradas.
A função Reduce é então aplicada em paralelo com cada grupo, que por sua
vez, produz uma coleção de valores no mesmo domínio, fazendo assim um grupo de
informações relevantes.
Hoje, existem diversas implementações de MapReduce, como: Hadoop,
Disco, Skynet, FileMap e Greenplum. Conforme Almeida (2009), Hadoop é a
implementação mais famosa em Java como um projeto open source.
4.7.2 Hadoop
Hadoop é um framework desenvolvido em Java para auxiliar na
computação distribuída voltada para clusters e processamento de grandes massas de
dados. Foi construído com base no sistema de gerenciamento do google (GoogleFS)
e no modelo de MapReduce. É um projeto de alto nível desenvolvido e mantido pela
apache fondation e diversas comunidades virtuais e principalmente o Yahoo.
Conforme Ferreira (2010):
Um exemplo de aplicação são as operadoras de telefonia, pois sabem que
muitas vezes um único usuário que resolve mudar de operadora acaba
levando com ele muitos outros. Analisar os padrões de interações entre
seus usuários e detectar quem são os que têm mais chances de mudar de
operadora é uma grande ferramenta estratégica.
O principal objetivo de Hadoop é a análises de grandes quantidades de
dados, onde podem ser feitas decisões mais precisas e bem elaboradas em bancos de
50
dados como de redes sociais e/ou instituições financeiras, que movimentam
diariamente milhões de bits de informação, e com necessidades em tempo real para
decisões estratégicas.
O Hadoop, conforme Breitman e Viterbo (2010, p. 27), [...] ele se propõe a
resolver problemas de escalabilidade das aplicações, possibilitando o processamento
de grandes volumes de dados, da ordem de grandeza de petabytes.
Hadoop também tem sido fortemente utilizado para marketing virtual, onde
é possível traçar um perfil melhor do usuário a partir da análise de dados de
pesquisas, emails, visitas eletrônicas, etc.
Ele também promete resolver problemas como no caso de encontrar fraudes,
onde podemos processar quantidades gigantes de dados e perceber tendências
imperceptíveis em escala menor.
4.7.3 Sharding
Sharding em banco de dados é um sistema de particionamento horizontal do
banco, onde cada partição individual é referida como um estilhaço ou fragmento de
banco de dados.
Sharding conforme Taurion (2009, p. 101):
É um termo relacionado à shared nothing, que consiste em dividir os
dados horizontalmente, ou seja, quebrar as tabelas, diminuindo o seu
número de linhas e separando-as em ambientes diferentes (em outros
servidores, por exemplo,”.
O particionamento horizontal é um princípio onde as linhas de uma tabela
do banco de dados são divididas na horizontal, ao invés de dividir por colunas (como
acontece na normalização de banco de dados). Cada partição faz parte de um
fragmento, que por sua vez, pode estar localizado em um servidor de banco de dados
separado em servidores virtuais, ou mesmo em localização física diferente, em
servidores espelhados geograficamente.
Neste ponto todos os dados de uma partição não devem conter referências
aos dados de outras partições, sendo que os dados em comum deverão ser replicados
entre as bases.
51
De acordo com Code futures (2010):
Sharding banco de dados pode ser simplesmente definido como um
"shared-nothing" esquema de particionamento para grandes bases de
dados através de um número de servidores, possibilitando novos níveis de
desempenho e escalabilidade do banco de dados alcançável. Se
pensarmos em vidro quebrado, podemos obter o conceito de sharding quebrando o banco de dados em pedaços menores chamados "cacos" e
divulgar os através de um número de servidores distribuídos.
Contudo, podemos dizer que Sharding tem uma enorme escalabilidade,
além do amplo desempenho no banco de dados central.
Existem várias vantagens para utilizar este tipo de particionamento. O
número total de linhas em cada tabela é reduzido, isso reduz o índice,
e
conseqüentemente tamanho das tabelas, que geralmente melhora o desempenho da
pesquisa.
52
5 BANCO DE DADOS NAS NUVENS
Este capítulo versa o tema central do trabalho, no qual será exposto o
conceito de banco de dados nas Nuvens, os seus modelos de dados baseado em
serviços, as suas limitações, consultas, seguranças, os modelos de Arquitetura
utilizada em banco de dados em nuvens e uma ênfase sobre os SGDBs.
5.2 CONCEITO
Os principais atrativos dessa nova tendência de banco de dados como
serviço estão na economia nos custos de hardware software e manutenção de
servidores e aplicativos, quando se contrata um host. Este fornecerá espaço e
infraestrutura de poderosos data centers, com os custos calculados proporcional à
utilização , isto se aplica tanto de licenciamento de software e custos administrativos.
Segundo Barros (2010):
A computação na nuvem pode ser definida como um modelo para
permitir acesso conveniente, sob demanda da rede para um conjunto
compartilhado de recursos de computação configurável (por exemplo,
redes, servidores, armazenamento, aplicações e serviços) que podem ser
rapidamente provisionados e lançados com o mínimo de gestão, esforço
ou a interação do prestador de serviços.
Sistemas gerenciadores de banco de dados (SGBD) é um item indispensável
como componente geral em ambientes computacionais atualmente, e é pouco
provável diminuir sua importância ou uso.
Então podemos dizer que, computação em nuvem é um modelo pay-per-use
para que permiteir o acesso à rede sob demanda para um conjunto compartilhado de
configurável recursos de computação (redes, servidores, armazenamento, aplicações,
serviços), que podem ser rapidamente configurados e liberados com a gestão do
esforço mínimo ou de interação prestador de serviços.
Conforme Barbieri (2010):
Uma nova forma de armazenamento de dados se estabeleceu nas Nuvens.
Nuvem, aqui, bem explicado, é a cloud, conceito maior com que se
denomina a grande Internet, composta de milhões de usuários e de
máquinas, e que tem uma conformação tão mutável e dinâmica, como a
própria. Os grandes usuários desse ambiente são aquelas empresas que
tem "negócio" centrado na manipulação de grandes volumes de dados
(marca dos penta e exabytes), como Google, Amazon, Facebook, Twitter
e etc.
53
As grandes empresas espalham através da internet aplicações e serviços,
para que todos tenham acesso, direcionando sempre seus esforços e tecnologia para
cloud computing.
5.2 MODELO DE DADOS BASEADO EM SERVIÇOS
De acordo com Taurion (2009, p. 129):
Bancos de dados são essenciais a qualquer negócio [...]. Não é comum
vermos centenas de empresas com diferentes tipos de bancos de dados, a
maioria críticos nas operações, suportado por diversos softwares de
gerenciamento de banco de dados, os SGBD.
Surge então o modelo database-as-a-service (DaaS), provendo banco de
dados por demanda. Com o DaaS, uma empresa usa uma nuvem para armazenar e
acessar informações sem se preocupar com a infraestrutura que vai suportar os
bancos de dados.
Conforme Taurion (2009, p. 129):
Neste modelo o usuário paga pelo volume de dados armazenado e pela
quantidade de dados transmitidos de e para a nuvem. Os custos de
infraestrutura e suporte ficam a cargo do provedor da nuvem que mantém
o DaaS.
Os atrativos do modelo DaaS são principalmente, a redução de custos
quando comparado ao modelo tradicional e elasticidade dos recursos.
O modelo DaaS pode ser implementado por três arquiteturas básicas: os
modelos de container, modelos de cópia compartilhada e modelo de cópia exclusiva.
•
Modelo container, no qual o provedor fornece um container que
representa uma coleção de entidades heterogêneas, da mesma maneira
que um banco de dados possui múltiplas tabelas. Os programas
acessam as entidades nos container.
•
Modelo cópia compartilhada, modelo de uma mesma cópia do banco
de dados residente na nuvem é compartilhada por vários clientes,
embora cada um possua seu próprio espaço de dados. O
compartilhamento é do software de banco de da infraestrutura apenas.
54
•
Modelo de cópia exclusiva, cada cliente tem sua própria cópia na
nuvem do software de banco, apenas compartilham a mesma
infraestrutura.
É de suma importância que a escolha do provedor de serviços seja feita de
forma adequada e consciente. Durante o processo de seleção deve-se verificar em
amplitude dos serviços oferecidos, solidez financeira do provedor, presença
geográfica, expertise e suporte técnico na tecnologia específica do banco de dados,
referências de clientes e oferta de serviços de nuvens adicionais.
De acordo com Alecrim (2010):
Database-as-a-service (DaaS): O nome já deixa claro que esta
modalidade é direcionada ao fornecimento de serviços para
armazenamento e acesso de volumes de dados. A vantagem aqui é que o
detentor da aplicação conta com maior flexibilidade para expandir o
banco de dados, compartilhar as informações com outros sistemas,
facilitar o acesso remoto por usuários autorizados, entre outros.
O modelo DaaS ainda se encontra com os seus serviços em nuvem nos
estágios iniciais de sua adoção. Provavelmente nos próximos anos veremos uma
evolução significativa, tanto em seus modelos de negócios, como na evolução de sua
tecnologia.
Conforme Tujal (2010, p, 78):
O padrão banco de dados como um serviço fornece a capacidade de alocar
serviços de um banco de dados hospedado remotamente, entregando-os
logicamente, em termos de desempenho e funcionalidades, como se o
banco fosse local.
Os principais serviços oferecidos no modelo DaaS é a capacidade de
flexibilidade e escalabilidade.
Para Holanda et al. (2009):
O modelo database-as-a-service (DaaS) oferece flexibilidade e
escalabilidade que uma empresa de pequeno ou médio-porte não são
capazes de bancar. Não há risco de que o serviço se torne atrasado.
Eliminam a necessidade de qualquer investimento de capital em
infraestrutura.
Existe tanto a possibilidade de se criar ambientes de testes, quanto à de
economizar ao armazenar dados poucos utilizados.
Conforme Holanda et al. (2009):
Oferecendo também flexibilidade para desenvolvimento e teste, sem ter que
esperar por dias ou semanas para ter o ambiente disponibilizado. Podemos
dizer que 20% dos dados das empresas são realmente ativos, o restante são
acessados com pouca ou nenhuma freqüência. Custo menor do que fosse
55
mantidos nos discos da empresa. Uso para backup devido ao custo do
armazenamento.
No database-as-a-service, existem dois modelos de cópias, o modelo de
cópia compartilhada e o modelo de cópia exclusiva.
Para Taurion (2009, p. 132), “No modelo de cópia compartilhada: uma
própria cópia residente na nuvem é compartilhada por diversos clientes, apesar de
cada uma possuir seu próprio espaço de dados (tabelas)”.
Já no modelo de cópia exclusiva cada cliente tem sua própria cópia do
software de banco de dados.
5.3 LIMITAÇÕES DO MODELO DAAS
De acordo com Taurion (2009, p. 132): as três principais limitações são:
1) A sobrecarga da largura de banda de internet entre o servidor e
clientes;
2) O risco de sobrecarregar pelos clientes com alto processamento de
consultas;
3) Limitações no lado dos hosts em oferecer recursos administrativos para
os operadores de banco de dados.
Isto decorre porque o servidor ainda não é capaz de executar consultas e
cruzamento de dados complexos, devido a esses dados serem criptografados em sua
maioria nos bancos de dados em nuvem, que por sua vez resulta em um conjunto de
dados criptografados, que são enviados para o cliente, que conseqüentemente detêm
a chave para concluir a consulta desejada.
A transmissão dos resultados é de grande sobrecarga na comunicação entre
o servidor e o cliente, exigindo uma larga banda de rede. Os tipos de consultas que
podem ser executados no servidor sobre os dados criptografados são limitadas a
lógica, o que reduz muito a utilidade do servidor no processamento da consulta.
Especificamente, como a reunião de dados e correspondência não é
suportada na íntegra, isso acaba resultando em um trabalho maior na carga dos
clientes. Isso pode ser aceitável se o cliente estiver usando o seu desktop ou laptop
com uma velocidade alta de conexão de rede e internet, mas no caso do cliente tiver
um dispositivo fraco, como um telefone celular ou PDA, a energia da bateria e
recursos computacionais são limitados.
56
Taurion (2009, p. 132) diz que:
“[...]este modelo está como a maioria dos serviços em nuvens, nos
estágios iniciais de sua adoção. Provavelmente nos próximos anos
veremos uma evolução significativa tanto em seus negócios quanto em
sua tecnologia”.
5.4 CONSULTAS
As consultas podem trazer muitas diferenças do modelo atual
utilizado, onde as querys são executadas na forma SQL, e de forma aberta, sem que
haja criptografia, com várias possibilidades de junção e funções para agrupar dados
de variadas tabelas.
Em sua maioria, os bancos de dados voltados para nuvem são de padrão
NoSQL (pós-relacional), onde formas de consulta dependem de API que são
comandos prontos para pesquisas de dados, eles não aceitam funções de junção
agrupação, de outra forma trazem mais segurança ao usuário, pois criptografa suas
consultas e seus resultados, e somente o detentor dos dados pode decodificá-los.
Conforme Mykletun et. al (2006, p. 89), “As consultas possibilitam ter
diferentes perspectivas sobre os dados e a selecionar e editar a informação que
satisfaz determinados critérios”. A disposição da informação dada por uma tabela,
não é a forma mais conveniente quando o objetivo é analisar dados.
A estrutura das cunsultas dependem muito da forma de armazenar do
SGDB, onde temos também tabelas que são chamadas de column-families. Como o
nome indica um column-family são várias colunas agrupadas entre si. As quais são
essas colunas que a aplicação define.
Cada coluna salva um valor, e o grupo de colunas dentro de uma familia é
acessível através de uma chave (row-key). O esquema fica assim:
1. columnFamily – parecido com uma tabela (tabela de colunas)
2. rowKey – ID do grupo de colunas
3. column – nome da coluna
4. value – valor a salvar
De acordo com Date (2004, p. 43), “Os atributos são criptografados com o
sistema chamado cryptosys, a qual somente o cliente sabe uma chave de decifração, e
quando confirmada essa chave, a base de dados resultante é transmitida”.
57
5.5 SEGURANÇA
A segurança dos resultados de um dispositivo é equipado com uma
multitude de sensores capazes de detectar vários ataques. No
caso em que a
penetração do dispositivo é detectada através da sinalização por meio de sensores,
esses são monitoramentos possíveis, se um alarme dispara todo o conteúdo de
memória é apagado, destruindo o chip de memória física através de um vazamento
de ácido.
Além de suas características de segurança, os serviços podem ser equipados
com suporte de criptografia de hardware, hash e geração aleatória de números.
Armazenando chaves criptográficas e outros dados confidenciais dentro de uma
memória e usá-lo como encriptação de decodificação. Essas Soluções já foram
propostas no âmbito da rede segura de servidores em que o objetivo é aumentar o
nível de confiança depositada no Servidor.
Conforme Date (2004, p. 30):
A IBM 4758 sc, que é o primeiro de seu tipo, é equipado com processador
de 99 mhz e 2 mb de memória, placa de memória on-board, embora o
avanço tecnológico realizados desde sua introdução espera para continuar.
Uma vez que o sc é uma unidade programável, é possível fornece para um
locomotor de execução da consulta.
Questões de segurança devem ser consideradas para prover a autenticidade,
confidencialidade e integridade.
Segundo Hacigumus (2002, p.28):
Uma vez que a criptografia de dados, é utilizada como uma solução para
o problema de privacidade de dados. Umas das coisas mais importantes
deles é garantir a integridade dos dados dos usuários. A integridade dos
dados pode ser comprometida , quando isto acontece, o cliente não tem
nenhum mecanismo para detectar a integridade dos dados originais.
Assim, novas tecnicas tem que ser desenvolvidas para fornecer mais
seguraças para os clientes.
Outra questão a abordar no âmbito das bases de dados criptografadas é o
gerenciamento de chaves. Todas as técnicas de criptografia dependem de segura e
eficiente arquitetura de gerenciamento de chaves. O modelo DaaS coloca mais
complexidade na arquitetura de gerenciamento de chaves. Geração, armazenamento,
registro e atualização de chaves de encriptação são funções essenciais que têm de ser
tratadas de forma eficiente no modelo de DAS.
58
Conforme Holanda et al. (2009):
Recentemente foi criada uma associação chamada cloud security alliance,
o qual produziu o relatório security guidance for critical areas of focus in
cloud computing (versão v2. 1). Este relatório é um work-in-progress,
pois cloud computing ainda é um conceito e um modelo computacional
em evolução. Começa ele com um nivelamento dos aspectos conceituais
da computação em nuvem, seus modelos de serviço (infrastruture-as-aservice, platform-as-a-service e software-as-a-service) e de entrega
(public ou private clouds). A partir daí descreve os aspectos críticos que
se relacionam com segurança, divididos basicamente em dois domínios: o
domínio da governança (incluindo fatores como riscos, compliance,
auditoria, interoperabilidade entre nuvens e assim por diante) e
operacional, que inclui variáveis como operação do data center em
cloud,continuidade do negócio, gerenciamento de identidades de acesso,
virtualização, etc .
FIGURA 10 - Processo de Consulta criptografado (Traduzido de HOLANDA, 2008)
Podemos utilizar técnicas de criptografia para garantir a privacidade dos
dados. Entretanto, estas técnicas têm implicações significativas de desempenho de
consultas em SGBDs.
Portanto, alternativas para a integração de técnicas de criptografia com
SGBDs devem ser investigadas e desenvolvidas, já que a complexidade
computacional da criptografia de dados aumenta o tempo de resposta da consulta.
59
5.6 ARQUITETURAS UTILIZADAS EM BANCO DE
DADOS EM NUVENS
Existem dois modelos de arquitetura, que são compatíveis para banco de
dados em nuvens, iremos fazer uma comparação entre os dois modelos e avaliar qual
será o ideal para sua utilização.
Os dois modelos são: disco de arquitetura de banco de dados compartilhado
e disco de arquitetura de banco de dados não compartilhado.
Segundo Taurion (2009, p. 123):
A arquitetura de banco de dados chamado de disco compartilhado, o que
elimina a necessidade de dados de partição, é ideal para banco de dados
em nuvem. As Bases de dados de disco compartilhado permitir clusters
de servidores de baixo custo para usar uma coleção única de dados,
geralmente servidos por uma Storage Área Network (SAN) e Network
Attached Storage (NAS).
Todos os dados estão disponíveis para todos os servidores e não há
separação dos dados. De acordo com Date (2004, p. 32), “Como resultado, se
estivermos usando dois servidores, e sua consulta leva 0,5 segundo, podendo
adicionar dinamicamente outro servidor e que a mesma consulta pode agora ter 0,35
segundo”. Em outras palavras, bancos de dados de disco partilhado suportam a
escalabilidade elástica.
A arquitetura de disco compartilhado DBMS tem outras importantes
vantagens, além de escalabilidade elástica que o tornam muito atraente para a
implantação na nuvem.
Nessa arquitetura são necessários menos servidores, as bases de dados não
compartilhados quebram os dados em partes distintas e não são suficientes para ter
um único servidor para cada conjunto de dados, precisando de um backup no caso de
o primeiro falhar. Por isso é chamado de escravo de configuração mestre. Em outras
palavras, deve duplicar sua infraestrutura de servidor. Já o disco de arquitetura de
banco de dados compartilhados é uma configuração mestre, de modo que cada nó
fornece fail-over para os outros nós. Isso reduz consideravelmente o número de
servidores necessários para metade quando se usa disco compartilhado.
Para Dikaiakos et al. (2009):
Servidores de custo mais baixo (prolongar a vida dos seus servidores
atuais) Em um banco de dados não compartilhado, cada servidor deve ser
executado em baixa utilização da CPU, a fim de ser capaz de acomodar
60
picos de uso para esse servidor de dados. Isso significa comparar grandes
(caro) servidores para lidar com os picos. Por outro lado, espalha esses
picos de uso em todo o cluster. Como resultado, cada sistema pode ser
executado em uma Maior utilização da CPU. Isto significa que com um
banco de dados no disco compartilhado pode comprar de baixo custo ao
invés de pagar um prêmio grande para computadores high-end. Isto
também se estende a tempo de vida dos servidores existentes, uma vez
que eles não precisam oferecer um desempenho de ponta.
A escala em modelo permite que os provedores de cloud computing
aloquem e cobrem os clientes com base na forma como muitas instâncias de um
banco de dados estão sendo executado em uma máquina multi-core. Essa escala
permite lançar uma instância do MySQL por núcleo de CPU.
A manutenção simplificada ou o processo de atualização, nos servidores que
fazem parte de um banco de dados em disco, pode ser compartilhado
individualmente, enquanto o cluster permanece online. Seletivamente, pode torná-los
fora de serviço, atualizá-los e recolocá-los no serviço, enquanto os outros continuar a
funcionar. Não podendo fazer isso com um banco de dados compartilhado, porque
cada nó individual é dono de uma parte específica de dados.
A alta disponibilidade em um banco de dados de disco compartilhados é
completamente intercambiável, podendo perder nós e degradar o seu desempenho,
mas o sistema continua operando. Banco de dados de um servidor perde o sistema se
for desligado manualmente até que promova um escravo para o papel principal. De
acordo com Foster (2008, p. 85):
A redução de particionamento e serviços tuning é uma das vantagens, os
dados devem ser particionado. Embora seja bastante simples para dividir
os dados entre servidores, pensativo dos dados para minimizar o tráfego
entre os nós do cluster, também conhecida como função ou data shipping,
que é o envio de dados, requer uma grande quantidade de análises em
andamento e afinação. Tentar fazer isso em um cluster compartilhado
nada estático é um desafio significativo, mas tentar fazê-lo com um
escalar dinamicamente database cluster de banco de dados é uma tarefa
Sysiphian.
Redução de custos de suporte é outra das vantagens das bases de dados em
nuvem. Mudam muito de baixo nível DBA com especialistas que estão a gerir as
bases de dados de forma centralizada para todos os usuários. No entanto, ajustar um
banco de dados nada compartilhado requer a participação coordenada de ambos os
DBA e o programador da aplicação. Isso aumenta significativamente os custos de
suporte. Diferente do disco compartilhado de banco de dados que de forma limpa
61
separa as funções do DBA e os desenvolvedores do aplicativo, sendo assim o modelo
ideal para bases de dados em nuvem.
Bases de dados de disco compartilhados fornecem igual balanceamento de
carga, reduzindo ainda mais os custos de suporte em uma nuvem ambiente. Tornando
assim o disco de arquitetura de banco de dados compartilhado o ideal para a
computação em nuvem.
A arquitetura de disco compartilhado requer menos servidores e menores
custos, oferecendo alta disponibilidade, reduzindo os custos de manutenção,
eliminando a partição, e oferecendo escalabilidade dinâmica. Sendo essa responsável
para identificar os componentes fundamentais dos sistemas; indicar as várias
interações destes componentes entre si e especificar o propósito e a função desses
componentes.
De acordo com Tujal (2010, p. 88):
Esta arquitetura é ponto de partida para da tecnologia de nuvens
computacionais. Juntas, tecnologia e arquitetura podem representar o que
comumente se denomina middleware de nuvem, visto sob a ótica dos
serviços necessários para suportar um conjunto de aplicações num
ambiente de rede distribuído.
Num ambiente em rede, a adoção de protocolos comuns possibilita a
interoperabilidade, a qual representa o principal aspecto a ser abordado.
Conforme Breitman e Viterbo (2009, p. 38):
Interoperar torna-se essencial para a constituição das OVs (organizações
virtuais) em cloud computing, dada a natureza fluida e dinâmica das
relações entre partes quaisquer, comportando participantes novos
dinamicamente, suportando diversas plataformas, linguagens e ambientes
de desenvolvimento.
A Arquitetura em nuvem é muito mais que apenas um conjunto (embora
massivo) de servidores interligados. É uma metáfora para a internet ou infraestrutura
de comunicação entre os componentes arquiteturais, baseada em uma abstração que
oculta à complexidade da infraestrutura.
Afirma Tujal (2010, p. 89):
Complementando o aspecto dos protocolos, destacam-se também as
application programming interfaces (APIs) e os softwar e development
kits (SDKs). Outra orientação importante para a arquitetura de cloud
consiste nos serviços. Deste modo, estabelece-se aqui que um serviço se
encontra definido em função do protocolo que ele usa para se comunicar e
do comportamento que ele implementa.
62
5.7 SISTEMAS GERENCIADORES DE BANCO DE
DADOS PARA NUVENS
Os SGDBs para nuvem são extremamente escaláveis, em sua maioria o
acesso é via browser pela internet, podem ser escritos em várias linguagens, como
Java, Ruby, C, e diversas outras.
De acordo com Foster (2008, p.86), “Os SGBDs fornecem uma interface
extremamente atraente para gerenciar e acessar dados, e tem provado ser um grande
sucesso em muitos negócios financeiros e aplicações da Internet”. No entanto, eles
têm várias limitações:
•
Sistemas de banco de dados são difíceis de dimensionar, a maioria dos
seus sistemas tem limites rígidos.
•
Sistemas de banco de dados são difíceis de configurar e manter os
custos administrativos e facilmente representam uma fração significativa do custo
total de propriedade de um sistema de banco de dados. Além disso, é extremamente
difícil para os profissionais sem formação obter um bom desempenho fora da maioria
dos sistemas comerciais;
•
Diversificação dos sistemas disponíveis dificulta a seleção tendo o
aumento dos sistemas de banco de dados especializado para mercados específicos
(sistemas de memória principal para OLTP ou colunas lojas para OLAP); complica a
seleção do sistema, especialmente para os clientes cujos volumes de trabalho não irão
cair perfeitamente em uma categoria;
•
Pico provisionamento leva a custos desnecessários as cargas de banco
de dados que estão sempre em rajadas na natureza e, portanto, de provisionamento
para o pico, geralmente resultando em um excesso de recursos durante as fases de
pico-off e custos desnecessários.
A seguir, destacaremos alguns Sistemas Gerenciadores de banco de dados
para Nuvens e apresentaremos uma análise comparativa dos seguintes sistemas:
Microsoft SQL Azure, BigTable, Cassandra, SimpleDB, Relational Cloud e
CouchDB
63
5.7.1 Microsoft SQL Azure
De acordo com Moura (2010):
A Microsoft Windows Azure é uma plataforma para serviços na nuvem
que é utilizado para o desenvolvimento, o armazenamento e o
gerenciamento dos serviços dentro do ambiente da plataforma Azure. A
plataforma é flexível e pode ser utilizada para construir novas aplicações
para rodar na nuvem ou para melhorar programas já existentes. A
arquitetura aberta permite que os desenvolvedores tenham a opção de
construir aplicações na web, conectar aparelhos, PCs, servidores ou
soluções híbridas.
Segundo Taurion (2009, p. 101), “O SQL Azure database é o serviço de
banco de dados na nuvem da Microsoft. Ele oferece funcionalidade de banco de
dados voltadas para a web como um serviço utilitário”. As soluções de banco de
dados baseadas na nuvem como o SQL Azure podem proporcionar muitos benefícios,
incluindo o provisionamento rápido, a escalabilidade eficaz e econômica, a alta
disponibilidade e a redução da sobrecarga de gerenciamento.
Conforme
mencionado
anteriormente,
são
muitos
os
benefícios
proporcionados pelo uso do SQL Azure. Eles incluem capacidade de gerenciamento,
alta disponibilidade, escalabilidade, modelo de desenvolvimento familiar e modelo
de dados relacional.
Vamos passar a analisar cada um dos seus benefícios.
Para Curino (2010, p. 230):
O autogerenciamento do SQL Azure onde oferece uma grande escala e a
funcionalidade de um data center corporativo sem a sobrecarga
administrativa associada às instâncias locais do SQL Server. Essa
capacidade de autogerenciamento permite que a organização provisione
serviços de dados para aplicações de toda a empresa sem aumentar a
carga de suporte do departamento de TI central ou tirar os funcionários
especializados em tecnologia de suas tarefas básicas de manutenção da
aplicação de banco de dados departamental.
Alta Disponibilidade do SQL Azure foi edificada a partir das tecnologias
Windows Server e SQL Server, cujo predicado já foi comprovado, sendo flexível o
bastante para lidar com qualquer variação no uso e na carga. O serviço replica
múltiplas cópias redundantes dos dados em vários servidores físicos para manter a
disponibilidade dos dados e a continuidade dos negócios. No caso de uma falha de
64
hardware, o SQL Azure realiza o failover automático para otimizar a disponibilidade
de sua aplicação.
Para a Microsoft (2009):
Escalabilidade é a principal vantagem do SQL Azure é a facilidade de
escalonamento da solução. Após particionar os dados, o serviço escala
conforme o crescimento deles. Com o modelo de precificação "pague à
medida que crescer", pagando apenas pelo armazenamento que usar, de
modo que pode reduzir a escala do serviço quando não precisa dele.
No Modelo de Desenvolvimento Familiar ao criar aplicações locais que
usam o SQL Server, o desenvolvedor utiliza bibliotecas de cliente que usam o
protocolo TDS para realizar a comunicação entre o cliente e o servidor. O SQL Azure
fornece a mesma interface TDS do SQL Server, portanto pode usar as mesmas
ferramentas e bibliotecas para construir aplicações clientes para os dados
armazenados no SQL Azure. Para saber mais sobre o TDS, veja protocolos de rede e
pontos de extremidade TDS.
De acordo com a Microsoft (2010):
O Modelo de dados Relacional o SQL Azure será familiar para os
desenvolvedores e administradores, pois o armazenamento dos dados é
semelhante ao que ocorre no SQL Server, ou seja, é feito através da
Transact-SQL. Conceitualmente similar a uma instância local do SQL
Server, o servidor do SQL Azure é um grupo lógico de bancos de dados
que atua como uma barreira de autorização.
Dentro de cada servidor do SQL Azure, podem ser criados múltiplos bancos
de dados, que terão tabelas, exibições, procedimentos armazenados, índices e outros
objetos familiares. Esse modelo de dados aproveita suas habilidades de programação
em Transact-SQL e design de banco de dados relacional, e simplifica o processo de
migração das aplicações de banco de dados locais para o SQL Azure.
Os servidores e bancos de dados do SQL Azure são objetos virtuais que não
correspondem a servidores e bancos de dados físicos. O SQL Azure cuida da
implementação física, permitindo que dedique seu tempo ao design do banco de
dados.
De acordo com a Microsoft (2009):
Mais de 70 % de um orçamento típico de TI é gasto com infra-instrutora,
como sistemas operacionais, armazenamento e rede. O custo do
gerenciamento desta infraestrutura está aumentando. Os clientes querem
proteger o acesso às informações a qualquer dispositivo, de qualquer
lugar.
65
O armazenamento da Microsoft SQL Azure é feito em minutos, tendo como
benefícios a diminuição dos custos e configura apenas o que for necessário. Tendo
no seu armazenamento o auto provisionamento no SQL Azure, alterando sempre que
for necessidades para melhor atender.
Segundo Oliveira (2010):
A segurança é uma das maiores preocupações das empresas ao considerar
a movimentação de suas informações para nuvem, a Microsoft criou o
Azure com segurança em mente. O. NET access controle service permite
integração das identificações, o security assertion markup language troca
mensagens que são usadas nas aplicações para quando é pra permitir
acesso. A Microsoft desenhou um framework que se adéqua às principais
normas reguladoras de segurança.
Com a autenticação nos acessos e com a criptografia do dado na rede, os
dados e as suas aplicações torna-se mais seguros. O usuário tem que fornecer nome e
senha para ter uma conexão com o SQL Azure, dando mais segurança nas suas
informações.
Em relação ao custo benefício e modelo de precificação, podemos dizer que
o SQL Azure é cobrado pelo consumo, ou seja, pode ser cobrado o serviço por mês,
hora, tudo depende do que for contratado.
Conforme Moura (2010):
O preço do Windows Azure é baseado na medição do consumo de
serviços usados conforme o crescimento. O consumo é medido por quatro
medidores: medidores de computação (por hora de serviço); medidores de
armazenamento (por GB/DB armazenados); medidores de largura de
banda (por GB transferidos) e medidores de transações (por
usuários/transações). Empresas de todos os tamanhos podem adquirir o
Windows Azure com a rede de parceiros da Microsoft ou no site.
5.7.2 BigTable
O BigTable é um sistema de armazenamento de dados distribuído em larga
escala. Segundo O’Reilly (2006), “Ele funciona como um SGBDs orientado a
colunas e utiliza o GFS para gerenciar os dados, podendo ser utilizado juntamente
com o MapReduce para distribuir o processamento dos dados”.
Conforme Sousa et al. (2010):
O BigTable não suporta um modelo relacional, mas fornece um modelo
simples e flexível. No modelo de dados do BigTable, uma tabela é um
mapa esparso, distribuído, persistente e multidimensional, organizado em
três dimensões: linha, coluna e timestamp, formando uma célula. Linhas
com chaves consecutivas são agrupadas em tablets, que são unidades de
distribuição e balanceamento de carga.
66
As linhas são a unidade básica de atomicidade e alterações de uma única
linha são sempre transacionais. As colunas são agrupadas em famílias que formam a
unidade de controle. Várias versões de uma mesma célula podem ser armazenadas e
indexadas pelo timestamp. BigTable não suporta nenhum tipo de junção e relações
são gerenciadas na camada de aplicação.
O BigTable tem três elementos principais: uma biblioteca comum aos
clientes, um servidor mestre e vários servidores de tablets. O servidor mestre é
responsável por designar para os servidores de tablets, balanceamento de cargas e
por gerenciar alterações nos esquemas dos dados.
Um tablet fornece uma grande consistência, mas não replica o banco de
dados diretamente, pois pode ser atribuído para apenas um servidor por vez. A
replicação dos dados é realizada por meio do GFS, que gerencia o armazenamento
dos tablets e dos arquivos de log. Conforme Date (2004, p. 25):
O Google App Engine (GAE) datastore é uma solução de gerenciamento
de dados baseado no BigTable. O GAE datastore utiliza um modelo de
dados livre de esquema, suporta tipos de dados primitivos e armazena os
objetos de forma serializada no BigTable. O GAE datastore suporta
transações realizadas sobre várias entidades, mas exige que todos os
objetos em uma transação estejam dentro do mesmo grupo de entidade.
Utiliza consistência forte, similar ao BigTable. Muitos tipos de dados
comuns são suportados no armazenamento de dados, incluindo String, int,
float, e DateTime.
O GAE datastore utiliza uma chave como identificador único para atributos
como linha, links, entre outros e pode ser acessado com a linguagem de consulta
Google Query Language (GQL), um subconjunto da linguagem SQL. A linguagem
GQL possui suporte a seleção, ordenação e alguns operadores. A instrução de
seleção pode ser realizada em uma única tabela, ou seja, não suporta junções, assim
como associações ou chaves compostas em decorrência do modelo de dados
utilizado. Dessa forma, associações devem ser implementadas na camada de
aplicação.
De acordo com Imasters (2010):
O BigTable, do Google, não é uma solução de dados relacionais nem
orientada a documentos (e, na verdade, não suporta JDBC de nenhuma
maneira). O BigTable é o que é conhecido como armazenamento de
chave/valor. Ou seja, ele não tem esquema e permite armazenar
basicamente qualquer coisa que quisermos, seja uma instância de multa
de estacionamento, uma lista de corridas, sejam os corredores de uma
67
corrida. A falta de esquema do BigTable oferece uma enorme
flexibilidade, que suporta o desenvolvimento rápido.
5.7.3 Cassandra
Cassandra primeiramente foi criada pelo Facebook, que abriu seu códigofonte para a comunidade em 2008. Agora é mantido por desenvolvedores da
fundação Apache e colaboradores de muitas empresas.
Conforme Date (2004, p. 35):
A Apache Cassandra é um projeto de sistema de banco de dados
distribuído altamente escalável de segunda geração, que reúne a
arquitetura do Dynamo, da Amazon e modelo de dados baseado no
BigTable, do Google.
Cassandra pode funcionar em hardware de baixo custo e lida com alta taxa
de escrita sem sacrificar a eficiência na leitura. Tendo ela uma arquitetura do
Dynamo com o modelo de dados do BigTable e possui uma API simples como meio
de acesso aos dados.
De acordo com Lopes (2010):
Ele é um banco de dados pós-relacional. Mas como esse termo não é
muito conhecido, utilizaremos o termo NoSQL. Um repositório de dados
leve, feito em Java, similar aos famosos CouchDB (outro projeto que,
assim como o Cassandra, é incubado na Apache Incubator) e
BigTable, utilizando ferramentas similares ao Hadoop e conceitos como
MapReduce (para bancos distribuídos).
Conforme Mucin (2010), “Exerce com excelência a função de repositório de
dados. Leve e desenvolvido na plataforma Java, ele não apresenta a sobrecarga de
recurso do banco de dados convencionais”. Atualmente o projeto é baseado na
tecnologia emergente NoSQL e encontra-se incubado pela Fundação Apache.
Segundo Breitman e Viterbo (2010, p. 37):
Cassandra integra o modelo de dados BigTable com o design distribuído
Dynamo, oferecendo consistência futura. Em vez de manter dados
armazenados em sequências de filas ou colunas, ele usa a ordem ColumnFamily, inspirada no BigTable. Cassandra é distribuído por diversos data
centers, como as zonas de disponibilidade do Amazon EC2, além de
oferecer a disponibilidade e escalabilidade para alguns sites bem
conhecidos, incluindo as gigantes comunidades de usuários, Twitter e
Facebook.
68
5.7.4 SimpleDB
SimpleDB é um serviço da Web que fornece armazenamento de dados
estruturados na nuvem, e apoiada por grupos de servidores de banco de dados
gerenciado Amazônia.
Os dados não requerem nenhum esquema e são armazenadas com segurança
na nuvem. Existe uma função de consulta, e todos os dados que forem armazenados
os valores são totalmente indexados. Em consonância com outros serviços web da
Amazon, não há taxa mínima, podendo ser cobrado apenas pelo seu uso real.
De acordo com Pigatto (2009):
O Amazon SimpleDB é um serviço que provê as principais funções de um
banco de dados voltado para as nuvens. O objetivo do SimpleDB é
diminuir a complexidade de uso de bancos de dados escaláveis,
permitindo ao desenvolvedor preocupar-se apenas com a aplicação em
desenvolvimento.
Amazon SimpleDB é um serviço web para execução de consultas sobre
dados estruturados em tempo real. Estes serviços são projetados para tornar a
computação na escala da Web mais fácil e mais rentável para os desenvolvedores.
Conforme Imasters (2011):
O SimpleDB da Amazon é um armazenamento de dados baseado em
nuvem bastante simples, mas substancialmente escalável e confiável.
Devido à sua base não relacional/NoSQL, o SimpleDB é flexível e
incrivelmente rápido. Como parte da família de serviços da Web da
Amazon, o SimpleDB usa HTTP como mecanismo de comunicação
subjacente, de modo que é capaz de suportar ligações de linguagem, da
linguagem Java a Ruby, e Perl.
Segundo Pigatto (2009), “Este tipo de serviço é classificado como
Armazenamento de dados (DaaS), visto que ele permite ao usuário armazenar seus
dados em discos remotos e acessá-los a qualquer momento e de qualquer lugar”.
Para Imasters (2011):
O SimpleDB também tem um preço acessível: no licenciamento do
SimpleDB, paga-se somente pelos recursos consumidos, diferente do
método mais tradicional de comprar uma licença de antemão para uso e
espaço previstos. Como parte da classe de armazenamento de dados
NoSQL, ou não relacional, que está surgindo, o SimpleDB está
relacionado ao BigTable ou CouchDB do Google.
O serviço da SimpleDB da Amazon funciona em estreita articulação com o
Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Compute Cloud
69
(Amazon EC2), colectivamente, a capacidade de processar, armazenar e consultar
dados conjuntos na nuvem.
Conforme Lopes (2010):
Amazon SimpleDB é um banco de dados vastamente distribuído do tipo
chave-valor. Definitivamente não é o tipo de banco que serve para todo
tipo de negócio, e possuí uma série de restrições de desempenho e
escalibilidade. Atributos são limitados a 1KB cada então os seus itens a
fazer não podem ter nomes maiores que um kilobyte.
O modelo de controle de acesso do SimpleDB é similar ao S3 (Simple
Storage Service) da Amazon que é um sistema de armazenamento distribuído, onde o
sistema usa uma chave de usuário (uma cadeia de caracteres longa com aparência
aleatória) e uma senha de usuário (outra cadeia de caracteres com aparência
aleatória) para permitir que arquivos sejam armazenados e recuperados do banco de
dados.
De acordo com Amazon web Services (2010):
Amazon SimpleDB fornece um ponto final https para garantir
criptografado, a comunicação segura entre seu aplicativo ou do cliente e
seu domínio. Além disso, através da integração com a AWS
gerenciamento de Identidade e Acesso, podendo estabelecer usuário ou
nível de controle sobre o acesso ao grupo SimpleDB domínios específicos
e operações.
A construção de uma rede social simples pode utilizar sem problemas o
SimpleDB. Mesmo assim, podemos avaliar os seus requisitos de negócio, orçamento
e qualquer outra restrição técnica para descobrir se o SimpleDB servirá aos seus
propósitos.
Afirma Pigatto (2009):
O Amazon SimpleDB trabalha com uma abordagem que elimina a
necessidade de modelagem de dados, constantes manutenções e
preocupação com aumento de desempenho, o que normalmente acontece
com desenvolvedores que utilizam bancos relacionais. O serviço oferece
um conjunto de APIs para armazenagem e acesso aos dados,
possibilitando implementar escalabilidade, pagando somente por recursos
utilizados.
O SimpleDB é um sistema de armazenamento hierárquico de dados
construído para superar as limitações do S3(Amazon Simple Storage Service).
Conforme Amazon web Services (2010):
70
Amazon SimpleDB mede o tamanho de seus dados faturável adicionando
o tamanho de bytes brutos dos dados que forem enviado + 45 bytes de
sobrecarga para cada item, o nome do atributo e um par atributo-valor.
Amazon SimpleDB é projetado para armazenar quantidades relativamente
pequenas de dados e é otimizado para acesso rápido aos dados e
flexibilidade na forma como os dados são expressos. A fim de minimizar
os seus custos nos serviços AWS, grandes objetos ou arquivos devem ser
armazenados em Amazon S3, enquanto os ponteiros e os meta-dados
associados com esses arquivos podem ser armazenados na Amazônia
SimpleDB. Isso permitirá que possa rapidamente procurar e acessar seus
arquivos, minimizando os custos de estocagem.
Os dados armazenados em SimpleDB ficam disponível na internet. A
segurança dos dados é de grande importância para muitas aplicações, enquanto a
segurança da base conta de serviços web deve ser importante para todos os usuários.
Para proteger os dados, todos os acessos aos SimpleDB, se ler ou escrever, é
protegido por credenciais de sua conta. Cada pedido deverá conter a assinatura
correta e autorizada digital ou então é rejeitada com um código de erro.
De acordo com Amazon web Services (2010):
Amazônia SimpleDB passa os seus benefícios financeiros de escala da
Amazônia. Podendo pagar apenas para os recursos que realmente
consumir. Para a Amazon SimpleDB, isso significa armazenar dados lê e
escreve são cobrados por recursos computacionais consumidos por cada
operação, e não são cobrados os recursos computacionais quando não
estiver usando-as. Pague apenas pelo que usa. Não há taxa mínima. Os
preços baseiam-se na região pode estabelecer o seu domínio Amazônia
SimpleDB. Podendo começar com a Amazon SimpleDB gratuitamente.
Novos e atuais clientes recebem 25 Horas Máquina SimpleDB e 1 GB de
armazenamento gratuito de cada mês. Muitas aplicações devem ser
capazes de operar dentro desses limites perpetuamente livre camada.
5.7.5 Relational Cloud
Conforme Curino (2010, p. 235):
Relational Cloud é um SGBD como um serviço concebido com o objetivo
de consolidar as funcionalidades de gestão de dados para grandes
empresas e outsourcing do gerenciamento de dados em nuvem para
pequenas e médias empresas.
O Relational cloud prove de uma disponibilidade por meio de replicação
transparente, gerenciamento automático das cargas de trabalho e migração de dados
em tempo de execução, além de oferecer suporte a transações distribuídas
serializáveis.
Para Sousa et al. (2010):
71
Tendo então o seu foco na fragmentação e alocação dos dados, migração
de dados em tempo de execução e análise de carga de trabalho. Em
relação à fragmentação, o Relational Cloud propõe um novo algoritmo
com o objetivo de minimizar a probabilidade de uma determinada
operação ter que acessar múltiplos nós para fornecer uma resposta.
Ocorre que a migração em tempo de execução é obtida por meio de uma
estratégia que prevê quando uma adaptação será necessária antes que algum nó do
sistema seja sobrecarregado. Para tanto, o deslocamento de pequenos conjuntos de
dados é realizada durante a execução.
A alocação e análise de carga de trabalho são realizadas por meio de
técnicas estáticas e dinâmicas de caracterização da carga de trabalho, seleção de
SGBDs, atribuição de cargas de trabalho para as instâncias de banco de dados e
atribuição de instâncias de banco de dados para nós físicos.
O Relational Cloud foi projetado para ser executado em máquinas em um
único centro de dados. Cada máquina física executa várias instâncias de um SGBDs.
Estas instâncias podem utilizar sistemas de armazenamento diferentes, visto que
sistemas especializados, em geral, são eficientes para tarefas específicas.
Cada banco de dados é dividido em partições lógicas por meio de técnicas
de fragmentação. Essas partições são armazenadas em grupos de réplicas com o
objetivo de garantir a disponibilidade e tolerância a falhas. Um grupo de réplica
consiste de várias instâncias do banco de dados sendo que cada uma armazena cópia
dos dados de uma partição lógica. A fragmentação dos dados e alocação dos grupos
de réplicas nas máquinas é controlada pelo analisador de carga de trabalho.
O Relational Cloud e a sua comunicação entre as aplicações são realizadas
por meio de interfaces padrão ou protocolos conhecidos, tais como a interface JDBC.
Segundo Couceiro (1984, p. 77), “As consultas SQL recebidas são enviadas
para um roteador, responsável por analisar e verificar os metadados do banco de
dados e determinar o plano de execução”. Por fim, o sistema de transações distribui a
carga de trabalho, assegurando a serializabilidade e o tratamento de falhas. Por meio
do monitoramento constante de desempenho e carga de trabalho, o Relational Cloud
ajusta a fragmentação dos dados e as opções de localização em tempo de execução.
Falhas no sistema e alterações de carga de trabalho exigem a evolução do esquema
de fragmentação e alocação em tempo de execução.
72
Para tanto, é necessária a migração dos dados baseada nas instâncias do
mecanismo de armazenamento, o que melhora o desempenho do sistema.
5.7.6 CouchDB
Segundo Henry (2006, p. 88): “O CouchDB é um banco de dados orientado
a documentos e de código fonte aberto escrito na linguagem Erlang, buscando
replicação e escalabilidade horizontal”.
Ele é construído em um poderoso mecanismo de armazenamento B-tree, que
é responsável por manter os dados do CouchDB classificados e fornece um
mecanismo para procurar, inserir e excluir em tempo amortizado de forma
logarítmica. O CouchDB usa esse mecanismo para todos os dados internos,
documentos e visualizações.
Devido à maneira livre de esquema na qual o banco de dados está
estruturado, o CouchDB depende do uso de visualizações para criar relacionamentos
arbitrários entre documentos e para fornecer recursos de agregação e relatório. Os
resultados dessas visualizações são computados usando Mapear/Reduzir, um modelo
para processar e gerar grandes conjuntos de dados usando computação distribuída.
Para Chirs (2009), as principais características do CouchDB são:
•
Atomicidade;
•
Consistência;
•
Isolamento;
•
Durabilidade;
•
Confiabilidade;
•
Tolerante a falhas;
•
Suporte a replicação.
Suas funções referentes a mapear/reduzir no CouchDB produzem pares de
chave/valor, permitindo que o CouchDB insira-os no mecanismo B-tree,
classificados por chaves. Isso permite consultas eficientes por chave e aprimora o
desempenho de operações no B-tree. Além disso, isso também significa que os dados
podem ser particionados por muitos nós sem interferir com a capacidade de consultar
cada nó individualmente.
73
Os bancos de dados CouchDB armazenam documentos denominados
exclusivamente e fornecem uma API de JSON RESTful que permitem que aplicativos
leiam e modifiquem esses documentos. Todos os dados de um banco de dados
CouchDB são armazenados em um documento e cada documento pode ser formado
por um número indefinido de campos. Isso significa que cada documento pode ter
campos que não são definidos em outros documentos. Ou seja, os documentos não
estão ligados a um esquema rígido de banco de dados.
Conforme Chirs (2009):
Cada documento pode conter metadados (dados sobre os dados), como
um ID de documento exclusivo e números de revisão. Os campos do
documento podem conter diversos tipos de dados, como cadeias de texto,
números, valores booleanos (true/false), etc. Os campos não são ligados a
um limite de tamanho. Cada campo deve receber um nome exclusivo (os
documentos não podem ter dois campos com o mesmo nome).
O CouchDB possui uma série de características que torna seu uso viável em
servidores que possuem hardware de menor desempenho e emprega técnicas de
armazenamento e controle de concorrência baseadas na estrutura do documento.
De acordo com Lennon (2009):
Quando são feitas mudanças em um documento do CouchDB, as
mudanças não são realmente anexadas ao documento existente, mas, em
vez disso, uma nova versão de todo o documento, chamada revisão, é
criada. Isso significa que um histórico completo de modificações de
documentos é mantido automaticamente pelo banco de dados. O sistema
de revisão de documento funciona de forma semelhante a como um wiki
ou o sistema de gerenciamento de documento baseado na Web gerencia o
controle de revisão, exceto por tudo ser tratado automaticamente no nível
do banco de dados.
O CouchDB gerencia as alterações de documentos por meio de um
identificador de revisão contido em cada documento.
Afirma Lennon (2009):
Ele não possui mecanismos de bloqueio; dois clientes podem carregar e
editar o mesmo documento ao mesmo tempo. No entanto, se um cliente
salvar suas mudanças, o outro cliente receberá um conflito de edição ao
tentar salvar suas mudanças. Esse conflito pode ser resolvido carregando
a versão mais nova do documento, aplicando novamente as edições e
tentando salvar novamente. O CouchDB mantém consistência de dados
assegurando que as atualizações de documento sejam tudo ou nada —
funcionam ou falham. Nunca haverá um documento parcialmente salvo
no banco de dados.
Dessa forma, o CouchDB possui um mecanismo incremental de replicação
com detecção e gerenciamento bi-direcional de conflitos.
74
Chirs (2009) afirma que:
O CouchDB é de natureza desestruturada e, embora sua falta de um
esquema rígido forneça benefícios em termos de flexibilidade e
escalabilidade, pode ser bem difícil de realmente usar em aplicativos no
mundo real. Quando se pensa em um banco de dados relacional, é
possível ver que, para aplicativos do dia-a-dia, o relacionamento entre
tabelas definidas rigidamente é importante para dar sentido aos dados.
No entanto, quando o alto desempenho é necessário, visualizações
materializadas são criadas para desnormalizar os dados. Muitas vezes, o banco de
dados orientado a documentos faz as coisas ao contrário. Armazena seus dados em
um espaço de endereço simples, bem semelhante a um armazém de dados
completamente desnormalizado. Fornece um modelo de visualização para incluir
estrutura nos dados de forma que possa ser agregada para fornecer significado útil.
Visualizações no CouchDB são criadas on demand e podem ser usadas para
agregar, juntar e relatar sobre documentos do banco de dados. Elas são construídas
dinamicamente e não têm nenhum efeito nos documentos do banco de dados. As
visualizações são definidas em documentos de design e podem ser replicadas em
instâncias. Esses documentos de design contêm funções JavaScript que executam
consultas usando o conceito MapReduce. A função mapear da visualização usa o
documento como um argumento e executa uma série de computações para
determinar quais dados devem estar disponíveis através da visualização. Se uma
visualização tiver uma função reduzir, é usada para agregar os resultados. Recebe um
conjunto de chaves e valores e combina os mesmos em um único valor.
As visualizações do CouchDB podem ser visualizações permanentes
armazenadas dentro do documento de design ou visualizações temporárias
executadas on demand. As visualizações temporárias exigem muitos recursos e se
tornam mais lentas à medida que a quantidade de dados armazenados no banco de
dados aumenta. Por essa razão, as visualizações do CouchDB devem, em grande
parte, ser criadas em documentos de design.
75
6 ANÁLISE COMPARATIVA DE SGBDS PARA NUVENS
Neste capítulo é realizada a análise comparativa dos sistemas gerenciadores
de banco de dados para nuvens. Antes disso, vamos apresentar algumas
características que nos permitem identificar tais sistemas como SBBDs. Para tal,
tivemos como base as características abordadas no capítulo 2 deste trabalho, em
especial aqueles apresentados na Tabela 01.
Segundo Machado (2008), existem algumas regras básicas e claras para que
um sistema de manipulação de dados possa ser considerado um SGBD. Podem-se
citar as seguintes regras: a auto-contenção, independência dos dados, abstração dos
dados, visões, transações e acesso automático.
A tabela 02 feita por Curino (2010) mostra requisitos diferentes dos
apresentados no capítulo 02. Desta vez as regras dizem sobre quais elementos devem
possuir os SGDBs para atender a 03 critérios macros para compor a computação em
nuvem e ser considerado como um sistema gerenciador de banco de dados.
Os elementos apresentados são requisitos de usuário com regras de API de
consultas, acesso fácil a configurações avançadas, disponibilidade e outros. Em
requisitos de provedor, exige-se controle de SLA (Service Level Agreemet),
economia de hardware e energia, e redução de custos administrativos. E por fim,
requisito extra de nuvem pública, onde traz questões de preço, garantias de segurança
e privacidade e baixa latência do sistema.
76
Requisitos do Usuário
U1 API simples com pouca configuração e administração (ex. sem tuning)
U2 Alto desempenho (ex. vazão, escalabilidade)
U3 Alta disponibilidade e confiança (ex. hot stand-by, backup)
U4 Acesso fácil à características avançadas (ex. snapshot, evolução de esquema,
mineração de dados)
Requisitos do Provedor
P1 Atender o SLA do usuário (ex. potencialmente sob carga de trabalho dinâmica)
P2 Limitar hardware e custo de energia (ex. multiplexação intensiva)
P3 Limitar custo de administração (ex. custo com pessoal)
Requisitos extra de Nuvem Pública
P1 Esquema de preço: barato, previsível e proporcional ao uso (elasticidade)
P2 Garantias de segurança e privacidade
P3 Baixa latência (relevante para OLTP e aplicações Web)
TABELA 02 - REQUISITOS PARA SGBD COMO UM SERVIÇO (CURINO ET AL. 2010)
A seguir, será feita uma análise comparativa dos seguintes sistemas
gerenciadores de bancos de dados para nuvens: Microsoft SQL Azure, BigTable,
Cassandra, SimpleDB, Relational Cloud e CouchDB.
Na visão de Foster (2008), os sistemas gerenciadores de banco de dados
para nuvens, não precisam mais dessas regras para ser considerados SGBDs. Com o
passar do tempo e com a evolução da tecnologia, esses sistemas foram evoluindo,
mudando as regras tradicionais citadas no capítulo 2.
De acordo com Curino et al. (2010), os sistemas evoluíram e apresentam
uma lista de requisitos novos para um SGBD como um serviço da nuvem, conforme
a tabela 02.
77
6.1 MICROSOFT SQL AZURE
Forma de distribuição: Serviço.
Segurança: a Microsoft criou o Azure pensando na sua segurança. O Net
Access Controle Service tem a integração das identificações, o Security Assertion
Markup Language troca mensagens que são usadas nas aplicações para quando é
para permitir acesso. A Microsoft delineou um framework que se adéqua às
principais normas reguladoras de segurança.
Armazenamento: em relação ao armazenamento, com SQL Azure, pode ser
configurado seu armazenamento de dados rapidamente. Isso reduz os custos iniciais
e permite que configure apenas o que o necessário. Quando as necessidades mudam,
pode-se facilmente estender seu armazenamento de dados baseados no auto
provisionamento do SQL Azure.
Suporte: podemos dizer que o preço é baseado de acordo com o seu
consumo de serviços. Este consumo é medido por quatro medidores: medidores de
armazenamento (por GB/DB armazenados); medidores de computação (por hora de
serviço); medidores de largura de banda (por GB transferidos) e medidores de
transações (por usuários/transações).
Benefícios: um dos seus benefícios é o seu acelerado provisionamento,
escalabilidade econômica, elevada disponibilidade e sobrecarga de gerenciamento
reduzida.
6.2 BIGTABLE
Forma de distribuição: serviço
Segurança: sedimentação dos dados em três partes, em servidores diversos e
aleatórios. Consulta de forma criptografada.
Armazenamento: o seu armazenamento é feito por meio da chave/valor. Não
precisa de esquema e permite armazenar basicamente qualquer coisa, seja uma
instância de multa de estacionamento, uma lista de corridas, sejam os corredores de
uma corrida.
Suporte: o seu serviço é pago, com custos inferiores da Amazon SimpleDB.
78
Benefícios: extrema rapidez na recuperação de dados, muito superior a
bancos de dados relacionais, devido a cada nó no cluster se comunicarem com outros
nós (p2p) e fazer ativamente parte da partição/replicação. A capacidade de
armazenamento e escalabilidade também se destacam por superar a marca do
teraflops facilmente.
6.3 SIMPLEDB
Forma de distribuição: serviço
Segurança: os dados que armazenados em SimpleDB ficam disponíveis na
internet. Para proteger os dados, todos os acessos aos SimpleDB, se ler ou escrever, é
protegido por credenciais de sua conta. Cada pedido deverá conter a assinatura
correta através de assinatura digital e criptografia para as consultas.
Armazenamento: a Amazon tem seu próprio armazenamento de chave/valor
baseado em nuvem chamado de SimpleDB, um armazenamento de dados de
chave/valor extremamente escalável e confiável, que é exposto via interface da Web.
De acordo com a Imasters (2010):
É possível manipular o armazenamento de dados SimpleDB por meio da
Web e de HTTP. Ligações em cima da infraestrutura de serviço da Web da
Amazon possibilitam aproveitar o SimpleDB usando a linguagem que
quisermos, entre opções que incluem PHP, Ruby, C# e linguagem Java.
Suporte: no licenciamento do SimpleDB, vai ser pago apenas o que for
consumido, diverso do método mais tradicional de comprar uma licença de para uso
e espaço previstos. Como parte da classe de armazenamento de dados NoSQL, ou
não relacional, que está surgindo, o SimpleDB está relacionado ao BigTable ou
CouchDB do Google.
Benefícios: é fácil de usar com interface simples que fornecem benefícios de
escalabilidade e flexibilidade.
79
6.4 CASSANDRA
Forma de distribuição: serviço
Segurança: os dados são automaticamente replicados para vários nós com
tolerância a falhas. A replicação através de vários centros de dados é suportada.
Falhas nos nós podem ser substituídas sem tempo de inatividade. Consultas
criptografadas para garantir a privacidade dos dados.
Armazenamento: utiliza chave chamada KeySpace que contem apenas pares
ordenados formados por “chave: registro”. O registro, por sua vez, tem sua própria
estrutura; podendo modificá-la sem alterar os demais. Os valores de todas as colunas
são passados para o banco como vetores de bytes, o banco não interpreta os tipos,
isso torna a base menor em tamanho. Como os dados são convertidos em vetores de
bytes, eles ocupam somente o espaço necessário.
Suporte: é mantido pela Apache Foundation e tem seu código aberto para
uso sem custos.
Benefícios: exerce com excelência a função de repositório de dados para
bases extremamente grandes. Disponibilidade e escalabilidade e fácil gerenciamento
são pontos fortes em seu uso.
6.5 RELATIONAL CLOUD
Forma de distribuição: serviço.
Segurança: sistema de segurança ajustável que permite consultas SQL para
ser executado sobre os dados criptografados, incluindo as operações de ordenação,
agregados e associações.
Armazenamento: o Relational Cloud foi arquitetado para ser executado em
máquinas em um único centro de dados. Cada máquina física executa várias
instâncias de um SGBDs. Essas instâncias podem utilizar sistemas de
armazenamento diferentes, visto que sistemas especializados, em geral, são eficientes
para tarefas específicas.
Então podemos associar o Relational Cloud como um bando de dados,
divididos em várias partições lógicas, através de técnicas de fragmentação. Sendo
80
essas partições armazenadas em grupos com objetivo de garantir a disponibilidade e
tolerância a falhas.
Suporte:
desenvolvida
e
mantida
pelo
instituto
tecnológico
de
Massachusetts MIT, a fim de testar os benefícios e custos do banco de dados como
serviço na nuvem.
Benefícios: menor complexidade técnica, graças a um sistema unificado e
simplificado interface de serviço de acesso, e muitos recursos disponíveis para sua
configuração.
O uso de um algoritmo gráfico baseado em dados de separação para
alcançar linear o desempenho máximo, mesmo para cargas de trabalho transacionais
complexas
6.6 COUCHDB
Forma de distribuição: ponto a ponto (p2p) e distribuída por serviço.
Segurança: é feita pela identificação exclusiva, podendo esta identificação
ser atribuída pelo usuário ou pelo aplicativo, ou ele pode usar um identificador
universalmente exclusivo, este número aleatório é gerado pelo CouchD.
Armazenamento:
o
CouchDB
armazena
documentos
denominados
exclusivamente e fornecem uma API de JSON RESTful que permitem que aplicativos
leiam e modifiquem esses documentos. Todos os dados de um banco de dados
CouchDB são armazenados em um documento e cada documento pode ser formado
por um número indefinido de campos. Isso significa que cada documento pode ter
campos que não são definidos em outros documentos. Ou seja, os documentos não
estão ligados a um esquema rígido de banco de dados.
Segundo Moraes (2011), a “base de dados orientados a documento é
diferente. Não existe hierarquia de dados, somente uma coleção de documentos que
pode conter virtualmente qualquer espécie de dados”. Os documentos não precisam
ser necessariamente do mesmo tamanho, pois alguns documentos podem conter
detalhes de campos que outros não precisam armazenar. “Em outras palavras, não
está condicionado a um esquema de banco de dados”.
81
Suporte: é mantido pela Apache Foundation e tem seu código aberto para
uso sem custos.
Benefícios: são vários os seus benefícios, um deles é a sua habilidade de se
replicar em diferentes servidores e sistemas offline o que é bastante útil para
aplicações móveis que são projetadas para funcionarem tanto online quanto offline.
De acordo com Taurion (2009, p. 137):
A aplicação pode guardar os seus dados offline no próprio dispositivo, e
então sincronizar com o servidor quando o aparelho estiver online.
gerenciamento multiplataforma;
Após a exploração de tais sistemas, busca-se identificar o modelo de banco
de dados em nuvem, traçando as características tais quais seguem na tabela 03,
como: o modelo, o tipo de armazenamento, a linguagem de consulta, as transações, a
forma de consistência, a escalabilidade e a disponibilidade
Características
SimpleDB
BigTable
GAE
Cassandra
Modelo
Chavevalor
Coluna
Coluna
Documento Relacional
Armazenamento
Hash
Consistente
Índices
Índices
Árvore B+
Tabela
Tabela
Linguagem de
Consulta
API
simples
API
simples
API simples
API
simples
SQL
SQL
Não
Sim
simplificada
Não
Sim
Sim
Transações
Não
CouchDB
SQL
Azure
Relational
Cloud
Relacional
Consistência
Eventual
Forte
Eventual
Eventual
Forte
Forte
Escalabilidade
Alta
Alta
Alta
Média
Média
Baixa
Disponibilidade
Alta
Alta
Alta
Alta
Alta
Média
TABELA 03. COMPARAÇÃO DOS SISTEMAS – (SOUSA ET AL. 2010)
82
A pesquisa em relação a tabela 03, ocorre através de estudos de cada um dos
sistemas relacionados anteriormente, onde os autores tiraram as semelhanças e as
diferenças de cada sistema e fizeram uma comparação a respeito de suas
características.
Em relação à escalabilidade e disponibilidade, SQL Azure e Relational
Cloud apontam características diferentes. O SQL Azure possui média escalabilidade,
já que não oferece suporte a transações distribuídas ou consultas através de múltiplas
partições de dados localizados em diferentes nós, mas apresenta alta disponibilidade.
Conforme Candan (2009, p. 1.761), as comparações referentes aos sistemas
podem ser analisadas nas seguintes formas:
Novos serviços de dados em nuvem, como o GAE datastore, Amazon S3,
SimpleDB e Cassandra utilizam modelos simplificados de dados
baseados em par chave-valor ou orientados a coluna. Os dados são
armazenados em estruturas otimizadas e acessados por meio de APIs
simples. GAE datastore, S3/SimpleDB, CouchDB não possuem suporte a
transações ACID. Cassandra utiliza um conceito simplificado de
transações para linhas. Estes sistemas suportam apenas consistência
eventual, exceto o GAE datastore e todos apresentam alta escalabilidade e
alta disponibilidade, menos o CouchDB que possui média escalabilidade,
em decorrência do modelo de dados utilizado.
O GAE Datastore, Amazon S3, SimpleDB e Cassandra apresentam ótimos
resultados na manipulação de grandes volumes de dados, pois estes modelos de
dados utilizam sistemas que favorecem a fragmentação dos dados. No entanto, estes
sistemas não suportam operações como junções, possuem apenas garantias de
consistência fraca e fornecem suporte limitado a transações. Ademais, empregam um
modelo de dados mais simples, a complexidade é empurrada para as demais camadas
da aplicação, determinando dos desenvolvedores a adição de funcionalidades mais
complexas nas camadas superiores.
De acordo com Sousa et al. (2010):
O CouchDB e sistemas baseados em grafo optaram por modelos mais
ricos de dados. Com isso, eles apresentam abstrações poderosas que
tornam mais fácil modelar domínios complexos. Estes modelos de dados
mais ricos introduzem maior quantidade de ligação entre os dados, o que
prejudicar a escalabilidade. Vale ressaltar que estes sistemas ainda são
muito recentes e existem poucos estudos detalhados sobre os mesmos,
assim como ferramentas e tecnologias de apoio para sua ampla utilização.
O CouchDB apresenta um estudo comparativo de BD em serviços,
contemplando as características de armazenamento, modelo, transação, consistência,
escalabilidade e disponibilidade.
83
Candan (2009, p. 1.7694), afirma que “Os sistemas SQL Azure e Relational
Cloud utilizam o modelo de dados relacional, que fornece grande flexibilidade no
acesso aos dados, tais como agregação e consultas com junções”. Eles programam
transações ACID e garantia de consistência forte, o que facilita no desenvolvimento
de aplicações.
Segundo Medeiros (2006, p. 10), o sistema relacional Cloud:
Apresenta baixa escalabilidade e média disponibilidade, pois se trata de
um sistema em desenvolvimento e que não considera aspectos de
elasticidade e ambientes virtualizados, características essenciais da
computação em nuvem. O SQL Azure não possui suporte a fragmentação
automática de dados, essencial para melhorar a escalabilidade, mas o
Relational Cloud apresenta iniciativas neste sentido. A Tabela mostra um
resumo deste comparativo.
Para Kossmann (2010, p. 549), “É importante ressaltar que os modelos de
dados utilizados pelos SGDBs em nuvem são compatíveis, ou seja, pode-se expressar
um conjunto de dados em qualquer um deles.”
Podemos citar exemplos, como no caso de ser possível decompor todos os
dados de um banco de dados relacional, em uma coleção de par chave-valor. Dessa
forma, existem contextos onde cada um destes modelos de dados é mais apropriado.
De acordo com Kossmann (2010, p. 550), “Os principais provedores tem
adotado diferentes arquiteturas para seus serviços e o custo e o desempenho destes
serviços variam significativamente dependendo da carga de trabalho”.
84
7. CONSIDERAÇÕES FINAIS
O presente trabalho objetivou verificar, por meio de pesquisas
bibliográficas, os tipos de bancos de dados em nuvem, com vistas a identificar
aspectos de segurança, arquitetura e métodos de consultas dessa tecnologia. Com
esses estudos apresentados, podemos concluir que os bancos de dados como serviços
em nuvem, oferecem o potencial para lidar com várias limitações graves de bancos
de dados existentes relacionados à escalabilidade e flexibilidade, facilidade de uso e
provisionamento de estresse de processamento.
Neste documento, foram explorados os principais requisitos e desafios
técnicos para tornar a visão de um serviço de banco de dados, introduzindo a sua
concepção e avaliação inicial de uma nova forma de armazenar, processar e
disponibilizar dados na rede de internet ou mesmo para particulares.
Vemos estes resultados como um primeiro passo no sentido de fornecer
bases de conhecimento aos leitores leigos no assunto de banco de dados como
serviço, além de comparativo para avaliar modelos diferentes, em uma tabela de
variados SGDBs baseados em nuvem.
Uma das dificuldades encontradas durante a elaboração deste trabalho foi o
material bibliográfico escasso, sendo que muitos dos materiais encontrados não são
claros com relação a informações mais científicas dos sistemas investigados, às vezes
trazendo detalhes tecnológicos de forma superficial.
Um trabalho futuro desta pesquisa seria uma aplicação do banco em um
modelo real á uma empresa ou instituição local, a fim de provar os benefícios do uso
de banco de dados como serviço de nuvem.
Ao comparativo, verificamos que todos os SGDBs têm muito em comum,
tratando da forma de armazenar e buscar os dados, devido que quase todos derivam
da mesma tecnologia e são mantidos pelas mesmas empresas e grupos de usuários da
comunidade de internautas. Com exceção do Relational Cloud todos têm de média a
alta escalabilidade e alta disponibilidade, tornando-se menos indicado para o sistema
de nuvem já que, a disponibilidade e escalonabilidade são essenciais para o sucesso
da nuvem.
85
8. REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, R. Entendendo MapReduce. Disponível em: http://manifestonaweb.
Wordp ress.com/2009/06/02/entendendo-mapreduce. Acesso em: 21 de dez. 2010.
AMAZON
WEB
SERVICE.
Amazon
SimpleDB.
Disponível
http://aws.Amazon. com / SimpleDB. Acesso em: 15 de jan. de 2011.
em:
ARMBRUST, M.; FOX, A.; GRIFFITH, R.; JOSEPH, A. D.; KATZ,
R.;KONWINSKI, A.; LEE, G.; PATTERSON, D.; RABKIN, A.; STOICA, I.;
ZAHARIA, M. Above the Clouds: A Berkeley View of Cloud Computing. EECS
Department, University of California, Berkeley, fevereiro 2009.
BARBIERI, C. banco de dados nas nuvens – NOSQL. Disponível em: http:
//blogdobarbi.
blogspot.com/2010/02/bancos-de-dados-nas-nuvens-noSQL.html.
Acesso em: 22 de dez. 2010.
BIAZUS, C J. Uma visão geral do gerenciamento de banco de dados. Disponível:
http://www.scribd.com/doc/7507097/Introdu-o-a-banco-de-dados-1-Alunos.Acesso
em: 15 de Nov. de 2010.
BOLZAN. W. Modelagem e projeto de banco de dados com o DBDesigner.
Disponível
em:
http://www.devmedia.com.br/articles/viewcomp_forprint.asp?
comp=777. Acesso em: 17 de nov. de 2010.
BREITMAN, K; VITERBO, J. Computação na nuven: Uma visão geral. In
Amãpytuna. Brasília: Funag,2010, p.17.
CANDAN, K. S., Li, W.-S., Phan, T., Zhou, M. . Frontiers in information and
software as services: Proceedings of the IEEE International Conference on Data
Engineering (ICDE ’09), Washington, DC, USA. IEEE Computer Society, 2009,
pg.1761–1768.
CAVALCANTI, Lucas Dantas. Computação em nuvem abordagem energética.
Disponível em: http://www2.cin.ufpe.br/site/index.php. Acesso em: 20 de fev. 2011.
CODE FUTURES. Database Sharding with dbShards. Disponível em: http:// www.
Code futures.com/. Acesso em: 05 de jan. de 2011.
COSTA, D M. Análise de frameworks para construção de portais para
ambientes de computação em grade e sua aplicabilidade no AppMan. Canoas:
Campus, 2009, p. 04.
COUCEIRO, L A C C. Sistemas de Gerência de banco de dados Distribuídos, Rio
de Janeiro: LTC, 1984. 77p.
86
CURINO, C., Jones, E., Zhang, Y., Wu, E., Madden, S. Relational Cloud: The case
for a database service. Technical report, MIT-CSAIL-TR-2010-014. Computer
Science and Artificial Intelligence Laboratory, MIT, USA, 2010, p.235.
CHANG, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M.,
Chandra, T., Fikes, A., and Gruber, R. E. Bigtable: A distribuição
sistema de armazenamento de dados estruturados. Berkeley: Association, 2006,
p.15.
CHIRS. A. 2009. Apache CouchDB: The definitive Guide. Disponível em:
http://CouchDB. apache.org/ Acessado em 05/12/2010.
DATE, C.J.; Introdução a Sistemas de bancos de dados. 8ª. ed. Rio de Janeiro:
Campus, 2004, p.18.
DIKAIAKOS MD, D. Katsaros, G. Pallis, A. VAKALI, P. Mehra: Cloud
Computing: Computação Distribuída na Internet para TI e Investigação Científica,
Informática Internet IEEE, 12 (5), setembro 2009.
FERREIRA, Edmar. Usos práticos de Hadoop. Disponível em: http://escalabilidade
.com/2010/09/27/usos-praticos-do-hadoop/. Acesso em: 20 de fev. de 2011.
FREITAS, T R. Modelagem Temporal de Sistema de Informação. Disponível em:
http://computacao.unitri.edu.br/downloads /monografia/625111 4313 38 92.pdf.
Acesso em: 17 de nov. de 2010.
FOSTER I., Yong Zhao, Raicu I, Lu S. Cloud Computing and Grid Computing 360Degree Compared – Department of Computer Science, University of Chigado – 16
de dezembro de 2008, p.20.
GREFF, G. Sistemas de banco de dados. Disponível em: http://.com.br/guaraci
/banco _ ados/bd.pdf. Acesso em: 17 de nov. de 2010.
HACIGUMUS H., B. Iyer, e S. Mehrotra, A integridade de dados criptografados
no banco de dados modelo de provedor de serviço, WCC IFIP, Workshop sobre
Certificação e Segurança em E-Services (CSES), Montreal, Canadá, 2002.
HEUSER, C A. Projeto de banco de dados. 6ª ed. São Paulo: Bookman, 2009, p.31.
HOLANDA, A T., AVELINO, B., CAVALCANTE, R. Sistemas Distribuídos
Engenharia da Computação. Cloud Computing. Disponível: http://www.scribd.
com/doc/45939000/Cloud-Computing. Acesso em: 05 de Jan. de 2011.
IMASTERS. Desenvolvimento em Java 2.0: armazenamento em nuvem com o
Simple DB da Amazon. Disponível em: http://imasters.com.br/artigo/17718. Acesso
em: 12 de jan. de 2011.
87
JAVAROTTI FILHO, E. Modelo de banco de dados. Disponível em: http://www.
administradores.com. br/informe-se/artigos/modelo-de-redes-em-banco-de-dados/2
65 41/. Acesso em: 21 de nov. de 2010.
KORTH, H. F. e Silberschatz, A.; Sistemas de bancos de dados, tradução da 5ª. São
Paulo: Campus, 2006.p.10.
KOSSMANN, D., Kraska, T., Loesing, S. (2010). An evaluation of alternative
architectures for transaction processing in the cloud. In SIGMOD ’10: Proceedings
of the 2010 international conference on Management of data, New York, NY, USA.
ACM, 2010, p.549-590
LENNON, J. Explorando o CouchDB. Disponível em: http://www.ibm.com/develo
perworks/br/library/os-CouchDB. Acesso em:05 de jan. de 2011.
LOPES, L F d S. Computação em nuvens Disponível em: http://jus.uol.com
.br/revista/texto/11537/o-poder-judiciario-brasileiro-nas-nuvens. Acesso em: 23 de
Dez. de 2010.
MACHADO, F N R. banco de dados: Projeto e Implementação. 2.ed, São Paulo:
Érica, 2008, p.25.
MAXIMINIANO, F d S. O que é computação nas nuvens. Disponível em: http:
//softwarelivre.org/felipemax/blog/o-iniciante-o-que-e-computacao-nas-nuvens.
Acesso em: 05 de Jan. de 2011.
MECENAS, I.;OLIVEIRA, V d. banco de dados: do modelo conceitual à
implementação. 1ª. ed. Rio de Janeiro:Alta Books, 2005,p.30.
MEDEIROS, M. banco de dados para Sistemas de Informação. 1ª.ed. Santa
Catarina: Visual Books, 2006, p.10.
MELO, R N.; SILVA, S D.; TANAKA, A K. banco de dados em Aplicações
Cliente/Servidor. Rio de Janeiro: Infobook, 1997.
MENESES, B R M d M.; CRUZ, M G. Curso de Sistemas de Informação.
Bandeirantes: Computação em nuvens: benefícios e viabilidade, 2009. Disponível
em: http://docs. Google.com/viewer?a=v&q =cache: U4h J6HCOLMJ:ramses
.ffalm.br/moo dledata /38/moddata/forum/98/498/TCC_-_Clou d. Acesso em: 25 de
Nov. de 2010.
MICROSOFT. SQL Azure. Disponível em: http://www.Microsoft.com/Azure/SQL
.mspx. Acesso em: 21 de Nov. de 2010
MILLER, H.g.; VEIGA, J.. Cloud computing: will commodity services benefit users
long term?. It professional . Washington, Dc, 01 dez. 2009.
88
MUCIN,
S
P.
Apache
Cassandra.
Disponível
http://www.plantaonerd.com/blog/?p =967. Acesso em: 12 de jan. 2011.
em:
MYKLETUN, E., Narasimha, M., Tsudik, G. Secure Esquemas comprovadamente
para consulta básica: Suporte em bancos de dados de terceiros. Rio de
Janeiro:Alta Books, 2006, p.89.
OLIVEIRA, R. 10 razões para usar Azure em aplicações na nuvem.Disponível
em: http://rafaeloliveirav.spaces.live.com/blog/cns!96D2228FA42BC450!779.entry.
Acesso em: 12 de jan. de 2011.
ÖZSU, M. T; VALDURIEZ, P. Principles of Distributed Database Systems.
Tradução [da 2ª ed. americana] Vandenberg D.de Souza. Rio de Janeiro: Campus,
2001, p. 14.
PIGATTO, D F. In: Departamento de Engenharias e Ciências da Computação.
Erechim: Estudo e implementação de uma solução de softwares aplicativos
utilizando
computação
nas
nuvens,
2009.
Disponível
em:
http://www.slideshare.net/dhannyel. Acesso em: 10 de jan. de 2011.
REIS, L. Curso de Ciência da Computação do Centro Universitário do
Triângulo. Uberlândia: Um estudo sobre sgbds para ambientes não críticos, 2000.
Disponível em: http://www.computacao.unitri.edu.br /downloads/monografia /1113
114 3218785. pdf. Acesso em: 15 de nov. de 2010.
RYDLEWSKI, C. Computação Sem Fronteiras. Revista Veja, ed. 2125, São Paulo:
Abril, ago 2009.
SEA SERVER. Infraestrutura do Data Center. Disponível em: http://www
.seaserver .com. br /aempresa.php. Acesso em: 19 de fev. de 2011.
SOFTCOV. Descrito um modelo para uma nova geração de data center Daas.
Disponível: http://www.softcov.com/pt/database. Acesso em: 23 de Dez. de 2010.
SOUSA, F R. C.; MOREIRA, L O.; MACÊDO, J A F. de.; MACHADO , J C.
Gerenciamento de banco de dados em nuvem:Conceitos, Sistemas e
Desafios.Disponível em: http://www.es.ufc.br/~flavio /files/Gerenciamento_dados_
Nuvem.pdf. Acesso em: 20 de dez. de 2010.
TAURION, C. Cloud computing: Computação em Nuvem: Transformando o mundo
da tecnologia e da informação. Rio de Janeiro: Brasport, 2009, p.129.
TAKAI, O K.; ITALIANO, I C.; FERREIRA. J E. Introdução a banco de dados.
Disponível em: http://www.ime.usp.br/~jef/apostila.pdf. Acesso em: 22 de nov. de
2010.
TERRY, D.Cloud Computing. Disponível em: http://techpack.acm.org/cloud/.
Acesso em: 22 de jan. De 2011.
89
TOLEDO, C M T. Sistemas gerenciadores de banco de dados orientados a
objetos para ambiente de desenvolvimento de software. Revista Instituto de
Informática, Campinas, v.2, n. 1, p. 18-28, mar./set. 1994.
TUJAL, L C P. Amãpytuna: Modelo de referencia da cloud. Brasília: Funag, 2010,
p.47.
VAQUERO, L. M.; MERINO-RODERO, L.; CACERES, J.; LINDNER, M. A
Break in the Clouds: Towards a Cloud Definition. ACM SIGCOMM Computer
Communication Review, 39(1): 50-55, janeiro 2009.
WORDLINGO. Big Table. Disponível em: http://www.worldlingo.com
/ma/enwiki/pt/ BigTable. Acesso em: 21 de Nov. de 2010.