Banco de Dados

Prof. Me.
Edson Yanaga
BANCO DE DADOS
grADuAO ANliSE 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 Administrao: Wilson de Matos Silva Filho presidente da mantenedora: Cludio Ferdinandi
NEAD - Ncleo de Educao a Distncia

Diretoria do NEAD: Willian Victor Kendrick de Matos Silva Coordenao pedaggica: Gislene Miotto Catolino Raymundo Coordenao de marketing: Bruno Jorge Coordenao Comercial: Helder Machado Coordenao de tecnologia: Fabrcio Ricardo Lazilha Coordenao de Curso: Danillo Xavier Saes Supervisora do Ncleo de produo de materiais: Nalva Aparecida da Rosa Moura Capa e Editorao: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, Jos Jhonny Coelho, Luiz Fernando Rokubuiti e Thayla Daiany Guimares Cripaldi Superviso de materiais: Ndila de Almeida Toledo reviso textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janana Bicudo Kikuchi, Jaquelina Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR
C397
CENTRO UNIVERSITRIO DE MARING. Ncleo de Educao a distncia: Banco de dados / Edson Yanaga. Maring - PR, 2012. 143 p. Graduao em Anlise e Desenvolvimento de Sistemas e Sistemas para Internet - EaD. 1. Banco de dados. 2. Arquitetura de sistemas. 3.EaD. I. Ttulo. 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. Aclimao - (44) 3027-6360 - CEP 87050-390 - Maring - Paran - www.cesumar.br NEAD - Ncleo de Educao a Distncia - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br
BANCO DE DADOS
Prof. Me. Edson Yanaga
AprESENtAO DO rEitOr
Viver e trabalhar em uma sociedade global um grande desafio para todos os cidados. A busca por tecnologia, informao, conhecimento de qualidade, novas habilidades para liderana e soluo de problemas com eficincia tornou-se uma questo de sobrevivncia no mundo do trabalho. Cada um de ns tem uma grande responsabilidade: as escolhas que fizermos por ns e pelos nossos far grande diferena no futuro. Com essa viso, o Cesumar Centro Universitrio 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 misso promover a educao de qualidade nas diferentes reas do conhecimento, formando profissionais cidados que contribuam para o desenvolvimento de uma sociedade justa e solidria , o Cesumar busca a integrao do ensino-pesquisa-extenso com as demandas institucionais e sociais; a realizao de uma prtica acadmica que contribua para o desenvolvimento da conscincia social e poltica e, por fim, a democratizao do conhecimento acadmico com a articulao e a integrao com a sociedade. Diante disso, o Cesumar almeja ser reconhecido como uma instituio universitria de referncia regional e nacional pela qualidade e compromisso do corpo docente; aquisio de competncias institucionais para o desenvolvimento de linhas de pesquisa; consolidao da extenso universitria; qualidade da oferta dos ensinos presencial e a distncia; bem-estar e satisfao da comunidade interna; qualidade da gesto acadmica e administrativa; compromisso social de incluso; processos de cooperao e parceria com o mundo do trabalho, como tambm pelo compromisso e relacionamento permanente com os egressos, incentivando a educao continuada. Professor Wilson de Matos Silva Reitor
BANCO DE DADOS | Educao a Distncia
Caro(a) aluno(a), ensinar no transferir conhecimento, mas criar as possibilidades para a sua produo ou a sua construo (FREIRE, 1996, p. 25). Tenho a certeza de que no Ncleo de Educao a Distncia do Cesumar, voc ter sua disposio todas as condies 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 formao e contemplam as diretrizes curriculares dos cursos de graduao, determinadas pelo Ministrio da Educao (MEC). Desta forma, buscando atender essas necessidades, dispomos de uma equipe de profissionais multidisciplinares para que, independente da distncia geogrfica que voc esteja, possamos interagir e, assim, fazer-se presentes no seu processo de ensino-aprendizagem-conhecimento. Neste sentido, por meio de um modelo pedaggico 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, alm do material produzido em linguagem dialgica, aulas sobre os contedos 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 formao, tm por intuito possibilitar o desenvolvimento de novas competncias necessrias para que voc se aproprie do conhecimento de forma colaborativa. Portanto, recomendo que durante a realizao de seu curso, voc procure interagir com os textos, fazer anotaes, responder s atividades de autoestudo, participar ativamente dos fruns, ver as indicaes de leitura e realizar novas pesquisas sobre os assuntos tratados, pois tais atividades lhe possibilitaro organizar o seu processo educativo e, assim, superar os desafios na construo 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 igualitria. Um grande abrao e timos momentos de construo de aprendizagem! Professora Gislene Miotto Catolino Raymundo Coordenadora Pedaggica do NEAD- CESUMAR
AprESENtAO
livro: BANCO DE DADOS
Professor Me. Edson Yanaga
Salve, carssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco de Dados, elaborado especificamente para contribuir na sua formao 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 Cincia da Computao pela Universidade Estadual de Maring (UEM) e Mestre em Engenharia Eltrica e Informtica Industrial pela Universidade Tecnolgica Federal do Paran (UTFPR) na rea de Telemtica. Sou empresrio (consultor e desenvolvedor) na rea de software e trabalho com a plataforma Java desde 1997 completando 15 anos de experincia neste ano de 2012. Trabalho tambm como administrador de sistemas Unix (Solaris, HP-UX e Linux) desde 2000, e desde 2008 j era adepto e entusiasta da computao em nuvem (cloud computing). Participo de vrios cursos em nvel de especializao em diversas instituies, como Cesumar, UEM, UNIPAR e Faculdade Integrado; e sou coordenador do curso de Especializao em Desenvolvimento Orientado a Objetos em Java do Cesumar desde 2004. Possuo as seguintes certificaes: 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 lder do Redfoot JUG (Java Users Group) Grupo de Usurio Java do Norte do Paran atuo desde 2004. Tive o prazer de ser membro do comit tcnico do JavaOne Latin America nas edies de 2010 e 2011. Apresento palestras em diversos eventos em nvel nacional e internacional, e ultimamente sou um grande entusiasta do Artesanato de Software e do cdigo bem-feito. Confesso que foi um tremendo desafio escrever este material. At certo ponto uma repetio cansativa dizer que o ritmo das mudanas e inovaes cada vez mais se acelera, mas a princpio 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 transformaes que chacoalharam os alicerces de fundamentos criados e utilizados desde a dcada de 1970. Os desafios dos sistemas de
informao atuais exigem que manipulemos no gigabytes ou terabytes de informaes, e sim petabytes, exabytes e zetabytes. Sistemas de informao das geraes anteriores tinham como objetivo gerar informaes que pudessem agregar valor aos processos de negcios. Pois bem, esse objetivo foi alcanado. Com a to aguardada e estimulada onipresena de software, a magnitude destas informaes geradas cresceu. Redes sociais, smartphones, tablets, sensores de automao e vrios outros dispositivos geram inmeros bits de informao a todo momento. Conceitos antigos j no so soberanos nesses ambientes inspitos atuais. Diante destes cenrios 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 no se engane, caro(a) leitor(a), estes fundamentos de bancos de dados relacionais so imprescindveis para que se possa dar o prximo passo rumo ao conhecimento de Big Data e NoSQL. Na Unidade I teremos a apresentao de tpicos conceituais e definies sobre bancos de dados, sistemas gerenciadores de bancos de dados e os tipos de usurios que interagem com esses sistemas. Teremos tambm uma breve explanao sobre o conceito de transaes, que uma ferramenta essencial no desenvolvimento de aplicaes mais tradicionais como aquelas que envolvem dados financeiros. Como leitura complementar, temos um texto de Cezar Taurion (Evangelista Tcnico da IBM) falando sobre Big Data. Afinal, importante darmos um passo no presente mas sempre com um olho no futuro. Essa ser a tnica das nossas leituras complementares e sugestes de vdeos: apresentar-lhe sempre os conceitos de vanguarda que j so aplicados em muitos casos de uso em aplicaes modernas. A Unidade II descrever a terminologia e outros conceitos bsicos que sero utilizados no restante deste material, tais como a diferenciao entre schemas e instncias 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 alm de auxili-lo(a) na escolha dos diferentes tipos de produtos existentes e tambm 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 caractersticas de modelos relacionais e passar a construir seus prprios modelos de dados baseado nos fundamentos apresentados. Na modelagem relacional, voc identificar entidades do seu domnio de negcios, suas restries 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 no ser um problema para voc, futuro(a) desenvolvedor(a) de software bem feito. Mas convm 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). Aps sua criao, a SQL tornou-se um padro de facto para manipular informaes em sistemas de banco de dados por meio de seus comandos para insero, atualizao, remoo e consulta de instncias de dados. E antes que voc possa apreciar o contedo do material, permita-me apresentar meu ponto de vista para reflexo: em muitas empresas o sistema de banco de dados tornou-se o repositrio sagrado das informaes, trancado a sete chaves e reservado ao guardio denominado de DBA (DataBase Administrator). Alis, bastante comum que os alunos aprendam ou venham a concluir que o banco de dados o corao de um sistema de informao baseados nessas falsas impresses transmitidas at certo ponto em grande quantidade. Para mim e tambm para muitos autores renomados do mundo do software, o banco de dados apenas uma ferramenta utilizada na construo de nossos sistemas de informao. E como toda e qualquer ferramenta, no pode ficar acima do prprio cdigo que atende ao processo de negcios da empresa. Isso diminui sua importncia? Certamente que no! Mas quando modelar seu sistema de informao, pense primeiro no seu modelo de negcios e postergue at o ltimo momento a sua viso sobre o banco de dados. Tenho certeza de que isso tornar a sua aplicao muito melhor projetada e permitir que ela oferea um retorno muito melhor ao seu negcio. O banco de dados s um detalhe. Um detalhe importante, mas o considere um detalhe. O corao da sua aplicao o cdigo bem feito que voc elaborar para atender ao seu negcio. Pense nisso, e a cada batida desse corao voc poder usufruir de muito retorno (e muito dinheiro, espero). Um bom proveito e uma tima leitura. Prof. Me. Edson Yanaga
SumriO
uNiDADE i CONCEITOS DE BANCOS DE DADOS CARACTERSTICAS DE SISTEMAS DE BANCOS DE DADOS............................................20 TRANSAES........................................................................................................................27 VANTAGENS DE SE UTILIZAR UM SGBD ............................................................................31 uNiDADE ii OS BANCOS DE DADOS E O SOFTWARE SCHEMAS, INSTNCIAS E ABSTRAES ..........................................................................42 INTERFACES DOS SGBDS ....................................................................................................43 ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS ...................................................46 MODELO CENTRALIZADO ....................................................................................................47 CLASSIFICAO DOS SISTEMAS DE BANCO DE DADOS ................................................56 uNiDADE iii O MODELO RELACIONAL CONCEITUAO ....................................................................................................................68 RESTRIES DO MODELO RELACIONAL ..........................................................................71 uNiDADE iv SQL BSICO DEFINIES DE DADOS E TIPOS EM SQL .........................................................................93
RESTRIES .........................................................................................................................97 CONSULTAS BSICAS EM SQL ............................................................................................99 COMANDOS DE MODIFICAO DE DADOS EM SQL.......................................................104 uNiDADE v MAIS SQL CONSULTAS ENVOLVENDO NULL ..................................................................................... 118 CONSULTAS UTILIZANDO JOINS .......................................................................................124 CONSULTAS COM FUNES DE AGREGAO ...............................................................126 COMANDOS DE ALTERAO DE SCHEMA ......................................................................128
CONCluSO........................................................................................................................ 141 rEFErNCiAS .....................................................................................................................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 interao dos usurios com os bancos de dados. Comparar as vantagens desta abordagem em relao a outras similares. plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Conceituar bancos de dados, sistemas gerenciadores de banco de dados e sistemas de banco de dados Apresentar as principais caractersticas de sistemas de banco de dados Enumerar alguns papis de usurios envolvidos na interao com sistemas de bancos de dados Descrever algumas vantagens na utilizao de sistemas de bancos de dados comparados a outras abordagens
iNtrODuO
Scientia potentia est: Conhecimento poder. Sim, caro(a) leitor(a), conhecimento poder. Informao poder. Na sociedade do sculo XXI, chamamos estas informaes armazenadas em sistemas computacionais de dados. E temos informao em abundncia. O desafio crescente dos prximos anos encontrar formas eficientes de processar os dados que j temos e ainda criar para gerar conhecimento e, consequentemente, riqueza. Nas ltimas dcadas, boa parte do software desenvolvido envolve alm do processamento de informaes: as informaes de entrada e de sada do software (alm de outras metainformaes intermedirias) devem ser armazenadas em um mecanismo confivel, e que possibilite o acesso simples e rpido leitura e escrita destas informaes. 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 mudana e os modelos de negcios que surgiram recentemente provocaram uma ruptura na forma de se pensar no armazenamento de informaes em bancos de dados.
Fonte: SHUTTERSTOCK.COM
15
Mas de onde vem este termo que conhecemos como banco de dados? Pois em ingls, o termo refere-se a databases, que numa traduo literal definiramos como base de dados. Um bom palpite remete a uma viso generalizada de que as instituies denominadas de bancos guardam de modo bastante seguro o nosso dinheiro. Os bancos de dados seriam ento ferramentas que guardariam nossas informaes (dados) de modo tambm supostamente seguro e confivel. Outra confuso bastante comum e plenamente justificada refere-se diferena entre os termos banco de dados e os sistemas que o gerenciam. Segue uma definio segundo Navathe (2011, p.3):
Um banco de dados uma coleo de dados relacionados. Os dados so fatos que podem ser gravados e que possuem um significado implcito. Por exemplo, considere nomes, nmeros telefnicos e endereos 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 informaes so uma coleo de dados com um significado implcito, consequentemente, um banco de dados.
Nossos bancos de dados podem ser colees de dados relacionados dos mais diversos tamanhos. Desde uma pequena agenda contendo nmeros e contatos de pessoas at um ndice gigantesco de pginas de Internet e buscas relacionadas ou todas as mensagens e informaes trocadas entre bilhes de usurios de uma rede social. Em termos computacionais, h uma categoria de software especializado que desenvolvido especificamente com o propsito de se gerenciar estas colees de dados: os sistemas gerenciadores de banco de dados popularmente reconhecidos pela sigla SGBD (ou DBMS DataBase Management Systems, na sigla original em ingls). Segue mais uma definio de Navathe (2011, p.3), sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) uma coleo de programas que permite aos usurios criar e manter um banco de dados. O SGBD , portanto, um sistema de software de propsito geral que facilita os processos de definio, construo, manipulao e compartilhamento de bancos de dados entre vrios usurios e aplicaes. A definio de um banco de dados implica especificar os tipos de dados,
16
as estruturas e as restries para os dados a serem armazenados em um banco de dados.
Embora no seja necessrio utilizar um SGBD para se desenvolver quaisquer sistemas de software, tal opo no se mostra vivel. Relembrando o nosso conceito de que a importncia do software consiste em sua capacidade de se gerar valor com as informaes que manipula, tem-se que implementar nosso prprio mecanismo de manipulao de dados em nossas aplicaes no 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 no relacionais (tambm conhecidos como NoSQL) incluem MongoDB, Redis, Neo4j e Riak. Para propsitos de definio, finalizaremos denominando o conjunto formado pelo banco de dados e o sistema que o gerencia, o SGBD, de sistema de banco de dados.
Bancos de dados Open Source: presente ou futuro? Cezar Taurion
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de dados Open Source. Bem, tenho minha opinio pessoal e quero compartilhar com vocs. Vamos ver se vai gerar muita discordncia...
17
Os softwares de banco de dados so um dos mais importantes componentes de software de uma organizao. Neste ambiente as alternativas de software livre j so bastante conhecidas e freqentemente so mencionadas na mdia, como MySQL, PostgreSQL, Ingres e Derby. O MySQL um produto de uma empresa privada, a MySQL AB. Seu cdigo desenvolvido pelos funcionrios da empresa e com isso ela garante a propriedade intelectual sobre o produto. Existe uma comunidade envolvida, mas submisses de cdigo so restritas apenas correo de bugs. Uma pergunta: o MySQL pode ser considerado realmente Open Source, uma vez que no adota o modelo de desenvolvimento colaborativo? O MySQL ofertado tanto em GPL como sob licena comercial. As duas verses so funcionalmente equivalentes, sendo diferenciadas pelo nvel de suporte e certificao. 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 tambm o Ingres, que foi um banco de dados da Computer Associates e agora pertence a uma organizao 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, geralmente embarcado em outros softwares. A IBM, por exemplo, o utiliza embutido em diversos softwares das famlias WebSphere, Tivoli e Lotus. Nas minhas andanas pelo mercado tenho visto que na prtica os bancos de dados Open Source s aparecem como competidores dos produtos mais avanados nas aplicaes pouco sofisticadas ou bem especificas. Por sua vez, os sistemas de banco de dados proprietrios buscam competir com funcionalidades diferenciadoras, principalmente as relacionadas com administrao de ambientes complexos; escalabilidade; desempenho com grande volume de transaes; alta disponibilidade e capacidade de recuperao rpida; e recursos de data warehousing. Alm disso, foi criado um ecossistema de negcios em torno dos principais software de banco de dados proprietrios, com diversas empresas independentes oferecendo ferramentas de software complementares (geradores de relatrios, analisadores estatsticos e outros), servios de suporte tcnico especializado e formao de recursos humanos, e assim por diante, o que tambm cria uma barreira de entrada difcil de transpor por qualquer novo entrante. J o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde se gera dinheiro) ainda incipiente, sendo formado por pequenas empresas com abrangncia de atuao bastante limitada. Ano passado, a MySQL gerou cerca de 50 milhes de dlares em receita (http://news. com.com/MySQL+hits+50+million+revenue,+plans+IPO/2100-7344_3-6179290.html), mas ainda um trao (cerca de 0,03%) no grfico que mostra o mercado global de bancos de dados relacionais, estimado pelo IDC em 16 bilhes de dlares. Como comparativo, o IDC estima que neste mesmo ano,
18
a receita da IBM com a famlia de produtos DB2 foi de aproximadamente 3,5 bilhes de dlares. Qual o papel que os bancos de dados Open Source desempenharo? Na minha opinio estaro atuando (pelo menos nos prximos 3 a 4 anos) na chamada faixa de produtos com funcionalidades comoditizadas, onde as caractersticas de preo so as de maior importncia. Os usurios tpicos sero organizaes e aplicaes que no precisam de recursos mais sofisticados. Como avaliar a qualidade de um banco de dados Open Source? Existem diversos critrios que podem e devem ser considerados em uma anlise para seleo de um banco de dados. Os nveis de importncia das variveis da anlise esto diretamente relacionadas com os objetivos do negcio e das necessidades a serem impostas aos softwares de bancos de dados. Alguns dos principais fatores a serem considerados so: a) b) c) Recursos de gerenciamento e administrao. So as ferramentas de apoio s tarefas do administrador do banco de dados. Desempenho e escalabilidade. Os recursos que o software oferece para garantir desempenho adequado, nos volumes de transaes que sero demandados. Recursos tcnicos. Disponibilidade de recursos como triggers, stored procedures, cursors, subqueries, capacidade de replicao, recursos de indexao, aderncia a padres (ANSI SQL), particionamento, backup/recovery, suporte a dados no estruturados, independncia de plataforma e recursos de segurana. Custos de Propriedade. Suporte tcnico e disponibilidade de recursos humanos. Abrangncia do ecossistema em termos de servios de suporte e qualificao de recursos humanos. Disponibilidade de aplicativos. Recursos de data warehousing e BI. Recursos de desenvolvimento de aplicaes. Modalidade de licenciamento. Viso, estratgia e road map do produto. Tamanho e participao/envolvimento da comunidade. Modelo de governana adotado pela comunidade.
d) e) f) g) h) i) j) k) l)
m) Base instalada e adoo pelo mercado. Bem e quanto a uma pergunta que muitos me fazem... Minha empresa deve adotar um banco de dados Open Source? Para mim, para mudar um software de banco de dados deve haver uma estratgia impulsionada por razes fortes e consistentes. Por exemplo, se houver desconfianas que o atual fornecedor esteja saindo do mercado; falta de funcionalidade do software (no mais adequado s
19
necessidades das novas aplicaes da empresa); falta de viso estratgica por parte do fornecedor do software atual; custos de manuteno e operao muito elevados para o resultado obtido; falta de pessoal gabaritado, que esteja disponvel no mercado; carncia de consultorias e servios de suporte externos; relacionamento com o fornecedor cada vez mais deteriorado... Mudar para um banco de dados Open Source simplesmente por questes ideolgicas deve estar fora de cogitao, pois banco de dados muito srio para ser tratado de forma simplista. OK, e quais seriam ento os custos e riscos da migrao? Existem custos de migrao que no podem ser subestimados. Temos os custos da converso de dados, custos da codificao, testes, e o que chamamos reconciliao entre as aplicaes no novo e no antigo ambiente, sempre considerando que dificilmente conseguiremos fazer uma migrao estilo big bang, mas que esta ser gradual. Quanto mais complexas forem as aplicaes a serem convertidas, mais custosa ser a migrao. Esta complexidade pode ser medida pelo nmero de programas, nmero de tabelas relacionais, restries de integridade referencial e tamanho do banco de dados. Existem custos indiretos como a construo de interfaces entre as aplicaes j convertidas e as que ainda esto no banco de dados antigo. Tambm os custos de suporte tcnicos aos dois ambientes implicam muitas vezes, em gastos adicionais elevados, principalmente quando o novo banco de dados no for de completo domnio da equipe tcnica da empresa. Em resumo, os custos da migrao afetam os clculos de custos totais de propriedade. A maioria das empresas extremamente cautelosa em trocar de fornecedor de softwares crticos. O perigo de uma interrupo nos seus negcios 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 benefcios forem claramente demonstrveis. Fonte: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/bancos_de_dados_open_source?lang=pt_br>. Acesso em: 14 ago. 2012.
CArACtErStiCAS DE SiStEmAS DE BANCOS DE DADOS

