Sei sulla pagina 1di 143
Prof. Me. Edson Yanaga BANCO DE DADOS grADuAçãO ANáliSE E DESENvOlvimENtO DE SiStEmAS SiStEmAS pArA

Prof. Me. Edson Yanaga

BANCO DE DADOS

grADuAçãO

ANáliSE E DESENvOlvimENtO DE SiStEmAS

SiStEmAS pArA iNtErNEt

mAriNgá-pr

2012

reitor: Wilson de Matos Silva vice-reitor: Wilson de Matos Silva Filho pró-reitor de Administração: Wilson

reitor: Wilson de Matos Silva vice-reitor: Wilson de Matos Silva Filho pró-reitor de Administração: Wilson de Matos Silva Filho presidente da mantenedora: Cláudio Ferdinandi

NEAD - Núcleo de Educação a Distância

Diretoria do NEAD: Willian Victor Kendrick de Matos Silva Coordenação pedagógica: Gislene Miotto Catolino Raymundo Coordenação de marketing: Bruno Jorge Coordenação Comercial: Helder Machado Coordenação de tecnologia: Fabrício Ricardo Lazilha Coordenação de Curso: Danillo Xavier Saes Supervisora do Núcleo de produção de materiais: Nalva Aparecida da Rosa Moura Capa e Editoração: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, José Jhonny Coelho, Luiz Fernando Rokubuiti e Thayla Daiany Guimarães Cripaldi Supervisão de materiais: Nádila de Almeida Toledo revisão textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janaína Bicudo Kikuchi, Jaquelina Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.

Ficha catalográfica elaborada pela Biblioteca Central - CESUMAR

CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a distância:

C397

Banco de dados / Edson Yanaga. Maringá - PR, 2012. 143 p.

“Graduação em Análise e Desenvolvimento de Sistemas e Sistemas para Internet - EaD”.

1. Banco de dados. 2. Arquitetura de sistemas. 3.EaD. I. Título.

CDD - 22 ed. 005.74 CIP - NBR 12899 - AACR/2

“As imagens utilizadas neste livro foram obtidas a partir dos sites pHOtOS.COm e SHuttErStOCK.COm”.

Av. Guedner, 1610 - Jd. Aclimação - (44) 3027-6360 - CEP 87050-390 - Maringá - Paraná - www.cesumar.br NEAD - Núcleo de Educação a Distância - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br

BANCO DE DADOS

Prof. Me. Edson Yanaga

BANCO DE DADOS Prof. Me. Edson Yanaga

AprESENtAçãO DO rEitOr

AprESENtAçãO DO rEitOr Viver e trabalhar em uma sociedade global é um grande desafio para todos
AprESENtAçãO DO rEitOr Viver e trabalhar em uma sociedade global é um grande desafio para todos

Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos.

A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para

liderança e solução de problemas com eficiência tornou-se uma questão de sobrevivência no mundo do trabalho.

Cada um de nós tem uma grande responsabilidade: as escolhas que fizermos por nós e pelos nossos fará grande diferença no futuro.

Com essa visão, o Cesumar – Centro Universitário de Maringá – assume o compromisso de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos brasileiros.

No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento

de uma sociedade justa e solidária” –, o Cesumar busca a integração do ensino-pesquisa-ex-

tensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que

contribua para o desenvolvimento da consciência social e política e, por fim, a democratização

do conhecimento acadêmico com a articulação e a integração com a sociedade.

Diante disso, o Cesumar almeja ser reconhecido como uma instituição universitária de referên- cia regional e nacional pela qualidade e compromisso do corpo docente; aquisição de compe- tências institucionais para o desenvolvimento de linhas de pesquisa; consolidação da extensão universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação

da comunidade interna; qualidade da gestão acadêmica e administrativa; compromisso social

de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também pelo compromisso e relacionamento permanente com os egressos, incentivando a educação continuada.

Professor Wilson de Matos Silva Reitor

Caro(a) aluno(a), “ ensinar não é transferir conhecimento, mas criar as possibilidades para a sua

Caro(a) aluno(a), “ensinar não é transferir conhecimento, mas criar as possibilidades para a sua produção ou a sua construção” (FREIRE, 1996, p. 25). Tenho a certeza de que no Núcleo de Educação a Distância do Cesumar, você terá à sua disposição todas as condições para se fazer um competente profissional e, assim, colaborar efetivamente para o desenvolvimento da realidade social em que está inserido.

Todas as atividades de estudo presentes neste material foram desenvolvidas para atender o seu processo de formação e contemplam as diretrizes curriculares dos cursos de graduação, determinadas pelo Ministério da Educação (MEC). Desta forma, buscando atender essas necessidades, dispomos de uma equipe de profissionais multidisciplinares para que, independente da distância geográfica que você esteja, possamos interagir e, assim, fazer-se presentes no seu processo de ensino-aprendizagem-conhecimento.

Neste sentido, por meio de um modelo pedagógico interativo, possibilitamos que, efetivamente, você construa e amplie a sua rede de conhecimentos. Essa interatividade será vivenciada especialmente no ambiente virtual de aprendizagem – AVA – no qual disponibilizamos, além do material produzido em linguagem dialógica, aulas sobre os conteúdos abordados, atividades de estudo, enfim, um mundo de linguagens diferenciadas e ricas de possibilidades efetivas para

a sua aprendizagem. Assim sendo, todas as atividades de ensino, disponibilizadas para o seu

processo de formação, têm por intuito possibilitar o desenvolvimento de novas competências

necessárias para que você se aproprie do conhecimento de forma colaborativa.

Portanto, recomendo que durante a realização de seu curso, você procure interagir com os textos, fazer anotações, responder às atividades de autoestudo, participar ativamente dos fóruns, ver as indicações de leitura e realizar novas pesquisas sobre os assuntos tratados,

pois tais atividades lhe possibilitarão organizar o seu processo educativo e, assim, superar os desafios na construção de conhecimentos. Para finalizar essa mensagem de boas-vindas, lhe estendo o convite para que caminhe conosco na Comunidade do Conhecimento e vivencie

a oportunidade de constituir-se sujeito do seu processo de aprendizagem e membro de uma comunidade mais universal e igualitária.

Um grande abraço e ótimos momentos de construção de aprendizagem!

Professora Gislene Miotto Catolino Raymundo

Coordenadora Pedagógica do NEAD- CESUMAR

AprESENtAçãO

livro: BANCO DE DADOS

Professor Me. Edson Yanaga

livro : BANCO DE DADOS Professor Me. Edson Yanaga Salve, caríssimo(a) leitor(a). Tenho um enorme prazer

Salve, caríssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco de Dados, elaborado especificamente para contribuir na sua formação de futuro(a) desenvolvedor(a) de software. Sou o Professor Edson Yanaga, autor deste livro. Espero que você tenha um bom proveito do material.

Permita-me apresentar-me adequadamente: sou Bacharel em Ciência da Computação pela Universidade Estadual de Maringá (UEM) e Mestre em Engenharia Elétrica e Informática Industrial pela Universidade Tecnológica Federal do Paraná (UTFPR) na área de Telemática.

Sou empresário (consultor e desenvolvedor) na área de software e trabalho com a plataforma Java desde 1997 – completando 15 anos de experiência neste ano de 2012. Trabalho também como administrador de sistemas Unix (Solaris, HP-UX e Linux) desde 2000, e desde 2008

já era adepto e entusiasta da computação em nuvem (cloud computing). Participo de vários

cursos em nível de especialização em diversas instituições, como Cesumar, UEM, UNIPAR

e Faculdade Integrado; e sou coordenador do curso de Especialização em Desenvolvimento

Orientado a Objetos em Java do Cesumar desde 2004. Possuo as seguintes certificações:

Oracle Certified Professional, Java Platform, Enterprise Edition 6 Enterprise JavaBeans Developer; Certified ScrumMaster; Sun Certified Developer for Java Web Services 5; Sun Certified Specialist for NetBeans IDE; Sun Certified Web Component Developer for J2EE 1.4; e Sun Certified Programmer for Java 2 Platform 1.4. Como líder do Redfoot JUG (Java Users Group) – Grupo de Usuário Java do Norte do Paraná – atuo desde 2004. Tive o prazer de ser membro do comitê técnico do JavaOne Latin America nas edições de 2010 e 2011. Apresento palestras em diversos eventos em nível nacional e internacional, e ultimamente sou um grande entusiasta do Artesanato de Software e do código bem-feito.

Confesso que foi um tremendo desafio escrever este material. Até certo ponto é uma repetição cansativa dizer que o ritmo das mudanças e inovações cada vez mais se acelera, mas a princípio o tema “banco de dados” aparentaria ser algo tranquilo pelo fato de ser uma área do conhecimento bastante consolidada. Ledo engano. Nos últimos cinco anos, a disciplina de banco de dados passou por profundas transformações que chacoalharam os alicerces de fundamentos criados e utilizados desde a década de 1970. Os desafios dos sistemas de

informação atuais exigem que manipulemos não gigabytes ou terabytes de informações, e sim petabytes ,

informação atuais exigem que manipulemos não gigabytes ou terabytes de informações, e sim petabytes, exabytes e zetabytes.

Sistemas de informação das gerações anteriores tinham como objetivo gerar informações que pudessem agregar valor aos processos de negócios. Pois bem, esse objetivo foi alcançado. Com a tão aguardada e estimulada onipresença de software, a magnitude destas informações geradas cresceu. Redes sociais, smartphones, tablets, sensores de automação e vários outros dispositivos geram inúmeros bits de informação a todo momento. Conceitos antigos já não são soberanos nesses ambientes inóspitos atuais. Diante destes cenários surgiram os conceitos de Big Data e NoSQl.

Mas para irmos longe e chegarmos a este ponto, devemos dar o primeiro passo. Este material aborda os conceitos que até recentemente eram considerados como as “regras sagradas” de banco de dados: os bancos de dados relacionais. E não se engane, caro(a) leitor(a), estes fundamentos de bancos de dados relacionais são imprescindíveis para que se possa dar o “próximo passo” rumo ao conhecimento de Big Data e NoSQL.

Na Unidade I teremos a apresentação de tópicos conceituais e definições sobre bancos de dados, sistemas gerenciadores de bancos de dados e os tipos de usuários que interagem com esses sistemas. Teremos também uma breve explanação sobre o conceito de transações, que é uma ferramenta essencial no desenvolvimento de aplicações mais tradicionais como aquelas que envolvem dados financeiros. Como leitura complementar, temos um texto de Cezar Taurion (Evangelista Técnico da IBM) falando sobre Big Data. Afinal, é importante darmos um passo no presente – mas sempre com um olho no futuro. Essa será a tônica das nossas leituras complementares e sugestões de vídeos: apresentar-lhe sempre os conceitos de vanguarda que já são aplicados em muitos casos de uso em aplicações modernas.

A Unidade II descreverá a terminologia e outros conceitos básicos que serão utilizados no

restante deste material, tais como a diferenciação entre schemas e instâncias de dados; bem como a arquitetura de sistemas de banco de dados. Conhecer a arquitetura permitirá que você, como desenvolvedor(a) de software, possa explorar melhor os recursos do seu sistema de banco de dados – além de auxiliá-lo(a) na escolha dos diferentes tipos de produtos existentes e também dos produtos concorrentes em cada tipo ofertado.

O modelo relacional de banco de dados propriamente dito será abordado na Unidade III. A

partir deste ponto você estará apto a identificar as características de modelos relacionais e passar

partir deste ponto você estará apto a identificar as características de modelos relacionais e passar a construir seus próprios modelos de dados baseado nos fundamentos apresentados. Na modelagem relacional, você identificará entidades do seu domínio de negócios, suas restrições e os relacionamentos entre as diversas entidades modeladas.

Nas Unidades IV e V aprenderemos a linguagem SQL (Structured Query Language), que é uma ferramenta dominada por 10 em cada 10 desenvolvedores de software que utilizam sistemas de banco de dados. De conceito simples, acredito piamente que não será um problema para você, futuro(a) desenvolvedor(a) de software bem feito. Mas convém ressaltar que SQL possui uma natureza declarativa, que é diferente das linguagens imperativas como Java, C ou Pascal com as quais você provavelmente está acostumado(a). Após sua criação, a SQL tornou-se um padrão de facto para manipular informações em sistemas de banco de dados por meio de seus comandos para inserção, atualização, remoção e consulta de instâncias de dados.

E antes que você possa apreciar o conteúdo do material, permita-me apresentar meu ponto de

vista para reflexão: em muitas empresas o sistema de banco de dados tornou-se o repositório “sagrado” das informações, trancado a sete chaves e reservado ao guardião denominado de DBA (DataBase Administrator). Aliás, é bastante comum que os alunos aprendam ou venham

a concluir que o banco de dados é o coração de um sistema de informação – baseados

nessas falsas impressões transmitidas até certo ponto em grande quantidade. Para mim e

também para muitos autores renomados do mundo do software, o banco de dados é apenas uma ferramenta utilizada na construção de nossos sistemas de informação. E como toda

e qualquer ferramenta, não pode ficar acima do próprio código que atende ao processo de

negócios da empresa. Isso diminui sua importância? Certamente que não! Mas quando modelar seu sistema de informação, pense primeiro no seu modelo de negócios e postergue

até o último momento a sua visão sobre o banco de dados. Tenho certeza de que isso tornará

a sua aplicação muito melhor projetada e permitirá que ela ofereça um retorno muito melhor

ao

seu negócio.

O

banco de dados é só um detalhe. Um detalhe importante, mas o considere um detalhe.

O

coração da sua aplicação é o código bem feito que você elaborará para atender ao seu

negócio. Pense nisso, e a cada batida desse coração você poderá usufruir de muito retorno (e

muito dinheiro, espero).

Um bom proveito e uma ótima leitura.

Prof. Me. Edson Yanaga

uNiDADE i

SumáriO

CONCEITOS DE BANCOS DE DADOS

CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE DADOS

20

TRANSAÇÕES

27

VANTAGENS DE SE UTILIZAR UM SGBD

31

uNiDADE ii

OS BANCOS DE DADOS E O SOFTWARE

SCHEMAS, INSTÂNCIAS E ABSTRAÇÕES

42

INTERFACES DOS SGBDS

43

ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS

46

MODELO CENTRALIZADO

47

CLASSIFICAÇÃO DOS SISTEMAS DE BANCO DE DADOS

56

uNiDADE iii

O MODELO RELACIONAL

CONCEITUAÇÃO

68

RESTRIÇÕES DO MODELO RELACIONAL

71

uNiDADE iv

SQL BáSICO

RESTRIÇÕES

97

CONSULTAS BáSICAS EM SQL

99

COMANDOS DE MODIFICAÇÃO DE DADOS EM SQL

104

uNiDADE v

MAIS SQL

CONSULTAS ENVOLVENDO NULL

118

CONSULTAS UTILIZANDO JOINS

124

CONSULTAS COM FUNÇÕES DE AGREGAÇÃO

126

COMANDOS DE ALTERAÇÃO DE SCHEMA

128

CONCluSãO

141

rEFErÊNCiAS

143

uNiDADE i

CONCEitOS DE BANCOS DE DADOS

Professor Me. Edson Yanaga

Objetivos de Aprendizagem

• Apresentar os conceitos fundamentais envolvendo dados e bancos de dados em sistemas computacionais.

• Descrever as formas interação dos usuários com os bancos de dados.

• Comparar as vantagens desta abordagem em relação a outras similares.

plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

• Conceituar bancos de dados, sistemas gerenciadores de banco de dados e sistemas de banco de dados

• Apresentar as principais características de sistemas de banco de dados

• Enumerar alguns papéis de usuários envolvidos na interação com sistemas de bancos de dados

• Descrever algumas vantagens na utilização de sistemas de bancos de dados comparados a outras abordagens

iNtrODuçãO

iNtrODuçãO Fonte: SHUTTERSTOCK.COM “Scientia potentia est”: “Conhecimento é poder” . Sim, caro(a) leitor(a),
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

“Scientia potentia est”: “Conhecimento é poder”.

Sim, caro(a) leitor(a), conhecimento é poder. Informação é poder. Na sociedade do século XXI, chamamos estas informações armazenadas em sistemas computacionais de dados. E temos informação em abundância. O desafio crescente dos próximos anos é encontrar formas eficientes de processar os dados que já temos e ainda criar para gerar conhecimento e, consequentemente, riqueza.

Nas últimas décadas, boa parte do software desenvolvido envolve além do processamento de informações: as informações de entrada e de saída do software (além de outras metainformações intermediárias) devem ser armazenadas em um mecanismo confiável, e que possibilite o acesso simples e rápido à leitura e escrita destas informações.

Há alguns anos, escrever sobre o tema “banco de dados” seria uma tarefa relativamente tranquila, pois muitos acreditavam tratar-se de um assunto absolutamente consolidado. Mas o nosso mundo está em constante mudança e os modelos de negócios que surgiram recentemente provocaram uma ruptura na forma de se pensar no armazenamento de informações em bancos de dados.

na forma de se pensar no armazenamento de informações em bancos de dados. BANCO DE DADOS
Mas de onde vem este termo que conhecemos como “banco de dados”? Pois em inglês,

Mas de onde vem este termo que conhecemos como “banco de dados”? Pois em inglês, o termo refere-se a databases, que numa tradução literal definiríamos como “base de dados”. Um bom palpite remete a uma visão generalizada de que as instituições denominadas de “bancos” guardam de modo bastante seguro o nosso dinheiro. Os “bancos de dados” seriam então ferramentas que guardariam nossas informações (dados) de modo também supostamente seguro e confiável.

Outra confusão bastante comum e plenamente justificada refere-se à diferença entre os termos “banco de dados” e os sistemas que o gerenciam. Segue uma definição segundo Navathe (2011, p.3):

Um banco de dados é uma coleção de dados relacionados. Os dados são fatos que podem ser gravados e que possuem um significado implícito. Por exemplo, considere nomes, números telefônicos e endereços de pessoas que você conhece. Esses dados podem ter sido escritos em uma agenda de telefones ou armazenados em um computador, por meio de programas como o Microsoft Access ou Excel. Essas informações são uma coleção de dados com um significado implícito, consequentemente, um banco de dados.

Nossos bancos de dados podem ser coleções de dados relacionados dos mais diversos tamanhos. Desde uma pequena agenda contendo números e contatos de pessoas até um índice gigantesco de páginas de Internet e buscas relacionadas ou todas as mensagens e informações trocadas entre bilhões de usuários de uma rede social.

Em termos computacionais, há uma categoria de software especializado que é desenvolvido especificamente com o propósito de se gerenciar estas coleções de dados: os sistemas gerenciadores de banco de dados – popularmente reconhecidos pela sigla SGBD (ou DBMS – DataBase Management Systems, na sigla original em inglês). Segue mais uma definição de Navathe (2011, p.3), sobre o termo:

Um sistema gerenciador de banco de dados (SGBD) é uma coleção de programas que permite aos usuários criar e manter um banco de dados. O SGBD é, portanto, um sistema de software de propósito geral que facilita os processos de definição, construção, manipulação e compartilhamento de bancos de dados entre vários usuários e aplicações. A definição de um banco de dados implica especificar os tipos de dados,

A definição de um banco de dados implica especificar os tipos de dados, 16 BANCO DE
as estruturas e as restrições para os dados a serem armazenados em um banco de

as estruturas e as restrições para os dados a serem armazenados em um banco de dados.

Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer sistemas de software, tal opção não se mostra viável. Relembrando o nosso conceito de que a importância do software consiste em sua capacidade de se gerar valor com as informações que manipula, tem-se que implementar nosso próprio mecanismo de manipulação de dados em nossas aplicações não gera valor: somente custo. É por este motivo que atualmente definimos os SGBDs numa categoria de software que consideramos como commodity.

Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem Oracle, DB2, SQL Server, Access, PostgreSQL, MySQL, Derby e H2. Já exemplos de SGBDs não relacionais (também conhecidos como NoSQL) incluem MongoDB, Redis, Neo4j e Riak.

Para propósitos de definição, finalizaremos denominando o conjunto formado pelo banco de dados e o sistema que o gerencia, o SGBD, de sistema de banco de dados.

que o gerencia, o SGBD, de sistema de banco de dados . Bancos de dados Open

