projeto tcc i
TRANSCRIPT
UNIVERSIDADE DO OESTE DE SANTA CATARINA – UNOESC
CAMPUS DE SÃO MIGUEL DO OESTE
ELIANE MARA CASAGRANDE
JÉSIKA PELLEGRINI
CADMIN TOOL: FERRAMENTA DE ADMINISTRAÇÃO PARA O BANCO DE DADOS
CASSANDRA
São Miguel do Oeste (SC)
2012
ELIANE MARA CASAGRANDE
JÉSIKA PELLEGRINI
CADMIN TOOL: FERRAMENTA DE ADMINISTRAÇÃO PARA O BANCO DE DADOS
CASSANDRA
Projeto de Trabalho de Conclusão de Curso
apresentado à Universidade do Oeste de Santa
Catarina – UNOESC, Campus de São Miguel do
Oeste como requisito parcial à obtenção do grau
de Bacharel em Sistemas de Informação.
Orientador: Prof. Esp. Roberson Junior Fernandes Alves
São Miguel do Oeste (SC)
2012
LISTA DE ILUSTRAÇÕES
Esquema 1 Modelo de um banco de dados hierárquico ...................................................... 10
Esquema 2 Modelo de um banco de dados em rede ............................................................ 11
Esquema 3 Modelo de um banco de dados relacional ......................................................... 12
Listagem 1 Lista de códigos do comando SELECT ............................................................ 13
Esquema 4 Função do SGBD .............................................................................................. 17
Esquema 5 Modelo de armazenamento em forma de chave/calor ...................................... 19
Listagem 2 Modelo de armazenamento em forma de documento ....................................... 19
Esquema 6 Modelo de armazenamento em forma de grafo ................................................ 20
Esquema 7 Modelo de armazenamento em forma de coluna .............................................. 21
Esquema 8 Modelo de dados do Apache Cassandra ........................................................... 22
Esquema 9 Modelo de desenvolvimento incremental ......................................................... 25
3
LISTA DE ABREVIATURAS E SIGLAS
NoSQL Not Only Structured Query Language
UML Unified Modeling Language
SGBD Sistema Gerenciador de Banco de Dados
CEP Código de Endereçamento Postal
SENAC Serviço Nacional de Aprendizagem Comercial
IBM International Business Machines
BDR Banco de Dados Relacional
SQL Structured Query Language
DML Data Manipulation Language
DDL Data Definition Language
DCL Data Control Language
DQL Data Query Language
ACID Atomicidade, Consistência, Isolamento e Durabilidade
TB Terra Byte
CAD Computer Aided Design
CAE Computer Aided Engineering
ABD Administrador de Banco de Dados
GB Giga Byte
KB Kilo Byte
IDE Integrated Drive Eletronics
PHP Hypertext Preprocessor
4
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................. 5
1.1 OBJETIVOS .................................................................................................................... 5
1.1.1 Objetivo Geral ............................................................................................................... 6
1.1.2 Objetivos Específicos ..................................................................................................... 6
1.2 JUSTIFICATIVA/PROBLEMATIZAÇÃO .................................................................... 6
2 REVISÃO DA LITERATURA .................................................................................... 8
2.1 DADOS, INFORMAÇÃO E CONHECIMENTO .......................................................... 8
2.2 BANCOS DE DADOS .................................................................................................... 8
2.2.1 Primeiros modelos de banco de dados ......................................................................... 9
2.2.2 O modelo relacional ..................................................................................................... 11
2.2.2.1 SQL (Structured Query Language)............................................................................... 13
2.2.2.2 Banco de dados PostgreSQL ........................................................................................ 14
2.2.2.3 Banco de dados Oracle ................................................................................................ 14
2.2.3 Banco de dados orientados a objetos ........................................................................ 15
2.2.4 Bancos de dados objeto-relacional ............................................................................ 16
2.3 SISTEMAS GERENCIADORES DE BANCOS DE DADOS .................................... 16
2.3.1 O administrador de banco de dados ......................................................................... 18
2.4 BANCOS DE DADOS NOSQL .................................................................................. 18
2.4.1 Apache Cassandra ...................................................................................................... 21
2.4.4.1 Ferramentas de administração ..................................................................................... 23
2.5 JAVA ............................................................................................................................ 24
2.6 ENGENHARIA DE SOFTWARE ............................................................................... 25
2.6.1 Ciclo de vida incremental............................................................................................ 25
2.6.2 Diagramas UML .......................................................................................................... 26
3 MATERIAIS E MÉTODOS ....................................................................................... 28
4 CRONOGRAMA DE EXECUÇÃO .......................................................................... 29
REFERÊNCIAS ..................................................................................................................... 30
5
1 INTRODUÇÃO
Atualmente com a capacidade de armazenamento e processamento dos computadores,
além da necessidade de acesso a informações de forma mais rápida e fácil, os bancos de dados
estão a cada dia mais presentes nas organizações, independentemente da área de atuação ou
do tamanho da empresa. E quanto mais dados são salvos, mais a empresa fica dependente do
seu banco de dados.
Apesar de existirem vários modelos de banco de dados, o modelo relacional é
atualmente o mais utilizado, porém devido as suas características como, por exemplo:
dificuldade para replicar os dados em vários datacenters (clusterização), baixa escalabilidade
incremental, ele não é capaz de suprir totalmente as necessidades de alguns sistemas.
Foi pensando nas necessidades destes sistemas que surgiu o movimento NoSQL.
Como o próprio nome nos sugere, “Not Only SQL”, ou “Não Somente SQL”, este modelo
propõem um novo padrão de bancos de dados, que não se baseiem apenas em comandos SQL,
ou seja, este modelo não tem a intenção de substituir o modelo relacional, apenas fornecer
uma solução alternativa para sistemas no qual o modelo relacional não é o mais indicado.
O presente projeto visa um estudo mais detalhado do banco de dados Apache
Cassandra, o qual segue o padrão NoSQL e propõem o desenvolvimento de uma ferramenta
web para administração deste banco de dados, chamado CAdmin Tool. O qual será voltado
preferencialmente a administradores/usuários deste banco de dados e busca propiciar a
otimização do trabalho do mesmo, através do uso de elementos gráficos, bem como oferecer
uma interface de usuário mais intuitiva.
1.1 OBJETIVOS
O presente projeto visa à produção de resultados que atinjam os objetivos propostos a
seguir.
6
1.1.1 Objetivo Geral
Desenvolver uma ferramenta de administração, na plataforma web, para o banco de
dados Apache Cassandra.
1.1.2 Objetivos Específicos
Pesquisar as técnicas utilizadas pelos bancos de dados NoSQL, em especial o
Apache Cassandra para o armazenamento de dados e o tratamento das
informações;
Modelar e desenvolver a ferramenta de administração utilizando a linguagem
UML e o ciclo de vida incremental da engenharia de software;
Desenvolver e disponibilizar a ferramenta na modalidade de software livre;
Promover um novo modelo de interação do administrador/usuário com o banco
de dados Apache Cassandra;
Verificar e validar a ferramenta de administração com usuários finais;
Criar um blog para divulgar o movimento NoSQL e os conhecimentos
adquiridos durante a execução do TCC.
1.2 JUSTIFICATIVA/PROBLEMATIZAÇÃO
É cada vez mais comum aplicações web que possuam uma quantidade enorme de
informações salvas em seus SGBD‟s – Sistema de Gerenciamento de Banco de Dados, e que
tenham a todo o momento mais e mais informações sendo armazenadas, além de uma
quantidade de acessos relativamente alta. De acordo com Rossi (2012, p.6), o Facebook,
Twitter, Google, Amazon, Yahoo, LinkedIn e Cisco System são exemplos de “gigantes” da
web que utilizam bancos de dados NoSQL, para gerenciar seus milhares de datacenters.
Sendo que o Facebook, Google e Amazon desenvolveram seus próprios bancos de dados
7
NoSQL, devido a dificuldade de encontrar soluções alternativas aos bancos de dados
relacionais, que fossem capazes de atender as suas necessidades.
Apesar de ser um padrão novo, já existem vários bancos de dados NoSQL, mas para
Bogoni (2011, p. 41), o mais conhecido faz parte do projeto Apache Cassandra. Desenvolvido
inicialmente pelo Facebook, ele foi liberado sob licença open source em 2008, sendo
atualmente mantido pela Fundação Apache e colaboradores. Desenvolvido em Java ele vem
sendo apontado como um excelente banco de dados e ganhou ainda mais destaque quando o
Twitter anunciou que estaria mudando sua base de dados do MySQL para o Cassandra.
Desta maneira pode-se concluir que apesar de o Apache Cassandra ser um sistema
muito recente, ele tem grandes chances de se tornar o banco de dados NoSQL mais usado no
futuro. Pois ele já conta com o apoio de gigantes da web, e que associado ao fato de ser um
projeto open source mantido pela Fundação Apache, contribui para o crescimento e
popularização do mesmo. Possuindo ainda toda uma comunidade de desenvolvedores que
contribuem para o aperfeiçoamento do software, além da correção de falhas e bugs.
Através de pesquisas realizadas em fóruns de discussão, blogs e no site oficial da
própria Fundação Apache pode-se constatar que atualmente as ferramentas de administração
disponíveis para o Apache Cassandra, são pagas ou de baixa qualidade, com poucos recursos
e funcionalidades. Por consequência administradores de banco de dados que trabalham com o
mesmo, acabam por utilizar ferramentas de modo texto, as quais exigem muito mais do
administrador, tanto na capacidade de lembrar dos comandos, quanto de interpretar e
gerenciar os dados armazenados no banco de dados.
Baseadas nestas perspectivas, o desenvolvimento de uma ferramenta web para a
administração do banco de dados Apache Cassandra é altamente viável. Sendo que através
dela o administrador poderá ter acesso as seguintes funcionalidades: gerenciamento da base
de dados, editor para digitação de comandos e explorador de objetos (editor visual).
8
2 REVISÃO DA LITERATURA
A presente revisão da literatura abordará a evolução dos bancos de dados e das
ferramentas de administração de banco de dados, mostrando qual é a função de cada uma.
Além disso, busca-se fundamentar a escolha dos materiais e métodos que serão utilizados no
projeto.
2.1 DADOS, INFORMAÇÃO E CONHECIMENTO
O dicionário online Michaelis (2012), conceitua dado como princípio ou base para se
entrar no conhecimento de algum assunto. Desta forma, segundo Hernandez (2000, p. 35), a
princípio os dados de forma isolada não têm sentido algum. Não podemos apreender,
simplesmente observando, o que o número “92883” quer dizer. É um CEP? É uma parte de
um número? Simplesmente não existe jeito de saber até que o dado seja processado.
Já a informação é para Hernandez (2000, p. 35): “o dado que foi processado de forma
que ele faça sentido e passe a ter uso para a pessoa esteja visualizando-o ou trabalhando com
ele.”.
Sordi (2008, p. 12) caracteriza conhecimento como um “novo saber, resultante de
análises e reflexões de informações segundo valores e o modelo mental daquele que o
desenvolve, proporcionando a este melhor capacidade adaptativa às circunstâncias do mundo
real.”. Desta forma, o conhecimento, não pode ser inserido em um computador por meio de
uma representação, pois senão foi reduzido a uma informação.
A partir desta necessidade de agrupar os dados, fazendo com que se transforme em
uma informação, capaz de proporcionar algum tipo de conhecimento para as pessoas que a
usam é que surgiram os bancos de dados.
2.2 BANCOS DE DADOS
Antes do surgimento dos primeiros bancos de dados, organizações como bibliotecas,
governo, universidades e empresas em geral armazenavam suas informações em fichas de
9
papel (fichas de clientes, fornecedores, funcionários e muitas outras mais). Com o passar do
tempo as fichas foram aumentando e a quantidade de informação também.
Desta forma Rezende (2006) destaca que:
Havia um histórico muito longo de informações armazenadas desta maneira
e também uma metodologia de indexação e recuperação da informação
quando se precisava dela. [...] Boas práticas e bons princípios de projetos de
bancos de dados datam aquela época e muito se aprendeu para a criação de
bons projetos que alcançam bom desempenho, segurança e confiabilidade.
A partir da década de 1960 os computadores se tornam parte efetiva do custo das
empresas juntamente com o crescimento da capacidade de armazenamento. Necessitando
desta forma de aplicações e ferramentas que possibilitassem o armazenamento de forma
digital de seus dados.
Segundo SENAC (1999, p. 11):
As primeiras aplicações comerciais dos bancos de dados informatizados
eram basicamente dirigidas a um setor específico de uma empresa, e sua
construção baseava-se nos processos, dados e arquivos utilizados em tal
setor. Com o tempo os outros setores da empresa passaram a ser
gradativamente atingidos pela informatização, e desta forma o sistema de
informação como um todo, foi sendo constituído por diversos sistemas
isolados, com programas e arquivos próprios e independentes.
Ainda segundo SENAC (1999, p.11) os principais problemas da construção deste tipo
de sistema eram: a redundância de informações, a inconsistência de arquivos e a necessidade
de desenvolvimento de uma aplicação específica para cada setor da empresa.
2.2.1 Primeiros modelos de banco de dados
Os primeiros modelos de banco de dados desenvolvidos foram: o modelo hierárquico e
o modelo em rede. Conforme definição de Date (1990, p. 528) “um banco de dados
hierárquico compõem-se de um conjunto ordenado de árvores – mais precisamente, de um
conjunto ordenado de ocorrências múltiplas de um tipo único de árvore.”. Esse modelo pode
ser facilmente representado por uma árvore invertida. Conforme o modelo a seguir:
10
Esquema 1: Modelo de um banco de dados hierárquico
Fonte: Adaptado de Hernandez (2000).
Segundo SENAC (1999, p. 17) “neste tipo de modelo é sempre feito no sentido
vertical, ou seja, irmãos não podem se „visitar‟ sem antes visitar o pai.”. Desta forma, se o
banco de dados contém informações que realmente constituam uma simples estrutura
hierárquica, o modelo hierárquico é perfeitamente adequado.
Hernandez (2000, p. 5) ainda destaca que: as vantagens deste tipo de banco de dados é
que o dado pode ser acessado rapidamente, devido as estruturas estarem conectadas. E a
integridade referencial é construída e automaticamente executada.
Porém segundo Elmasri e Navathe (2007, p. 15) e Hernandez (2000, p.6) este padrão
de bancos de dados tinha várias “deficiências”, como: dados redundantes, não suportava
relacionamentos complexos, não era possível armazenar um registro numa tabela-filha, que
não possuísse nenhuma conexão com nenhum registro da tabela-pai. Uma maneira de resolver
este problema era criar um registro “fantasma” na tabela-pai, para poder armazenar o registro
na tabela-filha. Entretanto isto causava o problema de ser ter registros falsos no banco de
dados, ou seja, dados inconsistentes; além de tudo isso, estes sistemas forneciam apenas
interfaces para a linguagem de programação, exigindo um profissional especializado neste
tipo de banco de dados, para realizar consultas simples e armazenar dados.
Já o modelo de dados em rede surgiu na tentativa de resolver alguns problemas do
modelo hierárquico e segundo Date (1990, p. 571) eles possuem basicamente uma única
diferença: “Na estrutura hierárquica, um registro-filho tem exatamente um pai; na estrutura de
rede um registro-filho pode ter qualquer número de pais (possivelmente zero).”.
11
Esquema 2: Modelo de um banco de dados em rede
Fonte: Hernandez (2000).
De acordo com Hernandez (2000, p. 7) através deste modelo o usuário podia acessar
os dados mais rapidamente e elaborar consultas mais complexas. Mas assim como no modelo
hierárquico era necessário que o usuário tivesse um alto nível de conhecimento sobre o banco
de dados, para poder “navegar” através das estruturas. Além disso, não era fácil mudar a
estrutura do banco de dados sem afetar as aplicações do programa que interage com ele.
2.2.2 O modelo relacional
O modelo relacional foi desenvolvido pelo pesquisador da IBM Dr. Edgar Frank
Codd, em junho de 1970 com a publicação do artigo “A Relational Model of Data for Large
Shared Data Banks” na revista “Communications of the ACM”. De acordo com Hernandez
(2000, p. 11) ele acreditava que aplicando disciplinas e estruturas matemáticas na
administração dos dados, para desconectar a estrutura lógica do banco de dados do método de
armazenamento físico, ajudaria a solucionar muitos dos problemas existentes nos outros
modelos de banco de dados.
De acordo com Date (1990, p. 100) “o banco de dados relacional é um banco visto
pelos usuários como um conjunto de tabelas (e nada além de tabelas).”. Manzano (2008, p.
15) ainda complementa que um banco de dados relacional (BDR) é composto de três
elementos básicos: o elemento campo, que é a menor unidade de armazenamento de um banco
de dados. Já o conjunto de campos, ou seja, o agrupamento de dados sobre um determinado
12
assunto chama-se registro. E o conjunto de registros forma uma tabela. Desta maneira, o
relacionamento entre várias tabelas é que forma o banco de dados.
Esquema 3: Modelo de um banco de dados relacional
Fonte: Adaptado de Machado e Abreu (1999).
O esquema acima mostra duas tabelas que fazem parte de um banco de dados
relacional, onde a tabela funcionários é utilizada para armazenar os dados dos funcionários de
uma determinada empresa e a tabela projetos mostra os projetos da mesma. A coluna
matrícula da tabela projetos identifica qual o funcionário responsável por determinado
projeto.
Date (1990, p. 327) destaca também a existência de três principais aspectos no modelo
relacional que o diferencia do modelo hierárquico e de rede:
• Estrutura dos dados (domínios e relações);
• Integridade dos dados (chaves primárias não podem ser nulos, valor da chave
estrangeira deve ser igual a chave primária ou nulos);
• Manipulação de dados (álgebra relacional, atribuição relacional);
Há muitas razões que fizeram o modelo relacional de banco de dados substituir o
modelo hierárquico e de rede. Nele é possível adicionar com facilidade novas tabelas em um
banco de dados, relacionando seus dados, sem afetar substancialmente a estrutura do banco de
dados e sem a necessidade de alterar os aplicativos que interagem com as tabelas. É possível
também alterar a estrutura de uma ou mais tabelas de maneira simples, inserindo ou excluindo
linhas e colunas sem comprometer a funcionalidade do banco de dados. (FERRARI, 2007, p.
9).
Quando o modelo relacional adotou a linguagem SQL (Structured Query Language)
que era a linguagem de consulta de dados mais utilizada no mundo e disponível para
praticamente todas as plataformas de hardware, desde mainframes até computadores portáteis.
O modelo relacional consolidou-se como o modelo mais famoso e utilizado, tornando-se
13
padrão para a maioria dos SGBDs, como nos mais utilizados atualmente o Oracle, SQL
Server, PostgreSQL e o MySQL. (BRITO, 2010, p. 1)
2.2.2.1 SQL (Structured Query Language)
A versão original do SQL foi desenvolvida pela IBM. Essa linguagem, era
originalmente chamada de Sequel, foi implementada como parte do projeto do Sistema R no
inicio dos anos 70. Desde então a linguagem Sequel foi evoluindo e seu nome mudado para
SQL (Linguagem de Consulta Estruturada - em português). (KORTH, SILBERSCHATZ,
SUDARSHAN, p. 109).
Date (1990, p. 107) define a linguagem SQL como sendo “tanto uma linguagem de
consulta interativa como uma linguagem de programação de banco de dados.”. E tem como
função facilitar o acesso a informações armazenadas em banco de dados relacionais, através
de consultas, atualizações, e manipulações de dados.
Segundo Oliveira (2002, p. 19) a linguagem SQL é composta por quatro grupos:
DML (Data Manipulation Language): permite a manipulação dos dados
armazenados no banco de dados. Possui os comandos: DELETE, INSERT e
UPDATE.
DDL (Data Definition Language): permite a criação dos componentes do
banco de dados. Principais comandossão: CREATE TABLE, ALTER TABLE,
DROP TABLE,CREATE INDEX, ALTER INDEX e DROP INDEX.
DCL (Data Control Language): provê a segurança interna do banco de dados.
Formado pelos comandos: CREATE USER, ALTER USER, GRANT,
REVOKE e CREATE SCHEMA.
DQL (Data Query Language): é formado apenas pelo comando SELECT. E
tem a função de extrair dados no banco de dados.
Segue um exemplo de um comando SQL (Listagem 1):
SELECT CODPRO, NOMPRO, DESDIS
FROM PROFESSOR, DISCIPLINA
WHERE PROFESSOR.CODDIS = DISCIPLINA.CODDIS
ORDER BY NOMPRO; Listagem 1: Lista de códigos do comando SELECT
Fonte: As autoras (2012).
14
Conforme o trecho SQL da listagem 1 seleciona-se o código, nome do professor e da
disciplina, e por fim, ordena os dados pelo nome do professor para emitir no relatório.
2.2.2.2 Banco de dados PostgreSQL
O programa PostgreSQL é um sistema de gerenciamento de banco de dados relacional
livre. Baseado no gerenciador de banco de dados POSTGRES, que foi desenvolvido Na
Universidade da Califórnia, em Berkely. (MANZANO, 2008, p. 19).
O PostgreSQL é um banco de dados de código aberto que possui os principais recursos
que existem no banco de dados pagos. Roda em todos os grandes sistemas operacionais,
incluindo GNU/Linux, Unix, e MS Windows. É totalmente compatível com ACID. Também
não tem limite de tamanho para seus bancos de dados, sua única limitação é a quantidade de
memória disponível pelo computador em que o PostgreSQL armazenará suas informações e a
quantidade máxima de 32 TB de dados por tabela. Possui funcionalidades sofisticadas como o
controle de concorrência multiversionado, replicação assíncrona, transações agrupadas
(savepoints), cópias de segurança a quente, um sofisticado planejador de consultas
(otimizador) e registrador de transações sequencial (WAL) para tolerância a falhas. É
altamente escalável, tanto na quantidade de dados que pode gerenciar, quanto no número de
usuários concorrentes. Possui interfaces nativas de programação para C/C++, Java, .Net, Perl,
Python, Ruby, Tcl, ODBC, entre outros. (MILANI, 2008).
2.2.2.3 Banco de dados Oracle
De acordo com Stroparo (2010) o Oracle é um banco de dados que surgiu no fim dos
anos 70, quando Larry Ellison vislumbrou uma oportunidade que até então, não havia sido
aproveitada por outras companhias, quando encontrou uma descrição de um protótipo
15
funcional de um banco de dados relacional e descobriu que nenhuma empresa se interessou
em comercializar essa tecnologia.
Os co-fundadores da Oracle Corporation, Bob Miner e Ed Oates, e Ellison perceberam
um tremendo potencial de negócios no modelo de banco de dados relacional, tornando-os
assim, a maior empresa de software empresarial do mundo. (STROPARO, 2010).
Segundo Proni (2012, p. 32), “O Oracle Database sempre foi conhecido como um
banco de dados robusto, escalável, sendo o líder do mercado em diversos segmentos, e o que
possui as funcionalidades mais avançadas.”.
2.2.3 Banco de dados orientados a objetos
De acordo com Sowek (c2009) os bancos de dados orientados a objetos começaram a
ser desenvolvidos na década de 80 como uma alternativa aos bancos de dados relacionais,
pois o padrão SQL não atendia algumas necessidades, como: herança.
Conforme Nassu, Setzer (1999) e Mansueli (2010, p. 6) um banco de dados orientado
a objetos é basicamente um sistema em que a unidade de armazenamento é o objeto, com o
mesmo conceito das linguagens de programação orientadas a objeto. Este modelo parte da
premissa de que, o que persiste são os objetos e, portanto, o seu “estado” é representado pelos
atributos. Os atributos são equivalentes aos campos, ou colunas de uma tabela e as
associações entre objetos podem ser comparados aos relacionamentos em banco de dados
relacionais.
Com o uso verificou-se que este modelo de bancos de dados não poderiam ser usados
para sistemas de missão crítica, tendo grande dificuldade de ser aceito pelo mercado. Por isso
é encontrado atualmente em poucas áreas, como em aplicações de CAD/CAE ou em
servidores de aplicações web para armazenar objetos persistentes. (SOWEK, c2009).
Porém segundo a Grehan (c2012), o modelo orientado a objeto é considerado o ideal
para aplicações embarcadas para dispositivos móveis, na qual exista um aplicativo que exija
um tempo de resposta super rápido ou banco de dados que possuam complexas relações de
objeto. Em tais aplicações, as classes podem definir várias referências cruzadas entre si.
16
2.2.4 Bancos de dados objeto-relacional
Os bancos de dados objetos-relacionais surgiram na década de 1990, como uma reação
dos principais fabricantes de bancos de dados relacionais aos bancos de dados orientados a
objetos. De acordo com Melo (2009) “nos bancos de dados objeto-relacionais, o banco
relacional tem uma parte transformada, além de receber a adição de novos recursos que
permitam implementações orientadas a objetos.”. De acordo com Dias Neto (2011, p.60)
esses novos recursos são: outros tipos de dados que permitem salvar dados de tipo
geoespaciais e mídias binárias diversas, como áudio, vídeo, imagem e applets em Java. Além
da possibilidade de navegar por objetos.
Dias Neto (2011, p.60) ainda destaca que apesar de os bancos de dados objeto-
relacionais serem uma tecnologia em crescimento e serem capaz de executar operações
analíticas complexas, e de manipular dados para buscar e transformar objetos multimídias e
de outros tipos. Este padrão ainda não é bem aceito no mercado, por não serem largamente
adotados e possuir base de experiência pequena.
Alguns bancos objeto-relacionais atuais são: Oracle, PostgreSQL, MySQL, Informix,
DB2, Cachê e SQLServer.
2.3 SISTEMAS GERENCIADORES DE BANCOS DE DADOS
É comum pessoas confundirem banco de dados com sistemas gerenciadores de banco
de dados, acreditando que os dois são iguais ou que eles possuem a mesma função.
O SGBD, ou Sistema de Gerenciamento de Banco de Dados é para Rezende (2006):
Um software que possui recursos capazes de manipular as informações do
banco de dados e interagir com o usuário. [...] 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.
A seguir um exemplo de funcionamento de um sistema gerenciador de banco de
dados:
17
Esquema 4: Função do SGBD
Fonte: Rezende (2006).
De acordo com SENAC (1999, p.38) o SGBD é também antes de tudo um facilitador da
localização dos dados. Todas as solicitações dos usuários para acesso ao banco de dados são
manipuladas pelo SGBD, desta forma, o usuário não acessa diretamente as informações, eles
fazem requisições ao SGBD e este recupera as informações no disco. Isso garante que o
acesso aos dados tenha um nível de segurança satisfatório, pois o usuário não acessa
fisicamente o arquivo, o que poderia causar perdas às vezes irreparáveis. Utilizando um
SGBD consegue-se também um controle centralizado dos dados. Algumas vantagens desta
centralização são:
Compartilhamento de dados;
Aplicação de restrições de segurança;
A redundância dos dados pode ser reduzida;
Dados inconsistentes podem ser evitados;
Controle de acessos ao banco de dados;
A integridade dos dados pode ser mantida;
Com o surgimento dos SGBD‟s, surgiu também a necessidade de um profissional que
pudesse dar suporte, ou seja, instalar, configurar, monitorar e solucionar problemas de um
SGBD, o administrador de banco de dados.
18
2.3.1 O administrador de banco de dados
Segundo Rodrigues Júnior (2006) e Korth, Silberschatz e Sudarshan (1999, p. 14) o
administrador de banco de dados (ABD), é o profissional responsável por:
Criar o projeto lógico do banco de dados: criação do esquema usando a DDL;
Controlar os acessos ao banco de dados e definição do nível de privilégio dos
usuários;
Definir a estrutura de armazenamento e método de acesso;
Projeto físico da base de dados;
Definição de procedimentos de recuperação (backup);
Monitoração do desempenho;
Especificar as regras de integridade;
Ajustes apropriados à medida que ocorram mudanças de requisitos;
“Administrar um banco é diferente de projetar lógica e conceitualmente um banco. A
administração deve prever a utilização do SGBD ao longo de vários anos, garantindo a
ausência de problemas físicos futuros que impeçam a disponibilidade dos dados.”
(RODRIGUES JÚNIOR, 2006).
2.4 BANCOS DE DADOS NOSQL
O termo NoSQL é uma abreviação de “Not Only SQL”, ou seja “Não Somente SQL”.
De acordo com Nascimento (2010) o termo surgiu em 1998, para denominar os bancos de
dados relacionais de código aberto que não possuíam uma interface SQL. Em 2009, o termo
NoSQL passou a ser utilizado para descrever banco de dados de código aberto, não
relacionais e que fossem projetados para armazenamento distribuído de dados. Segundo
Bogoni (2011, p. 41) o NoSQL é uma “novidade que vem ganhando destaque nos últimos
meses e que promete alcançar, com qualidade, um alto número de aplicações, propondo
soluções mais adequadas que os banco de dados relacionais”.
NoSQL é um modelo de banco de dados que surgiu como uma solução alternativa aos
bancos de dados relacionais, devido a dificuldade que algumas empresas tinham de tornar
19
seus bancos de dados mais escaláveis, devido ao alto custo e complexidade.
Bogoni (2011, p. 41), ressalta que para aumentar a performance e a escalabilidade,
banco de dados NoSQL não suportam as propriedades Atomicidade, Consistência, Isolamento
e Durabilidade (ACID), que são um padrão nos bancos de dados relacionais.
Segundo Porcelli (2011, p. 25) e Tiwari (2011), atualmente os banco de dados NoSQL
podem ser divididos em quatro tipos diferentes com relação aos modelos de dados:
Chave/Valor
Este modelo de dados é muito parecido com a estrutura do java.util.Map e usa
uma tabela “hash” na qual há uma chave única e um indicador de um dado ou
um valor de um item em particular. O modelo chave-valor é o mais simples e
fácil de implementar.
Esquema 5: Modelo de armazenamento em forma de chave/calor
Fonte: Adaptado de Porcelli (2011).
Neste exemplo, a chave é quantidade tweets:porcelli e o seu valor é 5000.
Documento
É similar ao armazenamento do tipo chave/valor. Com a diferença que bases de
dados de documentos permitem tratar um documento como um todo e não
dividir um documento em seus constituintes pares de chave/valor. O que
permite a elaboração de um conjunto diversificado de documentos em uma
única coleção. A indexação de documentos é feita com base não apenas em seu
identificador primário, mas também em suas propriedades. No esquema a
seguir, pode-se observar como são armazenados os dados neste modelo.
Listagem 2: Modelo de armazenamento em forma de documento
Fonte: Adaptado de Porcelli (2011).
20
Entre as companhias que usam bancos de dados com este modelo de
armazenamento encontramos: Shutterfly, Evite e The New York Times.
Grafo
O modelo orientado a grafos possui três componentes básicos: os nós (são os
vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou
atributos) dos nós e relacionamentos. Neste caso, o banco de dados pode ser
visto como um multigrafo rotulado e direcionado, onde cada par de nós pode
ser conectado por mais de uma aresta.
Esquema 6: Modelo de armazenamento em forma de grafo
Fonte: Adaptado de Porcelli (2011).
Este modelo é muito parecido com o modelo hierárquico e é bastante utilizado
em redes sociais, para armazenar as relações de amizades e seguidores.
Colunas
Este modelo foi desenvolvido para armazenar e processar grandes quantidades
de dados distribuídos em muitas máquinas. Ainda existem chaves, mas elas
apontam para colunas múltiplas. As colunas são organizadas por família da
coluna. O armazenamento em coluna permite que os dados sejam armazenados
de forma eficaz. Evita consumir espaço ao armazenar valores nulos por
simplesmente não armazenar uma coluna quando um valor não existe para essa
coluna.
21
Esquema 7: Modelo de armazenamento em forma de colunas
Fonte: Adaptado de Porcelli (2011).
O banco de dados mais conhecido que segue este modelo de armazenamento é o
Apache Cassandra.
2.4.1 Apache Cassandra
Desenvolvido inicialmente pelo Facebook, ele foi liberado sob licença open source em
2008, sendo atualmente mantido pela Fundação Apache e colaboradores. Projetado em Java
ele vem sendo apontado como um excelente banco de dados, e segundo Apache Software
Foundation (c2009) o Cassandra está em uso atualmente pelo Netflix, Twitter, Dirigível
Urbano, Contato Constante, Reddit, Cisco, OpenX, Digg, CloudKick, Ooyala, e mais
empresas que têm grandes conjuntos de dados ativos. O maior aglomerado conhecido do
Cassandra tem mais de 300 TB de dados em mais de 400 máquinas.
Segundo Hewitt (2011, XVII) e Apache Software Foundation (c2009) o banco de
dados Apache Cassandra é uma fonte livre e aberta, com armazenamento de dados distribuído
e encontra-se atualmente na versão 1.1.0.
22
Esquema 8: Modelo de dados do Apache Cassandra
Fonte: DataStax (c2012a).
No modelo acima tem-se um exemplo de como é o banco de dados Cassandra. Onde o
keyspace é o contêiner para os dados do aplicativo, semelhante a um banco de dados
relacional. Dentro do keyspace vão um ou mais objetos de coluna de família, que são análogas
às tabelas. E um conjunto de colunas relacionadas é identificado por uma chave. Cada linha
de uma família da coluna não é necessária para se ter o mesmo conjunto de colunas.
Cassandra não tem relações entre as famílias de colunas da mesma forma que os bancos de
dados relacionais tem entre as tabelas: não há chaves estrangeiras em Cassandra, desta forma
não é possível unir famílias de colunas em tempo de consulta. (DATASTAX, c2012a).
De acordo com Apache Software Foundation (2011) o Cassandra possui as seguintes
vantagens:
Alta disponibilidade e durabilidade;
23
Suporte para replicação de dados em vários datacenters (clusterização);
Escalabilidade incremental;
Eventual consistência;
Compensações entre consistência ajustáveis e latência;
Administração mínima;
Não há pontos únicos de falha. Cada nó do cluster é idêntico.
Ainda segundo Apache Software Foundation (2012) algumas das limitações são:
Todos os dados de uma única linha devem caber (em disco) em uma única
máquina no cluster. Porque as chaves de linhas sozinhas são usadas para
determinar os nós responsáveis por replicar os seus dados, a quantidade de
dados associados com uma única chave tem este limite superior;
Um valor de coluna única que não pode ser maior que 2 GB. (No entanto,
grandes valores são lidos para a memória quando solicitado, então, na prática
"pequeno número de MB" é mais apropriado.);
O número máximo de colunas por linha é de 2 bilhões;
A chave (e nomes de colunas) deve ter no máximo 64 KB.
De acordo com Bogoni (2011, p. 41), o Cassandra chamou ainda mais atenção quando
o Twitter comunicou que estaria migrando sua base dados do MySQL para o Cassandra.
Devido a dificuldade que o MySQL tinha em lidar com a leitura e escrita de grandes
quantidades de dados, como os 7 TB produzidos por dia pelo Twitter.
Em entrevista ao blog MyNoSQL o engenheiro do Twitter, Ryan King informou que
foram analisadas diversas opções para atualizar seu sistema, incluindo a rearquitetura do
MySQL para que pudesse rodar melhor em cluster, e as ofertas de diversos rivais do
Cassandra, como HBase, Voldemort, MongoDB, MemCacheDB, Redis e HyperTable. Porém,
após a realização de testes, o Cassandra demonstrou-se mais escalável, confiável, altamente
disponível e fácil de gerenciar do que as outras alternativas. Além de possuir uma grande
comunidade de desenvolvedores de código aberto para o Cassandra. (POPESCU, 2010).
2.4.4.1 Ferramentas de administração
De acordo com Apache Cassandra (c2009), atualmente existem duas ferramentas para
24
administração deste banco de dados, que são: DataStax OpsCenter e Cassandra Cluster
Admin.
DataStax OpsCenter é uma solução web que usa uma arquitetura baseada em agentes
para gerenciar, monitorar e realizar as tarefas em cada nó em um cluster empresarial ou
DataStax Cassandra e é oferecido em duas edições:
OpsCenter Community Edition - projetado para gerenciar e monitorar clusters
de banco de dados Apache Cassandra. OpsCenter Community Edition é
totalmente gratuito para download.
OpsCenter Enterprise Edition - projetado para gerenciar e monitorar
implementações corporativas DataStax, que incluem o Apache Cassandra,
Apache Hadoop e Apache Solr. OpsCenter Enterprise Edition contém
funcionalidade de gerenciamento avançado e é incluído como parte de uma
assinatura da empresa DataStax. (DATASTAX, c2012b).
De acordo com GitHub (c2012) Cassandra Cluster Admin é uma ferramenta gráfica gratuita
para administrar clusters no Apache Cassandra, semelhante ao PHP MyAdmin para
administração do MySQL. Com ele é possível criar, editar e excluir keyspaces e famílias de
colunas, exibir uma linha, procurar dados e inserir linhas. Porém por se encontrar ainda
numa versão beta não é indicado para implementações corporativas.
2.5 JAVA
De acordo com Furgeri (2005, p.17) a linguagem Java começou a ser desenvolvida em
1993, para ser utilizada em pequenos dispositivos eletrônicos inteligentes, porém devido a
dificuldade de financiamento de projetos nesta área e com o surgimento da Internet, a Sun
ampliou o projeto. Desta forma, Java deixou de ser apenas uma linguagem de programação e
se tornou também uma plataforma de desenvolvimento.
Segundo Mendes (2009, p. 17) e Furgeri (2005, p.17) desde 2006 até os dias atuais,
Java não para de crescer, por representar uma linguagem simples, orientada a objetos,
portável, neutra de arquitetura, segura, multithread, interpretada, possui suporte à
comunicação, acesso remoto a banco de dados e oferece alto desempenho.
25
2.6 ENGENHARIA DE SOFTWARE
Sommerville (2004, p. 5) define engenharia de software como “uma disciplina da
engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios
iniciais de especificação do sistema até a manutenção desse sistema, depois que ele entrou em
operação.”.
Engenheiros de software utilizam muito o modelo de desenvolvimento incremental
para o desenvolvimento do software.
2.6.1 Ciclo de vida incremental
De acordo com Sommerville (2004, p.43), o modelo de desenvolvimento incremental
é bastante utilizado por ser um modelo simples de gerenciamento, e sua separação de projeto
e implementação devem levar a sistemas robustos, que são suscetíveis a mudanças.
Este modelo foi proposto por Mills (esquema 9), em 1980 como uma forma de reduzir
o retrabalho no processo de desenvolvimento e de permitir aos clientes a possibilidade de
utilizar o software antes de ele ser totalmente finalizado.
Esquema 9: Modelo de desenvolvimento incremental
Fonte: Sommerville (2004).
Ainda segundo Sommerville (2004, p.43) como pode-se observar no esquema 9,
primeiramente os clientes identificam em um esboço, as funções necessárias do sistema e
quais delas são as mais importantes, para saber qual função vai ser incrementada
primeiramente. Depois são definidos quais os requisitos para implementação de cada um dos
26
incrementos ou funções e projetada a arquitetura do sistema. Após inicia-se o processo de
desenvolvimento do incremento considerado mais importante. Assim que ele for validado,
este incremento é integrado ao sistema e entregue a cliente. Permitindo desta forma, que o
cliente teste o incremento antes do sistema ficar completamente pronto, identificando falhas
ou a necessidade de novas funcionalidades. Este processo repete-se até que todos os
incrementos sejam integrados ao sistema. Uma grande vantagem deste modelo é que a
funcionalidade do sistema melhora a cada novo incremento que é entregue.
2.6.2 Diagramas UML
De acordo com Pender (2004, p. 3) a UML (Unified Modeling Language) surgiu em
1994 e desde então tem sido adotada por empresas do mundo inteiro. Pois ela permite que
desenvolvedores de sistemas especifiquem, visualizem e documentem os modelos de maneira
a permitir o desenvolvimento de softwares possuam um maior nível de segurança,
escalabilidade e execução robusta. A modelagem UML também facilita a identificação de
padrões de comportamento e, portanto, o aumento da possibilidade de recriação e reuso de
projetos. Consequentemente, a modelagem UML facilita a criação de projetos modulares,
resultando em componentes e bibliotecas de componentes que agilizam o desenvolvimento e
ajudam a garantir a coerência através de sistemas e implementações.
Para Pender (2004) a modelagem UML usa vários diagramas para modelar o sistema,
porém, os mais importantes e que serão utilizados no CAdmin Tool são: diagrama de caso de
uso, diagrama de classes, diagrama de implantação e diagrama de sequencia.
Diagrama de casos de uso
Este diagrama serve para modelar as expectativas dos usuários com relação ao
sistema, mas não revela qualquer detalhe sobre a implementação desses
recursos. As pessoas que interagem com o sistema alvo são chamadas de
atores. Os recursos do sistema que os atores utilizam são chamados de casos de
uso.
Diagrama de classes
Serve para modelar as definições de recursos essenciais à operação correta do
sistema. Este modelo é a origem para a geração do código, ou seja, é usado
para converter o modelo em código; e o destino para a engenharia reversa
(conversão do código em modelo).
27
Diagrama de implantação
É usado para modelar o hardware do ambiente de implementação. Cada nó do
diagrama representa um tipo de hardware, como uma unidade de disco, um
servidor, processador ou um computador cliente. Com este diagrama é possível
identificar como o hardware afeta o desempenho e a configuração do software.
Diagrama de sequência
O foco do diagrama está na identificação de interações entre os objetos com o
tempo, ajudando a identificar as mensagens entre os objetos. Essas trocas de
mensagem exigem um transmissor e um receptor, onde o receptor precisa de
uma interface para poder receber a mensagem. Este diagrama ajuda a localizar
e documentar novas operações do diagrama de classes.
Desta maneira é possível organizar o processo de desenvolvimento do software,
tornando mais fácil a identificação dos recursos necessários, a codificação do sistema, e a
realização e finalização do projeto dentro do prazo.
28
3 MATERIAIS E MÉTODOS
Por tratar-se de um projeto acadêmico e sem cunho comercial, para o desenvolvimento
do CAdmin Tool todas as funções cabíveis no processo de desenvolvimento serão
desempenhadas pelas acadêmicas. Os testes do software serão realizados com usuários
potenciais dentro do público alvo escolhido, a ferramenta CAdmin Tool será disponibilizada
através do blog desenvolvido pelas próprias acadêmicas.
Para a execução deste projeto, as informações e conhecimentos necessários serão
extraídos por meio de pesquisa bibliográfica, a qual indicará possibilidades e fornecerá
referencial teórico para a parte prática.
Os requisitos de hardware para o desenvolvimento do trabalho não exigem alto poder
de processamento, nem de memória, desta forma, não será necessária a compra de nenhum
hardware para o desenvolvimento do projeto.
Após a pesquisa teórica e tendo posse do hardware necessário, o CAdmin Tool
começará a ser codificado, seguindo as especificações prévias. O desenvolvimento da
ferramenta acontecerá em duas etapas. A primeira etapa visa a definição das funcionalidades
que o software possuirá e a ordem em que elas serão implementadas utilizando o ciclo de vida
incremental, onde divide-se inicialmente em três principais etapas: desenvolver classes de
interação com a API do Cassandra; desenvolver camada intermediária e desenvolver parte
web, juntamente coma produção dos diagramas de classe, de implantação, de sequência e de
casos de uso.
A segunda visa a codificação da ferramenta, através da implementação das
funcionalidades do software. Ao final desta etapa, ocorrerão testes com o público alvo
visando encontrar problemas e/ou falhas no software, para que estas possam ser corrigidas em
tempo hábil e implementar sugestões de melhoria.
Para desenvolvimento do projeto também serão utilizadas ferramentas free, como as
IDE‟s, NetBeans ou Eclipse, programando a aplicação utilizando Java ou PHP. Serão
realizados alguns testes no momento de configurar o ambiente de desenvolvimento para
avaliar a linguagem mais apropriada.
29
4 CRONOGRAMA DE EXECUÇÃO
Abaixo, apresenta-se o cronograma que regerá as atividades relativas ao
desenvolvimento do CAdmin Tool:
Atividades
Meses
2012 2013
Jul Ago Set Out Nov Dez Jan Fev Mar Abr Mai Jun
Revisão bibliográfica
Configuração do ambiente
de desenvolvimento
Desenvolvimento/Manutenç
ão do blog
Coleta e análise de requisitos
Modelagem dos diagramas
Codificação do CAdmin Tool
Verificação de erros
Validação com usuários
Elaboração do artigo
Elaboração da monografia
30
REFERÊNCIAS
BRITO, Ricardo W. Bancos de dados NoSQL x SGBDs Relacionais: Análise Comparativa.
2010. Disponível em:<http://www.infobrasil.inf.br/userfiles/27-05-S4-1-
68840bancos%20de%20Dados%20NoSQL.pdf> Acesso em: 22 maio 2011.
BOGONI, Leandro Paulo. Por dentro do movimento NoSQL: conhecendo o projeto Apache
Cassandra. SQL Magazine, ano 7, n. 83, p. 41-47, jan. 2011.
DATASTAX. Apache Cassandra 1.0 Documentation: The Cassandra Data Model. San
Mateo: DataStax, c2012a. Disponível em: <http://www.datastax.com/docs/1.0/ddl/about-data-
model>. Acesso em: 23 maio 2012.
DATASTAX. O que é DataStax OpsCenter?. San Mateo: DataStax, c2012b. Disponível
em: < http://www.datastax.com/products/opscenter>. Acesso em: 23 maio 2012.
DATE, Chris J. Introdução a sistemas de bancos de dados. 9. ed. Rio de Janeiro: Campus,
1990. 674 p.
DIAS NETO, Arilo Claudio. Banco de Dados Relacionais: uma visão geral sobre o assunto.
SQL Magazine, Grajaú: Fernando Chinaglia Distribuidora, v. 7, n. 86, p. 55-61, abr. 2011.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 4. ed. São
Paulo: Addison Wesley Longman, 2007. 724 p.
FERRARI, Fabrício Augusto. MySQL: Desvende os recursos desta poderosa ferramenta. São
Paulo: Digerati Books, 2008. 128 p.
FURGERI, Sérgio. Java 2: Ensino Didático. São Paulo: Érica, 2005. 371 p.
GITHUB. Cassandra Cluster Admin. GitHub: San Francisco, c2012. Disponível em: <
https://github.com/sebgiroux/Cassandra-Cluster-Admin>. Acesso em: 23 maio 2012.
GREHAN, Rick. When to Use an ODBMS. Hauptstrasse, c2012. Disponível em:
<http://www.odbms.org/Introduction/whenODBMS.aspx>. Acesso em:13 maio 2012.
HERNANDEZ, Michael J. Apreenda a projetar seu próprio banco de dados. Makron
Books, 2000.411 p.
31
HEWITT, Eben. Cassandra: The Definitive Guide. Sebastopol: O‟Reilly Media, 2010. 330 p.
KORTH, Henry F.; SILBERSCHATZ, Abraham; SUDARSHAN, S. Sistema de banco de
dados. 3. ed. São Paulo: Makron Books, 1999.
MACHADO, Felipe; ABREU, Maurício. Projeto de Banco de Dados: Uma Visão Prática. 5.
ed. São Paulo: Érica, 1999. 298 p.
MANSUELI, Victor Alexandre Ploeger. Banco de Dados Orientados a Objetos: Conheça os
benefícios de sua utilização. Revista SQL Magazine, Grajaú: Fernando Chinaglia
Distribuidora, v. 7, n. 78, p. 6-13, ago. 2011.
MANZANO, José Augusto N. G. PostgreSQL 8.3.0 interativo: guia de orientação e
desenvolvimento para Windows. São Paulo: Érica, 2008. 240 p.
MELO, Ana Cristina. Usando Banco de Dados Objeto-Relacionais. Engenharia de
Software, Grajaú, 2009. Disponível em:
<http://www.devmedia.com.br/space.asp?id=208126>. Acesso em: 22 abr. 2012.
MENDES, Douglas Rocha. Programação Java: Com Ênfase em Orientação a Objetos. São
Paulo: Novatec, 2009. 463 p.
MICHAELIS. Dicionário Online Michaelis UOL 2012. Disponível em:
<http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-
portugues&palavra=dado>. Acesso em: 27 fev. 2012.
MILANI, André. PostgreSQL: guia do programador. São Paulo: Novatec, 2008. 392 p.
NASSU, Eugênio A.; SETZER, Valdemar W. Bando de dados orientado a objetos. São
Paulo: Edgard Blucher, 1999. 122 p.
OLIVEIRA, Celso Henrique Poderoso de. SQL: Curso Prático. São Paulo: Novatec, 2002.
272 p.
PENDER, Tom. UML: a Bíblia. Rio de Janeiro: Campus, 2004. 711 p.
POPESCU, Alex. Cassandra @ Twitter: uma entrevista com Ryan King. Disponível em:
32
<http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-
king>. Acesso em: 02 maio 2012.
PORCELLI, Alexandre. O que é NoSQL?: Uma visão geral sobre o buzzword do momento –
parte 1. Revista Java Magazine, Grajaú: Fernando Chinaglia Distribuidora, v. 7, n. 86, p. 24-
29, jan. 2011.
PRONI, Ricardo Portilho. Oracle Database no Solaris – Parte 2. Revista SQL Magazine,
Grajaú: Fernando Chinaglia Distribuidora, v.8, n. 95, p. 32-40, jan. 2012.
REZENDE, Ricardo. Conceitos Fundamentais de Banco de Dados – Parte II. Grajaú:
Fernando Chinaglia Distribuidora, 20 abr. 2006. Disponível em:
<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados-parte-2/1678>.
Acesso em: 14 abr. 2012.
RODRIGUES JUNIOR, Methanias Colaço. Exigências para uma boa Administração de
Banco de Dados. Grajaú: Fernando Chinaglia Distribuidora, 24 maio 2006. Disponível em:
<http://www.devmedia.com.br/exigencias-para-uma-boa-administracao-de-banco-de-
dados/1916>. Acesso em: 21 abr. 2012.
ROSSI, Diego. NoSQL – Uma opção real aos bancos relacionais: conhecendo um pouco mais
sobre o MongoDB. SQL Magazine, Grajaú: Fernando Chinaglia Distribuidora, ano 8, n. 95,
p. 6-12, jan. 2012.
SENAC. Princípios de banco de dados. Rio de Janeiro: Senac Nacional, 1999. 64 p.
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Pearson Education, 2004.
592 p.
SORDI, José Osvaldo de. Administração da informação: fundamentos e práticas para uma
nova gestão do conhecimento. São Paulo: Saraiva, 2008. 185 p.
SOWEK, Carlos Alberto. Banco de dados, uma retrospectiva. Disponível em:
<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=1364>. Acesso
em: 18 abr. 2012.
STROPARO, Elder. História Oracle. Disponível em:
<http://elderstroparo.blogspot.com.br/2010/01/historia-oracle.html>. Acesso em: 02 maio
2012.
33
THE APACHE SOFTWARE FOUNDATION. Cassandra Wiki: ArchitectureOverview.
Forest Hill. Apache Software Foundation, 2011. Disponível em:
<http://wiki.apache.org/cassandra/ArchitectureOverview>. Acesso em: 08 maio 2012.
THE APACHE SOFTWARE FOUNDATION. Cassandra Wiki: CassandraLimitations.
Forest Hill. Apache Software Foundation, 2012. Disponível em:
<http://wiki.apache.org/cassandra/CassandraLimitations>. Acesso em: 11 maio 2012.
THE APACHE SOFTWARE FOUNDATION. Welcome to Apache Cassandra: Forest Hill.
Apache Software Foundation, c2009. Disponível em: <http://cassandra.apache.org/>. Acesso
em: 11 maio 2012.
TIWARI, Shashank. Professional NoSQL. Indianapolis: John Wiley& Sons, 2011. 361 p.
34
DECLARAÇÃO
Declaro ter ciência do conteúdo do presente projeto e concordar com sua apresentação a
banca examinadora do TCC I.
_______________________________________
Eliane Mara Casagrande
_______________________________________
Jésika Pellegrini
_______________________________________
Roberson Junior Fernandes Alves
São Miguel do Oeste, 29 de maio de 2012.