Se utilizar um sistema de banco de dados parece uma soluo natural, qual seria a outra soluo alternativa? Pense em algumas aplicaes que voc utiliza e que no fazem uso de SGBDs. Processadores de texto, planilhas, ferramentas de desenho etc., so alguns exemplos
20
dessas aplicaes. O que todas tm em comum? A necessidade de se armazenar a informao manipulada por meio de arquivos. Em qualquer aplicao que necessite do armazenamento de dados, faz-se necessrio 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 necessrio para se criar um formato e processar a sua gravao e recuperao e acredite, no pouco trabalho! Um SGBD, por outro lado, j dispe de uma srie de funcionalidades prontas para serem utilizadas pelo desenvolvedor da aplicao. Deste modo, uma srie de preocupaes passa a ser delegada a um software de terceiros (o SGBD). A seguir, apresentaremos uma srie de caractersticas que diferenciam a abordagem de sistemas de banco de dados da manipulao manual das informaes (como em arquivos, por exemplo). Natureza autodescritiva Uma caracterstica fundamental que distingue os sistemas de bancos de dados de outras abordagens o fato de que nos SGBDs, o banco de dados e as metainformaes sobre o banco de dados so armazenados conjuntamente. Essas metainformaes armazenadas contm informaes como o tipo, tamanho e restries do banco de dados. Em termos tcnicos, as metainformaes so chamadas de esquema (ou schema, em seu termo original em ingls). isolamento entre programa e Dados Numa aplicao que utilize arquivos para o armazenamento de dados, quaisquer alteraes na estrutura do arquivo tambm implicaro em alteraes 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 so armazenados, sem se
21
importar em como esses dados sero manipulados internamente. Esta caracterstica aumenta bastante o nvel de manutenibilidade do sistema, quando bem aplicada. mltiplas vises dos dados Esta no uma caracterstica fundamental, mas muitos SGBDs fornecem a possibilidade de que diferentes usurios com diferentes permisses possam acessar diferentes vises dos dados. Essas vises (views) correspondem a estruturas virtuais criadas a partir dos dados armazenados e podem conter, alm dos prprios dados, tambm informaes derivadas (calculadas) a partir desses dados. A criao de diferentes usurios com diferentes permisses a vises especficas uma abordagem muito utilizada em sistemas cliente/servidor; ou na integrao de aplicaes mediante banco de dados. O auge do uso destas abordagens deu-se no final da dcada de 1990, embora ainda hoje seja possvel testemunhar aplicaes sendo executadas sob este modelo. Recomenda-se fortemente que no desenvolvimento de novas aplicaes, a abordagem de mltiplas vises e de integrao mediante banco de dados seja substituda por uma abordagem orientada a servios como SOA (Service Oriented Architecture) ou como REST (REpresentational State Transfer). Vises no so uma m prtica. So um recurso bastante til, mas no imprescindvel. Como toda ferramenta, bem utilizada e de modo adequada, um recurso valioso. Acesso concorrente de mltiplos usurios Um SGBD multiusurio, como o prprio nome j define, deve permitir o acesso de mltiplos usurios. Alm disso, o acesso deve ser concorrente, permitindo que todos os usurios conectados executem operaes ao mesmo tempo. Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errnea na rea de Tecnologia da Informao: paralelo e concorrente. Paralelismo puro algo raro em
22
computao, embora seja perfeitamente possvel. Ao lidarmos com sistemas de banco de dados, utilizamos o termo concorrente, pois vrios usurios tm a impresso de que esto executando instrues ao mesmo tempo quando na verdade, por se tratar de informaes acessadas em disco ou com um nico barramento de acesso, torna-se necessrio algum mecanismo de conteno que serialize (coloque em fila) cada uma dessas instrues. Como idealmente a execuo dessas instrues bastante curta, tem-se a impresso do pseudoparalelismo. Um conceito fundamental para que o acesso destes mltiplos usurios mantenha o banco de dados num estado consistente o mecanismo de transaes, que ser descrito na prxima seo.
A revoluo do Big Data est prestes a acontecer Cezar Taurion
O termo Big Data comea a despertar muita ateno, mas ainda um conceito mal definido e com preendido. Com uma rpida pesquisa ao Google, identifiquei, pelo menos, uma dzia de definies. Neste artigo, vou falar um pouco sobre o assunto e debater alguns desafios que temos para conseguir colocar projetos de Big Data em ao.
23
Sem entrar em definies e nos atendo apenas a conceitos, podemos resumir com uma frmula simples o que Big Data: volume + variedade + velocidade de dados. Volume porque, alm dos dados gerados pelos sistemas transacionais, temos a imensido de dados gerados pelos objetos na Internet das Coisa, como sensores e cmeras, e os gerados nas mdias sociais, via PCs, smartphones e tablets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos no estruturados, como fotos, videos, emails e tutes. E, por fim, velocidade porque, muitas vezes, precisamos responder aos eventos quase que em tempo real. Ou seja, estamos falando de criao e tratamento de dados em volumes massivos. Outro desafio: criar e tratar apenas de dados histricos, como os veteranos Data Warehouse e as tecnologias de BI (Business Intelligence) comeam a se mostrar lentos demais para a velocidade com que os negcios precisam tomar decises. Alis, 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 nmeros so gigantescos. Se olharmos globalmente, estamos falando em zetabytes, ou 10 bytes. Grandes corporaes armazenam multiplos petabytes e mesmo as pequenas e mdias empresas trabalham com dezenas de terabytes de dados. Este volume tende a crescer geomtricamente. Em mundo cada vez mais competitivo e rpido, as empresas precisam tomar decises baseadas no apenas em palpites, mas em dados concretos. Assim, para um setor de marketing faz todo sentido ter uma viso 360 de um cliente, olhando no 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 so os recursos naturais da nova Revoluo Industrial. Na atual sociedade industrial, ter apenas recursos naturais, como minrio, e export-los de forma bruta - importando em troca produtos manufaturados, no garante a competitividade de um pas no longo prazo. O importante a tecnologia e o conhecimento que cria produtos manufaturados. Afinal, um quilo de satlite vale imensamente mais do que um quilo de minrio de ferro. Fazendo um paralelo, na sociedade da informao crucial saber tratar os dados na velocidade adequada. Dados no tratados e analisados em tempo hbil so dados inteis, pois no geram informao. Dados passam a ser ativos corporativos importantes e como tal, podem - e devero - ser quantificados econmicamente. Big Data representa um desafio tecnolgico, pois demanda ateno infraestrutura e tecnologias analticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de computao em nuvem, desde, claro, que este imenso volume no seja transmitido repetidamente via Internet. S para lembrar, os modelos de cobrana pelo uso de nuvens pblicas tendem a gerar processamentos muito baratos, mas tornam caro a transmisso de muitos dados. A principal base tecnolgica para Big Data Analytics o Hadoop e os bancos de dados NoSQL, onde
24
No significa Not Only SQL, ou seja, usa-se bases de dados SQL e no SQL. A importncia do Not Only SQL explica-se pelo fato do modelo relacional ser baseado na poca de sua criao, no incio dos anos 70. Nessa poca, acessar, categorizar e normalizar dados era bem mais fcil do que hoje. Praticamente no existiam dados no estruturados circulando pelos computadores da poca. Tambm no foi desenhado para escala massiva, ou para um processamento muito rpido. Seu objetivo bsico era possibilitar a criao de queries que acessacem bases de dados corporativas e, portanto, estruturadas. Para solues Big Data, tornam-se necessrias 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 no estamos falando apenas de armazenamento e tratamento analtico de volumes massivos de dados, mas de reviso, ou criao, de processos que garantam a qualidade destes dados e de processos de negcios que usufruam dos resultados obtidos. Portanto, Big Data no apenas um debate sobre tecnologias, mas, principalmente, sobre como os negcios podero usufruir da montanha de dados que est agora sua disposio. A emerge a questo da integrao: como integrar bases de dados estruturadas e no estruturadas com diversos softwares envolvidos? O Big Data abre oportunidades profissionais bem amplas. Na minha opinio, existe espao para dois perfis profissionais: um mais voltado para os negcios e qualificados para tratar analiticamente as informaes geradas por estas imensas bases de dados e outro com vis mais tcnico, ou Data Architect. Pelo vis dos negcios, um artigo interessante que foi publicado h poucos meses pelo Wall Street Journal, na edio brasileira, aponta como problema a escassez de talentos. Ele fala que muitas empresas americanas comearam a procurar profissionais que saibam interpretar os nmeros usando a anlise de dados, tambm conhecida como inteligncia empresarial. Mas encontrar profissionais qualificados tem se mostrado difcil. O resultado foi que vrias faculdades americanas, como a Faculdade de Ps-Graduao em Administrao da Universidade Fordham e a Faculdade de Administrao Kelley, da Universidade de Indiana, comearam a oferecer disciplinas eletivas, cursos de extenso e mestrados em anlise de dados. J o Data Architect deve lidar com tecnologias SQL e NoSQL, conhecer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto, ter capacidade de desenhar estratgias para manusear e analisar grandes volumes de dados de formatos diferentes, quase que em tempo real. A idia de stream processing, ou stream computing, fantstica; um novo paradigma. No modelo de data mining tradicional, uma empresa filtra dados dos seus vrios sistemas e, aps criar um data warehouse, dispara queries. Na prtica, faz-se uma garimpagem em cima de dados estticos, que no refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrs. Com o stream computing, esta garimpagem efetuada em tempo real. Em vez de disparar queries em cima de uma
25
base de dados esttica, coloca-se uma corrente contnua de dados (streaming data) atravessando um conjunto de queries. Podemos pensar em inmeras aplicaes, sejam estas em finanas, sade e mesmo manufatura. Vamos ver este ltimo exemplo: um projeto em desenvolvimento com uma empresa de fabricao de semicondutores monitora em tempo real o processo de deteo e classificao de falhas. Com o stream computing, as falhas nos chips que esto sendo fabricados so detetadas em minutos e no em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda, pode-se fazer ajustes em tempo real nos prprios processos de fabricao. Quanto ao EDA, pode-se comear a estudar o assunto acessando seu verbete na Wikipedia. O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Alis, j aparece no canto da tela de um ou outro CIO, e, provavelmente, em alguns anos j ser um dos temas mais prioritrios das tradicionais listas de tecnologias do ano. Portanto, bom estar atento sua evoluo e comear a colocar em prtica 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.
O maior evento da comunidade brasileira de NoSQL: <http://nosqlbr.com/>.
26
trANSAES
O conceito de transao fundamental em muitas reas da computao, e particularmente fundamental em sistemas de banco de dados. Consideramos como transao uma determinada unidade de trabalho, que realizada em qualquer sistema computacional de um modo coerente e independente de outras transaes. Estas transaes devem permitir que o sistema esteja num estado coerente antes e depois de sua execuo, independente de falhas ou outros problemas que possam ocorrer. Devem permitir tambm que vrios clientes diferentes acessem concorrentemente o sistema sem que isso possa corromper ou levar a estados que no sejam considerados coerentes. Uma definio clssica do conceito de transaes envolve o acrnimo ACID, oriundo das propriedades de Atomicidade, Consistncia, Isolamento e Durabilidade. Atomicidade A propriedade atomicidade de banco de dados advm do conceito de tomo da fsica o qual at recentemente supunha-se indivisvel. Essa indivisibilidade pressupe que as operaes realizadas numa transao sejam todas realizadas por completo; ou que nenhuma seja realizada. Popularmente seria o conceito do tudo ou nada. Isto permite que durante a nossa interao com um banco de dados, possamos agrupar vrios comandos relacionados com
27
a garantia de que todos sejam executados de modo que as informaes armazenadas permaneam num estado consistente aps a execuo da transao. Consistncia A propriedade de consistncia assegura que a execuo de qualquer transao trar o banco de dados de um estado consistente para outro estado tambm consistente. No caso, a consistncia implica que todos os dados de um banco de dados devem ser vlidos de acordo com um conjunto de regras que podem incluir restries de tipo, valor, referncias entre informaes etc. isolamento A propriedade de isolamento determina que o resultado da execuo concorrente de um conjunto de transaes ter o mesmo resultado de sua execuo em srie (uma aps a outra). O isolamento transacional o que garante e permite o acesso concorrente de mltiplos usurios ao mesmo SGBD. Durabilidade A propriedade de durabilidade garante que uma vez que uma transao tenha sido finalizada com sucesso, os dados tero a garantia de terem sido armazenados corretamente independentemente da eventualidade de falhas, falta de energia, erros de aplicao etc. Na opinio deste autor, justamente a propriedade de durabilidade que faz com que os bancos de dados sejam posicionados como ferramentas sagradas em muitas empresas. Novamente, no h menosprezo algum em dizer que o mais importante o cdigo que atende aos processos de negcios. Durabilidade essencial: imagine qualquer empresa perdendo todos os seus dados. A continuidade do prprio negcio est em risco. Mas mais importante do que os dados em si est o uso que se faz deles.
28
Sistemas tradicionais que vm sendo desenvolvidos nas ltimas dcadas sempre tiveram como premissa em seus dados sua corretitude (grau em que o software executa suas funes de modo correto). Isso normalmente implicou na utilizao de um banco de dados que pudesse satisfazer as propriedades ACID. Com o aumento da quantidade de informaes e usurios nas aplicaes, o fator disponibilidade passou em alguns casos a ser mais importante do que a prpria consistncia das informaes. Alm do ACID, surgiu o acrnimo BASE (Basically Available, Soft state, Eventually consistent) traduzido literalmente como Basicamente Disponvel, Estado flexvel e Eventualmente consistente. O BASE tornou-se uma sigla bastante comum ao lidar com bancos de dados no relacionais. Uma reflexo que vale a pena ser feita : para os novos desafios e empreitadas que vocs, futuros profissionais, enfrentaro, em quais situaes o ACID recomendado e em quais outras situaes o BASE mostra-se mais adequado? Referncia: <http://queue.acm.org/detail.cfm?id=1394128>. Acesso em 15 jul. 2012.
29
Papis assumidos pelos usurios de SGBDs

Desenvolvedores de SGBDs So pessoas que projetam e codificam os SGBDs. Exemplos de pessoas nestes papis incluem os funcionrios de empresas como Oracle, IBM e Microsoft que atuam diretamente na programao do software SGBD. No caso de SBGDs livres, podem ser tambm voluntrios ou pessoas e empresas interessadas na evoluo do software. Normalmente so programadores altamente qualificados que trabalham no cdigo-fonte do SBGD. Mas voluntrios de projetos de software livre tambm podem contribuir em outras atividades como documentao, por exemplo. So pessoas que desenvolvem software que armazena as informaes num SGBD. Tradicionalmente, em abordagens mais tradicionais e conservadoras, as equipes de desenvolvimento so separadas em desenvolvedores e DBAs. Os primeiros desenvolvem o software que acessa o SGBD. Os segundos projetam os bancos de dados e os mantm. Em abordagens de desenvolvimento mais modernas tende-se a eliminar esta distino entre os papis, pois quanto maior a distncia entre os membros da equipe envolvidos no projeto de software, menor tende a ser a qualidade do software entregue. So pessoas que no interagem diretamente com os bancos de dados, e sim com as aplicaes criadas pelos desenvolvedores de software que armazenam suas informaes em SGBDs. A maioria das pessoas enquadra-se nesta categoria, e embora sejam os grandes beneficiados pela tecnologia dos sistemas de bancos de dados, raramente possuem cincia do fato.
Desenvolvedores de aplicaes e Administradores de Bancos de Dados (DBAs DataBase Administrators)
Usurios finais
30
<http://youtu.be/Car5V9l8BiQ>. Klaus Wuestfeld Prevayler Neste vdeo Klaus Wuestfeld, um dos pioneiros do XP (eXtreme Programming) no Brasil e criador do conceito de prevalncia de objetos, mostra uma abordagem inovadora e de alto desempenho para manipulao e persistncia de objetos. Atualmente, alguns dos sistemas de transaes mais rpidos do mundo utilizam este conceito.
vANtAgENS DE SE utiliZAr um SgBD