Bancos de dados Open Source: presente ou futuro?

Cezar Taurion

Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de dados Open Source. Bem, tenho minha opinião pessoal e quero compartilhar com vocês. Vamos ver se vai gerar muita discordância

Os softwares de banco de dados são um dos mais importantes componentes de software de

Os softwares de banco de dados são um dos mais importantes componentes de software de uma organização. Neste ambiente as alternativas de software livre já são bastante conhecidas e freqüente- mente são mencionadas na mídia, como MySQL, PostgreSQL, Ingres e Derby.

O MySQL é um produto de uma empresa privada, a MySQL AB. Seu código é desenvolvido pelos

funcionários da empresa e com isso ela garante a propriedade intelectual sobre o produto. Existe uma comunidade envolvida, mas submissões de código são restritas apenas à correção de bugs. Uma pergunta: o MySQL pode ser considerado realmente Open Source, uma vez que não adota o modelo de desenvolvimento colaborativo? O MySQL é ofertado tanto em GPL como sob licença comercial. As duas versões são funcionalmente equivalentes, sendo diferenciadas pelo nível de suporte e cer-

tificação. Indiscutivelmente é o banco de dados Open Source mais popular, com o maior mindshare

do setor.

Outro software é o PostgreSQL, que tem suas origens no Postgres desenvolvido pela Universidade de Berkeley. Podemos citar também o Ingres, que foi um banco de dados da Computer Associates e agora pertence a uma organização independente, a Ingres Corporation (www.ingres.com) e o Derby, originalmente o Cloudscape da IBM e recentemente doado para a Apache Software Foundation, onde agora é o projeto Derby. O Derby (http://db.apache.org/derby/) é um banco de dados em Java, geral- mente embarcado em outros softwares. A IBM, por exemplo, o utiliza embutido em diversos softwares das famílias WebSphere, Tivoli e Lotus.

Nas minhas andanças pelo mercado tenho visto que na prática os bancos de dados Open Source só aparecem como competidores dos produtos mais avançados nas aplicações pouco sofisticadas ou bem especificas.

Por sua vez, os sistemas de banco de dados proprietários buscam competir com funcionalidades di- ferenciadoras, principalmente as relacionadas com administração de ambientes complexos; escalabi- lidade; desempenho com grande volume de transações; alta disponibilidade e capacidade de recupe- ração rápida; e recursos de data warehousing. Além disso, foi criado um ecossistema de negócios em torno dos principais software de banco de dados proprietários, com diversas empresas independentes oferecendo ferramentas de software complementares (geradores de relatórios, analisadores estatís- ticos e outros), serviços de suporte técnico especializado e formação de recursos humanos, e assim por diante, o que também cria uma barreira de entrada difícil de transpor por qualquer novo entrante.

Já o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde se gera di-

nheiro) ainda é incipiente, sendo formado por pequenas empresas com abrangência de atuação bas- tante limitada. Ano passado, a MySQL gerou cerca de 50 milhões de dólares em receita (http://news. com.com/MySQL+hits+50+million+revenue,+plans+IPO/2100-7344_3-6179290.html), mas ainda é um traço (cerca de 0,03%) no gráfico que mostra o mercado global de bancos de dados relacionais, estimado pelo IDC em 16 bilhões de dólares. Como comparativo, o IDC estima que neste mesmo ano,

16 bilhões de dólares. Como comparativo, o IDC estima que neste mesmo ano, 18 BANCO DE
a receita da IBM com a família de produtos DB2 foi de aproximadamente 3,5 bilhões

a receita da IBM com a família de produtos DB2 foi de aproximadamente 3,5 bilhões de dólares.

Qual o papel que os bancos de dados Open Source desempenharão? Na minha opinião estarão atuando (pelo menos nos próximos 3 a 4 anos) na chamada faixa de produtos com funcionalidades comoditizadas, onde as características de preço são as de maior importância. Os usuários típicos serão organizações e aplicações que não precisam de recursos mais sofisticados.

Como avaliar a qualidade de um banco de dados Open Source? Existem diversos critérios que podem

e devem ser considerados em uma análise para seleção de um banco de dados. Os níveis de impor-

tância das variáveis da análise estão diretamente relacionadas com os objetivos do negócio e das necessidades a serem impostas aos softwares de bancos de dados.

Alguns dos principais fatores a serem considerados são:

a) Recursos de gerenciamento e administração. São as ferramentas de apoio às tarefas do admi- nistrador do banco de dados.

b) Desempenho e escalabilidade. Os recursos que o software oferece para garantir desempenho adequado, nos volumes de transações que serão demandados.

c) Recursos técnicos. Disponibilidade de recursos como triggers, stored procedures, cursors, sub- queries, capacidade de replicação, recursos de indexação, aderência a padrões (ANSI SQL), par- ticionamento, backup/recovery, suporte a dados não estruturados, independência de plataforma e recursos de segurança.

d) Custos de Propriedade.

e) Suporte técnico e disponibilidade de recursos humanos. Abrangência do ecossistema em termos de serviços de suporte e qualificação de recursos humanos.

f) Disponibilidade de aplicativos.

g) Recursos de data warehousing e BI.

h) Recursos de desenvolvimento de aplicações.

i) Modalidade de licenciamento.

j) Visão, estratégia e road map do produto.

k) Tamanho e participação/envolvimento da comunidade.

l) Modelo de governança adotado pela comunidade.

m) Base instalada e adoção pelo mercado.

Minha empresa deve adotar um banco de da-

Bem e quanto a uma pergunta que muitos me fazem

dos Open Source? Para mim, para mudar um software de banco de dados deve haver uma estratégia impulsionada por razões fortes e consistentes. Por exemplo, se houver desconfianças que o atual fornecedor esteja saindo do mercado; falta de funcionalidade do software (não é mais adequado às

do mercado; falta de funcionalidade do software (não é mais adequado às BANCO DE DADOS |
necessidades das novas aplicações da empresa); falta de visão estratégica por parte do fornecedor do

necessidades das novas aplicações da empresa); falta de visão estratégica por parte do fornecedor do software atual; custos de manutenção e operação muito elevados para o resultado obtido; falta de

pessoal gabaritado, que esteja disponível no mercado; carência de consultorias e serviços de suporte

externos; relacionamento com o fornecedor cada vez mais deteriorado

dados Open Source simplesmente por questões ideológicas deve estar fora de cogitação, pois banco de dados é muito sério para ser tratado de forma simplista.

OK, e quais seriam então os custos e riscos da migração? Existem custos de migração que não po- dem ser subestimados. Temos os custos da conversão de dados, custos da codificação, testes, e o que chamamos reconciliação entre as aplicações no novo e no antigo ambiente, sempre considerando que dificilmente conseguiremos fazer uma migração estilo big bang, mas que esta será gradual.

Quanto mais complexas forem as aplicações a serem convertidas, mais custosa será a migração. Esta complexidade pode ser medida pelo número de programas, número de tabelas relacionais, restrições de integridade referencial e tamanho do banco de dados. Existem custos indiretos como a construção de interfaces entre as aplicações já convertidas e as que ainda estão no banco de dados antigo. Tam- bém os custos de suporte técnicos aos dois ambientes implicam muitas vezes, em gastos adicionais elevados, principalmente quando o novo banco de dados não for de completo domínio da equipe técnica da empresa.

Mudar para um banco de

Em resumo, os custos da migração afetam os cálculos de custos totais de propriedade. A maioria das empresas é extremamente cautelosa em trocar de fornecedor de softwares críticos. O perigo de uma interrupção nos seus negócios decorrente de uma troca mal planejada ou inadequada faz com que os custos de troca possam ser extremamente elevados e desestimuladores. Migrar de um banco de dados para outro é sempre uma tarefa complexa e de alto risco, que só deve ser efetuada quando os benefícios forem claramente demonstráveis.

Fonte: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/bancos_de_da- dos_open_source?lang=pt_br>. Acesso em: 14 ago. 2012.

dos_open_source?lang=pt_br>. Acesso em: 14 ago. 2012. CArACtErÍStiCAS DE SiStEmAS DE BANCOS DE DADOS Se utilizar

CArACtErÍStiCAS DE SiStEmAS DE BANCOS DE DADOS

Se utilizar um sistema de banco de dados parece uma solução natural, qual seria a outra solução alternativa? Pense em algumas aplicações que você utiliza e que não fazem uso de SGBDs. Processadores de texto, planilhas, ferramentas de desenho etc., são alguns exemplos

de texto, planilhas, ferramentas de desenho etc., são alguns exemplos 20 BANCO DE DADOS | Educação
dessas aplicações. O que todas têm em comum? A necessidade de se armazenar a informação

dessas aplicações. O que todas têm em comum? A necessidade de se armazenar a informação manipulada por meio de arquivos.

Em qualquer aplicação que necessite do armazenamento de dados, faz-se necessário dispor de algum mecanismo que permita que estes sejam gravados de modo persistente. A abordagem de arquivos tem suas vantagens, como por exemplo, a portabilidade dos dados. Você pode carregá-los eletronicamente ou fisicamente para locais diferentes de modo bastante simples. Mas entre as desvantagens desta abordagem há todo o trabalho necessário para se criar um formato e processar a sua gravação e recuperação – e acredite, não é pouco trabalho!

Um SGBD, por outro lado, já dispõe de uma série de funcionalidades prontas para serem

utilizadas pelo desenvolvedor da aplicação. Deste modo, uma série de preocupações passa

a ser delegada a um software de terceiros (o SGBD). A seguir, apresentaremos uma série de

características que diferenciam a abordagem de sistemas de banco de dados da manipulação manual das informações (como em arquivos, por exemplo).

Natureza autodescritiva

Uma característica fundamental que distingue os sistemas de bancos de dados de outras abordagens é o fato de que nos SGBDs, o banco de dados e as metainformações sobre

o banco de dados são armazenados conjuntamente. Essas metainformações armazenadas

contêm informações como o tipo, tamanho e restrições do banco de dados. Em termos técnicos, as metainformações são chamadas de esquema (ou schema, em seu termo original em inglês).

isolamento entre programa e Dados

Numa aplicação que utilize arquivos para o armazenamento de dados, quaisquer alterações na estrutura do arquivo também implicarão em alterações no programa. Nesse caso, dizemos que

o programa é altamente acoplado à sua estrutura de armazenamento de dados. Em contraste, SBGDs permitem que o programa somente informe quais dados são armazenados, sem se

que o programa somente informe quais dados são armazenados, sem se BANCO DE DADOS | Educação
importar em como esses dados serão manipulados internamente. Esta característica aumenta bastante o nível de

importar em como esses dados serão manipulados internamente. Esta característica aumenta bastante o nível de manutenibilidade do sistema, quando bem aplicada.

múltiplas visões dos dados

Esta não é uma característica fundamental, mas muitos SGBDs fornecem a possibilidade de que diferentes usuários com diferentes permissões possam acessar diferentes “visões” dos dados. Essas visões (views) correspondem a estruturas virtuais criadas a partir dos dados armazenados e podem conter, além dos próprios dados, também informações derivadas (calculadas) a partir desses dados.

A criação de diferentes usuários com diferentes permissões a visões específicas é uma abordagem muito utilizada em sistemas cliente/servidor; ou na integração de aplicações mediante banco de dados. O auge do uso destas abordagens deu-se no final da década de 1990, embora ainda hoje seja possível testemunhar aplicações sendo executadas sob este modelo. Recomenda-se fortemente que no desenvolvimento de novas aplicações, a abordagem de múltiplas visões e de integração mediante banco de dados seja substituída por uma abordagem orientada a serviços como SOA (Service Oriented Architecture) ou como REST (REpresentational State Transfer).

Visões não são uma má prática. São um recurso bastante útil, mas não imprescindível. Como toda ferramenta, bem utilizada e de modo adequada, é um recurso valioso.

Acesso concorrente de múltiplos usuários

Um SGBD multiusuário, como o próprio nome já define, deve permitir o acesso de múltiplos usuários. Além disso, o acesso deve ser concorrente, permitindo que todos os usuários conectados executem operações “ao mesmo tempo”.

Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errônea na área de Tecnologia da Informação: “paralelo” e “concorrente”. Paralelismo puro é algo raro em

“paralelo” e “concorrente”. Paralelismo puro é algo raro em 22 BANCO DE DADOS | Educação a
computação, embora seja perfeitamente possível. Ao lidarmos com sistemas de banco de dados, utilizamos o

computação, embora seja perfeitamente possível. Ao lidarmos com sistemas de banco de dados, utilizamos o termo “concorrente”, pois vários usuários têm a impressão de que estão executando instruções ao mesmo tempo – quando na verdade, por se tratar de informações acessadas em disco ou com um único barramento de acesso, torna-se necessário algum mecanismo de contenção que serialize (coloque em fila) cada uma dessas instruções. Como idealmente a execução dessas instruções é bastante curta, tem-se a impressão do pseudoparalelismo.

Um conceito fundamental para que o acesso destes múltiplos usuários mantenha o banco de dados num estado consistente é o mecanismo de transações, que será descrito na próxima seção.

de transações , que será descrito na próxima seção. A revolução do Big Data está prestes

A revolução do Big Data está prestes a acontecer

Cezar Taurion

Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

O termo Big Data começa a despertar muita atenção, mas ainda é um conceito mal definido e com- preendido. Com uma rápida pesquisa ao Google, identifiquei, pelo menos, uma dúzia de definições. Neste artigo, vou falar um pouco sobre o assunto e debater alguns desafios que temos para conseguir colocar projetos de Big Data em ação.

desafios que temos para conseguir colocar projetos de Big Data em ação. BANCO DE DADOS |
Sem entrar em definições e nos atendo apenas a conceitos, podemos resumir com uma fórmula

Sem entrar em definições e nos atendo apenas a conceitos, podemos resumir com uma fórmula sim- ples o que é Big Data: volume + variedade + velocidade de dados. Volume porque, além dos dados gerados pelos sistemas transacionais, temos a imensidão de dados gerados pelos objetos na Internet das Coisa, como sensores e câmeras, e os gerados nas mídias sociais, via PCs, smartphones e ta- blets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos não estru- turados, como fotos, videos, emails e tuítes. E, por fim, velocidade porque, muitas vezes, precisamos responder aos eventos quase que em tempo real. Ou seja, estamos falando de criação e tratamento de dados em volumes massivos.

Outro desafio: criar e tratar apenas de dados históricos, como os veteranos Data Warehouse e as tecnologias de BI (Business Intelligence) começam a se mostrar lentos demais para a velocidade com que os negócios precisam tomar decisões. Aliás, o termo BI já tem mais de 50 anos. Ele foi cunhado por Hans Peter Luhn, pesquisador da IBM em um artigo escrito nos idos de 1958.

Quando falamos em volume, os números são gigantescos. Se olharmos globalmente, estamos fa-

lando em zetabytes, ou 10²¹ bytes. Grandes corporações armazenam multiplos petabytes e mesmo as pequenas e médias empresas trabalham com dezenas de terabytes de dados. Este volume tende

a crescer geométricamente. Em mundo cada vez mais competitivo e rápido, as empresas precisam

tomar decisões baseadas não apenas em palpites, mas em dados concretos. Assim, para um setor de marketing faz todo sentido ter uma visão 360° de um cliente, olhando não apenas o que ele comprou da empresa, como registrado no ERP, mas saber o que ele pensa e diz sobre a empresa e como os faz - pelo Facebook e Twitter, por exemplo.

Hoje, já é consenso que dados são os recursos naturais da nova Revolução Industrial. Na atual socie- dade industrial, ter apenas recursos naturais, como minério, e exportá-los de forma bruta - importando em troca produtos manufaturados, não garante a competitividade de um país no longo prazo. O im- portante é a tecnologia e o conhecimento que cria produtos manufaturados. Afinal, um quilo de satélite vale imensamente mais do que um quilo de minério de ferro.

Fazendo um paralelo, na sociedade da informação é crucial saber tratar os dados na velocidade adequada. Dados não tratados e analisados em tempo hábil são dados inúteis, pois não geram in- formação. Dados passam a ser ativos corporativos importantes e como tal, podem - e deverão - ser quantificados econômicamente.

Big Data representa um desafio tecnológico, pois demanda atenção à infraestrutura e tecnologias analíticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de com- putação em nuvem, desde, é claro, que este imenso volume não seja transmitido repetidamente via Internet. Só para lembrar, os modelos de cobrança pelo uso de nuvens públicas tendem a gerar pro- cessamentos muito baratos, mas tornam caro a transmissão de muitos dados.

A principal base tecnológica para Big Data Analytics é o Hadoop e os bancos de dados NoSQL, onde

para Big Data Analytics é o Hadoop e os bancos de dados NoSQL, onde 24 BANCO
“No” significa Not Only SQL, ou seja, usa-se bases de dados SQL e não SQL.

“No” significa Not Only SQL, ou seja, usa-se bases de dados SQL e não SQL. A importância do “Not Only” SQL explica-se pelo fato do modelo relacional ser baseado na época de sua criação, no início dos anos 70. Nessa época, acessar, categorizar e normalizar dados era bem mais fácil do que hoje. Praticamente não existiam dados não estruturados circulando pelos computadores da época. Tam- bém não foi desenhado para escala massiva, ou para um processamento muito rápido. Seu objetivo básico era possibilitar a criação de queries que acessacem bases de dados corporativas e, portanto, estruturadas. Para soluções Big Data, tornam-se necessárias varias tecnologias, desde bancos de dados SQL, a softwares que utilizem outros modelos, que lidem melhor com documentos, grafos, processamento paralelo, etc.

A complexidade do Big Data vem à tona quando lembramos que não estamos falando apenas de armazenamento e tratamento analítico de volumes massivos de dados, mas de revisão, ou criação, de processos que garantam a qualidade destes dados e de processos de negócios que usufruam dos resultados obtidos. Portanto, Big Data não é apenas um debate sobre tecnologias, mas, principalmen- te, sobre como os negócios poderão usufruir da montanha de dados que está agora à sua disposição. Aí emerge a questão da integração: como integrar bases de dados estruturadas e não estruturadas com diversos softwares envolvidos?

O Big Data abre oportunidades profissionais bem amplas. Na minha opinião, existe espaço para dois

perfis profissionais: um mais voltado para os negócios e qualificados para tratar analiticamente as informações geradas por estas imensas bases de dados e outro com viés mais técnico, ou Data Architect.

Pelo viés dos negócios, um artigo interessante que foi publicado há poucos meses pelo Wall Street Journal, na edição brasileira, aponta como problema a escassez de talentos. Ele fala que muitas empresas americanas começaram a procurar profissionais que saibam interpretar os números usando

a análise de dados, também conhecida como inteligência empresarial. Mas encontrar profissionais

qualificados tem se mostrado difícil. O resultado foi que várias faculdades americanas, como a Facul- dade de Pós-Graduação em Administração da Universidade Fordham e a Faculdade de Administração Kelley, da Universidade de Indiana, começaram a oferecer disciplinas eletivas, cursos de extensão e mestrados em análise de dados. Já o Data Architect deve lidar com tecnologias SQL e NoSQL, conhe- cer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto, ter capacidade de desenhar estratégias para manusear e analisar grandes volumes de dados de formatos diferentes, quase que em tempo real.

A idéia de stream processing, ou stream computing, é fantástica; é um novo paradigma. No modelo de data mining tradicional, uma empresa filtra dados dos seus vários sistemas e, após criar um data warehouse, dispara “queries”. Na prática, faz-se uma garimpagem em cima de dados estáticos, que não refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrás. Com o stream computing, esta garimpagem é efetuada em tempo real. Em vez de disparar queries em cima de uma

é efetuada em tempo real. Em vez de disparar queries em cima de uma BANCO DE
base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando um conjunto

base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando um conjunto de queries. Podemos pensar em inúmeras aplicações, sejam estas em finanças, saúde

e mesmo manufatura.

Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de fabricação de semicondutores monitora em tempo real o processo de deteção e classificação de falhas. Com o stream computing, as falhas nos chips que estão sendo fabricados são detetadas em minutos e não em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda, pode-se fazer ajustes em tempo real nos próprios processos de fabricação.

Quanto ao EDA, pode-se começar a estudar o assunto acessando seu verbete na Wikipedia.

O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Aliás, já aparece no canto da tela

de um ou outro CIO, e, provavelmente, em alguns anos já será um dos temas mais prioritários das tradicionais listas de “tecnologias do ano”. Portanto, é bom estar atento à sua evolução e começar a colocar em prática algumas provas de conceito.

Fonte: <http://imasters.com.br/artigo/23437/banco-de-dados/a-revolucao-do-big-data-esta-prestes-a- -acontecer>. Acesso em 15 jul. 2012.

-acontecer>. Acesso em 15 jul. 2012. O maior evento da comunidade brasileira de NoSQL:
-acontecer>. Acesso em 15 jul. 2012. O maior evento da comunidade brasileira de NoSQL:

O maior evento da comunidade brasileira de NoSQL:

<http://nosqlbr.com/>.

evento da comunidade brasileira de NoSQL: <http://nosqlbr.com/>. 26 BANCO DE DADOS | Educação a Distância
evento da comunidade brasileira de NoSQL: <http://nosqlbr.com/>. 26 BANCO DE DADOS | Educação a Distância

trANSAçÕES

trANSAçÕES Fonte: SHUTTERSTOCK.COM O conceito de transação é fundamental em muitas áreas da computação, e
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

O conceito de transação é fundamental em muitas áreas da computação, e particularmente

fundamental em sistemas de banco de dados. Consideramos como transação uma determinada “unidade de trabalho”, que é realizada em qualquer sistema computacional de um modo coerente e independente de outras transações. Estas transações devem permitir que o sistema esteja num estado coerente antes e depois de sua execução, independente de falhas ou outros problemas que possam ocorrer. Devem permitir também que vários clientes diferentes acessem concorrentemente o sistema sem que isso possa corromper ou levar a estados que não sejam considerados coerentes.

Uma definição clássica do conceito de transações envolve o acrônimo ACID, oriundo das propriedades de Atomicidade, Consistência, Isolamento e Durabilidade.

Atomicidade

A propriedade atomicidade de banco de dados advém do conceito de átomo da física – o qual

até recentemente supunha-se indivisível. Essa indivisibilidade pressupõe que as operações realizadas numa transação sejam todas realizadas por completo; ou que nenhuma seja realizada. Popularmente seria o conceito do “tudo ou nada”. Isto permite que durante a nossa interação com um banco de dados, possamos agrupar vários comandos relacionados com

com um banco de dados, possamos agrupar vários comandos relacionados com BANCO DE DADOS | Educação
a garantia de que todos sejam executados – de modo que as informações armazenadas permaneçam

a garantia de que todos sejam executados – de modo que as informações armazenadas permaneçam num estado consistente após a execução da transação.

Consistência

A propriedade de consistência assegura que a execução de qualquer transação trará o

banco de dados de um estado consistente para outro estado também consistente. No caso,

a “consistência” implica que todos os dados de um banco de dados devem ser válidos de

acordo com um conjunto de regras que podem incluir restrições de tipo, valor, referências entre informações etc.

isolamento

A propriedade de isolamento determina que o resultado da execução concorrente de um

conjunto de transações terá o mesmo resultado de sua execução em série (uma após a outra).

O isolamento transacional é o que garante e permite o acesso concorrente de múltiplos

usuários ao mesmo SGBD.

Durabilidade

A propriedade de durabilidade garante que uma vez que uma transação tenha sido finalizada

com sucesso, os dados terão a garantia de terem sido armazenados corretamente – independentemente da eventualidade de falhas, falta de energia, erros de aplicação etc.

Na opinião deste autor, é justamente a propriedade de durabilidade que faz com que os bancos de dados sejam posicionados como “ferramentas sagradas” em muitas empresas. Novamente, não há menosprezo algum em dizer que o mais importante é o código que atende aos processos de negócios. Durabilidade é essencial: imagine qualquer empresa perdendo

todos os seus dados. A continuidade do próprio negócio está em risco. Mas mais importante

do que os dados em si está o uso que se faz deles.

Mas mais importante do que os dados em si está o uso que se faz deles.
Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas sempre tiveram como pre- missa em
Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas sempre tiveram como pre- missa em

Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas sempre tiveram como pre- missa em seus dados sua corretitude (grau em que o software executa suas funções de modo correto). Isso normalmente implicou na utilização de um banco de dados que pudesse satisfazer as proprieda- des ACID.

Com o aumento da quantidade de informações e usuários nas aplicações, o fator disponibilidade pas- sou em alguns casos a ser mais importante do que a própria consistência das informações.

Além do ACID, surgiu o acrônimo BASE (Basically Available, Soft state, Eventually consistent) – tradu- zido literalmente como Basicamente Disponível, Estado flexível e Eventualmente consistente. O BASE tornou-se uma sigla bastante comum ao lidar com bancos de dados não relacionais.

Uma reflexão que vale a pena ser feita é: para os novos desafios e empreitadas que vocês, futuros profissionais, enfrentarão, em quais situações o ACID é recomendado e em quais outras situações o BASE mostra-se mais adequado?

Referência: <http://queue.acm.org/detail.cfm?id=1394128>. Acesso em 15 jul. 2012.

Acesso em 15 jul. 2012. BANCO DE DADOS | Educação a Distância 29
Acesso em 15 jul. 2012. BANCO DE DADOS | Educação a Distância 29
Papéis assumidos pelos usuários de SGBDs Desenvolvedores de SGBDs São pessoas que projetam e codificam

Papéis assumidos pelos usuários de SGBDs

Desenvolvedores de SGBDs

São pessoas que projetam e codificam os SGBDs. Exem-

plos de pessoas nestes papéis incluem os funcionários de empresas como Oracle, IBM e Microsoft que atuam dire- tamente na programação do software SGBD. No caso de SBGDs livres, podem ser também voluntários ou pessoas

e

empresas interessadas na evolução do software. Nor-

malmente são programadores altamente qualificados que trabalham no código-fonte do SBGD. Mas voluntários de projetos de software livre também podem contribuir em ou- tras atividades como documentação, por exemplo.

Desenvolvedores de aplicações e Administradores de Bancos de Da- dos (DBAs – DataBase Administra- tors)

São pessoas que desenvolvem software que armazena as informações num SGBD. Tradicionalmente, em abor-

dagens mais tradicionais e conservadoras, as equipes de desenvolvimento são separadas em desenvolvedores e DBAs. Os primeiros desenvolvem o software que acessa

 

o

SGBD. Os segundos projetam os bancos de dados e os

mantém. Em abordagens de desenvolvimento mais mo- dernas tende-se a eliminar esta distinção entre os papéis, pois quanto maior a distância entre os membros da equi- pe envolvidos no projeto de software, menor tende a ser a qualidade do software entregue.

Usuários finais

São pessoas que não interagem diretamente com os bancos de dados, e sim com as aplicações criadas pelos desenvolvedores de software que armazenam suas infor- mações em SGBDs. A maioria das pessoas enquadra-se nesta categoria, e embora sejam os grandes beneficiados pela tecnologia dos sistemas de bancos de dados, rara- mente possuem ciência do fato.

dos sistemas de bancos de dados, rara- mente possuem ciência do fato. 30 BANCO DE DADOS
<http://youtu.be/Car5V9l8BiQ>. Klaus Wuestfeld – Prevayler Neste vídeo Klaus Wuestfeld, um dos pioneiros do XP
<http://youtu.be/Car5V9l8BiQ>. Klaus Wuestfeld – Prevayler Neste vídeo Klaus Wuestfeld, um dos pioneiros do XP

<http://youtu.be/Car5V9l8BiQ>.

Klaus Wuestfeld – Prevayler

Neste vídeo Klaus Wuestfeld, um dos pioneiros do XP (eXtreme Programming) no Brasil e criador do conceito de prevalência de objetos, mostra uma abordagem inovadora e de alto desempenho para manipulação e persistência de objetos. Atualmente, alguns dos sistemas de transações mais rápidos do mundo utilizam este conceito.

transações mais rápidos do mundo utilizam este conceito. vANtAgENS DE SE utiliZAr um SgBD Durante as

vANtAgENS DE SE utiliZAr um SgBD

Durante as seções anteriores, já citamos algumas vantagens de se utilizar um SGBD para armazenar as informações de nossas aplicações. A seguir, as enumeraremos de um modo mais detalhado, de forma a justificar seu uso numa diversidade de situações.

Diminuir a redundância e fornecer consistência

Imagine uma situação bastante comum: você resolve elaborar um documento e necessita da colaboração de várias pessoas para fazê-lo. Você então cria o esboço deste documento e o envia por e-mail a todos os interessados. Cada pessoa realiza as suas modificações em suas próprias cópias dos documentos e depois repassa novamente por e-mail. Quem tem a última versão do documento? Quais são os dados corretos? Estas são perguntas difíceis de serem respondidas nesta abordagem, e provavelmente exigirá muito trabalho manual para se chegar à versão final do documento.

Um SGBD centraliza todas estas informações, fazendo com que todos os usuários acessem os mesmos dados. Desse modo, diminui-se a redundância: há somente uma cópia dos dados

Desse modo, diminui-se a redundância: há somente uma cópia dos dados BANCO DE DADOS | Educação
a serem manipulados. Isto permite também que o banco de dados sempre permaneça num estado

a serem manipulados. Isto permite também que o banco de dados sempre permaneça num

estado consistente, pois todos os usuários terão sempre a “última versão” dos dados. Não há

a possibilidade de alguém permanecer com um “pedaço” dos dados antigos e outro “pedaço” com a informação atual.

Controle de acesso

Muitas informações armazenadas em sistemas são confidenciais. Ao mesmo tempo, é necessário que esta informação seja compartilhada com as pessoas para que sejam trabalhadas. Ao utilizar arquivos, é necessário que uma cópia seja enviada aos interessados. Por múltiplos motivos, essas cópias podem acabar sendo enviadas por e-mail a pessoas cujo acesso é indevido; ou a mesma pode ser deixada num dispositivo de armazenamento removível esquecido em alguma mesa de reunião.

No mínimo um SGBD oferece uma combinação de login/senha para acesso a um determinado banco de dados. Outras restrições relativas a qual usuário pode acessar quais dados também costumam ser implementadas pela maioria dos SBGDs. Como o acesso é centralizado, também tem-se uma única cópia para proteção.

Consultas eficientes

Como são aplicações de software de propósito específico, os SGBDs são especialmente projetados para armazenar eficientemente os dados a eles delegados; e para permitir formas de consulta eficientes aos mesmos dados. Cada SGBD possui sua estratégia interna para transformar estas informações em bytes gravados no dispositivo de armazenamento, mas de um modo geral, não há uma grande diferença de desempenho entre diferentes produtos em uma quantidade razoável de aplicações.

Em casos de usos típicos, é muito mais importante a eficiência em consultas do que a eficiência em armazenamento de informações. Assim, os SBGDs utilizam dispositivos como índices (que são estruturas criadas para otimizar consultas baseadas em certos critérios) e

estruturas criadas para otimizar consultas baseadas em certos critérios) e 32 BANCO DE DADOS | Educação
cachês ( caches ) para armazenar em memória os dados mais frequentemente acessados. Estes dispositivos

cachês (caches) para armazenar em memória os dados mais frequentemente acessados. Estes dispositivos permitem que as consultas possam ser executadas de modo mais rápido, e em muitos SGBDs, adequar estes dispositivos de modo otimizado chega a quase ser uma arte, tamanha a quantidade de opções disponíveis.

Backup e Restore

Para garantir a continuidade dos negócios, é essencial executar periodicamente o backup das informações armazenadas no servidor. Ao invés de cópias físicas dos arquivos do SGBD, é comum os próprios SGBDs fornecerem ferramentas que permitem a exportação dos dados para um formato intermediário (texto ou binário) para backup. Estas mesmas ferramentas suportam a restauração destes dados em caso de necessidade.

As rotinas de backup/restore também são uma ferramenta bastante útil na migração ou cópia

de servidores onde o mesmo SGBD esteja instalado. Situações de migração costumam ocorrer

em caso de falhas ou upgrade de equipamento. Cópias costumam ser utilizadas para permitir o

teste de aplicações em desenvolvimento.

CONSiDErAçÕES FiNAiS

Nesta unidade, pudemos perceber que os bancos de dados são uma coleção de dados relacionados que representam, por meio de um nível determinado de abstração, o modelo do mundo real de nossas aplicações de software. Boa parte das aplicações de software desenvolvidas na atualidade envolve a manipulação, e principalmente, o armazenamento dos dados – estes muitas vezes em enormes quantidades. Para manipular estes bancos de dados, criou-se uma categoria de software específico denominada de sistemas gerenciadores de bancos de dados (SGBDs). O banco de dados (os dados) e o sistema que o gerencia são denominados conjuntamente de sistemas de bancos de dados.

Durante esta unidade também descrevemos as características que identificam as

propriedades de sistemas de bancos de dados quando comparados a abordagens tradicionais de processamento de arquivos. Certamente que determinados casos de uso ainda exigem

a utilização de arquivos como meio de armazenamento das informações. Mas com as

informações que detalhamos como características destes sistemas de banco de dados, esperamos que você, como desenvolvedor(a) possa ter argumentos suficientes para decidir

adequadamente entre uma abordagem e outra. Como existem muitos tipos de usuários diferentes que podem

adequadamente entre uma abordagem e outra.

Como existem muitos tipos de usuários diferentes que podem interagir com os sistemas de

bancos de dados, também apresentamos uma lista não exaustiva dos papéis que estes usuários

podem assumir nestas interações. Uma máxima que devemos sempre utilizar é a “técnica do

espelho”. Olhe sempre para o software que você desenvolve por meio dos olhos de quem usa.

Compreender as situações em que cada tipo de usuário interage com um sistema de banco

de dados permite que tenhamos uma consciência melhor das dificuldades e das necessidades

que os usuários possuem em cada caso de uso cotidiano da nossa vida profissional.

Por fim, tentamos discutir algumas vantagens da abordagem de sistemas de bancos de

dados em relação à implementação de aplicações sem a facilidade e funcionalidade de

um SGBD. Claro que, tendenciosamente, um estudioso de sistemas de bancos de dados

observaria argumentos bastante positivos em relação à abordagem dos SGBDs. O papel de

um desenvolvedor experiente é distanciar-se destes apegos a uma determinada tecnologia ou

outra e decidir sobriamente qual a solução mais adequada para a sua aplicação.

Uma vez entendidos estes conceitos, podemos nos dedicar a estudar melhor alguns dos

detalhes internos dos modelos utilizados pelos sistemas de bancos de dados e das arquiteturas

de software existentes que utilizam estes sistemas. Tais tópicos serão abordados em nossa

próxima unidade.

AtiviDADE DE AutOEStuDO

1. Transações tradicionalmente são melhor entendidas por meio do conjunto de suas pro- priedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Em quais situ- ações da vida real você consegue enxergar a necessidade de se executar operações com estas propriedades?

2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparação com a utilização de arquivos para armazenamento dos dados. Tendenciosamente, o SGBD apareceu como o vencedor nas comparações. Quais seriam as situações em que os arquivos seriam uma solução mais adequada? Você consegue exemplificar alguma outra situação em que uma terceira alternativa seria mais viável?

3. Pense no SBGD como um módulo do sistema ou como uma outra aplicação a ser inte- grada (pois em muitas concepções modernas, é assim que ele deve ser tratado). Uma das características dos SGBDs é o isolamento entre o programa e os dados. Quais os benefícios deste isolamento? Em que outras partes do sistema esta característica também pode trazer benefícios?

Banco de Dados na Nuvem Jin Zhang, Diretor de Programas da IBM Fonte: SHUTTERSTOCK.COM Profissionais
Banco de Dados na Nuvem Jin Zhang, Diretor de Programas da IBM Fonte: SHUTTERSTOCK.COM Profissionais

Banco de Dados na Nuvem

Jin Zhang, Diretor de Programas da IBM

Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Profissionais de dados estão adotando conceitos de computação em nuvem para oferecer bancos de dados como um serviço – facilitando as dificuldades de gerenciamento e enviando usuários para a nuvem nove.

“Leva semanas para configurar um novo banco de dados. Preciso dele agora!”

“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”

Qualquer uma dessas reclamações soa familiar? Provavelmente sim, se você for um profissional de dados em uma grande empresa. Os departamentos de TI dos dias de hoje são afetados por uma lista não processada de demandas de administração de dados. De solicitações por novos bancos de dados de desenvolvimento e teste de aplicativos até o backup e a restauração de volumes de dados cada vez mais crescentes, nunca há uma falta de muito trabalho para manter DBAs na correria.

Em uma tentativa de minimizar o tempo que os profissionais de dados gastam no modo reativo - res- pondendo a solicitações de usuários com tarefas sem parada de “banco de dados, clone, banco de dados, clone” - algumas organizações estão tomando emprestado conceitos de autoatendimento do domínio de computação em nuvem e indo em direção a um modelo de banco de dados como serviço ou DBaaS, em que usuários podem simplesmente “acessar uma nuvem” e capturar um banco de dados conforme necessário.

É uma ideia provocante — principalmente para usuários finais. Desenvolvedores de sistemas e de software adoram o controle que eles obtêm com recursos de autoatendimento de DBaaS. Quando eles estão na toada, em vez de esperando que o departamento de TI volte uma semana mais tarde com um banco de dados de desenvolvimento/teste, eles podem solicitar e provisionar recursos imediatamente — mantendo seu ímpeto ativo e suas ideias frescas.

Para tornar essa visão uma realidade, no entanto, os profissionais de dados nos bastidores devem realizar uma quantia considerável de trabalho no backend. Desenvolver uma nuvem de dados privada

e lançar com sucesso DBaaS para usuários finais requer que DBAs considerem diversos fatores, en

e lançar com sucesso DBaaS para usuários finais requer que DBAs considerem diversos fatores, en-

tre eles a infraestrutura de hardware subjacente da nuvem, as “boas práticas” de dados abrangentes

a serem implementadas e replicadas pela nuvem e, por fim, a interface de serviços que trará todos esses itens de forma transparente aos usuários finais para concluir a imagem.

“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”

penetrando as nuvens

Computação em nuvem refere-se a uma categoria de soluções de tecnologia que permite que usu- ários acessem recursos de computação (neste caso, recursos de dados) on demand, conforme ne- cessário, sejam os recursos físicos ou virtuais, dedicados ou compartilhados e independentemente de como são acessados (por meio de uma conexão direta, rede local [LAN], rede de longa distância [WAN] ou a Internet).

Para oferecer DBaaS na nuvem, os departamentos de TI corporativos devem construir e gerenciar uma nuvem de dados corporativa privada — uma plataforma que consiste em hardware de armaze- namento, imagens virtuais, esquemas de banco de dados e mais — e disponibilizar essa nuvem a usuários por meio de uma interface de serviços.

Quando esta infraestrutura estiver instaurada, à medida que necessidades de banco de dados sur- gem, os usuários podem simplesmente ir para a nuvem, solicitar os recursos que requerem e obter acesso instantâneo a seu próprio banco de dados pessoal on demand. Quando eles não precisarem mais dos ativos de dados, os ativos são reciclados de volta na nuvem para redesignação, em vez de serem deixados desperdiçados e inativos.

em vez de serem deixados desperdiçados e inativos. Figura 1. uma infraestrutura otimizada para entrega em

Figura 1. uma infraestrutura otimizada para entrega em nuvem do banco de dados enfatiza simplicidade e eficiência por meio de automação e normatização de hardware.

Etapa um: Desenvolver a base da nuvem Sua primeira parada no caminho para construir um

Etapa um: Desenvolver a base da nuvem

Sua primeira parada no caminho para construir um ambiente de computação em nuvem e entregar DBaaS será considerar sua infraestrutura de hardware subjacente e assegurar que seja alinhada aos objetivos de DBaaS (consulte a Figura 1). Devido à maneira como a maioria dos departamentos de TI está estruturada, essas decisões de hardware provavelmente não ocorrerão em um vácuo. Na verdade, a maioria do DBAs precisará colaborar com administradores de sistemas e contrapartes da arquitetura corporativa para chegarem a um consenso sobre qual deve ser a infraestrutura de hardwa- re. Esse processo pode requerer concessões de todos os lados, portanto, tente entrar na conversa com um entendimento claro de suas principais prioridades de hardware e as “boas de ter”. Não tem certeza de quais devem ser essas prioridades? Leia adiante.