Durante as sees anteriores, j citamos algumas vantagens de se utilizar um SGBD para armazenar as informaes de nossas aplicaes. A seguir, as enumeraremos de um modo mais detalhado, de forma a justificar seu uso numa diversidade de situaes. Diminuir a redundncia e fornecer consistncia Imagine uma situao bastante comum: voc resolve elaborar um documento e necessita da colaborao de vrias pessoas para faz-lo. Voc ento cria o esboo deste documento e o envia por e-mail a todos os interessados. Cada pessoa realiza as suas modificaes em suas prprias cpias dos documentos e depois repassa novamente por e-mail. Quem tem a ltima verso do documento? Quais so os dados corretos? Estas so perguntas difceis de serem respondidas nesta abordagem, e provavelmente exigir muito trabalho manual para se chegar verso final do documento. Um SGBD centraliza todas estas informaes, fazendo com que todos os usurios acessem os mesmos dados. Desse modo, diminui-se a redundncia: h somente uma cpia dos dados
31
a serem manipulados. Isto permite tambm que o banco de dados sempre permanea num estado consistente, pois todos os usurios tero sempre a ltima verso dos dados. No h a possibilidade de algum permanecer com um pedao dos dados antigos e outro pedao com a informao atual. Controle de acesso Muitas informaes armazenadas em sistemas so confidenciais. Ao mesmo tempo, necessrio que esta informao seja compartilhada com as pessoas para que sejam trabalhadas. Ao utilizar arquivos, necessrio que uma cpia seja enviada aos interessados. Por mltiplos motivos, essas cpias podem acabar sendo enviadas por e-mail a pessoas cujo acesso indevido; ou a mesma pode ser deixada num dispositivo de armazenamento removvel esquecido em alguma mesa de reunio. No mnimo um SGBD oferece uma combinao de login/senha para acesso a um determinado banco de dados. Outras restries relativas a qual usurio pode acessar quais dados tambm costumam ser implementadas pela maioria dos SBGDs. Como o acesso centralizado, tambm tem-se uma nica cpia para proteo. Consultas eficientes Como so aplicaes de software de propsito especfico, os SGBDs so especialmente projetados para armazenar eficientemente os dados a eles delegados; e para permitir formas de consulta eficientes aos mesmos dados. Cada SGBD possui sua estratgia interna para transformar estas informaes em bytes gravados no dispositivo de armazenamento, mas de um modo geral, no h uma grande diferena de desempenho entre diferentes produtos em uma quantidade razovel de aplicaes. Em casos de usos tpicos, muito mais importante a eficincia em consultas do que a eficincia em armazenamento de informaes. Assim, os SBGDs utilizam dispositivos como ndices (que so estruturas criadas para otimizar consultas baseadas em certos critrios) e
32
cachs (caches) para armazenar em memria os dados mais frequentemente acessados. Estes dispositivos permitem que as consultas possam ser executadas de modo mais rpido, e em muitos SGBDs, adequar estes dispositivos de modo otimizado chega a quase ser uma arte, tamanha a quantidade de opes disponveis. Backup e Restore Para garantir a continuidade dos negcios, essencial executar periodicamente o backup das informaes armazenadas no servidor. Ao invs de cpias fsicas dos arquivos do SGBD, comum os prprios SGBDs fornecerem ferramentas que permitem a exportao dos dados para um formato intermedirio (texto ou binrio) para backup. Estas mesmas ferramentas suportam a restaurao destes dados em caso de necessidade. As rotinas de backup/restore tambm so uma ferramenta bastante til na migrao ou cpia de servidores onde o mesmo SGBD esteja instalado. Situaes de migrao costumam ocorrer em caso de falhas ou upgrade de equipamento. Cpias costumam ser utilizadas para permitir o teste de aplicaes em desenvolvimento.
CONSiDErAES FiNAiS
Nesta unidade, pudemos perceber que os bancos de dados so uma coleo de dados relacionados que representam, por meio de um nvel determinado de abstrao, o modelo do mundo real de nossas aplicaes de software. Boa parte das aplicaes de software desenvolvidas na atualidade envolve a manipulao, e principalmente, o armazenamento dos dados estes muitas vezes em enormes quantidades. Para manipular estes bancos de dados, criou-se uma categoria de software especfico denominada de sistemas gerenciadores de bancos de dados (SGBDs). O banco de dados (os dados) e o sistema que o gerencia so denominados conjuntamente de sistemas de bancos de dados. Durante esta unidade tambm descrevemos as caractersticas 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 utilizao de arquivos como meio de armazenamento das informaes. Mas com as informaes que detalhamos como caractersticas destes sistemas de banco de dados, esperamos que voc, como desenvolvedor(a) possa ter argumentos suficientes para decidir
33
adequadamente entre uma abordagem e outra. Como existem muitos tipos de usurios diferentes que podem interagir com os sistemas de bancos de dados, tambm apresentamos uma lista no exaustiva dos papis que estes usurios podem assumir nestas interaes. Uma mxima que devemos sempre utilizar a tcnica do espelho. Olhe sempre para o software que voc desenvolve por meio dos olhos de quem usa. Compreender as situaes em que cada tipo de usurio interage com um sistema de banco de dados permite que tenhamos uma conscincia melhor das dificuldades e das necessidades que os usurios 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 relao implementao de aplicaes sem a facilidade e funcionalidade de um SGBD. Claro que, tendenciosamente, um estudioso de sistemas de bancos de dados observaria argumentos bastante positivos em relao abordagem dos SGBDs. O papel de um desenvolvedor experiente distanciar-se destes apegos a uma determinada tecnologia ou outra e decidir sobriamente qual a soluo mais adequada para a sua aplicao. 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 tpicos sero abordados em nossa prxima unidade.
AtiviDADE DE AutOEStuDO
1. Transaes tradicionalmente so melhor entendidas por meio do conjunto de suas propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade). Em quais situaes da vida real voc consegue enxergar a necessidade de se executar operaes com estas propriedades? 2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparao com a utilizao de arquivos para armazenamento dos dados. Tendenciosamente, o SGBD apareceu como o vencedor nas comparaes. Quais seriam as situaes em que os arquivos seriam uma soluo mais adequada? Voc consegue exemplificar alguma outra situao em que uma terceira alternativa seria mais vivel? 3. Pense no SBGD como um mdulo do sistema ou como uma outra aplicao a ser integrada (pois em muitas concepes modernas, assim que ele deve ser tratado). Uma das caractersticas dos SGBDs o isolamento entre o programa e os dados. Quais os benefcios deste isolamento? Em que outras partes do sistema esta caracterstica tambm pode trazer benefcios?
34
Banco de Dados na Nuvem Jin Zhang, Diretor de Programas da IBM
Profissionais de dados esto adotando conceitos de computao em nuvem para oferecer bancos de dados como um servio facilitando as dificuldades de gerenciamento e enviando usurios para a nuvem nove. Leva semanas para configurar um novo banco de dados. Preciso dele agora! Nossos dados de desenvolvimento/teste esto uma baguna. Por que eles nunca so limpos? Qualquer uma dessas reclamaes soa familiar? Provavelmente sim, se voc for um profissional de dados em uma grande empresa. Os departamentos de TI dos dias de hoje so afetados por uma lista no processada de demandas de administrao de dados. De solicitaes por novos bancos de dados de desenvolvimento e teste de aplicativos at o backup e a restaurao 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 solicitaes de usurios com tarefas sem parada de banco de dados, clone, banco de dados, clone - algumas organizaes esto tomando emprestado conceitos de autoatendimento do domnio de computao em nuvem e indo em direo a um modelo de banco de dados como servio ou DBaaS, em que usurios podem simplesmente acessar uma nuvem e capturar um banco de dados conforme necessrio. uma ideia provocante principalmente para usurios finais. Desenvolvedores de sistemas e de software adoram o controle que eles obtm com recursos de autoatendimento de DBaaS. Quando eles esto 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 viso uma realidade, no entanto, os profissionais de dados nos bastidores devem realizar uma quantia considervel de trabalho no backend. Desenvolver uma nuvem de dados privada
35
e lanar com sucesso DBaaS para usurios finais requer que DBAs considerem diversos fatores, entre eles a infraestrutura de hardware subjacente da nuvem, as boas prticas de dados abrangentes a serem implementadas e replicadas pela nuvem e, por fim, a interface de servios que trar todos esses itens de forma transparente aos usurios finais para concluir a imagem. Nossos dados de desenvolvimento/teste esto uma baguna. Por que eles nunca so limpos? penetrando as nuvens Computao em nuvem refere-se a uma categoria de solues de tecnologia que permite que usurios acessem recursos de computao (neste caso, recursos de dados) on demand, conforme necessrio, sejam os recursos fsicos ou virtuais, dedicados ou compartilhados e independentemente de como so acessados (por meio de uma conexo direta, rede local [LAN], rede de longa distncia [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 armazenamento, imagens virtuais, esquemas de banco de dados e mais e disponibilizar essa nuvem a usurios por meio de uma interface de servios. Quando esta infraestrutura estiver instaurada, medida que necessidades de banco de dados surgem, os usurios podem simplesmente ir para a nuvem, solicitar os recursos que requerem e obter acesso instantneo a seu prprio banco de dados pessoal on demand. Quando eles no precisarem mais dos ativos de dados, os ativos so reciclados de volta na nuvem para redesignao, em vez de serem deixados desperdiados e inativos.
36
Figura 1. uma infraestrutura otimizada para entrega em nuvem do banco de dados enfatiza simplicidade e eficincia por meio de automao e normatizao de hardware.
Etapa um: Desenvolver a base da nuvem Sua primeira parada no caminho para construir um ambiente de computao 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 decises de hardware provavelmente no ocorrero em um vcuo. 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 hardware. Esse processo pode requerer concesses de todos os lados, portanto, tente entrar na conversa com um entendimento claro de suas principais prioridades de hardware e as boas de ter. No tem certeza de quais devem ser essas prioridades? Leia adiante. Como em qualquer deciso de compra de hardware, muitos atributos afetaro a discusso plataforma, 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 possvel. Como muito mais fcil automatizar um script em execuo em um sistema aberto homogneo do que muitos scripts diferentes em um heterogneo, a normatizao a chave para automao. DBaaS em seu mago nada mais que automao a automao do processo de configurao 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 opes de armazenamento disponveis 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, recuperao 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, crtico entender exatamente do que capaz - e o que possvel passar a seus usurios finais. Se voc usar uma base de armazenamento que tenha recursos excepcionais de confiabilidade, disponibilidade e capacidade de manuteno (RAS), por exemplo, estar mais bem equipado a fornecer bancos de dados na nuvem que so resilientes e altamente disponveis tambm. Etapa dois: Identificar cargas de trabalho comuns e melhores prticas O prximo estgio de planejamento de DBaaS fornece a voc, como um profissional de dados experiente com conhecimento ntimo dos funcionamentos internos de sua organizao e suas estruturas de dados, a chance de brilhar. A etapa mais crtica para a entrega de DBaaS que realmente traz valor a seus usurios finais decidir antecipadamente o tipo de modelos e imagens de banco de dados que devem ser disponibilizados na nuvem. Para tomar tais decises, voc deve identificar as cargas de trabalho comuns e os processos chaves que ocorrem em seu ambiente de negcios e coletar melhores prticas. Esses so os principais candidatos para automao e entrega por meio de DBaaS e a chave para seu lanamento bem-sucedido. Por exemplo, os DBAs podem trabalhar juntamente com os gerentes de linha de negcios para identificarem os conjuntos de dados que precisam ter e usarem essas informaes para criarem modelos de bancos de dados que conectem de forma eficiente a sistemas front-end, funcionem bem com ferramentas 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 contm os dados mais recentes, informaes atualizadas no minuto e estruturas de dados - sem criaBANCO DE DADOS | Educao a Distncia
37
rem as dificuldades de administrao de dados de mudanas de esquema, mapeamento, migrao de dados e mais. Em outros ambientes corporativos, DBAs podem escolher imagens de bancos de dados - frequentemente incorporando metadados especficos do segmento de mercado e dados de referncia - como candidatos para automao. Um DBA familiarizado com os requisitos de negcios pode isolar uma instncia de um banco de dados de produo que contenha um conjunto crtico de tabelas, visualizaes, acionadores e procedimentos armazenados - assim como dados de referncia chave - para criar uma imagem de banco de dados para ser automatizada por meio de DBaaS. Quando os negcios solicitam um banco de dados para suportar uma nova filial ou para testar um aplicativo, no haver nenhuma necessidade de esperar semanas enquanto DBAs o constroem. Em vez disso, ele estar disponvel instantaneamente por meio de DBaaS na nuvem. Etapa trs: 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 usurios finais para educar e ajudar os mesmos a selecionarem a interface por meio da qual esses servios de dados sero disponibilizados. H trs mtodos principais de acesso a DBaaS: por meio de uma interface grfica com o usurio (GUI), uma interface da linha de comandos (CLI) ou diretamente por meio de uma interface representational state transfer (REST) padro. Qual interface ser empregada por fim depender muito da preferncia do usurio final. Por exemplo, enquanto a GUI a abordagem mais fcil e simples das trs, se os usurios finais j utilizarem aplicativos que empregam CLI, pode ser que no queiram alternar. Como alternativa, os usurios podem querer eliminar a necessidade de interveno humana inteiramente e promover uma integrao mais forte com seu ambiente, programando aplicativos para se comunicarem diretamente com DBaaS por meio de REST. Quando se sabe as opes, possvel trabalhar com seus usurios e ajudar a gui-los para a interface de DBaaS mais adequada para seus desejos e necessidades especficos e juntos selecionar o wrapper que unir todo o pacote DBaaS. uma nuvem com um raio de esperana No nenhum segredo que gerenciar os valores de dados em rpida expanso e as necessidades de administrao de banco de dados das grandes empresas dos dias de hoje uma grande proeza. DBAs tm uma tarefa dura e no h outra maneira de descrever isso. A boa notcia que com DBaaS, os profissionais de dados esto em uma posio exclusiva no somente de darem aos usurios finais novos nveis de liberdade e servio, mas tambm para sarem 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 esperana, isso praticamente o melhor que se pode obter. Fonte: <http://www.ibm.com/developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBaaS/>. Acesso em: 14 ago. 2012.
38
uNiDADE ii
OS BANCOS DE DADOS E O SOFtWArE

Professor Me. Edson Yanaga Objetivos de Aprendizagem Apresentar as definies fundamentais de sistemas de bancos de dados. Descrever as arquiteturas de bancos de dados e suas caractersticas. plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Conceituar schemas, instncias, abstraes e as interfaces de interao com o SgBD Estudo do histrico das arquiteturas de computao em geral e de sistemas de banco de dados Classificao dos diferentes tipos de banco de dados de acordo com suas caractersticas
iNtrODuO
Nesta unidade, apresentaremos alguns conceitos fundamentais que sero utilizados nas demais unidades. Para compreender adequadamente os sistemas de banco de dados, necessrio diferenciar adequadamente os modelos das instncias dos modelos pois possuem ciclos de vida e finalidades bastante distintas. Diferentes tipos de interface de usurio so disponibilizadas para diferentes tipos de usurios em vrios produtos diferentes comercializados no mercado. Apresentaremos algumas delas para que voc, desenvolvedor(a), possa explor-las posteriormente. Entender como podem ser construdos sistemas com SGBDs implica em conhecer tambm a histria da arquitetura de sistemas de computao, que evoluram do monoltico at o distribudo em camadas. Cada gerao possui suas particularidades, que tambm so refletidas na construo dos diferentes SGBDs. Apresentaremos tambm alguns critrios de classificao 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.
41
SCHEMAS, INSTNCIAS E ABSTRAES

Uma caracterstica fundamental de qualquer modelo de software (o que inclui o banco de dados) o seu nvel de abstrao. impossvel conseguir modelar todos os aspectos do mundo real numa aplicao. 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 abstrao dos dados do mundo real. Um modelo de dados uma coleo de conceitos que pode ser utilizada para descrever a estrutura de um banco de dados. Por meio desses conceitos, conseguimos alcanar a abstrao necessria para construir o nosso modelo de software. Em qualquer modelo de dados, importante distinguir aquilo que representa a descrio do banco de dados com o banco de dados em si. A descrio do banco de dados denominada de schema1, que especificado durante o projeto do sistema de software. Os dados realmente armazenados num banco de dados podem mudar com uma alta frequncia. 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. Tambm definido como o estado atual de todas as instncias no banco de dados. Uma instncia um item dentro do banco de dados que segue as definies de seu schema correspondente. A distino 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 aps criado representa um snapshot inicial vazio. Ao manipularmos este banco de dados com operaes de insero, alterao e remoo, ns modificamos o snapshot. O SGBD responsvel por garantir a consistncia do snapshot em
1
O plural correto de schema schemata, mas praticamente no utilizado. Na rea de tecnologia da informao, costuma-se utilizar o plural schemas, mesmo sendo errado.
42
qualquer momento do tempo. No uma operao usual ter que realizar modificaes no schema, mas elas so realizadas toda vez que uma mudana nos requisitos do negcio demanda uma alterao no modelo de dados. Este conjunto de alteraes para acomodar mudanas no software denominado de schema evolution.
iNtErFACES DOS SgBDS

Algumas das interfaces do SGBD com o usurio so:
Linha de Comando Sem dvida nenhuma a linha de comando a interface mais poderosa e flexvel para a interao do usurio com o SGBD. Por este mesmo motivo, normalmente no uma opo que a maioria considere como amigvel. Mas desenvolvedores devem sem dvida nenhuma domin-la para poder explorar os recursos do mesmo.
43
Interfaces Web
Muitos SGBDs fornecem interfaces Web que podem ser acessadas por meio de qualquer navegador para a administrao e manipulao dos bancos de dados. Embora no sejam to poderosas ou produtivas, so bastante amigveis e possuem ainda a vantagem da disponibilizao do acesso. Muitos administradores de rede no se sentem confortveis em permitir o acesso direto ao banco de dados, mas no se importam em liberar o acesso por meio de HTTP (Web).
44
Interfaces Desktop
So to amigveis quanto as Interfaces Web, mas costumam fornecer capacidades de manipulao grfica de diagramas. Isso auxilia os desenvolvedores a enxergar os relacionamentos entre as entidades do banco de dados.
45
Interfaces baseadas em formulrios
O Oracle Forms um exemplo clssico desta interface, tpica de sistemas implementados utilizando-se triggers e stored procedures. Os usurios finais conseguem executar seus processos de negcios por meio da prpria interface do SGBD, preenchendo formulrios 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 prpria histria da arquitetura de sistemas de computao em geral. De fato, ao mesmo tempo em que as aplicaes e os modelos de arquitetura de aplicaes evoluram, tambm evoluram os sistemas de banco de dados. Dentre os fatores que influenciaram estas evolues esto o aumento da capacidade de processamento, o aumento da capacidade de armazenamento, o aumento da quantidade e capacidade das redes de comunicao, a reduo de custo dos equipamentos, o aumento do nmero de usurios, o aumento da quantidade de informaes e a universalizao do acesso. No h como explicar adequadamente as arquiteturas de sistemas de banco de dados sem descrever conjuntamente as arquiteturas de sistemas de computao em geral. Nas prximas sees, apresentaremos e descreveremos concomitantemente estas diferentes arquiteturas, da centralizada at o modelo em camadas.
46
mODElO CENtrAliZADO
Os primeiros modelos computacionais eram centralizados, baseados num nico mainframe fornecendo processamento, armazenamento e interface de interao com o usurio no mesmo equipamento/aplicao. Raros eram os mainframes (devido ao seu alto custo) e por consequncia tambm poucos eram os usurios que tinham acesso a aplicaes baseadas em mainframe. A interao dos usurios com as aplicaes era realizada por meio de terminais burros, que no possuam poder de processamento: somente teclado; e exibiam telas geradas no prprio mainframe e transmitidas at o monitor (usualmente de fsforo verde ou amarelo) por meio de um cabo de comunicao. A Figura 1 retrata um tpico sistema centralizado baseado em mainframe.
Mainframe
Terminal Burro
Figura 1
Fonte: o autor
Terminal Burro
Terminal Burro
47
Costumamos retratar este modelo de computao como monoltico, pois todas as atividades eram baseadas no mainframe. Naturalmente, as aplicaes desenvolvidas para este tipo de equipamento tambm foram concebidas e implementadas de modo monoltico. Isso significa que no havia uma distino clara entre o que era interface com o usurio ou o que era cdigo de negcios ou cdigo responsvel pelo armazenamento de dados. Esta situao denominada de sistema altamente acoplado, pois qualquer alterao numa pequena parte do sistema costuma levar a vrias outras alteraes em cascata para diversas outras partes do sistema. Os bancos de dados eram ento extenses da prpria aplicao e eram baseados nos modelos hierrquicos e em rede, que sero apresentados adiante. Modelo cliente/servidor Com a popularizao dos PCs e o declnio de seus preos, iniciaram-se as primeiras implantaes da arquitetura cliente/servidor. A ideia que ao invs de termos um grande equipamento monoltico (mainframe), passamos a ter vrios equipamentos menores (e de custo e capacidade inferior) com propsito especfico (banco de dados, arquivos, e-mail, impresso etc.) interligados por meio de uma rede de comunicao. Cada servidor tornou-se um servio especializado (embora no seja incomum agrupar vrios servios num nico equipamento, dependendo da convenincia). Os clientes, que tambm so PCs, podem acessar os recursos disponibilizados por estes servidores por meio de rede. A Figura 2 mostra um esquema simplificado da arquitetura cliente/servidor.
48
Servidor
Servidor
Servidor
PC
Figura 2
Fonte: o autor
PC
PC
PC
Em termos de arquitetura das aplicaes, denominamos o modelo cliente/servidor como modelo de 2 camadas, respectivamente camada cliente e camada servidor. No lado cliente costumase implantar os recursos da aplicao relacionados interface com o usurio, enquanto no lado servidor implanta-se a lgica de negcios, armazenamento e controle transacional. Este modelo tornou-se extremamente popular no final da dcada de 1980 e incio da dcada de 1990, e com ele tambm popularizou-se a prtica do desenvolvimento de aplicaes utilizando-se triggers e stored procedures dentro do prprio SGBD. Cada cliente estabelece uma conexo remota ao SGBD, que passa a executar a lgica de negcios, armazenar os dados e controlar as transaes. O modelo cliente/servidor bastante adequado quanto s aplicaes que possuem um nmero limitado de usurios concorrentes (de 100 a at 300 ou 400 usurios). A partir deste nmero,
49
o desempenho desta arquitetura degrada-se consideravelmente, e o particionamento e distribuio dos sistemas de banco de dados (escalabilidade horizontal) costuma ser bastante dispendioso. Naturalmente, h um limite tambm para a troca do equipamento por um maior (escalabilidade vertical). Surgiram ento os modelos de 3 camadas para tentar resolver este problema. modelo de 3 Camadas ou N-Camadas Aplicaes 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
Servidor de aplicao
Servidor de aplicao
Servidor de Banco de Dados

Figura 3
Fonte: o autor
50
Esta camada intermediria denominada de camada de aplicao, e responsvel pela execuo da lgica de negcios. Separa-se ento em 3 papis distintos cada camada: a camada mais prxima do usurio responsvel pela interface e interao com o usurio; a camada intermediria responsvel pela lgica de negcios; e a camada do SGBD responsvel pelo armazenamento dos dados. Como idealmente a camada de aplicaes projetada de modo stateless (sem estado), a replicao horizontal torna-se bem mais simples do que no modelo cliente/servidor. Toda a lgica de negcios que anteriormente era codificada utilizando-se triggers e stored procedures passa a ser executada na camada intermediria utilizando-se uma linguagem de propsito geral. A quantidade de conexes de rede com o SGBD tambm diminui, pois agora os usurios no o acessam diretamente esta tarefa passa a ser responsabilidade da camada de aplicao. Outras arquiteturas costumam subdividir a camada intermediria em outras 2 ou 3, criando aplicaes de 4, 5 ou N camadas. Podemos adicionar camadas de validao, auditoria, comunicao distribuda etc. A quantidade de camadas fica a gosto do arquiteto que projeta a arquitetura, mas a filosofia de todo este processo de diviso de camadas segue os princpios j apresentados. Este modelo de camadas o modelo utilizado atualmente para suportar a imensido de dados e usurios das aplicaes de Internet contemporneas.
O maior evento da comunidade de desenvolvedores do Brasil e referncia para profissionais iniciantes ou experientes nos mais variados assuntos, incluindo Arquitetura de Software, Banco de Dados, NoSQL e Cloud Computing: <http://www.thedevelopersconference.com.br/>.
51
Sem Banco de Dados Nos Estados Unidos, em 1920, a manufatura, venda e importao de bebidas alcolicas foram proibidas por emenda constitucional. Esta emenda foi revogada treze anos depois. Durante aquele perodo de proibio, a indstria de cerveja morreu. Em 1933, quando a proibio foi encerrada, algumas gigantes empresas de gros comearam a produzir cerveja. Eles monopolizaram completamente o mercado. E por quase 50 anos, ns nos Estados Unidos bebemos este lquido 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 atrao. Por que cerveja? Era um fluido pli do, amarelo e desagradvel derivado da urina de javalis doentes, e no possua nenhuma qualidade que eu pudesse observar. Em 1984, eu fui Inglaterra; e as escamas caram dos meus olhos. Finalmente pude entender. Pela primeira vez eu pude provar cerveja; e eu gostei. Desde aqueles dias a situao da cerveja nos Estados Unidos melhorou dramaticamente. Novas
52
Foto: SHUTTERSTOCK.COM
cervejarias esto sendo criadas por todo o pas; e em muitos casos a cerveja realmente boa. Ainda no temos nada to 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 dvida entre gerentes e profissionais de marketing. A palavra relacional tornou-se sinnimo de bom; e quaisquer outros mecanismos de armazenamento de dados foram proibidos. Eu era o lder de equipe de uma startup naquele tempo. Nosso produto media a qualidade de linhas de comunicao T1. Nosso modelo de dados era relativamente simples, e ns mantnhamos os dados em arquivos texto. E funcionava bem. Mas nosso responsvel pelo marketing continuou insistindo que precisvamos 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 ns no tnhamos 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. Ns teramos que utilizar um banco de dados relacional. Arquivos texto estavam proibidos. Como lder de equipe, e responsvel pela qualidade do software, minha viso de um banco de dados relacional era que ele seria um trambolho grande, indigesto, lento e caro. Ns no tnhamos consultas complexas. Ns no precisvamos de relatrios com anlises massivas. Certamente no precisvamos de um processo com mltiplos megabytes consumindo memria e desperdiando ciclos de processamento (lembrem-se, estvamos na dcada de 80). Portanto eu lutei contra esta idia com todos os recursos que eu tinha; porque era a soluo tcnica errada. Esta no foi uma jogada politicamente acertada para mim. Durante um perodo de vrios meses, um engenheiro de hardware que tinha a capacidade de escrever algumas linhas de cdigo foi alocado na equipe de software. Gradualmente ele foi recebendo mais e mais responsabilidade, e eventualmente foi nomeado meu cogerente. Ele e eu iramos dividir a responsabilidade de liderar a equipe de software. Uh huh. Claro. Com certeza. Um cara de hardware com nenhuma experincia 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 ms depois e iniciei minha carreira de consultor. Foi a melhor mudana que fiz na minha carreira profissional. A empresa que eu deixei no existe mais. E eu tambm 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
53
gigantes. Estes gigantes estavam criando uma tempestade. Eles eram deuses. Eles eram soberanos. Durante a bolha ponto com, um deles chegou a ter a audcia de comprar anncios de televiso 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 perodo eu assisti com horror a como uma equipe aps a outra colocava o banco de dados 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 corao do seu projeto. Eu testemunhei a criao de um novo tipo de emprego. O DBA! Meros programadores no eram confiveis o suficiente para guardar os dados assim diziam as propagandas. Os dados so to preciosos, to frgeis, to facilmente corrompveis por estes palhaos indisciplinados. Ns precisamos de pessoas 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 Usurio. Eu blasfemei incansavelmente contra a prtica de se mover toda a lgica de negcios 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 cdigo-fonte sistema aps 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 ento, na primeira dcada no sculo 21, uma proibio foi revogada, e o movimento NoSQL nasceu. Eu o considerei um milagre, uma luz brilhando no deserto. Finalmente, algum percebeu que pode haver alguns sistemas no mundo que no necessitam de um grande, gordo, lento e caro porco devorador de memria 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 comeando a ter um gosto bom. Mas ento eu percebi algo. Alguns dos sistemas utilizando estes bons, simples e saborosos banco de dados no relacionais estavam sendo projetados ao redor dos bancos de dados. Os bancos de dados, encapsulados em reluzentes novos frameworks, ainda estavam no centro da concepo do projeto! O veneno das campanhas publicitrias das empresas de banco de dados relacionais ainda estava ecoando na mente dos arquitetos. Eles ainda estavam cometendo o erro fatal.
54
Pare!, eu gritei. Pare! Vocs no entendem. Vocs no entendem. Mas a inrcia era muito grande. Uma enorme onda de frameworks cresceu e esmagou a nossa prpria indstria, levando tudo pelo caminho. Estes frameworks encapsularam os bancos de dados e brigaram com unhas e dentes para manter o centro de nossas aplicaes. 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 aps ler todas estas lamentaes voc possa entender o porqu do ttulo. O centro da sua aplicao no o banco de dados. Nem um ou outro framework que voc possa estar utilizando. O centro da sua aplicao so os casos de uso da sua aplicao. Eu enlouqueo quando ouo um desenvolvedor de software descrever o seu sistema como Um sistema no Tomcat utilizando Spring e Hibernate com Oracle. As prprias 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 so o centro do projeto? Ou voc acha que encontrar o cdigo-fonte adaptado para encaixar nos padres dos frameworks? Voc suspeitaria de objetos de negcios que parecem linhas de banco de dados? Ser que o schema e os frameworks poluiriam tudo? Isso como uma aplicao deve parecer. Os casos de uso devem estar no nvel mais alto e mais visvel das entidades arquiteturais. Os casos de uso esto no centro. Sempre! Banco de dados e frameworks so detalhes! Voc no tem que decidir utiliz-los prematuramente. Voc pode postergar esta deciso, at que todos seus casos de uso e regras de negcios tenham sido elaborados, codificados e testados. Quando a melhor hora de se determinar o seu modelo de dados? Quando voc j conhece quais so as entidades de dados, como elas se relacionam, e como so utilizadas. Quando voc sabe isso? Quando voc j tem todos os casos de uso e regras de negcios 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 no! Voc ainda focar em conseguir os casos de uso funcionando e testados antes de pensar no banco de dados; no 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 aplicao, 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
55
continuamente dizer No tentao de envolver o banco de dados logo no incio. Estamos nos aproximando de uma poca interessante. Uma poca em que a proibio contra diferentes 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 no deve envolv-lo logo no incio. Uncle Bob Martin o Mestre Arteso 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.
ClASSiFiCAO DOS SiStEmAS DE BANCO DE DADOS
Assim como na natureza, podemos utilizar vrios critrios diferentes para classificar os sistemas de banco de dados. Alguns desses critrios bastante comuns so modelos de dados, nmero de usurios, nmero de instalaes e custo. Nas prximas sees exploraremos como utilizar esses critrios para classificao. modelo de dados No tenha dvidas: muitas pessoas relacionam o modelo relacional a banco de dados devido sua absoluta onipresena. Um argumento costumeiro na escolha do modelo relacional
56
Foto: SHUTTERSTOCK.COM
que ningum ser demitido por t-lo escolhido. De fato, antes do advento do termo NoSQL, praticamente no havia outras opes a considerar. Durante anos houve muita pesquisa e discusso sobre banco de dados orientado a objetos, graas grande popularizao das linguagens orientadas a objetos. O pensamento da poca era que o desenvolvimento de aplicaes seria muito mais simples se pudssemos utilizar linguagens e banco de dados orientados a objetos juntos. Mas dois fatores foram decisivos para que isso no acontecesse. Primeiramente, o modelo relacional j era algo absolutamente consolidado e otimizado. Baseado em fundamentos matemticos extremamente simples, h anos j havia obtido sua maturidade. Robustos e confiveis, j eram utilizados em grandes aplicaes 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 rentvel ao redor de si. Atualmente, so raros os exemplos de sistemas de banco de dados deste tipo e no 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 hierrquico ou o modelo em rede. Mas no se engane ao considerar que aplicaes baseadas nestes modelos desapareceram. Grandes bancos so um segmento tradicionalmente conservador em relao a tecnologias adotadas. fato que boa parte deles ainda roda seus mais importantes sistemas em mainframes com sistemas de banco de dados hierrquicos ou em rede. o caso, por exemplo, do Banco do Brasil. H uma cumplicidade: mainframes garantem a sobrevida do modelo hierrquico e em rede, e as aplicaes 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 no sero abordados neste material.
57
Nmero de usurios Em relao ao nmero de usurios, sistemas de banco de dados podem ser monousurios ou multiusurios. Alguns raros exemplos atuais de banco de dados monousurios so os banco de dados embarcados, que so projetados para serem pequenos e rpidos o suficiente para serem embarcados dentro de uma aplicao. Alguns exemplos que poderamos considerar so o Apache Derby e o H2. Mas mesmo estes dois SBGDs podem se comportar como monousurio ou multiusurio, dependendo do seu tipo de instalao. Naturalmente, a grande maioria dos sistemas de banco de dados modernos suporta mltiplos usurios concorrentes com acesso mediante algum protocolo de rede. Nmero de instalaes Quanto quantidade de instalaes, podemos classificar os sistemas de banco de dados em centralizados ou distribudos. Sistemas centralizados so aqueles em que h uma nica instncia do sistema de banco de dados sendo executada. So apropriados para quantidades pequenas de dados ou em situaes em que a disponibilidade do sistema no crucial ao negcio. Sistemas distribudos so aqueles em que h mais de uma instncia (com a possibilidade de vrias) sendo executada. Em sistemas de banco de dados mais tradicionais, costuma-se utilizar uma distribuio master-slave, em que as atualizaes de dados so efetuadas no master e as leituras so efetuadas em um ou mais slaves. Como a maioria das aplicaes executa mais leituras do que atualizaes, o desempenho pode aumentar de modo significativo. Outros tipos de distribuies de banco de dados podem envolver particionamento (dividir os dados em instalaes diferentes) e/ou replicao (duplicar os dados) para aumentar o desempenho e/ou disponibilidade.
58
Custo no critrio custo em que amplitude de diferena entre os sistemas de banco de dados maior. Temos desde o gratuito at exemplares que podem custar alguns milhes de dlares. No caso dos gratuitos, vale a pena distinguir entre os sistemas livres (software livre) e os que representam verses reduzidas de produtos mais caros. Dois produtos livres bastante populares so o MySQL (bem mais popular) e o PostgreSQL. O modelo de negcios de ambos permite o livre uso e redistribuio; mas quando for necessrio o suporte, pode-se optar por contrat-lo de uma empresa terceirizada ou do prprio fornecedor (Oracle), no caso do MySQL. Ambos possuem graus de maturidade, estabilidade e funcionalidade bastante elevados e no devem nada a desejar em relao aos produtos pagos. Provavelmente em mais de 90% dos casos de uso de aplicaes tradicionais, no haveria diferena 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 soluo e outra passou a ser uma questo de gosto ao invs de uma questo puramente tcnica. Devido ao sucesso dos sistemas de banco de dados livres, produtos comerciais que tradicionalmente eram bastante custosos passaram a oferecer verses gratuitas (limitadas em nmero de processadores, quantidade de dados, instncias etc.). o caso de Oracle, DB2 e SQL Server. Trata-se de uma estratgia comercialmente interessante, pois migrar de um SGBD para outro no 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 negcios com uma verso gratuita poder passar a pagar pelo uso dos produtos mais completos quando a capacidade da verso gratuita for atingida. Nesse ponto espera-se que a empresa j esteja com um faturamento considervel e provavelmente no se importar com o investimento.
59
<http://youtu.be/piSbDWeu3pM>. Luciano Ramalho MongoDB Luciano Ramalho um dos grandes experts em linguagens de programao dinmica no Brasil, particularmente Python. Tambm um dos pioneiros em NoSQL e especialista em MongoDB, um banco de dados de documentos. Neste vdeo, Luciano apresenta as vantagens e as aplicaes deste banco de dados.
CONSiDErAES FiNAiS
Nesta unidade ns aprendemos a distinguir o schema, que um metamodelo do banco de dados, de suas instncias. Alteraes no schema no costumam ser muito frequentes, enquanto que as instncias so manipuladas por meio de operaes de insero, remoo ou atualizao. A boa assimilao da distino entre schema e instncias um conceito fundamental para o uso efetivo de um sistema de banco de dados alis, esta diferenciao entre modelo, metamodelo e instncias do modelo algo bastante frequente na rea de software. Existem diversos tipos de interfaces de interao dos usurios com o sistema de banco de dados, e a escolha de qual interface utilizar depende muito do propsito e do papel do usurio ao acess-lo. Sempre h a avaliao entre os quesitos poder versus facilidade de uso. A prtica faz-se necessria para que um bom desenvolvedor possa escolher o meio de interao mais adequado de acordo com a situao. Muitas vezes voc necessitar do poder da linha de comando; noutros, alguns cliques numa interface desktop sero mais cmodos. O seu conhecimento permitir que voc tome a deciso acertada. A apresentao das arquiteturas de computao em geral e das arquiteturas de sistemas de bancos de dados pde esclarecer a forma com que historicamente se desenvolve estas arquiteturas de aplicaes. O artigo apresentado no saiba mais promove uma reflexo importantssima para que voc possa ponderar sabiamente durante o processo de desenvolvimento de suas aplicaes. Este autor concorda com a proposta do Uncle Bob Martin, at porque vivemos um perodo em que muitos conceitos estabelecidos esto sendo
60
questionados. Poder desenvolver o seu software objetivando o valor de negcios e os seus usurios muito mais importante do que quaisquer abstraes de armazenamento de dados inclusive o banco de dados. Concentre-se naquilo que realmente importante para sua aplicao 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 critrios diferentes para a classificao de diferentes produtos de sistemas de bancos de dados. Diferentes fornecedores com diferentes produtos apresentaro uma infinidade de argumentos para que voc decida entre um e outro. Claro que os critrios comerciais influenciaro bastante sua deciso, mas a lista que assimilamos nesta unidade poder lhe nortear com alguns argumentos importantes. Nossa escalada para o domnio dos sistemas de bancos de dados passar na prxima unidade para um novo degrau: o modelo relacional que em muitos casos j foi (ou ainda ) sinnimo de banco de dados. Veremos o porqu de suas qualidades o tornarem to bem conceituado.
AtiviDADES DE AutOEStuDO
1. Defina os seguintes termos: schema, instncia, snapshot e schema evolution. 2. Qual a diferena entre sistemas de computao de duas e de trs ou N camadas, e como os sistemas de banco de dados interagem com estes sistemas de computao? 3. Escolha um caso de uso da vida real para avaliar a implementao de um software. Baseado(a) nos critrios descritos nesta unidade, quais seriam suas consideraes para decidir entre um SGBD e outro?
61
vida longa ao mainframe: a trajetria de um baby boomer Luiz Fadel, primeiro distinguished engineer da IBM no Brasil, conta sua experincia de 40 anos como prossional especializado na tecnologia. Poucos so os profissionais de tecnologia que conseguem sobreviver por tantos anos no mundo corporativo, em meio s constantes transformaes provocadas pela era digital. Com a revoluo da internet, TI passou a ser uma rea invadida e dominada, cada vez mais, pela intrigante gerao Y formada por jovens entre 18 e 30 anos. Vencer a linha do tempo um desafio, principalmente porque as empresas vm privilegiando o san gue novo. Uma dura realidade que atinge quase todos os que tentam o mercado de trabalho. Neste cenrio, difcil encontrar profissionais que tenham passado a casa dos 50, mas uma leva de execu tivos resiste bravamente. So os chamados dinossauros da indstria de tecnologia no Brasil. No bom sentido, claro. O engenheiro eletrnico paulistano Luiz A. Fadel um deles. Formado em um dos mais renomados celeiros de profissionais de engenharia do Pas, o Instituto Tecnolgico da Aeronutica (ITA), ele conta com uma trajetria profissional mpar. Assistiu aos efeitos da reserva de mercado - que protegeu a indstria nacional de informtica - 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 experincia em sistemas de grande porte, continua com o mesmo gs e energia de quando comeou a carreira. Reconhece que ainda tem muitos anos de estrada pela frente. Flego de causar inveja a qualquer um que tenha se formado j na era digital. Desemprego no uma palavra que faz parte do vocabulrio dos especialistas em mainframe, afir ma Fadel. Nem mesmo para ns da gerao 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.
62
Sem planos de sair de cena, o executivo conta um pouco de sua experincia ao longo de duas dcadas, toda construda na gigante IBM. Confira trechos da entrevista que Fadel concedeu Computerworld: Computerworld - Sua carreira foi construda em uma das tecnologias mais antigas e que ainda continua forte no mercado, sobretudo o brasileiro. Que razo o levou apostar nessa rea? Luiz A. Fadel - Sem dvida, h muitas oportunidades interessantes que o mercado de mainframe oferece. Em todos os meus 40 anos de carreira, s lembro um momento crtico para os profissionais dessa tecnologia. Na dcada de 90, com o auge dos PCs, a demanda por sistemas de grande porte sofreu retrao. Quadro que anos depois teve recuperao. Apesar dos percalos, a plataforma evoluiu bastante de 1964 (quando comecei) para c. No 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 contrrio, um sistema que completa o parque de muitas empresas por atender a necessidade de transaes 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 privilgio de participar de projetos envolvendo grandes bancos brasileiros que, na poca, tornavam-se os maiores consumidores da tecnologia. Tambm estive envolvido na primeira instalao do Mainframe Operating Systems (Mainframe OS) no Pas, 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 opo 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 ascenso profissional dentro da carreira tcnica. Nunca precisei mudar de rumo para dar saltos. Tanto que hoje cheguei a um cargo equivalente ao de um diretor com carreira em negcios, que a IBM chama de distinguished engineer. o posto mais alto da empresa na rea tcnica. Na subsidiria brasileira, s trs profissionais tm esse ttulo. Eu fui o primeiro a conquist-lo aqui, em 2003. No mundo, existem cerca de 200 pessoas com o posto. Ou seja, uma grande realizao na carreira que no posso ignorar. Tambm no podemos esquecer que a IBM sempre foi uma multinacional slida e de peso. Alm de abrir as portas para que os funcionrios possam ter experincia 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 rene os melhores especialistas da companhia do mundo. Isso quando ramos (os brasileiros) pouco respeitados, quanto ao aspecto tcnico, 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. No h gente
63
no meio da pirmide e quem possui experincia est empregado. Por isso a prpria IBM firmou par ceria com as universidades do Pas para formar gente. Posso garantir que oportunidade o que no falta para especialistas em mainframe. Na empresa, por exemplo, somos extremamente valorizados. Detalhe: h espao para quem se aposentou e quer voltar e para quem no 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.
64
uNiDADE iii
O mODElO rElACiONAl
Professor Me. Edson Yanaga Objetivos de Aprendizagem Conceituar o modelo relacional. Conceituar as restries do modelo relacional. Descrever as operaes de manipulao de instncias do modelo relacional. plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Conceituar domnio, atributos, tuplas e relaes Conceituar os diferentes tipos de restries do modelo relacional e de banco de dados Descrever as operaes de INSERT, UPDATE e DELETE do modelo relacional e como elas interagem com as restries do banco de dados
iNtrODuO
A partir desta unidade, abordaremos o modelo de dados relacional, que o modelo utilizado nos bancos de dados relacionais. O advento do modelo relacional atribudo a Ted Codd da IBM em 1970, e imediatamente se popularizou devido sua simplicidade e slidos fundamentos matemticos: baseado na teoria geral dos conjuntos e em lgica matemtica. Os primeiros SGBDs relacionais apareceram na dcada de 1980, sucedendo os bancos de dados hierrquicos e em rede predominantes em mainframes. Desde ento, sua expanso foi enorme, e acabou tornando-se sinnimo de banco de dados. Exemplos de produtos populares so DB2 (IBM), Oracle e MySQL (Oracle), SQLServer (Microsoft) e PostgreSQL (software livre). Dada a relevncia do assunto, tanto esta quanto as prximas duas unidades focaro 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.
67
CONCEituAO
No modelo relacional, o banco de dados representado como um conjunto de relaes. Podemos tentar entender uma relao como uma tabela ou uma planilha de clculo. Observando como uma tabela, cada linha representa uma coleo 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 Ademir Carlos Justino Marcela Sobrenome Santos Silva Carvalho Moreno Nascimento 20/12/1984 26/04/1970 11/07/1981 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 instncia de um contato real. Os nomes das colunas (Nome, Sobrenome, Nascimento) representam informaes 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 relao. O tipo de dado que pode ser inserido em cada coluna denominado de domnio, e representa os valores possveis de cada atributo. Caractersticas de uma Relao A seguir analisaremos as caractersticas atribudas a uma relao (tabela) no modelo relacional:
68
1. Ordem das tuplas. Como uma relao (tabela) representa a noo matemtica de conjunto, relaes no possuem ordem. Isso significa que no h uma ordem natural particular imposta dentro da relao. Como estes dados sero gravados em algum dispositivo de armazenamento, natural que sequencialmente eles estejam dispostos em alguma ordem mas para efeitos do modelo relacional, deve-se assumir que a ordem dos elementos catica. Durante o desenvolvimento de aplicaes, no se deve assumir nenhuma premissa sobre a ordem dos elementos dentro de uma relao. 2. Atomicidade dos valores e o valor Null. No modelo relacional, cada valor de cada atributo dentro de uma tupla atmico. Atmico no mesmo sentido de tomo e em transaes: estes valores no podem ser divididos em outros componentes. Assim, ao menos no modelo relacional puro, no so possveis valores compostos ou mltiplos 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 no se aplicar quela tupla; o valor no possui valor definido; ou o valor desconhecido. No caso da tabela Contato, podemos definir como NULL o atributo Nascimento quando desconhecemos o dia em que nosso Contato nasceu. 3. Semntica de uma relao. Relaes podem representar situaes factuais. Podemos considerar que cada tupla da relao Contato seja um fato: voc, no mundo real, possui um Contato verdadeiro que pode ser abstrado com os dados daquela tupla. Algumas relaes representam dados sobre entidades (como o caso de Contato). Outras relaes podem representar relacionamentos (como seriam os e-mails ou os telefones de cada Contato). No modelo relacional, tanto entidades quanto relacionamentos entre entidades podem ser igualmente representados por relaes (tabelas). Isto simplifica muito o modelo e sua utilizao, pois no precisamos de notaes nem de ferramentas para fazer distino entre as entidades e os relacionamentos entre elas.
69
Bancos de dados livres crescem no Brasil Uma nova gerao de bancos de dados livres comea a ganhar adeso de vrias empresas do setor nanceiro e industrial do pas, revela estudo. GENILSON CEZAR, ESPECIAL PARA COMPUTERWORLD Uma nova gerao de bancos de dados livres comea a ganhar adeso de vrias empresas do setor financeiro e industrial do pas, para aplicaes especficas ou embarcadas em equipamentos de co municao, e j est criando um impacto positivo entre os desenvolvedores. Essa uma concluso do consultor independente Fernando Lozano, community manager da Java. net, apresentada na quarta-feira (17/08) no Developers World 2005, realizado pelo IDG Brasil, no Hotel Jaragu, em So Paulo. Lozano vem trabalhando na implementao de projetos de banco de dados livres em vrias empresas como o Instituto Brasileiro de Petrleo e Gs, Elephant Internet, iBest e Amsterdam Sauer. O banco de dados livre hoje uma alternativa vivel e de alta performance, alm 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 adoo do produto em licitaes pblicas. Muitos desenvolvedores esto decididos a contribuir para o avano do open source, mesmo sem ter qualquer espcie de retorno financeiro, no mximo um outro patrocnio 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.
70
rEStriES DO mODElO rElACiONAl

Restries no modelo relacional so uma forma de se restringir os valores que os atributos das tuplas podem possuir num determinado snapshot. Essas restries podem ser derivadas dos prprios relacionamentos do modelo relacional ou de restries de valores de negcios impostos pelo modelo de software sendo desenvolvido. Os tipos de restries do modelo relacional so de domnio, de chave e de valores nulos, e de integridade e integridade referencial. Estas so descritas nas sees seguintes. Restries de domnio As restries de domnio impem ao banco de dados quais valores podem ser permitidos em cada atributo dentro de cada tupla em cada tabela. Algumas destas restries podem ser de tipo (voc no pode colocar um valor String num campo inteiro ou vice-versa). Outras restries possveis podem restringir valores dentro de um tipo (somente os inteiros maiores que zero). Exploraremos melhor estas restries de domnio quando tratarmos das restries do SQL. restries de chave e de valores nulos Como uma relao (tabela) representa um conjunto na definio formal da teoria dos conjuntos, no h a possibilidade de uma relao conter elementos repetidos; pois num conjunto, todos os elementos so distintos. Desse modo, havendo ou no a possibilidade de se haver registros com dados semelhantes dentro do modelo de negcios, utiliza-se uma restrio denominada de chave primria que define de modo nico cada registro dentro da relao. Esta chave primria pode ser composta de um nico atributo ou mesmo de um conjunto de atributos. No h verdades absolutas na rea de Tecnologia da Informao, mas no passado foi bastante comum a utilizao de chaves primrias compostas para representar as tuplas de uma relao. Matematicamente, no h diferena entre uma chave primria simples (um nico atributo) e
71
uma chave primria composta (mltiplos atributos). Baseando-se no princpio da Navalha de Occam, preferimos optar pela soluo mais simples: chaves primrias simples. Outra prtica atual diz respeito visibilidade por parte do usurio do valor da chave primria. Em aplicaes legadas, bastante comum visualizar este atributo em formulrios cadastrais e em listagens. Uma corrente de pensamento pondera que este nmero no faz sentido ao usurio e no deve ser exibido. No exibi-lo tambm permite que a chave primria seja trocada numa eventualidade em que o particionamento ou a replicao de banco de dados seja necessria e implique numa troca da chave primria. Pense: o usurio deseja ou precisa saber a chave primria ou a sua aplicao que foi projetada para obrigar o usurio a utiliz-la?
Princpio da Navalha de Occam (ou Ockham) Se em tudo o mais forem idnticas as vrias explicaes de um fenmeno, a mais simples a melhor - William de Occam. Popularmente costumamos citar este princpio como: se h mais de uma explicao para um fenmeno, e todas parecem igualmente corretas, ento a mais simples a mais correta. Em que outras partes da sua vida profissional poderamos aplicar com sucesso este princpio?
Outro tipo de restrio so as chaves ou chaves nicas: como o prprio nome j implica, representam atributos dentro de uma tupla que no podem ter valores repetidos. Valores nulos (NULL) podem ser restringidos com uma restrio de non-NULL. Atributos de uma tupla com esta restrio obrigatoriamente devem possuir um valor vlido que no seja nulo.
72
Integridade, Integridade referencial e chaves estrangeiras A restrio de integridade estabelece que nenhuma tupla pode possuir uma chave primria com valor NULL. Como a chave primria utilizada para identificar de modo nico cada tupla da relao, permitir o valor NULL faria com que fosse possvel ter duas tuplas com a mesma chave primria nula sendo impossvel distinguir uma da outra. A restrio de integridade referencial especificada entre duas relaes (tabelas) distintas, e utilizada para manter a consistncia entre tuplas pertencentes s duas relaes. Isto implica que uma restrio de integridade referencial obriga uma tupla numa relao a referenciar a uma tupla existente em outra relao para as quais a integridade referencial foi definida. Contato iD 1 2 3 4 Nome Ademir Carlos Justino Marcela telefone iD 1 2 Figura 5
Fonte: o autor
Sobrenome Santos Silva Carvalho Moreno
Nascimento 20/12/1984 26/04/1970 11/07/1981 03/06/1999
Nmero 443032020 4420201010
contato_id 1 3
Para compreender melhor este conceito, analisemos a Figura 5. Restries de integridade referencial so criadas entre duas tabelas diferentes (ou excepcionalmente na mesma tabela). Veja o relacionamento entre as tabelas Contato e Telefone. Na tabela Telefone, o atributo
73
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.
Estudo de caso:
Detran do Cear economizou R$ 1,7 milho com banco de dados livre Tomada h cerca de dois anos pelo governo do Cear, a deciso de substituir a soluo de banco de dados da Oracle pelo PostgreSQL fez com que o Detran economizasse gastos com pagamento de licenas e servio de suporte tcnico. Em 2008, o administrador de banco de dados Nabucodonosor Coutinho foi convidado pelo Detran do Cear para cuidar do processo de migrao do banco de dados. Em apresentao 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 aplicao ligado a um servidor Oracle. Era nesta situao que as 1.287 tabelas e 426 views do banco se encontravam. Gastava-se muito dinheiro com o pagamento de licenas 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
74
participar do projeto. Quais foram as principais dificuldades encontradas? A principal dificuldade era que a equipe estava ocupada com as tarefas dirias de manuteno e de senvolvimento de novas ferramentas para o rgo. Alm disso, a base de dados era muito complexa e utilizava muitos recursos que at ento estavam disponveis apenas no Oracle. Outro fator negativo foi que poucos tcnicos tinham conhecimento em PostgreSQL. Como a arquitetura do banco hoje? Agora o servidor de aplicao ligado diretamente a um balanceador de carga, que ligado a dois servidores do banco de dados. Alm da economia com as licenas, quais outros resultados positivos a nova arquitetura trouxe? As consultas ficaram mais rpidas. Tem uma que levava 2 horas e, depois da migrao, passou a ser realizada em 6 minutos. Na primeira vez, o responsvel do Detran no acreditou e acabamos gastando 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-banco-de-dados-livre/>. Acesso em: 1 ago. 2012.
Operaes de atualizao do modelo relacional Existem trs operaes bsicas de atualizao que podem alterar o snapshot do banco de dados. Vamos nos referir a estas operaes em seu termo em ingls, pois eles tambm correspondem aos comandos em SQL que veremos nas prximas duas unidades. As operaes so: Insert (Insero), Update (Modificao) e Delete (Remoo). A operao de Insert utilizada para inserir novas tuplas numa relao; a operao Update utilizada para atualizar valores de uma tupla j existente dentro de uma relao; e a operao Delete utilizada para remover uma tupla existente de uma relao. Em cada uma dessas operaes, so verificadas as restries descritas nas sees anteriores. Caso alguma das restries seja violada, o SGBD reportar um erro e a operao no ser completada com sucesso.
75
Insert
A operao de Insert fornece os atributos de uma nova tupla para ser adicionada na relao. Restries de domnio podem ser violadas se algum dos valores atribudos no for do tipo apropriado do atributo. Restries de chave podem ser violadas se alguma outra tupla possuir a mesma chave repetida. Restries de integridade podem ser violadas se a chave primria atribuda for NULL. Restries de integridade referencial podem ser violadas se o valor de qualquer chave estrangeira atribuda no existir no relacionamento referenciado.
Update
A operao de Update modifica os valores de um ou mais atributos em uma ou mais tuplas numa relao. Restries semelhantes operao de Insert podem ser violadas na execuo desta operao.
Delete
A operao de Delete remove uma tupla da relao. A nica restrio que pode ser violada pela operao Delete a restrio de integridade referencial. Neste caso, a tupla sendo removida referenciada por uma outra tupla num relacionamento entre duas relaes.
<http://youtu.be/gx1xT_GzH_g>. Alexandre Porcelli SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011
76
Os bancos de dados relacionais esto condenados? Recentemente uma grande leva de bancos de dados no relacionais surgiram tanto na nuvem quanto fora dela. Uma das principais mensagens que este cenrio nos traz se voc precisa de uma grande escalabilidade sob demanda, voc precisa de um banco de dados no relacional. Se isto for verdade, ento um sinal de que o outrora todo poderoso banco de dados relacional perdeu seu trono? Seria este um sinal de que os bancos de dados relacionais esto com os dias contados e iro declinar com o passar do tempo? Neste artigo ns analisaremos a tendncia atual de se migrar de bancos de dados relacionais em certas situaes e o que isso significa para o futuro dos bancos de dados relacionais. Bancos de dados relacionais j esto presentes no mercado h mais de 30 anos. Durante este tempo, muitas pseudo-revolues surgiram e se foram, e todas elas supostamente deveriam acabar com os bancos de dados relacionais. Todas estas revolues fracassaram, claro, e nenhuma chegou a fazer sequer um arranho na dominncia dos bancos de dados relacionais. Primeiro, um pouco de histrico Um banco de dados relacional essencialmente um grupo de tabelas (entidades). Tabelas so compostas de colunas e linhas (tuplas). Estas tabelas possuem restries, e relacionamentos so defi nidos entre elas. Bancos de dados relacionais so consultados atravs da SQL, e os conjuntos de
77
resultados so produzidos pelas consultas que acessam os dados de uma ou mais tabelas. Mltiplas tabelas sendo acessadas numa nica consulta so unidas, tipicamente por um critrio definido nas colunas de relacionamento das tabelas. Normalizao um modelo de estruturao de dados utilizado em bancos de dados relacionais que garante a consistncia dos dados e remove sua duplicao. Car Carkey 1 2 3 Markekey Colorkey Colorkey Year 1 2 2 1 1 1 2 3 2 2003 2005 2005 Color Colorkey 1 2 3 Color Red Green Blue
makemodel Modelkey Makekey 1 1 1 2 2 1
Model Pathfinder Bluebird Civic
make Makekey 1 2
Make Nissan Honda
Example of a Typical Data Model Bancos de dados relacionais so facilitados atravs de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDR). Praticamente todos os sistemas de bancos de dados em uso atualmente so SGBDRs, incluindo Oracle, SQL Server, MySQL, Sybase, DB2, TeraData etc. Os motivos para a dominncia do modelo relacional no so triviais. Eles tm continuamente oferecido o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade no gerenciamento de dados genricos. Entretanto, para oferecer tudo isto, os bancos de dados tornaram-se incrivelmente complexos internamente. Por exemplo, um relativamente simples comando SELECT pode ter centenas de possveis caminhos de execuo de consulta, os quais o otimizador deve avaliar em tempo de execuo. Tudo isto escondido dos usurios, mas sob o cap os SGBDRs determinam o plano de execuo que melhor atende nossas requisies utilizando recursos como algoritmos baseados em custo. O problema com bancos de dados relacionais Mesmo que os SGBDRs forneam aos usurios o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade, seu desempenho em cada uma destas reas no necessariamente melhor que o de uma soluo alternativa buscando um destes benefcios isolado. Isto no foi um grande problema at agora, pois a dominncia universal dos SGBDRs tem
78
compensado a necessidade de se quebrar essas barreiras. No entanto, se voc realmente tem uma necessidade que no pode ser atendida por um banco de dados relacional genrico, sempre houve alternativas para atender estes nichos. Atualmente vivemos uma situao um pouco diferente. Para um grande nmero de aplicaes, estes benefcios esto se tornando mais e mais crticos; e embora ainda sejam considerados um nicho, esto se tornando populares, tanto que para muitos usurios de bancos de dados estes requisitos esto comeando a sobrepor os outros em importncia. Este benefcio escalabilidade. medida que mais e mais aplicaes so implantadas em ambientes que possuem cargas de trabalho massivas, tais como servios web, seus requisitos de escalabilidade podem mudar rapidamente e crescer a nveis muito elevados. O primeiro cenrio pode ser difcil 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, quo rapidamente voc pode ampliar o seu hardware? O segundo cenrio 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 nico servidor. Quando a capacidade daquele nico servidor alcanada, voc precisa realizar uma escalabilidade horizontal e distribuir a carga entre mltiplos 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 invs de apenas alguns, e as complexidades tornam-se avassaladoras, e as caractersticas que tornam os SGBDRs to atraentes drasticamente reduzem sua viabilidade como plataforma para grandes sistemas distribudos. Os fornecedores de servios na nuvem tiveram que tratar esta limitao, pois uma plataforma na nuvem sem uma base de dados escalvel no chega a ser uma plataforma vivel. Assim, para fornecer aos clientes uma plataforma escalvel para armazenar seus dados, os fornecedores tiveram uma nica soluo. Estes fornecedores tiveram que implementar um novo tipo de sistema de banco de dados que focasse em escalabilidade, ao custo de outros benefcios dos bancos de dados relacionais. Estes esforos, combinados com aqueles de fornecedores de nichos de mercado, levaram criao de uma nova gerao de sistemas gerenciadores de banco de dados. A nova gerao Este novo tipo de sistema gerenciador de banco de dados comumente chamado de chave-valor. De fato, no h ainda um nome oficial, ento possvel encontrar nomes como orientado a documentos, orientado a atributos, banco de dados distribudo (embora bancos de dados distribudos tambm possam ser relacionais), arrays particionados, tabelas hash distribudas, e bancos de dados de chave-valor. Embora cada um destes nomes aponte para peculiaridades especficas desta nova abordagem, so todas variaes do mesmo tema, que chamaremos de bancos de dados de chave-valor. No importa como voc chame, este novo tipo de banco de dados j est no mercado h algum
79
tempo e tem sido utilizado em aplicaes especializadas para as quais os bancos de dados relacionais no serviam. Mas sem a escala que a web e a nuvem trouxeram, este novo tipo teria fica incgnito. Atualmente o desafio identificar se este novo tipo de banco de dados ou um banco de dados relacional o mais adequado para uma aplicao particular. Bancos de dados relacionais e bancos de dados de chave-valor so fundamentalmente diferentes e projetados para atender diferentes requisitos. Uma comparao lado-a-lado permite comparar superficialmente estas diferenas e apresentamos uma inicial abaixo: Definies de banco de dados Bancos de dados relacionais Bancos de dados contm tabelas, tabelas contm linhas e colunas e linhas so compostas dos valores das colunas. Linhas dentro de uma mesma tabela possuem todas as mesmas definies de schema. O modelo de dados conhecido a priori. Um schema fortemente tipado e possui restries e relacionamentos que foram a integridade dos dados. O modelo de dados baseado numa representao natural dos dados que contm, e no nas funcionalidades da aplicao. O modelo de dados normalizado para remover duplicaes de dados. A normalizao estabelece relacionamentos entre tabelas. Estes relacionamentos associam os dados entre as tabelas. Bancos de dados de chave-valor Domnios podem ser visualizados inicialmente como uma tabela, mas diferentemente de uma tabela voc no precisa definir um schema para um domnio. Um domnio basicamente um balde em que voc coloca itens. Itens dentro de um mesmo domnio podem ter diferentes schemas. Itens so identificados por chaves, e um dado item pode ter um conjunto de atributos dinmicos associado. Em algumas implementaes, atributos so do tipo String. Em outras implementaes, atributos possuem tipos simples que refletem os tipos do cdigo tais como ints, arrays de String e listas. No existem relacionamentos definidos de modo explcito entre domnios ou mesmo dentro de um mesmo domnio.
Sem Join de Entidades Bancos de dados de chave-valor so orientados a itens, o que significa que todos os dados relevantes so armazenados dentro do prprio item. Um domnio (que voc pode visualizar como uma tabela) pode conter itens muito diferentes um do outro. Por exemplo, um domnio pode conter itens de clientes e itens de pedidos. Isto significa que comumente os dados so duplicados entre itens num mesmo domnio. Esta uma prtica aceitvel porque espao em disco algo relativamente barato. Mas este modelo permite que um nico item contenha todos os itens relevantes, o que aumenta a escalabilida-
80
de ao eliminar a necessidade de joins entre mltiplas 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 so inevitveis. 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. No importa se estes dados residam no mesmo domnio ou em domnios diferentes; quando um cliente cria um pedido voc provavelmente no quer armazenar os atributos tanto do cliente quanto do produto no mesmo item do pedido. Ao invs disso, pedidos precisam armazenar as chaves dos itens de cliente e produto. Embora isso seja perfeitamente possvel em bancos de dados chave-valor, estes relacionamentos no esto definidos no modelo de dados em si, e portanto o sistema gerenciador de banco de dados no pode forar 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 aplicao. Acesso a dados Bancos de dados relacional Dados so criados, atualizados, removidos e consultados atravs de SQL. Consultas SQL podem acessar os dados de uma nica ou de mltiplas tabelas atravs de joins. Consultas SQL incluem funes de agregao e filtros complexos. Normalmente possuem meios de se embutir lgica prximo aos dados atravs de triggers e stored procedures. Interface com a aplicao Bancos de dados relacional Tendem a oferecer uma API prpria ou uma API genrica como o ODBC ou JDBC. Os dados so armazenados num formato que representa sua estrutura natural, de modo que deve haver um mapeamento entre as estruturas do cdigo da aplicao e a estrutura relacional. vantagens de bancos de dados chave-valor Existem duas claras vantagens dos bancos de dados chave-valor sobre os bancos de dados relacionais. Adequado para a nuvem O primeiro benefcio que os bancos de dados chave-valor so simples e portanto escalam melhor que os bancos de dados relacionais atuais. Se voc est desenvolvendo um sistema com uma equipe
Banco de dados chave-valor Dados so criados, atualizados, removidos e consultados atravs de APIs. Algumas implementaes fornecem uma sintaxe bsica parecida com SQL para definir critrios de filtragem. Somente predicados bsicos de filtragem podem ser aplicados na maioria das vezes. A lgica de integridade da aplicao e seus dados est toda implementada no cdigo da prpria aplicao. Banco de dados chave-valor Tendem a oferecer APIs SOAP e/ou REST para acesso aos dados. Os dados podem ser armazenados de modo mais eficiente em compatibilidade com o cdigo da aplicao, requerendo pouca infraestrutura para suport-lo.
81
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, ento considere seriamente um banco de dados chave-valor. Como bancos de dados chave-valor escalam facilmente e de modo dinmico, tambm so os banco de dados preferidos de servios de fornecedores de armazenamento atravs de web services com potencial de escalabilidade. Usurios tipicamente pagam somente pelo que usam, mas seu uso aumenta medida em que a demanda aumenta. Enquanto isso o fornecedor pode escalar a plataforma dinamicamente baseado na carga total do usurio, com pouqussimas limitaes provocadas pelo tamanho da plataforma. melhor adaptado para o cdigo Modelos de dados relacionais e modelos de cdigo de aplicaes so tipicamente construdos de modo diferente, o que leva a incompatibilidades. Desenvolvedores normalmente superam estas incompatibilidades com cdigo que mapeiam os seus objetos ao modelo relacional, um processo comumente denominado de mapeamento objeto-relacional. Este processo, que essencialmente requer muito cdigo de infraestrutura e no possui valor de negcios imediato, pode demandar uma parcela considervel do tempo e do esforo do desenvolvimento da aplicao. Outros argumentos a favor deste tipo de banco de dados, tais como bancos de dados relacionais podem se tornar pesados ou desajeitados no so convincentes. Mas antes de entrar de cabea no mundo dos bancos de dados chave-valor, considere algumas limitaes existentes. Desvantagens de bancos de dados chave-valor As restries inerentes de um banco de dados relacional garantem que os dados em seu nvel mais baixo possuem integridade. Dados que violam as restries de integridade no podem ser inseridos fisicamente no banco de dados. Estas restries no existem em bancos de dados de chave-valor, ento a responsabilidade de garantir a integridade dos dados da aplicao. Mas o cdigo da aplicao pode conter bugs. Bugs num banco de dados relacional devidamente projetado normalmente no 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 benefcios de um banco de dados relacional que ele te fora a um processo de modelagem de dados. Se bem feito, o processo de modelagem cria uma estrutura lgica no banco de dados que reflete os dados contidos, ao invs de refletir a estrutura da aplicao. Dados, ento, tornam-se quase que independentes de aplicao, o que reflete que outras aplicaes podem utilizar o mesmo conjunto de dados e a lgica da aplicao pode ser alterada sem modificar o modelo de dados. No se esquea tambm da compatibilidade. Diferentemente de bancos de dados relacionais, bancos de dados na nuvem no costumam seguir padres definidos. Embora todos tenham conceitos similares, cada um possui sua prpria API, interfaces de consulta especficas e peculiaridades. Desse
82
modo, voc ter que confiar em seu fornecedor, pois voc no poder simplesmente troc-lo depois se estiver descontente. Limitaes de anlise Na nuvem, bancos de dados chave-valor so compartilhados, o que significa que muitos usurios e aplicaes 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 no pode executar uma consulta que leve mais que 5 segundos. Com o Google AppEngine, voc no pode retornar mais que 1000 itens por consulta. Estas limitaes no so problemas para aplicaes comuns com adio, atualizao, remoo e consulta de poucos itens. Mas o que ocorre quando sua aplicao torna-se bem sucedida? Voc atraiu muitos usurios e ganhou muitos dados, e agora voc quer criar valor agregado para seus usurios 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. Situaes como criao de padres de uso e fornecimento de recomendaes baseado no histrico do usurio podem tornar-se difceis e talvez impossveis em algumas plataformas. Neste caso, voc provavelmente ir implementar um banco de dados analtico em separado, populado a partir de seu banco de dados chave-valor, para que estas anlises sejam executadas. Planeje com antecedncia onde e como voc o far. Voc o hospedaria na nuvem ou on premise? A latncia entre voc e o provedor na nuvem seria um problema? Seu banco de dados chave-valor suporta isso? Se voc possui 100 milhes 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 srio a considerar, mas se esquea da sua necessidade de converter os dados em uma fonte de receita. Toda a escalab do mundo intil se os seus usurios migrarem para seu concorrente porque ele possui funcionalidades mais interessantes. Competidores de servios baseados em nuvem Um bom nmero de fornecedores de servios web agora oferece bancos de dados chave-valor compartilhados no estilo pague-pelo-uso. A maioria deles atende aos critrios definidos at agora, mas cada um possui funcionalidades nicas que variam dos padres que descrevemos at agora. Descreveremos agora de um modo geral alguns bancos de dados particulares, como o SimpleDB, Google AppEngine Datastore e SQL Data Services. Amazon: SimpleDB
83
O SimpleDB um banco de dados de chave-valor orientado a atributos disponvel na plataforma da Amazon Web Services. O SimpleDB possui diversas limitaes. Primeiro, uma consulta pode ser executada por no mximo 5 segundos. Segundo, no h tipos de dados alm de Strings. Tudo armazenado, recuperado e comparado como uma String. Comparaes de data no funcionaro a no ser que voc converta todas as datas para o formato ISO8601. Terceiro, o tamanho mximo de uma String limitado a 1024 bytes, o que limita quanto de texto (por exemplo, descries de produtos) voc pode armazenar num nico atributo. Mas como o schema dinmico e flexvel, voc pode contornar este limite adicionado descricao1, descricao2 etc. O problema que cada item limitado em 256 atributos. Uma caracterstica chave do SimpleDB o seu modelo de consistncia eventual. Este modelo de consistncia bom para concorrncia, mas significa que se voc alterou o atributo de um item, estas mudanas no sero refletidas imediatamente nas operaes de leitura. Embora as chances de algum problema ocorrer em funo disso sejam pequenas, voc deve se preparar para estas situaes. Por exemplo, voc no deseja vender o ltimo ingresso de um show para cinco pessoas diferentes no seu sistema de eventos. google AppEngine Data Store
O Google AppEngine Datastore construdo sobre o BigTable, o sistema interno do Google para manipulao de dados estruturados. Em si, o AppEngine no 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 contm colees de elementos num nico item. Voc provavelmente utilizar este banco de dados se planeja construir aplicaes no Google AppEngine. Entretanto, diferentemente do SimpleDB, voc no consegue interfacear diretamente com o AppEngine Datastore (ou com o BigTable) utilizando uma aplicao foram da nuvem do Google. microsoft: SQl Data Services
84
O SQL Data Services parte da plataforma de servios web Microsoft Azure. O servio do SDS na verdade uma aplicao em si que roda sobre vrios SQL Servers, que formam o mecanismo de armazenamento da plataforma. Embora os bancos de dados de infraestrutura sejam relacionais, voc no precisa acess-los; SDS um banco de dados chave-valor, assim como as outras plataformas discutidas at agora. A Microsoft parece estar sozinha neste cenrio 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 conseguir implementar os mecanismos de escalabilidade e distribuio direito, e com o passar do tempo, adicionar funcionalidades que ajudaro a diminuir a diferena entre bancos de dados chave-valor e relacionais. Fornecedores on-premise Fora da nuvem, existem vrios produtos de bancos de dados chave-valor que podem ser instalados on-premise. A maioria open source; tendo acesso ao cdigo-fonte talvez voc possa analisar e tornar-se melhor ciente de potenciais problemas e limitaes uma vantagem que voc no teria em fornecedores de cdigo fechado. CouchDB
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 distncia entre bancos de dados orientados a documentos e relacionais ao permitir que vises sejam criadas dinamicamente com JavaScript. Estas vises mapeiam os dados do documento numa estrutura parecida com tabelas que podem ser indexadas e consultadas. At o momento, o CouchDB no realmente um banco de dados distribudo. Ele possui funes de replicao que permite que os dados sejam sincronizados entre servidores, mas no o tipo de distribuio suficiente para construir ambientes de alta escalabilidade. A comunidade do CouchDB, entretanto, est trabalhando disso. projeto voldemort
85
O projeto Voldemort um banco de dados distribudo chave-valor cujo objetivo escalar horizontalmente num grande nmero 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 tambm utiliza um modelo de consistncia eventual. mongoDB
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 baseado em JSON, excetuando-se o fato de que ele um verdadeiro banco de dados de objetos ao invs de ser puramente chave-valor. tomando uma deciso Basicamente h quatro motivos para se escolher uma plataforma de banco de dados no relacional chave-valor para sua aplicao: 1. 2. 3. 4. Seus dados so orientados a documentos, tornando-os uma escolha natural para o modelo de chave-valor ao invs do modelo relacional. Seu ambiente de desenvolvimento altamente orientado a objetos, e um banco de dados chave-valor pode diminuir a quantidade de cdigo de infraestrutura. O banco de dados barato e integra com sua plataforma de servios web. Sua principal preocupao a alta escalabilidade sob demanda ou seja, uma escalabilidade distribuda de larga escala que no pode ser obtida com escalabilidade vertical.
Ao tomar sua deciso, lembre-se das limitaes e dos riscos que voc corre ao sair da zona de conforto 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 no. Pelo menos por enquanto. Fonte: <http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php>. Acesso em: 14 ago. 2012.
86
CONSiDErAES FiNAiS
Nesta unidade, inicialmente descrevemos os conceitos de domnio, tuplas, atributos e relaes do modelo relacional. A abordagem deste autor para explicar o modelo relacional a de tentar fugir um pouco das definies formais matemticas do modelo e focar nos conceitos fundamentais do modo mais prximo possvel 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 srie de restries impostas para que se possa garantir a consistncia dos dados presentes nos diferentes domnios, bem como a consistncia do prprio modelo. As restries discutidas foram de domnio, de chave, de valores nulos, de integridade e de integridade referencial e chaves estrangeiras. Estas restries so os atributos que tornam o modelo relacional to interessante e to conceituado perante alguns desenvolvedores e, claro, DBAs. Enxergar o sistema de banco de dados como uma aplicao terceira que deve ser integrada ao software que desenvolvemos uma viso que nos permite entender o porqu de tamanha valorizao das restries. De fato, com estas restries (quando bem implementadas), h a garantia da integridade e consistncia das informaes armazenadas. As operaes de modificao do modelo relacional descritas no modelo relacional so as operaes de Insert, Update e Delete e todas podem provocar violaes do modelo sendo cada uma delas abordada em suas respectivas sees. Agora que j temos toda a base conceitual do popular modelo de dados relacional, podemos passar a interagir e executar operaes com os sistemas de bancos de dados relacionais. Para nossa sorte, h um padro bem estabelecido e slido de interao com os SGBDs relacionais, que a linguagem SQL. O assunto SQL to importante e ser to utilizado em sua vida profissional que dedicaremos as duas prximas unidades para trat-lo.
87
AtiviDADES DE AutOEStuDO
1. Por que no existe uma ordem definida para as tuplas dentro de uma relao? 2. Quais so as situaes em que adequada a utilizao de valores NULL? 3. Defina os conceitos de integridade e integridade referencial.
88
uNiDADE iv
SQl BSiCO
Professor Me. Edson Yanaga Objetivos de Aprendizagem Definir o que SQL. Apresentar os comandos de definio e uso da SQL. plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Definio e histrico da SQL Descrio dos comandos de definio de dados e tipos em SQL Descrio dos comandos de consulta bsicos em SQL Descrio dos comandos de modificao de dados em SQL
iNtrODuO
A primeira ideia que vem cabea de um desenvolvedor experiente quando se fala de banco de dados relacionais SQL. Realmente, talvez uma das boas razes pelas quais os SGBDs relacionais so to difundidos deve-se ao fato de que a SQL uma ferramenta bastante madura, elaborada e bem projetada. Em portugus, pronuncia-se SQL como uma sigla, com o som de cada uma das letras separadas, esse-qu-ele. Porm, nas conversas em projetos internacionais que voc far, ou em conferncias que voc participar em sua vida profissional, perceber que em ingls SQL pronunciado como squel. O motivo curioso e no 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 Ingls Estruturado) da o motivo da pronncia como squel. SQL uma linguagem diferente das linguagens de programao que voc provavelmente aprendeu at agora. Em qualquer curso de programao, costuma-se ensinar inicialmente linguagens de programao imperativas (como C, Pascal, Java ou Python), em que voc responsvel por escrever os comandos na ordem de execuo esperada. Neste tipo de
91
linguagem, preocupamo-nos em instruir o computador no modo como ele deve executar as tarefas. O resultado de seu processamento uma consequncia 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 reflexo sobre a natureza declarativa da SQL. Na SQL, ao definirmos somente o que esperamos de resultado ao invs do como, permitimos que o SGBD decida como que ele deve executar as instrues. H 10 anos, este seria um fator determinante para decidir entre um produto e outro. A evoluo dos produtos comerciais e livres fez com que esta diferena diminusse de modo significativo embora, dependendo dos casos de uso de sua aplicao, a diferena ainda possa ser relevante. Em alguns casos, centenas de parmetros de configurao 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 diferenas entre as diversas implementaes 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 padro para a SQL. A verso mais popular deste padro a SQL-92, embora haja uma verso mais recente: a SQL:1999. Infelizmente, os fabricantes de SGBDs no seguem 100% o padro, o que torna a tarefa de migrao de um produto para outro um pouco mais difcil. Comercialmente, uma estratgia interessante para os fabricantes, pois baseia-se no aprisionamento do cliente: uma vez comprometido com um produto, o custo para migrao (em tempo e esforo) torna-se elevado o suficiente para que o cliente desista da ideia. J para os usurios, este um fato infeliz. De positivo do padro SQL92 temos que mesmo com as sutis diferenas entre as implementaes da SQL em diferentes produtos, as semelhanas se sobressaem e permitem que os desenvolvedores de software possam aprender facilmente a lidar com produtos concorrentes. A SQL possui comandos tanto para a criao de definies de dados (criao de schemas) quanto para a execuo de comandos de manipulao de banco de dados (consultas e
92
atualizaes). uma linguagem bastante abrangente. por este motivo que trataremos da SQL em duas unidades distintas. Esta primeira abordar a criao de schemas e os comandos bsicos da linguagem, enquanto que a prxima unidade abordar os comandos um pouco mais avanados.
DEFiNiES DE DADOS E tipOS Em SQl