Como em qualquer decisão de compra de hardware, muitos atributos afetarão a discussão — plata- forma, tamanho de armazenamento, velocidade, custo e mais. Para suportar DBaaS na nuvem, acima de tudo você irá querer assegurar que seu hardware seja o mais padronizado possível. Como é muito mais fácil automatizar um script em execução em um sistema aberto homogêneo do que muitos scripts diferentes em um heterogêneo, a normatização é a chave para automação. DBaaS em seu âmago é nada mais que automação — a automação do processo de configuração e fornecimento de um banco de dados — de forma que quanto mais uniforme for sua plataforma de hardware, mais simples será configurar DbaaS.

Em seguida, dê uma olhada nas opções de armazenamento disponíveis para suportar seu banco de dados. Certifique-se de que você tenha um entendimento claro dos tipos de recursos que receberá prontos para uso - inclusive atributos como alta disponibilidade, recuperação de desastre e autonomia - assim como a capacidade geral de armazenamento e recursos de sua infraestrutura de hardware. Como essa plataforma formará por fim a base de sua oferta DBaaS, é crítico entender exatamente do que é capaz - e o que é possível passar a seus usuários finais. Se você usar uma base de armazena- mento que tenha recursos excepcionais de confiabilidade, disponibilidade e capacidade de manuten- ção (RAS), por exemplo, estará mais bem equipado a fornecer bancos de dados na nuvem que são resilientes e altamente disponíveis também.

Etapa dois: Identificar cargas de trabalho comuns e melhores práticas

O próximo estágio de planejamento de DBaaS fornece a você, como um profissional de dados expe- riente com conhecimento íntimo dos funcionamentos internos de sua organização e suas estruturas de dados, a chance de brilhar. A etapa mais crítica para a entrega de DBaaS que realmente traz valor a seus usuários finais é decidir antecipadamente o tipo de modelos e imagens de banco de dados que devem ser disponibilizados na nuvem. Para tomar tais decisões, você deve identificar as cargas de tra- balho comuns e os processos chaves que ocorrem em seu ambiente de negócios e coletar melhores práticas. Esses são os principais candidatos para automação e entrega por meio de DBaaS e a chave para seu lançamento bem-sucedido.

Por exemplo, os DBAs podem trabalhar juntamente com os gerentes de linha de negócios para identi- ficarem os conjuntos de dados que “precisam ter” e usarem essas informações para criarem modelos de bancos de dados que conectem de forma eficiente a sistemas front-end, funcionem bem com ferra- mentas de consulta e possam ser facilmente clonados para fornecimento futuro por meio de DBaaS. Em seguida, a equipe e os sistemas podem acessar a nuvem e ter acesso a todos os modelos que contêm os dados mais recentes, informações atualizadas no minuto e estruturas de dados - sem cria-

rem as dificuldades de administração de dados de mudanças de esquema, mapeamento, migração de dados

rem as dificuldades de administração de dados de mudanças de esquema, mapeamento, migração de dados e mais.

Em outros ambientes corporativos, DBAs podem escolher imagens de bancos de dados - frequente- mente incorporando metadados específicos do segmento de mercado e dados de referência - como candidatos para automação. Um DBA familiarizado com os requisitos de negócios pode isolar uma ins- tância de um banco de dados de produção que contenha um conjunto crítico de tabelas, visualizações, acionadores e procedimentos armazenados - assim como dados de referência chave - para criar uma imagem de banco de dados para ser automatizada por meio de DBaaS. Quando os negócios solicitam um banco de dados para suportar uma nova filial ou para testar um aplicativo, não haverá nenhuma necessidade de esperar semanas enquanto DBAs o constroem. Em vez disso, ele estará disponível instantaneamente por meio de DBaaS na nuvem.

Etapa três: Estabelecer um modelo de entrega

Agora que você decidiu sobre a sua infraestrutura de hardware e identificou os processos e procedi- mentos a serem automatizados por meio de DBaaS, sua etapa final será trabalhar com usuários finais para educar e ajudar os mesmos a selecionarem a interface por meio da qual esses serviços de dados serão disponibilizados.

Há três métodos principais de acesso a DBaaS: por meio de uma interface gráfica com o usuário (GUI), uma interface da linha de comandos (CLI) ou diretamente por meio de uma interface repre- sentational state transfer (REST) padrão. Qual interface será empregada por fim dependerá muito da preferência do usuário final. Por exemplo, enquanto a GUI é a abordagem mais fácil e simples das três, se os usuários finais já utilizarem aplicativos que empregam CLI, pode ser que não queiram alternar. Como alternativa, os usuários podem querer eliminar a necessidade de intervenção humana inteiramente e promover uma integração mais forte com seu ambiente, programando aplicativos para se comunicarem diretamente com DBaaS por meio de REST. Quando se sabe as opções, é possível trabalhar com seus usuários e ajudar a guiá-los para a interface de DBaaS mais adequada para seus desejos e necessidades específicos e juntos selecionar o wrapper que unirá todo o pacote DBaaS.

uma nuvem com um raio de esperança

Não é nenhum segredo que gerenciar os valores de dados em rápida expansão e as necessidades de administração de banco de dados das grandes empresas dos dias de hoje é uma grande proeza. DBAs têm uma tarefa dura e não há outra maneira de descrever isso. A boa notícia é que com DBaaS, os profissionais de dados estão em uma posição exclusiva não somente de darem aos usuários finais novos níveis de liberdade e serviço, mas também para saírem do ciclo vicioso de tarefas de dados rotineiras e irem para as coisas boas. E apesar de isso poder exigir algum fundamento para chegar lá, no que se refere a uma nuvem com um raio de esperança, isso é praticamente o melhor que se pode obter.

Fonte: <http://www.ibm.com/developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBa- aS/>. Acesso em: 14 ago. 2012.

uNiDADE ii

OS BANCOS DE DADOS E O SOFtWArE

Professor Me. Edson Yanaga

Objetivos de Aprendizagem

• Apresentar as definições fundamentais de sistemas de bancos de dados.

• Descrever as arquiteturas de bancos de dados e suas características.

plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

• Conceituar schemas, instâncias, abstrações e as interfaces de interação com o SgBD

• Estudo do histórico das arquiteturas de computação em geral e de sistemas de banco de dados

• Classificação dos diferentes tipos de banco de dados de acordo com suas características

iNtrODuçãO

iNtrODuçãO Fonte: SHUTTERSTOCK.COM Nesta unidade, apresentaremos alguns conceitos fundamentais que serão utilizados nas
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Nesta unidade, apresentaremos alguns conceitos fundamentais que serão utilizados nas demais unidades. Para compreender adequadamente os sistemas de banco de dados, é necessário diferenciar adequadamente os modelos das instâncias dos modelos – pois possuem ciclos de vida e finalidades bastante distintas.

Diferentes tipos de interface de usuário são disponibilizadas para diferentes tipos de usuários em vários produtos diferentes comercializados no mercado. Apresentaremos algumas delas para que você, desenvolvedor(a), possa explorá-las posteriormente.

Entender como podem ser construídos sistemas com SGBDs implica em conhecer também a história da arquitetura de sistemas de computação, que evoluíram do monolítico até o distribuído em camadas. Cada geração possui suas particularidades, que também são refletidas na construção dos diferentes SGBDs.

Apresentaremos também alguns critérios de classificação de SGBDs para que você, como desenvolvedor(a) de software incumbido(a) da árdua tarefa de escolher um produto, possa avaliar subjetivamente e objetivamente diferentes alternativas do mercado.