Na unidade anterior, definimos os termos relao, tupla e atributo do modelo relacional. Em SQL, estes termos so denominados respectivamente de tabela, linha e coluna. Boa parte dos comandos SQL relacionados criao e definio de dados utiliza o comando CREATE. O conceito de schema Em sua verso inicial, a SQL no possua um mecanismo para agrupar tabelas relacionadas. Como consequncia, 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 um conjunto de tabelas relacionadas. Por exemplo, o seguinte comando cria um schema denominado de agenda. Todos os comandos em SQL so finalizados por um ponto-e-vrgula:
create schema agenda;
Alm de agrupar logicamente as tabelas, um schema tambm convenientemente utilizado para autorizar/restringir o acesso pelos usurios. Voc pode autorizar determinados usurios a acessar um schema e restringir o acesso a outros. O comando CrEAtE tABlE O comando CREATE TABLE utilizado para criar uma nova tabela. O primeiro parmetro do
93
comando o nome da tabela sendo criada, seguido dos atributos e seus respectivos tipos e eventuais restries do atributo. Restries de integridade referencial podem ser definidas ao final do comando. contato id nome sobrenome nascimento peso
email id email contato_fk
telefone id telefone contato_fk
grupo id nome
aflio grupo_fk contato_fk
Figura 6
Fonte: o autor
Os seguintes comandos criam as tabelas definidas na Figura 6:
94
CREATE TABLE contato ( id INT PRIMARY KEY, nome VARCHAR(30) NOT NULL, sobrenome VARCHAR(30) NOT NULL, nascimento DATE, peso DECIMAL(10,2) ); CREATE TABLE email ( id INT PRIMARY KEY, email VARCHAR(60) NOT NULL, contato_fk INT, FOREIGN KEY (contato_fk) REFERENCES contato(id) ); CREATE TABLE telefone ( id INT PRIMARY KEY, telefone VARCHAR(20) NOT NULL, contato_fk INT, FOREIGN KEY (contato_fk) REFERENCES contato(id) ); CREATE TABLE grupo ( id INT PRIMARY KEY, nome VARCHAR(30) NOT NULL ); CREATE TABLE afiliacao ( grupo_fk INT NOT NULL, contato_fk INT NOT NULL, PRIMARY KEY (grupo_fk, contato_fk), FOREIGN KEY (grupo_fk) REFERENCES grupo(id), FOREIGN KEY (contato_fk) REFERENCES contato(id) );
95
Em algumas situaes, no possvel definir as restries de integridade referencial e chave estrangeira no prprio CREATE TABLE, pois as tabelas referenciadas ainda no existem. Na prxima unidade, abordaremos como resolver este impasse. tipos de dados A SQL define um conjunto de tipos de dados bsicos para os seus atributos. Diferentes produtos adicionam tipos de dados diferentes ao conjunto suportado, mas todos os produtos disponveis no mercado suportam ao menos estes tipos bsicos:
Tipos numricos Tipos de dados numricos suportam dados inteiros (INT e SMALLINT) e de ponto flutuante (FLOAT e DOUBLE). Nmeros com preciso decimal (normalmente utilizados em clculos de moeda, por exemplo) so DECIMAL ou NUMERIC, declarados como DECIMAL(a,b) ou NUMERIC(a,b) onde a o nmero de dgitos inteiros e b o nmero de dgitos decimais. Tipos de caractere podem ser de tamanho fixo ou varivel. Os atributos de tamanho fixo podem ser declarados como CHAR(n) onde n o nmero mximo de caracteres suportado pelo atributo. Para especificar um atributo de tamanho varivel, utiliza-se o tipo VARCHAR(n). Para se entender o critrio de uso entre um e outro, necessrio entender como a alocao de espao destes tipos no arquivo fsico. Se o tamanho for fixo (CHAR), o SGBD j aloca este tamanho predefinido no arquivo: as buscas podem ser mais rpidas, pois o SGBD j sabe o tamanho do campo ao pular bytes na busca sequencial. Entretanto, se o contedo dos atributos no preencher todo o tamanho definido, h o desperdcio de espao de armazenamento. Por outro lado, utilizando-se VARCHAR, o SGBD aloca um ponteiro para determinar qual o tamanho do atributo: as buscas so mais lentas, mas no h desperdcio de espao. Tipos booleanos Assim como em linguagens de programao, tipos booleanos podem assumir os valores TRUE ou FALSE. Muitos SGBDs mapeiam estes valores em 1 e 0, respectivamente.
Tipos Caractere
96
Tipos temporais
O tipo DATE suporta dados temporais no formato AAAA-MM-DD (ano, ms, dia), enquanto que o tipo TIME utiliza o formato HH:MM:SS (hora, minuto e segundo). A prpria SQL assegura representaes temporais vlidas.
rEStriES
Seguindo o nosso planejamento, abordaremos agora as restries que podem ser declaradas em SQL no comando CREATE TABLE. Restries adicionais especificadas em outros comandos sero abordadas na prxima unidade. valores Null e valores padro A linguagem SQL permite que todos os atributos (com exceo daqueles que compem a chave primria) sejam nulos. Se o seu modelo de negcios no permite que um atributo seja nulo, necessrio especificar uma restrio de NOT NULL na declarao do atributo. Uma outra considerao (pequena talvez) sobre o NOT NULL que no mnimo o SGBD ter que gravar um bit (ou um byte) a mais em cada atributo em casos de campos NULL. Se um atributo permitir nulos, ento o SGBD ter que primeiramente saber se o campo nulo ou no, e depois armazenar o prprio contedo. Alm de valores nulos, tambm h possibilidade de se definir um valor padro para os atributos utilizando-se a clusula DEFAULT <valor>. Caso este atributo seja omitido durante a insero de uma linha da tabela, assume-se o valor padro. Por padro na SQL, caso nenhuma clusula seja declarada, os atributos permitiro valores nulos e o valor padro tambm ser nulo. Como exemplo, poderamos definir Silva como o sobrenome padro dos nossos contatos no comando CREATE TABLE:
97
CREATE TABLE contato ( id INT PRIMARY KEY, nome VARCHAR(30) NOT NULL, sobrenome VARCHAR(30) NOT NULL DEFAult Silva, nascimento DATE, peso DECIMAL(10,2) );
Chaves e integridade referencial Para especificar uma chave primria, utiliza-se a clusula PRIMARY KEY. Caso a chave primria possua um nico atributo, ela pode ser declarada no prprio atributo (como no exemplo da tabela contato):
id INT primArY KEY
Havendo mais de um atributo na chave primria, necessrio declar-la ao final (como no exemplo da tabela grupo):
primArY KEY (grupo_fk, contato_fk)
A clusula UNIQUE especifica chaves nicas (no primrias) numa tabela. Poderamos alterar a definio da tabela email para garantir que no haja e-mails duplicados em nossa aplicao:
CREATE TABLE email ( id INT PRIMARY KEY, email VARCHAR(60) NOT NULL uNiQuE, contato_fk INT, FOREIGN KEY (contato_fk) REFERENCES contato(id) );
J a integridade referencial e as chaves estrangeiras so definidas por meio da clusula
98
FOREIGN KEY, como utilizada j no nosso exemplo nas tabelas email e telefone:
CREATE TABLE email ( id INT PRIMARY KEY, email VARCHAR(60) NOT NULL, contato_fk INT, FOrEigN KEY (contato_fk) rEFErENCES contato(id) ); CREATE TABLE telefone ( id INT PRIMARY KEY, telefone VARCHAR(20) NOT NULL, contato_fk INT, FOrEigN KEY (contato_fk) rEFErENCES contato(id) );
CONSultAS BSiCAS Em SQl

O comando em SQL para a execuo de operaes de consulta o SELECT, e as consultas que podem ser elaboradas com este comando variam das mais simples at as bem complicadas. Em sua forma fundamental, um comando de consulta SELECT assume a forma SELECT <atributos> FROM <tabelas> WHERE <condies>. De acordo com Silberschatz (1999), a expresso bsica de consulta em SQL consiste de trs clusulas: SELECT, FROM e WHERE: 1. A clusula de SELECT utilizada para listar os atributos desejados no resultado da consulta. 2. A clusula FROM lista as relaes (tabelas) que devem ser examinadas na avaliao da expresso SQL. 3. A clusula WHERE corresponde ao predicado envolvendo os atributos das relaes que aparecem na clusula FROM.
99
As condies do comando SQL podem utilizar comparadores lgicos similares aos de outras linguagens de programao j conhecidas, tais como = (igual), < (menor), <= (menor ou igual), > (maior), >= (maior ou igual) e <> (diferente). Provavelmente, uma das melhores formas de se aprender por meio de exemplos. Ao invs de nos atermos aos detalhes sintticos e conceituais de cada tipo de consulta, apresentaremos exemplos de como realiz-las a seguir. Todos os exemplos de consulta sero realizados tendo-se como base a definio de esquema proposta na Figura 6. Exemplo 1: Selecione o nome e o telefone de todos os contatos cujo sobrenome seja Silva.
SELECT nome, telefone FROM contato, telefone WHERE contato.id = telefone.contato_fk AND contato.sobrenome = Silva;
Neste exemplo, a condio contato.sobrenome = Silva um predicado que seleciona somente as linhas especificadas na tabela contato. A condio contato.id = telefone.contato_fk denominada de condio de join, pois combina duas tabelas diferentes baseadas, neste caso, numa chave estrangeira de um relacionamento entre ambas. Exemplo 2: Selecione o nome, o telefone e o e-mail de todos os contatos cujo nome seja Edson.
SELECT nome, telefone, email FROM contato, telefone, email WHERE contato.id = telefone.contato_fk AND contato.id = email.contato_fk AND contato.nome = Edson;
Neste exemplo pode-se notar que numa consulta permitido realizar o join entre vrias tabelas diferentes; e novamente neste caso, todas esto relacionadas por meio de uma condio de combinao baseada em chaves estrangeiras.
100 BANCO DE DADOS | Educao a Distncia
Exemplo 3: Selecione o id do telefone de todos os contatos cujo peso seja maior que 70.
SELECT telefone.id FROM contato, telefone WHERE contato.peso > 70;
O exemplo 3 mostra como devemos definir os nomes dos atributos nas clusulas quando h a possibilidade de ambiguidade na definio dos nomes. Tanto a tabela contato quanto a tabela telefone possuem um atributo denominado de id. Neste caso, devemos informar SQL qual o atributo id que desejamos obter, prefixando o atributo com o nome de sua respectiva tabela. No caso do exemplo, eliminamos a ambiguidade descrevendo o atributo como telefone.id. Exemplo 4: Selecione o nome do grupo e o nome do contato de todos os contatos cujo nome seja Joaquim.
SELECT contato.nome as n, grupo.nome as g FROM contato, grupo, afiliacao WHERE contato.id = afiliacao.contato_fk AND grupo.id = afiliacao.grupo_fk AND n = Joaquim;
Uma facilidade na construo de consultas que possuem termos repetidos sendo referenciados a criao de um alias. Um alias um apelido definido para um determinado termo da consulta SQL. No Exemplo 4, definimos que o atributo contato.nome possui um alias n e que o atributo grupo.nome possui um alias g. Desse modo, no restante desta consulta, no precisamos mais nos referenciar a estes atributos pela referncia completa, e torna-se possvel ento simplesmente escrevermos a condio final da consulta como sendo n = Joaquim. Exemplo 5: Selecione o peso de todos os contatos com peso < 100.
SELECT c.peso FROM contato c WHERE c.peso < 100;
No exemplo 5, demonstramos que a definio de um alias no est restrita aos atributos; um alias pode tambm ser definido como um apelido para uma tabela na consulta SQL.
101
Exemplo 6: Selecione a data de nascimento de todos os contatos.