avaliar subjetivamente e objetivamente diferentes alternativas do mercado. BANCO DE DADOS | Educação a Distância 41
SCHEMAS , INSTÂNCIAS E ABSTRAÇÕES Uma característica fundamental de qualquer modelo de software (o que

SCHEMAS, INSTÂNCIAS E ABSTRAÇÕES

Uma característica fundamental de qualquer modelo de software (o que inclui o banco de dados) é o seu nível de abstração. É impossível conseguir modelar todos os aspectos do

mundo real numa aplicação. Assim, decidimos adequadamente escolher somente os aspectos mais relevantes para resolver um determinado problema, e representamos estes aspectos por meio de um modelo – que é uma abstração dos dados do mundo real. Um modelo de dados

é uma coleção de conceitos que pode ser utilizada para descrever a estrutura de um banco de dados. Por meio desses conceitos, conseguimos alcançar a abstração necessária para construir o nosso modelo de software.

Em qualquer modelo de dados, é importante distinguir aquilo que representa a descrição do banco de dados com o banco de dados em si. A descrição do banco de dados é denominada de schema 1 , que é especificado durante o projeto do sistema de software.

Os dados realmente armazenados num banco de dados podem mudar com uma alta frequência. No conjunto de contatos da minha agenda pessoal, esse banco de dados muda toda vez que eu adiciono um novo contato ou altero um telefone ou e-mail deste contato. O conjunto de dados de um banco de dados num determinado instante do tempo é denominado de snapshot. Também é definido como o estado atual de todas as instâncias no banco de dados. Uma instância é um item dentro do banco de dados que segue as definições de seu schema correspondente.

A distinção entre o schema do banco de dados e o estado do banco de dados é muito importante. No processo de desenvolvimento de software, quando definimos um novo banco de dados, primeiro definimos o seu schema – que após criado representa um snapshot inicial vazio. Ao manipularmos este banco de dados com operações de inserção, alteração e remoção, nós modificamos o snapshot. O SGBD é responsável por garantir a consistência do snapshot em

1 O plural correto de schema é schemata, mas praticamente não é utilizado. Na área de tecnologia da informação, costuma-se utilizar o plural schemas, mesmo sendo errado.

da informação , costuma-se utilizar o plural schemas, mesmo sendo errado. 42 BANCO DE DADOS |

qualquer momento do tempo.

qualquer momento do tempo. Não é uma operação usual ter que realizar modificações no schema ,

Não é uma operação usual ter que realizar modificações no schema, mas elas são realizadas toda vez que uma mudança nos requisitos do negócio demanda uma alteração no modelo de dados. Este conjunto de alterações para acomodar mudanças no software é denominado de schema evolution.

iNtErFACES DOS SgBDS

Algumas das interfaces do SGBD com o usuário são:

Linha de Comando Sem dúvida nenhuma a linha de comando é a interface mais poderosa
Linha de Comando
Sem dúvida nenhuma a linha de comando é a interface mais poderosa e
flexível para a interação do usuário com o SGBD. Por este mesmo motivo,
normalmente não é uma opção que a maioria considere como amigável.
Mas desenvolvedores devem sem dúvida nenhuma dominá-la para poder
explorar os recursos do mesmo.
sem dúvida nenhuma dominá-la para poder explorar os recursos do mesmo. BANCO DE DADOS | Educação
Interfaces Web Muitos SGBDs fornecem interfaces Web que podem ser acessadas por meio de qualquer
Interfaces Web Muitos SGBDs fornecem interfaces Web que podem ser acessadas por meio de qualquer
Interfaces Web
Muitos SGBDs fornecem interfaces Web que podem ser acessadas por
meio de qualquer navegador para a administração e manipulação dos ban-
cos de dados. Embora não sejam tão poderosas ou produtivas, são bastan-
te amigáveis e possuem ainda a vantagem da disponibilização do acesso.
Muitos administradores de rede não se sentem confortáveis em permitir o
acesso direto ao banco de dados, mas não se importam em liberar o aces-
so por meio de HTTP (Web).
dados, mas não se importam em liberar o aces- so por meio de HTTP (Web). 44
Interfaces Desktop São tão amigáveis quanto as Interfaces Web, mas costumam fornecer ca- pacidades de
Interfaces Desktop São tão amigáveis quanto as Interfaces Web, mas costumam fornecer ca- pacidades de
Interfaces Desktop
São tão amigáveis quanto as Interfaces Web, mas costumam fornecer ca-
pacidades de manipulação gráfica de diagramas. Isso auxilia os desenvol-
vedores a “enxergar” os relacionamentos entre as entidades do banco de
dados.
a “enxergar” os relacionamentos entre as entidades do banco de dados. BANCO DE DADOS | Educação
Interfaces baseadas em formulários O Oracle Forms é um exemplo clássico desta interface, típica de
Interfaces baseadas em formulários O Oracle Forms é um exemplo clássico desta interface, típica de
Interfaces baseadas
em formulários
O Oracle Forms é um exemplo clássico desta interface, típica de sistemas
implementados utilizando-se triggers e stored procedures. Os usuários fi-
nais conseguem executar seus processos de negócios por meio da própria
interface do SGBD, preenchendo formulários e interagindo com a interface
de controle.

ArQuitEturAS DE SiStEmAS DE BANCO DE DADOS

A arquitetura de sistemas de banco de dados confunde-se com a própria história da arquitetura de sistemas de computação em geral. De fato, ao mesmo tempo em que as aplicações e os modelos de arquitetura de aplicações evoluíram, também evoluíram os sistemas de banco de dados. Dentre os fatores que influenciaram estas evoluções estão o aumento da capacidade de processamento, o aumento da capacidade de armazenamento, o aumento da quantidade e capacidade das redes de comunicação, a redução de custo dos equipamentos, o aumento do número de usuários, o aumento da quantidade de informações e a universalização do acesso. Não há como explicar adequadamente as arquiteturas de sistemas de banco de dados sem descrever conjuntamente as arquiteturas de sistemas de computação em geral. Nas próximas seções, apresentaremos e descreveremos concomitantemente estas diferentes arquiteturas, da centralizada até o modelo em camadas.

mODElO CENtrAliZADO

mODElO CENtrAliZADO Os primeiros modelos computacionais eram centralizados, baseados num único mainframe fornecendo

Os primeiros modelos computacionais eram centralizados, baseados num único mainframe fornecendo processamento, armazenamento e interface de interação com o usuário no mesmo equipamento/aplicação. Raros eram os mainframes (devido ao seu alto custo) e por consequência também poucos eram os usuários que tinham acesso a aplicações baseadas em mainframe. A interação dos usuários com as aplicações era realizada por meio de terminais burros, que não possuíam poder de processamento: somente teclado; e exibiam telas geradas no próprio mainframe e transmitidas até o monitor (usualmente de fósforo verde ou amarelo) por meio de um cabo de comunicação. A Figura 1 retrata um típico sistema centralizado baseado em mainframe.

Mainframe

sistema centralizado baseado em mainframe . Mainframe Terminal Burro Figura 1 Fonte: o autor Terminal Terminal

Terminal

Burro

Figura 1

Fonte: o autor

mainframe . Mainframe Terminal Burro Figura 1 Fonte: o autor Terminal Terminal Burro Burro BANCO DE
Terminal Terminal Burro Burro
Terminal
Terminal
Burro
Burro
Costumamos retratar este modelo de computação como monolítico , pois todas as atividades eram baseadas

Costumamos retratar este modelo de computação como monolítico, pois todas as atividades eram baseadas no mainframe. Naturalmente, as aplicações desenvolvidas para este tipo de equipamento também foram concebidas e implementadas de modo monolítico. Isso significa que não havia uma distinção clara entre o que era interface com o usuário ou o que era código de negócios ou código responsável pelo armazenamento de dados. Esta situação é denominada de sistema altamente acoplado, pois qualquer alteração numa pequena parte do sistema costuma levar a várias outras alterações em cascata para diversas outras partes do sistema.

Os bancos de dados eram então extensões da própria aplicação e eram baseados nos modelos hierárquicos e em rede, que serão apresentados adiante.

Modelo cliente/servidor

Com a popularização dos PCs e o declínio de seus preços, iniciaram-se as primeiras implantações da arquitetura cliente/servidor. A ideia é que ao invés de termos um grande equipamento monolítico (mainframe), passamos a ter vários equipamentos menores (e de custo e capacidade inferior) com propósito específico (banco de dados, arquivos, e-mail, impressão etc.) interligados por meio de uma rede de comunicação. Cada servidor tornou-se um serviço especializado (embora não seja incomum agrupar vários serviços num único equipamento, dependendo da conveniência).

Os clientes, que também são PCs, podem acessar os recursos disponibilizados por estes servidores por meio de rede. A Figura 2 mostra um esquema simplificado da arquitetura cliente/servidor.

A Figura 2 mostra um esquema simplificado da arquitetura cliente/servidor. 48 BANCO DE DADOS | Educação

Servidor

Servidor

Servidor Servidor Servidor PC PC PC PC Figura 2 Fonte: o autor Em termos de arquitetura

Servidor

Servidor Servidor Servidor PC PC PC PC Figura 2 Fonte: o autor Em termos de arquitetura
Servidor Servidor Servidor PC PC PC PC Figura 2 Fonte: o autor Em termos de arquitetura
Servidor Servidor Servidor PC PC PC PC Figura 2 Fonte: o autor Em termos de arquitetura
PC PC PC PC
PC
PC
PC
PC

Figura 2

Fonte: o autor

Em termos de arquitetura das aplicações, denominamos o modelo cliente/servidor como modelo de 2 camadas, respectivamente camada cliente e camada servidor. No lado cliente costuma- se implantar os recursos da aplicação relacionados à interface com o usuário, enquanto no lado servidor implanta-se a lógica de negócios, armazenamento e controle transacional. Este

modelo tornou-se extremamente popular no final da década de 1980 e início da década de 1990,

e com ele também popularizou-se a prática do desenvolvimento de aplicações utilizando-se

triggers e stored procedures dentro do próprio SGBD. Cada cliente estabelece uma conexão remota ao SGBD, que passa a executar a lógica de negócios, armazenar os dados e controlar as transações.

O modelo cliente/servidor é bastante adequado quanto às aplicações que possuem um número

limitado de usuários concorrentes (de 100 a até 300 ou 400 usuários). A partir deste número,

concorrentes (de 100 a até 300 ou 400 usuários). A partir deste número, BANCO DE DADOS
o desempenho desta arquitetura degrada-se consideravelmente, e o particionamento e distribuição dos sistemas de banco

o desempenho desta arquitetura degrada-se consideravelmente, e o particionamento e distribuição dos sistemas de banco de dados (escalabilidade horizontal) costuma ser bastante dispendioso. Naturalmente, há um limite também para a troca do equipamento por um maior (escalabilidade vertical). Surgiram então os modelos de 3 camadas para tentar resolver este problema.

modelo de 3 Camadas ou N-Camadas

Aplicações baseadas na Internet (web) costumam adicionar uma camada de software adicional entre o cliente e o SGBD, como ilustrado na Figura 3.

PC PC PC PC
PC
PC
PC
PC

Servidor de aplicação

Servidor de aplicação

PC PC PC Servidor de aplicação Servidor de aplicação Servidor de Banco de Dados Figura 3

Servidor de Banco de Dados

Figura 3

Fonte: o autor

Servidor de aplicação Servidor de Banco de Dados Figura 3 Fonte: o autor 50 BANCO DE
Esta camada intermediária é denominada de camada de aplicação, e é responsável pela execução da

Esta camada intermediária é denominada de camada de aplicação, e é responsável pela execução da lógica de negócios. Separa-se então em 3 papéis distintos cada camada: a

camada mais próxima do usuário é responsável pela interface e interação com o usuário;

a camada intermediária é responsável pela lógica de negócios; e a camada do SGBD é

responsável pelo armazenamento dos dados. Como idealmente a camada de aplicações é projetada de modo stateless (sem estado), a replicação horizontal torna-se bem mais simples

do que no modelo cliente/servidor. Toda a lógica de negócios que anteriormente era codificada utilizando-se triggers e stored procedures passa a ser executada na camada intermediária utilizando-se uma linguagem de propósito geral. A quantidade de conexões de rede com o SGBD também diminui, pois agora os usuários não o acessam diretamente – esta tarefa passa

a ser responsabilidade da camada de aplicação.

Outras arquiteturas costumam subdividir a camada intermediária em outras 2 ou 3, criando aplicações de 4, 5 ou N camadas. Podemos adicionar camadas de validação, auditoria,

comunicação distribuída etc. A quantidade de camadas fica a gosto do arquiteto que projeta a arquitetura, mas a filosofia de todo este processo de divisão de camadas segue os princípios

já apresentados.

Este modelo de camadas é o modelo utilizado atualmente para suportar a imensidão de dados

e usuários das aplicações de Internet contemporâneas.

e usuários das aplicações de Internet contemporâneas. O maior evento da comunidade de desenvolvedores do Brasil

O maior evento da comunidade de desenvolvedores do Brasil e referência para profissionais iniciantes ou experientes nos mais variados assuntos, incluindo Arquitetura de Software, Banco de Dados, NoS- QL e Cloud Computing:

<http://www.thedevelopersconference.com.br/>.

e Cloud Computing : <http://www.thedevelopersconference.com.br/>. BANCO DE DADOS | Educação a Distância 51
e Cloud Computing : <http://www.thedevelopersconference.com.br/>. BANCO DE DADOS | Educação a Distância 51
Foto: SHUTTERSTOCK.COM Sem Banco de Dados Nos Estados Unidos, em 1920, a manufatura, venda e
Foto: SHUTTERSTOCK.COM Sem Banco de Dados Nos Estados Unidos, em 1920, a manufatura, venda e
Foto: SHUTTERSTOCK.COM
Foto: SHUTTERSTOCK.COM

Sem Banco de Dados

Nos Estados Unidos, em 1920, a manufatura, venda e importação de bebidas alcoólicas foram proibi- das por emenda constitucional. Esta emenda foi revogada treze anos depois. Durante aquele período de proibição, a indústria de cerveja morreu.

Em 1933, quando a proibição foi encerrada, algumas gigantes empresas de grãos começaram a pro- duzir cerveja. Eles monopolizaram completamente o mercado. E por quase 50 anos, nós nos Estados Unidos bebemos este líquido encorpado efervescente e o chamado de “cerveja”. O único modo de tolerar o sabor era bebê-lo bem gelado.

Como um adolescente nos anos 60, eu nunca entendi a atração. Por que cerveja? Era um fluido páli- do, amarelo e desagradável derivado da urina de javalis doentes, e não possuía nenhuma qualidade que eu pudesse observar.

Em 1984, eu fui à Inglaterra; e as escamas caíram dos meus olhos. Finalmente pude entender. Pela primeira vez eu pude provar cerveja; e eu gostei.

Desde aqueles dias a situação da cerveja nos Estados Unidos melhorou dramaticamente. Novas

a situação da cerveja nos Estados Unidos melhorou dramaticamente. Novas 52 BANCO DE DADOS | Educação
cervejarias estão sendo criadas por todo o país; e em muitos casos a cerveja é

cervejarias estão sendo criadas por todo o país; e em muitos casos a cerveja é realmente boa. Ainda não temos nada tão bom quanto a cerveja inglesa; mas estamos chegando lá.

Nos anos 80 algumas poucas gigantes empresas de banco de dados monopolizaram o mercado. Elas o fizeram ao promover o medo, incerteza e dúvida entre gerentes e profissionais de marketing. A palavra “relacional” tornou-se sinônimo de “bom”; e quaisquer outros mecanismos de armazenamento de dados foram proibidos.

Eu era o líder de equipe de uma startup naquele tempo. Nosso produto media a qualidade de linhas de comunicação T1. Nosso modelo de dados era relativamente simples, e nós mantínhamos os dados em arquivos texto. E funcionava bem.

Mas nosso responsável pelo marketing continuou insistindo que precisávamos utilizar um banco de dados relacional. Ele disse que os clientes iriam demandar um banco de dados relacional. Eu achei tudo aquilo um pedido estranho pois nós não tínhamos vendido nenhum sistema até aquele momento, e nenhum cliente havia sequer questionado a nossa tecnologia de armazenamento de dados. Mas o cara do marketing foi taxativo. Nós teríamos que utilizar um banco de dados relacional. Arquivos texto estavam proibidos.

Como líder de equipe, e responsável pela qualidade do software, minha visão de um banco de dados relacional era que ele seria um trambolho grande, indigesto, lento e caro. Nós não tínhamos consultas complexas. Nós não precisávamos de relatórios com análises massivas. Certamente não precisá- vamos de um processo com múltiplos megabytes consumindo memória e desperdiçando ciclos de processamento (lembrem-se, estávamos na década de 80). Portanto eu lutei contra esta idéia com todos os recursos que eu tinha; porque era a solução técnica errada.

Esta não foi uma jogada politicamente acertada para mim. Durante um período de vários meses, um engenheiro de hardware que tinha a capacidade de escrever algumas linhas de código foi alocado na equipe de software. Gradualmente ele foi recebendo mais e mais responsabilidade, e eventualmente foi nomeado meu cogerente. Ele e eu iríamos “dividir” a responsabilidade de liderar a equipe de software.

Uh huh. Claro. Com certeza. Um cara de hardware com nenhuma experiência real em software iria me “ajudar” a liderar a equipe. E qual você acha que foi o primeiro problema? Foi o de inserir um banco de dados relacional no nosso sistema!

Eu saí um mês depois e iniciei minha carreira de consultor. Foi a melhor mudança que fiz na minha carreira profissional. A empresa que eu deixei não existe mais. E eu também acredito que eles nunca faturaram um centavo sequer.

Eu assisti ao crescimento do mercado de banco de dados relacionais durante os anos 90. Eu assisti às outras tecnologias de armazenamento de dados, como banco de dados de objetos, e banco de dados B-tree morrendo; assim como as cervejarias nos anos 20. Ao fim dos anos 90, sobraram somente os

como as cervejarias nos anos 20. Ao fim dos anos 90, sobraram somente os BANCO DE
gigantes. Estes gigantes estavam criando uma tempestade. Eles eram deuses. Eles eram soberanos. Durante a

gigantes.

Estes gigantes estavam criando uma tempestade. Eles eram deuses. Eles eram soberanos. Durante a bolha ponto com, um deles chegou a ter a audácia de comprar anúncios de televisão que diziam que seu produto era “o poder que movia a Internet”. Isto me lembrou de um comercial de cerveja dos anos 80 “Ya gotta grab for all the gusto in life ya can”. Meu deus.

Durante este período eu assisti com horror a como uma equipe após a outra colocava o banco de da- dos no centro do seu sistema. Eles foram convencidos por um monte de propaganda que o modelo de dados era o aspecto mais importante da arquitetura, e que o banco de dados era a alma e o coração do seu projeto.

Eu testemunhei a criação de um novo tipo de emprego. O DBA! Meros programadores não eram confi- áveis o suficiente para guardar os dados – assim diziam as propagandas. Os dados são tão preciosos, tão frágeis, tão facilmente corrompíveis por estes palhaços indisciplinados. Nós precisamos de pes- soas especiais para gerenciar os dados. Pessoas treinadas pelos fornecedores de banco de dados. Pessoas que iriam garantir e divulgar a mensagem de marketing das grandes empresas de banco de dados: que o banco de dados pertence ao centro. Ao centro do sistema, da empresa, do mundo e do universo. MUAHAHAHAHAHAHAHA!

Eu assisti ao SQL ser enfiado em cada buraco e fenda do sistema. Eu fugi correndo de sistemas em que o SQL havia contaminado a Interface do Usuário. Eu blasfemei incansavelmente contra a prática de se mover toda a lógica de negócios em stored procedures. Eu fraquejei, tremi, resmunguei e rugi enquanto observava programas de mala direta sendo escritos em SQL.

Eu ataquei e ataquei à medida que vi tabelas e linhas invadindo o código-fonte sistema após sistema. Eu avisei sobre o perigo. Eu avisei que o schema havia se tornado o “Blob”, consumindo tudo à sua vista. Mas eu sabia que meus ataques eram como jogar pedrinhas num behemoth.

E então, na primeira década no século 21, uma proibição foi revogada, e o movimento NoSQL nasceu. Eu o considerei um milagre, uma luz brilhando no deserto. Finalmente, alguém percebeu que pode haver alguns sistemas no mundo que não necessitam de um grande, gordo, lento e caro porco devo- rador de memória chamado banco de dados relacional!

Eu assisti com alegria ao nascimento de BigTable, Mongo, CouchDB, e a todos os outros pequenos sistemas de armazenamento de dados florescendo; assim como as pequenas microcervejarias nos anos 80. A cerveja estava de volta! E estava começando a ter um gosto bom.

Mas então eu percebi algo. Alguns dos sistemas utilizando estes bons, simples e saborosos banco de dados não relacionais estavam sendo projetados ao redor dos bancos de dados. Os bancos de dados, encapsulados em reluzentes novos frameworks, ainda estavam no centro da concepção do projeto!

O veneno das campanhas publicitárias das empresas de banco de dados relacionais ainda estava

ecoando na mente dos arquitetos. Eles ainda estavam cometendo o erro fatal.

na mente dos arquitetos. Eles ainda estavam cometendo o erro fatal . 54 BANCO DE DADOS
“Pare!”, eu gritei. “Pare! Vocês não entendem. Vocês não entendem.” Mas a inércia era muito

“Pare!”, eu gritei. “Pare! Vocês não entendem. Vocês não entendem.” Mas a inércia era muito grande. Uma enorme onda de frameworks cresceu e esmagou a nossa própria indústria, levando tudo pelo caminho. Estes frameworks encapsularam os bancos de dados e brigaram com unhas e dentes para manter o centro de nossas aplicações. Eles afirmavam que eram o senhor e mestre dos banco de dados. Eles até alegavam serem capazes de transformar um banco de dados num banco de dados NoSQL. E os frameworks gritaram com uma poderosa voz ecoada por toda a a terra: “Dependa de mim, e eu os libertarei!”

----------

O nome deste artigo é “Sem Banco de Dados”. Talvez após ler todas estas lamentações você possa

entender o porquê do título.

O centro da sua aplicação não é o banco de dados. Nem é um ou outro framework que você possa

estar utilizando. O centro da sua aplicação são os casos de uso da sua aplicação.

Eu enlouqueço quando ouço um desenvolvedor de software descrever o seu sistema como “Um siste-

ma no Tomcat utilizando Spring e Hibernate com Oracle.” As próprias palavras colocam os frameworks

e o banco de dados no centro.

Com o que você acha que a arquitetura desse sistema se parece? Você acredita que os casos de uso são o centro do projeto? Ou você acha que encontrará o código-fonte adaptado para encaixar nos padrões dos frameworks? Você suspeitaria de objetos de negócios que parecem linhas de banco de dados? Será que o schema e os frameworks poluiriam tudo?

Isso é como uma aplicação deve parecer. Os casos de uso devem estar no nível mais alto e mais visível das entidades arquiteturais. Os casos de uso estão no centro. Sempre! Banco de dados e frameworks são detalhes! Você não tem que decidir utilizá-los prematuramente. Você pode postergar esta decisão, até que todos seus casos de uso e regras de negócios tenham sido elaborados, codifi- cados e testados.

Quando é a melhor hora de se determinar o seu modelo de dados? Quando você já conhece quais são as entidades de dados, como elas se relacionam, e como são utilizadas. Quando você sabe isso? Quando você já tem todos os casos de uso e regras de negócios escritas e testadas. Neste momento

você já terá identificado todas as consultas, todos os relacionamentos, todos os elementos de dados,

e estará capaz de construir um modelo de dados que encaixe perfeitamente no seu banco de dados.

Isso muda alguma coisa se você estiver utilizando um banco de dados NoSQL? Claro que não! Você ainda focará em conseguir os casos de uso funcionando e testados antes de pensar no banco de dados; não importa qual banco de dados você acabe escolhendo.

Se você envolve o banco de dados muito cedo, ele deturpará o seu projeto. Ele lutará para ganhar o controle do centro da aplicação, e uma vez lá ele guardará o centro como um cachorro bravo. Você tem que trabalhar duro para manter o banco de dados fora do centro de seus sistemas. Você deve

para manter o banco de dados fora do centro de seus sistemas. Você deve BANCO DE
continuamente dizer “Não” à tentação de envolver o banco de dados logo no início. Estamos

continuamente dizer “Não” à tentação de envolver o banco de dados logo no início.

Estamos nos aproximando de uma época interessante. Uma época em que a proibição contra diferen- tes mecanismos de armazenamento foi revogada e em que estamos livres para experimentar muitas abordagens novas e inovadoras. Mas à medida que brincamos com nossos CouchDBs, Mongos e BigTables, lembrem-se: o banco de dados é só um detalhe e você não deve envolvê-lo logo no início.

Uncle Bob Martin é o Mestre Artesão de Software da 8th Light. Ele é um autor premiado, renomado palestrante e super geek de software desde 1970.

Fonte: <http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html>. Acesso em: 12 ago. 2012.

Acesso em: 12 ago. 2012. ClASSiFiCAçãO DOS SiStEmAS DE BANCO DE DADOS Foto:

ClASSiFiCAçãO DOS SiStEmAS DE BANCO DE DADOS

Foto: SHUTTERSTOCK.COM
Foto: SHUTTERSTOCK.COM

Assim como na natureza, podemos utilizar vários critérios diferentes para classificar os sistemas de banco de dados. Alguns desses critérios bastante comuns são modelos de dados, número de usuários, número de instalações e custo. Nas próximas seções exploraremos como utilizar esses critérios para classificação.

modelo de dados

Não tenha dúvidas: muitas pessoas relacionam o modelo relacional a banco de dados devido à sua absoluta onipresença. Um argumento costumeiro na escolha do modelo relacional é

onipresença. Um argumento costumeiro na escolha do modelo relacional é 56 BANCO DE DADOS | Educação
que “ninguém será demitido por tê-lo escolhido”. De fato, antes do advento do termo NoSQL,

que “ninguém será demitido por tê-lo escolhido”. De fato, antes do advento do termo NoSQL, praticamente não havia outras opções a considerar.

Durante anos houve muita pesquisa e discussão sobre banco de dados orientado a objetos, graças à grande popularização das linguagens orientadas a objetos. O pensamento da época era que o desenvolvimento de aplicações seria muito mais simples se pudéssemos utilizar linguagens e banco de dados orientados a objetos juntos. Mas dois fatores foram decisivos para que isso não acontecesse. Primeiramente, o modelo relacional já era algo absolutamente consolidado e otimizado. Baseado em fundamentos matemáticos extremamente simples, há anos já havia obtido sua maturidade. Robustos e confiáveis, já eram utilizados em grandes aplicações por empresas dos mais variados segmentos. O outro motivo foi que realmente os bancos de dados orientados a objetos nunca se popularizaram comercialmente o suficiente para criar um ecossistema rentável ao redor de si. Atualmente, são raros os exemplos de sistemas de banco de dados deste tipo e não possuem uma fatia que possa ser considerada significativa do mercado.

Sistemas de bancos de dados mais antigos (particularmente os baseados em mainframe) utilizam o modelo hierárquico ou o modelo em rede. Mas não se engane ao considerar que aplicações baseadas nestes modelos desapareceram. Grandes bancos são um segmento tradicionalmente conservador em relação a tecnologias adotadas. É fato que boa parte deles ainda roda seus mais importantes sistemas em mainframes com sistemas de banco de dados hierárquicos ou em rede. É o caso, por exemplo, do Banco do Brasil. Há uma cumplicidade:

mainframes garantem a sobrevida do modelo hierárquico e em rede, e as aplicações baseadas nestes modelos garantem a longevidade do mainframe.

Há outros modelos de dados bastante recentes (os oriundos do NoSQl), como os baseados em chave-valor, baseados em grafos, baseados em documentos etc. Esses modelos mais recentes não serão abordados neste material.

etc. Esses modelos mais recentes não serão abordados neste material. BANCO DE DADOS | Educação a
Número de usuários Em relação ao número de usuários, sistemas de banco de dados podem

Número de usuários

Em relação ao número de usuários, sistemas de banco de dados podem ser monousuários ou multiusuários. Alguns raros exemplos atuais de banco de dados monousuários são os banco de dados embarcados, que são projetados para serem pequenos e rápidos o suficiente para serem embarcados dentro de uma aplicação. Alguns exemplos que poderíamos considerar são o Apache Derby e o H2. Mas mesmo estes dois SBGDs podem se comportar como monousuário ou multiusuário, dependendo do seu tipo de instalação.

Naturalmente, a grande maioria dos sistemas de banco de dados modernos suporta múltiplos usuários concorrentes com acesso mediante algum protocolo de rede.

Número de instalações

Quanto à quantidade de instalações, podemos classificar os sistemas de banco de dados em centralizados ou distribuídos. Sistemas centralizados são aqueles em que há uma única instância do sistema de banco de dados sendo executada. São apropriados para quantidades pequenas de dados ou em situações em que a disponibilidade do sistema não é crucial ao negócio.

Sistemas distribuídos são aqueles em que há mais de uma instância (com a possibilidade de várias) sendo executada. Em sistemas de banco de dados mais tradicionais, costuma-se utilizar uma distribuição master-slave, em que as atualizações de dados são efetuadas no master e as leituras são efetuadas em um ou mais slaves. Como a maioria das aplicações executa mais leituras do que atualizações, o desempenho pode aumentar de modo significativo. Outros tipos de distribuições de banco de dados podem envolver particionamento (dividir os dados em instalações diferentes) e/ou replicação (duplicar os dados) para aumentar o desempenho e/ou disponibilidade.

(duplicar os dados) para aumentar o desempenho e/ou disponibilidade. 58 BANCO DE DADOS | Educação a

Custo

Custo É no critério custo em que amplitude de diferença entre os sistemas de banco de

É no critério custo em que amplitude de diferença entre os sistemas de banco de dados é maior. Temos desde o gratuito até exemplares que podem custar alguns milhões de dólares. No caso dos gratuitos, vale a pena distinguir entre os sistemas livres (software livre) e os que representam versões reduzidas de produtos mais caros. Dois produtos livres bastante populares são o MySQL (bem mais popular) e o PostgreSQL. O modelo de negócios de ambos permite o livre uso e redistribuição; mas quando for necessário o suporte, pode-se optar por contratá-lo de uma empresa terceirizada ou do próprio fornecedor (Oracle), no caso do MySQL. Ambos possuem graus de maturidade, estabilidade e funcionalidade bastante elevados e não devem nada a desejar em relação aos produtos pagos. Provavelmente em mais de 90% dos casos de uso de aplicações tradicionais, não haveria diferença no uso entre um sistema de banco de dados livre e outro pago. Nosso mercado consolidou-se a um ponto em que optar entre uma solução e outra passou a ser uma questão de gosto ao invés de uma questão puramente técnica.

Devido ao sucesso dos sistemas de banco de dados livres, produtos comerciais que tradicionalmente eram bastante custosos passaram a oferecer versões gratuitas (limitadas em número de processadores, quantidade de dados, instâncias etc.). É o caso de Oracle, DB2 e SQL Server. Trata-se de uma estratégia comercialmente interessante, pois migrar de um SGBD para outro não é uma tarefa simples, e permitir que empresas avaliem e usem seus produtos de modo gratuito pode ajudar na tarefa de “aprisionar” o cliente. Assim, uma startup que inicie seus negócios com uma versão gratuita poderá passar a pagar pelo uso dos produtos mais “completos” quando a capacidade da versão gratuita for atingida. Nesse ponto espera-se que a empresa já esteja com um faturamento considerável e provavelmente não se importará com o investimento.

considerável e provavelmente não se importará com o investimento. BANCO DE DADOS | Educação a Distância
<http://youtu.be/piSbDWeu3pM>. Luciano Ramalho – MongoDB Luciano Ramalho é um dos grandes experts em
<http://youtu.be/piSbDWeu3pM>. Luciano Ramalho – MongoDB Luciano Ramalho é um dos grandes experts em

<http://youtu.be/piSbDWeu3pM>.

Luciano Ramalho – MongoDB

Luciano Ramalho é um dos grandes experts em linguagens de programação dinâmica no Brasil, par- ticularmente Python. Também é um dos pioneiros em NoSQL e especialista em MongoDB, um banco de dados de documentos. Neste vídeo, Luciano apresenta as vantagens e as aplicações deste banco de dados.

as vantagens e as aplicações deste banco de dados. CONSiDErAçÕES FiNAiS Nesta unidade nós aprendemos a

CONSiDErAçÕES FiNAiS

Nesta unidade nós aprendemos a distinguir o schema, que é um metamodelo do banco de dados, de suas instâncias. Alterações no schema não costumam ser muito frequentes, enquanto que as instâncias são manipuladas por meio de operações de inserção, remoção ou atualização.

A boa assimilação da distinção entre schema e instâncias é um conceito fundamental para

o uso efetivo de um sistema de banco de dados – aliás, esta diferenciação entre modelo, metamodelo e instâncias do modelo é algo bastante frequente na área de software.

Existem diversos tipos de interfaces de interação dos usuários com o sistema de banco de dados, e a escolha de qual interface utilizar depende muito do propósito e do papel do usuário ao acessá-lo. Sempre há a avaliação entre os quesitos poder versus facilidade de uso. A prática faz-se necessária para que um bom desenvolvedor possa escolher o meio de interação mais adequado de acordo com a situação. Muitas vezes você necessitará do poder da linha de comando; noutros, alguns cliques numa interface desktop serão mais cômodos. O seu conhecimento permitirá que você tome a decisão acertada.

A apresentação das arquiteturas de computação em geral e das arquiteturas de sistemas

de bancos de dados pôde esclarecer a forma com que historicamente se desenvolve estas arquiteturas de aplicações. O artigo apresentado no saiba mais promove uma reflexão importantíssima para que você possa ponderar sabiamente durante o processo de desenvolvimento de suas aplicações. Este autor concorda com a proposta do Uncle Bob Martin, até porque vivemos um período em que muitos conceitos estabelecidos estão sendo

questionados. Poder desenvolver o seu software objetivando o valor de negócios e os seus usuários

questionados. Poder desenvolver o seu software objetivando o valor de negócios e os seus usuários é muito mais importante do que quaisquer abstrações de armazenamento de dados – inclusive o banco de dados. Concentre-se naquilo que é realmente importante para sua aplicação e deixe o banco de dados como aquilo que ele realmente é: um detalhe. Um detalhe importante, é verdade – mas continua sendo um detalhe.

Finalizando esta unidade, pudemos listar alguns critérios diferentes para a classificação de diferentes produtos de sistemas de bancos de dados. Diferentes fornecedores com diferentes produtos apresentarão uma infinidade de argumentos para que você decida entre um e outro. Claro que os critérios comerciais influenciarão bastante sua decisão, mas a lista que assimilamos nesta unidade poderá lhe nortear com alguns argumentos importantes.

Nossa escalada para o domínio dos sistemas de bancos de dados passará na próxima unidade para um novo degrau: o modelo relacional – que em muitos casos já foi (ou ainda é) sinônimo de banco de dados. Veremos o porquê de suas qualidades o tornarem tão bem conceituado.

AtiviDADES DE AutOEStuDO

1. Defina os seguintes termos: schema, instância, snapshot e schema evolution.

2. Qual a diferença entre sistemas de computação de duas e de três ou N camadas, e como os sistemas de banco de dados interagem com estes sistemas de computação?

3. Escolha um caso de uso da vida real para avaliar a implementação de um software. Baseado(a) nos critérios descritos nesta unidade, quais seriam suas considerações para decidir entre um SGBD e outro?

Fonte: SHUTTERSTOCK.COM vida longa ao mainframe: a trajetória de um baby boomer Luiz Fadel, primeiro
Fonte: SHUTTERSTOCK.COM vida longa ao mainframe: a trajetória de um baby boomer Luiz Fadel, primeiro
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

vida longa ao mainframe: a trajetória de um baby boomer

Luiz Fadel, primeiro distinguished engineer da IBM no Brasil, conta sua experiência de 40 anos como profissional especializado na tecnologia.

Poucos são os profissionais de tecnologia que conseguem sobreviver por tantos anos no mundo corporativo, em meio às constantes transformações provocadas pela era digital. Com a revolução da internet, TI passou a ser uma área invadida e dominada, cada vez mais, pela intrigante geração Y – formada por jovens entre 18 e 30 anos.

Vencer a linha do tempo é um desafio, principalmente porque as empresas vêm privilegiando o “san- gue novo”. Uma dura realidade que atinge quase todos os que tentam o mercado de trabalho. Neste cenário, é difícil encontrar profissionais que tenham passado a casa dos 50, mas uma leva de execu- tivos resiste bravamente.

São os chamados “dinossauros” da indústria de tecnologia no Brasil. No bom sentido, claro. O enge- nheiro eletrônico paulistano Luiz A. Fadel é um deles. Formado em um dos mais renomados celeiros de profissionais de engenharia do País, o Instituto Tecnológico da Aeronáutica (ITA), ele conta com uma trajetória profissional ímpar.

Assistiu aos efeitos da reserva de mercado - que protegeu a indústria nacional de informática - e ao sobe e desce de uma tecnologia que depois de altos e baixos continua forte no Brasil – o mainframe. Agora, aos 63 anos, e 40 de experiência em sistemas de grande porte, continua com o mesmo gás e energia de quando começou a carreira. Reconhece que ainda tem muitos anos de estrada pela frente. Fôlego de causar inveja a qualquer um que tenha se formado já na era digital.

“Desemprego não é uma palavra que faz parte do vocabulário dos especialistas em mainframe”, afir- ma Fadel. “Nem mesmo para nós da geração baby boomer”. A falta de gente qualificada para atuar com a tecnologia - que vive um momento de retomada no Brasil - tem trazido de volta ao mercado muitos profissionais que já haviam pendurado as chuteiras.

Sem planos de sair de cena, o executivo conta um pouco de sua experiência ao

Sem planos de sair de cena, o executivo conta um pouco de sua experiência ao longo de duas dé- cadas, toda construída na gigante IBM. Confira trechos da entrevista que Fadel concedeu à Compu- terworld:

Computerworld - Sua carreira foi construída em uma das tecnologias mais antigas e que ainda conti- nua forte no mercado, sobretudo o brasileiro. Que razão o levou apostar nessa área?

Luiz A. Fadel - Sem dúvida, há muitas oportunidades interessantes que o mercado de mainframe oferece. Em todos os meus 40 anos de carreira, só lembro um momento crítico para os profissionais dessa tecnologia. Na década de 90, com o auge dos PCs, a demanda por sistemas de grande porte sofreu retração. Quadro que anos depois teve recuperação.

Apesar dos percalços, a plataforma evoluiu bastante de 1964 (quando comecei) para cá. Não falo da base dela, que permanece a mesma, mas do que é adicionado a ela, exigindo do profissional estar sempre se atualizando. Todo dia há coisas novas.

E engana-se quem pensa que o mainframe morreu. Pelo contrário, é um sistema que completa o parque de muitas empresas por atender a necessidade de transações mais robustas. Prova disso é que ainda existe uma forte demanda.

CW – Desde que ingressou na IBM, que momentos o senhor elenca como os mais marcantes?

Fadel – Quando entrei, em 1969, a empresa era umas das poucas - fora ela, existiam só outras duas - a atuar com sistemas de grande porte, os conhecidos mainframes. Logo de cara tive o privilégio de participar de projetos envolvendo grandes bancos brasileiros que, na época, tornavam-se os maiores consumidores da tecnologia. Também estive envolvido na primeira instalação do Mainframe Operating Systems (Mainframe OS) no País, assim que fui promovido à analista de sistemas.

CW – Hoje acabou o tempo em que os profissionais “vestiam a camisa” da empresa. Como o senhor enxerga a opção de ter feito carreira em uma única companhia?

Fadel - Comecei como trainee em vendas, assim que saí da faculdade, e estou na empresa até hoje porque sempre vi grandes oportunidades de ascensão profissional dentro da carreira técnica. Nunca precisei mudar de rumo para dar saltos. Tanto que hoje cheguei a um cargo equivalente ao de um diretor com carreira em negócios, que a IBM chama de distinguished engineer.

É o posto mais alto da empresa na área técnica. Na subsidiária brasileira, só três profissionais têm esse título. Eu fui o primeiro a conquistá-lo aqui, em 2003. No mundo, existem cerca de 200 pessoas com o posto. Ou seja, uma grande realização na carreira que não posso ignorar.

Também não podemos esquecer que a IBM sempre foi uma multinacional sólida e de peso. Além de abrir as portas para que os funcionários possam ter experiência profissional fora do Brasil. Eu mesmo estive por duas vezes trabalhando nos Estados Unidos, somando um total de seis anos – a primeira fase entre 1977 e 1980; a segunda de 1988 a 1991.

Nos dois casos, em Poughkeepsie, ao norte do estado de Nova York, onde está o centro de pesquisa da IBM, que reúne os melhores especialistas da companhia do mundo. Isso quando éramos (os bra- sileiros) pouco respeitados, quanto ao aspecto técnico, no exterior.

CW – É fato que, por um lado, existe uma forte demanda de projetos e por outro, poucos profissionais para desenvolvê-los. Esse quadro valoriza o profissional de mainframe, inclusive os mais seniores?

Fadel – Sim. A falta de pessoal especializado em sistemas de grande porte é enorme. Não há gente

no meio da pirâmide e quem possui experiência está empregado. Por isso a própria IBM

no meio da pirâmide e quem possui experiência está empregado. Por isso a própria IBM firmou par- ceria com as universidades do País para formar gente. Posso garantir que oportunidade é o que não falta para especialistas em mainframe. Na empresa, por exemplo, somos extremamente valorizados. Detalhe: há espaço para quem se aposentou e quer voltar e para quem não pretende pendurar as chuteiras.

Fonte: <http://computerworld.uol.com.br/carreira/2009/09/03/vida-longa-ao-mainframe-a-trajetoria-de- -um-baby-boomer/>. Acesso em: 1 ago. 2012.

-um-baby-boomer/>. Acesso em: 1 ago. 2012. 64 BANCO DE DADOS | Educação a Distância

uNiDADE iii

O mODElO rElACiONAl

Professor Me. Edson Yanaga

Objetivos de Aprendizagem

• Conceituar o modelo relacional.

• Conceituar as restrições do modelo relacional.

• Descrever as operações de manipulação de instâncias do modelo relacional.

plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

• Conceituar domínio, atributos, tuplas e relações

• Conceituar os diferentes tipos de restrições do modelo relacional e de banco de dados

• Descrever as operações de INSERT, UPDATE e DELETE do modelo relacional e como elas interagem com as restrições do banco de dados

iNtrODuçãO

iNtrODuçãO Fonte: SHUTTERSTOCK.COM A partir desta unidade, abordaremos o modelo de dados relacional, que é o
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

A partir desta unidade, abordaremos o modelo de dados relacional, que é o modelo utilizado nos bancos de dados relacionais. O advento do modelo relacional é atribuído a Ted Codd da IBM em 1970, e imediatamente se popularizou devido à sua simplicidade e sólidos fundamentos matemáticos: é baseado na teoria geral dos conjuntos e em lógica matemática.

Os primeiros SGBDs relacionais apareceram na década de 1980, sucedendo os bancos de dados hierárquicos e em rede predominantes em mainframes. Desde então, sua expansão foi enorme, e acabou tornando-se sinônimo de “banco de dados”. Exemplos de produtos populares são DB2 (IBM), Oracle e MySQL (Oracle), SQLServer (Microsoft) e PostgreSQL (software livre).

Dada a relevância do assunto, tanto esta quanto as próximas duas unidades focarão no modelo relacional de dados. Nesta unidade, introduziremos alguns conceitos fundamentais do modelo relacional tentando nos distanciar um pouco da teoria geral dos conjuntos e nos aproximando mais do nosso mundo cotidiano.

teoria geral dos conjuntos e nos aproximando mais do nosso mundo cotidiano. BANCO DE DADOS |
CONCEituAçãO No modelo relacional, o banco de dados é representado como um conjunto de relações

CONCEituAçãO

No modelo relacional, o banco de dados é representado como um conjunto de relações. Podemos tentar entender uma relação como uma tabela ou uma planilha de cálculo. Observando como uma tabela, cada linha representa uma coleção de valores relacionados. De fato, cada linha de uma tabela no modelo relacional costuma representar uma entidade do mundo real ou um relacionamento entre duas entidades.

Contato

Nome

Sobrenome

Nascimento

Ademir

Santos

20/12/1984

Carlos

Silva

26/04/1970

Justino

Carvalho

11/07/1981

Marcela

Moreno

03/06/1999

Figura 4

Fonte: o autor

Observando a Figura 4, verificamos que a tabela se chama Contato, pois representa um

conjunto de contatos numa agenda pessoal. Cada linha da tabela representa uma instância de um contato real. Os nomes das colunas (Nome, Sobrenome, Nascimento) representam informações sobre um Contato. Dentro de uma determinada coluna, todos os dados possuem

o mesmo tipo (String, data, inteiro, real etc.).

Definido de modo formal, uma linha é denominada de tupla, o nome de uma coluna é denominado de atributo e a tabela é denominada de relação. O tipo de dado que pode ser inserido em cada coluna é denominado de domínio, e representa os valores possíveis de cada atributo.

Características de uma Relação

A seguir analisaremos as características atribuídas a uma relação (tabela) no modelo relacional:

características atribuídas a uma relação (tabela) no modelo relacional: 68 BANCO DE DADOS | Educação a
1. Ordem das tuplas. Como uma relação (tabela) representa a noção matemática de conjunto, relações

1. Ordem das tuplas. Como uma relação (tabela) representa a noção matemática de conjunto, relações não possuem ordem. Isso significa que não há uma ordem natural particular imposta dentro da relação. Como estes dados serão gravados em algum dispositivo de armazenamento, é natural que sequencialmente eles estejam dispos- tos em alguma ordem – mas para efeitos do modelo relacional, deve-se assumir que

a ordem dos elementos é caótica. Durante o desenvolvimento de aplicações, não se deve assumir nenhuma premissa sobre a ordem dos elementos dentro de uma relação.

2. Atomicidade dos valores e o valor Null. No modelo relacional, cada valor de

cada atributo dentro de uma tupla é atômico. Atômico no mesmo sentido de átomo

e em transações: estes valores não podem ser divididos em outros componentes.

Assim, ao menos no modelo relacional puro, não são possíveis valores compostos ou múltiplos valores dentro de um mesmo atributo. Um conceito essencial e bastante utilizado em atributos é o valor definido como NULL. NULL é um valor utilizado em colunas para definir casos especiais em que: o valor pode não se aplicar àquela tupla; o valor não possui valor definido; ou o valor é desconhecido. No caso da tabela Contato, podemos definir como NULL o atributo Nascimento quando desconhece- mos o dia em que nosso Contato nasceu.

3. Semântica de uma relação. Relações podem representar situações factuais. Po- demos considerar que cada tupla da relação Contato seja um fato: você, no mundo real, possui um Contato verdadeiro que pode ser abstraído com os dados daquela tupla. Algumas relações representam dados sobre entidades (como é o caso de Con- tato). Outras relações podem representar relacionamentos (como seriam os e-mails ou os telefones de cada Contato). No modelo relacional, tanto entidades quanto re- lacionamentos entre entidades podem ser igualmente representados por relações (tabelas). Isto simplifica muito o modelo e sua utilização, pois não precisamos de notações nem de ferramentas para fazer distinção entre as entidades e os relacio- namentos entre elas.

para fazer distinção entre as entidades e os relacio- namentos entre elas. BANCO DE DADOS |
Fonte: SHUTTERSTOCK.COM Bancos de dados livres crescem no Brasil Uma nova geração de bancos de
Fonte: SHUTTERSTOCK.COM Bancos de dados livres crescem no Brasil Uma nova geração de bancos de
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Bancos de dados livres crescem no Brasil

Uma nova geração de bancos de dados livres começa a ganhar adesão de várias empresas do setor financeiro e industrial do país, revela estudo.

GENILSON CEZAR, ESPECIAL PARA COMPUTERWORLD

Uma nova geração de bancos de dados livres começa a ganhar adesão de várias empresas do setor financeiro e industrial do país, para aplicações específicas ou embarcadas em equipamentos de co- municação, e já está criando um impacto positivo entre os desenvolvedores.

Essa é uma conclusão do consultor independente Fernando Lozano, community manager da Java. net, apresentada na quarta-feira (17/08) no Developer’s World 2005, realizado pelo IDG Brasil, no Hotel Jaraguá, em São Paulo.

Lozano vem trabalhando na implementação de projetos de banco de dados livres em várias empresas como o Instituto Brasileiro de Petróleo e Gás, Elephant Internet, iBest e Amsterdam Sauer. “O banco de dados livre é hoje uma alternativa viável e de alta performance, além de comercialmente atraente, pois pode utilizar qualquer ferramenta de desenvolvimento para acesso aos dados”, diz ele.

Para Thiago José Macieira, desenvolvedor central do KDE, uma das principais comunidades de open source do mundo, com quase 20 colaboradores brasileiros, o interesse pelo software livre no Brasil é cada vez maior, principalmente depois que o governo federal decidiu estimular a adoção do produto em licitações públicas.

“Muitos desenvolvedores estão decididos a contribuir para o avanço do open source, mesmo sem ter qualquer espécie de retorno financeiro, no máximo um outro patrocínio para participar em congressos internacionais”, afirma Macieira.

Fonte: <http://computerworld.uol.com.br/tecnologia/2005/08/18/idgnoticia.2006-05-15.4431159825/>. Acesso em: 1 ago. 2012.

rEStriçÕES DO mODElO rElACiONAl Restrições no modelo relacional são uma forma de se restringir os

rEStriçÕES DO mODElO rElACiONAl

Restrições no modelo relacional são uma forma de se restringir os valores que os atributos das tuplas podem possuir num determinado snapshot. Essas restrições podem ser derivadas dos próprios relacionamentos do modelo relacional ou de restrições de valores de negócios impostos pelo modelo de software sendo desenvolvido.

Os tipos de restrições do modelo relacional são de domínio, de chave e de valores nulos, e de integridade e integridade referencial. Estas são descritas nas seções seguintes.

Restrições de domínio

As restrições de domínio impõem ao banco de dados quais valores podem ser permitidos em cada atributo dentro de cada tupla em cada tabela. Algumas destas restrições podem ser de tipo (você não pode colocar um valor String num campo inteiro ou vice-versa). Outras restrições possíveis podem restringir valores dentro de um tipo (somente os inteiros maiores que zero). Exploraremos melhor estas restrições de domínio quando tratarmos das restrições do SQL.

restrições de chave e de valores nulos

Como uma relação (tabela) representa um conjunto na definição formal da teoria dos conjuntos, não há a possibilidade de uma relação conter elementos repetidos; pois num conjunto, todos os elementos são distintos. Desse modo, havendo ou não a possibilidade de se haver registros com dados semelhantes dentro do modelo de negócios, utiliza-se uma restrição denominada de chave primária que define de modo único cada registro dentro da relação. Esta chave primária pode ser composta de um único atributo ou mesmo de um conjunto de atributos.

Não há verdades absolutas na área de Tecnologia da Informação, mas no passado foi bastante comum a utilização de chaves primárias compostas para representar as tuplas de uma relação. Matematicamente, não há diferença entre uma chave primária simples (um único atributo) e

não há diferença entre uma chave primária simples (um único atributo) e BANCO DE DADOS |
uma chave primária composta (múltiplos atributos). Baseando-se no princípio da Navalha de Occam, preferimos optar

uma chave primária composta (múltiplos atributos). Baseando-se no princípio da Navalha de Occam, preferimos optar pela solução mais simples: chaves primárias simples.

Outra prática atual diz respeito à visibilidade por parte do usuário do valor da chave primária. Em aplicações legadas, é bastante comum visualizar este atributo em formulários cadastrais e em listagens. Uma corrente de pensamento pondera que este número não faz sentido ao usuário

e não deve ser exibido. Não exibi-lo também permite que a chave primária seja trocada numa

eventualidade em que o particionamento ou a replicação de banco de dados seja necessária

e implique numa troca da chave primária. Pense: o usuário deseja ou precisa saber a chave primária ou é a sua aplicação que foi projetada para obrigar o usuário a utilizá-la?

que foi projetada para obrigar o usuário a utilizá-la? Princípio da Navalha de Occam (ou Ockham)

Princípio da Navalha de Occam (ou Ockham)

“Se em tudo o mais forem idênticas as várias explicações de um fenômeno, a mais simples é a melhor” - William de Occam.

Popularmente costumamos citar este princípio como: “se há mais de uma explicação para um fenôme- no, e todas parecem igualmente corretas, então a mais simples é a mais correta”.

Em que outras partes da sua vida profissional poderíamos aplicar com sucesso este princípio?

poderíamos aplicar com sucesso este princípio? Outro tipo de restrição são as chaves ou chaves

Outro tipo de restrição são as chaves ou chaves únicas: como o próprio nome já implica, representam atributos dentro de uma tupla que não podem ter valores repetidos.

Valores nulos (NULL) podem ser restringidos com uma restrição de non-NULL. Atributos de uma tupla com esta restrição obrigatoriamente devem possuir um valor válido que não seja nulo.

obrigatoriamente devem possuir um valor válido que não seja nulo. 72 BANCO DE DADOS | Educação
Integridade, Integridade referencial e chaves estrangeiras A restrição de integridade estabelece que nenhuma tupla

Integridade, Integridade referencial e chaves estrangeiras

A restrição de integridade estabelece que nenhuma tupla pode possuir uma chave primária

com valor NULL. Como a chave primária é utilizada para identificar de modo único cada tupla da relação, permitir o valor NULL faria com que fosse possível ter duas tuplas com a mesma chave primária nula – sendo impossível distinguir uma da outra.

A restrição de integridade referencial é especificada entre duas relações (tabelas) distintas, e

é utilizada para manter a consistência entre tuplas pertencentes às duas relações. Isto implica

que uma restrição de integridade referencial obriga uma tupla numa relação a referenciar a uma tupla existente em outra relação – para as quais a integridade referencial foi definida.

Contato

 
 

iD

Nome

Sobrenome

Nascimento

1

Ademir

Santos

20/12/1984

2

Carlos

Silva

26/04/1970

3

Justino

Carvalho

11/07/1981

4

Marcela

Moreno

03/06/1999

 

telefone

iD

Número

contato_id

1

443032020

1

2

4420201010

3

Figura 5

Fonte: o autor

Para compreender melhor este conceito, analisemos a Figura 5. Restrições de integridade referencial são criadas entre duas tabelas diferentes (ou excepcionalmente na mesma tabela). Veja o relacionamento entre as tabelas Contato e Telefone. Na tabela Telefone, o atributo

entre as tabelas Contato e Telefone. Na tabela Telefone, o atributo BANCO DE DADOS | Educação
contato_id referencia o contato ao qual o Telefone pertence. Neste caso, definimos que o atributo

contato_id referencia o contato ao qual o Telefone pertence. Neste caso, definimos que o atributo contato_id é uma chave estrangeira da tabela Contato que referencia o relacionamento entre as duas tabelas.

que referencia o relacionamento entre as duas tabelas. Estudo de caso: Fonte: SHUTTERSTOCK.COM Detran do Ceará

Estudo de caso:

Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Detran do Ceará economizou R$ 1,7 milhão com banco de dados livre

Tomada há cerca de dois anos pelo governo do Ceará, a decisão de substituir a solução de banco de dados da Oracle pelo PostgreSQL fez com que o Detran economizasse gastos com pagamento de licenças e serviço de suporte técnico.

Em 2008, o administrador de banco de dados Nabucodonosor Coutinho foi convidado pelo Detran do Ceará para cuidar do processo de migração do banco de dados. Em apresentação no IV Encontro Nordestino de Software Livre, realizado semana passada em Natal (RN), ele explicou o projeto.

Como o Detran chegou ao seu nome?

O Detran tinha a seguinte arquitetura: um servidor de aplicação ligado a um servidor Oracle. Era nesta

situação que as 1.287 tabelas e 426 views do banco se encontravam. Gastava-se muito dinheiro com

o pagamento de licenças e o governador queria que o Detran utilizasse o Software Livre. Pensou-se

em utilizar o MySQL, mas optou-se pelo PostgreSQL, que já era o banco de dados oficial do Governo

do Ceará. Como trabalhava há cerca de 8 anos com o PostgreSQL, minha empresa foi chamada para

há cerca de 8 anos com o PostgreSQL, minha empresa foi chamada para 74 BANCO DE
participar do projeto. Quais foram as principais dificuldades encontradas? A principal dificuldade era que a

participar do projeto.

Quais foram as principais dificuldades encontradas?

A principal dificuldade era que a equipe estava ocupada com as tarefas diárias de manutenção e de- senvolvimento de novas ferramentas para o órgão. Além disso, a base de dados era muito complexa e utilizava muitos recursos que até então estavam disponíveis apenas no Oracle. Outro fator negativo foi que poucos técnicos tinham conhecimento em PostgreSQL.

Como é a arquitetura do banco hoje?

Agora o servidor de aplicação é ligado diretamente a um balanceador de carga, que é ligado a dois servidores do banco de dados.

Além da economia com as licenças, quais outros resultados positivos a nova arquitetura trouxe?

As consultas ficaram mais rápidas. Tem uma que levava 2 horas e, depois da migração, passou a ser realizada em 6 minutos. Na primeira vez, o responsável do Detran não acreditou e acabamos gastan- do as 2 horas tentando convencer que a consulta tinha sido mesmo realizada em 6 minutos.

Fonte: <http://www.softwarelivre.gov.br/noticias/detran-do-ceara-economizou-r-1-7-milhao-com-ban- co-de-dados-livre/>. Acesso em: 1 ago. 2012.

co-de-dados-livre/>. Acesso em: 1 ago. 2012. Operações de atualização do modelo relacional Existem

Operações de atualização do modelo relacional

Existem três operações básicas de atualização que podem alterar o snapshot do banco de dados. Vamos nos referir a estas operações em seu termo em inglês, pois eles também correspondem aos comandos em SQL que veremos nas próximas duas unidades. As operações são: Insert (Inserção), Update (Modificação) e Delete (Remoção). A operação de Insert é utilizada para inserir novas tuplas numa relação; a operação Update é utilizada para atualizar valores de uma tupla já existente dentro de uma relação; e a operação Delete é utilizada para remover uma tupla existente de uma relação. Em cada uma dessas operações, são verificadas as restrições descritas nas seções anteriores. Caso alguma das restrições seja violada, o SGBD reportará um erro e a operação não será completada com sucesso.

o SGBD reportará um erro e a operação não será completada com sucesso. BANCO DE DADOS
Insert operação de Insert fornece os atributos de uma nova tupla para ser adicionada na

Insert

operação de Insert fornece os atributos de uma nova tupla para ser adicionada na relação.

A

Restrições de domínio podem ser violadas se algum dos valores atribuídos não for do tipo apropriado do atributo.

Restrições de chave podem ser violadas se alguma outra tupla possuir a mesma chave repetida.

Restrições de integridade podem ser violadas se a chave primária atribuída for NULL.

Restrições de integridade referencial podem ser violadas se o valor de qualquer chave estrangeira atribuída não existir no relacionamento referenciado.

Update

A

operação de Update modifica os valores de um ou mais atributos em uma ou mais

tuplas numa relação.

Restrições semelhantes à operação de Insert podem ser violadas na execução des-

ta operação.

Delete

A operação de Delete remove uma tupla da relação. A única restrição que pode ser

violada pela operação Delete é a restrição de integridade referencial. Neste caso, a tupla sendo removida é referenciada por uma outra tupla num relacionamento entre duas relações.

uma outra tupla num relacionamento entre duas relações. <http://youtu.be/gx1xT_GzH_g>. Alexandre Porcelli

<http://youtu.be/gx1xT_GzH_g>.

Alexandre Porcelli – SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011

– SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011 76 BANCO DE DADOS
– SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011 76 BANCO DE DADOS
Fonte: SHUTTERSTOCK.COM Os bancos de dados relacionais estão condenados? Recentemente uma grande leva de bancos
Fonte: SHUTTERSTOCK.COM Os bancos de dados relacionais estão condenados? Recentemente uma grande leva de bancos
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

Os bancos de dados relacionais estão condenados?

Recentemente uma grande leva de bancos de dados não relacionais surgiram tanto na nuvem quanto fora dela. Uma das principais mensagens que este cenário nos traz é “se você precisa de uma grande escalabilidade sob demanda, você precisa de um banco de dados não relacional”.

Se isto for verdade, então é um sinal de que o outrora todo poderoso banco de dados relacional per- deu seu trono? Seria este um sinal de que os bancos de dados relacionais estão com os dias contados e irão declinar com o passar do tempo? Neste artigo nós analisaremos a tendência atual de se migrar de bancos de dados relacionais em certas situações e o que isso significa para o futuro dos bancos de dados relacionais.

Bancos de dados relacionais já estão presentes no mercado há mais de 30 anos. Durante este tempo, muitas pseudo-revoluções surgiram e se foram, e todas elas supostamente deveriam acabar com os bancos de dados relacionais. Todas estas revoluções fracassaram, claro, e nenhuma chegou a fazer sequer um arranhão na dominância dos bancos de dados relacionais.

Primeiro, um pouco de histórico

Um banco de dados relacional é essencialmente um grupo de tabelas (entidades). Tabelas são com- postas de colunas e linhas (tuplas). Estas tabelas possuem restrições, e relacionamentos são defi- nidos entre elas. Bancos de dados relacionais são consultados através da SQL, e os conjuntos de

de dados relacionais são consultados através da SQL, e os conjuntos de BANCO DE DADOS |
resultados são produzidos pelas consultas que acessam os dados de uma ou mais tabelas. Múltiplas

resultados são produzidos pelas consultas que acessam os dados de uma ou mais tabelas. Múltiplas tabelas sendo acessadas numa única consulta são “unidas”, tipicamente por um critério definido nas colunas de relacionamento das tabelas. Normalização é um modelo de estruturação de dados utiliza- do em bancos de dados relacionais que garante a consistência dos dados e remove sua duplicação.

Car

 

Color

Carkey

Markekey

Colorkey

Colorkey

Year

Colorkey

Color

1

1

1

 

2

2003

1 1 1   2 2003 1 Red

1

Red

 

2

2

1

3

2005

2

Green

3

2

1

2

2005

3

Blue

 
   
 

makemodel

 

Modelkey

Makekey

Model

 

make

1

1

Pathfinder

1 1 Pathfinder Makekey Make

Makekey

Make

1

2

Bluebird

 

1

Nissan

2

1

Civic

2

Honda

Example of a Typical Data Model

Bancos de dados relacionais são facilitados através de Sistemas Gerenciadores de Bancos de Da- dos Relacionais (SGBDR). Praticamente todos os sistemas de bancos de dados em uso atualmente são SGBDRs, incluindo Oracle, SQL Server, MySQL, Sybase, DB2, TeraData etc.

Os motivos para a dominância do modelo relacional não são triviais. Eles têm continuamente oferecido o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibili- dade no gerenciamento de dados genéricos.

Entretanto, para oferecer tudo isto, os bancos de dados tornaram-se incrivelmente complexos inter- namente. Por exemplo, um relativamente simples comando SELECT pode ter centenas de possíveis caminhos de execução de consulta, os quais o otimizador deve avaliar em tempo de execução. Tudo isto é escondido dos usuários, mas sob o capô os SGBDRs determinam o “plano de execução” que melhor atende nossas requisições utilizando recursos como algoritmos baseados em custo.

O problema com bancos de dados relacionais

Mesmo que os SGBDRs forneçam aos usuários o melhor conjunto de simplicidade, robustez, flexibi- lidade, desempenho, escalabilidade e compatibilidade, seu desempenho em cada uma destas áreas não é necessariamente melhor que o de uma solução alternativa buscando um destes benefícios isolado. Isto não foi um grande problema até agora, pois a dominância universal dos SGBDRs tem

um grande problema até agora, pois a dominância universal dos SGBDRs tem 78 BANCO DE DADOS
compensado a necessidade de se quebrar essas barreiras. No entanto, se você realmente tem uma

compensado a necessidade de se quebrar essas barreiras. No entanto, se você realmente tem uma necessidade que não pode ser atendida por um banco de dados relacional genérico, sempre houve alternativas para atender estes nichos.

Atualmente vivemos uma situação um pouco diferente. Para um grande número de aplicações, estes benefícios estão se tornando mais e mais críticos; e embora ainda sejam considerados um nicho, estão se tornando populares, tanto que para muitos usuários de bancos de dados estes requisitos estão começando a sobrepor os outros em importância. Este benefício é escalabilidade. À medida que mais e mais aplicações são implantadas em ambientes que possuem cargas de trabalho massi- vas, tais como serviços web, seus requisitos de escalabilidade podem mudar rapidamente e crescer a níveis muito elevados. O primeiro cenário pode ser difícil de gerenciar se você possui um banco de dados relacional implantado em um único servidor. Por exemplo, se sua carga triplica de um dia para o outro, quão rapidamente você pode ampliar o seu hardware? O segundo cenário pode ser complicado demais para ser gerenciado por um banco de dados relacional de um modo geral.

Bancos de dados relacionais escalam bem, mas isto somente quando a escalada acontece num úni- co servidor. Quando a capacidade daquele único servidor é alcançada, você precisa realizar uma escalabilidade horizontal e distribuir a carga entre múltiplos servidores. Este é o momento em que a complexidade dos bancos de dados relacionais limita o seu potencial de escalabilidade. Tente escalar para centenas ou milhares de servidores, ao invés de apenas alguns, e as complexidades tornam-se avassaladoras, e as características que tornam os SGBDRs tão atraentes drasticamente reduzem sua viabilidade como plataforma para grandes sistemas distribuídos.

Os fornecedores de serviços na nuvem tiveram que tratar esta limitação, pois uma plataforma na nu- vem sem uma base de dados escalável não chega a ser uma plataforma viável. Assim, para fornecer aos clientes uma plataforma escalável para armazenar seus dados, os fornecedores tiveram uma única solução. Estes fornecedores tiveram que implementar um novo tipo de sistema de banco de dados que focasse em escalabilidade, ao custo de outros benefícios dos bancos de dados relacionais.

Estes esforços, combinados com aqueles de fornecedores de nichos de mercado, levaram à criação de uma nova geração de sistemas gerenciadores de banco de dados.

A nova geração

Este novo tipo de sistema gerenciador de banco de dados é comumente chamado de chave-valor. De fato, não há ainda um nome oficial, então é possível encontrar nomes como orientado a documen- tos, orientado a atributos, banco de dados distribuído (embora bancos de dados distribuídos também possam ser relacionais), arrays particionados, tabelas hash distribuídas, e bancos de dados de chave- -valor. Embora cada um destes nomes aponte para peculiaridades específicas desta nova abordagem, são todas variações do mesmo tema, que chamaremos de bancos de dados de chave-valor.

Não importa como você chame, este “novo” tipo de banco de dados já está no mercado há algum

chame, este “novo” tipo de banco de dados já está no mercado há algum BANCO DE
tempo e tem sido utilizado em aplicações especializadas para as quais os bancos de dados

tempo e tem sido utilizado em aplicações especializadas para as quais os bancos de dados relacionais não serviam. Mas sem a escala que a web e a nuvem trouxeram, este novo tipo teria fica incógnito. Atualmente o desafio é identificar se este novo tipo de banco de dados ou um banco de dados relacio- nal é o mais adequado para uma aplicação particular.

Bancos de dados relacionais e bancos de dados de chave-valor são fundamentalmente diferentes e projetados para atender diferentes requisitos. Uma comparação lado-a-lado permite comparar super- ficialmente estas diferenças e apresentamos uma inicial abaixo:

Definições de banco de dados

Bancos de dados relacionais

Bancos de dados de chave-valor

Bancos de dados contêm tabelas, tabelas contêm linhas e colunas e linhas são com- postas dos valores das colunas. Linhas

Domínios podem ser visualizados inicial- mente como uma tabela, mas diferente- mente de uma tabela você não precisa definir um schema para um domínio. Um

dentro de uma mesma tabela possuem todas as mesmas definições de schema.

O modelo de dados é conhecido a priori. Um schema é fortemente tipado e possui restrições e relacionamentos que forçam a integridade dos dados.

O modelo de dados é baseado numa representação “natural” dos dados que contém, e não nas funcionalidades da aplicação.

O modelo de dados é normalizado para remover duplicações de dados. A norma- lização estabelece relacionamentos entre tabelas. Estes relacionamentos associam os dados entre as tabelas.

domínio é basicamente um “balde” em que você coloca itens. Itens dentro de um mesmo domínio podem ter diferentes schemas.

• Itens são identificados por chaves, e um dado item pode ter um conjunto de atribu- tos dinâmicos associado.

Em algumas implementações, atributos são do tipo String. Em outras implementa- ções, atributos possuem tipos simples que refletem os tipos do código tais como ints, arrays de String e listas.

• Não existem relacionamentos definidos de modo explícito entre domínios ou mesmo dentro de um mesmo domínio.

Sem Join de Entidades

Bancos de dados de chave-valor são orientados a itens, o que significa que todos os dados relevantes são armazenados dentro do próprio item. Um domínio (que você pode visualizar como uma tabela) pode conter itens muito diferentes um do outro. Por exemplo, um domínio pode conter itens de clientes e itens de pedidos. Isto significa que comumente os dados são duplicados entre itens num mesmo domínio. Esta é uma prática aceitável porque espaço em disco é algo relativamente barato. Mas este modelo permite que um único item contenha todos os itens relevantes, o que aumenta a escalabilida-

item contenha todos os itens relevantes, o que aumenta a escalabilida- 80 BANCO DE DADOS |
de ao eliminar a necessidade de joins entre múltiplas tabelas. Com um banco de dados

de ao eliminar a necessidade de joins entre múltiplas tabelas. Com um banco de dados relacional, os dados teriam que ser unidos para poder reagrupar todos os atributos relevantes.

Embora a necessidade de relacionamentos seja bastante reduzida com bancos de dados chave- -valor, alguns ainda são inevitáveis. Estes relacionamentos costumam existir entre entidades chave do modelo. Por exemplo, um sistema de pedidos pode ter itens que contenham dados sobre clientes, produtos e outros. Não importa se estes dados residam no mesmo domínio ou em domínios diferen- tes; quando um cliente cria um pedido você provavelmente não quer armazenar os atributos tanto do cliente quanto do produto no mesmo item do pedido.

Ao invés disso, pedidos precisam armazenar as chaves dos itens de cliente e produto. Embora isso seja perfeitamente possível em bancos de dados chave-valor, estes relacionamentos não estão defini- dos no modelo de dados em si, e portanto o sistema gerenciador de banco de dados não pode forçar a integridade dos relacionamentos. Isto significa que você pode excluir clientes e produtos que possuem pedidos feitos. A responsabilidade por garantir a integridade dos dados cai toda sobre a aplicação.

Acesso a dados

Bancos de dados relacional

Banco de dados chave-valor

Dados são criados, atualizados, removidos e consultados através de SQL.

Dados são criados, atualizados, removidos e consultados através de APIs.

Consultas SQL podem acessar os dados de uma única ou de múltiplas tabelas através de joins.

Algumas implementações fornecem uma sinta- xe básica parecida com SQL para definir crité- rios de filtragem.

Consultas SQL incluem funções de agregação e filtros complexos.

Somente predicados básicos de filtragem po- dem ser aplicados na maioria das vezes.

Normalmente possuem meios de se embutir lógica próximo aos dados através de triggers e stored procedures.

A lógica de integridade da aplicação e seus dados está toda implementada no código da própria aplicação.

Interface com a aplicação

Bancos de dados relacional

Banco de dados chave-valor

Tendem a oferecer uma API própria ou uma API genérica como o ODBC ou JDBC.

Tendem a oferecer APIs SOAP e/ou REST para acesso aos dados.

Os dados são armazenados num formato que representa sua estrutura natural, de modo que deve haver um mapeamento entre as estrutu- ras do código da aplicação e a estrutura rela- cional.

Os dados podem ser armazenados de modo mais eficiente em compatibilidade com o código da aplicação, requerendo pouca infraestrutura para suportá-lo.

vantagens de bancos de dados chave-valor

Existem duas claras vantagens dos bancos de dados chave-valor sobre os bancos de dados relacio- nais.

Adequado para a nuvem

O primeiro benefício é que os bancos de dados chave-valor são simples e portanto escalam melhor que os bancos de dados relacionais atuais. Se você está desenvolvendo um sistema com uma equipe

interna e pretende colocar dezenas ou centenas de servidores na sua base de dados para

interna e pretende colocar dezenas ou centenas de servidores na sua base de dados para atender o que você acredita que seja uma quantidade massiva de dados, então considere seriamente um banco de dados chave-valor.

Como bancos de dados chave-valor escalam facilmente e de modo dinâmico, também são os banco de dados preferidos de serviços de fornecedores de armazenamento através de web services com potencial de escalabilidade. Usuários tipicamente pagam somente pelo que usam, mas seu uso au- menta à medida em que a demanda aumenta. Enquanto isso o fornecedor pode escalar a plataforma dinamicamente baseado na carga total do usuário, com pouquíssimas limitações provocadas pelo tamanho da plataforma.

melhor adaptado para o código

Modelos de dados relacionais e modelos de código de aplicações são tipicamente construídos de modo diferente, o que leva a incompatibilidades. Desenvolvedores normalmente superam estas in- compatibilidades com código que mapeiam os seus objetos ao modelo relacional, um processo co- mumente denominado de mapeamento objeto-relacional. Este processo, que essencialmente requer muito código de infraestrutura e não possui valor de negócios imediato, pode demandar uma parcela considerável do tempo e do esforço do desenvolvimento da aplicação.

Outros argumentos a favor deste tipo de banco de dados, tais como “bancos de dados relacionais podem se tornar pesados ou desajeitados” não são convincentes. Mas antes de entrar de cabeça no mundo dos bancos de dados chave-valor, considere algumas limitações existentes.

Desvantagens de bancos de dados chave-valor

As restrições inerentes de um banco de dados relacional garantem que os dados em seu nível mais baixo possuem integridade. Dados que violam as restrições de integridade não podem ser inseridos fisicamente no banco de dados. Estas restrições não existem em bancos de dados de chave-valor, então a responsabilidade de garantir a integridade dos dados é da aplicação. Mas o código da apli- cação pode conter bugs. Bugs num banco de dados relacional devidamente projetado normalmente não levam a problemas de integridade de dados; bugs num banco de dados chave-valor, entretanto, facilmente levam a problemas de integridade de dados.

Um dos principais benefícios de um banco de dados relacional é que ele te força a um processo de modelagem de dados. Se bem feito, o processo de modelagem cria uma estrutura lógica no banco de dados que reflete os dados contidos, ao invés de refletir a estrutura da aplicação. Dados, então, tornam-se quase que independentes de aplicação, o que reflete que outras aplicações podem utilizar o mesmo conjunto de dados e a lógica da aplicação pode ser alterada sem modificar o modelo de dados.

Não se esqueça também da compatibilidade. Diferentemente de bancos de dados relacionais, ban- cos de dados na nuvem não costumam seguir padrões definidos. Embora todos tenham conceitos similares, cada um possui sua própria API, interfaces de consulta específicas e peculiaridades. Desse

própria API, interfaces de consulta específicas e peculiaridades. Desse 82 BANCO DE DADOS | Educação a
modo, você terá que confiar em seu fornecedor, pois você não poderá simplesmente trocá-lo depois

modo, você terá que confiar em seu fornecedor, pois você não poderá simplesmente trocá-lo depois se estiver descontente.

Limitações de análise

Na nuvem, bancos de dados chave-valor são compartilhados, o que significa que muitos usuários e aplicações utilizam o mesmo sistema. Para prevenir que um único processo sobrecarregue o ambiente compartilhado, muitos fornecedores na nuvem limitam o impacto total que uma consulta simples pode causar. Por exemplo, no SimpleDB, você não pode executar uma consulta que leve mais que 5 segun- dos. Com o Google AppEngine, você não pode retornar mais que 1000 itens por consulta.

Estas limitações não são problemas para aplicações comuns com adição, atualização, remoção e consulta de poucos itens. Mas o que ocorre quando sua aplicação torna-se bem sucedida? Você atraiu muitos usuários e ganhou muitos dados, e agora você quer criar valor agregado para seus usuários ou utilizar os dados para gerar outras fontes de receita. Neste caso talvez os limites de consulta impostos pelos fornecedores de nuvem possam limitá-lo severamente. Situações como criação de padrões de uso e fornecimento de recomendações baseado no histórico do usuário podem tornar-se difíceis e talvez impossíveis em algumas plataformas.

Neste caso, você provavelmente irá implementar um banco de dados analítico em separado, populado a partir de seu banco de dados chave-valor, para que estas análises sejam executadas. Planeje com antecedência onde e como você o fará. Você o hospedaria na nuvem ou on premise? A latência entre você e o provedor na nuvem seria um problema? Seu banco de dados chave-valor suporta isso? Se você possui 100 milhões de itens em seu banco de dados chave-valor, e você pode somente consultar 1000 de cada vez, quantas consultas isso levaria?

Em último caso, embora escalabilidade seja um fator sério a considerar, mas se esqueça da sua necessidade de converter os dados em uma fonte de receita. Toda a escalab do mundo é inútil se os seus usuários migrarem para seu concorrente porque ele possui funcionalidades mais interessantes.

Competidores de serviços baseados em nuvem

Um bom número de fornecedores de serviços web agora oferece bancos de dados chave-valor com- partilhados no estilo pague-pelo-uso. A maioria deles atende aos critérios definidos até agora, mas cada um possui funcionalidades únicas que variam dos padrões que descrevemos até agora. Descre- veremos agora de um modo geral alguns bancos de dados particulares, como o SimpleDB, Google AppEngine Datastore e SQL Data Services.

Amazon: SimpleDB

o SimpleDB, Google AppEngine Datastore e SQL Data Services. Amazon: SimpleDB BANCO DE DADOS | Educação
O SimpleDB é um banco de dados de chave-valor orientado a atributos disponível na plataforma
O SimpleDB é um banco de dados de chave-valor orientado a atributos disponível na plataforma

O SimpleDB é um banco de dados de chave-valor orientado a atributos disponível na plataforma da

Amazon Web Services.

O SimpleDB possui diversas limitações. Primeiro, uma consulta pode ser executada por no máximo

5 segundos. Segundo, não há tipos de dados além de Strings. Tudo é armazenado, recuperado e comparado como uma String. Comparações de data não funcionarão a não ser que você converta todas as datas para o formato ISO8601. Terceiro, o tamanho máximo de uma String é limitado a 1024 bytes, o que limita quanto de texto (por exemplo, descrições de produtos) você pode armazenar num único atributo. Mas como o schema é dinâmico e flexível, você pode contornar este limite adicionado “descricao1”, “descricao2” etc. O problema é que cada item é limitado em 256 atributos.

Uma característica chave do SimpleDB é o seu modelo de consistência eventual. Este modelo de consistência é bom para concorrência, mas significa que se você alterou o atributo de um item, estas mudanças não serão refletidas imediatamente nas operações de leitura. Embora as chances de algum problema ocorrer em função disso sejam pequenas, você deve se preparar para estas situações. Por exemplo, você não deseja vender o último ingresso de um show para cinco pessoas diferentes no seu sistema de eventos.

google AppEngine Data Store

no seu sistema de eventos. google AppEngine Data Store O Google AppEngine Datastore é construído sobre

O Google AppEngine Datastore é construído sobre o BigTable, o sistema interno do Google para

manipulação de dados estruturados. Em si, o AppEngine não é um mecanismo de acesso direto ao BigTable, mas pode ser considerado como uma interface simplificada sobre o BigTable.

O AppEngine Datastore suporta muito mais tipos de dados que os itens do SimpleDB, incluindo tipos

de lista, que contém coleções de elementos num único item.

Você provavelmente utilizará este banco de dados se planeja construir aplicações no Google AppEn- gine. Entretanto, diferentemente do SimpleDB, você não consegue interfacear diretamente com o AppEngine Datastore (ou com o BigTable) utilizando uma aplicação foram da nuvem do Google.

microsoft: SQl Data Services

uma aplicação foram da nuvem do Google. microsoft: SQl Data Services 84 BANCO DE DADOS |
O SQL Data Services é parte da plataforma de serviços web Microsoft Azure. O serviço
O SQL Data Services é parte da plataforma de serviços web Microsoft Azure. O serviço

O SQL Data Services é parte da plataforma de serviços web Microsoft Azure. O serviço do SDS é

na verdade uma aplicação em si que roda sobre vários SQL Servers, que formam o mecanismo de armazenamento da plataforma. Embora os bancos de dados de infraestrutura sejam relacionais, você não precisa acessá-los; SDS é um banco de dados chave-valor, assim como as outras plataformas discutidas até agora.

A Microsoft parece estar sozinha neste cenário ao concordar que embora bancos de dados chave-

-valor sejam ótimo para escalabilidade, esta escalabilidade vem ao custo do gerenciamento de dados, quando comparado a SGBDRs. A abordagem da Microsoft parece ser focar no fundamental para con- seguir implementar os mecanismos de escalabilidade e distribuição direito, e com o passar do tempo, adicionar funcionalidades que ajudarão a diminuir a diferença entre bancos de dados chave-valor e relacionais.

Fornecedores on-premise

Fora da nuvem, existem vários produtos de bancos de dados chave-valor que podem ser instalados on-premise. A maioria é open source; tendo acesso ao código-fonte talvez você possa analisar e tornar-se melhor ciente de potenciais problemas e limitações – uma vantagem que você não teria em fornecedores de código fechado.

CouchDB

você não teria em fornecedores de código fechado. CouchDB CouchDB é um banco de dados orientado

CouchDB é um banco de dados orientado a documentos livre e open-source. Derivado de um banco

de dados chave-valor, utiliza JSON para definir o schema de seus itens. O CouchDB tenta diminuir

a distância entre bancos de dados orientados a documentos e relacionais ao permitir que “visões” sejam criadas dinamicamente com JavaScript. Estas visões mapeiam os dados do documento numa estrutura parecida com tabelas que podem ser indexadas e consultadas.

Até o momento, o CouchDB não é realmente um banco de dados distribuído. Ele possui funções de replicação que permite que os dados sejam sincronizados entre servidores, mas não é o tipo de distribuição suficiente para construir ambientes de alta escalabilidade. A comunidade do CouchDB, entretanto, está trabalhando disso.

projeto voldemort

do CouchDB, entretanto, está trabalhando disso. projeto voldemort BANCO DE DADOS | Educação a Distância 85
O projeto Voldemort é um banco de dados distribuído chave-valor cujo objetivo é escalar horizontal-

O projeto Voldemort é um banco de dados distribuído chave-valor cujo objetivo é escalar horizontal-

mente num grande número de servidores. Ele surgiu como um trabalho desenvolvido no LinkedIn e é

utilizado no LinkedIn em alguns poucos sistemas que possuem requisitos elevados de escalabilidade.

O projeto Voldemort também utiliza um modelo de consistência eventual.

mongoDB

também utiliza um modelo de consistência eventual. mongoDB O MongoDB é um sistema de banco de

O MongoDB é um sistema de banco de dados desenvolvido pela 10gen por Geir Magnusson e Dwight

Merriman. Assim como o CouchDB, o MongoDB é um banco de dados orientado a documentos base- ado em JSON, excetuando-se o fato de que ele é um verdadeiro banco de dados de objetos ao invés de ser puramente chave-valor.

tomando uma decisão

Basicamente há quatro motivos para se escolher uma plataforma de banco de dados não relacional chave-valor para sua aplicação:

1. Seus dados são orientados a documentos, tornando-os uma escolha natural para o modelo de chave-valor ao invés do modelo relacional.

2. Seu ambiente de desenvolvimento é altamente orientado a objetos, e um banco de dados chave- -valor pode diminuir a quantidade de código de infraestrutura.

3. O banco de dados é barato e integra com sua plataforma de serviços web.

4. Sua principal preocupação é a alta escalabilidade sob demanda – ou seja, uma escalabilidade distribuída de larga escala que não pode ser obtida com escalabilidade vertical.

Ao tomar sua decisão, lembre-se das limitações e dos riscos que você corre ao sair da “zona de con- forto” do modelo relacional.

Para todos os outros requisitos, provavelmente você estará melhor servidor pelo bom e velho modelo relacional. Portanto, estariam os bancos de dados relacionais condenados? Claramente não. Pelo menos por enquanto.

Fonte: <http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php>. Acesso em: 14 ago. 2012.

Acesso em: 14 ago. 2012. 86 BANCO DE DADOS | Educação a Distância
Acesso em: 14 ago. 2012. 86 BANCO DE DADOS | Educação a Distância

CONSiDErAçÕES FiNAiS

CONSiDErAçÕES FiNAiS Nesta unidade, inicialmente descrevemos os conceitos de domínio, tuplas, atributos e relações do

Nesta unidade, inicialmente descrevemos os conceitos de domínio, tuplas, atributos e relações do modelo relacional. A abordagem deste autor para explicar o modelo relacional é a de tentar fugir um pouco das definições formais matemáticas do modelo e focar nos conceitos fundamentais do modo mais próximo possível ao cotidiano de desenvolvimento de software. Propositadamente deixamos de lado aspectos de álgebra relacional, que podem ser aprofundados em excelentes livros como o de Silberschatz (1999) e Date (1988).

No modelo relacional há uma série de restrições impostas para que se possa garantir a consistência dos dados presentes nos diferentes domínios, bem como a consistência do próprio modelo. As restrições discutidas foram de domínio, de chave, de valores nulos, de integridade e de integridade referencial e chaves estrangeiras. Estas restrições são os atributos que tornam o modelo relacional tão interessante e tão conceituado perante alguns desenvolvedores e, claro, DBAs. Enxergar o sistema de banco de dados como uma aplicação terceira que deve ser integrada ao software que desenvolvemos é uma visão que nos permite entender o porquê de tamanha valorização das restrições. De fato, com estas restrições (quando bem implementadas), há a garantia da integridade e consistência das informações armazenadas.

As operações de modificação do modelo relacional descritas no modelo relacional são as operações de Insert, Update e Delete e todas podem provocar violações do modelo – sendo cada uma delas abordada em suas respectivas seções.

Agora que já temos toda a base conceitual do popular modelo de dados relacional, podemos passar a interagir e executar operações com os sistemas de bancos de dados relacionais. Para nossa sorte, há um padrão bem estabelecido e sólido de interação com os SGBDs relacionais, que é a linguagem SQL. O assunto SQL é tão importante e será tão utilizado em sua vida profissional que dedicaremos as duas próximas unidades para tratá-lo.

AtiviDADES DE AutOEStuDO

AtiviDADES DE AutOEStuDO

1. Por que não existe uma ordem definida para as tuplas dentro de uma relação?

2. Quais são as situações em que é adequada a utilização de valores NULL?

3. Defina os conceitos de integridade e integridade referencial.

uNiDADE iv

SQl BáSiCO

Professor Me. Edson Yanaga

Objetivos de Aprendizagem

• Definir o que é SQL.

• Apresentar os comandos de definição e uso da SQL.

plano de Estudo

A seguir, apresentam-se os tópicos que você estudará nesta unidade:

• Definição e histórico da SQL

• Descrição dos comandos de definição de dados e tipos em SQL

• Descrição dos comandos de consulta básicos em SQL

• Descrição dos comandos de modificação de dados em SQL

iNtrODuçãO

iNtrODuçãO Fonte: SHUTTERSTOCK.COM A primeira ideia que vem à cabeça de um desenvolvedor experiente quando se
Fonte: SHUTTERSTOCK.COM
Fonte: SHUTTERSTOCK.COM

A primeira ideia que vem à cabeça de um desenvolvedor experiente quando se fala de banco

de dados relacionais é SQL. Realmente, talvez uma das boas razões pelas quais os SGBDs relacionais são tão difundidos deve-se ao fato de que a SQL é uma ferramenta bastante madura, elaborada e bem projetada.

Em português, pronuncia-se SQL como uma sigla, com o som de cada uma das letras separadas, “esse-quê-ele”. Porém, nas conversas em projetos internacionais que você fará, ou em conferências que você participará em sua vida profissional, perceberá que em inglês SQL é pronunciado como “síquel”. O motivo é curioso e não tem a ver com a sigla SQL, e sim com o nome original desta linguagem. Atualmente, a sigla SQL significa Structured Query Language (Linguagem de Consulta Estruturada), mas originalmente seu nome era SEQUEL:

Structured English QUEry Language (Linguagem de Consulta em Inglês Estruturado) – daí o motivo da pronúncia como “síquel”.

SQL é uma linguagem diferente das linguagens de programação que você provavelmente aprendeu até agora. Em qualquer curso de programação, costuma-se ensinar inicialmente linguagens de programação imperativas (como C, Pascal, Java ou Python), em que você

é responsável por escrever os comandos na ordem de execução esperada. Neste tipo de

por escrever os comandos na ordem de execução esperada. Neste tipo de BANCO DE DADOS |
linguagem, preocupamo-nos em instruir o computador no modo como ele deve executar as tarefas. O

linguagem, preocupamo-nos em instruir o computador no modo como ele deve executar as tarefas. O resultado de seu processamento é uma consequência daquilo que comandamos. Já a SQL é uma linguagem declarativa, pois nela define-se o quê deve ser retornado como resultado do processamento, sem especificar o como isso será feito.

Permita uma reflexão sobre a natureza declarativa da SQL. Na SQL, ao definirmos somente o que esperamos de resultado ao invés do como, permitimos que o SGBD decida como é que ele deve executar as instruções. Há 10 anos, este seria um fator determinante para decidir entre um produto e outro. A evolução dos produtos comerciais e livres fez com que esta diferença diminuísse de modo significativo – embora, dependendo dos casos de uso de sua aplicação, a diferença ainda possa ser relevante. Em alguns casos, centenas de parâmetros de configuração do produto permitem alterar a forma com que o SGBD executa o “como”:

uma tarefa que muitas vezes chega a ser minuciosa – tudo isso para conseguir aumentar o desempenho do seu SGBD.

Para tentar diminuir as diferenças entre as diversas implementações e variantes da SQL utilizadas em produtos distintos, a ANSI (American National Standards Institute) e a ISO (International Standards Organization) uniram-se para criar um padrão para a SQL. A versão mais popular deste padrão é a SQL-92, embora haja uma versão mais recente: a SQL:1999. Infelizmente, os fabricantes de SGBDs não seguem 100% o padrão, o que torna a tarefa de migração de um produto para outro um pouco mais difícil. Comercialmente, é uma estratégia interessante para os fabricantes, pois baseia-se no aprisionamento do cliente: uma vez comprometido com um produto, o custo para migração (em tempo e esforço) torna-se elevado o suficiente para que o cliente desista da ideia. Já para os usuários, este é um fato infeliz. De positivo do padrão SQL- 92 temos que mesmo com as sutis diferenças entre as implementações da SQL em diferentes produtos, as semelhanças se sobressaem e permitem que os desenvolvedores de software possam aprender facilmente a lidar com produtos concorrentes.

A SQL possui comandos tanto para a criação de definições de dados (criação de schemas) quanto para a execução de comandos de manipulação de banco de dados (consultas e

a execução de comandos de manipulação de banco de dados (consultas e 92 BANCO DE DADOS
atualizações). É uma linguagem bastante abrangente. É por este motivo que trataremos da SQL em

atualizações). É uma linguagem bastante abrangente. É por este motivo que trataremos da SQL em duas unidades distintas. Esta primeira abordará a criação de schemas e os comandos básicos da linguagem, enquanto que a próxima unidade abordará os comandos um pouco mais avançados.

DEFiNiçÕES DE DADOS E tipOS Em SQl

Na unidade anterior, definimos os termos relação, tupla e atributo do modelo relacional. Em SQL, estes termos são denominados respectivamente de tabela, linha e coluna. Boa parte dos comandos SQL relacionados à criação e definição de dados utiliza o comando CREATE.

O conceito de schema

Em sua versão inicial, a SQL não possuía um mecanismo para agrupar tabelas relacionadas. Como consequência, todas as tabelas no SGBD coexistiam dentro de um mesmo “ambiente”.

A partir do SQL-92, criou-se o conceito de schema, que é simplesmente um conjunto de

tabelas relacionadas. Do mesmo modo que em UML um pacote é um conjunto de classes relacionadas, um schema