SELECT nascimento FROM contato;
A clusula WHERE de uma consulta SQL opcional. Embora em muitos casos voc, como programador(a), deva se questionar se isto oportuno ou no, j que potencialmente a quantidade de registros numa tabela pode chegar aos milhes ou bilhes. Quando a clusula WHERE omitida, a consulta ir processar todos os registros das tabelas referenciadas. No Exemplo 6 demonstramos como obter todas as datas de nascimento por meio do processamento de todas as linhas da tabela contato. Exemplo 7: Selecione todos os atributos de contatos cujo peso = 75.
SELECT * FROM contato WHERE peso = 75;
Quando no se deseja limitar quais atributos devem ser retornados na consulta, pode-se utilizar um asterisco (*) para determinar ao SQL que processe todos os atributos de todas as tabelas da clusula FROM no resultado da consulta SQL. Exemplo 8: Selecione todos os sobrenomes distintos de todos os contatos.
SELECT DISTINCT sobrenome FROM contato;
Embora o modelo relacional seja baseado na teoria geral dos conjuntos e matematicamente em conjuntos no haja elementos repetidos, permite-se elementos repetidos em tabelas, e consequentemente, nos resultados das consultas estes elementos repetidos so exibidos. Nas situaes em que se deseje eliminar as tuplas repetidas nos resultados das consultas, pode-se utilizar a clusula DISTINCT como no Exemplo 8.
Exemplo 9: Selecione todos os telefones cujo nmero comece com 44.

SELECT * FROM telefone WHERE telefone LIKE 44%;
No Exemplo 9, utilizamos o comparador LIKE para definir uma busca por padres em Strings. O caractere % utilizado em condies LIKE para definir zero ou mais caracteres. Neste exemplo, o 44% determina que a String deve iniciar com 44 e pode possuir zero ou mais caracteres posteriores. Exemplo 10: Selecione todos os contatos que nasceram na dcada de 1980.
SELECT * FROM contato WHERE nascimento LIKE 198_-__-__;
Um outro caractere especial que pode ser utilizado em condies LIKE o _. Ele representa um nico caractere arbitrrio utilizado na busca. Como as datas em SQL podem ser representadas como uma String AAAA-MM-DD, utilizamos o _ para preencher os campos da nossa busca. Exemplo 11: Selecione todos os contatos cujo peso esteja entre 90 e 100.
SELECT * FROM contato WHERE peso BETWEEN 90 AND 100;
A condio BETWEEN da SQL pode ser utilizada para determinar intervalos de valor em comparaes.
103
Exemplo 12: Selecione o nome de todos os contatos por ordem alfabtica crescente.
SELECT nome FROM contato ORDER BY nome ASC;
A clusula ORDER BY da SQL permite que o resultado da busca seja ordenado de acordo com os parmetros informados. Uma clusula ORDER BY pode ordenar os resultados de modo ascendente ou descendente. Para tanto, basta adicionar respectivamente o modificador ASC ou DESC na clusula. O valor ASC o padro e o valor assumido caso o modificador seja omitido. Exemplo 13: Selecione o nome e o sobrenome de todos os contatos cujo sobrenome inicie com A e ordene por sobrenome em ordem decrescente e por nome em ordem crescente.
SELECT nome, sobrenome FROM contato WHERE sobrenome LIKE A% ORDER BY sobrenome DESC, nome ASC;
No exemplo 13 demonstramos como ordenar o resultado de uma consulta a partir de dois critrios diferentes. Os critrios so avaliados pela ordem em que so declarados.
COmANDOS DE mODiFiCAO DE DADOS Em SQl

At agora pudemos definir quais so os comandos bsicos da SQL para a execuo de consultas bsicas em nossos bancos de dados. Nesta seo abordaremos os comandos da SQL que permitem a adio, atualizao e remoo de tuplas (linhas), que respectivamente correspondem ao INSERT, UPDATE e DELETE. Abordaremos cada um deles nas prximas subsees.
O comando iNSErt O comando INSERT utilizado para inserir linhas numa determinada tabela. Devido definio formal do schema da tabela, precisamos informar os valores de insero na tabela dentro de uma ordem especfica. Esta ordem pode ser a prpria ordem determinada pela definio do schema ou pode ser a ordem em que definimos os nomes das colunas da clusula de INSERT. O comando INSERT em sua forma mais simples pode ser exemplificado do seguinte modo:
INSERT INTO contato VALUES (10, Edson, Yanaga, 1978-04-12, 95);
Neste exemplo, determinamos que os valores da clusula VALUES seguem a mesma ordem da definio do schema, como definido no incio desta unidade. Note que durante a insero os valores informados devem satisfazer as condies de restries de domnio, integridade, nulo e integridade referencial.
INSERT INTO contato (nome, sobrenome, peso, nascimento, id) VALUES (Edson, Yanaga, 95, 1978-04-12, 10);
Nesta segunda forma do comando INSERT ns especificamos explicitamente qual a ordem desejada de insero de cada um dos atributos da tabela contato. Uma questo que surge para os desenvolvedores : qual seria a forma mais adequada? Certamente no h uma resposta que possa ser considerada melhor ou pior, mas um argumento a favor da segunda forma estabelece que quando a ordem dos argumentos especificada no prprio comando INSERT, evita-se que este torne-se invlido quando o schema da tabela for modificado para adio ou alterao de ordem de alguma coluna. O fato do comando tornar-se invlido provavelmente provocaria um erro da aplicao em tempo de execuo, j que este tipo de bug no pode ser identificado pelo compilador.
105
Uma terceira forma do comando INSERT permite que os valores informados para insero sejam determinados por uma clusula SELECT ao invs de serem argumentos literais na prpria clusula. Podemos criar uma tabela adicional no nosso schema para armazenar estes dados provenientes do comando SELECT:
CREATE TABLE lista_de_nomes ( nome varchar(30), sobrenome varchar(30) );
Baseando-se nos dados j existentes na tabela contato, a recm-criada tabela lista_de_nomes poderia ser populada com o seguinte comando INSERT:
INSERT INTO lista_de_nomes (nome,sobrenome) SELECT nome,sobrenome FROM contato WHERE nascimento > 1980-01-01;
O comando upDAtE O comando UPDATE modifica os valores de uma ou mais tuplas (linhas) das tabelas selecionadas. Neste comando a clusula WHERE determina quais so as linhas da tabela selecionadas para modificao. Em sua forma fundamental, um comando de modificao UPDATE assume a forma UPDATE <tabela> SET <atributos e valores> WHERE <condies>. Note que diferentemente do comando SELECT, um comando UPDATE s pode ser aplicado numa nica tabela. Caso seja necessrio modificar os valores de atributos de mais de uma tabela, vrios comandos UPDATE tero que ser executados todos possivelmente agrupados dentro de uma nica transao.
UPDATE contato SET peso = 99, nascimento = 1982-04-25 WHERE nome = Carlos;
Neste exemplo do comando UPDATE, estamos modificando o valor de dois atributos das tuplas cujo nome = Carlos. uma prtica bastante comum executarmos comandos UPDATE no banco de dados somente identificando a chave primria na clusula WHERE. Assim, temos a garantia de que um nico registro ser modificado de cada vez (j que cada chave primria nica dentro de uma mesma tabela), se assim for o caso de uso desejado.
UPDATE contato SET peso = peso * 1.1;
Assim como no comando SELECT, a clusula WHERE opcional tambm no comando UPDATE. Neste caso, todas as linhas da tabela informada sero selecionadas para a execuo das modificaes solicitadas. No exemplo acima demonstramos que podemos executar operaes aritmticas com os valores dos atributos das tabelas. Neste exemplo, atualizamos para 10% acima o peso de todos os contatos (no caso de uma hipottica epidemia de obesidade).
UPDATE contato SET nascimento = NULL;
O valor nulo tambm pode ser utilizado como valor de atribuio em comandos UPDATE, desde que as restries do schema do banco de dados assim o permita. Assim como o comando INSERT e de acordo com o j explanado na Unidade III todas as restries do schema que se aplicam ao comando INSERT tambm so vlidas para o comando UPDATE.
107
O comando DElEtE O comando DELETE na SQL remove linhas de uma determinada tabela. Assim como os comandos INSERT e UPDATE, possui uma clusula WHERE para limitar as linhas que sero processadas pelo comando. Novamente, assim como nos comandos INSERT e UPDATE, a ausncia da clusula WHERE implica que todas as linhas de uma determinada tabela sero processadas o que no caso do comando DELETE implica que o resultado ser uma tabela vazia. Em sua forma fundamental, um comando de modificao DELETE assume a forma DELETE FROM <tabela> WHERE <condies>.
DELETE FROM telefone WHERE id = 5;
O exemplo acima a forma mais comum de execuo do comando DELETE. A exemplo do comando UPDATE, o comando DELETE s pode ser aplicado em uma nica tabela de cada vez.
DELETE FROM contato;
Um caso extremo, este exemplo resultaria numa tabela contato vazia. Entretanto, como nas operaes de DELETE, as restries de integridade referencial so verificadas, este comando falharia com um erro caso alguma outra tabela (telefone, por exemplo) tivesse alguma chave estrangeira apontando para uma linha da tabela contato.
Sugesto de Vdeo: <http://youtu.be/HJre77TPpSw>. Cezar Taurion, da IBM, fala das vantagens da computao em nuvem.
10 coisas que voc deve saber sobre banco de dados NoSQl Por um quarto de sculo, os Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) tm sido o modelo dominante para gerenciamento de banco de dados. Mas hoje, no relacionais, cloud ou bancos de dados NoSQL esto ganhando ateno como um modelo alternativo para gerenciamento de banco de dados. Neste artigo, abordaremos os 10 aspectos principais destes bancos de dados NoSQL no relacionais: as cinco principais vantagens e os cinco desafios. Cinco vantagens do NoSQl 1. Escalabilidade elstica Por anos, administradores de banco de dados apoiaram-se na escalabilidade vertical que consiste na compra de servidores maiores medida que a carga aumenta ao invs da escalabilidade horizontal distribuio dos bancos de dados em mltiplos servidores medida que a carga aumenta. Entretanto, medida que os requisitos de carga de transaes e disponibilidade aumentam, e os banco de dados movem para a nuvem ou para ambientes virtualizados, as vantagens econmicas da escalabilidade horizontal em hardware comoditizado tornam-se irresistveis. SGBDRs podem no escalar to facilmente em clusters comoditizados, mas a nova gerao de banco de dados NoSQL projetada para expandir-se transparentemente de modo a tirar proveito de novos ns, e normalmente so concebidos com hardware de baixo custo em mente. 2. Big data Assim como os nveis de transaes cresceram absurdamente na ltima dcada, o volume de dados
109
que est sendo armazenado tambm cresceu massivamente. OReilly chamou isto de revoluo industrial dos dados. A capacidade dos SGBDRs tem crescido para se equiparar a estes aumentos, mas assim como os nveis de transaes, as restries de volumes de dados que podem ser efetivamente gerenciados na prtica por um nico SGBDR tornaram-se intolerveis para algumas empresas. Atualmente, os volumes de big data que podem ser manipulados por sistemas NoSQL como o Hadoop superam em muito o que pode ser manipulado pelos maiores SGBDRs disponveis. 3. Adeus DBAs (ou at logo?) Apesar das muitas melhorias de gerenciamento alegadas pelos fornecedores de SGBDRs ao longo dos anos, SGBDRs de alto nvel s podem ser mantidos com a assistncia de caros e altamente treinados DBAs. DBAs esto intimamente envolvidos no projeto, instalao e otimizao de sistemas baseados em SGBDRs. Bancos de dados NoSQL so normalmente concebidos para requerer menos gerenciamento: reparos automticos, distribuio de dados e modelos de dados mais simples tendem a requisitos de administrao e otimizao menores na teoria. Na prtica, provvel que os rumores da morte dos DBAs tenham sido um pouco exagerado. Algum sempre ser responsvel pelo desempenho e disponibilidade de um repositrio de dados de misso crtica. 4. Economia Bancos de dados NoSQL tipicamente utilizam clusters de servidores baratos para gerenciar a exploso no volume de transaes e dados, enquanto que SGBDRs tendem a depender de caros servidores e dispositivos de armazenamento proprietrios. O resultado que o custo por gigabyte ou transaes/ segundo para o NoSQL pode ser muitas vezes menor que o custo de SGBDRs, permitindo que voc armazene e processe os dados com um custo muito menor. 5. Modelos de dados flexveis Gerncia de mudana uma grande dor de cabea para grandes SGBDRs em produo. Cada pequena mudana no modelo de dados deve ser cuidadosamente gerenciada e pode necessitar de downtime ou nveis de servio reduzidos. Bancos de dados NoSQL possuem restries de modelos de dados muito mais flexveis ou inexistentes. Bancos de dados NoSQL do tipo chave-valor ou de documentos permitem que a aplicao virtualmente armazene qualquer estrutura num elemento de dado. Mesmo um banco de dados NoSQL definido de modo mais rgido como aqueles baseados em BigTable (Cassandra e HBase) tipicamente permitem o acrscimo de novas colunas sem maiores problemas. O resultado que as mudanas na aplicao e as mudanas no schema do banco de dados no precisam mais ser gerenciadas como uma nica e complicada mudana. Na teoria, isto permite que as aplicaes possuam ciclos de iterao mais rpidos, embora claramente possa haver efeitos colaterais indesejveis caso a aplicao falhe em gerenciar a integridade dos dados. Cinco desafios do NoSQL A promessa dos bancos de dados NoSQL gerou muito entusiasmo, mas ainda h obstculos a serem superados antes que eles possam seduzir grandes empresas mais conservadoras. A seguir listamos alguns dos principais desafios.
1. maturidade SGBDRs j esto por a h um longo tempo. Defensores do NoSQL argumentaro que sua idade avanada um sinal de sua obsolescncia, mas para a maioria dos CIOs, a maturidade dos SGBDRs reconfortante. Para a maioria, SGBDRs so estveis e ricos em funcionalidades. Em comparao, muitas alternativas NoSQL so verses de pr-produo em que muitas funcionalidades importantes ainda devem ser implementadas. 2. Suporte Empresas querem a garantia de que se um sistema chave falhar, tero um suporte competente com um tempo de resposta aceitvel. Todos os fornecedores de SGBDRs trabalham bastante para conseguirem fornecer um elevado nvel de suporte corporativo. Em contraste, muitos sistemas NoSQL so projetos open-source, e embora existam muitas empresas oferecendo suporte a banco de dados NoSQL, estas empresas normalmente so pequenas startups sem o alcance global, recursos de suporte ou credibilidade de empresas como Oracle, Microsoft ou IBM. 3. Business intelligence e Business Analytics Banco de bancos NoSQL evoluram para atender a demanda de escala de modernas aplicaes Web 2.0. Consequentemente, a maioria de suas funcionalidades est relacionada s demandas destas aplicaes. Entretanto, os dados de uma aplicao tm um valor para o negcio que vai alm do ciclo de insert-read-update-delete de uma tpica aplicao Web. Empresas mineram informaes em banco de dados corporativos para melhorar sua eficincia e competitividade, e business intelligence (BI) um ativo valioso de TI para todas as mdias e grandes empresas. Bancos de dados NoSQL oferecem poucas funcionalidades para consultas e anlises ad-hoc. Mesmo uma simples consulta exige um domnio significativo de programao, e muitas ferramentas de BI populares no fornecem conectividade a NoSQL. Algum alvio trazido pelo surgimento de soluo como HIVE e PIG, que podem fornecer um fcil acesso a dados em clusters Hadoop e eventualmente outros bancos de dados NoSQL. A Quest Software desenvolveu um produto Toad for Cloud Databases que pode fornecer a capacidade de consultas ad-hoc em uma boa variedade de bancos de dados NoSQL. 4. Administrao Os objetivos de projeto do NoSQL podem ser o de fornecer uma soluo com custo zero de administrao, mas a realidade atual ainda no esta. O NoSQL hoje requer muita habilidade para instalar e muito esforo de manuteno. 5. Expertise Existem literalmente milhes de desenvolvedores no mundo todo, em praticamente todo segmento de negcios, que esto familiarizados com os conceitos e programao em SGBDRs. Em contraste, praticamente todo desenvolver NoSQL ainda est em processo de aprendizado. Esta situao ser resolvida naturalmente com o passar do tempo, mas por enquanto, muito mais fcil encontrar programadores ou administradores SGBDR que um expert em NoSQL. Concluso Bancos de dados NoSQL esto se tornando uma crescente e importante parte do cenrio de banBANCO DE DADOS | Educao a Distncia
111
co de dados, e quando utilizados de modo apropriado, podem oferecer benefcios reais. Entretanto, empresas devem proceder com cautela com total conscincia das limitaes e problemas que esto associados com estes bancos de dados. Guy Harrison o diretor de pesquisa e desenvolvimento da Quest Software. Um reconhecido expert em banco de dados com mais de 20 anos de experincia em aplicaes, administrao de banco de dados, tuning de desempenho e desenvolvimento de software. Guy autor de vrios livros e diversos artigos em tecnologias de banco de dados e um palestrante regular em conferncias tcnicas. Fonte: <http://www.techrepublic.com/blog/10things/10-things-you-should-know-about-nosql-databases/1772>. Acesso em: 12 ago. 2012.
Blog do Cezar Taurion, BigData e Cloud Computing:
Evangelista
da
IBM
no
Brasil
especialista
em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/?lang=pt_br>.
CONSiDErAES FiNAiS
Finalizada a leitura desta unidade, j temos a convico de que voc, como profissional comprometido(a) e fluente em ingls que (sim, na rea de Tecnologia da Informao ingls obrigatrio e deveria ser o idioma principal), j abordar seus colegas, alunos(as) e profissionais, falando squel ao invs do famigerado esse-qu-ele quando se referir linguagem SQL. Como toda tecnologia e assunto novo, SQL exige prtica para o domnio. Este autor acredita piamente na educao por meio de exemplos como a melhor forma de se formar profissionais que consigam utilizar os conhecimentos assimilados na execuo prtica das tarefas. Durante as sees desta unidade, pudemos estudar a formao dos comandos INSERT, UPDATE e DELETE e suas respectivas sintaxes e clusulas individuais. Em seguida, por meio de exemplos, praticamos uma srie de diferentes definies de comandos e explicamos o que se esperava de cada um deles, bem como sua motivao. Crie seus prprios schemas baseado(a) nas abstraes reais do mundo que o cerca. Exercite-se e execute consultas e comandos de
modificao SQL nestes seus schemas. Com a prtica cotidiana voc perceber que SQL tambm bastante simples. At agora fomos capazes de abordar as estruturas bsicas da linguagem SQL. Na prxima unidade, poderemos nos dedicar a alguns casos mais elaborados de uso desta popular linguagem.
Todas as atividades de autoestudo desta unidade baseiam-se na Figura abaixo. aluno id nome sobrenome ra email
professor id nome sobrenome titulao
curso id nome ano
matricula disciplina_fk aluno_fk
disciplina id nome curso_fk professor_fk
1. Considere o exemplo de schema da figura apresentada. Crie os comandos SQL para definio e criao das tabelas. a. Elabore consultas SQL para selecionar: b. O nome de todos os alunos matriculados no curso com nome = Banco de Dados. c. A titulao do professor da disciplina com nome = SQL.
113
d. O nome, sobrenome e ra de todos os alunos matriculados nas disciplinas lecionadas pelo professor com nome Edson. e. Todos os atributos de todos os cursos com ano > 1990. 3. Elabore comandos de modificao de dados para incluir, modificar e remover linhas das diferentes tabelas deste schema.
uNiDADE v
mAiS SQl
Professor Me. Edson Yanaga Objetivos de Aprendizagem Definir consultas complexas em SQL. Apresentar os comandos de alterao de definies em SQL. plano de Estudo A seguir, apresentam-se os tpicos que voc estudar nesta unidade: Definio de consultas em SQL envolvendo NULL Descrio de consultas em SQL com subqueries Descrio de consultas em SQL com diferentes tipos de join Descrio de consultas em SQL com funes de agregao Descrio de comandos em SQL para alterao de schema
iNtrODuO
Agora que j aprendemos a sintaxe bsica dos comandos SQL, podemos nos aventurar em consultas um pouco mais complexas. Em praticamente todos os sistemas de bancos de dados disponveis no mercado, sejam eles relacionais ou NoSQL, as funes de consulta e manipulao bsicas se equivalem. Isso significa que com o material estudado at a unidade anterior, ainda no foi possvel perceber um dos bons diferenciais competitivos dos bancos de dados relacionais, que justamente a capacidade de se executar estas consultas um pouco mais complexas e sofisticadas. Quando citamos estas consultas um pouco mais complexas do SQL, no o fazemos com o propsito de intimid-lo(a). Muito pelo contrrio. Aprendemos com a Teoria Geral dos Sistemas que sempre que h um problema complexo, possvel dividi-lo em problemas menores at que estes sejam de fcil resoluo. com esta definio em mente que apresentaremos nesta unidade uma grande variedade de exemplos que podem ser solucionados com estas consultas mais elaboradas da SQL.
117
Nas prximas sees, abordaremos consultas envolvendo valores nulos, subqueries, consultas com joins e consultas com funes de agregao; alm dos comandos de alterao de schema.
CONSultAS ENvOlvENDO Null

Ns j abordamos na Unidade III que o valor NULL representa um valor ausente, mas que pode ter diferentes interpretaes. Algumas possibilidades de uso para o valor NULL so: O valor desconhecido. Pensando na tabela telefone do exemplo da Unidade IV, um telefone pode ser NULL se voc no sabe o valor do telefone do contato. O valor no est disponvel. No caso do telefone, voc conhece o nmero do telefone do contato, mas no gostaria que ele fosse exibido ou armazenado, setando o valor NULL para represent-lo. O valor no aplicvel. Caso algum contato no tenha telefone, certamente no faz sentido armazenar esta informao.
A avaliao de comandos de consulta SQL com valores NULL merece uma ateno especial. Todos os fundamentos de computao baseiam-se na lgica booleana, o que implica que as expresses possuem sempre somente dois valores possveis: verdadeiro (TRUE) ou falso (FALSE). Como em SQL os atributos podem ter valor nulo, agora as expresses que envolvem os atributos podem resultar em valores verdadeiros (TRUE), falso (FALSE) ou um terceiro valor que representado por NULL. Este terceiro valor pode ser checado de um modo especial com os operadores SQL definidos, como IS e IS NOT. Ademais, todas as condies da clusula WHERE de comandos SQL filtram as linhas baseando-se no valor verdadeiro (TRUE) das expresses. Nesse caso, linhas que sejam avaliadas pelas expresses da clusula WHERE como falso (FALSE) ou como o valor representado por NULL simplesmente so descartadas (com exceo da operao de OUTER JOIN que veremos mais adiante nesta unidade).
Comecemos com alguns exemplos ainda baseados no schema apresentado na Unidade IV. Exemplo 1: Selecione todos os contatos que no possuem data de nascimento definida.
SELECT * FROM contato WHERE nascimento IS NULL;
Exemplo 2: Situao oposta a do Exemplo 1, selecionaremos todos os contatos que possuem uma data de nascimento definida.
SELECT * FROM contato WHERE nascimento IS NOT NULL;
Consultas aninhadas (Subqueries) Algumas consultas em SQL so mais facilmente construdas se pudermos buscar primeiramente alguns valores das tabelas e utiliz-los posteriormente em nossa consulta. Estas consultas diferenciadas podem ser formuladas com uma certa convenincia por meio de consultas aninhadas (uma consulta dentro de outra) ou, como popularmente denominadas, de subqueries. Exemplo 3: Selecione todos os telefones de contatos com sobrenome = Machado.
SELECT telefone FROM telefone, contato WHERE contato.id = telefone.contato_fk and sobrenome = Machado;
A consulta acima foi criada utilizando-se um join normal. Agora no exemplo abaixo a reescreveremos utilizando uma subquery.
119
SELECT telefone FROM telefone WHERE contato_fk IN ( SELECT id FROM contato WHERE sobrenome = Machado );
Uma dvida comum a muitos desenvolvedores est relacionada frequncia de uso de cada opo. Matematicamente, de acordo com o modelo relacional, no h diferena entre as duas consultas: so equivalentes. Toda consulta que utiliza um join pode ser reescrita na forma de uma consulta aninhada (com subqueries). Decidir entre uma forma e outra passa a ser uma questo de gosto, convenincia e legibilidade de cdigo. H alguns anos, poderia ser argumentado que uma forma seria mais rpida que outra ou vice-versa. Entretanto, devido evoluo dos interpretadores de SQL nos SGBDs modernos, esta diferena hoje praticamente nula: todos os SGBDs modificam internamente as consultas fornecidas e automaticamente j escolhem o melhor plano de execuo. Isto faz com que boa parte das supostas otimizaes que muitos DBAs realizam em consultas SQL tornem-se incuas, pois o SGBD na maioria das vezes reescrever as consultas para a melhor forma possvel2. No exemplo acima, note o uso da clusula IN (<subquery>). A clusula IN espera um conjunto de valores sendo retornado pela subquery dentro dos parnteses, que deve ser compatvel com o atributo sendo comparado pela clusula IN. Na hiptese de voc ter certeza da sua subquery retornar um nico valor ao invs de retornar um conjunto de valores, pode substituir o IN pelo operador de igual (=). Mas mesmo nas situaes de um nico valor sendo retornado
2
Justia seja feita, em algumas situaes (talvez 5% ou 10% dos casos), um bom conhecimento do funcionamento
do interpretador SQL do SGBD pode fazer diferena. Mas como j citou Knuth (1974, p.268), a otimizao prematura a raiz de todo o mal. Primeiro implemente os casos de uso de seu software e depois, num eventual gargalo, otimize.
o operador, IN continua equivalente. por este motivo que muitos programadores acabam adotando a conveno de se utilizar o operador IN em todas as consultas que envolvem subqueries. Considere nos exemplos a partir de agora o seguinte schema representado pela Figura 7: funcionrio id nome sobrenome cargo
subordinado id nome sobrenome superior_fk
Figura 7
Fonte: o autor
O schema da Figura 7 pode ser construdo da seguinte forma:
121
CREATE TABLE funcionario ( id int primary key, nome varchar(30), sobrenome varchar(30), cargo varchar(30) ); CREATE TABLE subordinado ( id int primary key, nome varchar(30), sobrenome varchar(30), superior_fk int, FOREIGN KEY (superior_fk) REFERENCES funcionario(id) );
Exemplo 4 Selecione o nome e sobrenome de todos os funcionrios que possuem subordinados com o mesmo nome.
SELECT f.nome, f.sobrenome FROM funcionario AS f, subordinado AS s WHERE f.id = s.superior_fk AND f.nome = s.nome;
Reescrevendo o exemplo acima com uma subquery:

SELECT f.nome, f.sobrenome FROM funcionario AS f WHERE id IN( SELECT superior_fk FROM subordinado AS s WHERE f.nome = s.nome );
Este exemplo reescrito com uma subquery um caso especial de consulta aninhada em
SQL, pois como pode notar, a subquery utiliza atributos da consulta externa em sua clusula WHERE. Chamamos este caso especial de consultas aninhadas correlacionadas.
SELECT f.nome, f.sobrenome FROM funcionario AS f WHERE EXISTS ( SELECT * FROM subordinado AS s WHERE f.nome = s.nome );
Apresentamos a mesma consulta do exemplo reescrita acima com um novo operador denominado de EXISTS. Este operador retorna um resultado verdadeiro (TRUE) se a sua subquery retornar ao menos uma linha de resultado e falso (FALSE) se o resultado for vazio. Exemplo 5: Selecione o nome e o sobrenome de todos os funcionrios que no possuem subordinados.
SELECT f.nome, f.sobrenome FROM funcionario AS f WHERE NOT EXISTS ( SELECT * FROM subordinado AS s WHERE s.superior_fk = f.id );
A exemplo do operador EXISTS, o operador NOT EXISTS retorna o oposto do operador EXISTS, sendo falso (FALSE) se o resultado possui ao menos uma linha e verdadeiro (TRUE) se o resultado for vazio.
123
CONSultAS utiliZANDO JOINS

Na Unidade IV ns vimos que o conceito de join permite que faamos consultas que utilizam duas ou mais tabelas, unidas por meio de uma ou mais condies que unem os elementos das duas ou mais tabelas. Em alguns casos, mais fcil compreender as consultas se estas forem escritas na forma com join ao invs de misturar as condies de join na clusula WHERE. Voltemos a utilizar o schema definido na Unidade IV em nossos exemplos abaixo. Exemplo 6: Selecione o nome de todos os contatos cujo telefone inicie com 44.
SELECT nome FROM contato, telefone WHERE contato.id = telefone.contato_fk and telefone.telefone LIKE 44%;
Agora vejamos esta mesma consulta reescrita com um JOIN:

SELECT nome FROM (contato JOIN telefone ON contato.id = telefone.contato_fk) WHERE telefone.telefone LIKE 44%;
Neste caso do exemplo reescrito com JOIN, a clusula FROM possui uma joined table que contm todos os atributos de ambas as tabelas unidas pelo JOIN e pela condio do JOIN, que o predicado aps o ON. Na SQL o tipo de JOIN padro quando simplesmente declarado pela clusula JOIN o inner join, que descarta todas as tuplas que no possuam um valor correspondente na segunda tabela do JOIN. Os outros tipos de JOIN disponveis so descritos na tabela a seguir:
Tipo de JOIN INNER JOIN
Semntica o tipo de JOIN padro. Somente tuplas que satisfaam a condio do JOIN so selecionadas. Todas as tuplas da tabela do lado esquerdo do ON so selecionadas. Caso no haja uma tupla correspondente na tabela do lado direito do JOIN, os valores so preenchidos com NULL. a condio inversa do LEFT JOIN. Todas as tuplas da tabela do lado direito do ON so selecionadas. Caso no haja uma tupla correspondente na tabela do lado esquerdo do JOIN, os valores so preenchidos com NULL. Todas as tuplas dos dois lados do JOIN so selecionadas. Caso no haja correspondncia na condio do JOIN, o lado vazio preenchido com NULL.
LEFT OUTER JOIN ou LEFT JOIN
RIGHT OUTER JOIN ou RIGHT JOIN
FULL OUTER JOIN ou FULL JOIN
Exemplo 7: Selecione todos os nomes de contatos que iniciem com a letra A e seus respectivos telefones. Se o contato no tiver um telefone, mostre somente o nome e NULL como o valor do telefone.
SELECT nome, telefone FROM contato LEFT JOIN telefone ON contato.id = telefone.contato_fk WHERE contato.nome LIKE A%;
Um caso tpico de LEFT JOIN em que voc deseja listar todos os contatos, tendo eles telefone ou no.
125
CONSultAS COm FuNES DE AgrEgAO

Uma das grandes vantagens da SQL e dos bancos de dados relacionais, se comparados com outras alternativas no relacionais, so as suas funes de agregao. Estas funes permitem uma anlise resumida das informaes armazenadas nas tabelas. Funes de agregao populares da SQL incluem COUNT, SUM, MAX, MIN e AVG que executam as funes matemticas respectivas de contagem, soma, valor mximo, valor mnimo e mdia aritmtica. Exemplo 8: Selecione o peso mnimo e mximo de todos os contatos.
SELECT MAX(peso), MIN(peso) FROM contato;
As funes de agregao em SQL recebem como parmetro o nome do atributo em que se deseja aplic-las. Neste exemplo, o caso do atributo peso. Exemplo 9: Selecione o nmero total de contatos cujo peso > 80;
SELECT COUNT(*) FROM contato WHERE peso > 80;
Neste uso da funo COUNT, o asterisco (*) representa o nmero de linhas do resultado da consulta, e bastante utilizado para se determinar a quantidade de resultados retornados. Exemplo 10: Selecione a quantidade de pesos distintos de todos os contatos.
SELECT COUNT(DISTINCT peso) FROM contato;
Neste exemplo contamos a quantidade de pesos distintos de nossos contatos. Caso a clusula
DISTINCT no fosse aplicada, contaramos somente a quantidade de pesos dos contatos. Funes de agrupamento Em muitas situaes, desejamos aplicar as funes de agregao no em todos os itens das tuplas selecionadas, mas em determinados grupos de tuplas separados dentro da tabela baseados em um determinado valor. Para conseguir este objetivo em SQL, utilizamos a clusula GROUP BY. Ao utilizarmos o GROUP BY, separamos as tuplas em grupos distintos em que todas tuplas dentro de um determinado grupo possuem o mesmo valor avaliado pelas condies do GROUP BY. Exemplo 11: Selecione o sobrenome e quantidade de contatos que possuem o mesmo sobrenome.
SELECT sobrenome, COUNT(*) FROM contato GROUP by sobrenome;
Na avaliao desta consulta, todas as tuplas da tabela contato so divididas em grupos cujo sobrenome seja igual. Ao aplicarmos a funo COUNT(*), ao invs dela contar todas as tuplas da tabela, ela conta somente as tuplas de cada grupo. O resultado uma lista que contm os sobrenomes e as quantidades de contatos com cada sobrenome. Exemplo 12: Selecione o sobrenome e quantidade de contatos que possuem o mesmo sobrenome, desde que haja pelo menos dois contatos com o mesmo sobrenome.
SELECT sobrenome, COUNT(*) FROM contato GROUP by sobrenome HAVING COUNT(*) > 1;
Em algumas situaes, desejamos agrupar as tuplas em grupos, mas queremos selecionar
127
apenas alguns destes grupos no resultado e no todos. A clusula que permite filtrar quais grupos sero exibidos no resultado a HAVING. Somente grupos que satisfaam a condio imposta pelo HAVING so selecionados no resultado. importante salientar a diferena entre as clusulas WHERE e HAVING, pois aparentemente ambas filtram os resultados da consulta. A clusula WHERE filtra as tuplas avaliadas primeiramente. Portanto, a clusula WHERE avaliada antes de qualquer funo de agregao ou qualquer agrupamento ser avaliado. J a clusula HAVING avaliada somente depois que os grupos j foram formados, e serve ento para filtrar estes grupos do resultado final.
COmANDOS DE AltErAO DE SCHEMA

Ns definimos como schema evolution o processo de alteraes da estrutura do schema. Normalmente, estas alteraes de estrutura no so frequentes e so motivadas por alteraes dos requisitos do negcio, e consequentemente tambm da aplicao. Os comandos em SQL que podem alterar as definies de schema so os comandos para adicionar, modificar e remover schemas, tabelas, atributos e restries. Vamos abord-los nos exemplos seguintes. Exemplo 13: Remova o schema agenda do banco de dados.
DROP SCHEMA agenda;
Este comando remove o schema, e por consequncia, todas as tabelas dentro do schema. H uma certa controvrsia neste comando. Alguns SGBDs removem todas as tabelas do schema ao remover o prprio schema. Outros s permitem a remoo do schema se ele no contiver nenhuma tabela, sendo necessrio remover todas as tabelas antecipadamente.
Exemplo 14: Remova a tabela telefone do schema.

DROP TABLE telefone;
Neste exemplo, a tabela telefone seria removida do schema. importante notar que a tabela sendo removida do schema pode conter dependncias de integridade referencial e chave estrangeira em outras tabelas. Nesse caso, se alguma outra tabela depender da tabela sendo removida, este comando ir falhar devido restrio de integridade referencial do banco, sendo necessrio primeiro remover a integridade referencial. Exemplo 15: Adicione uma coluna apelido na tabela contato contendo 15 caracteres.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15);
Este exemplo adiciona uma coluna denominada apelido no final da definio da tabela contato com o tipo definido de VARCHAR(15). Quando um valor DEFAULT no especificado no ALTER TABLE, todas as tuplas existentes na tabela recebem um valor NULL na coluna adicionada. Exemplo 16: Adicione uma coluna apelido na tabela contato contendo 15 caracteres e com valor padro de Senhor.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15) DEFAULT Senhor;
O Exemplo 16 a mesma situao do Exemplo 15, apenas definindo um valor padro para a coluna sendo adicionada. Exemplo 17: Altere o tamanho da coluna apelido para 25 caracteres.
ALTER TABLE contato ALTER COLUMN apelido VARCHAR(25);
A definio da coluna apelido da tabela contato foi modificada e o seu tipo de dados agora define a capacidade de 25 caracteres.
129
Exemplo 18: Remova a coluna apelido da tabela contato.

ALTER TABLE contato DROP COLUMN apelido;
A coluna apelido removida da tabela contato desde que no haja nenhuma restrio de integridade referencial nesta coluna. Exemplo 19: Supondo que ainda no houvesse uma integridade referencial entre a tabela telefone e a tabela contato, adicione-a.
ALTER TABLE telefone ADD FOREIGN KEY (contato_fk) REFERENCES contato(id);
Este comando adiciona a restrio de integridade referecial entre a tabela telefone e a tabela contato. Tambm possvel remover as restries de integridade referencial por meio do comando ALTER TABLE <tabela> DROP FOREIGN KEY <nome>, mas para tanto, necessrio saber o nome da restrio no banco de dados. Como os comandos para exibio das restries das tabelas variam muito de um produto para outro, deixaremos esta soluo como uma sugesto de estudo para voc.
<http://youtu.be/S2iQ2RKMw-w>. Entrevista com Fernando de la Riva, scio-diretor da Concrete Solutions, falando das perspectivas para o mercado em 2012, incluindo Cloud Computing e NoSQL.
NoSQL, sem problemas Uma introduo a banco de dados NoSQL Desvendar o NoSQL e tentar explicar o que e por que voc deveria se interessar ou no uma tarefa difcil. Este artigo tenta dar uma introduo de alto nvel ao NoSQL e fornece uma comparao das ltimas tecnologias disponveis desta rea. introduo Desvendar o NoSQL e tentar explicar o que e por que voc deveria se interessar ou no uma tarefa difcil. O termo cobre uma grande variedade de tecnologias, arquitetura de dados e prioridades; ele representa tanto um movimento quanto a uma escola de pensamento ou uma tecnologia particular. Mesmo o nome confuso, pois para alguns, isto representa qualquer mecanismo de armazenamento de dados que no utilize SQL, mas at agora a indstria parece ter estabelecido como Not Only SQL (no somente SQL). medida que o tempo passe, provvel que o termo cresa at o momento em que perca o sentido e subdivises tornem-se necessrias para clarificar o significado do termo. O que NoSQL? O movimento NoSQL um pedao de um marketing de guerrilha que traz um grande grupo de tecnlogos e tecnologias sob a mesma bandeira. As ideias que baseiam a infinidade de soluo que existe sob o termo NoSQL antes estavam somente disponveis para aqueles cujas necessidades tornaram necessria uma implementao prpria e especfica. Nas reas em que estas solues so uma necessidade, seu valor j foi provado, e agora o uso destas solues passou a ser uma opo para outros com um custo de investimento muito menor. Para qualquer organizao que tenha que escolher entre NoSQL e dados relacionais tradicionais, h a difcil questo de qual das duas utilizar. Ainda muito cedo para fornecer uma resposta decisiva e definitiva, mas est claro que muitas organizaes podem se beneficiar de um modelo de dados que se encaixe melhor nos tipos de armazenamento e consulta que eles executam na prtica do que na teoria. Tambm parece provvel que a maioria das solues consistir de um hbrido misto de tecnologias de armazenamento, assim como um misto de estruturas de N-camadas e cliente-servidor tende a ser mais comum do que comprometimentos absolutos com uma nica estratgia. Lderes tcnicos tm um papel importante na compreenso das opes disponveis e na adaptao do software, produtos e servios que mais se aplicam ao seu domnio de negcios. Possuir uma estratgia lgica e localizada para a adoo do que o NoSQL oferece de melhor ser o fator que diferenciar
131
o sucesso do fracasso em sua adoo. Assim como o NoSQL apresenta novos desafios, ele tambm oferece recompensas significativas queles que o incorporam com sucesso no seu portfolio de soluo. Os principais benefcios viro da maior compreenso sobre os dados, escalonamento flexvel e produtividade. A rica variedade de novos modelos de negcios possuem requisitos de armazenamento que so suportados pelo NoSQL e as dcadas de coero de dados em modelos relacionais ficaram para trs. NoSQL uma rea grande e em expanso. Para os propsitos deste artigo, as caractersticas mais comuns de banco de dados NoSQL so: 1. Facilidade de uso em clusters com balanceamento de carga tradicionais; 2. Dados persistentes (no somente cachs); 3. Escalabilidade na memria disponvel; 4. No possuem schemas fixos e permitem a migrao de schemas sem indisponibilidade; 5. Possui sistemas de consulta individuais ao invs de uma linguagem de consulta padro; 6. So ACID dentro de um n no cluster e eventualmente consistentes dentro do cluster. Nem todos os produtos deste artigo possuem todas estas propriedades, mas a maioria dos bancos de dados que discutiremos suporta boa parte destas caractersticas. O que est acontecendo agora? Movimentos em tecnologia ou em correntes de pensamento raramente acontecem de modo totalmente espontneo. Existem trs principais motivaes por trs do elevado interesse em NoSQL. Primeiro foi o surgimento de uma nova forma de perfil de trfego provocada pelo que pode ser chamado de Web 2.0 ou de Web Social, assim como a Internet de varejo. Web Scale, como comumente referido, o problema de capacidade de planejamento, escala e provisionamento que tornou-se crtico para muitos negcios na Web nos ltimos cinco anos. medida que o mundo torna-se mais conectado, possvel que sites recebam variaes enormes de trfego. Algumas destas esto relacionadas a eventos previsveis: a Copa do Mundo ou o Natal; outros so imprevisveis e globais, como por exemplo, o 11 de Setembro. Sites como o Facebook tornaram fcil a escalada de popularidade de sites medida que itens tornam-se virais e so distribudos pelo mundo todo. Contedos criados pelo usurio causam dores de cabea particulares, pois os problemas relacionados a websites com leitura intensiva j so solucionados com a utilizao de contedo esttico e CDNs (Content Distribution Networks Redes de Distribuio de Contedo). Contedos criados pelo usurio significam que os sites tornam-se mais equilibrados no quesito leitura-escrita. Sites como o Twitter recebem montanhas de trfego em intervalos muito curtos de tempo (um gol validado ou invalidado, a apurao de uma votao ou o final de um seriado ou novela de TV), e sua infraestrutura deve se adaptar rapidamente para no ficar indisponvel na hora errada. A abordagem normal para
escalabilidade tem sido adicionar novos servidores web, que funciona at o ponto em que o banco de dados (que historicamente tem sido um nico grande servidor) torna-se o gargalo. A resposta ento comprar progressivamente um hardware cada vez mais poderoso at que o banco de dados possa servir todo o trfego. A Web Scale invalida este modelo quando voc tem que enfrentar o dilema de comprar um hardware caro para atender sua demanda de pico (Natal ou Copa do Mundo), mas que ficar quase que totalmente ocioso no dia a dia. Para alguns empreendimentos, simplesmente impossvel comprar o hardware e as licenas de software para atender a demanda de pico atravs de um nico servidor. Estes empreendimentos tm procurado uma soluo de dados escalvel que possa espelhar a estrutura da prpria Web. A segunda motivao o fato de que os dados mudam com o passar do tempo. Com a evoluo do modelo de negcios, os modelos de dados normalmente contorcem-se para evoluir e manter o ritmo das mudanas. O resultado normalmente uma estrutura de dados repleta de linguagens arcaicas e remendadas com dados adaptados. Qualquer um que j teve que explicar que o valor de uma coluna possui um significado diferente dependendo se o valor for menor ou maior que 10 ou que padaria na verdade significa armazm devido a um erro anterior, sabe que o peso do histrico no modelo de dados pode ser um srio entrave na manuteno do sistema e na incorporao de novas ideias de negcios. A motivao final que a tecnologia de NoSQL est comeando a se tornar um commodity. Amazon e Google no tiveram escolha no passado a no ser desenvolver sua prpria soluo para resolver os problemas de escala. O custo de escrever tal soluo impediu muitas empresas que no tinham estes problemas no corao de seus negcios de explorar esta nova tecnologia. Recentemente uma srie de doaes de cdigo para entidades como a Apache Foundation ou outros grupos de open source que fornecem desenvolvimento e suporte baseado em comunidades trouxe a possibilidade de se utilizar cdigo extremamente sofisticado com um baixo custo de manuteno. Tais cdigo colocam o NoSQL firmemente ao alcance de empresas menores. Ao invs de ser um assunto esotrico, agora os bancos de dados NoSQL podem ser baixados e integrados arquitetura corporativa em questo de semanas. Est sendo realmente utilizado? Uma questo comum que se pergunta sobre o NoSQL se ele realmente est sendo utilizado ou se somente uma moda. A resposta que se voc alguma vez j utilizou servios da Amazon, Yahoo ou Google ento voc teve os dados fornecidos atravs de uma soluo NoSQL. Se voc j utilizou o eBay ou o Twitter, voc indiretamente j utilizou bancos de dados que possuem muito pouco em comum com bancos de dados tradicionais, (por exemplo, o eBay no utiliza transaes e o Twitter utiliza um banco de dados de grafos para saber quem segue quem). Normalmente a questo realmente significa se pessoas como eu esto realmente utilizando NoSQL.
133
A resposta que se voc est enfrentando problemas lidando com certos tipos de dados, ento h um diferencial competitivo em potencial ao se avaliar uma soluo NoSQL. A rea nova o suficiente para que muitos negcios sintam-se desconfortveis executando trabalho crtico em qualquer outro software que no seja um maduro banco de dados relacional, mesmo que estes bancos de dados relacionais causem vrios problemas e tenham suas diversas limitaes. por que voc utilizaria um banco de dados NoSQl? Uma das principais motivaes se voc tiver problemas em seu negcio que so difceis de se resolver utilizando a tecnologia de banco de dados relacional. Se voc possui um excelente modelo relacional com um banco de dados maduro que fornece todas as funcionalidades que voc precisa, ento h pouca necessidade de se alterar seu mecanismo de armazenamento de dados. A seguir esto alguns casos de uso em que subtimo utilizar um banco de dados relacional: Seu banco de dados relacional no escalar seu trfego a um custo aceitvel; Seus dados so fornecidos em pequenas mudanas ao longo do tempo, de modo que o nmero de tabelas necessrias para manter a forma normal cresceu desproporcionalmente em relao aos dados sendo mantidos. Informalmente, se voc no consegue mais imprimir o seu DER num papel A3, voc deve ter alcanado este problema ou voc est armazenando muita coisa num nico banco de dados; Seu modelo de negcios gera muitos dados temporrios que no pertencem ao banco de dados principal. Exemplos comuns incluem carrinhos de compras, critrios de pesquisa salvos, personalizao do site e questionrios de usurio incompletos; Seu banco de dados relacional est denormalizado por motivos de desempenho ou por convenincia ao manipular dados na aplicao; Seus conjuntos de dados consistem em grandes quantidades de texto ou imagens e as definies de coluna so simples LOBs (CLOB ou BLOB); Voc tem que executar consultas em seus dados que no envolvem simples relaes hierrquicas; exemplos comuns so questes de recomendaes ou de business intelligence que envolvem a ausncia de dados; Voc possui transaes de dados que no precisam de muita durabilidade. Por exemplo, o curtir de itens em websites: criar transaes para este tipo de interao so um exagero, pois se a ao falhar o usurio provavelmente ir repetir a ao at que funcione. Websites com muito AJAX tendem a ter muitos desses casos de uso.
maturidade da linguagem de consultas Uma das queridinhas que corre o risco de ser deixada de lado a SQL. O NoSQL escolheu a SQL como o monstro a ser derrotado, mesmo que na realidade a SQL seja somente um padro muitas
vezes deturpado por implementaes customizadas. A SQL possui muitas vantagens que os produtos NoSQL tero que tratar ao longo do tempo. Primeiramente, ela madura, refinada e geralmente atende s expectativas dos usurios. Possui uma sintaxe coerente e rica em funcionalidades, o que significa que pessoas que produzem consultas SQL complexas certamente reclamaro se tiverem que replicar operadores como SUM, ORDER BY e GROUP numa tarefa do tipo map-reduce em JavaScript. Mesmo os fornecedores reconhecem este problema. Se eles no forem capazes de encontrar um conjunto comum de operaes de manipulao de dados, ento provvel que uma outra implementao torne-se popular e seus usurios migraro para este outro produto. Ou todos os fornecedores tero que implementar o mesmo conjunto de comandos do lder de mercado para manterem-se competitivos. J h alguns padres disponveis como a SparQL, um padro para fazer consultas em RDF ou dados em tuplas. Este poderia ser adaptado para bancos de dados de documentos e grafos, mas mesmo assim ainda no h nada que fornea um conjunto modular de comandos de consulta que possa ser comparado SQL. uma ironia que os produtos NoSQL mais complexos que os bancos de dados de chave-valor tero que implementar algo muito similiar SQL se quiserem ter o mesmo nvel de utilizao que os produtos de dados relacionais tm hoje. Em alguns casos este fato se esconde por trs do slogan Not Only SQL, concordando que simplesmente jogar fora a SQL seria doloroso demais. Novas tecnologias, novos desafios Na tentativa de se incorporar o NoSQL em sistemas de larga escala existentes, v-se que obviamente mais fcil se a sua aplicao possui um baixo acoplamento entre os componentes. Nesta situao mais fcil identificar reas que se beneficiariam da soluo NoSQL e implementar esta integrao aos poucos. Na situao em que o armazenamento de dados monoltico e que os sistemas dependem de certas propriedades do modelo relacional por exemplo, tipos de dados ou consistncia transacional ento o problema muito mais difcil. Em alguns casos o desacoplamento dos dados a primeira tarefa a ser executada ao invs da migrao do armazenamento dos dados. Do ponto de vista da soluo, h a necessidade de se analisar claramente quais dados so relacionais e quais dados esto armazenados em bancos de dados relacionais por falta de outra alternativa. Tambm importante revisar decises histricas e verificar se estas foram feitas com restries histricas em mente. Um exemplo particular o uso de bancos de dados de grafos ao invs de uma estrutura complexa de tabelas relacionais. perfeitamente possvel criar conjuntos de relacionamentos N-N em dados relacionais e ento consultar as interseces destes relacionamentos, mas expressar somente os relacionamentos num banco de dados de grafos uma soluo muito mais simples. Existem algumas reas bvias em que o NoSQL pode ser aplicado imediatamente. Contedo de websistes pode ser geralmente expresso em bancos de dados de documentos ou de chave-valor.
135
Exemplos particulares destas situaes so as metforas de formulrios e de wizards de formulrios. Qualquer formulrio pode ser expresso diretamente na forma de um documento. Dados de buscas so outro exemplo, pois muitos dados de referncia consistem em mapas, listas e conjuntos, referncias, pases, estados, cidades etc. Analisando estes padres nos dados, devem surgir novas oportunidades de uso do NoSQL. Analisando de um modo mais estratgico, sistemas que precisam evoluir e mudar seus dados com frequncia possuem uma boa chance de utilizar um banco de dados sem schema. Se a migrao de estruturas de dados sem indisponibilidade for um diferencial competitivo, ento este um forte indicador de que o uso de uma soluo NoSQL seria valioso. tipos de bancos de dados NoSQl As prximas sees descrevem os diferentes tipos de bancos de dados NoSQL. Bancos de dados chave-valor Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort e Oracle BDB. Aplicaes Tpicas: Cach de contedo. Pontos Fortes: Acesso rpido. Pontos Fracos: Os dados armazenados no tm schema. Aplicao de exemplo: Voc est escrevendo um software de frum em que a pgina do perfil fornece as estatsticas do usurio (mensagens postadas etc.) e as ltimas dez mensagens escritas por ele. A pgina l estes dados baseada numa chave que o id do usurio e recupera uma String JSON que representa todas estas informaes. Um processo em background recalcula esta informao a cada 15 minutos e grava no banco de dados de modo independente. Banco de dados de documentos Exemplos: CouchDB e MongoDB. Aplicaes Tpicas: Aplicaes Web. Pontos Fortes: Tolerncia com dados incompletos. Pontos Fracos: Desempenho em consultas, no h uma sintaxe de consulta padro. Aplicao de exemplo: Voc est criando um software que cria perfis de crianas refugiadas com o propsito de reuni-las novamente com suas famlias. Os detalhes que voc precisa gravar de cada criana podem variar muito de acordo com as circunstncias do evento e elas so construdas aos poucos. Por exemplo, uma criana pequena pode saber o seu primeiro nome e voc pode tirar uma foto dela, mas pode no saber os nomes de seus pais. Mais tarde um conhecido pode reconhecer a criana e fornecer informaes adicionais que voc pode querer gravar, mas at conseguir confirmar, voc ter que tratar estas informaes com ceticismo.
Banco de dados de grafos Exemplos: Neo4J, InfoGrid e Infinite Graph. Aplicaes Tpicas: Redes sociais. Pontos Fortes: Algoritmos de grafos, por exemplo: caminho mais curto, conectividade, graus de relacionamento etc. Pontos Fracos: Tem que percorrer todo o grafo de modo a encontrar uma resposta. No simples de clusterizar. Aplicao de exemplo: Qualquer aplicao que requeira conectividade social uma candidata a um banco de dados de grafos. Este mesmo princpio pode ser estendido a qualquer aplicao em que voc precisa saber o que as pessoas esto fazendo, comprando ou curtindo de modo a recomendar aes futuras. Em qualquer momento voc pode responder a questes como Quais restaurantes receberam votos negativos das irms de pessoas com mais de 40 que gostam de esquiar e que visitaram o Qunia?. Bancos de dados de Xml Exemplos: Exist, Oracle, MarkLogic. Aplicaes Tpicas: Publicao. Pontos Fortes: Tecnologias de busca maduras e validao de schema XML. Pontos Fracos: No uma soluo binria pura, mais fcil reescrever um documento do que atualiz-lo. Aplicao de exemplo: Uma editora que utiliza formatos XML para produzir verses web, impressa e eBook de seus artigos. Os editores precisam fazer buscas rpidas tanto no texto quanto em sees semnticas do XML. Eles armazenam o XML dos artigos finalizados no banco de dados XML e os encapsulam em web services para os sistemas de produo de documentos. Quando mudanas so necessrias, atualizaes utilizando XQuery modificam todos os documentos XML para o novo formato. Bancos de dados ponto-a-ponto distribudos Exemplos: Cassandra, HBase e Riak. Aplicaes Tpicas: Sistemas de arquivo distribudos. Pontos Fortes: Buscas rpidas e boa distribuio do armazenamento dos dados. Pontos Fracos: API de baixo nvel. Aplicao de exemplo: Voc possui um site de notcias em que qualquer tipo de contedo (artigos, comentrios, perfis de autores etc.) pode ser votado e pode ter um comentrio opcional no voto. Voc pode criar uma base por usurio e uma base por tipo de contedo utilizando um UUID como chave
137
(gerado a partir de cada tipo de contedo e usurio). O bucket do usurio mantm cada voto dele, enquanto que o bucket do contedo contm uma cpia de cada voto que j foi feito para aquele contedo. Durante a noite, um processo batch identifica em quais contedos os usurios votaram e voc gera uma lista de contedo que possui muitos votos para cada usurio, mas que os usurios ainda no votaram. Esta lista uma lista de artigos recomendados para o usurio e fica armazenada no bucket de recomendaes. Banco de dados de objetos Exemplos: Oracle Coherence, db4o, ObjectStore, GemStone e Polar. Aplicaes Tpicas: Sistemas financeiros. Pontos Fortes: Reflete o paradigma de desenvolvimento orientado a objetos, baixa latncia ACID e tecnologia madura. Pontos Fracos: Consultas limitadas ou operaes de mltiplas atualizaes. Aplicao de exemplo: Uma empresa de comrcio internacional quer fazer transaes a partir do Japo e Nova York e verific-las atravs de um processo de anlise de risco em Londres. Um objeto representando a transao gravado no banco de dados de objetos e o analisador de riscos est aguardando pelas notificaes de objetos de transaes. Quando um objeto replicado no datacenter europeu, o analisador de riscos l a transao e verifica o risco da mesma. Ele ento reescreve o objeto para informar que a transao foi autorizada e gera uma venda. O cliente est aguardando por mudanas nos objetos e recebe uma notificao de que a sua transao foi aprovada. Concluso Dados tabulares permanecem tabulares e a planilha de clculo ainda a ferramenta de modelagem de dados favorita no mundo dos negcios. SQL no vai morrer to cedo. Entretanto, at agora ns temos criado sistemas baseados nas restries de um tpico banco de dados relacional. O NoSQL oferece a chance de se pensar de um modo diferente sobre os dados e uma possibilidade extremamente excitante. Robert Rees. Fonte: <http://www.thoughtworks.com/articles/nosql-comparison>. Acesso em: 13 ago. 2012.
CONSiDErAES FiNAiS
Finalmente chegamos ao fim de nossa ltima unidade deste material. Neste ponto, voc
provavelmente j ter assimilado contedo suficiente para poder j desenvolver algumas aplicaes utilizando sistemas de bancos de dados. Como descrevemos no incio da unidade, bastante provvel que voc se depare em sua vida profissional com consultas um tanto quanto complexas. Lembre-se que todo problema pode ser decomposto em partes menores de fcil soluo. Utilize esta tcnica e aplique os conceitos assimilados com os exemplos apresentados nesta unidade para resolv-los. Teoria importantssima, mas a prtica uma atividade fundamental para que voc possa converter toda esta teoria aprendida em resultados tanto pessoais quanto profissionais. A prtica das atividades de autoestudo pode auxili-lo(a) na trabalhosa tarefa de assimilao dos conceitos apresentados nesta unidade. Analise-as com carinho e tenha um bom proveito.
Todas as atividades de autoestudo desta unidade baseiam-se na Figura abaixo. beneficiario id nome sobrenome altura plano_fk
dependente id nome sobrenome beneficiario_fk
plano id nome valor
1. Considere o exemplo de schema da figura apresentada. Crie os comandos SQL para definio e criao das tabelas. 2. Elabore consultas SQL para: a. Selecione todos os beneficirios que possuem dependentes com o mesmo nome utilizando uma condio de JOIN.
139
b. Execute a mesma consulta anterior utilizando uma subquery. c. Execute a mesma consulta anterior utilizando uma clusula EXISTS. d. Selecione o beneficirio que contm dependente que possui a maior altura entre todos. 3. Utilizando a clusula de GROUP BY, elabore consultas para: a. Agrupe os beneficirios por nome e selecione o sobrenome e altura de cada um deles. b. Selecione todos os beneficirios que contm mais de um dependente com o mesmo sobrenome. c. Selecione todos os planos que contm mais de um beneficirio com altura > 1.75.
CONCluSO
Se h uma palavra que possa descrever meu sentimento ao concluir este livro, esta talvez seja alvio. Sim, entre outras emoes que certamente passam pela minha cabea neste momento, o alvio de poder concluir este material se destaca. J dizia um antigo ditado sobre a arte da escrita, e que era direcionado queles que pretendiam produzir qualquer texto: o que escrito sem esforo lido sem prazer. No posso me assegurar que voc, carssimo(a) leitor(a), conseguir ler este material com o prazer que eu gostaria que lhe proporcionasse mas no duvide, certamente as palavras organizadas neste material foram fruto de um enorme esforo. E no somente de esforo: tambm de dor, privao de certas liberdades que me foram tomadas pelo tempo dedicado, desespero por querer mais tempo para poder esculpir melhor alguns pargrafos e a angstia de saber que na verdade o trabalho nunca termina ele apenas possui uma data de trmino. Tivesse mais seis meses ou um ano, certamente no o terminaria antes do prazo final. Mas assim o tambm em tudo aquilo que nos dedicamos. Antoine de Saint-Exupry escreveu que tu te tornas eternamente responsvel por aquilo que cativas. Espero que eu possa ter cativado algo com este material e talvez algum, pois esforo no faltou na elaborao do mesmo. Certamente durante a leitura de alguns pontos do material, voc pde perceber a grande inspirao que tenho ao falar de desenvolvimento de software. Sou partidrio da corrente que acredita que o mais importante de todo e qualquer software o problema que ele resolve e o quo satisfatrio ele para seus usurios. Considero a utilidade do software como mecanismo fundamental para qualquer inovao do conhecimento humano atual. E no me agrada observar alguns programadores valorizando uma ferramenta qualquer em detrimento da utilidade do software sendo desenvolvido. Este um dos motivos pelos quais eu considero o banco de dados como apenas um detalhe diante de um projeto maior, que o uso do prprio software. Como j enfatizado nas unidades do material, o banco de dados apenas um detalhe. Um detalhe importante, verdade. Mas apenas um detalhe dentro de um escopo muito maior que a inovao que o software pode proporcionar. Ao trmino deste material voc provavelmente j ter todas as habilidades necessrias para integrar um sistema de banco de dados relacional ao software que voc desenvolve. Saber escolher as opes do mercado baseado(a) nos critrios de classificao que apresentamos
141
e ter com certeza uma pontinha de dvida se deve mesmo utilizar um banco de dados relacional. Afinal, as leituras complementares, os vdeos e os estudos de caso apresentados no material tinham como objetivo provocar o senso crtico para libert-lo(a) da priso relacional. Abra a sua mente e liberte-se de paradigmas preestabelecidos. Saiba decidir qual sistema de banco de dados deve escolher baseado nos requisitos e utilidade da sua aplicao, ao invs de tomar decises baseadas em medo, incerteza e dvida. Se optar por manter-se no ambiente dos sistemas de bancos de dados relacionais, j ter todos os meios para criar, manipular, popular e consultar bancos de dados relacionais graas aos conhecimentos de SQL adquiridos. A lista deste material certamente no exaustiva, mas tambm um bom comeo. Afinal, a jornada do conhecimento nunca acaba. Baseado(a) em tudo o que voc pode aprender, aproveite bem e utilize todo o contedo que tentamos transmitir para desenvolver um bom software; software inovador. isto o que eu sinceramente desejo para sua frutfera jornada. E que est apenas comeando... Bom proveito, boa sorte e acima de tudo, muito sucesso. Um grande abrao. Edson Yanaga.
rEFErNCiAS
DATE, C. J. Bancos de dados: tpicos avanados. Rio de Janeiro: Campus, 1988. KNUTH, Donald. Structured Programming with go to Statements. ACm Journal Computing Surveys, 6 (4): 268. Dezembro de 1974. NAVATHE, Shamkant B.; ELMASRI, Ramez. Sistemas de Banco de Dados. 6. ed. Pearson - Addison Wesley, 2011. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. So Paulo: Makron Books do Brasil, 1999.
143

Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Banco de Dados

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Prof. Me.

grADuAO ANliSE E DESENvOlvimENtO DE SiStEmAS SiStEmAS pArA iNtErNEt

NEAD - Ncleo de Educao a Distncia

Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

CONCluSO........................................................................................................................ 141 rEFErNCiAS .....................................................................................................................143

CONCEitOS DE BANCOS DE DADOS

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

as estruturas e as restries para os dados a serem armazenados em um banco de dados.

Bancos de dados Open Source: presente ou futuro? Cezar Taurion

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

CArACtErStiCAS DE SiStEmAS DE BANCOS DE DADOS

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

A revoluo do Big Data est prestes a acontecer Cezar Taurion

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

O maior evento da comunidade brasileira de NoSQL: <http://nosqlbr.com/>.

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

Papis assumidos pelos usurios de SGBDs

Desenvolvedores de aplicaes e Administradores de Bancos de Dados (DBAs DataBase Administrators)

BANCO DE DADOS | Educao a Distncia

vANtAgENS DE SE utiliZAr um SgBD

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

Banco de Dados na Nuvem Jin Zhang, Diretor de Programas da IBM

BANCO DE DADOS | Educao a Distncia

OS BANCOS DE DADOS E O SOFtWArE

BANCO DE DADOS | Educao a Distncia

SCHEMAS, INSTNCIAS E ABSTRAES

BANCO DE DADOS | Educao a Distncia

iNtErFACES DOS SgBDS

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

Interfaces baseadas em formulrios

ArQuitEturAS DE SiStEmAS DE BANCO DE DADOS

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

Servidor de Banco de Dados

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia