Sistemas de Banco de Dados [7 ed.]
 8543025001, 9788543025001

  • Commentary
  • t.me/AnonLivros
  • 1 2 0
  • Like this paper and download? You can publish your own PDF file online for free in a few minutes! Sign Up
File loading please wait...
Citation preview

SISTEMAS DE BANCO DE DADOS ■ WWÂ / / / í l

7- edição

5> Pearson

/H

W Ak VA\

QUER SEP MAIS LIVRE? Aprenda a Pesquisar e Fazer Ebooks | Armazene arquivos de forma segura

APRENDA A FAZER EBOOKS

HTTPS://ODYSEE.COM

Seja a partir de Livro ou PDF escaneado Construa PDF pesquisável ou Epub Qualidade Profissional

Plataforma descentralizada para Reprodução e Hospedagem de arquivos Garantida por BlockChain

Rápido e Eficiente

Prática como Youtube Descentralizada e resiliente como torrent Facilitadora de transações financeiras como Bitcoin

t.me/AnonLivros

Acervo em Português Mais de 70 mil ebooks no Telegram t.me/PolemicBooks Mais de 2 mil cursos em vídeo t.me/oAcervoCursos

HTTPS://LIBGEN.IS HTTPSy/Z-LIB.ORG Portais de Ebooks e artigos científicos Mais de 2 milhões de documentos

Cursos via streaming no Telegram t.me/LivreSaber

CONTRA A PROPRIEDADE INTELECTUAL A fundamentação Teórica em favor do Conhecimento Livre https://www.mises.org.br/Ebook.aspx?id=29

t.me/AnonLivros

SISTEMAS DE BANCO DE DADOS 7Q ediçõo

SISTEMAS DE BANCO DE DADOS 7Q ediçõo

Ramez Elmasri Departamento de Ciência da Computação e Engenharia

Universidade do Texas em Arlington

Shamkant B. Navathe Faculdade de Computação Georgia Institute of Technology

Tradução

Daniel Vieira Revisão técnica

Enzo Seraphim Thatyana F. Piola Seraphim Professores Doutores Associados do Instituto de

Engenharia de Sistemas e Tecnologias da Informação Universidade Federal de Itajubá

Pearson

© 2016. 20] 1.2007 tn Ramez Elmasri and Shamkant B. Navalhe

©2019 by Pcjimmi Education do Brasil lida. Iodos os direitos rescoados Neuliuiiu parte desta publicação poderá ser reproduzida

ou transmitida de qualquer maxluuu por qualquer outro meio, eletrônico ou mecânico, incluindo fbtocõpra. grasação ou qualquer outro tipo de sistema de armazenamento e transmissão dc

informação. sem prétii inioriz.tçáo por escrito da Pearson Education do Brasil.

VlCE-RESlDENTE DL EDUCAÇÃO GlRLXIE DL PRODClOs

SUPOMSOftA DE PRODCÇÀO LDIIOUAL

COORDLXADOK DE PRODUÇÃO LDtlOUAL EDITORA DETEXIO

ElMtOK.SS ASSISTEX I ES ESIACIÁRK)

PlEPARAÇÃO Revisão

Capa D1ACRAMAÇÃO L PROJEIO CRÁFICO

Juliano Costa Alexandre Mattioli Silvana Afonso Jean Xavier Sabrina Levensteinas Karina Ono e Mariana Rodrigues Rodrigo Orsi Renata Siqueira Campos Maria AiLo Natália Gaio «sobre o projeto original de Micha PasvIrtzki/lènaCorbis? Casa de Idéias

Dados Internacionais de Catalogação na Publicação (CIP) (Câmara BrasHe-ra do Livro. SP. Brasil)

Elmasri. Ran-ez

Sistemas de oanco de dados / Ramez Elmasri, Snamleant B Navatne; tradução Daniel Vieira; revisão têcn ca F-vo Seraphim, TFatyana de Faria Pioa Seraphim. - 7. ed — São Paulo : Pearson

Education do Brasi. 2018.

Título ongral: Fundamentals of database sys’ems

ISBN 978-85-430-2500-1

1 Banco de dados l Navathe, Snamkant B II Seracbirr. Enzo. HI.

* Seraph ”, Thatyana de Faria P>o4a. IV. Título.

CDD-005.75

18-16099

índice para catálogo sistemático:

1. Barco de dados: Sistemas: Processamento de dados 005.75 2. Barco de cados . Fundamentes : Processamento de cacos CO5.75 IoIanda Rodrigues Bode - BiDÜotecâria - CRB-8/10014

2018 Direitos exclusixos cedidos à Pearson Education do Brasil Lida., nina empresa do gnipo Pearson Education

Avenida Santa Marina. 1195 CEP 05056-001 - São Paulo - SP - Brasil Eone: 11 2178-8609 e 11 2178-8655 pea rsonuniversidadesia pearson.com

Para Amalia e para Ramy, Riyad, Katrina e Thomas R.E.

Para minha esposa Aruna por seu amor, apoio e compreensão, e para Rohan, Maya e Ayush, por trazer tanta alegria às nossas vidas S.B.N.

Este livro é uma introdução aos conceitos fundamentais necessários para projetar, usar e implementar sistemas de banco de dados e aplicações de banco de dados. Nossa apresentação enfatiza os fundamentos da modelagem e projeto de banco de dados, as linguagens e modelos fornecidos pelos sistemas de gerenciamento de banco de dados e as técnicas de implementação do sistema de banco de dados. O propósito do livro é que ele seja usado como um livro-texto para um curso de um ou dois semestres sobre sistemas de banco de dados nos níveis técnico, graduação ou pós-graduação, e como um livro de referência. Nosso objetivo é oferecer uma apresentação profunda e atualizada dos aspectos mais importantes dos sistemas c aplicações de banco de dados, bem como das tecnologias relacionadas. Consideramos que os leitores estejam acostumados aos conceitos elementares de programação e estruturação de dados, e que tenham tido algum contato com os fundamentos de organização de computadores.

Novidades nesta edição Os recursos-chave a seguir foram acrescentados na sétima edição:

■ Uma reorganização da ordem dos capítulos (baseada em um estudo feito pelos professores que utilizam o livro); porém, o livro ainda está organizado de modo que o professor individual possa decidir entre seguir a nova ordenação ou escolher uma ordenação diferente (por exemplo, seguir a ordem dos capítulos da sexta edição) ao apresentar o material. ■ Há dois capítulos novos sobre os avanços recentes em sistemas de banco de dados e processamento big data; um capítulo novo (Capítulo 24) aborda uma introdu­ ção à classe mais nova de sistemas de banco de dados, conhecidos como bancos

VIII Sistemas de banco de dados

de dados NOSQL, e o outro capítulo novo (Capítulo 25) aborda as tecnologias para processamento de big data, incluindo MapReduce e Hadoop. ■ O capítulo sobre processamento e otimização de consulta foi expandido e reor­ ganizado em dois capítulos; o Capítulo 18 é focado nas estratégias e algoritmos para processamento de consulta, enquanto o Capítulo 19 aborda as técnicas de otimização de consulta. ■ Um segundo exemplo do banco de dados UNIVERSIDADE foi acrescentado aos primeiros capítulos (capítulos 3 a 8), além do nosso exemplo de banco de dados EMPRESA, das edições anteriores. ■ Muitos dos capítulos individuais foram atualizados de várias formas, para incluir técnicas e métodos mais recentes; em vez de discutir essas melhorias aqui, vamos descrevê-las mais adiante neste prefácio, quando discutirmos sobre a organização da sétima edição.

A seguir, estão os principais recursos do livro: ■ Uma organização autocontida e flexível, que pode ser ajustada às necessidades individuais; em particular, os capítulos podem ser usados em diferentes ordens, dependendo da preferência do professor. ■ Um diagrama de dependência (mostrado mais adiante neste prefácio) para indicar quais capítulos dependem de capítulos anteriores; isso poderá orientar o professor que queira ajustar a ordem de apresentação dos capítulos. ■ A Sala Virtual inclui uma coleção de suplementos, incluindo um rico conjunto de materiais para professores e alunos, como slides do PowerPoint, figuras do texto e um guia do professor com soluções.

Organização e conteúdo da sétima edição Há algumas mudanças organizacionais na sétima edição, bem como melhorias nos capítulos individuais. O livro agora é dividido em doze partes, da seguinte forma:

■ /\ Parte 1 (capítulos 1 e 2) descreve os conceitos introdutórios básicos, necessá­ rios para uma boa compreensão dos modelos, sistemas e linguagens de banco de dados. Os capítulos 1 e 2 apresentam bancos de dados, usuários típicos e conceitos de SGBD, terminologia e arquitetura, bem como uma discussão do progresso das tecnologias de banco de dados com o passar do tempo e uma breve história dos modelos de dados. Esses capítulos têm sido usados para introduzir algumas das novas tecnologias, como sistemas NOSQL. ■

Parte 2 (capítulos 3 e 4) inclui a apresentação sobre modelagem de entidade-relacionamento e projeto de banco de dados; contudo, é importante observar que os professores podem utilizar os capítulos sobre o modelo relacionai (capítulos 5 a 8) antes dos capítulos 3 e 4 se esta for sua ordem de apresentação preferida para o material do curso. No Capítulo 3, apresentamos os conceitos do modelo Entidade-Rclacionamento (ER) e dos diagramas ER, usando-os para ilustrar o projeto conceituai do banco de dados. O Capítulo 4 mostra como o modelo ER básico pode ser estendido a fim de incorporar outros conceitos de modelagem, como subclasses, especialização, generalização, tipos (categorias) de união e herança, levando ao modelo de dados Enhanced-ER (EER) e aos diagramas EER. A notação para os diagramas de classe da UML também é apresentada nos Capítulos 7 e 8 como um modelo alternativo e notação diagramática para os diagramas ER/EER.

■ A Parte 3 (capítulos 5 a 9) inclui uma apresentação detalhada sobre os bancos de dados relacionais e SQL, com material novo nos capítulos sobre SQL, abordando algumas construções SQL que não estavam na edição anterior. O Capítulo 5 descreve

Prefácio

o modelo relacionai básico, suas restrições de integridade e operações de atualização. O Capítulo 6 descreve algumas das partes básicas do padrão SQL para bancos de dados relacionais, incluindo definição de dados, operações de modificação de dados e consultas SQL simples. O Capítulo 7 apresenta consultas SQL mais complexas, bem como os conceitos SQL de gatilhos, asserções, visões e modificação de esquema. O Capítulo 8 descreve as operações formais da álgebra relacionai e introduz o cálculo relacionai. O material sobre SQL (capítulos 6 e 7) é apresentado antes da nossa apresentação sobre álgebra relacionai e cálculo, no Capítulo 8, para permitir que os professores iniciem projetos SQL mais no começo do curso, se desejarem (é possível abordar o Capítulo 8 antes dos capítulos 6 e 7 se o professor preferir essa ordem). O capítulo final da Parte 3, Capítulo 9, aborda o mapeamento ER e EER-relacional, algoritmos que podem ser usados para projetar um esquema de banco de dados relacionai a partir de um esquema conceituai ER/EER. ■ A Parte 4 (capítulos 10 e 11) são os capítulos referentes às técnicas de progra­ mação de banco de dados; esses capítulos podem ser designados como materiais de leitura e aumentados com materiais na linguagem de programação específica usada no curso para projetos de programação (grande parte dessa documentação pode ser facilmente encontrada na web). O Capítulo 10 aborda tópicos tradicio­ nais de programação SQL, como SQL embutida, SQL dinâmica, ODBC, SQLJ, JDBC e SQL/CLI. O Capítulo 11 apresenta a programação de banco de dados na web, usando a linguagem de script PHP em nossos exemplos, e inclui material novo que discute tecnologias Java para a programação de banco de dados da web. ■ A Parte 5 (capítulos 12 e 13) aborda o material atualizado sobre bancos de dados objeto-relacional e orientados a objeto (Capítulo 12) e XML (Capítulo 13); ambos os capítulos agora incluem uma apresentação explicando como o padrão SQL incorpora conceitos de objeto e de XML nas versões mais recentes do padrão SQL. O Capítulo 12 primeiro introduz os conceitos para bancos de dados de objeto e depois mostra como eles foram incorporados no padrão SQL para adicionar recursos de objeto a sistemas de banco de dados relacionais. Em seguida, ele aborda o padrão de modelo de objeto ODMG e sua definição de objeto e linguagens de consulta. O Capítulo 13 aborda o modelo e as linguagens XML (extensible Markup Language) e discute como a XML está relacionada aos sistemas de banco de dados. Ele apresenta conceitos c linguagens XML e compara o modelo XML com os modelos tradicionais de banco de dados. Mostramos também como os dados podem ser convertidos entre a XML e representações relacionais, e os comandos SQL para extrair documentos XML de tabelas relacionais. ■ A Parte 6 (capítulos 14 e 15) são os capítulos de normalização e teoria do projeto relacionai (passamos todos os aspectos formais dos algoritmos de normalização para o Capítulo 15). O Capítulo 14 define as dependências funcionais e as formas normais baseadas em dependências funcionais. O Capítulo 14 também desenvolve uma abordagem de normalização intuitiva passo a passo e inclui as definições de dependências multivaloradas e dependências de junção. O Capítulo 15 aborda a teoria da normalização e os formalismos, teorias e algoritmos desenvolvidos para o projeto de banco de dados relacionai por meio da normalização, incluindo os algoritmos de decomposição relacionais e os algoritmos de síntese relacionai. ■ A Parte 7 (capítulos 16 e 17) contém os capítulos sobre organizações de arquivo em disco (Capítulo 16) e indexação de arquivos de banco de dados (Capítulo 17). O Capítulo 16 descreve os principais métodos de organização de arquivos de registros em disco, incluindo arquivos ordenados (classificados), desordenados (heap) e de hash; nele, são abordadas as técnicas de hashing estático e dinâmico. O Capítulo 16 foi atualizado para incluir material sobre estratégias de gerencia­ mento de buffer para SGBDs, além de uma visão geral dos novos dispositivos de

IX

X

Sistemas de banco de dados

armazenamento e padrões para arquivos e arquiteturas de armazenamento moder­ nas. O Capítulo 17 descreve as técnicas de indexação para arquivos, incluindo estruturas de dados em B-trees e B’-trees e arquivos de grade, e foi atualizado com novos exemplos e uma discussão avançada sobre indexação, incluindo como escolher índices apropriados e a criação de índices durante o projeto físico. ■ A Parte 8 (capítulos 18 e 19) inclui os capítulos sobre algoritmos de processa­ mento de consulta (Capítulo 18) e técnicas de otimização (Capítulo 19); esses dois capítulos foram atualizados e reorganizados a partir de um único capítulo, nas edições anteriores, que incluía os dois tópicos; eles também incluem algumas técnicas mais recentes utilizadas em SGBDs comerciais. O Capítulo 18 apresenta algoritmos para a pesquisa de registros em arquivos de disco e para a junção de registros a partir de dois arquivos (tabelas), além de outras operações relacionais. O Capítulo 18 também possui material novo, incluindo uma discussão sobre operações de semijunção (semi-join) e antijunção (anti-join), com exemplos de como elas são usadas no processamento de consultas, bem como uma discussão das técnicas para estimativa de seletividade. O Capítulo 19 aborda as técnicas para otimização de consulta usando a estimativa de custo e regras heurísticas; ele inclui material novo sobre otimização de subconsulta aninhada, uso de histogramas, otimização física e métodos de ordenação de junção e otimização de consultas típicas em data warehouses. ■ A Parte 9 (capítulos 20,21 e 22) aborda os conceitos de processamento de tran­ sação; controle de concorrência; e recuperação do banco de dados contra falhas. Esses capítulos foram atualizados para incluir algumas das técnicas mais recentes utilizadas em alguns SGBDs comerciais e open source. O Capítulo 20 apresenta as técnicas necessárias para os sistemas de processamento de transação e define os conceitos de facilidade de recuperação e serialização de escalonamentos; ele contém uma nova seção sobre políticas de substituição de buffer para SGBDs e uma nova discussão sobre o conceito de isolamento de snapshot. O Capítulo 21 oferece uma visão geral de diversos tipos de protocolos de controle de concor­ rência, com foco no bloqueio em duas fases. Também discutimos as técnicas de ordenação de timestamp e controle de concorrência otimista, além do bloqueio de detalhamento múltiplo. O Capítulo 21 inclui uma nova apresentação dos métodos de controle de concorrência baseados no conceito de isolamento de snapshot. Por fim, o Capítulo 22 focaliza os protocolos de recuperação de banco de dados e oferece uma visão geral dos conceitos e técnicas usados na recuperação. ■ A Parte 10 (capítulos 23,24 e 25) inclui o capítulo sobre bancos de dados distri­ buídos (Capítulo 23) e mais dois capítulos novos sobre sistemas de armazenamento NOSQL para big data (Capítulo 24) e tecnologias big data baseadas em Hadoop e .MapReduce (Capítulo 25). O Capítulo 23 oferece uma introdução aos concei­ tos de bancos de dados distribuídos, incluindo disponibilidade e escalabilidade, replicação e fragmentação de dados, manutenção de consistência de dados entre as réplicas e muitos outros conceitos e técnicas relacionadas. No Capítulo 24, os sistemas NOSQL são divididos em quatro categorias gerais, com um sistema de exemplo utilizado em cada categoria; também discutimos e comparamos modelos de dados, operações e estratégias de replicação/distribuição/escalabilidade de cada tipo de sistema NOSQL. No Capítulo 25, introduzimos o modelo de programação MapReduce para o processamento distribuído de big data,e depois apresentamos o sistema Hadoop e o HDFS (Hadoop Distributed File System), além das interfaces de alto nível Pig e Hive e da arquitetura YARN. ■ A Parte 11 (capítulos de 26 a 29) é intitulada “Modelos, sistemas e aplicações de bancos de dados avançados”, e inclui o seguinte material: o Capítulo 26 introduz vários modelos de dados avançados, incluindo bancos de dados ativos

Prefácio XI e triggers (Seção 26.1), bancos de dados temporais (Seção 26.2), bancos de dados espaciais (Seção 26.3), bancos de dados multimídia (Seção 26.4) e bancos de dados dedutivos (Seção 26.5). O Capítulo 27 discute técnicas de recuperação de informações (RI) e pesquisa na web, incluindo tópicos como RI e pesquisa baseada em palavra-chave, comparação de BD com RI, modelos de recuperação, avaliação de busca e algoritmos de ranqueamento (ranking). O Capítulo 28 é uma introdução à mineração de dados (data mining), que inclui uma visão geral dc diversos métodos de mineração de dados, como mineração por regra dc asso­ ciação, agrupamento, classificação e descoberta de padrão sequencial. O Capítulo 29 é uma visão geral do data warehousing, incluindo tópicos como modelos e operações de data warehousing e o processo de criação de um data warehouse.

■ A Parte 12 (Capítulo 30) inclui apenas um capítulo sobre segurança de banco de dados, que traz uma discussão sobre comandos SQL para o controle de acesso discricionário (GRANT, REVOKE), além dos níveis de segurança obrigatórios e modelos para a inclusão do controle de acesso obrigatório nos bancos de dados relacionais, com uma discussão sobre ameaças, como os ataques de injeção de SQL e outras técnicas e métodos relacionados à segurança e à privacidade dos dados.

O Apêndice A oferece uma série de notações diagramáticas alternativas para exibir um esquema ER ou EER conceituai. Estas podem ser usadas em substituição à notação que usamos, se o professor preferia O Apêndice B oferece alguns parâmetros físicos importantes dos discos. O Apêndice C contém uma visão geral da linguagem de consulta gráfica QBE.

Orientações para o uso deste livro Existem muitas maneiras diferentes de ministrar um curso de banco de dados. Os capítulos das partes 1 a 7 podem ser usados em um curso introdutório sobre sistemas de banco dc dados, na ordem cm que aparecem ou na ordem preferida dc cada professor. Capítulos c seções selecionadas podem ser omitidos, e o professor pode acrescentar outros capítulos do restante do livro, dependendo da ênfase do curso. Ao final da seção inicial de muitos dos capítulos do livro, listamos seções que podem ser omitidas sempre que se desejar uma discussão menos detalhada do assunto. Sugerimos incluir até o Capítulo 15 em um curso introdutório de banco de dados e incluir panes selecionadas de outros capítulos, dependendo da base dos alunos e da cobertura desejada. Para uma ênfase cm técnicas dc implementação de sistemas, os capítulos das partes 7,8 c 9 devem ser usados cm substituição a alguns dos capítulos anteriores. Os capítulos 3 e 4, que abordam a modelagem conceituai usando os modelos ER e EER, são importantes para um bom conhecimento conceituai dos bancos dc dados. Porém, eles podem ser parcialmentc abordados, abordados mais adiante cm um curso ou até mesmo omitidos, se a ênfase for sobre a implementação do SGBD. Os capítulos 16 e 17, sobre organização de arquivos e indexação, também podem ser abordados mais cedo, mais tarde ou ainda omitidos, se a ênfase for sobre modelos de banco de dados e linguagens. Para alunos que concluíram um curso sobre orga­ nização dc arquivos, partes desses capítulos podem ser indicadas como material de leitura ou alguns exercícios podem ser passados como revisão para esses conceitos. Se a ênfase de um curso for no projeto de banco de dados, o professor deverá abordar os capítulos 3 e 4 mais cedo, seguidos pela apresentação dos bancos de dados relacionais. Um curso sobre o ciclo de vida completo do projeto e implemen­ tação dc bancos dc dados incluiría o projeto conceituai (capítulos 3 e 4), bancos dc dados relacionais (capítulos 5, 6 e 7), mapeamento do modelo dc dados (Capítulo

XII Sistemas de banco de dados 9), normalização (Capítulo 14) e implementação de programas de aplicação com SQL (Capítulo 10). O Capítulo 11 também deverá ser incluído se a ênfase for na programação e nas aplicações de banco de dados na web. A documentação adicional sobre linguagens de programação e SGBDRs específicos seria necessária. O livro foi escrito de modo que fosse possível abordar tópicos em várias sequências. O gráfico de dependência dos capítulos, a seguir, mostra as principais dependências entre os capítulos. Conforme o diagrama ilustra, é possível começar com vários tópicos diferentes após os dois capítulos introdutórios. Embora o gráfico possa parecer complexo, é importante observar que, se os capítulos forem usados na ordem, as dependências não serão perdidas. O gráfico pode ser consultado por aqueles que desejam usar uma ordem de apresentação alternativa. Para um curso de um semestre baseado neste livro, capítulos selecionados podem ser atribuídos como material de leitura. O livro também pode ser usado para uma sequência de cursos em dois semestres. O primeiro curso. Introdução ao Projeto e Sistemas de Bancos de Dados., em nível de aluno de segundo ano, técnico ou gradua­ ção, pode abranger a maioria dos capítulos de 1 a 15. O segundo curso. Modelos e Técnicas de Implementação de Bancos de Dados, no nível de aluno de graduação ou pós-graduação, pode abranger a maioria dos capítulos de 16 a 30. A sequência de dois semestres também pode ser elaborada de várias outras maneiras, dependendo da preferência de cada professou

1,2 Introdução 3,4 Modelos ER, EER

5 Mndelo

6,7 SQL

Álgebra relacionai '

9 EReERR para relacionai

Z 16,17 í Organização de Karquivo, indexação

I 20,21,22 Transações, CC. recuperação

14,15 FD, DMV, normalização

23,24, 25 BDD, NOSQL Big Data 18,19 Processamento de consulta, otimização

10,11 Programação de BD e web 28,29 x Mineração de dados. Warehousing

30 Segurança de BD

* Agradecimentos É um grande prazer reconhecer o auxílio e as contribuições dc muitos indivíduos para este projeto. Primeiro, gostaríamos de agradecer ao nosso editor Matt Goldstein, por sua orientação, encorajamento e apoio. Gostaríamos dc agradecer o excelente trabalho de Rose Kernan pela gerência de produção, Patricia Daly por uma revisão completa do livro, Martha McMaster por sua diligência na revisão das páginas, e Scott Disanno, cditor-chcfc da equipe de produção. Também queremos agradecer a Kelsey loanes, da Pearson, por sua ajuda constante no projeto,e aos revisores Michael Doherty, Deborah Dunn, Imad Rahal, Karen Davis, Gilliean Lee, Leo Mark, Monisha Pulimood, Hassan Reza, Susan Vrbsky, Li Da Xu, Weining Zhang e Vincent Oria. Ramez Elmasri gostaria de agradecer a Kulsawasd Jitkajornwanich, Vivek Sharma e Surya Swaminathan por sua ajuda na preparação de parte do material do Capítulo 24. Sham Navathe gostaria de agradecer aos seguintes profissionais, que ajudaram na análise crítica e na revisão de diversos tópicos: Dan Forsythe e Satish Damle, pela discussão sobre sistemas de armazenamento; Rafi Ahmed, pela reorganização detalhada do material sobre processamento c otimização dc consulta; Harish Butani, Balaji Palanisamy e Prajakta Kalmegh, por sua ajuda com o material sobre Hadoop e tecnologia MapReduce; Vic Ghorpadcy c Nenad Jukic, pela revisão do material sobre data warehousing; e, por fim, Frank Rietta, pelas técnicas mais recentes em segurança de banco de dados, Kunal Malhotra, por diversas discussões, e Saurav Sahay, pelos avanços nos sistemas dc recuperação de informação. Gostaríamos de repetir nossos agradecimentos àqueles que revisaram e contribuí­ ram de alguma maneira para as edições anteriores de Sistemas de Banco de Dados.

■ Primeira edição. Alan Apt (editor), Don Batory, Scott Downing, Dennis Heimbinger, Julia Hodges, Yannis loannidis, Jim Larson, Per-Ake Larson, Dennis McLeod, Rahul Patel, Nicholas Roussopoulos, David Stemple, Michael Stonebrakcg Frank Tompa c Kyu-Young Whang. ■ Segunda edição. Dan Joraanstad (editor), Rafi Ahmed, Antonio Albano, David Beech, Jose Blakeley, Panos Chrysanthis, Suzanne Dietrich, Vic Ghorpadey, Goetz Graefe, Eric Hanson, Junguk L. Kim, Roger King, Vram Kouramajian, Vijay * Equipe da 7a edição original, em inglês.

XIV Sistemas de banco de dados Kumar, John Lowther, San jay Manchanda/Foshimi Minoura, Inderpal Mumick, Ed Omiecinski, Girish Pathak, Raghu Ramakrishnan, Ed Robertson, Eugene Sheng, David Stotts, Marianne Winslett e Stan Zdonick. ■ Terceira edição. Maite Suarez-Rivas e Katherine Harutunian (editores); Suzanne Dietrich, Ed Omiecinski, Rafi Ahmed, François Bancilhon, Jose Blakeley, Rick Cartel), Ann Chervenak, David W. Embley, * Henn A. Edinger, Leonidas Fegaras, Dan Forsyth, Farshad Fotouhi, Michael Franklin, Sreejith Gopinath, Goetz Craefe, Richard Hull, Sushil Jajodia, Ramesh K. Kame, Harish Kotbagi, Vijay Kumar,Tarcisio Lima, Ramon A. Mata-Toledo, Jack McCaw, Dennis McLeod, Rokia Missaoui, Magdi Morsi, M. Narayanaswarny, Carlos Ordonez,Joan Peckham, Bern Salzberg, Ming-Chien Shan, J unping Sun, Rajshekhar Sunderraman, Aravindan Veerasamy e Emilia E. Villareal. ■ Quarta edição. Maite Suarez-Rivas, Katherine Harutunian, Daniel Rausch e Juliet Silveri (editores); Phil Bernhard, Zhengxin Chen, Jan Chomicki, Hakan Ferhatosmanoglu, Len Fisk, William Hankley, Ali R. Hurson, Vijay Kumar, Peretz Shoval, Jason T. L. Wang (revisores); Ed Omiecinski (que contribuiu para o Capítulo 27). Os colaboradores da Universidade do Texas em Arlington são Jack Fu, Hyoil Han, Babak Hojabri, Charley Li, Ande Swathi e Steven Wu; os colaboradores da Georgia Tech são Weimin Feng, Dan Forsythe, Angshuman Guin, Abrar Ul-Haque, Bin Liu, Ying Liu, Wanxia Xie e Waigen Yee. ■ Quinta edição. Mart Goldstein e Katherine Harutunian (editores); Michelle Brown, Gillian Hall, Patty Xlahtani, Maite Suarez-Rivas, Bethany Tidd e Joyce Cosentino Wells (da Addison-Wesley); Hani Abu-Salem, Jamal R. Alsabbagh, Ramzi Bualuan, Soon Chung, Sumali Conlon, Hasan Davulcu, James Geller, Le Gruenwald, Larifur Khan, Herman Lam, Byung S. Lee, Donald Sanderson, Jamil Saquer, Costas Tsatsoulis e Jack C. Wileden (revisores); Raj Sunderraman (que contribuiu com os projetos de laboratório); Salman Azar (que contribuiu com alguns exercícios novos); Gaurav Bhatia, Fariborz Farahmand, Ying Liu, Ed Omiecinski, Xalini Polavarapu, Liora Sahar, Saurav Sahay e Wanxia Xie (da Georgia Tech). ■ Sexta edição. Matt Goldstein (editor); Gillian Hall (gerente de produção); Rebecca Greenberg (revisora de texto); Jeff Holcomb, Marilyn Lloyd, Margaret Waples e Chelsea Bell (da Pearson); Rafi Ahmed, Venu Dasigi, Neha Deodhar, Fariborz Farahmand, Hariprasad Kumai; Leo Mark, Ed Omiecinski, Balaji Palanisamy, Nalini Polavarapu, Parimala R. Pranesh, Bharath Rengarajan, Liora Sahar, Saurav Sahay, Narsi Srinivasan c Wanxia Xie.

Por ultimo, mas não menos importante, gostaríamos de agradecer pelo apoio, encorajamento e paciência de nossas famílias. R.E. S.B.N.

Sumário Prefácio............

.VII

Sobre os autores

XXV

PARTE 1 Introdução aos bancos de dados Capítulo 1 Bancos de dados e usuários de banco de dados....................................... 3 1.1 Introdução............................................................................................................................ 4 1.2 Um exemplo......................................................................................................................... 7 1.3 Características da abordagem de banco de dados......................................................................... 9 1.4 Atores em cena.................................................................................................................... 14 1.5 Trabalhadores dos bastidores.................................................................................................. 15 1.6 Vantagens de usar a abordagem de SGBD..................................................................................16 1.7 Uma breve história das aplicações de banco de dados.................................................................. 22 1.8 Quando não usar un SGBD ....................................................................................................25 1.9 Resumo.............................................................................................................................. 26 Perguntas de revisão................................................................................................................... 26 Exercícios.................................................................................................................................. 27 Bibliografia selecionada............................................................................................................... 27 Capítulo 2 Conceitos e arquitetura do sistema de banco de dados........................ 29 2.1 Modelos de dados, esquemas e instâncias................................................................................. 30 2.2 Arquitetura de três esquemas e independência de dados............................................................... 33 2.3 Linguagens e interfaces do banco de dados................................................................................ 36 2.4 O ambiente do sistema de banco de dados ................................................................................ 39 2.5 Arquiteturas centralizadas e diente/servidor para SGBDs ............................................................. 43 2.6 Classificação dos sistemas gerenciadores de banco de dados ........................................................ 47 2.7 Resumo.............................................................................................................................. 50 Perguntas de revisão................................................................................................................... 51

XVI

Sistemas de banco de dados

Exerdcios..................................................................................................................................52 Bibliografia selecionada............................................................................................................... 52

PARTE 2 Modelagem conceituai e projeto de banco de dados Capitulo 3 Modelagem de dados usando o modelo Entidade-Relacionamento (ER)................................................................. 55 3.1 Usando modelos de dados conceituais de alto nível para o projeto do banco de dados ....................... 56 32 Exemplo de aplicação de banco de dados..................................................................................58 3.3 Tipos de entidade, conjuntos de entidades, atributos e chaves........................................................ 59 3.4 Tipos e conjuntos de relacionamentos, papéis e restrições estruturais...............................................66 3.5 Tipos de entidade fraca.......................................................................................................... 72 3.6 Refinando o projeto ER para o banco de dados EMPRESA............................................................. 73 3.7 Diagramas ER, convenções de nomes e questões de projeto .......................................................... 74 3.8 Exemplo de outra notação: diagramas de ciasses UML ................................................................. 79 3.9 Tipos de relacionamento de grau maior que dois......................................................................... 81 3.10 Outro exemplo: um banco de dados UNIVERSIDADE.................................................................. 84 3.11 Resumo............................................................................................................................. 87 Perguntas de revisão................................................................................................................... 88 Exercícios..................................................................................................................................88 Exerácios de laboratório..............................................................................................................94 Bibliografia selecionada............................................................................................................... 95 Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)............................ 97 4.1 Subclasses, superclasses e herança........................................................................................... 98 42 Especialização e generalização............................................................................................... 100 4.3 Restrições e caracteristicas das hierarquias de especialização e generalização................................... 102 4.4 Modelagem dos tipos UNIAO usando categorias....................................................................... 108 4.5 Um exemplo de esquema UNIVERSIDADE de EER, opções de projeto e definições formais.................. 110 4.6 Exemplo de outra notação: representando especialização e generalização em diagramas de classes em UML.............................................................................................................. 114 4.7 Conceitos de abstração de dados» representação do conhecimento e ontologia................................. 116 4.8 Resumo............................................................................................................................. 121 Perguntas de revisão................................................................................................................. 122 Exerdcios................................................................................................................................ 123 Exerdcios de laboratório............................................................................................................ 129 Bibliografia selecionada.............................................................................................................. 131

PARTE 3 Modelo de dados relacionai e SQL Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais............................................................................. 135 5.1 Conceitos do modelo relacionai........................................................................................... 136 52 Restrições em modelo reladonal e esquemas de bancos de dados reladonais................................... 142 5.3 Operações de atualização, transações e tratamento de violações de restrição................................... 150 5.4 Resumo............................................................................................................................. 153 Perguntas de revisão................................................................................................................. 154 Exerdcios................................................................................................................................ 155 Bibliografia selecionada.............................................................................................................. 158 Capitulo 6 SQL básica................................................................................................ 159 6.1 Definições e tipos de dados em SQL........................................................................................ 161 6.2 Especificando restrições em SQL............................................................................................. 166 6.3 Consultas de recuperação básicas em SQL................................................................................ 169 6.4 Instruções INSERT, DELETE e UPDATE em SQL ........................................................................... 180 6.5 Recursos adicionais da SQL .................................................................................................. 183 6.6 Resumo............................................................................................................................. 184

Sumário XVII

Perguntas de revisão................................................................................................................. 184 Exercícios................................................................................................................................ 184 Bibliografia selecionada..............................................................................................................187 Capítulo 7 Mais SQL: consultas complexas, triggers, views e modificação de esquema............................................................................... 189 7.1 Consultas de recuperação SQL mais complexas......................................................................... 189 7.2 Especificando restrições como asserções e ações como gatilho (triggers) ........................................206 7.3 Visões (views) —tabelas virtuais em SQL................................................................................ 209 7.4 Instruções de alteração de esquema em SQL............................................................................ 213 7.5 Resumo............................................................................................................................. 215 Perguntas de revisão................................................................................................................. 216 Exercícios................................................................................................................................ 217 Bibliografia selecionada..............................................................................................................218

Capítulo 8 Álgebra e cálculo relacionai................................................................... 219 8.1 Operações relacionais unárias: SELEÇÃO e PROJEÇÃO................................................................. 221 8.2 Operações de álgebra relacionai com base na teoria dos conjuntas ...............................................226 8.3 Operações relacionais binárias: JUNÇÃO e DIVISÃO.................................................................... 229 8.4 Outras operações relacionais................................................................................................ 238 8.5 Exemplos de consultas na álgebra relacionai............................................................................ 243 8.6 O cálculo relacionai de tupla ................................................................................................ 246 8.7 O cálculo relacionai de domínio............................................................................................. 254 8.8 Resumo............................................................................................................................. 256 Perguntas de revisão................................................................................................................. 257 Exercícios................................................................................................................................ 258 Exercidos de laboratório............................................................................................................ 262 Bibliografia selecionada..............................................................................................................263 Capítulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai........................................................................................265 9.1 Projeto de banco de dados relacionai usando o mapeamento ER para relacionai .............................. 266 9.2 Mapeando construções do modelo EER para relações................................................................. 273 9.3 Resumo............................................................................................................................. 278 Pergunta de revisão................................................................................................................... 278 Exercícios................................................................................................................................ 278 Exercícios de laboratório............................................................................................................ 279 Bibliografia selecionada ............................................................................................................ 280

PARTE 4 Técnicas de programação de banco de dados Capítulo 10 Introdução às técnicas de programação SQL.......................................283 10.1 Programação de banco de dados: técnicas e problemas ............................................................ 284 102 SQL embutida, SQL dinâmica e SQU .....................................................................................287 10.3 Programação de banco de dados com chamadas de função e bibliotecas de dasses: SQL/CLI e JDBC .. 299 10.4 Procedimentos armazenados de banco de dados e SQl/PSM ..................................................... 308 10.5 Comparando as três técnicas............................................................................................... 311 10.6 Resumo........................................................................................................................... 311 Perguntas de revisão................................................................................................................. 312 Exercidos................................................................................................................................ 312 Bibliografia seleaonada..............................................................................................................313 Capítulo 11 Programação de banco de dados web usando PHP............................ 315 11.1 Um exemplo simples em PHP............................................................................................... 316 112 Visão geral dos recursos básicos da PHP .............................................................................. 318 11.3 Visão geral da programação de banco de dados em PHP............................................................ 324 11.4 Panorama das tecnologias Java para programação web com banco de dados................................. 328

XVIII Sistemas de banco de dados

11.5 Resumo......................................................................................................................... 329 Perguntas de revisão................................................................................................................. 329 Exerdcios................................................................................................................................ 330 Bibliografia selecionada..............................................................................................................330

PARTE 5 Objeto, objeto-relacional e XML: conceitos, modelos, linguagens e padrões Capítulo 12 Bancos de dados de objeto e objeto-relacional...................................333 12.1 Visão geral dos concertos de banco de dados de objeto...........................................................335 111 Extensões do banco de dados de objeto para SQL.................................................................... 347 12.3 0 modelo de objeto ODMG e a Object Definition Language (ODL) ...............................................353 12.4 Projeto conceituai de banco de dados de objeto ...................................................................... 368 12.5 A linguagem de consulta de objeto (OQL — Object Query Language)........................................... 371 12.6 Visão geral de binding da linguagem C++ no padrão ODMG ..................................................... 378 12.7 Resumo........................................................................................................................... 380 Perguntas de revisão................................................................................................................. 381 Exerdcios................................................................................................................................ 382 Bibliografia selecionada.............................................................................................................. 382 Capítulo 13 XML: extensible Markup Language.......................................................... 385 13.1 Dados estruturados, semiestruturados e não estruturados.......................................................... 386 132 Modelo de dados hierárquico (em árvore) da XML.................................................................... 390 133 Documentos XML, DTD e esquema XML..................................................................................392 13.4 Armazenando e extraindo documentos XML de bancos de dados..................................................399 13.5 Linguagens XML............................................................................................................... 400 13.6 Extraindo documentos XML de bancos de dados relacionais.......................................................404 13.7 XML/SQL funções SQL para a criação de dados XML.................................................................409 13.8 Resumo........................................................................................................................... 411 Perguntas de revisão................................................................................................................. 411 Exerdcios................................................................................................................................ 412 Bibliografia selecionada..............................................................................................................412

PARTE 6 Teoria e normalização de projeto de banco de dados Capítulo 14 Fundamentos de dependências funcionais e normalização para bancos de dados relacionais............................................ 415 14.1 Diretrizes de projeto informais para esquemas de relação.......................................................... 417 14.2 Dependências funcionais ................................................................................................. 426 14.3 Formas normais baseadas em chaves primárias....................................................................... 429 14.4 Definições gerais da segunda e da terceira formas normais........................................................ 438 14.5 Forma Normal de Boyce-Codd ............................................................................................. 440 14.6 Dependência multivalorada e quarta forma normal.................................................................. 443 14.7 Dependências de junção e quinta forma normal ...................................................................... 446 14.8 Resumo........................................................................................................................... 447 Perguntas de revisão................................................................................................................. 448 Exerdcios................................................................................................................................ 449 Exerdcio de laboratório..............................................................................................................453 Bibliografia selecionada..............................................................................................................453

Capitulo 15 Algoritmos de projeto de banco de dados relacionai e demais dependências...................................................................455 15.1 Outros tópicos em dependêndas fundonais: regras de inferência, equivalência e cobertura mínima... 456 152 Propriedades de decomposições reladonais............................................................................ 463 15.3 Algoritmos para projeto de esquema de banco de dados relacionai.............................................. 468 15.4 Sobre NULLs, tuplas suspensas e projetosreladonais alternativos................................................. 472

Sumário XIX

15.5 Discussão adicional sobre dependências multivaloradas e 4FN................................................... 477 15.6 Outras dependências e formas normais..................................................................................479 15.7 Resumo........................................................................................................................... 482 Perguntas de revisão................................................................................................................. 483 Exercícios................................................................................................................................ 483 Exercício de laboratório..............................................................................................................484 Bibliografia selecionada..............................................................................................................485

PARTE 7 Estruturas de arquivo, hashing, indexação e projeto físico de banco de dados Capítulo 16 Armazenamento de disco, fundamentos de estruturas de arquivo, hashing e arquiteturas de armazenamento modernas... 489 16.1 Introdução........................................................................................................................490 162 Dispositivos de armazenamento secundários...........................................................................494 16.3 Buffering de blocos............................................................................................................ 503 16.4 Gravando registros de arquivo no disco..................................................................................506 16.5 Operações em arquivos ..................................................................................................... 510 16.6 Arquivos de registros desordenados (arquivos de heap)............................................................. 513 16.7 Arquivos de registros ordenados (arquivos dassificados)............................................................ 514 16.8 Técnicas de hashing .......................................................................................................... 517 16.9 Outras organizações de arquivo primárias.............................................................................. 526 16.10 Paralelizando o acesso de disco usando tecnologia RAID.......................................................... 527 16.11 Arquiteturas de annazenamento modernas...........................................................................531 16.12 Resumo......................................................................................................................... 535 Perguntas de revisão................................................................................................................. 537 Exercidos................................................................................................................................ 538 Bibliografia seledonada..............................................................................................................541

Capítulo 17 Estruturas de indexação para arquivos e projeto físico de banco de dados...........................................................................543 17.1 Tipos de índices ordenados de único nível .............................................................................. 544 172 índices multiniveis............................................................................................................ 554 17.3 índices multiniveis dinâmicos usando B-trees e B’-trees............................................................ 557 17.4 índices em múltiplas chaves................................................................................................ 569 17.5 Outras tipos de índices....................................................................................................... 572 17.6 Algumas questões gerais referentes à indexação...................................................................... 576 17.7 Projeto fisico em bancos de dados relaóonais......................................................................... 581 17.8 Resumo........................................................................................................................... 584 Perguntas de revisão................................................................................................................. 585 Exercícios................................................................................................................................ 585 Bibliografia seledonada..............................................................................................................588

PARTE 8 Processamento e otimização de consulta Capítulo 18 Estratégias para processamento de consulta...................................... 593 18.1 Traduzindo consultas SQL para álgebra relacionai e outros operadores......................................... 595 182 Algoritmos para ordenação externa...................................................................................... 598 18.3 Algoritmos para a operação SELECT...................................................................................... 600 18.4 Implementando a operação JOIN.......................................................................................... 605 18.5 Algoritmos para operações PROJEÇÃO e de conjunto................................................................. 612 18.6 Implementando operações de agregação e diferentes tipos de JOINs............................................. 614 18.7 Combinando operações usando pipelining.............................................................................. 616 18.8 Algoritmos paralelos para processamento de consulta............................................................... 618 18.9 Resumo........................................................................................................................... 622 Perguntas de revisão................................................................................................................. 623

XX Sistemas de banco de dados

Exerdcios................................................................................................................................ 624 Bibliografia selecionada..............................................................................................................624 Capítulo 19 Otimizaçãode consulta.......................................................................... 625 19.1 Árvores de consulta e heuristica para otimização de consulta.......................................................626 19.2 Escolha de planos de execução de consulta............................................................................ 634 19.3 Usando seletividades na otimização baseada em custo............................................................. 642 19.4 Funções de custo para a operação SELEÇÃO............................................................................ 645 19.5 Funções de custo para a operação JUNÇÃO............................................................................ 648 19.6 Exemplo para ilustrar a otimização de consulta baseada em custo................................................ 657 19.7 Outras questões relacionadas ã otimização de consulta............................................................. 659 19.8 Exemplo de otimização de consulta em data warehouses............................................................ 661 19.9 Visão geral da otimização da consulta na Oracle...................................................................... 663 19.10 Otimização de consulta semântica...................................................................................... 667 19.11 Resumo......................................................................................................................... 667 Perguntas de revisão................................................................................................................. 668 Exerdcios................................................................................................................................ 669 Bibliografia selecionada..............................................................................................................669

PARTE 9 Processamento de transações, controle de concorrência e recuperação Capítulo 20 Introdução aos conceitos e teoria de processamento de transações..............................................................................................673 20.1 Introdução ao processamento de transações...........................................................................674 202 Conceitos de transação e sistema ........................................................................................ 680 20.3 Propriedades desejáveis das transações................................................................................. 684 20.4 Caracterizando schedules com base na facilidade de recuperação................................................ 685 20.5 Caracterizando schedules com base na facilidade de serialização................................................ 689 20.6 Suporte para transação em SQL........................................................................................... 697 20.7 Resumo........................................................................................................................... 699 Perguntas de revisão................................................................................................................. 700 Exerdcios................................................................................................................................ 701 Bibliografia selecionada.............................................................................................................. 702

Capitulo 21 Técnicas de controle de concorrência................................................... 703 21.1 Técnicas de bloqueio em duas fases para controle de concorrénda...............................................704 212 Controle de concorrência baseado na ordenação de rótulo de tempo (timestamp)............................ 713 21.3 Técnicas de controle de concorrência multiversão .................................................................... 716 21.4 Técnicas de validação (otimista) e controle de concorrénda por isolamento de snapshot.................... 718 21.5 Granularidade dos itens de dados e bloqueio de granularidade múltipla........................................ 721 21.6 Usando bloqueios para controle de concorrência em indices....................................................... 724 21.7 Outras questões de controle de conconência........................................................................... 725 21.8 Resumo........................................................................................................................... 727 Perguntas de revisão................................................................................................................. 728 Exerdcios................................................................................................................................ 729 Bibliografia selecionada.............................................................................................................. 729 Capítulo 22 Técnicas de recuperação de banco de dados....................................... 731 22.1 Conceitos de recuperação.................................................................................................... 732 222 Recuperação NO-UNDO/REDO baseada em atualização adiada................................................... 738 22.3 Técnicas de recuperação baseadas em atualização imediata....................................................... 741 22.4 Paginação de sombra......................................................................................................... 742 22.5 O algoritmo de recuperação ARIES........................................................................................ 743 22.6 Recuperação em sistemas de múltiplos bancos de dados............................................................ 747 22.7 Backup e recuperação de banco de dados contra falhas catastróficas........................................... 748 22.8 Resumo........................................................................................................................... 748

Sumário XXI

Perguntas de revisão................................................................................................................. 749 Exercícios................................................................................................................................ 750 Bibliografia selecionada..............................................................................................................752

PARTE 10 Bancos de dados distribuídos, sistemas NOSQL e Big Data Capítulo 23 Bancos de dados distribuídos............................................................... 757 23.1 Conceitos de banco de dados cistribuído................................................................................ 758 232 Técnicas de fragmentação, replkação e alocação de dados para projeto de banco de dados distribuído........................................................................................................................ 762 23.3 Visão geral do controle de conconência e recuperação em bancos de dados distrbuídos.................. 769 23.4 Visão geral do gerenciamento de transação em bancos de dados distribuídos ............................... 772 23.5 Processamento e otimização de consulta em bancos de dados distribuídos ................................... 774 23.6 Tipos de sistemas de bancos de dados distribuídos .................................................................. 779 23.7 Arquiteturas de banco de dados distribuídas...........................................................................782 23.8 Gerenciamento de catálogo distribuído..................................................................................787 23.9 Resumo........................................................................................................................... 788 Perguntas de revisão................................................................................................................. 789 Exercidos................................................................................................................................ 790 Bibliografia selecionada..............................................................................................................792 Capítulo 24 Bancos de dados NOSQL e sistemas de armazenamento Big Data . . 795 24.1 Introdução aos sistemas NOSQL........................................................................................... 796 242 0 teorema CAP................................................................................................................. 800 24.3 Sistemas NOSQL baseados em documentos e MongoDB............................................................ 801 24.4 Armazenamentos chave-valor em NOSQL .............................................................................. 806 24.5 Sistemas NOSQL baseados em coluna ou em largura de coluna ................................................ 810 24.6 Bancos de dados de grafos NOSQL e Neo4j............................................................................. 814 24.7 Resumo........................................................................................................................... 818 Perguntas de revisão................................................................................................................. 819 Bibliografia selecionada..............................................................................................................820 Capítulo 25 Tecnologias Big Databaseadas em MapReduce e Hadoop................... 821 25.1 0 que é Big Data? ............................................................................................................ 823 252 Introdução a MapReduce e Hadoop...................................................................................... 826 25.3 Hadoop Distributed Rle System (HDfS) ..................................................................................830 25.4 MapReduce: detalhes adicionais .......................................................................................... 835 25.5 Hadoop v2, também chamado YARN .....................................................................................844 25.6 Discussão geral................................................................................................................. 851 25.7 Resumo........................................................................................................................... 859 Perguntas de revisão................................................................................................................. 860 Bibliografia selecionada..............................................................................................................861

PARTE 11 Modelos, sistemas e aplicações de bancos de dados avançados Capitulo 26 Modelos de dados avançados: introdução a bancos de dados ativos, temporais, espaciais, multimídia e dedutivos..... 867 26.1 Conceitos de banco de dados ativo e triggers...........................................................................868 262 Conceitos de banco de dados temporal................................................................................... 878 26.3 Conceitos de banco de dados espacial................................................................................... 890 26.4 Conceitos de banco de dados multimídia................................................................................ 897 26.5 Introdução aos bancos de dados dedutivos.............................................................................. 901 26.6 Resumo........................................................................................................................... 913 Perguntas de revisão................................................................................................................. 914 Exercícios...............................................................................................................................915 Bibliografia selecionada..............................................................................................................918

XXII

Sistemas de banco de dados Capítulo 27 Introdução à recuperação de informações e busca na web.............. 921 27.1 Conceitos de recuperação de informações (Ri)......................................................................... 922 272 Modelos de recuperação..................................................................................................... 930 27.3 Tipos de consdtas em sistemas de RI.....................................................................................934 27.4 Pré-processamento de textos...............................................................................................936 27.5 Indexação invertida............................................................................................................ 939 27.6 Medidas de avaliação de relevância da pesquisa...................................................................... 942 27.7 Pesquisa e análise na web................................................................................................. 945 27.8 Tendêndas na recuperação de informações.............................................................................. 954 27.9 Resumo........................................................................................................................... 960 Perguntas de revisão................................................................................................................. 960 Bibliografia selecionada..............................................................................................................962 Capítulo 28 Conceitos de mineração de dados....................................................... 965 28.1 Visão geral da tecnologia de mineração de dados...................................................................... 966 28.2 Regras de associação......................................................................................................... 969 28.3 Classificação.................................................................................................................... 979 28.4 Agrupamento.................................................................................................................... 982 28.5 Abordagens para outros problemas de mineração de dados........................................................ 984 28.6 Aplicações de mineração de dados........................................................................................ 987 28.7 Ferramentas comerciais de mineração de dados....................................................................... 988 28.8 Resumo........................................................................................................................... 990 Perguntas de revisão................................................................................................................. 990 Exerdcios............................................................................................................................... 991 Bibliografia selecionada..............................................................................................................992 Capítulo 29 Visão geral de data warehousing e OLAP.............................................995 29.1 Introdução, definições e terminologia.....................................................................................996 292 Características dos data warehouses...................................................................................... 997 29.3 Modelagem de dados para data warehouses...........................................................................998 29.4 Criando um data warehouse............................................................................................... 1003 29.5 Funoonalidade típica de um data warehouse......................................................................... 1006 29.6 Data warehouses versus visões............................................................................................1007 29.7 Dificuldades de implementação de data warehouses............................................................... 1008 29.8 Resumo.......................................................................................................................... 1009 Perguntas de revisão............................................................................................................... 1010 Bibliografia selecionada............................................................................................................ 1011

PARTE 12 Tópicos adicionais de banco de dados: segurança Capitulo 30 Segurança de banco de dados........................................................... 1015 30.1 Introdução a questões de segurança de banco de dados.......................................................... 1016 302 Controle de acesso discricionário baseado na concessão e revogação de privilégios....................... 1022 30.3 Controle de acesso obrigatório e controle de acesso baseado em papel para segurança multinível... 1027 30.4 Injeção de SQL................................................................................................................. 1035 30.5 Introdução à segurança do banco de dados estatístico............................................................. 1037 30.6 Introdução ao controle de fluxo.......................................................................................... 1039 30.7 Criptografia e infraestruturas de chave pública....................................................................... 1041 30.8 Questões de privacidade e preservação..................................................................................1044 30.9 Desafios da segurança do banco de dados.............................................................................1045 30.10 Segurança baseada em rótulo no Oracle.............................................................................. 1046 30.11 Resumo........................................................................................................................ 1049 Perguntas de revisão................................................................................................................1050 Exerdcios...............................................................................................................................1051 Bibliografia selecionada............................................................................................................ 1051

Sumário XXIII Apêndice A Notações diagramáticas alternativas para modelos ER.................... 1053 Apêndice B Parâmetros de discos..........................................................................1057 Apêndice C Visão geral da linguagem QBE........................................................... 1061 C1 Recuperações básicas em QBE............................................................................................. 1061 C2 Agnçamento, agregação e modificação de banco de dados em QBE............................................ 1065 Bibliografia.............................................................................................................. 1069

índice remissive........................................................................................................ 1097

Ramez Elmasri é professor e presidente associado do Departamento de Ciência da Computação e Engenharia da Universidade do Texas em Arlington. Ele tern mais de 140 publicações de pesquisa indicadas e supervisionou 16 estudantes de doutorado e mais de 100 estudantes de mestrado. Sua pesquisa cobriu muitas áreas de gerenciamento de banco de dados e big data, incluindo modelagem conceituai e integração de dados, linguagens de consulta e técnicas de indexação, bancos de dados temporais e espaço-temporais, bancos de dados bioinformáticos, coleta de dados de redes de sensores e mineração/análise de dados temporais e espaço-temporais. Elmasri trabalhou como consultor em várias empresas, incluindo Digital, Honeywell, Hewlett-Packard e Action Technologies, além de prestar consultoria sobre patentes em empresas de advocacia. Foi presidente de programa na International Conference on Conceptual Modeling (conferência ER) em 1993 e vice-presidente de programa na IEEE International Conference on Data Engineering em 1994. Ele participou do comitê diretor da conferência ER e esteve nos comitês de programa de muitas conferências. Ele ofereceu vários tutoriais nas conferências VLDB, ICDE e ER. Também foi coautor do livro “Operating Systems: A Spiral Approach” (McGraw-Hill, 2009) com Gil Carrick e David Levine. Elmasri recebeu o Prêmio de Excelência em Ensino da UTA College of Engineering em 1999. É bacharel em Engenharia pela Alexandria University e possui mestrado e doutorado em Ciência da Computação pela Stanford University. Shamkant B. Navathe é professor e fundador do grupo de pesquisa em banco de dados da Faculdade de Computação do Georgia Institute of Technology, em Atlanta. Ele trabalhou com a IBM e a Siemens em suas divisões de pesquisa e foi consultor de várias empresas, incluindo Digital, Computer Corporation of America, Hewlett Packard, Equifax e Persistent Systems. Ele foi copresidente geral da Conferência Internacional VLDB (Very Large Data Base) em 1996 em Bombaim, na índia. Ele

também foi copresidente de programa da Conferência Internacional ACM SIGMOD

XXVI

Sistemas de banco de dados em 1985 e copresidente geral do IFIP WG 2.6 Data Semantics Workshop em 1995. Ele trabalhou na f undação VLDB e esteve nos comitês diretores de várias conferên­ cias. Navathe foi editor associado de vários periódicos, incluindo ACM Computing Surveys e IEEE Transactions on Knowledge and Data Engineering. Também foi coautor do livro “Conceptual Design: An Entity Relationship Approach” (Addison Wesley, 1992) com Carlo Batini e Stefano Ceri. Navathe é membro da Association for Computing Machinery (ACM) e recebeu o prêmio TCDE Computer Science, Engineering and Education Impact do IEEE em 2015. Navathe possui doutorado pela Universidade de Michigan e tem mais de 150 publicações indicadas em perió­ dicos e conferências.

Site de apoio do tivro Na Sala Virtual deste livro (), professores e estu­ dantes podem acessar os seguintes materiais adicionais:

Para professores:

■ Apresentações em PowerPoint. ■ Banco de imagens (em inglês). ■ Manual de soluções (em inglês).

Esse material é de uso exclusivo para professores e está protegido por senha. Para ter acesso a ele, os

professores que adoram o livro devem entrar em con­ tato com seu representante Pearson ou enviar e-mail

para [email protected].

Para estudantes:

■ Xlanual de laboratório (em inglês).

PARTE 1 Introdução aos bancos de dados

Bancos de dados e usuários de banco de dados ancos de dados e sistemas de banco de dados são um componente essencial da vida na sociedade moderna; a maioria de nós encontra diariamente diver­ sas atividades que envolvem alguma interação com um banco de dados. Por exemplo, quando vamos ao banco para depositar ou retirar fundos, quando fazemos uma reserva de hotel ou de voo, quando acessamos o catálogo de uma biblioteca para buscar um livro ou quando compramos algo on-line — como um livro, um brinquedo ou um computador —, essas atividades provavelmente envolverão alguém ou algum programa de computador que acessa um banco de dados. Até mesmo a compra de produtos em um supermercado em geral atualiza automaticamente o banco de dados que mantém o controle de estoque dos itens. Essas interações são exemplos do que podemos chamar de aplicações de banco de dados tradicionais, em que a maior parte da informação armazenada e acessada é textual ou numérica. Nos últimos anos, os avanços na tecnologia levaram a novas e interessantes aplicações dos sistemas de banco de dados. A proliferação de websites de redes sociais, como Facebook, Twitter e Flickr, dentre muitos outros, exigiu a criação de bancos dc dados imensos, que armazenam dados não tradicionais, como postagens, tuítes, imagens e clipes de vídeos. Novos tipos de sistemas de banco de dados, geralmente chamados de sistemas de armazenamento big data, ou sistemas NOSQL, foram criados para gerenciar dados para aplicações de mídia social. Esses tipos de sistemas também são usados por empresas como Google, Amazon c Yahoo, para administrar os dados exigidos em seus mecanismos de busca na web, assim como para oferecer armazenamento em nuvem, em que os usuários recebem capacidade de armazenamento na web para gerenciar todos os tipos de dados, incluindo documentos, programas, imagens, vídeos e e-mails. O Capítulo 24 oferecerá uma visão geral desses novos tipos de sistemas de banco de dados. Agora mencionaremos algumas outras aplicações dos bancos de dados. A grande disponibilidade de tecnologia de foto e vídeo em telefones celulares e outros dispo­ sitivos tomou possível armazenar imagens, clipes de áudio e streams de vídeo de

B

4 Sistemas de banco de dados forma digital. Esses tipos de arquivos estão se tornando um componente importante dos bancos dc dados dc multimídia. Os sistemas dc informações geográficas (GIS — Geographic information Systems) podem armazenar e analisar mapas, dados de clima e imagens de satélite. Sistemas de data warehousing c processamento analítico on-line (OLAP— On-Line Analytical Processing) sào usados em muitas empresas para extrair c analisar informações comerciais úteis a partir dc bancos dc dados muito grandes, para ajudar na tomada dc decisão. A tecnologia dc tempo real e banco dc dados ativo é usada para controlar processos industriais c dc manufatura. Além disso, técnicas dc pesquisa de banco de dados estão sendo aplicadas à World Wide Web para melhorar a busca por informações necessárias feita pelos usuários que utilizam a internet. No entanto, para entender os fundamentos da tecnologia de banco de dados, devemos começar das aplicações básicas dc banco de dados tradicional. Na Seção 1.1, começamos definindo um banco de dados, e a seguir explicamos outros ter­ mos básicos. Na Seção 1.2, oferecemos um simples exemplo de banco de dados UNIVERSIDADE para ilustrar nossa discussão. A Seção 1.3 descreve algumas das principais características dos sistemas de banco de dados, e as seções 1.4 e 1.5 clas­ sificam os tipos de pessoas cujas funções envolvem o uso e a interação com sistemas dc banco dc dados. As seções 1.6,1.7 c 1.8 ofcrcccm uma discussão mais profunda sobre as diversas capacidades oferecidas pelos sistemas de banco dc dados e discutem algumas aplicações típicas. A Seção 1.9 resume o capítulo. O leitor interessado em uma introdução rápida aos sistemas de banco dc dados pode estudar as seções 1.1a 1.5, depois pular ou folhear as seções 1.6 a 1.8 c seguir para o Capítulo 2.

1.1 Introdução Os bancos dc dados e sua tecnologia têm um impacto importante sobre o uso cada vez maior dos computadores. E correto afirmar que os bancos de dados desem­ penham um papel crítico em quase todas as áreas nas quais os computadores são usados, incluindo comércio tradicional, comércio eletrônico, mídias sociais, enge­ nharia, medicina, genérica, direito, educação e biblioteconomia. O termo banco de dados (do original database) é tão utilizado que precisamos começar definindo o que é um banco de dados. Nossa definição inicial é bastante genérica. Um banco de dados é uma coleção de dados1 relacionados. Com dados queremos dizer fatos conhecidos que podem ser registrados e que possuem significado implí­ cito. Por exemplo, considere os nomes, números de telefone e endereços das pessoas que você conhece. Atualmente, esses dados costumam ser armazenados em telefones celulares, que possuem seu próprio software de banco dc dados simples. Eles também podem ser registrados em uma agenda indexada ou armazenados cm um disco rígido, usando um computador pessoal e um software como Microsoft Access ou Excel. Essa coleção de dados relacionados, com um significado implícito, é um banco de dados. Essa definição de banco de dados é muito genérica; por exemplo, podemos considerar a coleção dc palavras que compõem esta página dc texto como dados relacionados c, ponanto, constitui um banco dc dados. Porém, o uso comum do termo banco de dados normalmente é mais restrito. Um banco de dados tem as seguintes propriedades implícitas: ■ Um banco de dados representa algum aspecto do mundo real, às vezes chamado dc minimundo ou dc universo dc discurso. As mudanças no minimundo são refletidas no banco dc dados. 1 O livro original utiliza a palavra data no singular c no plural, pois isso c comum na literatura dc banco de dados; o contexto determinará se ela está no singular ou no plural. (Em inglês padrão, data é usado para o plural c datum, para o singular.)

Capítulo 1

Bancos de dados e usuários de banco de dados

■ Um banco de dados é uma coleção logicamente coerente de dados com algum significado inerente. Uma variedade aleatória de dados não pode ser corretamente chamada de banco de dados. ■ Um banco de dados é projetado, montado e preenchido com dados para uma finalidade específica. Ele tem um grupo intencionado de usuários e algumas aplicações previamente concebidas nas quais esses usuários estão interessados.

Em outras palavras, um banco de dados tem alguma fonte da qual os dados são derivados, algum grau de interação com eventos no mundo real e uma audiência que está ativamente interessada cm seu conteúdo. Os usuários finais de um banco de dados podem realizar transações comerciais (por exemplo, um cliente compra uma câmera) ou podem acontecer eventos (por exemplo, uma funcionária tem um filho) que fazem com que a informação no banco de dados mude. Para que um banco de dados seja preciso e confiável o tempo todo, ele precisa ser um reflexo verdadeiro desse minimundo que representa; portanto, as mudanças precisam ser refletidas no banco de dados o mais rápido possível. Um banco de dados pode ter qualquer tamanho e complexidade. Por exemplo, a lista de nomes e endereços referenciados anteriormente pode consistir em apenas algumas centenas de registros, cada um com uma estrutura simples. Por outro lado, o catálogo com­ putadorizado de uma grande biblioteca pode conter meio milhão de entradas organizadas sob diferentes categorias — por sobrenome do autor principal, por assunto, por título do livro—com cada categoria organizada alfabedcamente. Um banco de dados de tamanho e complexidade ainda maiores podería ser mantido por uma empresa de rede social, como o Facebook, que tem mais de um bilhão de usuários. O banco de dados precisa manter informações sobre quais usuários estão relacionados a outros como amigos, as postagens de cada usuário, quais usuários poderão ver cada postagem e uma quantidade imensa de outros tipos de informações necessárias para a operação correta de seu website. Para esses sites, é preciso haver uma grande quantidade de bancos de dados para acompanhar as informações, em constante mudança, exigidas pelo site de rede social. Um exemplo de um grande banco de dados comercial é o Amazon.com. Ele contém dados de mais de 60 milhões de usuários ativos e milhões de livros, CDs, vídeos, DVDs, jogos, produtos eletrônicos, roupas e outros itens. O banco de dados ocupa mais de 42 terabytes (um terabyte equivale a IO12 bytes de armazenamento) e é armazenado em centenas de computadores (denominados servidores). Milhões de visitantes acessam o Amazon.com diariamente e utilizam o banco de dados para fazer compras. O banco de dados é continuamente atualizado à medida que novos livros e outros itens são acrescentados ao estoque e as quantidades em estoque são atualizadas à medida que as compras são feitas. Um banco de dados pode ser gerado e mantido manualmente, ou pode ser compu­ tadorizado. Por exemplo, um catálogo de cartão de biblioteca é um banco de dados que pode ser criado e mantido manualmente. Um banco de dados computadorizado pode ser criado e mantido por um grupo de programas de aplicação, escritos cspecificamente para essa tarefa, ou por um sistema de gerenciamento de banco de dados. Neste livro, naturalmente, vamos tratar apenas dos bancos de dados computadorizados. Um sistema de gerenciamento de banco de dados (SGBD) é um sistema compu­ tadorizado que permite que os usuários criem e mantenham um banco de dados. O SGBD é um sistema de software de uso geral que facilita o processo de definição, construção, manipulação e compartilhamento de bancos de dados entre diversos usuários e aplicações. A definição de um banco de dados envolve especificar os tipos de dados, as estruturas e restrições dos dados a serem armazenados. A definição ou informação descritiva do banco de dados também é armazenada pelo SGBD na forma de um catálogo ou dicionário, chamado de metadados. A construção do banco de dados é o processo de armazenar os dados em algum meio de armazenamento

5

6 Sistemas de banco de dados

controlado pelo SGBD. A manipulação de um banco de dados inclui funções como consulta, para recuperar dados específicos, atualização, para refletir mudanças no minimundo, e geração de relatórios a partir dos dados. O compartilhamento per­ mite que vários usuários e programas acessem o banco de dados simultaneamente. Um programa de aplicação acessa o banco de dados enviando consultas ou solicitações para dados ao SGBD. Uma consulta2 normalmente faz com que alguns dados sejam recuperados; uma transação pode fazer com que alguns dados sejam lidos e alguns sejam gravados no banco de dados. Outras funções importantes fornecidas pelo SGBD incluem proteção do banco de dados e sua manutenção por um longo período de tempo. A proteção inclui pro­ teção do sistema contra defeitos (ou falhas) de hardware ou software e proteção de segurança contra acesso não autorizado ou malicioso. Um grande banco de dados típico pode ter um ciclo de vida de muitos anos, de modo que o SGBD precisa ser capaz de manter o sistema de banco de dados, permitindo que ele evolua à medida que os requisitos mudam com o tempo. Não é absolutamente necessário usar software de SGBD de uso geral para implemen­ tar um banco de dados computadorizado. Poderiamos escrever nosso próprio conjunto de programas para criar e manter o banco de dados, com efeito criando nosso próprio software de SGBD de uso especial para uma aplicação específica, como reservas de voos. De qualquer forma — se usarmos um SGBD de uso geral ou não —, normalmente temos de implementar uma quantidade considerável de software complexo. De fato, a maioria dos SGBDs e constituída de sistemas de software muito complexos. Para completar nossas definições iniciais, chamaremos a união do banco de dados com o software de SGBD de sistema de banco de dados. A Figura 1.1 ilustra alguns dos conceitos que discutimos até aqui. Usuários/programadores

Figura 1.1 Diagrama simplificado de um ambiente de sistema de banco de dados.

- O termo consulta (em inglês query), que originalmente significa uma pergunta ou uma pesquisa, é usado livremente para todos os tipos de interações com bancos de dados, incluindo a modificação dos dados.

Capítulo 1

Bancos de dados e usuários de banco de dados

7

1.2 Um exemplo Vamos considerar um exemplo simples ao qual a maioria dos leitores pode estar acostumada: um bancode dados UNIVERSIDADE,para manter informações referentes a alunos, disciplinas e notas em um ambiente universitário. A Figura 1.2 mostra a estrutura do banco de dados e alguns exemplos de registros de dados. O banco de dados está organizado como cinco arquivos, cada um armazenando registros

ALUNO

Nome

Numero aluno

Tipo aluno

Curso

Silva

17

1

CC

Braga

8

2

cc

Figura 1.2 Exemplo de um banco de dados que armazena informações de aluno e disciplina.

DISCIPLINA

Departamento

Nome disciplina

Numero disciplina

Créditos

Introdução à ciência da computação

CC1310

4

CC

Estruturas de dados

CC3320

4

CC

Matemática discreta

MAT2410

3

MAT

Banco de dados

CC3380

3

CC

TURMA

ldentificador_turma

Numero_disciplina

Semestre

Ano

85

MAT2410

Segundo

07

Kleber

92

CC1310

Segundo

07

Anderson

102

CC3320

Primeiro

08

Carlos

112

MAT2410

Segundo

08

Chang

119

CC1310

Segundo

08

Anderson

135

CC3380

Segundo

08

Santos

REGISTRO NOTA Numero aluno

Identificador turma

Nota

17

112

B

17

119

C

8

85

A

8

92

A

8

102

B

8

135

A

PRE REQUISITO

Numero disciplina

Numero pre_requisito

CC3380

CC3320

CC3380

MAT2410

CC3320

CC1310

Professor

8 Sistemas de banco de dados

de dados do mesmo tipo.3 O arquivo ALUNO armazena dados sobre cada aluno, o arquivo DISCIPLINA armazena dados sobre cada disciplina, o arquivo TURMA arma­ zena dados sobre cada turma de uma disciplina, o arquivo REGISTRO_NOTA armazena as notas que os alunos recebem nas várias turmas que eles concluíram, e o arquivo PRE_REQUISITO armazena os pré-requisitos de cada disciplina. Para definir esse banco de dados, precisamos especificar a estrutura dos registros de cada arquivo, especificando os diferentes tipos de elementos dc dados a serem armazenados em cada registro. Na Figura 1.2, cada registro de ALUNO inclui dados para representar Nome, Numero_aluno, Tipo_aluno (como novato ou ‘1’, segundo ano ou ‘2*, e assim por diante) e Curso (como matemática ou ‘MAT e ciência da computação ou ‘CC’); cada registro de DISCIPLINA inclui dados para representar Nome_disciplina, Numero_disciplina, Créditos e Departamento (o departamento que oferece a disciplina), e assim por diante. Também precisamos especificar um tipo de dado para cada elemento de dado dentro de um registro. Por exemplo, pode­ mos especificar que o Nome de ALUNO é uma sequência de caracteres alfabéticos; Numero.aluno de ALUNO é um inteiro, e Nota de REGISTRO_NOTA é um único caractere de um conjunto {‘A’, ‘B’, ‘C’, ‘D’, ‘F, ‘I’). Também podemos usar um esquema de codificação para representar os valores dc um item dc dados. Por exemplo, na Figura 1.2, representamos o Tipo_aluno de um ALUNO como 1 para novato, 2 para segundo ano, 3 para júnior, 4 para sênior e 5 para aluno formado. Para construir o banco de dados UNIVERSIDADE, armazenamos dados para repre­ sentar cada aluno, disciplina, turma, registro de nota e pré-requisito como um registro no arquivo apropriado. Observe que os registros nos diversos arquivos podem estar relacionados. Por exemplo, o registro para Silva no arquivo ALUNO está relacionado a dois registros no arquivo REGISTRO_NOTA, que especificam as notas de Silva em duas turmas. De modo semelhante, cada registro no arquivo PRE_REQUISITO relaciona-se a dois registros de disciplina: um representando a disciplina e o outro representando o pré-requisito. A maioria dos bancos de dados de tamanho médio e grande inclui muitos tipos de registros e possui muitos relacionamentos entre os registros. A manipulação do banco de dados envolve consulta e atualização. Alguns exem­ plos de consultas são os seguintes: ■ Recuperar o histórico — uma lista dc todas as disciplinas c notas — dc ‘Silva’. ■ Listar os nomes dos alunos que realizaram a disciplina “Banco de dados” ofere­ cida no segundo semestre de 2008 e suas notas nessa turma. ■ Listar os pré-requisitos da disciplina ‘Banco de dados’.

Alguns exemplos dc atualizações incluem os seguintes: ■ Alterar o tipo de aluno de ‘Silva’ para segundo ano. ■ Criar outra turma para a disciplina ‘Banco de dados’ para este semestre. ■ Entrar com uma nota ‘A’ para ‘Silva’ na disciplina ‘Banco de dados’ do último semestre.

Essas consultas e atualizações informais precisam ser especificadas exaramente na linguagem de consulta do SGBD antes que possam ser processadas. Nesse estágio, é útil descrever o banco dc dados como uma parte de uma tarefa maior conhecida como sistema de informação dentro dc qualquer organização. O departamento de Tecnologia da Informação (TI) dentro de uma empresa projeta e mantém um sistema de informações que consiste de vários computadores, sistemas de armazenamento, software de aplicação e bancos de dados. O projeto de uma

3 Usamos o termo arquivo informalmente aqui. Em um nível conceituai, um arquivo é uma coleção de registros que podem ou não estar ordenados.

Capítulo 1

Bancos de dados e usuários de banco de dados

nova aplicação para um banco de dados existente ou o projeto de um novo banco de dados começa com uma fase chamada especificação e análise de requisitos. Esses requisitos são documentados com detalhes e transformados em um projeto conceituai, que pode ser representado e manipulado com o uso de algumas ferra­ mentas computadorizadas, de modo que possa ser facilmente mantido, modificado e transformado em uma implementação de banco de dados. (Apresentaremos um modelo chamado modelo Entidade-Relacionamento, no Capítulo 3, que é usado para essa finalidade.) O projeto é então traduzido para um projeto lógico, que pode ser expresso em um modelo de dados implementado em um SGBD comercial. (Diversos tipos de SGBDs serão discutidos no decorrer do texto, com ênfase nos SGBDs relacionais, nos capítulos 5 a 9.) O estágio final é o projeto físico, durante o qual outras especificações são for­ necidas para armazenar e acessar o banco de dados. O projeto de banco de dados é implementado, preenchido com dados reais e mantido continuamente para refletir o estado do minimundo.

1.3 Características da abordagem de banco de dados Diversas características distinguem a abordagem de banco de dados da técnica muito mais antiga de escrever programas customizados para acessar os dados armazenados em arquivos. No processamento de arquivo tradicional, cada usuá­ rio define e implementa os arquivos necessários para uma aplicação de software específica como parte da programação da aplicação. Por exemplo, um usuário, o departamento de registro acadêmico, pode manter arquivos sobre os alunos e suas noras. Os programas para imprimir o histórico do aluno e entrar com novas notas são implementados como parte da aplicação. Um segundo usuário, o departamento de finanças, pode registrar as mensalidades dos alunos e seus pagamentos. Embora os dois usuários estejam interessados cm dados sobre os alunos, cada usuário mantém arquivos separados — e programas para manipular esses arquivos —, pois cada um requer algum dado não disponível nos arquivos do outro usuário. Essa redundância na definição e no armazenamento de dados resulta em espaço de armazenamento desperdiçado e em esforços redundantes para manter os dados comuns atualizados. Na abordagem de banco de dados, um único repositório mantém dados que são definidos uma vez e depois acessados por vários usuários, repetidamente, por meio de consultas, transações e programas de aplicação. As principais características da abordagem de banco de dados versus a abordagem de processamento de arquivos são as seguintes:

■ Natureza de autodescrição de um sistema de banco de dados. ■ Isolamento entre programas c dados, e abstração de dados. ■ Suporte de múltiplas visões dos dados. ■ Compartilhamento de dados e processamento de transação multiusuário.

Descrevemos cada uma dessas características cm uma seção separada. Discutiremos características adicionais dos sistemas dc banco dc dados nas seções 1.6 a 1.8.

1.3.1 Natureza de autodescrição de um sistema de banco de dados Uma característica fundamental da abordagem de banco de dados é que o sis­ tema contém não apenas o próprio banco de dados, mas também uma definição ou descrição completa de sua estrutura c suas restrições. Essa definição é armazenada no catálogo do SGBD, que contém informações como a estrutura de cada arquivo,

9

10 Sistemas de banco de dados

o ripo e o formato de armazenamento de cada item de dados e diversas restrições sobre os dados. A informação armazenada no catálogo é chamada de metadados, e descreve a estrutura do banco de dados principal (Figura 1.1). É importante obser­ var que alguns tipos mais novos de sistemas de banco de dados, conhecidos como sistemas NOSQL, não exigem metadados. Em vez disso, os dados são armazenados como dados autodescritivos, que incluem os nomes dos itens de dados e os valores de dados, juntos em uma única estrutura (veja no Capítulo 24). O catálogo é usado pelo software de SGBD c também pelos usuários do banco de dados que precisam de informações sobre a estrutura do banco de dados. Um pacote de software de SGBD de uso geral não é escrito para uma aplicação de banco de dados específica. Portanto, ele precisa consultar o catálogo para conhecer a estrutura dos arquivos em um banco de dados específico, como o tipo e o formato dos dados que acessará. O software de SGBD precisa trabalhar de forma satisfatória com qualquer quantidade de aplicações de banco de dados — por exemplo, um banco de dados de universidade, de uma instituição bancária ou corporativo —, desde que a definição do banco de dados esteja armazenada no catálogo. No processamento de arquivos tradicional, a definição de dados normalmente faz parte dos próprios programas de aplicação. Logo, esses programas são restritos a trabalhar com apenas uni banco de dados específico, cuja estrutura é declarada nos programas de aplicação. Por exemplo, um programa de aplicação escrito em C++ pode ter declarações de estrutura ou classe. Enquanto o software de processa­ mento de arquivos pode acessar apenas bancos de dados específicos, o software de SGBD pode acessar diversos bancos de dados extraindo e usando as definições do catálogo de banco de dados. Para o exemplo mostrado na Figura 1.2, o catálogo do SGBD armazenará as definições de rodos os arquivos mostrados. A Figura 1.3 mostra alguns exemplos de entradas em um catálogo de banco de dados. Sempre que é feira uma solicitação para acessar, digamos, o Nome de um registro de ALUNO, o software de SGBD acessa o catálogo para determinar a estrutura do arquivo ALUNO e a posição e o tamanho do item de dados Nome dentro do registro de ALUNO. Ao contrário, em uma aplicação típica de processamento de arquivo, a estrutura de arquivo e, no caso extremo, o local exato do Nome dentro de um registro de ALUNO já são codificados dentro de cada programa que acessa esse item de dados.

1.3.2 Isolamento entre programas e dados, e abstração de dados No processamento de arquivos tradicional, a estrutura dos arquivos de dados está embutida nos programas de aplicação, de modo que quaisquer mudanças na estrutura de um arquivo podem exigir mudar todos os programas que acessam esse arquivo. Ao contrário, os programas de acesso ao SGBD não exigem essas mudanças na maioria dos casos. A estrutura dos arquivos de dados é armazenada no catálogo do SGBD separadamente dos programas de acesso. Chamamos essa propriedade de independência de dados do programa. Por exemplo, um programa de acesso a arquivo pode ser escrito de modo que possa acessar apenas registros de ALUNO com a estrutura mostrada na Figura 1.4. Se quisermos acrescentar outro dado a cada registro de ALUNO, digamos Data.nascimento, esse programa não funcionará mais e precisará ser alterado. Ao contrário, em um ambiente de SGBD, só precisamos mudar a descrição dos registros de ALUNO no catálogo (Figura 1.3) para refletir a inclusão do novo item de dados Data_nascimento; nenhum programa é alterado. Da próxima vez que o programa de SGBD consultar o catálogo, a nova estrutura dos registros de ALUNO será acessada c usada.

Capítulo 1

Bancos de dados e usuários de banco de dados

11

RELAÇÕES

Nome_relacao

Numero_colunas

ALUNO

4

DISCIPLINA

4

TURMA

5

REGISTRO_NOTA

3

PRE.REQUISITO

2

COLUNAS

Nomecoluna

Tipo de dado

Pertence_a_relacao

Nome

Caractere (30)

ALUNO

Numero.aluno

Caractere (4)

ALUNO

Tipo_aluno

Inteiro (1)

ALUNO

Curso

Ti po_ curso

ALUNO

Nome disdplina

Caractere (10)

DISCIPLINA

Numero-disciplina

XXXXNNNN

DISCIPLINA

Numero pre requisito

XXXXNNNN

PRE_REQUISITO

Nota: Tipo_curso é definido como um tipo enumerado com todas as matérias conheddas.

XXXXNNNN é usado para definir um tipo com quatro caracteres alfanuméricos seguidos por quatro dígitos.

Em alguns tipos de sistemas de banco de dados, como sistemas orientados a objeto e objeto-relacional (ver Capítulo 12), os usuários podem definir operações sobre dados como parte das definições do banco de dados. Uma operação (tam­ bém chamada de função ou método) é especificada em duas partes. A interface (ou assinatura) de uma operação inclui o nome da operação e os tipos de dados de seus argumentos (ou parâmetros). A implementação (ou método) da operação é especi­ ficada separadamente e pode ser alterada sem afetar a interface. Os programas de aplicação do usuário podem operar sobre os dados invocando essas operações por meio de seus nomes e argumentos, independentemente de como as operações são implementadas. Isso pode ser chamado de independência de operação do programa. A característica que permite a independência de dados do programa e a independência da operação do programa é chamada de abstração dc dados. Um SGBD oferece aos usuários uma representação conceituai de dados que não inclui muitos dos detalhes de como os dados são armazenados ou como as operações são implementadas. Informalmente, um modelo de dados é um tipo de abstração de dados usado para oferecer essa representação conceituai. O modelo de dados usa conceitos lógicos, como objetos, suas propriedades e seus inter-relacionainentos, que os usuários podem entender mais rapidamente que os conceitos de armazenamento no computador. Logo, o modelo de dados oculta os detalhes de armazenamento e implementação que não são do interesse da maioria dos usuários de banco de dados. Por exemplo, examinando as figuras 1.2 e 1.3, a implementação interna do arquivo ALUNO pode ser definida por seu tamanho de registro — o número de

Figura 1.3 Exemplo de um catálogo para o banco de dados na Figura 1.2.

12 Sistemas de banco de dados

caracteres (bytes) em cada registro — e cada item de dados pode ser especificado pelo byte inicial dentro dc um registro e seu tamanho em bytes. O registro de ALUNO, assim, seria representado como mostra a Figura 1.4. Mas um usuário de banco de dados típico nâo está preocupado com o local de cada item de dados dentro de um registro ou seu tamanho; em vez disso, o usuário se preocupa que, quando for feita uma referência ao Nome do ALUNO, o valor correto seja retor­ nado. Uma representação conceituai dos registros de ALUNO aparece na Figura 1.2. Muitos outros detalhes da organização do armazenamento do arquivo — como os caminhos de acesso especificados em um arquivo — podem ser ocultados dos usuários do banco de dados pelo SGBD; discutiremos detalhes de armazenamento nos capítulos 16 e 17. Na abordagem de banco de dados, a estrutura e organização detalhadas dc cada arquivo são armazenadas no catálogo. Os usuários do banco de dados e os programas de aplicação se referem à representação conceituai dos arquivos, e o SGBD extrai os detalhes do armazenamento do arquivo do catálogo quando estes são necessários pelos módulos de acesso a arquivo do SGBD. Muitos modelos de dados podem ser usados para oferecer essa abstração de dados aos usuários do banco de dados. Uma parte significativa deste livro é dedicada à apresentação dos vários modelos de dados e os conceitos que eles utilizam para abstrair a representação dos dados. Nos bancos de dados orientado a objeto e objeto-relacional, o processo de abs­ tração inclui não apenas a estrutura dos dados, mas também as operações sobre os dados. Essas operações oferecem uma abstração das atividades do minimundo nor­ malmente entendidas pelos usuários. Por exemplo, uma operação CALCULA_MEDIA pode ser aplicada ao objeto ALUNO para calcular a média das notas. Essas operações podem ser chamadas pelas consultas do usuário ou por programas de aplicação sem ter de saber os detalhes de como as operações são implementadas. Figura 1.4 Formato de armazenamento interno para um registro de ALUNO, com base no catálogo do banco de dados da Figura 1.3.

Posição inicial no registro

Tamanho em caracteres (bytes)

1

30

Numero_aluno

31

4

Tipo aluno

35

1

Curso

36

4

Nome do item de dados Nome

1.3.3 Suporte para múltiplas visões dos dados Um banco de dados normalmente tem muitos usuários, cada um podendo exigir uma perspectiva ou visão diferente. Uma visão (ou view) pode ser um subconjunto do banco de dados ou conter dados virtuais derivados dos arquivos do banco de dados, mas que não estão armazenados explicitamenre. Alguns usuários não preci­ sam saber se os dados a que se referem estão armazenados ou são derivados. Um SGBD multiusuário, cujos usuários têm uma série de aplicações distintas, precisa oferecer facilidades para definir múltiplas visões. Por exemplo, um usuário do banco de dados da Figura 1.2 pode estar interessado apenas em acessar e imprimir o histórico de cada aluno; a visão para esse usuário aparece na Figura 1.5(a). Um segundo usuário, que está interessado apenas em verificar se os alunos possuem todos os pré-requisitos de cada disciplina para a qual se inscreveram, pode exigir a visão mostrada na Figura 1.5(b).

Capítulo 1

Bancos de dados e usuários de banco de dados

13

HISTORICO (a) Historico.aluno

Nome_aluno

Nota

Semestre

Ano

ldentificador_turma

CC1310

C

Segundo

08

119

MAT2410

B

Segundo

08

112

MAT2410

A

Segundo

07

85

CC1310

A

Segundo

07

92

CC3320

B

Primeiro

08

102

CC3380

A

Segundo

08

135

Numero_disciplina

Silva

Braga

PRE_REQUISITO_DISCIPLINA (b)

Nome.disdplina

Numero_disciplina

Pre_requisitos

CC3320

Banco de dados

CC3380 MAT2410

Estrutura de dados

CC3320

CC1310

1.3.4 Compartilhamento de dados e processamento de transação multiusuário Um SGBD multiusuário, como o nome sugere, precisa permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Isso é essencial para que dados de várias aplicações sejam integrados e mantidos em um único banco de dados. O SGBD precisa incluir software de controle de concorrência, a fim de garantir que vários usuários tentando atualizar os mesmos dados façam isso de maneira contro­ lada, de modo que o resultado das atualizações seja correto. Por exemplo, quando vários agentes de reserva tentam atribuir um assento a um voo de uma companhia aérea, o SGBD precisa garantir que cada assento só possa ser acessado por um agente de cada vez, para que seja reservado para um único passageiro. Esses tipos de aplicações geralmente sào chamados de aplicações de processamento de transa­ ção on-line (OLTP — On-Line Transaction Processing). Um papel fundamental do software dc SGBD multiusuário é garantir que as transações concorrentes operem de modo correto e eficiente. O conceito de uma transação tem se tornado fundamental para muitas aplicações de banco de dados. Uma transação é um programa em execução ou processo que inclui um ou mais acessos ao banco dc dados, como a leitura ou a atualização dos registros. Cada transação deverá executar um acesso ao banco dc dados, sendo logicamente correta para ser executada em sua totalidade, sem interferência de outras transações. O SGBD precisa impor diversas propriedades da transação. A propriedade de isola­ mento garante que cada transação pareça executar isoladamente das outras transações, embora centenas de transações possam estar sendo executadas simultaneamente. A propriedade de atomicidadc garante que todas as operações em uma transação sejam executadas ou nenhuma seja. Discutimos sobre transações com detalhes na Parte 9.

Figura 1.5 Duas visões derivadas do banco de dados da Figura 1.2. (a) A visão HISTORICO. (b) A visão PRE_REQUISrrO_DISCIPLINA.

14 Sistemas de banco de dados

As características anteriores sào importantes na distinção entre um SGBD e o software tradicional de processamento de arquivos. Na Seção 1.6, discutiremos recur­ sos adicionais que caracterizam um SGBD. Primeiro, porém, categorizamos os dife­ rentes tipos de pessoas que trabalham em um ambiente de sistema de banco de dados.

1.4 Atores em cena Para um pequeno banco de dados pessoal, como a lista de endereços discutida na Seção 1.1, uma pessoa normalmente define, constrói e manipula o banco de dados, e não existe compartilhamento. Porém, em grandes organizações, muitas pessoas estão envolvidas no projeto, uso e manutenção de um grande banco de dados, com centenas ou milhares dc usuários. Nesta seção, identificamos as pessoas cujas fun­ ções envolvem o uso cotidiano de um grande banco de dados; nós os chamamos dc atores em cena. Na Seção 1.5, consideraremos as pessoas que podem ser chamadas de trabalhadores dos bastidores — aqueles que trabalham para manter o ambiente do sistema dc banco dc dados, mas que não estão ativamente interessados em seu conteúdo como parte dc seu trabalho cotidiano.

1.4.1 Administradores de banco de dados Em qualquer organização na qual muitas pessoas utilizam os mesmos recursos, há uma necessidade de um administrador principal supervisionar e gerenciar esses recursos. Em um ambiente de banco de dados, o recurso principal é o próprio banco de dados, e o recurso secundário é o SGBD e o software relacionado. A adminis­ tração desses recursos é de responsabilidade do administrador de banco de dados (DBA — database administrator). O DBA é responsável por autorizar o acesso ao banco de dados, coordenar e monitorar seu uso e adquirir recursos de software e hardware conforme a necessidade. Também é responsável por problemas como falhas na segurança e demora no tempo de resposta do sistema. Em grandes organizações, ele é auxiliado por uma equipe que executa essas funções.

1.4.2 Projetistas de banco de dados Os projetistas de banco de dados são responsáveis por identificar os dados a serem armazenados e escolher estruturas apropriadas para representar e armazenar esses dados. Essas tarefas são realizadas principalmente antes que o banco de dados seja realmente implementado e preenchido. É responsabilidade dos projetistas se comuni­ carem com todos os usuários do banco de dados em potencial a fim de entender seus requisitos e criar um projeto que os atenda. Em muitos casos, os projetistas estão na equipe do DBA e podem receber outras responsabilidades após o projeto do banco de dados estar concluído. Os projetistas normalmente interagem com cada grupo de usuários em potencial e desenvolvem visões do banco de dados que cumprem os requisitos de dados e processamento desses grupos. Cada visão é então analisada e integrada às visões de outros grupos de usuários. O projeto de banco de dados final precisa ser capaz de dar suporte aos requisitos de todos os grupos de usuários.

1.4.3 Usuários finais Os usuários finais são pessoas cujas funções exigem acesso ao banco de dados para consulta, atualização e geração de relatórios; o banco dc dados existe princi­ palmente para seu uso. Existem várias categorias dc usuários finais:

Capítulo 1

Bancos de dados e usuários de banco de dados

■ Usuários finais casuais ocasionalmente acessam o banco de dados, mas podem precisar de diferentes informações a cada vez. Eles utilizam uma interface dc consulta sofisticada para especificar suas solicitações e normalmente são gerentes de nível intermediário ou alto, ou outros usuários ocasionais. ■ Usuários finais iniciantes ou paramctricos compõem uma grande parte dos usuá­ rios finais. Sua função principal gira cm torno dc consultar c atualizar o banco de dados constantemente, usando tipos padrão dc consultas e atualizações — chamadas transações programadas — que foram cuidadosamente programadas e restadas. Muitas dessas tarefas estão disponíveis hoje em dia em aplicações móveis usadas com dispositivos móveis. As tarefas que esses usuários realizam são variadas. Alguns exemplos são: ■ Clientes e caixas de banco verificam saldos de conta e realizam saques e depósitos. ■ Agentes dc reserva ou clientes dc companhias aéreas, hotéis c locadoras dc auto­ móveis verificam a disponibilidade dc determinada solicitação c fazem reservas. ■ Funcionários nas estações de recebimento de transportadoras inserem identi­ ficações de pacotes por códigos de barra e informações descritivas por meio de botões para atualizar um banco de dados central de pacotes recebidos e em trânsito. ■ Usuários de redes sociais postam e leem itens nos websites das redes sociais.

■ Usuários finais sofisticados incluem engenheiros, cientistas, analistas de negócios e outros que estão profundamente familiarizados com as facilidades do SGBD a fim de implementar suas próprias aplicações, que atenderão aos seus requisitos complexos. ■ Usuários isolados mantêm bancos de dados pessoais usando pacotes de progra­ mas prontos, que oferecem interfaces dc fácil utilização, com base cm menus ou cm gráficos. Um exemplo c o usuário dc um pacote dc software financeiro, que armazena uma série dc dados financeiros pessoais.

Um SGBD típico oferece diversas facilidades para acessar um banco dc dados. Usuários finais comuns precisam aprender muito pouco sobre as facilidades ofe­ recidas pelo SGBD; eles simplesmente precisam entender as interfaces do usuário das aplicações móveis ou das transações-padrão projetadas e implementadas para seu uso. Os usuários casuais aprendem apenas algumas facilidades que podem usar repetidamente. Usuários sofisticados tentam aprender a maioria das facilidades do SGBD a fim dc satisfazer seus requisitos complexos. Usuários isolados normalmcntc se tomam especialistas no uso dc um pacote dc software específico.

1.4.4 Analistas de sistemas e programadores de aplicações

(engenheiros de software) Analistas dc sistemas determinam os requisitos dos usuários finais, especialmente os usuários comuns e paramétricos, e desenvolvem especificações para transa­ ções programadas que cumpram esses requisitos. Os programadores de aplicações implementam essas especificações como programas; depois eles testam, depuram, documentam e mantêm essas transações programadas. Esses analistas e programa­ dores — também conhecidos como desenvolvedores dc software ou engenheiros dc software — deverão estar familiarizados com toda a gama dc capacidades fornecidas pelo SGBD para realizarem suas tarefas.

1.5 Trabalhadores dos bastidores Além daqueles que projetam, usam c administram um banco de dados, outros estão associados ao projeto, desenvolvimento e operação do software do SGBD c do

15

16 Sistemas de banco de dados

ambiente de sistema. Essas pessoas normalmente nào estão interessadas no conteúdo do banco de dados em si. Vamos chamá-las de trabalhadores dos bastidores, e neles se incluem as seguintes categorias: ■ Projetistas e implementadores de sistema de SGBD projetam e implementam os módulos e interfaces do SGBD como um pacote de software. Um SGBD é um sistema de software muito complexo, que consiste em muitos componentes, ou módulos, incluindo módulos para implementação do catálogo, processamento da linguagem de consulta, processamento de interface, acesso e buffering de dados, controle de concorrência e tratamento de recuperação e segurança de dados. O SGBD precisa realizar a interface com outro software de sistemas, como o sistema operacional, e compiladores para diversas linguagens de programação. ■ Desenvolvedores de ferramentas projetam e implementam ferramentas — os pacotes de software que facilitam a modelagem e o projeto do banco de dados, o projeto do sistema de banco dc dados e a melhoria do desempenho. Ferramentas são pacotes opcionais que, em geral, são adquiridos separadamente. Elas incluem pacotes para projeto de banco de dados, monitoramento de desempenho, lingua­ gem natural ou interfaces gráficas, protótipo, simulação e geração de dados de teste. Em muitos casos, fornecedores de software independentes desenvolvem e comercializam essas ferramentas. ■ Operadores e pessoal de manutenção (pessoal de administração de sistemas) são responsáveis pela execução e manutenção real do ambiente de hardware e software para o sistema de banco dc dados.

Embora essas categorias de trabalhadores dos bastidores sejam instrumento para disponibilizar o sistema aos usuários finais, eles normalmente não utilizam o conteúdo do banco de dados para fins pessoais.

1.6 Vantagens de usar a abordagem de SGBD Nesta seção, discutimos algumas das vantagens e as capacidades que um bom SGBD deve possuir. Essas capacidades estão além das quatro principais caracterís­ ticas discutidas na Seção 1.3. O DBA precisa utilizá-las para realizar uma série de objetivos relacionados ao projeto, à administração e ao uso de um grande banco de dados multiusuário.

1.6.1 Controlando a redundância No desenvolvimento de software tradicional, utilizando processamento de arqui­ vos, cada grupo de usuários mantém seus próprios arquivos para tratar de suas aplicações dc processamento dc dados. Por exemplo, considere o exemplo do banco de dados UNIVERSIDADE da Seção 1.2; aqui, dois grupos de usuários podem ser o pessoal do registro acadêmico e o departamento financeiro. Na técnica tradicional, cada grupo mantém, independentemente, os arquivos sobre os alunos. O depar­ tamento financeiro mantém dados sobre o registro c as informações dc cobrança relacionadas, enquanto o departamento dc registro acadêmico acompanha os cursos e as notas dos alunos. Outros grupos podem duplicar ainda mais alguns ou todos os dados em seus próprios arquivos. Essa redundância em armazenar os mesmos dados várias vezes ocasiona vários problemas. Primeiro, é preciso realizar uma única atualização lógica — como a entrada de dados sobre um novo aluno — várias vezes: uma para cada arquivo em que os dados do aluno são registrados. Isso ocasiona uma duplicação de esforço.

Capítulo 1

Bancos de dados e usuários de banco de dados

17

Segundo, o espaço de armazenamento é desperdiçado quando os mesmos dados sào armazenados repetidamente, e esse problema pode ser sério para bancos de dados grandes. Terceiro, os arquivos que representam os mesmos dados podem se tomar inconsistentes. Isso pode acontecer porque uma atualização é aplicada a alguns dos arquivos, mas não a outros. Mesmo que uma atualização — como a inclusão de um novo aluno — seja aplicada a todos os arquivos apropriados, os dados referentes ao aluno ainda podem ser inconsistentes porque as atualizações são aplicadas indepen­ dentemente por cada grupo de usuários. Por exemplo, um grupo de usuários pode entrar com a data de nascimento de um aluno incorretamente como ‘19/01/1988’, enquanto outros grupos de usuários podem inserir o valor correto,‘29/01/1988’. Na abordagem de banco de dados, as visões de diferentes grupos de usuários são integradas durante o projeto. O ideal é que tenhamos um projeto de banco dc dados que armazena cada item de dados lógico — como o nome ou a data de nascimento de um aluno — em apenas um lugar. Isso é conhecido como normalização de dados, e garante consistência e economiza espaço de armazenamento (a normalização de dados é descrita na Parte 6 do livro). Porém, na prática, às vezes é necessário usar a redundância controlada para melhorar o desempenho das consultas. Por exemplo, podemos armazenar Nome_ aluno e Numero_disdplina redundantemente em um arquivo REGISTRO_NOTA |Figura 1.6(a)] porque sempre que recuperamos um REGISTRO_NOTA, queremos recuperar o nome do aluno e o número da disciplina juntamente com a nota, o número do aluno e o identificador dc turma. Colocando todos os dados juntos, não precisamos pesquisar vários arquivos para coletar esses dados. Isso é conhecido como desnormalização. Nesses casos, o SGBD deverá ter a capacidade de controlar essa redundância a fim de proibir inconsistências entre os arquivos. Isso pode ser feito verificando automa­ ticamente se os valores de Nome_aluno-Numero_aluno em qualquer REGISTRO.NOTA na Figura 1.6(a) combinam com um dos valores de Nome-Numero_aluno de um registro de ALUNO (Figura 1.2). De modo semelhante, os valores de Identificador.turma-Numero_disciplina dc REGISTRO_NOTA podem ser comparados com os registros de TURMA. Essas verificações podem ser especificadas ao SGBD durante o projeto

REGISTRO NOTA

Numero_ aluno

Nome_aluno

Identificador, turma

Numero, disciplina

Nota

17

Silva

112

MAT2410

B

17

Silva

119

CC1310

C

8

Braga

85

MAT2410

A

8

Braga

92

CC1310

A

8

Braga

102

CC3320

B

8

Braga

135

CC3380

A

Numero, aluno

Nome.aluno

Identificador. turma

Numero, disciplina

Nota

17

Braga

112

MAT2410

B

REGISTRO NOTA

Figura 1.6 Armazenamento redundante de Nome_aluno e Numero_disdplina em REGISTRO.NOTA. (a) Dados consistentes, (b) Registro inconsistente.

18 Sistemas de banco de dados

do banco de dados e impostas automaticamente pelo SGBD sempre que o arquivo REGISTRO_NOTA for atualizado. A Figura 1.6(b) mostra um REGISTRO_NOTA incon­ sistente com o arquivo ALUNO na Figura 1.2; esse tipo de erro pode ser inserido se a redundância não for controlada. Você consegue identificar a parte inconsistente?

1.6.2 Restringindo o acesso não autorizado Quando vários usuários compartilham um banco de dados grande, é provável que a maioria deles não esteja autorizada a acessar todas as informações. Por exemplo, dados financeiros, como salários c bonificações, normalmente sâo considerados con­ fidenciais, e somente pessoas autorizadas têm permissão para acessá-los. Além disso, alguns usuários podem ter permissão apenas para recuperar dados, enquanto outros têm permissão para recuperar e atualizar. Logo, o tipo de operação de acesso — recu­ peração ou atualização — também deve ser controlado. Normalmente, os usuários ou grupos de usuários recebem números de conta protegidos por senhas, que eles podem usar para obter acesso ao banco de dados. Um SGBD deve oferecer um subsistema de segurança e autorização, que o DBA utiliza para criar contas e especificar restrições de conta. Então, o SGBD deve impor essas restrições automaticamente. Observe que podemos aplicar controles semelhantes ao software de SGBD. Por exemplo, somente o pessoal do DBA pode ter permissão para usar certo software privilegiado, como o software para criar novas contas. De modo semelhante, usuários paramétricos podem ter permissão para acessar o banco de dados apenas por meio de aplicações predefinidas ou transações programadas, desenvolvidas para seu uso. Discutiremos sobre segurança do banco dc dados e autorização no Capítulo 30.

1.6.3 Oferecendo armazenamento persistente para objetos do

programa Os bancos dc dados podem ser usados para oferecer armazenamento persistente para objetos e estruturas dc dados do programa. Esse é um dos principais motivos para usar os sistemas de banco de dados orientados a objeto (ver Capítulo 12). Linguagens de programação normalmente possuem estruturas de dados complexas, como definições de struct ou de classe em C++ ou Java. Os valores das variáveis de programa ou objetos são descartados quando um programa termina, a menos que o programador os armazene explicitamente em arquivos permanentes, o que em geral envolve converter essas estruturas complexas em um formato adequado para armazenamento em arquivo. Quando é preciso ler esses dados mais uma vez, o programador precisa converter do formato de arquivo para a variável de pro­ grama ou estrutura de objeto. Os sistemas de banco de dados orientados a objeto são compatíveis com linguagens dc programação como C++ c Java,e o software de SGBD realiza automaticamente quaisquer conversões necessárias. Logo, um objeto complexo em C++ pode ser armazenado permanentemente em um SGBD orientado a objeto. Esse objeto é considerado persistente, pois sobrevive ao término da execução e pode ser recuperado mais tarde diretamente por outro programa. O armazenamento persistente de objetos e de estruturas de dados de programa é uma função importante dos sistemas de banco dc dados. Os sistemas tradicionais normalmente sofrem do chamado problema de divergência de impedância, pois as estruturas de dados fornecidas pelo SGBD eram incompatíveis com as estruturas da linguagem de programação. Os sistemas de banco de dados orientados a objeto normalmente oferecem compatibilidade da estrutura de dados com uma ou mais linguagens de programação orientadas a objeto.

Capítulo 1

Bancos de dados e usuários de banco de dados

1.6.4 Oferecendo estruturas de armazenamento e técnicas de pesquisa

para o processamento eficiente de consulta Sistemas dc banco dc dados precisam oferecer capacidades para executar con­ sultas e atualizações de modo eficiente. Como o banco dc dados normalmente é armazenado em disco, o SGBD precisa oferecer estruturas de dados e técnicas de pesquisa especializadas para agilizar a busca dos registros desejados no disco. Arquivos auxiliares, chamados índices, sâo comumentc utilizados para essa fina­ lidade. Os índices normalmente são baseados cm estruturas dc dados em árvore ou estruturas de dados em bash, que são modificadas de modo adequado para a pesquisa no disco. Para processar os registros de banco de dados necessários por uma consulta em particular, eles precisam ser copiados do disco para a memória principal. Portanto, o SGBD normalmente tem um módulo de buffering ou caching que mantém partes do banco dc dados nos buffers de memória principais. Em geral, o sistema operacional é responsável pelo buffering do disco para a memória. Porém, como o buffering de dados é essencial para o desempenho do SGBD, a maioria desses sistemas realiza seu próprio buffering. O módulo dc processamento c otimização dc consulta do SGBD é responsável por escolher um plano dc execução eficiente para cada consulta, com base nas estruturas dc armazenamento existentes. A escolha de quais índices criar c manter faz parte do projeto e ajuste do banco de dados físico, que é uma das responsabilidades da equipe de DBAs. Discutiremos sobre o processamento e a otimização de consulta na Parte 8 do livro.

1.6.5 Oferecendo backup e recuperação Um SGBD precisa oferecer facilidades para recuperar-se dc falhas dc hardware ou software. O subsistema de backup e recuperação do SGBD é responsável pela recuperação. Por exemplo, se o sistema de computador falhar no meio de uma transação de atualização complexa, o subsistema de recuperação é responsável por garantir que o banco de dados seja restaurado ao estado em que estava antes que a transação iniciasse a execução. O backup dc disco também é necessário no caso dc uma falha de disco catastrófica. Discutiremos a respeito do backup e recuperação no Capítulo 22.

1.6.6 Oferecendo múltiplas interfaces do usuário Como muitos tipos de usuários com diversos níveis de conhecimento técnico utilizam um banco de dados, um SGBD deve oferecer uma série dc interfaces do usuário. Estas incluem aplicativos para usuários móveis, linguagens de consulta para usuários casuais, interfaces de linguagem de programação para programadores de aplicação, formulários e códigos de comando para usuários paramétricos, além de interfaces controladas por menu c interfaces dc linguagem natural para usuários isolados. As interfaces no estilo dc formulários e controladas por menus normal­ mente são conhecidas como interfaces gráficas do usuário (GUIs — Graphical User Interfaces}. Existem muitas linguagens e ambientes especializados para especificar GUIs. Recursos para oferecer interfaces GUI Web para um banco de dados — ou um banco de dados habilitado para a web — também são muito comuns.

1.6.7 Representando relacionamentos complexos entre os dados Um banco de dados pode incluir muitas variedades de dados que estão inter-relacionados de diversas maneiras. Considere o exemplo mostrado na Figura 1.2. O

19

20 Sistemas de banco de dados registro de ‘Braga’ no arquivo ALUNO está relacionado a quatro registros no arquivo REGISTROJMOTA. De modo semelhante, cada registro de turma está relacionado a um registro de curso e a uma série de REGISTRO_NOTA — um para cada aluno que concluiu a turma. Um SGBD precisa ter a capacidade de representar uma série de relaciona­ mentos complexos entre os dados, definir novos relacionamentos à medida que eles surgem e recuperar e atualizar dados relacionados de modo fácil e eficaz.

1.6.8 Impondo restrições de integridade A maioria das aplicações de banco de dados possui certas restrições dc integri­ dade que devem ser mantidas para os dados. Um SGBD deve oferecer capacidades para definir e impor essas restrições. O tipo mais simples de restrição de integridade envolve especificar um tipo dc dado para cada item dc dados. Por exemplo, na Figura 1.3, especificamos que o valor do item dc dados Tipo_aluno dentro dc cada registro de ALUNO deve ser um inteiro dc um dígito e que o valor de Nome precisa ser uma string (cadeia de caracteres) de até 30 caracteres alfabéticos. Para restringir o valor de Tipo_aluno entre 1 e 5, seria preciso uma restrição adicional, que não aparece no catálogo atual. Um tipo de restrição mais complexo, que ocorre com frequên­ cia, envolve especificar que um registro em um arquivo deve estar relacionado a registros cm outros arquivos. Por exemplo, na Figura 1.2, podemos especificar que cada registro de turma deve estar relacionado a um registro de disciplina. Isso é conhecido como restrição de integridade referencial. Outro ripo de restrição espe­ cifica unicidade sobre valores de item de dados, como cada registro de curso deverá ter um valor único para Numero_disciplina. Isso é conhecido como uma restrição de chave ou unicidade. Essas restrições são derivadas do significado ou da semântica dos dados e do minim undo que eles representam. E responsabilidade dos projetistas do banco de dados identificar restrições de integridade durante o projeto. Algumas restrições podem ser especificadas ao SGBD e impostas automaticamente. Outras podem ter de ser verificadas por programas de atualização ou no momento da entrada de dados. Normalmente, para aplicações grandes, é comum chamar essas restrições de regras de negócio. Um item de dados pode ser inserido erroneamente e ainda satisfazer as restri­ ções de integridade especificadas. Por exemplo, se um aluno recebe uma nota ‘A’, mas uma nota ‘C’ é inserida no banco de dados, o SGBD não consegue descobrir esse erro automaticamente, pois ‘C’ é um valor válido para o tipo de dados Nota. Esses erros de entrada dc dados só podem ser descobertos manualmcnte (quando o aluno receber a nota c reclamar) e corrigidos posteriormente, atualizando o banco de dados. Porém, uma nota ‘Z * seria rejeitada automaticamente pelo SGBD, pois ‘Z’ não é um valor válido para o tipo de dado Nota. Quando discutirmos sobre cada modelo dc dados nos próximos capítulos, vamos apresentar regras que pertencem a esse modelo implicitamente. Por exemplo, no modelo Entidadc-Rclacionamcnto, no Capítulo 3, um relacionamento deverá envolver pelo menos duas entidades. Regras que pertencem a um modelo de dados específico são chamadas de regras inerentes ao modelo de dados.

7.6.9 Permitindo dedução e ações usando regras e gatilhos

Alguns sistemas de banco de dados oferecem capacidades para definir regras de dedução a fim de inferir novas informações com base nos fatos armazenados no banco de dados. Esses sistemas são chamados sistemas de banco de dados deduti­ vos. Por exemplo, pode haver regras complexas na aplicação do minimundo para determinar quando um aluno está em época de provas. Estas podem ser especifica­ das declarativamente como regras que, quando compiladas c mantidas pelo SGBD,

Capítulo 1

Bancos de dados e usuários de banco de dados 21

podem determinar todos os alunos em época de provas. Em um SGBD tradicional, um código de programa de procedimento explícito teria de ser escrito para dar suporte a tais aplicações. Porém, se as regras do minimundo mudarem, geralmente é mais conveniente mudar as regras de dedução declaradas do que recodifícar programas procedurais. Nos sistemas de banco de dados relacionais de hoje, é possível asso­ ciar gatilhos (ou triggers) a tabelas. Um gatilho é uma forma de regra ativada por atualizações na tabela, que resulta na realização dc algumas operações adicionais em algumas outras tabelas, envio de mensagens e assim por diante. Procedimentos mais elaborados para impor regras são popularmente chamados de procedimentos armazenados (ou stored procedures); eles se tornam parte da definição geral de banco de dados e são chamados apropriadamente quando cerras condições são atendidas. A funcionalidade mais poderosa é fornecida por sistemas dc banco dc dados ativos, que oferecem regras ativas que automaticamente iniciam ações quando ocorrem certos eventos e condições (veja, no Capítulo 26, introduções aos bancos de dados ativos, na Seção 26.1, e bancos de dados dedutivos, na Seção 26.5).

1.6.10 Implicações adicionais do uso da abordagem de banco de dados Esta seção discute algumas implicações adicionais do uso da abordagem de banco de dados, que podem beneficiar a maioria das organizações. Potencial para garantir padrões. A abordagem dc banco de dados permite que o DBA defina e garanta padrões entre os usuários em uma grande organização. Isso facilita a comunicação e a cooperação entre vários departamentos, projetos e usuá­ rios dentro da organização. Podem ser definidos padrões para nomes e formatos dos elementos de dados, formatos de exibição, estruturas de relatório, terminologia e assim por diante. O DBA pode garantir padrões em um ambiente de banco dc dados centralizado mais facilmente do que em um ambiente no qual cada grupo dc usuários tem controle dos seus próprios arquivos dc dados c software. Tempo reduzido para desenvolvimento de aplicação. Uma característica importante de venda da abordagem de banco de dados é que o desenvolvimento de uma nova aplicação — como a recuperação de certos dados para a impressão de um novo relatório — leva muito pouco tempo. Projetar e implementar um grande banco de dados multiusuário do zero pode levar mais tempo que escrever uma única apli­ cação dc arquivo especializada. Porém, quando um banco de dados está pronto e funcionando, gcralmcntc é preciso muito menos tempo para criar novas aplicações usando recursos do SGBD. Estima-se que o tempo de desenvolvimento usando um SGBD seja um sexto a um quarto daquele para um sistema de arquivo tradicional.

Flexibilidade. Pode ser necessário mudar a estrutura dc um banco dc dados à medida que os requisitos mudam. Por exemplo, pode aparecer um novo grupo dc usuários precisando de informações atualmente nào incluídas no banco de dados. Em resposta, pode ser preciso acrescentar um arquivo ou estender os elementos de dados cm um arquivo existente. Os SGBDs modernos permitem certos tipos de mudanças evolutivas na estrutura sem afetar os dados armazenados e os programas de aplicação existentes.

Disponibilidade de informações atualizadas. Um SGBD toma o banco dc dados dis­ ponível a todos os usuários. Assim que a atualização dc um usuário é aplicada, todos os outros usuários podem ver essa atualização imediatamente. Essa disponibilidade de informações atualizadas é essencial para muitas aplicações de processamento de transação, como nos bancos de dados de sistemas de reserva ou bancários, e ela é pos­ sibilitada pelos subsistemas dc controle de concorrência e recuperação dc um SGBD. Economias de escala. A abordagem dc SGBD permite a consolidação dc dados c aplicações, reduzindo assim a quantidade dc sobreposição desperdiçada entre

22 Sistemas de banco de dados as atividades do pessoal de processamento de dados em diferentes projetos ou departamentos, bem como as redundâncias entre as aplicações. Isso permite que a organização inteira invista em processadores, dispositivos de armazenamento ou mecanismos de rede mais poderosos, em vez de cada departamento ter de comprar seu próprio equipamento (menor desempenho). Isso reduz os custos gerais de ope­ ração e gerenciamento.

1.7 Uma breve história das aplicações de banco de dados Agora, vamos apresentar uma breve visão geral histórica das aplicações que usam SGBDs e como essas aplicações forneceram o incentivo para novos tipos de sistemas de banco de dados.

1.7.1 Antigas aplicações de banco de dados usando sistemas

hierárquicos e de rede Muitas aplicações de banco de dados antigas mantinham registros em grandes organizações, como corporações, universidades, hospitais e bancos. Em muitas des­ sas aplicações, havia grandes quantidades de registros com estrutura semelhante. Por exemplo, em uma aplicação de universidade, informações semelhantes seriam mantidas para cada aluno, cada curso, cada registro de nota e assim por diante. Também havia muitos tipos de registros e muitos inter-relacionamentos entre eles. Um dos principais problemas com os sistemas de banco de dados antigos era a mistura de relacionamentos conceituais com o armazenamento e o posicionamento físico dos registros no disco. Logo, esses sistemas não ofereciam capacidades suficien­ tes para abstração de dados e independência entre dados e programas. Por exemplo, os registros de notas de determinado aluno poderíam ser armazenados fisicamente próximos do registro do aluno. Embora isso fornecesse um acesso muito eficiente para as consultas e transações originais que o banco de dados foi projetado para lidar, não oferecia flexibilidade suficiente para acessar registros de modo eficiente quando novas consultas e transações fossem identificadas. Em particular, novas consultas que exigiam uma organização de armazenamento diferente para o pro­ cessamento eficiente eram muito difíceis de implementar de modo eficaz. Também era muito trabalhoso reorganizar o banco de dados quando eram feitas mudanças nos requisitos da aplicação. Outra deficiência dos sistemas antigos era que eles ofereciam apenas interfaces da linguagem de programação. Isso tomava a implementação de novas consultas e transações demorada e cara, pois novos programas tinham de ser escritos, testados e depurados. A maioria desses sistemas de banco de dados era implementada em computadores mainframe grandes c caros, começando em meados da década dc 1960 e continuando pelos anos 1970 e 1980. Os principais tipos dos primeiros sis­ temas eram baseados em três paradigmas principais: sistemas hierárquicos, sistemas baseados em modelo de rede e sistemas de arquivo invertidos.

1.7.2 Oferecendo abstração de dados e flexibilidade de aplicação com

bancos de dados relacionais Os bancos de dados relacionais foram propostos originalmente para separar o armazenamento físico dos dados de sua representação conceituai e para fornecer uma base matemática para a representação e a consulta dos dados. O modelo de

Capítulo 1

Bancos de dados e usuários de banco de dados 23

dados relacionai também introduziu linguagens de consulta de alto nível, que forne­ ciam uma alternativa às interfaces de linguagem de programação, tornando muito mais rápido a escrita de novas consultas. A representação relacionai dos dados é semelhante ao exemplo que apresentamos na Figura 1.2. Os sistemas relacionais visavam inicialmente às mesmas aplicações dos sistemas mais antigos, e forneciam flexibilidade para desenvolver novas consultas rapidamente e reorganizar o banco dc dados à medida que os requisitos mudavam. Logo, a abstração de dados e a independência entre dados e programas foram muito melhoradas em comparação com os sistemas anteriores. Os sistemas relacionais experimentais, desenvolvidos no final da década de 1970, e os sistemas de gerenciamento de banco de dados relacionais (SGBDR), introduzidos na década de 1980, eram muito lentos, pois não usavam ponteiros de armazenamento físico ou posicionamento de registro para acessar registros de dados relacionados. Com o desenvolvimento de novas técnicas de armazenamento e indexação e melhorias no processamento e otimização de consulta, seu desempenho melhorou. Por fim, os bancos de dados relacionais se tornaram o tipo de sistema de banco de dados dominante para aplicações tradicionais de banco de dados. Agora existem bancos dc dados relacionais para quase todos os tipos dc computadores, desde os menores computadores pessoais até os grandes servidores.

1.7.3 Aplicações orientadas a objeto e a necessidade de bancos de

dados mais complexos O surgimento de linguagens de programação orientadas a objeto no final da década de 1980 e a necessidade de armazenar e compartilhar objetos complexos e estruturados levou ao desenvolvimento de bancos de dados orientados a objeto (BDOOs). Inicialmente, os BDOOs eram considerados como concorrentes dos bancos de dados relacionais, pois forneciam estruturas de dados mais gerais. Eles também incorporavam muitos dos paradigmas úteis orientados a objeto, como tipos de dados abstratos, encapsulamento de operações, herança e identidade de objeto. Porém, a complexidade do modelo e a falta de um padrão inicial contribuíram para seu uso limitado. Eles agora são usados principalmente em aplicações especializadas, como projeto dc engenharia, publicação dc multimídia c sistemas dc manufatura. Apesar das expectativas dc que eles terão um grande impacto, sua penetração geral no mercado de produtos de banco de dados permanece baixa. Além disso, muitos conceitos de orientação a objeto foram incorporados nas versões mais recentes dos SGBDs relacionais, levando a sistemas de gerenciamento de banco de dados objeto-rclacionais, conhecidos como SGBDORs.

1.7.4 Intercâmbio de dados na web para e-commerce usando XML A World Wide Web oferece uma grande rede de computadores interconectados. Os usuários podem criar páginas estáticas usando uma linguagem de publicação na web, como HyperText Markup Language (HTML), e armazenar esses documentos em servidores web, em que outros usuários (clientes) podem acessá-los e visualiza-los através de navegadores web. Os documentos podem ser vinculados por meio de hyperlinks, que são ponteiros para outros documentos. A partir da década de 1990, o comércio eletrônico (e-commerce) surgiu como uma importante aplicação web. Grande parte da informação crítica sobre páginas web de e-commerce consiste em dados extraídos dinamicamente de SGBDs, como informações de voos, preços e disponibilidade dc produtos. Diversas técnicas foram desenvolvidas para permitir o intercâmbio de dados extraídos na web para exibição em páginas. A eXtended

24 Sistemas de banco de dados

Markup Language (XML,em português, linguagem de marcação extensível) é um padrão para intercâmbio entre diversos tipos de bancos de dados e páginas web. A XML combina conceitos dos modelos usados nos sistemas de documentos com os conceitos de modelagem de banco de dados. O Capítulo 13 é dedicado a uma visão geral da XML.

1.7.5 Estendendo as capacidades do banco de dados para novas aplicações O sucesso dos sistemas de banco de dados nas aplicações tradicionais encorajou os desenvolvedores de outros tipos dc aplicações a tentarem utilizá-los. Essas apli­ cações tradicionalmente usavam suas próprias estruturas especializadas dc arquivo e dados. Os sistemas de banco de dados agora oferecem extensões para dar melhor suporte aos requisitos especializados para algumas dessas aplicações. A seguir estão alguns exemplos dessas aplicações: ■ Aplicações científicas que armazenam grandes quantidades dc dados resultantes dc experimentos científicos cm áreas como física dc alta energia, mapeamento do genoma humano e descoberta de estruturas de proteínas. ■ Armazenamento c recuperação dc imagens, incluindo notícias cscancadas e fotografias pessoais, imagens fotográficas dc satélite c imagens de procedimentos médicos, como raio X c IRMs (imagens por ressonância magnética). ■ Armazenamento c recuperação de vídeos, como filmes, c clipes dc vídeo dc notí­ cias ou câmeras digitais pessoais. ■ Aplicações de mineração dc dados (ou data mining), que analisam grandes quantidades de dados procurando as ocorrências de padrões ou relacionamen­ tos específicos, e para identificar padrões incomuns em áreas como detecção de fraudes com cartões de crédito. ■ /Yplicações espaciais, que armazenam e analisam as localizações espaciais de dados, como informações de clima, mapas usados em sistemas de informações geográficas e em sistemas de navegação de automóveis. ■ /Xplicações de série temporal, que armazenam informações como dados econô­ micos em pontos regulares no tempo, como vendas diárias e valores mensais do Produto Interno Bruto (PIB).

Logo ficou claro que os sistemas relacionais básicos não eram muito adequados para muitas dessas aplicações, em geral por um ou mais dos seguintes motivos: ■ Estruturas de dados mais complexas eram necessárias para modelar a aplicação do que a representação relacionai simples. ■ Novos tipos de dados eram necessários além dos tipos básicos numéricos e de cadeia de caracteres. ■ Novas operações e construções de linguagem de consulta eram necessárias para manipular os novos tipos dc dados. ■ Novas estruturas de armazenamento e indexação eram necessárias para a pesquisa eficiente sobre os novos tipos de dados.

Isso levou os desenvolvedores de SGBD a acrescentarem funcionalidades aos seus sistemas. Algumas funcionalidades eram de uso geral, como a incorporação de conceitos dos bancos de dados orientados a objeto aos sistemas relacionais. Outras funcionalidades eram de uso especial, na forma de módulos opcionais que poderíam ser usados para aplicações específicas. Por exemplo, os usuários poderíam comprar

Capítulo 1

Bancos de dados e usuários de banco de dados 25

um módulo de série de tempo para usar com seu SGBD relacionai para sua aplicação de série de tempo.

1.7.6 Surgimento de sistemas de armazenamento big data e bancos de dados NOSQL Na primeira década do século XXI, a proliferação de aplicações e plataformas, como sites dc redes sociais, grandes empresas dc comércio eletrônico, índices dc pesquisa na web e armazenamento/backup em nuvem, levou a um aumento na quan­ tidade de dados armazenados em grandes bancos de dados e servidores robustos. Novos tipos dc sistemas foram necessários para gerenciar esses imensos bancos dc dados — sistemas que proporcionariam busca c recuperação rápidas, bem como armazenamento confiável e seguro de tipos não tradicionais dc dados, como posta­ gens de redes sociais e tuítes. Alguns dos requisitos desses novos sistemas não eram compatíveis com SGBDs relacionais SQL (SQL é uma padronização do modelo de dados e da linguagem para bancos de dados relacionais). O termo NOSQL é geralmente interpretado como Não Apenas SQL (Not Only SQL), o que significa que, cm sistemas que gerenciam grandes quantidades dc dados, alguns deles são armazenados usando sistemas SQL, enquanto outros serão armazenados usando o NOSQL, dependendo dos requisitos da aplicação.

1.8 Quando não usar um SGBD Apesar das vantagens de usar um SGBD, existem algumas situações em que um SGBD pode envolver custos adicionais desnecessários, que não aconteceriam no processamento de arquivos tradicional. Os custos adicionais do uso de um SGBD devem-se aos seguintes fatores:

■ Alto investimento inicial em hardware, software e treinamento. ■ A generalidade que um SGBD oferece para a definição c o processamento dc dados. ■ Esforço adicional para oferecer funções dc segurança, controle dc concorrência, recuperação e integridade. Portanto, pode ser mais desejável usar arquivos comuns sob as seguintes circunstâncias:

■ Aplicações de banco de dados simples e bem definidas, para as quais não se esperam muitas mudanças. ■ Requisitos rigorosos, dc tempo real, para alguns programas dc aplicação, que podem não ser atendidos cm decorrência da sobrecarga dc operações executadas pelo SGBD. ■ Sistemas embarcados com capacidade dc armazenamento limitada, nos quais um SGBD dc uso geral não seria apropriado. ■ Nenhum acesso de múltiplos usuários aos dados. Certos setores e aplicações decidiram não usar SGBDs de uso geral. Por exemplo, muitas ferramentas de projeto auxiliado por computador (CAD — computer-aided design) usadas por engenheiros civis e mecânicos possuem software proprietário para gerenciamento dc arquivos e dados, preparado para as manipulações internas dos desenhos e objetos 3D. Dc modo semelhante, sistemas de comunicação e comutação projetados por empresas como AT&T foram manifestações iniciais do software de banco de dados que foi preparado para executar de forma muito rápida, com dados

26 Sistemas de banco de dados organizados hierarquicamente, para agilizar o acesso e o roteamento das chamadas. De modo semelhante, implementações dos Sistemas de Informações Geográficas (SIG) normalmente usam os próprios esquemas de organização de dados, a fim de implementar, de modo eficiente, funções relacionadas ao processamento de mapas, contornos físicos, linhas, polígonos e assim por diante.

1.9 Resumo Neste capítulo, definimos um banco de dados como uma coleção de dados relacio­ nados, em que dados significa fatos gravados. Um banco de dados típico representa algum aspecto do mundo real e é usado para fins específicos por um ou mais grupos de usuários. Um SGBD c um pacote de software generalizado para implementar e manter um banco dc dados computadorizado. Juntos, o banco dc dados c o software formam um sistema de banco de dados. Identificamos várias características que distinguem a abordagem de banco de dados das aplicações tradicionais de proces­ samento dc arquivo, e discutimos as principais categorias dc usuários dc banco dc dados, ou os atores em cena. Observamos que, além dos usuários, existem várias categorias de pessoal de suporte, ou trabalhadores dos bastidores, em um ambiente de banco de dados. Apresentamos uma lista de capacidades que devem ser fornecidas pelo software de SGBD ao DBA, aos projetistas de banco de dados e aos usuários finais para ajudá-los a projetar, a administrar e a usar um banco de dados. Depois, mostramos uma rápida perspectiva histórica da evolução das aplicações dc banco dc dados. Indicamos o recente crescimento rápido das quantidades e dos tipos dc dados que deverão ser armazenados nos bancos de dados, e discutimos o surgimento de novos sistemas para tratar de aplicações “big data”. Por fim, discutimos os custos adicionais do uso de um SGBD e algumas situações em que sua utilização pode não ser vantajosa.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

1.1.

1.2. 1.3. 1.4. 1.5.

1.6. 1.7.

Defina os seguintes termos: dados, banco de dados, SGBD, sistema de banco de dados, catálogo de banco de dados, independência entre dados e programas, visão do usuário, DBA, usuário final, transação programada, sistema de banco de dados dedutivo, objeto persistente, metadados e aplicação de processamento de transação. Quais os quatro tipos principais de ações que envolvem bancos de dados? Discuta cada ripo brevemente. Discuta as principais características da abordagem de banco de dados e como ela difere dos sistemas dc arquivo tradicionais. Quais são as responsabilidades do DBA e dos projetistas dc banco dc dados? Quais são os diferentes tipos de usuários finais do banco de dados? Discuta as principais atividades de cada um. Discuta as capacidades que devem ser fornecidas por um SGBD. Discuta as diferenças entre sistemas dc banco de dados c sistemas de recupe­ ração de informações.

Capítulo 1

Bancos de dados e usuários de banco de dados 27

EXERCÍCIOS -----------------------------------------------------------------------------------------------

1.8.

1.9. 1.10.

1.11. 1.12.

1.13. 1.14.

Identifique algumas operações informais dc consulta e atualização que você esperaria aplicar ao banco de dados mostrado na Figura 1.2. Qual é a diferença entre redundância controlada e não controlada? Ilustre com exemplos. Especifique todos os relacionamentos entre os registros do banco de dados mostrado na Figura 1.2. Mostre algumas visões adicionais que podem ser necessárias a outros grupos de usuários para o banco de dados mostrado na Figura 1.2. Cite alguns exemplos de restrições de integridade que você acredita que possam se aplicar ao banco de dados mostrado na Figura 1.2. Dê exemplos de sistemas nos quais pode fazer sentido usar o processamento dc arquivos tradicional em vez da abordagem dc banco de dados. Considere a Figura 1.2. a. Se o nome do departamento ‘CC' (Ciência da Computação) mudar para ‘CCES’ (Ciência da Computação e Engenharia de Software) e o prefixo correspondente para o número da disciplina também mudar, identifique as colunas no banco de dados que precisariam ser atualizadas. b. Você consegue reestruturar as colunas nas tabelas DISCIPLINA, TURMA e PRE_REQUISITO de modo que somente uma coluna precise ser atualizada?

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

A edição dc outubro dc 1991 de Communications of the ACM c Kim (1995) incluem vários artigos descrevendo SGBDs da próxima geração; muitos dos recursos de banco de dados discutidos no passado agora estão disponíveis comercialmente. A edição dc março dc 1976 de ACM Computing Surveys oferece uma introdução inicial aos sistemas dc banco dc dados e pode oferecer uma perspectiva histórica para o leitor interessado. Nos capítulos que discutem cada tópico com mais detalhes, incluiremos referências a outros conceitos, sistemas e aplicações que apresentamos neste capítulo.

Conceitos e arquitetura do sistema de banco de dados arquitetura dos SGBDs tem evoluído desde os primeiros sistemas monolíti­ cos, nos quais todo o software SGBD era um sistema altamente integrado, até os mais modernos, que têm um projeto modular, com arquitetura de sistema cliente/servidor. O recente crescimento na quantidade de dados exigindo armazenamento levou a sistemas dc banco dc dados com arquiteturas distribuídas, compostas dc milhares de computadores que gerenciam os armazenamentos de dados. Essa evolução espelha as tendências na computação, em que grandes computadores mainframe centralizados estão sendo substituídos por centenas de estações de tra­ balho distribuídas c computadores pessoais conectados por redes dc comunicações a vários tipos dc máquinas servidoras — servidores web, servidores de banco de dados, servidores de arquivos, servidores de aplicações, e assim por diante. Os atuais ambientes de computação em nuvem consistem em milhares de grandes servidores que gerenciam big data para usuários da web. Em uma arquitetura básica de SGBD cliente/servidor, a funcionalidade do sis­ tema é distribuída entre dois tipos de módulos.1 O módulo cliente normalmcnte é projetado para executar em um dispositivo móvel, estação dc trabalho ou compu­ tador pessoal (PC). Em geral, os programas de aplicação e interfaces com o usuário que acessam o banco de dados executam no módulo cliente. Logo, esse módulo se encarrega da interação do usuário c oferece interfaces amigáveis, como aplicativos para dispositivos móveis, ou GUIs (interfaces gráficas do usuário) com base em formulário ou menu, para PCs. O outro tipo dc módulo, chamado módulo servi­ dor, normalmente é responsável pelo armazenamento de dados, acesso, pesquisa e outras funções. Discutiremos sobre arquiteturas cliente/servidor com mais detalhes

A

1 Conforme veremos na Seção 2.5, existem variações sobre essa simples arquitetura cliente/servidor em

duas caniadas.

30 Sistemas de banco de dados na Seção 2.5. Primeiro, temos de estudar mais os conceitos básicos, que nos darão melhor conhecimento das arquiteturas de banco de dados modernas. Neste capítulo, apresentamos a terminologia e os conceitos básicos que serão usados no decorrer do livro. A Seção 2.1 discute os modelos de dados e define os conceitos de esquemas e instâncias, que são fundamentais para o estudo dos sistemas de banco de dados. Depois, discutimos a arquitetura do SGBD de três esquemas e a independência de dados na Seção 2.2; isso oferece um ponto de vista do usuário sobre o que um SGBD deve realizar. Na Seção 2.3, descrevemos os tipos dc interfaces e linguagens que normalmente são fornecidas por um SGBD. A Seção 2.4 discute o ambiente de software de um sistema de banco de dados. A Seção 2.5 oferece uma visão geral dc vários tipos dc arquiteturas clicntc/servidor. Por fim, a Seção 2.6 apresenta uma classificação dos tipos dc pacotes dc SGBD. A Seção 2.7 apresenta um resumo do capítulo. O material nas seções 2.4 a 2.6 oferece conceitos mais detalhados, que podem ser considerados suplementares ao material introdutório básico.

2.1 Modelos de dados, esquemas e instâncias Uma característica fundamental da abordagem de banco de dados é que ela ofe­ rece algum nível de abstração. /X abstração de dados geralmente se refere à supressão de detalhes de organização e armazenamento, destacando os recursos essenciais para melhor conhecimento desses dados. Uma das principais características da abordagem dc banco dc dados c possibilitar a abstração, dc modo que diferentes usuários possam percebê-los em seu nível de detalhe preferido. Um modelo de dados — uma coleção de conceitos que podem ser usados para descrever a estrutura de um banco de dados — oferece os meios necessários para alcançar essa abstração.2 Com estrutura de uni banco de dados, queremos dizer os tipos, os relacionamentos e as restrições que se aplicam aos dados. A maioria dos modelos dc dados também inclui um conjunto dc operações básicas para especificar recuperações e atualizações no banco de dados. /Uém das operações básicas fornecidas pelo modelo de dados, está se tomando mais comum incluir conceitos no modelo de dados para especificar o aspecto dinâmico ou comportamento de uma aplicação de banco de dados. Isso permite ao projetista especificar um conjunto de operações válidas, definidas pelo usuário, sobre os objetos do banco de dados.3 Um exemplo de uma operação definida pelo usuário podería ser CALCULA_MEDIA, que pode ser aplicada a um objeto ALUNO. Por sua vez, operações genéricas para inserir, excluir, modificar ou recuperar qualquer tipo de objeto normalmente estão incluídas nas operações básicas do modelo de dados. Conceitos para especificar o comportamento são fundamentais para os modelos de dados orientados a objeto (ver Capítulo 12), mas também estão sendo incorporados em modelos de dados mais tradicionais. Por exemplo, modelos objeto-relacionais (ver Capítulo 12) estendem o modelo relacionai básico para incluir tais conceitos, entre outros. No modelo de dados relacionai básico, existe um recurso para conectar um comportamento às relações, na forma dc módulos de armazenamento persistente, popularmente conhecidos como procedimentos armazenados ou stored procedures (ver Capítulo 10).

2 Às vezes a palavra modelo é usada para indicar uma descrição de banco de dados específica, ou esquema — por exemplo, o modelo de dados de marketing. Não usaremos essa interpretação. ’ A inclusão de conceitos para descrever um comportamento reflete uma tendência por meio da qual as atividades do projeto do banco dc dados c do projeto dc software estão, cada vez mais, sendo combinadas em uma única atividade. Tradicionalmente, especificar um comportamento é algo associado ao projeto de software.

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 31

2.1.1 Categorias de modelos de dados Muitos modelos de dados foram propostos, e podemos classificá-los de acordo com os tipos de conceitos que eles utilizam para descrever a estrutura do banco de dados. Modelos de dados de alto nível ou conceituais oferecem conceitos próximos ao modo como muitos usuários percebem os dados, enquanto os modelos dc dados de baixo nível ou físicos oferecem conceitos que descrevem os detalhes de como os dados são armazenados no computador, em geral em discos magnéticos. Os conceitos oferecidos pelos modelos de dados físicos costumam ser voltados para especialistas de computadores, não para usuários finais. Entre esses dois extremos está uma classe de modelos dc dados representativos (ou dc implementação),4 que oferece conceitos que podem ser facilmente entendidos pelos usuários finais, mas que não está muito longe do modo como os dados são organizados e armazenados no computador Modelos de dados representativos ocultam muitos detalhes do armazenamento de dados em disco, mas podem ser implementados diretamente em um sistema de computador. Os modelos dc dados conceituais utilizam conceitos como entidades, atributos e relacionamentos. Uma entidade representa um objeto ou conceito do mundo real, como um funcionário ou um projeto do minimundo que é descrito no banco de dados. Um atributo representa alguma propriedade de interesse que descreve melhor uma entidade, como o nome ou o salário do funcionário. Um relacionamento entre duas ou mais entidades representa uma associação entre elas — por exemplo, um relacio­ namento trabalha-cm, entre um funcionário c um projeto. O Capítulo 3 apresentará o modelo cntidade-rclacionamento — um modelo de dados conceituai popular dc alto nível. O Capítulo 4 descreverá abstrações adicionais usadas para a modelagem avançada, como generalização, especialização e categorias (tipos de união). Os modelos de dados representativos ou dc implementação são os usados com mais frequência nos SGBDs comerciais tradicionais. Estes incluem o amplamente utilizado modelo de dados relacionai, bem como os chamados modelos de dados legados — os modelos de rede e hierárquicos — que foram bastante usados no passado. A Parte 3 do livro é dedicada ao modelo de dados relacionai e suas res­ trições, operações e linguagens. O padrão SQL para bancos de dados relacionais será descrito nos capítulos 6 e 7. Os modelos de dados representativos mostram os dados usando estruturas de registro e, portanto, às vezes são denominados modelos de dados baseados em registro. Podemos considerar o modelo de dados dc objeto como um exemplo de uma nova família dc modelos dc dados dc implementação de nível mais alto e que são mais próximos dos modelos de dados conceituais. Um padrão para bancos de dados de objeto, chamado modelo de objeto ODMG, foi proposto pelo grupo de gerenciamento de dados de objeto (ODX1G — Object Data Management Group). O Capítulo 12 descreve as características gerais dos bancos de dados de objeto e o padrão proposto do modelo de objeto. Os modelos de dados de objeto também são frequentemente utilizados como modelos conceituais de alto nível, em particular no domínio da engenharia de software. Os modelos de dados físicos descrevem como o dado é armazenado como arqui­ vos no computador, com informações como formatos de registro, ordenações de registro e caminhos de acesso. Um caminho de acesso é uma estrutura que torna efi­ ciente a busca por registros de um banco de dados em particular, como indexação ou hashing. Discutiremos as técnicas dc armazenamento físico e as estruturas de acesso nos capítulos 16 e 17. Um índice é um exemplo de um caminho de acesso que permite o acesso direto aos dados usando um termo de índice ou uma palavra-chave. Ele é 4 O termo modelo de dados de implementação nào é um termo padrão; ele foi apresentado para nos referirmos aos modelos de dados disponíveis nos sistemas de banco de dados comerciais.

32 Sistemas de banco de dados semelhante ao índice no final deste livro, com a exceção de que pode ser organizado de forma linear, hierárquica (estruturada em árvore) ou de alguma outra maneira. Outra classe de modelos de dados é conhecida como modelos de dados autodescritivos. O armazenamento de dados nos sistemas baseados nesses modelos combina a descrição dos dados com seus próprios valores. Nos SGBDs tradicionais, a descri­ ção (esquema) fica separada dos dados. Esses modelos incluem XML (ver Capítulo 12), além de muitos dos armazenamentos dc chavc-valor c sistemas NOSQL (ver Capítulo 24), que foram criados rcccntemente para gerenciar big data.

2.1.2 Esquemas, instâncias e estado do banco de dados Em um modelo de dados, é importante distinguir entre a descrição do banco de dados e o próprio banco de dados. A descrição de um banco de dados é chamada de esquema do banco dc dados, que c especificado durante o projeto c não se espera que mude com frequência.' A maioria dos modelos de dados possui convenções para representar esquemas como diagramas.*6 A representação de um esquema é chamada de diagrama de esquema. A Figura 2.1 mostra um diagrama de esquema para o banco de dados da Figura 1.2; o diagrama apresenta a estrutura de cada tipo de registro, mas não as instâncias reais dos registros. Chamamos cada objeto no esquema — por exemplo, ALUNO ou DISCIPLINA — dc construtor do esquema. Um diagrama de esquema representa apenas alguns aspectos de um esquema, como os nomes de tipos de registro e itens de dados, e alguns tipos de restrições. Outros aspectos não são especificados no diagrama de esquema; por exemplo, a Figura 2.1 não mostra nem o tipo dc dado de cada item nem os relacionamentos entre os diversos arquivos. Xluitos tipos dc restrições não são apresentados nos dia­ gramas de esquema. Uma restrição do tipo alunos prestes a se formarem em ciência da computação precisam realizar o curso CC1310 antes do final de seu segundo ano é muito difícil de representar em forma de diagrama. ALUNO______________________________________________________ Nome I Numero aluno I Típo aluno I Curso

DISCIPLINA Nome disciplina

Numero disciplina

Departamento

Créditos

PRE_REQUISITO____________________________________ Numero disciplina [ Numero pre requisito

TURMA ldentificador turma Figura 2.1 Diagrama de esquema para o banco de dados da Figura 1.2.

Numero disciplina

Semestre

Ano

Professor

REGISTRO NOTA Numero aluno

Identificador turma

Nota

' Xfudanças no esquema normalmente são necessárias à medida que os requisitos das aplicações do banco de dados mudam. A maioria dos sistemas de banco de dados inclui operações para permitir mudanças de esquema.

6 Em terminologia dc banco dc dados, cm inglês, c comum usar schemas como plural para schema, embora schemata seja a forma apropriada no plural. A palavra scheme também é usada para se referir a um esquema.

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 33

Os dados reais armazenados em um banco de dados podem mudar com bastante frequência. Por exemplo, o banco de dados mostrado na Figura 1.2 muda toda vez que acrescentamos um novo aluno ou inserimos uma nova nota. Os dados no banco de dados em determinado momento no tempo são chamados de estado ou instante (snapshot) do banco de dados. Também sào chamados de conjunto atual de ocorrências ou instâncias no banco de dados. Em determinado estado do banco de dados, cada construtor dc esquema tem o próprio conjunto de instâncias atuais; por exemplo, o construtor ALUNO terá o conjunto de entidades de cada aluno (registros) como suas instâncias. Muitos estados de banco de dados podem ser construídos para corresponder a um esquema em particular. Toda vez que inserimos ou excluímos um registro ou alteramos o valor de um item de dados em um registro, mudamos de um estado do banco de dados para outro. A distinção entre esquema e estado de banco de dados é muito importante. Quando definimos um novo banco de dados, especificamos seu esquema apenas para o SGBD. Nesse ponto, o estado correspondente é o estado vazão., sem dados. Obtemos o estado inicial do banco de dados quando ele c populado ou carregado com os dados iniciais. Daí em diante, toda vez que uma operação de atualização é aplicada ao banco dc dados, obtemos outro estado. Em qualquer ponto no tempo, o banco dc dados tem um estado atual.7 O SGBD é parcialmcnte responsável por garantir que todo estado do banco de dados seja um estado válido — ou seja, um estado que satisfaça a estrutura e as restrições especificadas no esquema. Logo, especificar um esquema correto para o SGBD é extremamente importante, c o esquema deve ser projetado com extremo cuidado. O SGBD armazena as descrições das construções e restrições do esquema — também denominadas metadados — no catálogo do SGBD, de modo que o software do SGBD possa recorrer ao esquema sempre que precisar. O esquema às vezes é chamado de intenção, e um estado do banco de dados é chamado de extensão do esquema. Embora, como já mencionamos, o esquema não deva mudar com frequência, não c raro que as mudanças ocasionalmcntc precisem ser aplicadas ao esquema, à medida que os requisitos da aplicação mudam. Por exemplo, podemos decidir que outro item de dados precisa ser armazenado para cada registro em um arquivo, como a inclusão de Data, nascimento ao esquema ALUNO da Figura 2.1. Isso é conhecido como evolução do esquema. A maioria dos SGBDs modernos possui algumas ope­ rações para evolução de esquema que podem ser aplicadas enquanto o banco de dados está em funcionamento.

2.2 Arquitetura de três esquemas e independência de dados Três das quatro características importantes da abordagem de banco de dados, listadas na Seção 1.3, são (1) uso de um catálogo para armazenar a descrição (esquema) do banco de dados de modo a torná-lo autodescritivo, (2) isolamento de programas e dados (independência entre dados e operação do programa) e (3) suporte para múltiplas visões do usuário. Nesta seção, especificamos uma arquitetura para sistemas de banco de dados, chamada arquitetura de três esquemas,8 que foi

' O estado atual também é chamado de instante atual do banco de dados. Ele também é chamado de instância do banco de dados, mas preferimos usar o termo instância para nos referir a registros individuais.

• Isso também c conhecido como arquitetura ANSL'SPARC (American National Standards Institute/ Standard Planning And Requirement Committee), mesmo nome do comitê que a propôs (Tsichritzis e Klug, 19781.

34 Sistemas de banco de dados

proposta para ajudar a alcançar e a visualizar essas características. Depois, vamos discutir melhor o conceito de independência de dados. 2.2.7 A arquitetura de três esquemas

O objetivo da arquitetura de três esquemas, ilustrada na Figura 2.2, é separar as aplicações do usuário do banco de dados físico. Nessa arquitetura, os esquemas podem ser definidos nos três níveis a seguir: 1. O nível interno tem um esquema interno, que descreve a estrutura do armaze­ namento físico do banco de dados. O esquema interno usa um modelo de dados físico e descreve os detalhes completos do armazenamento de dados e os caminhos de acesso para o banco de dados.

2. O nível conceituai tem um esquema conceituai, que descreve a estrutura do banco de dados inteiro para uma comunidade de usuários. O esquema concei­ tuai oculta os detalhes das estruturas de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamentos, operações do usuário e restrições. Normalmente, um modelo de dados representativo é usado para descrever o esquema conceituai quando um sistema de banco de dados é imple­ mentado. Esse esquema conceituai de implementação costuma estar baseado em um projeto de esquema conceituai em um modelo de dados de alto nível.

3. O nível externo ou de visão inclui uma série de esquemas externos ou visões do usuário. Cada esquema externo descreve a parte do banco de dados em que um grupo de usuários em particular está interessado e oculta o restante do banco de dados do grupo de usuários. Como no nível anterior, cada esquema externo é comumente implementado com o uso de um modelo de dados representativo, possivelmente fundamentado em um projeto de esquema externo em um modelo de dados de alto nível. A arquitetura de três esquemas é uma ferramenta conveniente, com a qual o usuário pode visualizar os níveis de esquema em um sistema de banco de dados. z\ maioria dos SGBDs não separa os três níveis completa e explicitamente, mas dá

Usuários finais

Figura 2.2 A arquitetura de três esquemas.

Bancos de dados armazenado

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 35

suporte a eles de alguma forma. Alguns sistemas mais antigos podem incluir detalhes de nível físico no esquema conceituai. A arquitetura ANSI de três níveis tem um lugar importante no desenvolvimento da tecnologia de banco de dados, pois separa claramente o nível externo dos usuários, o nível conceituai e o nível de armazena­ mento interno no projeto de um banco de dados. Ainda hoje ela é bastante aplicável no projeto de SGBDs. Na maioria dos SGBDs que têm suporte a visões do usuário, os esquemas externos sâo especificados no mesmo modelo dc dados que descreve a informação no nível conceituai (por exemplo, um SGBD relacionai como Oracle ou SQLServer utiliza SQL para isso). Observe que os três esquemas sâo apenas descrições dos dados; os dados arma­ zenados que realmente existem estão apenas no nível físico. Na arquitetura de três esquemas, cada grupo dc usuários recorre ao seu próprio esquema externo. Assim, o SGBD precisa transformar uma solicitação especificada em um esquema externo em uma solicitação no esquema conceituai, e depois em uma solicitação no esquema interno para o processamento no banco de dados armazenado. Se a solicitação for uma recuperação no banco, os dados extraídos do banco de dados armazenados devem ser reformatados para corresponder à visão extema do usuário. Os proces­ sos dc transformação de requisições c os resultados entre os níveis sâo chamados de mapeamentos. Esses mapeamentos podem ser demorados, dc modo que alguns SGBDs — especialmente aqueles que servem para dar suporte a pequenos bancos de dados — não oferecem suporte a visões externas. Porém, mesmo em tais sistemas, é necessário transformar solicitações entre os níveis conceituai c interno.

2.2.2 Independência de dados

A arquitetura de três esquemas pode ser usada para explicar melhor o conceito de independência de dados, que pode ser definida como a capacidade de alterar o esquema em um nível do sistema de banco de dados sem ter de alterar o esquema no próximo nível mais alto. Podemos definir dois tipos de independência de dados: 1. Independência lógica dc dados é a capacidade dc alterar o esquema conceituai sem ter de alterar os esquemas externos ou os programas de aplicação. Podemos alterar o esquema conceituai para expandir o banco de dados (acrescentando um tipo dc registro ou item de dado), para alterar restrições ou para reduzi-lo (removendo um tipo dc registro ou item dc dado). No último caso, esquemas externos que se referem apenas aos dados restantes não seriam afetados. Por exemplo, o esquema externo da Figura 1.5(a) não deverá ser afetado pela alte­ ração do arquivo (ou ripo de registro) REGISTRO.NOTA, mostrado na Figura 1.2, para aquele mostrado na Figura 1.6(a). Somente a definição da visão e os mapeamentos precisam ser alterados em um SGBD que suporta a independência lógica de dados. Depois que o esquema conceituai passa por uma reorganização lógica, os programas de aplicação que referenciam as construções do esquema externo devem funcionar da mesma forma que antes. As mudanças nas restrições podem ser aplicadas ao esquema conceituai sem afetar os esquemas externos ou os programas de aplicação.

2. Independência física de dados é a capacidade de alterar o esquema interno sem ter de alterar o esquema conceituai. Logo, os esquemas externos também não precisam ser alterados. Mudanças no esquema interno podem ser necessárias porque alguns arquivos físicos foram reorganizados — por exemplo, ao criar estruturas de acesso adicionais — para melhorar o desempenho da recuperação ou atualização. Se os mesmos dados de antes permanecerem no banco de dados, provavelmente não teremos de alterar o esquema conceituai. Por exemplo, oferecer um caminho de acesso para melhorar a velocidade de recuperação dos

36 Sistemas de banco de dados registros de TURMA (Figura 1.2) por semestre e ano nào deverá exigir que uma consulta como listar todas as turmas oferecidas no segundo semestre de 2008 seja alterada, embora a consulta seja executada com mais eficiência pelo SGBD ao utilizar o novo caminho de acesso.

Em geral, a independência física de dados existe na maioria dos bancos de dados e ambientes de arquivo, nos quais detalhes físicos, como a localização exata dos dados no disco, e detalhes de hardware sobre codificação do armazenamento, posicionamento, compactação, divisão, fusão de registros, e assim por diante, são ocultados do usuário. As demais aplicações desconhecem esses detalhes. Por sua vez, a independência lógica de dados é mais difícil de ser alcançada porque permite alterações estruturais e de restrição sem afetar os programas de aplicação — um requisito muito mais estrito. Sempre que temos um SGBD dc múltiplos níveis, seu catálogo deve ser expandido para incluir informações sobre como mapear solicitações e dados entre os diversos níveis. O SGBD usa software adicional para realizar esses mapeamentos, recorrendo à informação dc mapeamento no catálogo. A independência dc dados ocorre porque, quando o esquema é alterado em algum nível, o esquema no próximo nível mais alto permanece inalterado; somente o mapeamento entre os dois níveis é alterado. Portanto, os programas de aplicação que fazem referência ao esquema de nível mais alto não precisam ser alterados.

2.3 Linguagens e interfaces do banco de dados Na Seção 1.4, discutimos a variedade de usuários atendidos por um SGBD. O banco de dados precisa oferecer linguagens e interfaces apropriadas para cada categoria de usuário. Nesta seção, discutimos os tipos de linguagens e interfaces oferecidas por um SGBD e as categorias de usuário que são alvo de cada interface.

2.3.1 Linguagens do SGBD Quando o projeto de um banco de dados é finalizado e um SGBD é escolhido para implementá-lo, o primeiro passo é especificar esquemas conceituais e internos para o banco de dados e quaisquer mapeamentos entre os dois. Em muitos SGBDs, em que não é mantida nenhuma separação estrita de níveis, uma linguagem, chamada linguagem dc definição dc dados (DDL — Data Definition Language}, c usada pelo DBA c pelos projetistas de banco de dados para definir os dois esquemas. O SGBD terá um compilador da DDL cuja função é processar instruções da DDL a fim de identificar as descrições dos construtores de esquema e armazenar a descrição dc esquema no catálogo do SGBD. Nos SGBDs que mantêm uma separação clara entre os níveis conceituai e interno, a DDL é usada para especificar apenas o esquema conceituai. Outra linguagem, a linguagem de definição de armazenamento (SDL — Storage Definition Language), é utilizada para especificar o esquema interno. Os mapeamentos entre os dois esquemas podem ser especificados em qualquer uma dessas linguagens. Na maioria dos SGBDs relacionais, nào existe uma linguagem específica que realize o papel de SDL. Em vez disso, o esquema interno é especificado por uma combinação de funções, parâmetros e especificações relacionadas ao armazenamento de arquivos. Estes permitem aos DBAs controlar opções de indexação e mapeamento de dados que serão armazenados. Para uma verdadeira arquitetura de três esquemas, precisa­ ríamos de uma terceira linguagem, a linguagem dc definição dc visão (VDL — View Definition Language), para especificar visões do usuário c seus mapeamentos ao

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 37 esquema conceituai, mas na maioria dos SGBDs a DDL é usada para definir tanto o esquema conceituai como o externo. Nos SGBDs relacionais, a SQL é usada no papel de VDL para definir visões do usuário ou da aplicação como resultados de consultas predefinidas (ver capítulos 6 e 7). Quando os esquemas do banco de dados são compilados e o banco é populado com dados, os usuários precisam de alguma forma para manipulá-lo. As manipu­ lações típicas incluem recuperação, inserção, exclusão e modificação dos dados. O SGBD oferece um conjunto de operações ou uma linguagem chamada linguagem de manipulação de dados (DML — Data Manipulation Language) para essas finalidades. Nos SGBDs atuais, esses tipos de linguagens normalmente não são considerados linguagens distintas; ao contrário, uma linguagem integrada e abrangente é usada na definição do esquema conceituai, definição de visão e manipulação de dados. A definição do armazenamento, em geral, é mantida em separado, pois serve para definir estruturas de armazenamento físicas, para ajustar o desempenho do sistema de banco de dados, o que é normalmente feito pela equipe de DBA. Um exemplo típico de linguagem de banco de dados abrangente é a linguagem relacionai SQL (ver capítulos 6 e 7), que representa uma combinação de DDL, VDL c DML, bem como as instruções para especificação de restrição, evolução de esquema e outros recursos. A SDL era um componente nas primeiras versões da SQL, mas foi removida da linguagem para mantê-la apenas nos níveis conceituai e externo. Existem dois tipos dc DML. Uma DML de alto nível ou não procedural pode ser utilizada para especificar operações de banco de dados complexas de forma concisa. Muitos SGBDs permitem que instruções DML de alto nível sejam inseridas interativamente em um monitor ou terminal ou sejam embutidas em uma linguagem de programação de uso geral. Nesse último caso, as instruções DML precisam ser identificadas dentro do programa, de modo que possam ser extraídas por um pré-compilador e processadas por um SGBD. Uma DML de baixo nível ou procedural deve ser embutida em uma linguagem dc programação dc uso geral. Esse tipo de DML recupera registros individuais ou objetos do banco de dados e processa cada um deles separadamente. Portanto, precisa de construções de linguagem de programa­ ção, como laços (ou loop), para recuperar e processar cada registro de um conjunto dc registros. DMLs de baixo nível também são chamadas dc DMLs que tratam um registro dc cada vez, cm virtude dessa propriedade. As DXILs dc alto nível, como a SQL, podem especificar e recuperar muitos registros em uma única instrução DML; portanto, elas são chamadas de DMLs de um conjunto de cada vez ou orientadas a conjunto. Uma consulta em uma DML de alto nível normalmente especifica quais dados recuperar, em vez de como recuperá-los; portanto, essas linguagens também são chamadas dcclarativas. Sempre que comandos DML, sejam eles de alto ou de baixo nível, são incor­ porados em uma linguagem de programação de uso geral, ela é chamada de lin­ guagem hospedeira e a DML é chamada de sublinguagem de dados.9 Por sua vez, uma DML de alto nível usada em uma maneira interativa é chamada linguagem dc consulta. Em geral, comandos dc recuperação c atualização dc uma DML dc alto nível podem ser usados dc maneira interativa e, portanto, são considerados parte da linguagem de consulta.10

9 Em bancos dc dados de objeto, as sublinguagens hospedeiras e de dados formam uma linguagem integrada — por exemplo, C++ com algumas extensões para dar suporte à funcionalidade de banco de dados. Alguns sistemas relacionais também oferecem linguagens integradas — por exemplo, a PIVSQL do Oracle.

10 De acordo com seu significado em inglês, a palavra consulta para descrever apenas recuperações, e não atualizações.

(query), na realidade, deveria ser usada

38 Sistemas de banco de dados Usuários finais casuais costumam usar uma linguagem de consulta de alto nível para especificar suas solicitações, enquanto os programadores usam a DML em sua forma embutida. Para usuários comuns e paramétricos, normalmente existem interfaces amigáveis para interagir com o banco de dados; estas também podem ser usadas por usuários casuais ou outros que nào querem aprender os detalhes de uma linguagem de consulta de alto nível. Discutiremos esses tipos de interface a seguir.

2.3.2 Interfaces de SGBD As interfaces amigáveis oferecidas por um SGBD podem incluir:

Interfaces baseadas em menu para clientes web ou de navegação. Essas interfaces apresentam ao usuário uma lista de opções (chamadas menus) que acompanham o usuário na formulação de uma solicitação. Os menus acabam com a necessidade de memorizar os comandos específicos e a sintaxe de uma linguagem de consulta; em vez disso, a consulta é composta passo a passo ao se escolherem opções de um menu que é exibido pelo sistema. Os menus pull-down são uma técnica muito popular nas interfaces dc usuário baseadas na web. Eles também são usados com frequência em interfaces dc navegação, que permitem a um usuário examinar o conteúdo de um banco de dados de uma maneira exploratória e desestruturada.

Aplicativos para dispositivos móveis. Essas interfaces dão acesso aos dados para os usuários móveis. Por exemplo, bancos, empresas de reservas e seguros, entre muitas outras, oferecem aplicativos para permitir que os usuários acessem seus dados por meio dc um telefone celular ou outro dispositivo móvel. Os aplicativos possuem interfaces programadas embutidas que, cm geral, permitem que os usuários façam login com seu nome dc conta e senha; então, os aplicativos oferecem um menu de opções limitado para o acesso móvel aos dados do usuário, além de opções como pagar contas (para bancos) ou fazer reservas (para sites de reserva). Interfaces baseadas em formulário. Uma interface baseada em formulário apre­ senta um formulário para cada usuário. Os usuários podem preencher todas as entra­ das do formulário para inserir novos dados ou preencher apenas certas entradas, caso em que o SGBD recuperará os dados correspondentes para as entradas restantes. Os formulários normalmente são projetados e programados para usuários finais como interfaces para transações já programadas. Muitos SGBDs possuem linguagens de especificação de formulários, que são linguagens especiais que ajudam os progra­ madores a especificar tais formulários. SQL Forms * é uma linguagem baseada em formulário que especifica consultas usando um formulário projetado em conjunto com o esquema de banco de dados relacionai. Oracle Forms é um componente do pacote de produtos da Oracle que oferece um extenso conjunto dc recursos para projetar e montar aplicações usando formulários. Alguns sistemas possuem utilitários para definir um formulário, permitindo que o usuário final construa interativamente um formulário de amostra na tela.

Interfaces gráficas com o usuário. Uma GUI normalmente apresenta um esquema para o usuário em formato de diagrama. O usuário pode então especificar uma consulta manipulando o diagrama. Em muitos casos, as GUIs utilizam menus e formulários. Interfaces de linguagem natural. Essas interfaces aceitam solicitações escritas em inglês ou em outro idioma, e tentam entendê-las. Uma interface de linguagem natural costuma ter o próprio esquema, que é semelhante ao esquema concei­ tuai do banco de dados, bem como um dicionário de palavras importantes. Essa interface de linguagem natural recorre às palavras em seu esquema, bem como ao conjunto dc palavras-padrão em seu dicionário, que são usadas para interpretar

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 39

a solicitação. Se a interpretação for bem-sucedida, a interface gera uma consulta de alto nível correspondente à solicitação de linguagem natural e a submete ao SGBD para processamento; caso contrário, um diálogo é iniciado com o usuário para esclarecer a solicitação. Pesquisa do banco de dados baseada em palavra-chave. Estas são semelhantes aos mecanismos de busca na web, que aceitam sequências de palavras de linguagem natural (como inglês ou espanhol) e as combinam com documentos em sites especí­ ficos (para mecanismos de busca locais) ou páginas web em geral (para mecanismos como Google ou Ask). Eles utilizam índices predefinidos sobre palavras e funções dc pontuação (ranking) para recuperar c apresentar documentos resultantes em um grau decrescente de combinação. Essas interfaces dc consulta textual “em forma livre” ainda não são comuns nos bancos de dados de modelo relacionai estruturado, embora uma área dc pesquisa chamada consulta baseada cm palavra-chave tenha surgido rcccntcmcntc para os bancos dc dados relacionais.

Entrada e saída de voz. O uso limitado da voz como entrada para uma consulta e como resposta para uma pergunta ou resultado de uma solicitação está se tor­ nando comum. Aplicações com vocabulários limitados, como consultas ao catálogo telefônico, chcgada/saída dc voo c informações da conta dc cartão dc credito, estão permitindo que a voz, como forma de entrada e saída, facilite o acesso a essas infor­ mações pelos clientes. A entrada de voz é detectada com o uso de uma biblioteca de palavras predefinidas e usadas para configurar os parâmetros fornecidos para as consultas. Para a saída, acontece uma conversão semelhante de texto ou de números para voz.

Interfaces para usuários paramétricos. Os usuários paramctricos, como caixas de banco, cm geral possuem um pequeno conjunto dc operações que precisam realizar repetidamente. Por exemplo, um caixa pode usar teclas de função isoladas para fazer transações de rotina e repetitivas, como depósitos em conta ou saques, ou consultas de saldo. Os analistas de sistemas e programadores projetam e implementam uma interface especial para cada classe conhecida de usuários finais. Normalmente, um pequeno conjunto de comandos abreviados é incluído, com o objetivo dc minimizar o número de toques de teclas exigido para cada solicitação. Interfaces para o DBA. A maioria dos sistemas de banco dc dados contem coman­ dos privilegiados que podem ser usados apenas pela equipe de DBAs. Estes incluem comandos para criar contas, definir parâmetros do sistema, conceder autorização de conta, alterar um esquema e reorganizar as estruturas de armazenamento de um banco de dados.

2.4 O ambiente do sistema de banco de dados Um SGBD é um sistema de software complexo. Nesta seção, vamos discutir os tipos de componentes de software que constituem um SGBD e os tipos de software de sistemas de computação com os quais ele interage. 2.4.7 Módulos componentes do SGBD

A Figura 2.3 ilustra, de uma forma simplificada, os componentes típicos do SGBD. A figura está dividida em duas partes. A parte superior refere-se aos diversos usuários do ambiente de banco de dados e suas interfaces. A parte inferior mostra os módulos internos do SGBD, responsáveis pelo armazenamento de dados e pro­ cessamento dc transações.

40 Sistemas de banco de dados

Usuários:

Equipe de DBAs

Instruções DDL

Comandos privilegiados

Compilador DDL

Usuários casuais

Programadores de aplicação

Consulta interativa

Programas de aplicação

Compilador de consulta

Usuários paramétricos

Compilador Pré-compilador I----- ►Ide linguagem ------------ i---------- 1 hospedeira

Otimizador de consulta

Compilador DML

(

----

Transações compiladas

A

Comandos, consultas e transações do DBA

Processador rie banco de dados em tempo de execução

Catalogo do sistema? Dicionário de dados

Execução de consulta e transação:

Saneo de dados armazenado

Gerenciador ► de dados , armazenados Subsistemas de controle de concorrência/ backup/recuperação

Entrada/saida do banco de dados

Figura 2.3 Módulos componentes de um SGBD e suas interações.

O banco de dados e o catálogo do SGBD normalmente sào armazenados em disco. O acesso ao disco é controlado, em especial, pelo sistema operacional (SO), que escalona a Icitura/escrita em disco. Muitos SGBDs possuem o próprio módulo de gerenciamento de buffer para planejar a Icitura/escrita cm disco, pois isso tem um efeito considerável sobre o desempenho. A redução da leitura/escrita em disco melhora o desempenho de maneira considerável. Um módulo gerenciador dc dados armazenados dc nível mais alto do SGBD controla o acesso às informações do SGBD armazenadas cm disco, se elas fizerem parte do banco de dados ou se forem parte do catálogo. Primeiro, vamos considerar a parte superior da Figura 2.3. Ela mostra as interfaces para a equipe de DBAs, usuários casuais que trabalham com interfaces interativas para formular consultas, programadores de aplicação que criam programas usando algumas linguagens de programação hospedeiras, e usuários paramétricos que rea­ lizam a entrada dos dados fornecendo parâmetros para transações predefinidas. A equipe de DBAs define o banco de dados e faz ajustes, alterando sua definição por meio da DDL e de outros comandos privilegiados. O compilador da DDL processa as definições de esquema especificadas e arma­ zena as descrições dos esquemas (metadados) no catálogo do SGBD. O catálogo

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 41

inclui informações como nomes e tamanhos dos arquivos, nomes e tipos dos itens de dados, detalhes de armazenamento de cada arquivo, informações de mapeamento entre esquemas, além de restrições. Além disso, o catálogo armazena muitos outros tipos de informações necessárias aos módulos do SGBD, que podem, então, utilizar as informações do catálogo conforme a necessidade. Usuários casuais e pessoas com necessidade ocasional de informações do banco dc dados interagem usando a interface dc consulta interativa, representada na Figura 2.3. Não mostramos explicitamente qualquer interação baseada em menu ou em for­ mulário ou em dispositivo móvel que possa ser usada para gerar a consulta interativa de maneira automática ou para acessar transações programadas. Essas consultas são analisadas e validadas pela exatidão da sintaxe da consulta, os nomes de arquivos c elementos dc dados, e assim por diante, por um compilador dc consulta, que as compila para um formato interno. Essa consulta interna está sujeita à otimização de consultas (discutida nos capítulos 18 e 19). Entre outras coisas, o otimizador de consulta preocupa-se com o rearranjo e a possível reordenação de operações, com a eliminação de redundâncias e o uso dos algoritmos de busca eficientes durante a execução. Ele consulta o catálogo do sistema em busca de informações estatísticas c outras informações físicas a respeito dos dados armazenados, gerando um código executável que realiza as operações necessárias para a consulta c faz chamadas ao processador em tempo de execução. Os programadores de aplicação escrevem programas em linguagens hospe­ deiras, como Java, C ou C++, que são submetidas a um pré-compilador. O pré-compilador extrai comandos DML do programa de aplicação escrito cm uma linguagem de programação hospedeira. Esses comandos são enviados ao compi­ lador DML para serem compilados em código objeto para o acesso ao banco de dados. O restante do programa é enviado ao compilador da linguagem hospedeira. Os códigos objeto para os comandos DML e o restante do programa são ligados (“linkados”), formando uma transação programada cujo código executável inclui chamadas para o processador dc banco dc dados em tempo de execução. E cada vez mais comum usar linguagens de scripting, como PHP e Python, para escrever programas de banco de dados. As transações programadas são executadas repe­ tidamente pelos usuários paramétricos via computador pessoal ou aplicativos móveis; esses usuários apenas fornecem os parâmetros para as transações. Cada execução é considerada uma transação separada. Um exemplo é uma transação de pagamento bancário, na qual o número da conta, o credor e o valor podem ser fornecidos como parâmetros. Na parte inferior da Figura 2.3, o processador de banco de dados em tempo de execução executa (1) os comandos privilegiados, (2) os planos de consulta execu­ táveis e (3) as transações programadas com parâmetros em tempo de execução. Ele trabalha com o catálogo do sistema e pode atualizá-lo com estatísticas. Também trabalha com o gerenciador de dados armazenados, que, por sua vez, utiliza os serviços básicos do sistema operacional para executar operações de entrada/saída (leitura/escrita) de baixo nível entre o disco e a memória principal. O processador de banco dc dados cm tempo de execução cuida de outros aspectos da transferencia dc dados, como o gerenciamento de buffers na memória principal. Alguns SGBDs têm o próprio módulo de gerenciamento de buffer, enquanto outros dependem do SO para fazê-lo. Mostramos os sistemas de controle de concorrência e backup e recuperação separadamente como um módulo nessa figura. Eles são integrados ao funcionamento do processador de banco dc dados em tempo dc execução para fins de gerenciamento de transação. E comum que o programa cliente acesse o SGBD executando em um compu­ tador separado daquele em que o banco de dados reside. O primeiro é chamado

42 Sistemas de banco de dados computador cliente, que executa um software cliente do SGBD, e o segundo é chamado servidor de banco dc dados. Em alguns casos, o cliente acessa um computador intermediário, conhecido como servidor de aplicações, que, por sua vez, acessa o servidor de banco de dados. Abordaremos melhor esse assunto na Seção 2.5. A Figura 2.3 não pretende descrever um SGBD específico; ao contrário, ela ilustra seus módulos básicos. O SGBD interage com o sistema operacional quando os acessos ao disco — ao banco de dados ou ao catálogo — são necessários. Se o computador for compartilhado por muitos usuários, o SO planejará as solicitações de acesso ao disco do SGBD e o processamento do SGBD com outros processos. Por outro lado, se o computador estiver principalmente dedicado a executar o servidor de banco de dados, o SGBD controlará a memória principal mantendo as páginas do disco em buffers. O SGBD também realiza a interface com compilado­ res das linguagens de programação hospedeiras de uso geral, e com os servidores de aplicações e programas cliente rodando em máquinas separadas, por meio da interface de rede do sistema.

2.4.2 Utilitários do sistema de banco de dados Além dos módulos de software que descrevemos, a maioria dos SGBDs possui utilitários de banco de dados que ajudam o DBz\ a gerenciar o sistema. Os utilitários comuns têm os seguintes tipos de funções: ■ Carga. Um utilitário de carga é usado para carregar os arquivos dc dados existentes — como arquivos de texto ou sequenciais — no banco de dados. Normalmente o formato atual do arquivo de dado (origem) e a estrutura do arquivo do banco de dados desejado (destino) são especificados pelo utilitário, que reformara automaticamente os dados e os armazena no banco de dados. Com a proliferação de SGBDs, a transferência de dados de um SGBD para outro está se tornando comum cm muitas organizações. Alguns fornecedores dc SGBDs estão oferecendo ferramentas dc conversão que geram os programas dc carga apropriados, tendo como base descrições de armazenamento de banco dc dados de origem e destino (esquemas internos). ■ Backup. Um utilitário de backup cria uma cópia de segurança do banco de dados, normalmente copiando-o inteiro para fira ou outro meio de armazena­ mento em massa. A cópia de backup pode ser usada para restaurar o banco de dados no caso dc uma falha catastrófica no disco. Os backups incrementais também costumam ser utilizados c registram apenas as mudanças ocorridas após o backup anterior O backup incremental é mais complexo, mas economiza espaço de armazenamento. ■ Reorganização do armazenamento do banco dc dados. Esse utilitário pode ser usado para reorganizar um conjunto de arquivos do banco de dados em dife­ rentes organizações de arquivo e cria novos caminhos de acesso para melhorar o desempenho. ■ Monitoração de desempenho. Esse utilitário monitora o uso do banco de dados e oferece estatísticas ao DBA, que as usa para decidir se deve ou não reorganizar arquivos ou se deve incluir ou remover índices para melhorar o desempenho.

Podem estar disponíveis outros utilitários para classificar arquivos, tratar da compactação de dados, monitorar o acesso pelos usuários, realizar a interface com a rede e desempenhar outras funções.

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 43

2.4.3 Ferramentas, ambientes de aplicação e facilidades de

comunicações Outras ferramentas estâo frequentemente disponíveis aos projetistas de bancos de dados, usuários e ao SGBD. Ferramentas CASE” são usadas na fase de projeto dos sistemas de banco de dados. Outra ferramenta que pode ser muito útil em gran­ des organizações é um sistema de dicionário dc dados (ou de repositório de dados) expandido. Além de armazenar informações dc catálogo sobre esquemas c restrições, o dicionário de dados armazena decisões do projeto, padrões dc uso, descrições do programa de aplicação e informações do usuário. Esse sistema também é chamado de repositório de informação. Essa informação pode ser acessada diretamente pelos usuários ou pelo DBA, quando necessário. Um utilitário de dicionário de dados é semelhante ao catálogo do SGBD, mas inclui uma variedade maior de informações e é acessado principal mente pelos usuários, em vez de pelo software de SGBD. Ambientes de desenvolvimento de aplicação, como o PowerBuilder (Sybase) ou o JBuilder (Borland), são muito populares. Esses sistemas oferecem um ambiente para desenvolver aplicações de banco de dados e incluem estruturas que ajudam em muitas facetas dos sistemas, incluindo projeto de banco de dados, desenvolvimento GUI, consulta c atualização, e desenvolvimento dc programas dc aplicação. O SGBD também precisa realizar a interface com o software dc comunicações, cuja função é permitir que os usuários em locais remotos do sistema de banco de dados acessem-no por meio de terminais de computador, estações de trabalho ou computadores pessoais. Estes são conectados ao local do banco de dados por meio de hardware dc comunicações dc dados, como roteadores da internet, linhas telefônicas, redes de longa distância, redes locais ou dispositivos de comunicação por satélite. Muitos sistemas de banco de dados do mercado possuem pacotes de comunicação que trabalham com o SGBD. O sistema integrado de SGBD e comunicações de dados é chamado de sistema DB/DC. Além disso, alguns SGBDs estão fisicamente distribuídos em várias máquinas. Nesse caso, são necessárias redes de comunicações para conectar as máquinas. Estas, com frequência, sâo redes locais (LANs — Local Area Networks), mas também podem ser outros tipos de redes.

2.5 Arquiteturas centralizadas e cliente/servidor para SGBDs 2.5.1 Arquitetura de SGBDs centralizada As arquiteturas para SGBDs têm seguido tendências semelhantes às dos sistemas de computação em geral. As arquiteturas mais antigas usavam computadores main­ frame para oferecer o processamento principal para todas as funções do sistema, incluindo programas de aplicação do usuário e programas de interface com o usuá­ rio, bem como toda a funcionalidade do SGBD. O motivo é que, nos sistemas mais antigos, a maioria dos usuários acessava tais sistemas por terminais de computador, que não tinham poder de processamento e apenas ofereciam capacidades de exibição. Portanto, todo o processamento era realizado remotamente no computador central, que continha o SGBD, e somente informações de exibição e controle eram enviadas do computador para os terminais dc vídeo, que eram conectados ao computador central por meio de vários tipos de redes de comunicações.

11 Embora CASE signifique ‘‘engenharia de software auxiliada por computador", muitas de suas ferramentas são usadas, prinápalmente. para o projeto de banco de dados.

44 Sistemas de banco de dados A medida que os preços do hardware caíram, a maioria dos usuários substituiu seus terminais por PCs, estações de trabalho e, mais recentemente, por dispositivos móveis. No início, os sistemas de banco de dados usavam esses computadores de modo semelhante à forma que usavam terminais de vídeo, de maneira que o SGBD em si ainda era um SGBD centralizado, em que sua funcionalidade, execução de programas de aplicação e processamento de interface do usuário eram realizados em uma máquina. A Figura 2.4 ilustra os componentes físicos em uma arquitetura centralizada. Gradualmente, os sistemas de SGBD começaram a explorar o poder de processamento disponível no lado do usuário, o que levou às arquiteturas de SGBD cliente/servidor.

Terminais

Monitor de vídeo Rede

Figura 2.4 Uma arquitetura física centralizada.

2.5.2 Arquiteturas cliente/servidor básicas Primeiro, vamos discutir a arquitetura cliente/servidor em geral e depois veremos como ela se aplica aos SGBDs. z\ arquitetura cliente/servidor foi desenvolvida para lidar com ambientes de computação cm que um grande número de PCs, estações de trabalho, servidores dc arquivos, impressoras, servidores de banco dc dados, servido­ res web, servidores de correio (e-mail) e outros softwares e equipamentos são conec­ tados por uma rede. A ideia é definir servidores especializados com funcionalidades específicas. Por exemplo, é possível conectar uma série de PCs ou pequenas estações de trabalho como clientes a um servidor de arquivos que mantém os arquivos das máquinas clientes. Outra máquina pode ser designada como servidor dc impressão, sendo conectada a várias impressoras; todas as solicitações dc impressão pelos clien­ tes são encaminhadas a essa máquina. Os servidores web ou servidores dc correio também se encontram na categoria de servidor especializado. Os recursos fornecidos pelos servidores especializados podem ser acessados por muitas máquinas clientes. As máquinas clientes oferecem ao usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento local para executar aplicações locais. Esse conceito pode ser transportado para outros pacotes de software, com progra­ mas especializados — como o pacote de CAD (Computer-Aided Design) — sendo armazenados em máquinas servidoras específicas e acessíveis a múltiplos clientes. A Figura 2.5 ilustra a arquitetura cliente/servidor no nível lógico; a Figura 2.6 é um

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 45

Figura 2.5 Arquitetura cliente/servidor lógica em duas camadas.

Cliente

Cliente

Servidor

Figura 2.6 Arquitetura cliente/servidor física em duas camadas.

diagrama simplificado que mostra a arquitetura física. Algumas máquinas seriam apenas locais do cliente (por exemplo, dispositivos móveis ou estações de trabalho/ PCs que têm apenas software cliente instalado). Outras máquinas seriam servidores dedicados, e outras ainda teriam funcionalidade de cliente e servidor. O conceito de arquitetura cliente/servidor assume uma estrutura básica composta por muitos PCs/estações de trabalho e dispositivos móveis, além de um número menor de máquinas servidoras, conectadas por redes sem fio (wireless) ou LANs e outros tipos de redes de computadores. Um cliente nessa estrutura normalmente é uma máquina que oferece capacidades dc interface com o usuário e processamento local. Quando um cliente requer acesso a alguma funcionalidade adicional — como acesso ao banco de dados — que não existe na máquina do cliente, ele se conecta a um servidor que oferece a funcionalidade necessária. Um servidor é um sistema com hardware e software que pode oferecer serviços às máquinas clientes, como acesso a arquivo, impressão, arquivamento ou acesso a banco dc dados. Em geral, algumas máquinas têm instalados apenas software cliente, outras, apenas software servidor, e ainda outras podem incluir softwares cliente e servidor, conforme ilustrado na Figura 2.6. Porém, é mais comum que o software cliente e servidor seja executado em máquinas separadas. Dois tipos principais de arquiteturas de SGBD foram cria­ dos nessa estrutura cliente/servidor básica: duas camadas e três camadas. 2 Vamos explicar esses dois tipos a seguir. *- Existem muitas outras variações de arquiteturas diente/servidor. Discutiremos aqui as duas mais usuais.

46 Sistemas de banco de dados

2.5.3 Arquiteturas cliente/servidor de duas camadas para SGBDs Em sistemas de gerenciamento de banco de dados relacionais (SGBDRs), muitos dos quais começaram como sistemas centralizados, os componentes do sistema movidos inicialmente para o lado do cliente foram a interface com o usuário e os programas de aplicação. Como a SQL (ver capítulos 6 e 7) fornecia uma linguagem-padrão para os SGBDRs, isso criou um ponto de divisão lógico entre cliente e servidor. Assim, as funcionalidades de consulta e de transação relacionadas ao pro­ cessamento da SQL permaneceram no lado do servidor. Nesse ripo de arquitetura, o servidor frequentemente é chamado servidor dc consulta ou servidor dc transação, pois ofcrccc essas duas funcionalidades. Em um SGBDR, o servidor também é cha­ mado de servidor SQL. Os programas da interface com o usuário e os programas de aplicação podem ser executados no lado do cliente. Quando é necessário acessar o SGBD, o pro­ grama estabelece uma conexão com o SGBD (que está no lado do servidor); quando a conexão é criada, o programa cliente pode se comunicar com o SGBD. Um padrão denominado Conectividade de Banco de Dados Aberta (ODBC — Open Database Connectivity) oferece uma interface de programação de aplicações (API — Application Programming Interface), que permite que os programas do cliente chamem o SGBD, desde que as máquinas cliente e servidor tenham o software necessário instalado. A maioria dos fabricantes de SGBD oferece drivers ODBC para seus sistemas. Um programa cliente pode se conectar a vários SGBDRs c enviar solicitações de consulta e transação usando a API da ODBC, que é processada nos servidores. Quaisquer resultados de consulta são enviados de volta ao programa cliente, que pode processar e exibir os resultados conforme a necessidade. Foi defi­ nido também um padrão para a linguagem dc programação Java, chamado JDBC. Isso permite que programas clientes em Java acessem um ou mais SGBDs por meio de uma interface-padrão. As arquiteturas descritas aqui são chamadas arquiteturas de duas camadas porque os componentes de software são distribuídos por dois sistemas: cliente e servidor. As vantagens dessa arquitetura são sua simplicidade e compatibilidade transparente com os sistemas existentes. O surgimento da web mudou os papéis dc clientes e servidores, levando à arquitetura de três camadas.

2.5.4 Arquiteturas de três camadas e n camadas para aplicações web Muitas aplicações web utilizam uma arquitetura chamada arquitetura de três camadas, que acrescenta uma camada intermediária entre o cliente e o servidor de banco de dados, conforme ilustrado na Figura 2.7(a). Essa camada intermediária é chamada dc servidor dc aplicação ou servidor web, dependendo da aplicação. Esse servidor desempenha um papel intermediário pela execução de programas de aplicação e armazenamento de regras de negócios (procedimentos ou restrições), usados para acessar os dados do servidor de banco dc dados. Ela também pode melhorar a segurança do banco de dados, verificando as credenciais de um cliente antes de encaminhar uma solicitação ao servidor Os clientes têm interfaces com o usuário e navegadores web. O servidor intermediário aceita e processa solicitações do cliente, e envia consultas e comandos do banco de dados ao servidor, e depois atua como um canal para passar (parcialmente) dados processados do servidor aos clientes, onde podem ainda ser processados e filtrados para serem apresentados aos usuários. Assim, a interface com o usuário, as regras da aplicação e o acesso aos dados atuam como três camadas. A Figura 2.7(b) mos­ tra outra visão da arquitetura de três camadas usada pelo banco de dados e outros fabricantes de pacote de aplicação. A camada de apresentação exibe informações

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 47

Cliente

Servidor de aplicação ou Servidor web

Servidor de banco de dados

(a)

(b)

Figura 2.7 Arquitetura cliente/servidor lógica de três camadas, com algumas nomenclaturas comumente utilizadas.

ao usuário e permite a entrada de dados. A camada de lógica de negócios cuida das regras e das restrições intermediárias antes de os dados serem passados para o usuário ou devolvidos ao SGBD. A camada inferior inclui todos os serviços de geren­ ciamento de dados. A camada do meio também pode atuar como um servidor web, que recupera resultados das consultas do servidor de banco de dados e os formara para as páginas web dinâmicas, que sào vistas pelo navegador web no lado do cliente. A máquina cliente geralmente é um PC ou um dispositivo móvel conectado à web. Outras arquiteturas também foram propostas. É possível dividir as camadas entre o usuário e os dados armazenados em outros componentes mais detalhados, resul­ tando, assim, em arquiteturas de n camadas, onde w pode ser quatro ou cinco cama­ das. Em geral, a camada da lógica de negócios é dividida em várias camadas. zMém de distribuir a programação e os dados pela rede, as aplicações de n camadas têm a vantagem de que qualquer camada pode ser executada em um processador ou em uma plataforma de sistema operacional adequado e ser tratada independentemente. Os fabricantes de pacotes de ERP (Enterprise Resource Planning — Planejamento dos Recursos da Empresa) e CR.M (Customer Relationship Management— Gestão de Relacionamento com o Cliente) costumam utilizar uma camada mediadora, que é responsável pelos módulos de front-end (clientes) que se comunicam com uma série dc bancos de dados de back-cnd (servidores). Os avanços na tecnologia dc criptografia tornam mais seguro transferir dados confidenciais em formato codificado do servidor ao cliente, onde serão decodificados. Isso pode ser feito pelo hardware ou por um software avançado. Essa tecnologia oferece níveis mais altos dc segurança dc dados, mas as questões dc segurança da rede continuam sendo uma preocupação constante. Diversas tecnologias de compactação de dados também ajudam a transferir grande quantidade de dados dos servidores aos clientes por redes com e sem fio.

2.6 Classificação dos sistemas gerenciadores de banco de dados Vários critérios podem ser utilizados para classificar os SGBDs. O primeiro é o modelo dc dados no qual o SGBD é baseado. O principal modelo dc dados usado

48 Sistemas de banco de dados

atualmente em muitos SGBDs comerciais é o modelo de dados relacionai, e os siste­ mas baseados nele sào conhecidos como sistemas SQL. O modelo dc dados dc objeto foi implementado em alguns sistemas comerciais, mas não tem seu uso generalizado. Recenremente, os chamados sistemas big data, também conhecidos como sistemas de armazenamento de chave-valor e sistemas NOSQL, utilizam diversos modelos de dados: baseados cm documento, baseados cm gráfico, baseados em coluna e chave-valor. Muitas aplicações legadas ainda rodam cm sistemas de banco dc dados baseados nos modelos dc dados hierárquico e dc rede. Os SGBDs relacionais estão evoluindo continuamente e, em particular têm incor­ porado muitos dos conceitos que foram desenvolvidos nos bancos de dados de objeto. Isso tem levado a uma nova classe de SGBDs, chamados SGBDs objeto-relacionais. Assim, podemos categorizar os SGBDs com base no modelo de dados: relacionai, objeto, objeto-relacional, NOSQL, chave-valor, hierárquico, rede, entre outros. /Ylguns SGBDs experimentais se baseiam no modelo XX1L (extended Markup Language), que é um modelo de dados estruturado em árvore. Estes têm sido cha­ mados de SGBDs XML nativos. Vários SGBDs relacionais comerciais acrescentaram interfaces e armazenamento XML a seus produtos. O segundo critério usado para classificar SGBDs é o número dc usuários supor­ tados pelo sistema. Sistemas monousuário admitem apenas um usuário dc cada vez, e são usados principalmente com computadores pessoais. Sistemas multiusuário. que incluem a maioria dos SGBDs, admitem múltiplos usuários simultaneamente. O terceiro critério é o número dc locais sobre os quais o banco dc dados está distribuído. Um SGBD c centralizado se os dados estiverem armazenados cm um único computador. Um SGBD centralizado pode atender a vários usuários, mas o SGBD e o banco de dados residem integralmente em um único computador. Um SGBD distribuído (SGBDD) pode ter o banco de dados real e o software de SGBD distribuídos por vários locais, conectados por uma rede de computadores. Sistemas big data costumam ser maciçamente distribuídos, com centenas de locais. Os dados normalmcntc são replicados cm vários locais, de modo que a falha em um deles não tornará os dados indisponíveis. Os SGBDDs homogêneos usam o mesmo software de SGBD em rodos os locais, ao passo que SGBDDs heterogêneos podem usar um software de SGBD diferente em cada local. Também é possível desenvolver software mediador para acessar vários bancos dc dados autônomos preexistentes, armazenados sob SGBDs heterogêneos. Isso leva a um SGBD federado (ou sistema multibanco de dados),em que os sistemas participantes são fracamente acoplados e possuem um certo grau de autonomia local. Muitos SGBDDs utilizam arquitetura cliente/servidor, conforme descrito na Seção 2.5. O quarto critério é o custo. E difícil propor uma classificação dos SGBDs com base no custo. Hoje, temos SGBDs de código aberto (gratuito), como MySQL e PostgreSQL, que têm suporte de fornecedores terceirizados com serviços adicionais. Os principais SGBDRs estão disponíveis em versões gratuitas para testes durante 30 dias, além de versões pessoais, que podem custar menos de US$ 100 e permitir uma funcionalidade razoável. Os sistemas gigantes estão sendo vendidos em formato modular, com componentes para lidar com distribuição, replicação, processamento paralelo, capacidade móvel, e assim por diante, e com um grande número de parâ­ metros que precisam ser definidos na configuração. Além disso, eles são vendidos na forma de licenças — as licenças por local permitem o uso ilimitado do sistema de banco de dados com qualquer número dc cópias rodando na instalação definida pelo comprador. Outro tipo de licença limita o número de usuários simultâneos ou o número total de usuários em determinado local. As versões de alguns sistemas para um único usuário isolado, como Microsoft Access, são vendidas por cópia ou

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 49

incluídas na configuração geral do computador desktop ou notebook. Além disso, recursos de data warehousing e mineração de dados, bem como o suporte para tipos de dados adicionais, estão disponíveis por um custo extra. É possível pagar milhões de dólares anualmente pela instalação e manutenção de grandes sistemas de banco de dados. Também podemos classificar um SGBD com base nas opções dc tipos dc caminho dc acesso para armazenar arquivos. Uma Família bem conhecida de SGBDs é baseada cm estruturas invertidas de arquivo. Por fim, um SGBD pode ser dc uso geral ou de uso especial. Quando o desempenho é um aspecto importante, um SGBD de uso especial pode ser projetado e construído para uma aplicação específica; esse sistema não pode ser usado para outras aplicações sem mudanças relevantes. Muitos sistemas dc reservas aéreas c catálogo telefônico desenvolvidos no passado são SGBDs de uso especial. Eles se encontram na categoria de sistemas de processamento de transação on-line (OLTP — Online Transaction Processing), que precisam dar suporte a um grande número de transações simultâneas sem causar atrasos excessivos. Vamos detalhar rapidamente o critério principal para classificar SGBDs: o modelo dc dados. O modelo dc dados relacionai básico representa um banco de dados como uma coleção dc tabelas, em que cada tabela pode ser armazenada como um arquivo separado. O banco dc dados na Figura 1.2 se assemelha a uma representação relacio­ nai. A maior parte dos bancos de dados relacionais utiliza a linguagem de consulta de alto nível, chamada SQL, e admite uma forma limitada de visões do usuário. Discutiremos o modelo relacionai c suas linguagens c operações nos capítulos 5 a 8, e as técnicas para programar aplicações relacionais nos capítulos 10 c 11. O modelo de dados dc objeto define um banco de dados em termos de objetos, suas propriedades e operações. Objetos com a mesma estrutura e comportamento pertencem a uma classe, e as classes são organizadas em hierarquias (ou grafos acíclicos). As operações de cada classe são especificadas com procedimentos predefinidos, chamados métodos. Os SGBDs relacionais tem estendido seus modelos para incorporar conceitos dc banco dc dados dc objeto c outras funcionalidades; esses sistemas são chamados de sistema objeto-relacional ou sistema relacionai estendido. Discutiremos os sistemas de bancos de dados de objeto e objeto-relacional no Capítulo 12. Sistemas big data são baseados em diversos modelos dc dados, com os quatro modelos de dados mais comuns citados a seguir. O modelo dc dados dc chavc-valor associa uma chave única a cada valor (que pode ser um registro ou um objeto) e fornece acesso muito rápido a um valor a partir de sua chave. O modelo de dados de documento é baseado em JSON (Java Script Object Notation) e armazena os dados como documentos, um pouco semelhante a objetos complexos. O modelo dc dados de grafo armazena objetos como nós de um grafo e relações entre objetos como arestas direcionadas do grafo. Finalmente, os modelos de dados baseados em coluna armazenam as colunas de linhas agrupadas em páginas de disco para obter acesso rápido e permitem múltiplas versões dos dados. Vamos discutir alguns deles em detalhes no Capítulo 24. O modelo XML surgiu como um padrão para troca dc dados pela web e foi usado como base para implementar vários protótipos dc sistemas com XML nativa. A XML utiliza estruturas de árvore hierárquicas e combina conceitos de banco de dados com conceitos dos modelos de representação de documentos. Os dados são representados como elementos; com o uso de tags (rótulos), os dados podem ser aninhados para criar estruturas hierárquicas complexas. Esse modelo é conccitualmcnte semelhante ao modelo de objeto, mas usa uma terminologia diferente. Funcionalidades XML têm sido acrescentadas a muitos produtos de SGBD comerciais. /Vpresentaremos uma visão geral da XML no Capítulo 13.

50 Sistemas de banco de dados

Dois modelos de dados mais antigos, historicamente importantes, agora conhe­ cidos como modelos de dados legados, sào os modelos de rede e hierárquico. O modelo de rede representa dados como tipos de registro e também representa um tipo limitado de relacionamento 1:N, chamado tipo de conjunto. Um relacionamento 1:N, ou um para muitos, relaciona uma instância de um registro a muitas instâncias de registros usando algum mecanismo de ligação com ponteiros nesses modelos. O modelo de rede, também conhecido como modelo CODASYL DBTG,13 possui uma linguagem que trata um registro por vez e que deve estar embutida cm uma linguagem de programação hospedeira. A DML do modelo de rede foi proposta no Database Task Group (DBTG) Report de 1971 como uma extensão da linguagem COBOL. O modelo hierárquico representa os dados como estruturas hierárquicas em forma dc árvore. Cada hierarquia simboliza uma série dc registros relacionados. Não existe uma linguagem-padrão para o modelo hierárquico. Uma DML hierárquica popular é a DL/1 do sistema IMS. Ela dominou o mercado de SGBD por mais de 20 anos, entre 1965 e 1985. Sua DML, chamada DL/1, foi um padrão de fato na indústria por um longo tempo.

2.7 Resumo Neste capítulo, apresentamos os principais conceitos usados em sistemas de banco de dados. Definimos um modelo de dados e destacamos três categorias principais: ■ Modelos dc dados dc alto nível ou conceituais (baseados cm entidades c relacionamentos). ■ Modelos dc dados dc baixo nível ou físicos. ■ Modelos de dados representativos ou de implementação (baseados em registro, orientados a objeto).

Destacamos a separação do esquema, ou descrição de um banco de dados, do próprio banco de dados. O esquema não muda com muita frequência, ao passo que o estado do banco de dados muda todas as vezes em que dados são inseridos, excluídos ou modificados. Depois, descrevemos a arquitetura de SGBD, que permite três níveis de esquema: ■ Um esquema interno, que descreve a estrutura física do armazenamento do banco de dados. ■ Um esquema conceituai, que é uma descrição de alto nível do banco de dados inteiro. ■ Esquemas externos, que descrevem as visões de diferentes grupos de usuários.

Um SGBD que separa nitidamente os três níveis precisa ter mapeamentos entre os esquemas para transformar requisições e resultados das consultas de um nível para o seguinte. A maioria dos SGBDs não separa os três níveis complctamcntc. Usamos a arquitetura de três esquemas para definir os conceitos de independência lógica e física dos dados. Depois, discutimos os principais tipos de linguagens e interfaces para as quais os SGBDs têm suporte. Uma linguagem de definição de dados (DDL) é usada para definir o esquema conceituai do banco de dados. Na maioria dos SGBDs, a DDL também define visões do usuário e, às vezes, estruturas de armazenamento; em outros, existem linguagens ou funções separadas para especificar estruturas de armazenamento. Atualmente, essa distinção está desaparecendo nas implementações 13 CODASYL DBTG significa Conference on Data Systems Languages DatabaseTask Group, que é o nome do comitê que especificou o modelo de rede e sua linguagem.

Capítulo 2 Conceitos e arquitetura do sistema de banco de dados

reladonais, com a SQL servindo como uma linguagem geral para realizar vários papéis, incluindo definição de visões. A parte de definição de armazenamento (SDL) foi incluída nas primeiras versões da SQL, mas agora costuma ser implementada como comandos especiais para o DBA nos SGBDs relacionais. O SGBD compila todas as definições do esquema e armazena suas descrições no catálogo do sistema. Uma linguagem de manipulação de dados (DML) é usada para especificar leituras e atualizações no banco de dados. As DMLs podem ser de alto nível (orientadas a conjunto, não procedurais) ou dc baixo nível (orientadas a registro, proccdurais). Uma DML de alto nível pode ser embutida em uma linguagem de programação hospedeira, ou pode ser usada como uma linguagem independente; neste último caso, ela costuma ser chamada de linguagem de consulta. Discutimos os diferentes tipos dc interfaces fornecidas pelos SGBDs e os tipos dc usuários com os quais cada interface está associada. Depois, abordamos o ambiente do sistema de banco de dados, módulos de software de SGBD típicos e utilitários de SGBD para ajudar os usuários e as equipes de DBAs a realizar suas tarefas. Continuamos com uma visão geral das arquiteturas de duas e três camadas para aplicações de banco de dados. Por fim, classificamos os SGBDs dc acordo com vários critérios: modelo dc dados, número de usuários, número dc locais, tipos dc caminhos de acesso e custo. Discutimos a disponibilidade dos SGBDs e módulos adicionais — desde nenhum custo, na forma de software de código aberto, até configurações que custam milhões ao ano para serem mantidas. Também indicamos diversos tipos dc licença para os SGBDs c produtos relacionados. A principal classificação dos SGBDs é baseada no modelo de dados. Discutimos rapidamente os principais modelos de dados usados nos SGBDs comerciais disponíveis atualmente.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

2.1.

Defina os seguintes termos: modelo de dados, esquema de banco de dados, estado de banco de dados, esquema interno, esquema conceituai, esquema externo, independência de dados, DDL, DML, SDL, VDL, linguagem de consulta, linguagem hospedeira, sublinguagem de dados, utilitário de banco de dados, catálogo, arquitetura cliente/servidor, arquitetura de três camadas e arquitetura de n camadas. 2.2. Discuta as principais categorias de modelos dc dados. Quais são as diferenças básicas entre os modelos relacionai, de objeto e XML? 23. Qual é a diferença entre um esquema de banco de dados e um estado de banco de dados? 2.4. Descreva a arquitetura dc três esquemas. Por que precisamos de mapeamen­ tos entre os níveis de esquema? Como diferentes linguagens de definição de esquema dão suporte a essa arquitetura? 2.5. Qual é a diferença entre a independência lógica e a independência física dos dados? Qual é a mais difícil de alcançar? Por quê? 2.6. Qual é a diferença entre DMLs procedurais e não procedurais? 2.7. Discuta os diferentes tipos dc interfaces amigáveis c que usuários que normal­ mente utilizam cada tipo. 2.8. Com que outro software um SGBD interage? 2.9. Qual é a diferença entre as arquiteturas cliente/servidor de duas e três camadas? 2.10. Discuta alguns tipos dc utilitários c ferramentas de banco dc dados c suas funções. 2.11. Qual é a funcionalidade adicional incorporada na arquitetura dc n camadas (»>3)?

51

52 Sistemas de banco de dados

EXERCÍCIOS ----------------------------------------------------------------------------------------------2.12. Pense nos diferentes usuários para o banco de dados mostrado na Figura 1.2. De que tipos de aplicações cada usuário precisaria? A que categoria de usuário cada um pertencería e de que ripo de interface cada um precisaria? 2.13. Escolha uma aplicação de banco de dados com a qual você esteja acostu­ mado. Crie um esquema e mostre um exemplo de banco de dados para essa aplicação, usando a notação das figuras 1.2 e 2.1. Que tipos de informações e restrições adicionais você gostaria dc representar no esquema? Pense nos diversos usuários de seu banco de dados e projete uma visão para cada tipo. 2.14. Se você estivesse projetando um sistema baseado na web para fazer reservas e vender passagens aéreas, qual arquitetura de SGBD você escolhería, com base na Scçào 2.5? Por quê? Por que as outras arquiteturas não seriam uma boa escolha? 2.15. Considere a Figura 2.1. Além das restrições relacionando os valores das colunas de uma tabela às colunas de outra tabela, também existem restrições que impõem limitações sobre valores de uma coluna ou uma combinação de colunas de uma tabela. Uma restrição desse tipo impõe que uma coluna ou um grupo de colunas deva ser exclusivo em todas as linhas na tabela. Por exemplo, na tabela ALUNO, a coluna Numero_aluno deve ser exclusiva (para impedir que dois alunos diferentes tenham o mesmo Numero_aluno). Identifique a coluna ou o grupo de colunas das outras tabelas que precisam ser exclusivos em rodas as linhas na tabela.

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Muitos livros-texto de banco de dados, incluindo Date (2004), Silberschatz et al. (2011), Ramakrishnan e Gehrke (2003), Garcia-Molina et al. (2000, 2009) e Abitcboul et al. (1995), oferecem uma discussão sobre os diversos conceitos de banco de dados apresentados aqui. Tsichritzis e Lochovsky (1982) é o livro-texto mais antigo sobre modelos de dados. Tsichritzis e Klug (1978) e Jardine (1977) apresentam a arquitetura de três esquemas, que foi sugerida inicialmente no relatório CODASYL DBTG de 1971 e, mais tarde, em um relatório do American National Standards Institute (ANSI, instituto norte-americano de padrões) de 1975. Uma análise profunda do modelo de dados relacionai c algumas de suas possíveis exten­ sões são apresentadas em Codd (1990). O padrão proposto para bancos de dados orientados a objeto é descrito em Cattell et al. (2000). Muitos documentos descre­ vendo XML estão disponíveis na web, como XML (2005). Alguns exemplos de utilitários de banco dc dados são as ferramentas Connect, Analyze e Transform, e a ferramenta dc administração de banco de dados, DBArtisan, da Embarcadero Technologies ().

PARTE 2 Modelagem conceituai e projeto de banco de dados

Modelagem de dados usando o modelo Entidade-Relacionamento (ER) modelagem conceituai é uma fase muito importante no projeto de uma aplicação de banco de dados bem-sucedida. Geralmente, o termo aplicação de banco de dados refere-se a um banco de dados em particular e aos pro­ gramas associados que implementam suas consultas e atualizações. Por exemplo, uma aplicação de banco de dados BANCO que controla contas de clientes incluiria programas que implementam atualizações ao banco de dados correspondentes a depósitos e saques de clientes. Esses programas oferecem interfaces gráficas com o usuário (GUIs) de fácil utilização, com formulários e menus para os usuários finais da aplicação — neste exemplo, os clientes ou caixas de banco. Além disso, agora é comum oferecer interfaces desses programas a clientes do BANCO por meio de dispo­ sitivos móveis, usando aplicativos móveis. Logo, uma parte importante da aplicação de banco de dados exigirá o projeto, a implementação e o teste desses programas de aplicação. Tradicionalmente, o projeto e o teste dos programas de aplicação têm sido considerados parte da engenharia de software, em vez do projeto de banco de dados. Em muitas ferramentas de projeto de software, as metodologias de projeto de banco de dados e de engenharia de software são interligadas, pois essas atividades estão fortemente relacionadas. Neste capítulo, abordamos a técnica tradicional de se concentrar nas estruturas e nas restrições de banco de dados durante seu projeto conceituai. O projeto de pro­ gramas de aplicação normalmente é abordado em cursos de engenharia de software. Apresentamos os conceitos de modelagem do modelo Entidadc-Rclacionamcnto (ER), que é um modelo de dados conceituai popular dc alto nível. Esse modelo c suas variações costumam ser utilizados para o projeto conceituai de aplicações de banco de dados, e muitas ferramentas de projeto empregam seus conceitos. Descrevemos os conceitos e as restrições básicas de estruturação de dados do modelo ER e dis­ cutimos seu uso no projeto de esquemas conceituais para aplicações de banco de

A

56 Sistemas de banco de dados

dados. Também apresentamos a notação diagramática associada ao modelo ER, conhecida como diagramas ER. /\s metodologias de modelagem de objeto, como a Unified Modeling Language (UML — Linguagem de Modelagem Unificada), estão se tornando cada vez mais populares no projeto de software e de banco de dados. Essas metodologias vão além do projeto de banco de dados para especificar o projeto detalhado dos módulos de software e suas interações usando vários tipos de diagramas. Uma parte importante dessas metodologias — a saber, os diagramas de classe1 — é semelhante, de muitas maneiras, aos diagramas ER. Nos diagramas de classe são especificadas operações sobre objetos, além da especificação da estrutura do esquema do banco de dados. As operações podem ser usadas para especificar os requisitos funcionais durante o projeto, conforme discutiremos na Seção 3.1. Apresentamos parte da notação c dos conceitos em UML para diagramas de classe que são particularmente relevantes ao projeto de banco de dados da Seção 3.8, e os comparamos rapidamente com a notação e os conceitos de ER. Notação e conceitos de UML adicionais serão apre­ sentados na Seção 4.6. Este capítulo está organizado da seguinte forma: a Seção 3.1 discute o pape) dos modelos de dados conceituais de alto nível em projeto dc banco dc dados. Apresentamos os requisitos para uma aplicação dc banco de dados de exemplo na Seção 3.2, para ilustrar o uso dos conceitos do modelo ER. Esse banco de dados de exemplo também é usado no decorrer do livro. Na Seção 3.3, apresentamos os con­ ceitos dc entidades c atributos, c gradualmcntc introduzimos a técnica diagramática para exibir um esquema ER. Na Seção 3.4, apresentamos os conceitos dc relaciona­ mentos binários e seu papel e restrições estruturais. A Seção 3.5 apresenta os tipos de entidade fraca. A Seção 3.6 mostra como um projeto de esquema é refinado para incluir relacionamentos. A Seção 3.7 analisa a notação para diagramas ER, resume os problemas e armadilhas comuns que ocorrem no projeto de esquema e discute como escolher os nomes para construções de esquema de banco de dados, como tipos dc entidade e tipos dc relacionamento. A Seção 3.8 apresenta alguns concei­ tos de diagrama de classe UML, compara-os com os conceitos do modelo ER e os aplica ao mesmo banco de dados EMPRESA de exemplo. A Seção 3.9 discute tipos de relacionamentos mais complexos. A Seção 3.10 contém um resumo do capítulo. O material contido nas seções 3.8 c 3.9 pode ser excluído dc um curso introdu­ tório. Sc for desejada uma cobertura mais completa dos conceitos dc modelagem de dados e projeto de banco de dados conceituai, o leitor deverá continuar até o Capítulo 4, no qual descrevemos as extensões ao modelo ER que levam ao modelo EER (ER Estendido), o qual inclui conceitos como especialização, generalização, herança e tipos (categorias) de união.

3.1 Usando modelos de dados conceituais de alto nível para o projeto do banco de dados A Figura 3.1 mostra uma visão geral simplificada do processo de projeto de banco de dados. A primeira etapa mostrada é o levantamento e análise de requisitos. Durante essa etapa, os projetistas entrevistam os usuários esperados para entenderem e documentarem seus requisitos dc dados. O resultado dessa etapa é um conjunto dc requisitos dos usuários escrito de forma concisa. Esses requisitos devem ser especifi­ cados da forma mais detalhada c completa possível. Em paralelo com a especificação dos requisitos de dados, é útil determinar os requisitos funcionais da aplicação. Estes

1 Uma classe é semelhante a um

tipo de entidade de várias maneiras.

Capitulo 3

Requisitos funcionais

Modelagem de dados usando o modelo Entidade-Relacionamento (ER)

57

Requisitos de dados

Programas de aplicação

consistem cm operações (ou transações) definidas pelo usuário, que serão aplicadas ao banco de dados, incluindo consultas e atualizações. No projeto de software, é comum usar diagramas de fluxo de dados, diagramas de sequência, cenários e outras técnicas para especificar requisitos funcionais. Não discutiremos essas técnicas aqui; elas normalmente são descritas cm detalhes nos textos de engenharia dc software. Assim que os requisitos tiverem sido levantados e analisados, a etapa seguinte é criar um esquema conceituai para o banco de dados, usando um modelo de dados conceituai de alto nível. Essa etapa é chamada de projeto conceituai. O esquema conceituai é uma descrição concisa dos requisitos de dados dos usuários e inclui detalhes dos tipos de entidade, relacionamentos e restrições; estes são expressos com o uso dos conceitos fornecidos pelo modelo dc dados dc alto nível. Como não incluem descrições detalhadas de implementação, esses conceitos normalmente são mais fáceis de entender e podem ser usados para a comunicação com usuários não técnicos. O esquema conceituai de alto nível também pode ser utilizado como uma referência para garantir que todos os requisitos dc dados dos usuários sejam atendidos e que não estejam cm conflito. Essa abordagem permite que os projetistas se concentrem em especificar as propriedades dos dados, sem se preocuparem com detalhes de armazenamento e implementação. Isso toma mais fácil criar um bom projeto de banco de dados conceituai.

Figura 3.1 Um diagrama simplificado para ilustrar as principais fases do projeto de banco de dados.

58 Sistemas de banco de dados

Durante ou após o projeto do esquema conceituai, as operações básicas do modelo de dados podem ser usadas para especificar as consultas e operações do usuário de alto nível identificadas durante a análise funcional. Isso também serve para confir­ mar se o esquema conceituai atende a todos os requisitos funcionais identificados. Podem ser introduzidas modificações no esquema conceituai, se alguns requisitos funcionais não puderem ser especificados usando o esquema inicial. A etapa seguinte no projeto é a implementação real do próprio banco dc dados, usando um SGBD comercial. A maioria dos SGBDs comerciais utiliza um modelo de dados de implementação — como o modelo relacionai (SQL) —, de modo que o esquema conceituai é transformado do modelo de dados de alto nível para o modelo de dados da implementação. Essa etapa é chamada de projeto lógico ou mapeamento do modelo de dados. Seu resultado é um esquema dc banco de dados no modelo de dados da implementação do SGBD. O mapeamento do modelo de dados normalmente é automatizado ou semiautomatizado nas ferramentas de pro­ jeto do banco de dados. A última etapa é a fase do projeto físico, durante a qual as estruturas de armaze­ namento internas, organizações de arquivo, índices, caminhos de acesso e parâmetros físicos do projeto para os arquivos do banco dc dados são especificados. Em paralelo com essas atividades, os programas dc aplicação são projetados e implementados como transações de banco de dados correspondentes às especificações da transação de alto nível. Neste capítulo, apresentamos apenas os conceitos básicos do modelo ER para o projeto do esquema conceituai. Outros conceitos dc modelagem serão discutidos no Capítulo 4, quando apresentaremos o modelo EER.

3.2 Exemplo de aplicação de banco de dados Nesta seção, descrevemos um exemplo de aplicação de banco de dados, chamado EMPRESA, que serve para ilustrar os conceitos básicos do modelo ER e seu uso no pro­ jeto do esquema. Listamos os requisitos de dados para o banco dc dados aqui, e depois criaremos seu esquema conceituai passo a passo, quando introduzirmos os conceitos de modelagem do modelo ER. O banco de dados EMPRESA registra os funcionários, os departamentos e os projetos de uma empresa. Suponha que, depois da fase de levan­ tamento e análise dc requisitos, os projetistas dc banco dc dados ofereçam a seguinte descrição do minimimdo — a pane da empresa que será representada no banco dc dados: ■ A empresa é organizada em departamentos. Cada departamento tem um nome e um número exclusivos e um funcionário em particular que o gerencia. Registramos a data inicial em que esse funcionário começou a gerenciar o departamento. Um departamento pode ter várias localizações. ■ Um departamento controla uma série de projetos, em que cada projeto tem um nome e um número exclusivos e uma localização. ■ O banco de dados armazena nome, número do CPF (Cadastro de Pessoa Física),2 endereço, salário, sexo (gênero) e data dc nascimento de cada funcionário. Um fun­ cionário é designado para um departamento, mas pode trabalhar em vários projetos, que não necessariamente são controlados pelo mesmo departamento. Registramos o número atual de horas por semana que um funcionário trabalha em cada projeto, bem como o supervisor direto de cada funcionário (que é outro funcionário). ■ O banco de dados registra os dependentes de cada funcionário para fins de seguro, incluindo nome, sexo, data de nascimento e parentesco com o funcionário. 2 O número do Cadastro dc Pessoa Física (CPF) c um identificador exclusivo dc onze dígitos, atribuído a cada indivíduo no Brasil. Outros países possuem esquemas de identificação semelhantes, como núme­ ros dc Seguro Social (SSN l c identificação civil.

Capitulo 3

Modelagem de dados usando o modelo Entidade-Relacionamento (ER)

59

A Figura 3.2 mostra como o esquema para essa aplicação de banco de dados pode ser exibido por meio da notação gráfica conhecida como diagrama ER. Essa figura será explicada gradualmente à medida que os conceitos do modelo ER forem apresentados. Descrevemos o processo passo a passo da derivação desse esquema com base nos requisitos declarados — e explicamos a notação diagramática ER — à medida que introduzirmos os conceitos do modelo ER.

(^Primeiro nome

Nome meio

Data nascimento

Momp

timo nome

ndereco.

Salario Sexo j

------

TRABALHA PARA ~Nom^)

FUNOONARIO

ata inicio.

Numero de funcionários

^^imêro

- DEPARTAMENTO J

GERENCIA

CONTROLA

Horas M/ \ N < TRABALHA EM

Supervisor

N PROJETO

Supervisionad Nome

lUrtKVbONA

(TocalizacacT) JtrtNDtM Uh

Num£íQ

N DEPENDENTE

'Jnmp

Sexo

3.3 Tipos de entidade, conjuntos de entidades, atributos e chaves O modelo ER descreve os dados como entidades, relacionamentos e atributos. Na Seção 3.3.1, apresentamos os conceitos de entidades e seus atributos. Discutimos os tipos de entidade e os principais atributos chave na Seção 3.3.2. Depois, na Seção 3.3.3, especificamos o projeto conceituai inicial dos tipos de entidade para o banco de dados EMPRESA. Os relacionamentos são descritos na Seção 3.4.

3.3.1 Entidades e atributos Entidades e seus atributos. O conceito básico que o modelo ER representa é uma entidade, que é uma coisa ou objeto no mundo real com uma existência independente. Uma entidade pode ser um objeto com uma existência física (por exemplo, uma

Figura 3.2 Um diagrama de esquema ER para o banco de dados EMPRESA. A notação diagramática é apresentada gradual mente no decorrer do capítulo e está resumida na Figura 3.14.

60 Sistemas de banco de dados pessoa em particular, um carro, uma casa ou um funcionário), ou pode ser um objeto com uma existência conceituai (por exemplo, uma empresa, um cargo ou um curso universitário). Cada entidade possui atributos — as propriedades específicas que a descrevem. Por exemplo, uma entidade FUNCIONÁRIO pode ser descrita pelo nome, idade, endereço, salário e cargo do funcionário. Uma entidade em particular terá um valor para cada um de seus atributos. Os valores de atributo que descrevem cada entidade tornam-se uma parte importante dos dados armazenados no banco de dados. A Figura 3.3 mostra duas entidades e os valores de seus atributos. A entidade FUNCIONÁRIO fy tem quatro atributos: Nome, Endereço, Idade e Telefone_residencial; seus valores sào ‘João Silva’, ‘Rua das Flores, 751, São Paulo, SP, 07700110’,‘55’ e ‘11-4749-2630’, respectiva men te. A entidade EMPRESA e, tem três atributos: Nome, Matriz e Presidente; seus valores são ‘Empresa Modelo’, ‘São Paulo’ e ‘João Silva’, respectivamente. Vários tipos de atributos ocorrem no modelo ER: simples versus composto, valor único versus mitltivalorado e armazenado versus derivado. Primeiro, vamos definir esses tipos de atributo e ilustrar seu uso por meio de exemplos. Depois, discutiremos o conceito de um valor NULL para um atributo. Atributos compostos versus simples (atômicos). Atributos compostos podem ser divididos em subpartes menores, que representam atributos mais básicos, com signi­ ficados independentes. Por exemplo, o atributo Endereço da entidade FUNCIONÁRIO mostrada na Figura 3.3 pode ser subdividido em Logradouro, Cidade, Estado e Cep,3 com os valores ‘Rua das Flores, 751’, ‘Sào Paulo’, ‘SP’ e ‘07700110.' Os atributos não divisíveis são chamados atributos simples ou atômicos. Os atributos compostos podem formar uma hierarquia; por exemplo. Logradouro pode ser subdividido em três atributos simples: Numero, Rua e Numero_apartamento, como mostra a Figura 3.4. O valor dc um atributo composto é a concatenação dos valores de seus com­ ponentes atributos simples.

Nome = João Silva

Nome = Empresa Modelo

Endereço = Rua das Flores, 751 São Paulo, SP 07700110 Matriz = São Paulo

Figura 3.3 Duas entidades, FUNCIONÁRIO fy e EMPRESA e„e seus atributos.

Figura 3.4 Uma hierarquia de atributos compostos.

Idade = 55

Telefone residencial = 11-4749-2630

Numero

Rua

Presidente = João Silva

Numero apartamento

3 CEP (Código de Endereçamento Postal) é o nome usado no Brasil para um código postal com oito dígitos, como 07601-090.

Capitulo 3

Modelagem de dados usando o modelo Entidade-Relacionamento (ER) 61

Atributos compostos são úteis para modelar situações em que um usuário às vezes se refere ao atributo composto como uma unidade, mas outras vezes se refere especifica mente a seus componentes. Se o atributo composto for referenciado apenas como um rodo, nào é necessário subdividi-lo em atributos componentes. Por exem­ plo, se nào for preciso referenciar os componentes individuais de um endereço (CEP, rua etc.), então o endereço inteiro pode ser designado como um atributo simples. Atributos de valor único versus multivalorados. A maioria dos atributos possui um valor único para uma entidade em particular; tais atributos sào chamados de valor único. Por exemplo. Idade é um atributo de valor único de uma pessoa. Em alguns casos, um atributo pode ter um conjunto dc valores para a mesma entidade — por exemplo, um atributo Cores para um carro, ou um atributo Formacao_academica para uma pessoa. Os carros com uma cor têm um único valor, enquanto os carros com duas cores possuem dois valores de cor. De modo semelhante, uma pessoa pode não ter formação acadêmica, outra pessoa pode ter uma, c uma terceira pode ter duas ou mais formações; portanto, diferentes pessoas podem ter distintos números de valores para o atributo Formacao_academica. Esses atributos são chamados de multivalorados. Um atributo multivalorado pode ter um limite mínimo e um máximo para restringir o número de valores permitidos para cada entidade individual. Por exemplo, o atributo Cores de um carro pode ser restrito a ter entre ume dois valores, se considerarmos que um carro pode ter no máximo duas cores.

Atributos armazenados versus derivados. Em alguns casos, dois (ou mais) valores dc atributo estão relacionados — por exemplo, os atributos Idade e Data_nasdmento de uma pessoa. Para uma entidade de pessoa em particular, o valor de Idade pode ser determinado pela data atual (hoje) e o valor da Data_nascimento dessa pessoa. O atributo Idade, portanto, é chamado de atributo derivado e considerado derivável do atributo Data_nascimento, que é chamado, por sua vez, de atributo armazenado. Alguns valores de atributo podem ser derivados dc entidades relacionadas; por exemplo, um atributo Numero_de_funcionarios dc uma entidade DEPARTAMENTO pode ser derivado contando-se o número dc funcionários relacionados a (trabalhando para) esse departamento.

Valores NULL. Em alguns casos, uma entidade cm particular pode nào ter um valor aplicável para um atributo. Por exemplo, o atributo Numero_apartamento de um endereço só se aplica a endereços que estão em prédios de apartamento, e não a outros tipos de residências, como casas. Dc modo semelhante, um atributo Formacao_academica só se aplica a pessoas com esse tipo dc formação. Para tais situações, foi criado um valor especial, chamado NULL. Um endereço de uma casa teria NULL para seu atributo Numero_apartamento,e uma pessoa sem formação aca­ dêmica teria NULL para Formacao_academica. NULL também pode ser usado quando não conhecemos o valor de um atributo para determinada entidade — por exemplo, se não soubermos o número do telefone residencial de ‘João Silva’ na Eigura 3.3. O significado do primeiro tipo de NULL é não aplicável, enquanto o significado do segundo é desconhecido. A categoria desconhecido ainda pode ser classificada em mais dois casos. O primeiro caso acontece quando se sabe que o valor do atributo existe, mas está faltando — por exemplo, se o atributo Altura de uma pessoa for listado como NULL. O segundo caso surge quando não se sabe se o valor do atributo existe — por exemplo, se o atributo Telefone_residencial dc uma pessoa for NULL.

Atributos complexos. Observe que, em geral, os atributos compostos e mul­ tivalorados podem ser aninhados arbitrariamente. Podemos representar o aninhamento arbitrário ao agrupar componentes dc um atributo composto entre parênteses ( ) e separá-los com vírgulas, e ao exibir os atributos multivalorados entre chaves {). Esses atributos sào chamados de atributos complexos. Por exem­ plo, se uma pessoa pode ter mais de uma residência e cada residência pode ter

62 Sistemas de banco de dados um único endereço e vários telefones, um atributo Endereço_telefone para uma pessoa pode ser especificado como na Figura 3.5.4 Tanto Telefone quanto Endereço são atributos compostos. {Endereço_telefone( {Telefone(Codigo_area,Numero_telefone)),Endereco(Logradouro (Numero,Rua,Numero_apartamento),Cidade,Estado, Cep))} Figura 3.5 Um atributo complexo: Endereço_telefone.

3.3.2 Tipos de entidade, conjuntos de entidade, chaves e conjuntos de

valores Tipos de entidade e conjuntos de entidade. Um banco de dados em geral contém grupos de entidades que são semelhantes. Por exemplo, uma empresa que emprega centenas de funcionários pode querer armazenar informações semelhantes com relação a cada um dos funcionários. Essas entidades de funcionário comparti­ lham os mesmos atributos, mas cada uma tem o(s) próprio(s) valor(es) para cada atributo. Um tipo de entidade define uma coleção (ou conjunto) de entidades que têm os mesmos atributos. Cada tipo de entidade no banco de dados é descrito por seu nome e atributos. A Figura 3.6 mostra dois tipos de entidade: FUNCIONÁRIO e EMPRESA, e uma lista de alguns dos atributos para cada um. Algumas entidades individuais dc cada tipo também são ilustradas com os valores de seus atributos. A coleção de todas as entidades de determinado tipo de entidade no banco de dados, em qualquer ponto no tempo, é chamada dc conjunto de entidades ou coleção dc entidades. Xormalmente, o conjunto de entidades é referenciado como o tipo de entidade, embora sejam dois conceitos separados. Por exemplo, FUNCIONÁRIO refere-se ao tipo de entidade e também ao conjunto atual de todas as entidades de funcionário no banco de dados. Agora é mais comum dar nomes separados ao tipo de entidade e à coleção de entidades; por exemplo, nos modelos de dados de objeto e objeto-relacional (ver Capítulo 12). Nome do tipo de entidade:

FUNCIONÁRIO Nome, Idade, Salario

Conjunto de entidade: (Extensão)

Figura 3.6 Dois tipos de entidade, FUNCIONÁRIO e EMPRESA, e algumas entidades membros de cada uma.

EMPRESA Nome, Matriz, Presidente

6 •

ei •

(João Silva, 55, 80K)

(Modelo, São Paulo, João Silva)

6 •

*2 •

(Fred Borges, 40, 30K)

(Rápido Informática, Diadema, Roberto King)

h •

• • •

(Juliana Campos, 25, 20K)

• •

1. Os números significam que, para cada entidade e em E, e precisa participar de pelo menos min e no máximo max instâncias de relacionamento em R em qual­ quer ponto no tempo. Nesse método, min = 0 implica participação parcial, enquanto min > 0 implica participação total. A Figura 3.15 mostra o esquema de banco de dados EMPRESA usando a notação (min, max).14 Em geral, usa-se ou a notação dc razão de cardinalidadc/linha simples/ linha dupla ou a notação (min, max). A notação (min, max) é mais precisa, e podemos usá-la para especificar algumas restrições estruturais para os tipos de relacionamento de maior grau. Porém, isso não é suficiente para especificar algumas restrições de chave nos relacionamentos de maior grau, conforme discutiremos na Seção 3.9. A Figura 3.15 também apresenta todos os nomes de papel para o esquema de banco de dados EMPRESA. onde f é um FORNECEDOR que atualmente está abastecendo um PROJETO /' com uma PECA p. Em geral, um tipo de relacionamento R dc grau n terá n arestas em um diagrama ER, uma conectando R a cada tipo dc entidade participante.

(0

Figura 3.17 Tipos de relacionamento ternário. (a) O relacionamento FORNECE. (b)Três relacionamentos binários não equivalentes a FORNECE, (c) FORNECE representado como um tipo de entidade fraca.

82 Sistemas de banco de dados A Figura 3.17(b) mostra um diagrama ER para os três tipos de relacionamento binário PODE_FORNECER, USA e FORNECE. Em geral, um tipo de relacionamento ternário representa informações diferentes dos três tipos de relacionamento biná­ rio. Considere os três tipos de relacionamento binário PODE_FORNECER, USA e FORNECE. Suponha que PODE.FORNECER, entre FORNECEDOR e PECA, inclua uma instância (/, p) sempre que o fornecedor f puder fornecer a peça p (a qualquer projeto); USA, entre PROJETO e PECA, inclui uma instância (/, p) sempre que o pro­ jeto / usa a peça p; e FORNECE, entre FORNECEDOR e PROJETO, inclui uma instância (f i) sempre que o fornecedor f fornece alguma peça ao projeto /. A existência de três instâncias de relacionamento (/, p), (/’, p) e (/, /') em PODE_FORNECER, USA e FORNECE, respecrivamente, não implica que existe uma instância (/, /, p) no rela­ cionamento ternário FORNECE, pois o significado é diferente. Com frequência, é complicado decidir se um relacionamento em particular deve ser representado como um tipo de relacionamento de grau n ou se deve ser desmembrado em vários tipos de relacionamento de graus menores. O projetista deverá basear essa decisão na semântica ou no significado da situação em particular que está sendo represen­ tada. A solução típica é incluir o relacionamento ternário com um ou mais dos relacionamentos binários, se eles representarem significados diferentes e se todos forem necessários à aplicação. Algumas ferramentas de projeto de banco de dados são baseadas em variações do modelo ER que permitem apenas relacionamentos binários. Nesse caso, um relacionamento ternário como SUPRIMENTO deve ser representado como um tipo de entidade fraca, sem chave parcial e com três relacionamentos dc identificação. Os três tipos de entidade participantes FORNECEDOR, PECA e PROJETO são, juntos, os tipos de entidade proprietária (ver Figura 3.17(c)). Logo, uma entidade no tipo de entidade fraca SUPRIMENTO na Figura 3.17(c) é identificada pela combinação de suas três entidades proprietárias de FORNECEDOR, PECA e PROJETO. Também é possível representar o relacionamento ternário como um tipo dc entidade regular introduzindo uma chave artificial ou substituta. Neste exemplo, um atributo-chave Cod_fornecimento poderia ser usado para o ripo de entidade SUPRIMENTO, convertendo-o em um tipo de entidade regular. Três relacionamentos binários N:1 relacionam SUPRIMENTO aos três tipos de entidade participantes. Outro exemplo c mostrado na Figura 3.18. O tipo dc relacionamento ternário OFERECE representa informações sobre professores que oferecem cursos durante determinados semestres; logo, ele inclui uma instância de relacionamento (p, s, d) sempre que o PROFESSOR p oferece a DISCIPLINA d durante o SEMESTRE s. Os três tipos de relacionamento binário mostrados na Figura 3.18 têm os seguintes significados: PODE_LECIONAR relaciona uma disciplina aos professores que podem lecionar essa disciplina, LECIONOU_DURANTE relaciona um semestre aos professores que lecionaram alguma disciplina durante esse semestre, e OFERECIDA_DURANTE relaciona um semestre às disciplinas oferecidas durante esse semestre por qualquer professor. Esses relaciona­ mentos ternários e binários representam informações diferentes, mas certas restrições deverão ser mantidas entre os relacionamentos. Por exemplo, uma instância de rela­ cionamento (p, s, d) nào deve existir em OFERECE, a menos que exista uma instância (p, s) cm LECIONOU_DURANTE, uma instância (s, d) em OFERECIDA_DURANTE e uma instância (p, d) em PODE_LECIONAR. Contudo, a recíproca nem sempre é verdadeira: podemos ter instâncias (p, s), (s, d) e (p, d) nos três tipos de relacionamento binário sem a instância correspondente (p, s, d) em OFERECE. Observe que, neste exemplo, com base no significado dos relacionamentos, podemos deduzir as instâncias dc LECIONOU_DURANTE e OFERECIDA_DURANTE com base nas instâncias em OFERECE, mas não podemos deduzir as instâncias de PODEJ.ECIONAR; portanto, LECIONOU.DURANTE e OFERECIDA DURANTE são redundantes e podem ser omitidas.

Capitulo 3

Modelagem de dados usando o modelo Entidade-Relacionamento (ER) 83

Figura 3.18 Outro exemplo de tipos de relacionamento ternário versus binário.

Embora em geral três relacionamentos binários não possam substituir um relaciona­ mento ternário, eles podem fazer isso sob certas restrições adicionais. Em nosso exemplo, se o relacionamento PODE_LECIONAR for 1:1 (um professor pode lecionar uma disciplina e uma disciplina pode ser lecionada por apenas um professor), então o relacionamento ternário OFERECE pode ser omitido porque ele pode ser deduzido pelos três relacionamen­ tos binários PODEJ.ECIONAR, LECIONOU.DURANTE e OFERECIDA_DURANTE. O projetista do esquema precisa analisar o significado de cada situação específica para decidir quais dos tipos de relacionamento binário c ternário são necessários. Observe que é possível ter um tipo de entidade fraca com um ternário (ou w-ário) identificando o tipo de relacionamento. Nesse caso, o tipo de entidade fraca pode ter uãrios tipos de entidade proprietários. Um exemplo é mostrado na Figura 3.19. Ele mos­ tra parte de um banco de dados que registra candidatos para entrevistas de emprego em diversas empresas, que podem fazer parte de um banco de dados da agência de emprego. Nos requisitos, um candidato pode ter várias entrevistas com a mesma empresa (por exemplo, com diferentes departamentos ou em datas separadas), mas uma oferta de emprego é feira com base em uma das entrevistas. rXqui, ENTREVISTA é representada como uma entidade fraca com dois proprietários CANDIDATO e EMPRESA,e com a chave parcial Dep_data. Uma entidade ENTREVISTA é identificada exclusiva mente por um candidato, uma empresa e a combinação de data c departamento da entrevista.

Figura 3.19 Um tipo de entidade fraca ENTREVISTA com um tipo de relacionamento de identificação ternário.

84 Sistemas de banco de dados

3.9.2 Restrições sobre relacionamentos ternários (ou de grau mais alto) Existem duas notações para especificar restrições estruturais sobre relacionamentos w-ários, e elas especificam restrições diferentes. Assim, ambas devem ser itsadas se for importante determinar totalmente as restrições estruturais sobre um relacionamento ternário ou de grau maior. A primeira notação é baseada na nota­ ção de razão de cardinalidade dos relacionamentos binários exibidos na Figura 3.2. Aqui, 1, M ou N é especificado em cada arco de participação (os símbolos M e N significam muitos ou qualquer número)}'' Vamos ilustrar essa restrição usando o relacionamento SUPRIMENTO da Figura 3.17. Lembre-se de que o conjunto de relacionamento de SUPRIMENTO é um conjunto de instâncias de relacionamento (/, /, p), em que fé um FORNECEDOR, j é um PROJETO e p é uma PECA. Suponha que exista a restrição de que, para determi­ nada combinação de projero-peça, somente um fornecedor será usado (somente um fornecedor abastece determinado projeto com determinada peça). Nesse caso, colocamos 1 na participação de FORNECEDOR, e M, N nas participações de PROJETO, PECA na Figura 3.17. Isso especifica a restrição dc que uma combinação em particular (/', p) pode aparecer no máximo uma vez no conjunto de relaciona­ mento, pois cada combinação (PROJETO, PECA) desse tipo determina de maneira exclusiva um único fornecedor. Logo, qualquer instância dc relacionamento

(A /’» p) é identificada exclusivamente no conjunto de relacionamentos por sua combinação (/, p), que torna (/, p) uma chave para o conjunto de relacionamen­ tos. Nessa notação, as participações que têm 1 especificado nelas não precisam fazer parte da chave de identificação para o conjunto dc relacionamentos.15 16 Sc todas as três cardinalidadcs forem M ou N, a chave será a combinação dc todos os três participantes. A segunda notação é baseada na notação (min, max) exibida na Figura 3.15 para relacionamentos binários. Um (min, max) cm uma participação aqui especifica que cada entidade está relacionada a pelo menos min e no máximo max instâncias de relacionamento no conjunto de relacionamentos. Essas restrições não têm influên­ cia na determinação da chave de um relacionamento w-ário, no qual n > 2,17 mas especificam um tipo diferente de restrição, que faz restrições sobre o número dc instâncias de relacionamento de que cada entidade participa.

3.10 Outro exemplo: um banco de dados UNIVERSIDADE Apresentamos agora outro exemplo, um banco de dados UNIVERSIDADE, para ilustrar os conceitos de modelagem ER. Suponha que seja necessário um banco de dados para acompanhar as matrículas dc aluno cm disciplinas c as notas finais dos

15 Esta notação nos permite determinar a chave da no Capítulo 9.

relação do relacionamento, conforme discutiremos

16 Isso também c verdadeiro para razões dc cardinalidade dos relacionamentos binários. 17 As restrições (min, max) podem determinar as chaves para relacionamentos binários.

Capitulo 3

Modelagem de dados usando o modelo Entidade-Relacionamento (ER) 85

alunos. Depois de analisar as regras do minimundo e as necessidades dos usuários, dererminaram-se os requisitos para esse banco de dados da seguinte forma (para resu­ mir, mostramos os nomes de tipo de entidade e atributo escolhidos para o esquema

conceituai entre parênteses, enquanto descrevemos os requisitos; os nomes de tipo de relacionamento aparecem apenas no diagrama do esquema ER):

■ A universidade é organizada em faculdades (FACULDADE), e cada faculdade tem um nome exclusivo (Nome_faculdade), uma sala do escritório principal (Salajaculdade) e telefone (Telefonejaculdade), e um membro em particular que é o reitor. Cada faculdade administra uma série dc departamentos acadêmicos (DEPARTAMENTO). Cada departamento tem um nome exclusivo (Nome_departamento), um código numérico exclusivo (Cod_departamento), uma sala do

escritório principal (Sala_departamento) e telefone (Telefone_departamento), e um membro em particular que dirige o departamento. Acompanhamos a data de início (Datajnicio) quando esse membro da faculdade começou a dirigir o departamento. ■ Um departamento disponibiliza uma série de disciplinas (DISCIPLINA), cada uma com um nome de disciplina exclusivo (Nome_disciplina), um código numérico exclusivo (Cod_disciplina), um nível de disciplina (pode ser codificado como 1 para o nível de primeiro ano, 2 para o segundo ano, 3 para júnior, 4 para sênior, 5 para o nível mestrado e 6 para doutorado), horas de crédito da disciplina (Créditos) e uma descrição da disciplina (Descricao). O banco de dados também registra os professores (PROFESSOR); e cada professor tem um identificador exclu­ sivo (Cod_professor), nome (Nome_professor), escritório (Sala_professor), telefone (Telefone.professor) e pontuação (Pontuacao); além disso, cada professor trabalha para um departamento acadêmico principal.

■ O banco de dados manterá dados do aluno (ALUNO) e armazenará o nome de cada um l(Nome_aluno, composto de primeiro nome (Primeiro_nome),nome do meio (Nome_meio), sobrenome (Ultimo_nome)], identificação do aluno (Matricula, exclusivo para cada aluno), endereço (Endereço), telefone (Telefone.aluno),código do curso (Curso) e data de nascimento (Data_nascimento). Um aluno é designado a um departamento acadêmico principal, que deverá registrar as notas do aluno em cada turma que ele tiver concluído. ■ As disciplinas são oferecidas como turmas (TURMA). Cada turma está relacio­ nada a uma única disciplina e a um único professor, e possui um identificador de turma exclusivo (Cod.turma). Uma turma também possui um número de turma (Numero_turma: este é codificado como 1,2, 3,... para várias turmas oferecidas durante o mesmo período e ano do semestre), período (Periodo), ano (Ano), sala (Sala_aula: esta é codificada como uma combinação de código de prédio (Prédio) e número de sala (Numero.sala) dentro do prédio] e dias/horas (Horario.semanal: por exemplo, ‘Segunda, Quarta e Sexta 9:00-9:50' ou ‘Terça e Sexta 15:30-17:20' — restrito a apenas valores de dias/horários permitidos). (Nota: o banco de dados registrará todas as turmas oferecidas durante os últimos anos, além das ofertas atuais. Cod_turma é exclusivo para todas as turmas, não apenas aquelas para um semestre em particular.) O banco de dados registra os alunos em cada turma e a nota é registrada quando estiver disponível (esse é um relacionamento muitos para muitos entre alunos e turmas). Uma turma precisa ter pelo menos cinco alunos.

86 Sistemas de banco de dados O diagrama ER para esses requisitos pode ser visto na Figura 3.20, usando a notação diagramática ER min-max. Observe que, para o tipo de entidade TURMA, só mostramos Cod_turma como uma chave sublinhada, mas, em razão das restrições do minimundo, várias outras combinações de valores precisam ser exclusivas para cada entidade de turma. Por exemplo, cada uma das seguintes combinações precisa ser exclusiva, com base nas restrições típicas do minimundo: 1. [NumerO-turma, Periodo, Ano, Cod.disciplina (da DISCIPLINA relacionada à TURMA)]: isso especifica que os números de turma de determinada disciplina precisam ser diferentes durante cada período e ano do semestre em particular.

2. (Periodo, Ano, Sala_aula, Horario_semanal): isso especifica que, em determinado período e ano do semestre, uma sala de aula não pode ser usada por duas turmas diferentes nos mesmos dias/horas. 3. [Periodo, Ano, Horario_semanal, Cod_professor (do PROFESSOR lecionando para a TURMA)]: isso especifica que, em determinado período e ano do semestre, um professor não pode lecionar para duas turmas nos mesmos horários semanais. Observe que essa regra não se aplicará se o professor tiver um meio de lecionar para duas turmas combinadas na universidade em particular. Cftome_professoF} ^Sala_facu Idade

Cjontuacao

od professor FACULDADE

(0,N)

PROFESSOR |

TEM REITOR

(1,1)

(0,1)

(0,N)

Data inicio

(0,1 IFM D RFT

(1,1)

VEICULO. CARRO

VEICULO

d

Numero eixos

CAMINHAO

4.3 Restrições e características das hierarquias de especialização e generalização Primeiro, vamos discutir as restrições que se aplicam a uma única especialização ou a uma única generalização. Para abreviar, nossa discussão refere-se apenas à especialização, embora se aplique também à generalização. Depois, vamos discutir as diferenças entre reticidado (múltipla herança) e hierarquias (herança simples) de espccialização/gcneralização,e detalhar as diferenças entre os processos dc especia­ lização e generalização durante o projeto de esquema dc banco dc dados conceituai.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

4.3.1 Restrições sobre especialização e generalização Em geral, podemos ter várias especializações definidas no mesmo ripo de enti­ dade (ou superclasse), como mostra a Figura 4.1. Nesse caso, as entidades podem pertencer a subclasses em cada uma das especializações. Uma especialização também pode consistir cm uma única subclasse, como a especialização {GERENTE} na Figura 4.1; em tal caso, não usamos a notação de círculo. Em algumas especializações, podemos determinar exatamente as entidades que se tornarão membros de cada subclasse ao colocar uma condição sobre o valor dc algum atributo da superclasse. Essas subclasses são chamadas subclasses definidas por predicado (ou definidas por condição). Por exemplo, se o tipo dc entidade FUNCIONÁRIO tiver um atributo Tipo_emprego, como mostra a Figura 4.4, podemos especificar a condição de membro na subclasse SECRETARIA pela condição (Tipo_emprego = ‘Secretaria'), que chamamos de predicado de defini­ ção da subclasse. Essa condição é uma restrição que especifica exatamente que aquelas entidades do tipo de entidade FUNCIONÁRIO, cujo valor de atributo para Tipo_emprego é ‘Secretaria’, pertencem à subclasse. Indicamos uma subclasse definida pelo predicado escrevendo a condição de predicado ao lado da linha que conecta a subclasse ao círculo de especialização. Se todas as subclasses em uma especialização tiverem sua condição de membro no mesmo atributo da superclasse, a própria especialização é chamada dc especia­ lização definida por atributo, c o atributo c chamado dc atributo dc definição da especialização.6 Nesse caso, todas as entidades com o mesmo valor para o atributo pertencem à mesma subclasse. Indicamos uma especialização definida por atributo escrevendo o nome do atributo dc definição próximo ao arco que vai do círculo à superclasse, como mostra a Figura 4.4. Quando não temos uma condição para determinar os membros em uma subclasse, diz-se que esta é definida pelo usuário. A condição de membro nessa subclasse é determinada pelos usuários do banco de dados quando eles aplicam a operação para incluir uma entidade à subclasse; logo, a condição de membro é especificada indi­ vidualmente para cada entidade pelo usuário, e não por qualquer condição que possa ser avaliada automaticamente. Duas outras restrições podem se aplicar a uma especialização. A primeira é a restrição de disjunção (ou desconexão), que especifica que as subclasses da

Tal atributo é chamado dc discriminador em terminologia UML

103

104 Sistemas de banco de dados especialização devem ser disjuntas. Isso significa que uma entidade pode ser um membro de no máximo uma das subclasses da especialização. Uma especialização definida por atributo implica a restrição de disjunção (se o atributo usado para definir o predicado de membro for de valor único). A Figura 4.4 ilustra esse caso, onde o d no círculo significa disjunção. A notação d também se aplica a subclasses definidas pelo usuário de uma especialização que precisa ser disjunta, conforme ilustrado pela especialização {FUNCIONARIO_HORISTA, FUNCIONARIO.MENSAL} na Figura 4.1. Se as subclasses não forem restringidas a serem disjuntas, seus con­ juntos de entidades podem ser sobrepostos; ou seja, a mesma entidade (mundo real) pode ser um membro de mais de uma subclasse da especialização. Esse caso, que é o padrão, é exibido colocando-se um o (de overlapping) no círculo, como mostra a Figura 4.5. A segunda restrição sobre a especialização é chamada de restrição de completude (ou totalidade), que pode ser total ou parcial. Uma restrição de especialização total especifica que toda entidade na superclasse precisa ser um membro de pelo menos uma subclasse na especialização. Por exemplo, se rodo FUNCIONÁRIO tiver de ser um FUNCIONARIO.HORISTA ou um FUNCIONARIO.MENSAL, então a especialização {FUNCIONARIO_HORISTA, FUNCIONARIO_MENSAL} da Figura 4.1 é uma especialização total de FUNCIONÁRIO. Isso é mostrado nos diagramas EER com uma linha dupla para conectar a superclasse ao círculo. Uma linha simples é utilizada para exibir uma especialização parcial, que permite que uma entidade não pertença a qualquer uma das subclasses. Por exemplo, se algumas entidades FUNCIONÁRIO não pertencerem a nenhuma das subclasses (SECRETARIA, ENGENHEIRO, TÉCNICO} nas figuras 4.1 c 4.4, então essa especialização será parcial. Observe que as restrições de disjunção e completude são independentes. Logo, temos quatro restrições possíveis na especialização: ■ Disjunção, total. ■ Disjunção, parcial. ■ Sobreposição, total. ■ Sobreposição, parcial.

Naturalmenre, a restrição correra é determinada com base no significado do mundo real que se aplica a cada especialização. Em geral, uma superclasse identi­ ficada por meio do processo de generalização costuma ser total, pois a superclasse é derivada das subclasses e, portanto, contém apenas as entidades que estão nas subclasses. ^Descricao

Preco

PECA FABRICADA |

PECA_COMPRADA

Figura 4.5 Notação de diagrama EER para uma especialização sobreposta (não disjunta).

" A notação de usar linhas simples ou duplas é semelhante à da participação parcial ou total de um ripo de entidade em um tipo de relacionamento, conforme descrito no Capítulo 3.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

Certas regras de inserção e exclusão se aplicam à especialização (e generalização) como uma consequência das restrições especificadas anteriormente. Algumas dessas regras são as seguintes:

■ Excluir uma entidade de uma superclasse implica que ela seja automaticamente excluída de todas as subclasses às quais pertence. ■ Inserir uma entidade em uma superclasse implica que a entidade seja obrigato­ riamente inserida em todas as subclasses definidas por predicado (ou definidas por atributo) para as quais a entidade satisfaz a definição do predicado. ■ Inserir uma entidade em uma superclasse de uma especialização total implica que a entidade é obrigatoriamente inserida cm pelo menos uma das subclasses da especialização.

O leitor é encorajado a fazer uma lista completa das regras para inserções e exclusões para os vários tipos de especialização.

4.3.2 Hierarquias e reticulado da especialização e generalização A própria subclasse pode ter mais subclasses especificadas nela, formando uma hierarquia ou um reticulado de especializações. Por exemplo, na Figura 4.6, ENGENHEIRO é uma subclasse de FUNCIONÁRIO e também uma superclasse de GERENTE-ENGENHEIRO; isso representa a restrição do mundo real de que cada gerente engenheiro precisa ser um engenheiro. Uma hierarquia de especialização tem a restrição dc que cada subclasse participa como uma subclasse em apenas um relacionamento dc classc/subclasse; ou seja, cada subclasse tem apenas um pai, que resulta em uma estrutura dc árvore ou hierarquia estrita. Ao contrário, para um reticulado de especialização, uma subclasse pode ser uma subclasse em mais de um relacionamento de classe/subclasse. Assim, a Figura 4.6 é um reticulado. A Figura 4.7 mostra outro reticulado dc especialização dc mais de um nível. Este pode ser parte de um esquema conceituai para um banco dc dados UNIVERSIDADE. Observe que esse arranjo teria sido uma hierarquia, exceto para a subclasse ALUNO_COLABORADOR, que é uma subclasse em dois relacionamentos de classe/ subclasse distintos.

Figura 4.6 Um reticulado de especialização com a subclasse compartilhada GERENTE-ENGENHEIRO.

105

106 Sistemas de banco de dados

' Títulos ' Ano .

■: Titulo d:

ADMINISTRATIVO

Figura 4.7 Cargo Um reticulado de " especialização com herança múltipla para um banco de dados UNIVERSIDADE.

PROFESSOR

i Curso_tituTó> ------- 7-" d

Porcentagem_te m po.

ALUNO_ (COLABORADOR

1 ALUNO_ POSGRADUACAO ' Titu 1o_progra ma J.-

■’ PontuacaoJ

ALUNO_ GRADUACAO Tipo_aluno ■

dj Projeto COLABORADOR_PESQUISA

-

^Disciplina;

COLABORADOR.ENSINO

Os requisitos para a parte do banco de dados UNIVERSIDADE mostrado na Figura 4.7 são os seguintes: 1. O banco dc dados registra três tipos dc pessoas: funcionários, ex-alunos e alunos. Uma pessoa pode pertencer a um, dois ou a todos esses três tipos. Cada pessoa tem um nome, CPF, sexo, endereço e data de nascimento.

2. Cada funcionário tem um salário, e existem três tipos dc funcionários: professog administrativo e aluno colaborador. Cada funcionário pertence a exatamente um desses tipos. Para cada ex-aluno, é mantido um registro do título ou dos títulos que ele obteve na universidade, incluindo o nome do título, o ano em que foi concedido c o curso cm que o aluno se formou. Cada aluno tem um departamento principal. 3. Cada membro professor tem uma pontuação, enquanto cada membro adminis­ trativo tem um cargo administrativo. Os alunos colaboradores sào classificados ainda como colaboradores dc pesquisa ou colaboradores dc ensino, c a por­ centagem dc tempo cm que eles trabalham é registrada no banco de dados. Os colaboradores de pesquisa têm seu projeto de pesquisa armazenado, ao passo que os colaboradores de ensino têm a disciplina atual em que trabalham. 4. Os alunos são classificados ainda como de pós-graduação ou graduação, com os atributos específicos de título do programa (mestrado, doutorado, N1BA etc.) para alunos de pós-graduaçào formados e o tipo de aluno (novato, segundo ano etc.) para os alunos dc graduação. Na Figura 4.7, todas as entidades de pessoa representadas no banco de dados são membros do ripo de entidade PESSOA, que é especializado nas subclasses (FUNCIONÁRIO, EX_ALUNO, ALUNO}. Essa especialização é sobreposta; por exem­ plo, um ex-aluno também pode ser um funcionário e ainda pode ser um aluno bus­ cando um título avançado. A subclasse ALUNO c a superclasse para a especialização

Capítulo 4 O modelo Entidade-Relaoonamento Estendido (EER)

(ALUNO-POSGRADUACAO, ALUNO_GRADUACAO),enquanto FUNCIONÁRIO é a super­ classe para a especialização {ALUNO.COLABORADOR, PROFESSOR, ADMINISTRATIVO). Observe que ALUNO_COLABORADOR também é uma subclasse de ALUNO. Finalmente, ALUNO-COLABORADOR é a superclasse para a especialização em {COLABORADORPESQUISA, COLABORADOR-ENSINO). Em tal reticulado ou hierarquia de especialização, uma subclasse herda os atri­ butos não só de sua superclasse direta, mas também dc todas as suas superclasses predecessoras, até chegar à raiz da hierarquia ou reticulado, se for preciso. Por exemplo, uma entidade em ALUNO_POSGRADUACAO herda todos os atributos dessa entidade como um ALUNO e como uma PESSOA. Observe que uma entidade pode existir em vários nós folha da hierarquia, em que um nó folha é uma classe que nào tent subclasses próprias. Por exemplo, um membro dc ALUNO_GRADUACAO também pode ser um membro de COLABORADOR_PESQUISA. Uma subclasse com mais de uma superclasse é chamada de subclasse comparti­ lhada. como GERENTE-ENGENHEIRO na Figura 4.6. Isso leva ao conceito conhecido como herança múltipla, na qual a subclasse compartilhada GERENTE_ENGENHEIRO herda dirctamentc atributos e relacionamentos dc múltiplas superclasses. Observe que a existência de pelo menos uma subclasse compartilhada leva a um reticulado (e, por­ tanto, à herança múltipla). Sc não existisse qualquer subclasse compartilhada, teríamos uma hierarquia em vez de um reticulado, e ha veria somente a herança simples. Uma regra importante relacionada à herança múltipla pode ser ilustrada pelo exemplo da subclasse compartilhada ALUNO_COLABORADOR na Figura 4.7, que herda atributos de FUNCIONÁRIO e ALUNO. Aqui, tanto FUNCIONÁRIO quanto ALUNO herdam os mesmos atributos de PESSOA. A regra declara que, se um atributo (ou relacionamento) originado na mesma superclasse (PESSOA) é herdado mais de uma vez por caminhos diferentes (FUNCIONÁRIO e ALUNO) no reticulado, então ele deverá ser incluído apenas uma vez na subclasse compartilhada (ALUNO-COLABORADOR). Logo, os atributos de PESSOA são herdados apenas uma vez na subclasse ALUNO_COLABORADOR da Figura 4.7. E importante observar aqui que alguns modelos c linguagens são limitados à herança simples e não permitem a herança múltipla (subclasses compartilhadas). Também é importante observar que alguns modelos não permitem que uma enti­ dade tenha tipos múltiplos, e, portanto, uma entidade pode ser membro de apenas uma classe folha.8 Em tal modelo, é necessário criar subclasses adicionais como nós folha para cobrir todas as combinações possíveis de classes que podem ter alguma entidade que pertença a todas essas classes simultaneamente. Por exemplo, em uma especialização de sobreposição de PESSOA para {FUNCIONÁRIO, EX_ALUNO, ALUNO) (ou {F, E, A) para abreviar), seria necessário criar sete subclasses de PESSOA a fim de cobrir todos os tipos de entidades possíveis: F, E, A, F_E, F_A, E_A e F_E_A. Obviamente, isso pode gerar uma complexidade extra. Embora tenhamos usado a especialização para ilustrar nossa discussão, concei­ tos semelhantes se aplicam igualmente à generalização, conforme mencionamos no início desta seção. Logo, também podemos falar de hierarquias de generalização e reticulados de generalização.

4.3.3 Utilizando especialização e generalização no refinamento de

esquemas conceituais Agora, vamos detalhar as diferenças entre os processos de especialização e gene­ ralização, c como eles são usados para refinar os esquemas conceituais durante o

* Em alguns modelos, a classe é restringida ainda mais para ser um reticulado.

nó folha

na hierarquia ou no

107

108 Sistemas de banco de dados projeto conceituai do banco de dados. No processo de especialização, os projetistas de banco dc dados normalmcnte começam com um tipo de entidade e depois definem subclasses do tipo de entidade pela especialização sucessiva; ou seja, eles repetida­ mente definem agrupamentos mais específicos do ripo de entidade. Por exemplo, ao projetar o reticulado de especialização da Figura 4.7, primeiro podemos especificar um tipo de entidade PESSOA para um banco de dados de universidade. Depois, des­ cobriremos que três tipos de pessoas serão representados no banco dc dados: funcio­ nários da universidade, ex-alunos e alunos, e criamos a especialização {FUNCIONÁRIO, EX_ALUNO, ALUNO). Escolhemos a restrição de sobreposição, pois uma pessoa pode pertencer a mais de uma das subclasses. Especializamos FUNCIONÁRIO ainda mais em (ADMINISTRATIVO, PROFESSOR, ALUNO_COLABORADOR) e especializamos ALUNO em {ALUNO_POSGRADUACAO, ALUNO_GRADUACAO). Por fim, especializamos ALUNO.COLABORADOR em (COLABORADOR.PESQUISA, COLABORADOR.ENSINO). Esse processo é chamado de refinamento conceituai de cima para baixo (top-down). Até aqui, temos uma hierarquia; depois, observamos que ALUNO_COLABORADOR é uma subclasse compartilhada, pois ela também é uma subclasse de ALUNO, o que leva ao reticulado. E possível chegar à mesma hierarquia ou reticulado vindo de outra direção. Nesse caso, o processo envolve a generalização, em vez da especialização, e cor­ responde a uma síntese conceituai de baixo para cima (bottom-up). Por exemplo, os projetistas de banco de dados primeiro podem descobrir tipos de entidade como ADMINISTRATIVO, PROFESSOR, EX.ALUNO, ALUNO_POSGRADUACAO, ALUNO. GRADUACAO, COLABORADOR.PESQUISA, COLABORADOR.ENSINO, e assim por diante; depois, eles podem generalizar (ALUNO.POSGRADUACAO, ALUNO.GRADUACAO) para ALUNO; daí generalizar {COLABORADOR.PESQUISA, COLABORADOR.ENSINO) para ALUNO.COLABORADOR; então generalizar (ADMINISTRATIVO, PROFESSOR, ALUNOCOLABORADOR) para FUNCIONÁRIO; e, finalmente, generalizar (FUNCIONÁRIO, EXALUNO, ALUNO) para PESSOA. O projeto final de hierarquias ou reticulados resultantes dc qualquer processo pode ser idêntico; a única diferença relaciona-se à maneira ou ordem em que as superclasses e subclasses do esquema foram criadas durante o processo de projeto. Na prática, é provável que seja empregada uma combinação dos dois processos. Observe que a noção de representar dados e conhecimento usando hierarquias e reticulados de superclasse/subclasse é muito comum cm sistemas baseados cm conhecimento e sistemas especialistas, que combinam tecnologia de banco de dados com técnicas de inteligência artificial. Por exemplo, esquemas de representação do conhecimento baseados em quadro são muito semelhantes às hierarquias de classes. A especialização também é comum nas metodologias de projeto de engenharia de software baseadas no paradigma orientado a objeto.

4.4 Modelagem dos tipos UNIÃO usando categorias As vezes é necessário representar uma coleção dc entidades a partir de diferentes tipos dc entidade. Neste caso, a subclasse representará uma coleção de entidades que é um subconjunto da UNIÃO de entidades de tipos distintos; chamamos essa subclasse de tipo de união ou categoria.9 Por exemplo, suponha que tenhamos três tipos de entidade: PESSOA, BANCO e EMPRESA. Em um banco de dados para registro de veículos a motor, o proprietário dc um veículo pode ser uma pessoa, um banco (mantendo uma alienação sobre um 9 Nosso uso do termo categoria é baseado no modelo ECR -categoria-relacionamento) (Elmasri et al., 1985).

iemity-category-relationship, ou entidade

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

109

veículo) ou uma empresa. Precisamos criar uma classe (coleção de entidades) que inclua entidades de todos os três tipos para desempenhar o papel de proprietário de veículo. Uma categoria (tipo de união) PROPRIETÁRIO, que é uma subclasse da UNIÃO dos três conjuntos de entidades de EMPRESA, BANCO e PESSOA, pode ser criada para essa finalidade. Exibimos categorias no diagrama EER, como mostra a Eigura 4.8. As superclasses EMPRESA, BANCO e PESSOA são conectadas ao círculo com o símbolo •, que significa operação de união de conjuntos. Um arco com o símbolo de subconjunto conecta o círculo à categoria (subclasse) PROPRIETÁRIO. Na Figura 4.8, temos duas categorias: PROPRIETÁRIO, que é uma subclasse (subconjunto) da união de PESSOA, BANCO e EMPRESA; e VEICULO_REGISTRADO, que é uma subclasse (subconjunto) da união de CARRO e CAMINHAO. Uma categoria tem duas ou mais superclasses que podem representar tipos de entidade distintos, enquanto outros relacionamentos de superclasse/subclasse sempre têm uma única superclasse. Para entender melhor a diferença, podemos comparar uma categoria, como PROPRIETÁRIO (Figura 4.8), com a subclasse compartilhada GERENTE-ENGENHEIRO (Figura 4.6). Esta última é uma subclasse de cada unia das três superclasses ENGENHEIRO, GERENTE e FUNCIONARIO_MENSAL, de modo que uma entidade que é um membro dc GERENTE_ENGENHEIRO deva existir cm todas as três coleções. Isso representa a restrição de que um gerente de engenharia precisa ser um ENGENHEIRO, um GERENTE e um FUNCIONARIO.MENSAL; ou seja, o conjunto de

Figura 4.8 Duas categorias (tipos de união): PROPRIETÁRIO e VEICULO-REGISTRADO.

110 Sistemas de banco de dados entidades GERENTE.ENGENHEIRO é um subconjunto da interseção dos conjuntos de entidades. Por sua vez, uma categoria é um subconjunto da união de suas superclas­ ses. Logo, uma entidade que é um membro de PROPRIETÁRIO deve existir em apenas uma das superclasses. Isso representa a restrição de que um PROPRIETÁRIO pode ser uma EMPRESA, um BANCO ou uma PESSOA na Figura 4.8. A herança de atributo funciona de maneira mais seletiva no caso de categorias. Por exemplo, na Figura 4.8, cada entidade PROPRIETÁRIO herda os atributos de uma EMPRESA, uma PESSOA ou um BANCO, dependendo da superclasse à qual a entidade pertence. Por sua vez, uma subclasse compartilhada,como GERENTE_ENGENHEIRO (Figura 4.6), herda todos os atributos de suas superclasses FUNCIONARIO.MENSAL, ENGENHEIRO e GERENTE. É interessante observar a diferença entre a categoria VEICULO_REGISTRADO (Figura 4.8) e a superclasse generalizada VEICULO (Figura 4.3(b)). Na Figura 4.3(b), todo carro e todo caminhão é um VEICULO; mas, na Figura 4.8, a categoria VEICULO.REGISTRADO inclui alguns carros e alguns caminhões, mas não necessariamente todos eles (por exemplo, alguns carros ou caminhões podem não ser registrados). Em geral, uma especialização ou generalização como a da Figura 4.3(b),se fosse parcial, não impediría VEICULO de conter outros tipos de entidades, como motocicletas. Porém, uma categoria como VEICULO_REGISTRADO na Figura 4.8 implica que somente carros e caminhões, mas não outros tipos de entidades, possam ser membros de VEICULO_REGISTRADO. Uma categoria pode ser total ou parcial. Uma categoria total mantém a união de todas as entidades em suas superclasses, enquanto a parcial pode manter um subconjunto da união. Uma categoria total é representada cm diagrama por uma linha dupla que conecta a categoria e o círculo, ao passo que uma categoria parcial é indicada por uma linha simples. /\s superclasses de uma categoria podem ter diferentes atributos de chave, conforme demonstrado pela categoria PROPRIETÁRIO da Figura 4.8, ou podem ter o mesmo atributo de chave, conforme demonstrado pela categoria VEICULO. REGISTRADO. Observe que, se uma categoria é total (não parcial), ela pode ser representada alternativamente como uma especialização total (ou uma generaliza­ ção total). Nesse caso, a escolha de qual representação usar é subjetiva. Se as duas classes representam o mesmo ripo de entidades e compartilham diversos atributos, incluindo os mesmos atributos-chave, a especialização/generalização é preferida; caso contrário, a categorização (tipo dc união) é mais apropriada. E importante observar que algumas metodologias dc modelagem não possuem tipos de união. Nesses modelos, um tipo de união precisa ser representado de maneira indireta (ver Seção 9.2).

4.5 Um exemplo de esquema UNIVERSIDADE de EER, opções de projeto e definições formais Nesta seção, primeiro vamos dar um exemplo de esquema de banco de dados no modelo EER para ilustrar o uso dos diversos conceitos discutidos aqui e no Capítulo 3. Depois, vamos discutir as escolhas de projeto para esquemas conceituais e, por fim, resumir os conceitos do modelo EER e defini-los formalmente da mesma maneira que fizemos com os conceitos do modelo ER básico, no Capítulo 3.

4.5.1 Um exemplo do banco de dados UNIVERSIDADE Considere um banco de dados UNIVERSIDADE contendo requisitos diferentes do banco dc dados UNIVERSIDADE apresentado na Seção 3.10. Esse banco de dados regis­ tra alunos e seus cursos, históricos e registro, bem como as ofertas de disciplina da

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER) universidade. O banco de dados também registra os projetos de pesquisa patrocinados dos professores e dos alunos de pós-graduação. Esse esquema aparece na Figura 4.9. Uma discussão dos requisitos que levaram a esse esquema pode ser vista em seguida. Para cada pessoa, o banco de dados mantém informações sobre o nome dela [Nome], número do Cadastro de Pessoa Física [Cpf], endereço [Endereço], sexo [Sexo] e data de nascimento [Data_nascimento]. Duas subclasses do tipo de entidade PESSOA são identificadas: PROFESSOR e ALUNO. Atributos específicos de PROFESSOR são a

^Nome_meio Rua

Sexo

Cidade

Fs’adn Cec

Numero Endereço

Nome

Tipo_aluno

Salario

CSaía professor)

Nivel

Titulo

Ano

PROFESSOR

ALUNO

Titu os

ftRTC PA RANCA

S PC) N SAVE

ALUNO POSGRADUACAO

Numero

Agencia NCULU StCUNDAK (J

BOLSA

ata inicia

N meio

M

APO U

-’FRTFNC F

edicaca^)

NCULO PR NC PA

M

u

Nota

PROFESSOR PESQUISADOR~|

MATR C l ADO

vi

LUKbUL

:SIA D Rt OK

FC ONA

prURMA_ATUÃT~

eriodo = Periodo atual ífl Ano = Ano atual

TURMA

DEPARTAMENTO

CJa I a_d e pa rta me nto FACULDADc

^Nome_facu Idade

J SPUN B L ZA

^t^

Figura 4.9 Esquema conceituai EER para um banco de dados UNIVERSIDADE.

DISCIPLINA

om e_d i sei píin^^>

111

112 Sistemas de banco de dados classificação [Nivel] (assistente, associado, adjunto, pesquisador, visitante etc.), sala [Sala_professor], telefone do professor [Telefone_professor] e salário [Salario]. Todos os professores estão relacionados a departamento(s) acadêmico(s) ao(s) qual(is) eles estão afiliados [PERTENCE] (um membro do corpo docente pode estar associado a vários departamentos, de modo que o relacionamento é M:N). Um atributo específico de ALUNO é [Tipo_aluno] (novato = 1, segundo ano = 2,..., mestrado = 5, doutorado = 6). Cada ALUNO também está vinculado a seus departamentos principal e secundário (se forem conhecidos) [VINCULO_PRINCIPAL] e [VINCULO_SECUNDARIO], às turmas da disciplina que está frequentando atualmente [MATRICULADO] e às disciplinas concluídas [CURSOU]. Cada instância de CURSOU inclui a nota que o aluno recebeu [Nota] em uma turma de uma disciplina. ALUNO-POSGRADUACAO é uma subclasse de ALUNO, com o predicado de defini­ ção (Tipo_aluno = 5 ou 6). Para cada aluno de pós-graduação, mantemos uma lista dos títulos anteriores em um atributo composto, multivalorado [TitulosJ. Também relacionamos o aluno formado a um orientador acadêmico [ORIENTA] e a um comitê de tese [PARTICIPA_BANCA], se existir. Um departamento acadêmico tem os atributos nome [Nome_departamento], telefone [Telefone_departamento] e número da sala [Sala_departamento], e está rela­ cionado ao membro acadêmico que é seu ESTA_DIRETOR e à faculdade à qual é admi­ nistrado [ADMINISTRADO]. Cada faculdade tem como atributos o nome da faculdade [Nome.facuidade], o número da sala [Sala.faculdade] e o nome de seu reitor [Reitor]. Uma disciplina tem os atributos número da disciplina [Cod_disciplina|, nome da disciplina [Nome_disciplina] e descrição da disciplina [Descricao]. São ofereci­ das várias turmas de cada disciplina, com cada uma tendo os atributos código da turma [Cod_turma], o ano e o período em que foi oferecida ([Ano] e [Período]).10Os códigos de turma identificam cada uma de maneira exclusiva. As turmas oferecidas durante o período atual estão em uma subclasse TURMA_ATUAL de TURMA, com o predicado de definição Periodo = Periodo_atual e Ano = Ano_atual. Cada turma está relacionada ao professor que lecionou ou está lecionando ([LECIONA]), se ele estiver no banco de dados. A categoria PROFESSOR.PESQUISADOR é um subconjunto da união de PROFESSOR e ALUNO.POSGRADUACAO e inclui todos os professores, bem como alunos de pósgraduação que recebem apoio por ensino ou pesquisa. Finalmente, o tipo dc entidade BOLSA registra bolsas e contratos dc pesquisa outorgados à universidade. Cada bolsa tem os atributos de título da bolsa [Titulo], número da bolsa [Numero], agência de fomento [Agencia] e a data inicial [DataJnicialJ. Uma bolsa está relacionada a um docente responsável [RESPONSÁVEL] e a rodos os pesquisadores a que ele dá apoio [APOIO]. Cada instância de apoio tem como atributos a data inicial do apoio [Inicio], a data final do apoio (se for conhecida) [Termino] e a porcentagem do tempo gasto no projeto [Dedicacao] pelo pesquisador que recebe o apoio.

4.5.2 Escolhas de projeto para especialização/generalização Nem sempre é fácil escolher o projeto conceituai mais apropriado para uma aplicação de banco de dados. Na Seção 3.7.3, apresentamos algumas das questões típicas enfrentadas por um projetista ao escolher entre os conceitos de tipos de entidade, tipos dc relacionamento c atributos para representar uma situação cm particular do minimundo como um esquema ER. Nesta seção, vamos discutir as diretrizes e escolhas de projeto para os conceitos EER de especialização/generalização e categorias (tipos dc união). 10 Consideramos que o sistema de exemplo.

período,

em vez de

semestre,

seja utilizado na universidade do

Capítulo 4 O modelo Entidade-Relaoonamento Estendido (EER)

Conforme mencionamos na Seção 3.7.3, o projeto conceituai do banco de dados deve ser considerado um processo de refinamento iterative, até que o projeto mais adequado seja alcançado. As orientações a seguir ajudam a guiar o processo de projeto para conceitos de EER:

■ Em geral, muitas especializações e subclasses podem ser definidas para tornar o modelo conceituai preciso. No entanto, a desvantagem é que o projeto se torna muito confuso. E importante representar apenas as subclasses que se julguem necessárias para evitar uma aglomeração extrema do esquema conceituai. ■ Se uma subclasse possui poucos atributos específicos (locais) e nenhum relacio­ namento específico, ela pode ser mesclada à superclasse. Os atributos específicos manteriam valores NULL para entidades que não são membros da subclasse. Um atributo de tipo poderia especificar se uma entidade é um membro da subclasse. ■ De modo semelhante, se todas as subclasses da especialização/generalização tiverem alguns atributos específicos e nenhum relacionamento específico, elas podem ser mescladas à superclasse e substituídas por um ou mais atributos de tipo que especificam a subclasse ou subclasses a que cada entidade pertence (ver Seção 9.2 para saber como esse critério se aplica aos bancos de dados relacionais). ■ Os tipos dc união e categorias gcralmentc devem ser evitados, a menos que a situação definitivamente justifique esse tipo de construção, o que ocorre em algu­ mas situações práticas. Se possível, tentamos modelar usando a especialização/ generalização conforme discutimos no final da Seção 4.4. ■ A escolha de restrições disjuntas/sobrepostas e totais/parciais sobre a especia­ lização/generalização é controlada pelas regras no minimundo que está sendo modelado. Se os requisitos não indicarem quaisquer restrições em particular, o padrão gcralmentc seria sobreposição c parcial, pois isso não especifica quaisquer restrições sobre a condição dc membro da subclasse.

Como um exemplo da aplicação dessas orientações, considere a Figura 4.6, na qual nenhum atributo específico (local) aparece. Poderiamos mesclar todas as sub­ classes no tipo de entidade FUNCIONÁRIO e acrescentar os seguintes atributos a ele: ■ Um atributo Tipo_emprego cujo conjunto de valores {‘Secretária', ‘Engenheiro’, ‘Técnico’| indicaria a qual subclasse cada funcionário pertence na primeira especialização. ■ Um atributo Forma_pagamento cujo conjunto de valores {‘Mensal’, ‘Horista’) indicaria a qual subclasse cada funcionário pertence na segunda especialização. ■ Um atributo É_gerente cujo conjunto de valores {‘Sim’,‘Não’) indicaria se uma entidade de funcionário individual é um gerente ou não.

4.5.3 Definições formais para os conceitos do modelo EER Agora, vamos resumir os conceitos do modelo EER e mostrar as definições for­ mais. Uma classe11 define um tipo de entidade e representa um conjunto dc coleções de entidades desse ripo; isso inclui qualquer uma das construções de esquema EER que correspondem às coleções de entidades, como tipos de entidade, subclasses, superclasses e categorias. Uma subclasse S é uma classe cujas entidades sempre pre­ cisam ser um subconjunto das entidades cm outra classe, chamada superclasse C do relacionamento superclassc/subclassc (ou E_UM). Indicamos tal relacionamento por C/S. Para tal relacionamento superclasse/subclasse, sempre devemos ter 11 O uso da palavra classe aqui sc refere à coleção (conjunto} dc entidades, que difere dc sua utilização mais comum nas linguagens de programação orientadas a objeto, como C++. Em C++, uma classe é uma definição de tipo estruturado com suas funções (operações) aplicáveis.

113

114 Sistemas de banco de dados SçC

Uma especialização Z = {Sp S„ SJ é um conjunto de subclasses que têm a mesma superclasse G; ou seja, G/S- é um relacionamento superclasse/subclasse para i = 1, 2,n. G é chamado de tipo de entidade generalizada (ou a superclasse da especialização, ou uma generalização das subclasses {SPS2,...» SJ). Z é considerada total se sempre (em qualquer ponto no tempo) tivermos

Ú S-=G i-l ‘ Caso contrário, Z é considerada parcial. Z é considerada disjunta se sempre tivermos

St A SJ = 0 (conjunto vazio) para / =# / Caso contrário, Z é considerada sobreposta. Uma subclasse S dc C é considerada definida por predicado se um predicado p sobre os atributos de C for usado para especificar quais entidades em C são membros de S; ou seja, S = C|pJ, onde Qp] é o conjunto de entidades em C que satisfazem p. Uma subclasse que não é definida por um predicado é chamada de definida pelo usuário. Uma especialização Z (ou generalização G) é considerada definida por atributo se um predicado (A = onde A c um atributo dc G c ci c um valor constante do domínio dc A, for usado para especificar a condição dc membro em cada subclasse S, em Z. Observe que, se ct * c. para i =£ j,e A for um atributo de único valoi; então a especialização será disjunta. Uma categoria Té uma classe que é um subconjunto da união de n que define as superclasses Dp D2, Dn, w > 1, podendo ser especificada formalmente da seguinte maneira:

T Ç (D, U D2 ... U DJ

Um predicado pt sobre os atributos de D- pode ser usado para especificar os membros dc cada D-que são membros dc T. Se um predicado for especificado sobre cada Dp obtemos T=(DI[p1]UD,[p2] ...UDjpJ)

Agora, devemos estender a definição dc tipo dc relacionamento dada no Capítulo 3, permitindo que qualquer classe — não apenas um tipo dc entidade — participe de um relacionamento. Logo, devemos substituir as palavras tipo de entidade por classe naquela definição. A notação gráfica de EER é coerente com ER porque todas as classes são representadas por retângulos.

4.6 Exemplo de outra notação: representando especialização e generalização em diagramas de classes em UML Agora, vamos discutir a notação UML para especialização/generalização e herança. Já apresentamos a notação e terminologia básica do diagrama de classes UML na Seção 3.8. A Figura 4.10 ilustra um possível diagrama dc classes UML cor­ respondente ao diagrama EER da Figura 4.7. A notação básica para especialização/ generalização (ver Figura 4.10) é conectar as subclasses por linhas verticais a uma linha horizontal, que tem um triângulo conectando a linha horizontal por meio de outra linha vertical até a superclasse. Um triângulo preto indica uma especialização/ generalização com a restrição disjunta, e um triângulo contornado indica uma res­ trição de sobreposição. A superclasse raiz é chamada dc classe base, e as subclasses (nós folhas) são chamadas de classes de folha.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

PESSOA

Nome Cpf Data nascimento Sexo Endereço

idade

FUNCIONÁRIO

EX_ALUNO

Salario contratar_ funcionário

novo_ex_aluno

TITULO

ALUNO

Ano Titulo Curso

Departamento principal

troca, departamento

J ADMINISTRATIVO

DOCENTE

ALUNO COLABORADOR

Cargo

Nivel

Porcentagem tempo

contrata r_adm in istrativo

promoção

contratar_aluno

COLABORADOR PESQUISA

COLABORADOR ENSINO

ALUNO. POSGRADUACAO

ALUNO. GRADUACAO

Projeto

Disciplina

Titulo programa

Tipo.aluno

troca_projeto

inscreve.disciplina

troca_titulo_programa

troca_tipo_aluno

Figura 4.10 Um diagrama de classes UML correspondente ao diagrama EER da Figura 4.7, ilustrando a notação UML para especializaçãc/generalização.

A discussão citada e o exemplo da Figura 4.10, com a apresentação da Seção 3.8, oferecem uma rápida introdução aos diagramas de classes UML e sua terminologia. Focalizamos os conceitos relevantes à modelagem de banco de dados ER e EER, em vez dos conceitos que são mais relevantes à engenharia de software. Em UML, existem muitos detalhes que não discutimos, pois estão fora do escopo deste livro e são relevantes principalmente para a engenharia de software. Por exemplo, as classes podem ser de vários tipos: ■ Classes abstratas definem atributos e operações, mas não têm objetos corres­ pondentes a essas classes. Elas são usadas principalmente para especificar um conjunto de atributos e operações que podem ser herdados. ■ Classes concretas podem ter objetos (entidades) instanciados para pertencer à classe. ■ Classes de template especificam um modelo que também pode ser usado para definir outras classes.

115

116 Sistemas de banco de dados No projeto de banco de dados, estamos preocupados principal mente com a espe­ cificação de classes concretas, cujas coleções de objetos são permanentemente (ou persistentemente) armazenadas no banco de dados. A bibliografia selecionada ao final deste capítulo oferece algumas referências a livros que descrevem os detalhes completos da U.ML.

4.7 Conceitos de abstração de dados, representação do conhecimento e ontologia Nesta seção, discutimos em termos gerais alguns dos conceitos de modelagem que descrevemos bem especificamente cm nossa apresentação dos modelos ER e EER no Capítulo 3 e anteriormente neste capítulo. Essa terminologia é usada não só na modelagem de dados conceituais, mas também na literatura de inteligência artificial quando se discute a representação do conhecimento (ou RC). Esta seção discute as semelhanças e as diferenças entre a modelagem conceituai c a represen­ tação do conhecimento, além de introduzir um pouco da terminologia alternativa e de alguns conceitos adicionais. O objetivo das técnicas de RC é desenvolver conceitos para modelar com precisão algum domínio de conhecimento, criando uma ontologia12 que descreve os conceitos do domínio e como esses conceitos estão inter-relacionados. Tal ontologia é usada para armazenar e manipular o conhecimento para tirar conclusões, tomar decisões ou responder a perguntas. Os objetivos da RC são semelhantes aos dos modelos de dados semânticos, mas existem algumas semelhanças e diferenças importantes entre as duas disciplinas: ■ Ambas as disciplinas usam um processo de abstração para identificar proprieda­ des comuns c aspectos importantes de objetos no minimundo (também conhecido como domínio de discurso em RC), enquanto suprimem diferenças insignificantes e detalhes sem importância. ■ /\s duas disciplinas oferecem conceitos, relacionamentos, restrições, operações e linguagens para definir dados e representar conhecimento. ■ A RC geralmente é mais ampla em escopo que os modelos de dados semânticos. Diferentes formas de conhecimento, como regras (usadas na inferência, dedu­ ção e pesquisa), conhecimento incompleto e padrão, e conhecimento temporal e espacial, são representadas em esquemas RC. Os modelos de banco de dados estão sendo expandidos para incluir alguns desses conceitos (ver Capítulo 26). ■ Esquemas RC incluem mecanismos de raciocínio que deduzem fatos adicionais dos armazenados cm um banco dc dados. Logo, embora a maioria dos sistemas de banco de dados atuais seja limitada a responder a consultas diretas, os sistemas baseados em conhecimento que usam esquemas RC podem responder a consultas que envolvem inferências sobre os dados armazenados. A tecnologia de banco de dados está sendo estendida com mecanismos de inferência (ver Seção 26.5). ■ Embora a maioria dos modelos de dados se concentre na representação dos esquemas de banco de dados, ou metaconhecimento, os esquemas RC costumam misturar os esquemas com as próprias instâncias, a fim de oferecer flexibilidade na representação de exceções. Isso normalmente resulta em ineficiências quando esses esquemas RC são implementados, espccialmcntc quando comparados com bancos dc dados c quando uma grande quantidade de dados estruturados (fatos) precisa ser armazenada.

12 Uma ontologia é algo semelhante a um esquema conceituai, mas com mais conhecimento, regras e exceções.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER) Agora, vamos discutir sobre quatro conceitos de abstração usados em modelos de dados semânticos, como o modelo EER, bem como em esquemas RC: (1) clas­ sificação e instanciação, (2) identificação, (3) especialização e generalização e (4) agregação e associação. Os conceitos emparelhados de classificação e instanciação são inversos um do outro, assim como a generalização e a especialização. Os concei­ tos de agregação e associação também são relacionados. Discutimos esses conceitos abstratos e sua relação com as representações concretas usadas no modelo EER para esclarecer o processo de abstração de dados e melhorar nosso conhecimento do processo relacionado de projeto de esquema conceituai. Fechamos a seção com uma rápida discussão sobre ontologia, que está sendo bastante usada na pesquisa recente sobre representação do conhecimento.

4.7.1 Classificação e instanciação O processo de classificação consiste em atribuir sistematicamente objetos/entidades semelhantes aos tipos classe/entidade do objeto. /\gora, podemos descrever (em BD) ou raciocinar sobre (em RC) as classes em vez dos objetos individuais. Coleções de objetos que compartilham os mesmos tipos de atributos, relacionamentos e res­ trições são classificadas em classes, a fim de simplificar o processo de descoberta de suas propriedades. A instanciação c o inverso da classificação, e refere-se à geração e ao exame específico de objetos distintos de uma classe. Uma instância de objeto está relacionada à sua classe de objeto por um relacionamento E_UM A_INSTANCIA_DE ou É_UM_MEMBRO_DE. Embora os diagramas EER nào apresentem instâncias, os diagramas UML permitem uma forma de instanciação ao possibilitar a exibição de objetos individuais. Não descrevemos esse recurso em nossa introdução aos diagramas de classes UML. Em geral, os objetos de uma classe devem ter uma estrutura de tipo semelhante. Contudo, alguns objetos podem exibir propriedades que diferem em alguns aspectos dos outros objetos da classe. Esses objetos de exceção também precisam ser modela­ dos, e os esquemas RC permitem exceções mais variadas que os modelos de banco de dados. Além disso, certas propriedades se aplicam à classe como um todo, e não aos objetos individuais; os esquemas RC permitem tais propriedades de classe. Os diagramas UML também permitem a especificação de propriedades de classe. No modelo EER, as entidades são classificadas em tipos de entidade de acordo com seus atributos e relacionamentos básicos. As entidades são classificadas ainda em subclasses e categorias, com base nas semelhanças e nas diferenças adicionais (exceções) entre elas. As instâncias de relacionamento são classificadas em tipos de relacionamento. Logo, os tipos de entidade, subclasses, categorias e tipos de relacionamento são os diferentes conceitos usados para classificação no modelo EER. O modelo EER não prove explicitamente propriedades de classe, mas pode ser estendido para fazer isso. Em UML, os objetos são classificados em classes, e é possível exibir tanto propriedades de classe quanto objetos individuais. Os modelos de representação do conhecimento permitem múltiplos esquemas de classificação, em que uma classe é uma instância de outra classe (chamada metaclasse). Observe que isso não pode ser representado diretamente no modelo EER, pois temos apenas dois níveis — classes e instâncias. O único relacionamento entre classes no modelo EER é um relacionamento de superclasse/subclasse, ao passo que em alguns esquemas RC um relacionamento adicional de classe/instância pode ser representado diretamente em uma hierarquia de classes. Uma instância pode, por si só, ser outra classe, permitindo esquemas de classificação multiníveis.

117

118 Sistemas de banco de dados 4.7.2 Identificação

Identificação é o processo de abstração pelo qual classes e objetos se tornam exclu­ sivamente identificáveis por meio de algum identificador. Por exemplo, um nome de classe identifica de maneira exclusiva uma classe inteira dentro de um esquema. É necessário que haja um mecanismo adicional para distinguir instâncias dc objeto

distintas por meio de identificadores de objeto. zMém disso, é necessário identificar múltiplas manifestações no banco de dados do mesmo objeto no mundo real. Por exemplo, podemos ter uma tu pia em uma relação PESSOA e outra tupla em uma relação ALUNO que representem a mesma entidade do mundo real. Não há como identificar o fato dc que esses dois objetos de banco de dados (tuplas) representam a mesma entidade do mundo real, a menos que tomemos uma providência em tempo de projeto para a referência cruzada apropriada, que fornece essa identificação. Logo, a identificação é necessária em dois níveis: ■ Para distinguir entre objetos c classes dc banco dc dados. ■ Para identificar objetos de banco de dados e relacioná-los a seus equivalentes no mundo real.

No modelo EER, a identificação das construções de esquema é baseada em um sistema de nomes exclusivos para as construções em um esquema. Por exemplo, cada classe cm um esquema EER — seja um tipo dc entidade, uma subclasse, uma categoria ou um tipo de relacionamento — precisa ter um nome distinto. Os nomes de atributos de determinada classe também precisam ser distintos. As regras para identificar referências de nome de atributo sem ambiguidade em um reticulado ou hierarquia de especialização ou generalização também são necessárias. No nível de objeto, os valores dos atributos-chave sào usados para distinguir entre entidades dc um tipo em particular. Para tipos dc entidade fraca, as entidades são identificadas por uma combinação de valores próprios de chave parcial c aquelas às quais estão relacionadas no(s) tipo(s) de entidade do proprietário. As instâncias de relacionamento são identificadas por alguma combinação das entidades às quais estão relacionadas, dependendo da razão dc cardinalidade especificada.

4.7.3 Especialização e generalização Especialização é o processo de classificar uma classe de objetos em subclasses mais especializadas. Generalização é o processo inverso de generalizar várias clas­ ses em uma classe abstrata de mais alto nível, que inclua os objetos em todas essas classes. A especialização é o refinamento conceituai, enquanto a generalização é a síntese conceituai. Subclasses são usadas no modelo EER para representar a espe­ cialização e a generalização. Chamamos o relacionamento entre uma subclasse e suas superclasses de relacionamento E_UMA_SUBCLASSE_DE, ou simplesmente um relacionamento É_UM. Trata-se do mesmo relacionamento E_U.M discutido anteriormente, na Seção 4.5.3.

4.7.4 Agregação e associação Agregação é um conceito dc abstração para a criação de objetos compostos com base em seus objetos componentes. Existem três casos em que esse conceito pode estar relacionado ao modelo EER. O primeiro caso é a situação em que agregamos valores de atributo de um objeto para formar o objeto inteiro. O segundo caso é quando representamos um relacionamento de agregação como um relacionamento comum. O terceiro caso, que o modelo EER não propicia cxplicitamentc, envolve a

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

possibilidade de combinar objetos relacionados por uma instância de relacionamento em particular a um objeto agregado de nível superior. Isso às vezes é útil quando o próprio objeto de agregação de nível mais alto tem de estar relacionado a outro objeto. Chamamos o relacionamento entre os objetos primitivos e seu objeto de agre­ gação É_UMA_PARTE_DE; o inverso é chamado de É_UM_COMPONENTE_DE. A UML possibilita todos os três tipos de agregação. A abstração dc associação é usada para associar objetos dc várias classes indepen­ dentes. Assim, às vezes ela é semelhante ao segundo uso da agregação. Ela é repre­ sentada no modelo EER por tipos de relacionamento e, em UML, por associações. Esse relacionamento abstrato é chamado de E_ASSOCIADO_A. Para entender melhor os diferentes usos da agregação, considere o esquema ER mostrado na Figura 4.11(a), que armazena informações sobre entrevistas por candidatos a emprego para várias empresas. A classe EMPRESA é uma agregação dos atributos (ou objetos componentes) Nome_empresa (nome de empresa) e Endereco_empresa (endereço da empresa), enquanto CANDIDATO é uma agregação de Cpf, Nome, Endereço e Telefone. Os atributos de relacionamento Nome_responsavel e Telefone_responsavel representam o nome c o número de telefone da pessoa na empresa que c responsável pela entrevista. Suponha que algumas entrevistas resultem em ofertas de emprego, ao passo que outras não. Gostaríamos dc tratar ENTREVISTA como uma classe para associá-la a OFERTA_EMPREGO. O esquema mostrado na Figura 4.11(b) está incorreto porque requer que cada instância de relacionamento dc entrevista tenha uma oferta dc emprego. O esquema mostrado na Figura 4.11(c) não é permitido porque o modelo ER não permite relaciona­ mentos entre relacionamentos. Uma forma de representar essa situação é criar uma classe agregada de nível mais alto, composta por EMPRESA, CANDIDATO e ENTREVISTA, e relacioná-la a OFERTA, EMPREGO, como mostra a Figura 4.11 (d). Embora o modelo EER, conforme descrito neste livro, não tenha essa característica, alguns modelos de dados semânticos o permitem, e chamam o objeto resultante de objeto composto ou molecular. Outros modelos tratam tipos de entidade e tipos de relacionamento de maneira uniforme e, portanto, permitem relacionamentos entre relacionamentos, conforme ilustrado pela Figura 4.11(c). Para representar essa situação corrctamcntc no modelo ER descrito aqui, precisa­ mos criar um novo tipo dc entidade fraca ENTREVISTA, como mostra a Figura 4.11(e), e relacioná-lo a OFERTA_EMPREGO. Logo, sempre podemos representar essas situações de modo correto no modelo ER criando tipos de entidade adicionais, embora possa ser conceitualmente mais desejável permitir a representação direta da agregação, como na Figura 4.11(d), ou permitir relacionamentos entre relacionamentos, como na Figura 4.11(c). A distinção estrutural principal entre agregação e associação é que, quando uma instância de associação é excluída, os objetos participantes podem continuar a existir. Porém, se dermos suporte à noção de um objeto de agregação — por exemplo, um CARRO que é composto dos objetos MOTOR, CHASSI e PNEUS —, então a exclusão do objeto de agregação CARRO corresponde à exclusão de todos os seus objetos componentes.

4.7.5 Ontologias e a web semântica Nos últimos anos, a quantidade de dados e informações computadorizadas disponíveis na web se tornou algo fora de controle. Muitos modelos e formatos diferentes são utilizados. Além dos modelos dc banco dc dados que apresentamos neste livro, muita informação é armazenada na forma dc documentos, que possuem

119

120 Sistemas de banco de dados

OFERTA EMPREGO |

Figura 4.11 Agregação, (a) O tipo de relacionamento ENTREVISTA, (b) Incluindo OFERTA_ EMPREGO em um tipo de relacionamento ternário (incorreto), (c) Fazendo o relacionamento RESULTA_EM participar de outros relacionamentos (não permitido em ER). (d) Usando agregação e um objeto composto ou molecular (geralmente não permitido em ER, mas permitido por algumas ferramentas de modelagem), (e) Representação correta em ER.

consideravelmente muito menos estrutura que a informação do banco dc dados. Um projeto cm andamento, que está tentando permitir a troca dc informações entre computadores na web, é chamado de web semântica, que tenra criar modelos de representação do conhecimento que sejam bastante genéricos, a fim de permitir

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

a troca e a pesquisa de informações significativas entre máquinas. O conceito de ontologia é considerado a base mais promissora para alcançar os objetivos da web semântica e está bastante relacionado à representação do conhecimento. Nesta seção, oferecemos uma rápida introdução ao que é a ontologia e como ela pode ser usada como uma base para automatizar o conhecimento, a busca e a troca de informações. O estudo das ontologias tenta descrever os conceitos e os relacionamentos possíveis na realidade por meio dc um vocabulário comum; portanto, ele pode ser considerado um meio para descrever o conhecimento de uma certa comunidade sobre a realidade. A ontologia originou-se nas áreas de filosofia e metafísica. Uma definição muito usada de ontologia é uma especificação de uma conceitualização.1* Nessa definição, uma conceitualização é o conjunto de conceitos usados para representar a parte da realidade ou conhecimento que é de interesse dc uma comu­ nidade de usuários. Especificação refere-se à linguagem e termos do vocabulário usados para especificar a conceitualização. A ontologia inclui tanto a especificação quanto a conceitualização. Por exemplo, a mesma conceitualização pode ser especi­ ficada em duas linguagens diferentes, gerando duas ontologias separadas. Com base nessa definição bastante geral, não existe consenso sobre o que é exatamente uma ontologia. Algumas maneiras possíveis de descrever as ontologias são as seguintes: ■ Um thesaurus (ou ainda um dicionário ou um glossário de termos) descreve os relacionamentos entre palavras (vocabulário) que representam diversos conceitos. ■ Uma taxonomia descreve como os conceitos de determinada área do conheci­ mento são relacionados usando estruturas semelhantes às utilizadas em uma especialização ou generalização. ■ Um esquema de banco de dados detalhado é considerado por alguns uma onto­ logia que descreve os conceitos (entidades e atributos) e relacionamentos de um minimundo a partir da realidade. ■ Uma teoria lógica usa conceitos da lógica matemática para tentar definir conceitos e seus inter-relacionamentos. Normalmente, os conceitos usados para descrever ontologias são muito seme­ lhantes aos conceitos que discutimos na modelagem conceituai, como entidades, atributos, relacionamentos, especializações e assim por diante. A principal diferença entre uma ontologia e, digamos, um esquema de banco de dados, é que o esquema em geral está limitado a descrever um pequeno subconjunto de um minimundo a partir da realidade a fim dc armazenar c gerenciar dados. Uma ontologia costuma ser considerada mais geral no sentido de tentar descrever uma parte da realidade ou de um domínio de interesse (por exemplo, termos médicos, aplicações de comércio eletrônico, esportes etc.) o mais completamente possível.

4.8 Resumo Neste capítulo, discutimos as extensões ao modelo ER que melhoram suas capacidades de representação. Chamamos o modelo resultante de modelo ER estendido ou EER. Apresentamos o conceito dc uma subclasse e sua superclasse e o mecanismo relacionado dc herança dc atributo/rclacionamcnto. Vimos como às vezes é necessário criar classes de entidades adicionais, por causa dos atributos específicos adicionais ou dos tipos de relacionamento específicos. Discutimos dois processos principais para definir hierarquias e rericulados de superclasse/subclasse: especialização e generalização.

15 Essa definição é dada cm Gruber (1995).

121

122 Sistemas de banco de dados

Em seguida, mostramos como apresentar essas novas construções em um dia­ grama EER.Também discutimos os diversos tipos de restrições que podem se aplicar à especialização ou generalização. z\s duas principais restrições são total/parcial e disjunta/sobreposta. Discutimos o conceito de uma categoria ou ripo de união, que é um subconjunto da união de duas ou mais classes, e mostramos as definições formais de todos os conceitos apresentados. Apresentamos parte da notação e terminologia da UML para representar a espe­ cialização e a generalização. Na Seção 4.7, discutimos rapidamente a disciplina de representação do conhecimento (RC) e como ela está relacionada à modelagem de dados semântica. Também demos uma visão geral e um resumo dos tipos de concei­ tos abstratos da representação de dados: classificação e instanciação, identificação, especialização e generalização, e agregação e associação. Vimos como os conceitos de EER e UML estão relacionados a cada um deles.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

4.1. 4.2.

4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10.

4.11.

4.12. 4.13. 4.14. 4.15.

O que é uma subclasse? Quando uma subclasse é necessária na modelagem de dados? Defina os seguintes termos: superclasse de uma subclasse, relacionamento de superclasse/subclasse, relacionamento E_UM, especialização, generalização, categoria, atributos específicos (locais) e relacionamentos específicos. Discuta o mecanismo de herança de atributo/relacionamento. De que forma ele é útil? Discuta as subclasses definidas pelo usuário e definidas por predicado, e iden­ tifique as diferenças entre as duas. Discuta as especializações definidas pelo usuário e definidas por atributo, e identifique as diferenças entre as duas. Discuta os dois tipos principais de restrições sobre especializações e generalizações. Qual é a diferença entre uma hierarquia de especialização e um reticulado de especialização? Qual é a diferença entre especialização e generalização? Por que não exibimos essa diferença nos diagramas de esquema? Como uma categoria difere de uma subclasse compartilhada regular? Para que uma categoria é usada? Ilustre sua resposta com exemplos. Para cada um dos seguintes termos da UML (ver seções 3.8 e 4.6), discuta o termo correspondente no modelo EER, se houver: objeto, classe, associação, agregação, generalização, multiplicidade, atributos, discriminador, ligação, atributo de ligação, associação reflexiva e associação qualificada. Discuta as principais diferenças entre a notação para diagramas de esquema EER e diagramas de classe UML comparando como os conceitos comuns são representados em cada um. Liste os diversos conceitos de abstração de dados e os conceitos de modelagem correspondentes no modelo EER. Que recurso de agregação está faltando do modelo EER? Como o modelo pode ser melhorado para dar suporte a esse recurso? Quais são as principais semelhanças e diferenças entre as técnicas conceituais de modelagem de banco de dados e as técnicas de representação do conhecimento? Discuta as semelhanças c diferenças entre uma ontologia e um esquema dc banco de dados.

Capítulo 4 O modelo Entidade-Relaoonamento Estendido (EER)

EXERCÍCIOS ----------------------------------------------------------------------------------------------4.16. Projete um esquema EER para uma aplicação de banco de dados em que você está interessado. Especifique todas as restrições que devem ser mantidas no banco de dados. Cuide para que o esquema tenha pelo menos cinco tipos de entidade, quatro tipos de relacionamento, um tipo de entidade fraca, um relacionamento de superclasse/subclasse, uma categoria e um tipo de relacio­ namento w-ário (n > 2). 4.17. Considere o esquema ER BANCO da Figura 3.21 e suponha que seja necessário registrar diferentes tipos de CONTAS (CONTA_POUPANCA, CONTA_CORRENTE,...» e EMPRÉSTIMOS (EMPRESTIMO.CARRO, EMPRÉSTIMO JHABITACAO,...). Suponha que também se deseje registrar cada uma das TRANSAÇÕES de CONTA (depósitos, saques, cheques,...) e os PAGAMENTOS de EMPREST1MO; ambos incluem valor, data e hora. Modifique o esquema BANCO, usando os conceitos dc ER e EER de especialização e generalização. Indique quaisquer suposições que você fizer sobre os requisitos adicionais. 4.18. A narrativa a seguir descreve uma versão simplificada da organização das instalações olímpicas planejadas para os Jogos Olímpicos de verão. Desenhe um diagrama EER que mostre os tipos de entidade, atributos, relacionamentos e especializações para essa aplicação. Indique quaisquer suposições que você fizer. As instalações olímpicas são divididas em complexos esportivos, os quais são divididos em tipos de um esporte e poliesportiuo. Os complexos poliesportivos possuem áreas designadas para cada esporte com um indicador de localização (por exemplo,centro, canto NE, c assim por diante). Um complexo tcin um local, organizador-chcfc, área total ocupada, c assim por diante. Cada complexo mantém uma série de eventos (por exemplo, o estádio com raias pode englobar muitas corridas diferentes). Para cada evento existe uma data planejada, duração, número dc participantes, número de oficiais e assim por diante. Uma relação dc todos os oficiais será mantida com a lista dos eventos em que cada oficial estará envolvido. Diferentes equipamentos são necessários para os eventos (por exemplo, balizas, postes, barras paralelas), bem como para a manutenção. Os dois tipos de instalações (um esporte e poliesportivo) terão diferentes tipos de informação. Para cada tipo, o número de instalações necessárias é mantido, com um orçamento aproximado. 4.19. Identifique todos os conceitos importantes representados no estudo dc caso do banco dc dados de biblioteca descrito a seguir Em particular identifique as abstrações de classificação (tipos de entidade e tipos de relacionamento), agre­ gação, identificação e especializaçào/generalização. Especifique as restrições dc cardinalidade (min, max) sempre que possível. Liste detalhes que afetarão o eventual projeto, mas que não têm relevância no projeto conceituai. Liste as restrições semânticas separadamente. Desenhe um diagrama EER do banco de dados de biblioteca. Estudo de caso: A Georgia Tech Library (GTL) tem aproximadamente 16 mil usuários, 100 mil títulos e 250 mil volumes (uma média de 2,5 cópias por livro). Cerca de 10% dos volumes estão emprestados a qualquer momento. Os bibliotecários garantem que os livros estejam disponíveis quando os usuários quiserem pegá-los emprestado. Além disso, eles precisam saber a qualquer momento quantas cópias de cada livro existem na biblioteca ou estão empres­ tadas. Um catálogo de livros está disponível on-line, listando livros por autor, título e assunto. Para cada título da biblioteca, é mantida uma descrição do livro no catálogo, que varia dc uma sentença a várias páginas. Os bibliotecá­ rios de referência desejam poder acessar essa descrição quando os usuários

123

124 Sistemas de banco de dados solicitarem informações sobre um livro. O pessoal da biblioteca inclui o bibliotecário-chefe, bibliotecários associados ao departamento, bibliotecários de referência, pessoal de despacho e assistentes de bibliotecário. Os livros podem ser emprestados por 21 dias. Os usuários têm permissão para pegar apenas cinco livros de uma só vez. Os usuários normalmente devolvem os livros dentro de 3 a 4 semanas. A maioria dos usuários sabe que tem uma semana de tolerância antes que um aviso seja enviado para eles e, por isso, tentam devolver os livros antes que o período de tolerância termine. Cerca de 5% dos usuários precisam receber lembretes para devolver os livros. A maioria dos livros atrasados é devolvida dentro de um mês da data de vencimento. Aproximadamente 5% dos livros atrasados são mantidos ou nunca são devol­ vidos. Os membros mais ativos da biblioteca são definidos como aqueles que pegam livros emprestados pelo menos dez vezes durante o ano. Um por cento dos usuários que mais utilizam empréstimos realizam 15% dos empréstimos, e os maiores 10% dos usuários realizam 40% dos empréstimos. Cerca de 20% dos usuários são totalmente inativos por nunca terem retirado livros. Para tornar-se um usuário da biblioteca, os candidatos preenchem um for­ mulário incluindo seu CPF, endereço de correspondência da república e da residência familiar e números dc telefone. Os bibliotecários emitem um cartão numerado, legível à máquina, com a foto do usuário. Esse cartão tem validade de quatro anos. Um mês antes de o cartão expirar, um aviso é enviado ao usuário para que faça a renovação. Os professores do instituto são considera­ dos usuários automáticos. Quando um novo usuário do corpo docente entra para o instituto, suas informações são puxadas dos registros de funcionários e um cartão da biblioteca é remetido à sua sala de professor no campus. Os professores têm permissão para retirar livros por intervalos de três meses, e possuem um período de tolerância de duas semanas. Os avisos de renovação para os professores são enviados para sua sala de professor no campus. A biblioteca não empresta alguns livros, como livros dc referência, livros raros e mapas. Os bibliotecários precisam diferenciar livros que podem ser emprestados daqueles que não podem. Além disso, eles possuem uma lista de alguns livros que estão interessados em adquirir, mas não conseguem obter, como livros raros ou que estão esgotados, c livros que foram perdidos ou destruídos, mas não substituídos. Os bibliotecários precisam ter um sistema que registre os livros que não podem ser emprestados, bem como os que eles estão interessados em adquirir. Alguns livros podem ter o mesmo título; portanto, o título não pode ser usado como um meio de identificação. Cada livro é identificado por seu International Standard Book Number (ISBN), um código internacional exclusivo atribuído a todos os livros. Dois livros com o mesmo título podem ter diferentes ISBNs se estiverem em diferentes idiomas ou diferentes encadernações (capa dura ou brochura). As edições de um mesmo livro possuem ISBNs diferentes. O sistema de banco de dados proposto precisa ser projetado para registrar os usuários, os livros, o catálogo c a atividade dc empréstimo. 4.20. Projete um banco dc dados para registrar informações para um inuscu de arte. Suponha que os seguintes requisitos foram coletados: ■ O museu tem uma coleção de OBJETOS_ARTE. Cada OBJETO_ARTE tem um codigo exclusivo, um Artista (se conhecido), um Ano (quando foi criado, se conhecido), um Titulo c uma Descricao. Os objetos dc arte são categorizados de várias maneiras, conforme discutido a seguir. ■ OBJETOS_ARTE são categorizados com base em seu tipo. Existem três tipos principais: PINTURA, ESCULTURA e ESTATUA, mais um ripo chamado OUTRO

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

para acomodar objetos que nào se encaixam em nenhum dos três tipos principais. ■ Uma PINTURA tem um Tipo_pintura (óleo, aquarela etc.), material em que é desenhada (Desenhado_em — papel, tela, madeira etc.) e Estilo (moderno, abstrato etc.). ■ Uma ESCULTURA ou uma estátua tem um Material com o qual foi criada (madeira, pedra etc.). Altura, Peso e Estilo. ■ Um objeto de arte na categoria OUTRO tem um Tipo (impressão, foto etc.) e Estilo. ■ OBJETOS-ARTE sào categorizados como COLECAO.PERMANENTE (objetos que pertencem ao museu) e EMPRESTADOS. As informações capturadas sobre os objetos na COLECAO_PERMANENTE incluem Data_aquisicao, Status (em exibição, emprestado ou guardado) e Custo. A informação capturada sobre objetos EMPRESTADOS inclui a Colecao da qual foi emprestado, Data_emprestimo e Data_retorno. ■ A informação descrevendo o país ou cultura de Origem (italiano, egíp­ cio, norte-americano, indiano etc.) e Epoca (Renascença, Moderno, Antiguidade, e assim por diante) é capturada para cada OBJETO_ARTE. ■ O museu registra a informação de ARTISTA, se for conhecida: Nome, Data_ nascimento (se conhecida), Data_morte (se não estiver vivo), Pais_de_origem, Epoca, Estilo—principal e Descricao. O Nome é considerado exclusivo. ■ Ocorrem diferentes EXPOSICOES, cada uma com um Nome, Datajnicio e Data_final. As EXPOSICOES são relacionadas a todos os objetos de arte que estavam em amostra durante a exposição. ■ A informação é mantida em outras COLECOES com as quais o museu interage, incluindo Nome (exclusivo). Tipo (museu, pessoal etc.), Descricao, Endereço, Telefone e Pessoa_contato atual. Desenhe um diagrama de esquema EER para essa aplicação. Discuta quaisquer suposições que você fizer e que justifiquem suas escolhas dc projeto. 4.21. A Figura 4.12 mostra um exemplo de diagrama EER para o banco de dados de um pequeno aeroporto particular, que é usado para registrar aeronaves, seus proprietários, funcionários do aeroporto e pilotos. Com base nos requisitos para esse banco dc dados, a informação a seguir foi coletada: cada AERONAVE tem um código de registro [Codigo_registro],é de um tipo dc avião em particular [ATRIBUÍDO] e é mantido em um hangar em particular [GUARDADO_EM|. Cada TIPO_AVIAO tem um número de modelo [Modelo_aeronave], uma capacidade [Capacidade] e um peso [Peso]. Cada HANGAR tem um número [Numero], uma capacidade [Capacidade] e uma localização [Localizacao). O banco de dados também registra os PROPRIETÁRIOS de cada avião [PERTENCE] e os FUNCIONÁRIOS que fazem a manutenção da aeronave [FAZ_MANUTENCAOJ. Cada instância de relacionamento em PERTENCE relaciona uma AERONAVE a um PROPRIETÁRIO e inclui a data de compra [Data_comp]. Cada instância de relacionamento em FAZ_MANUTENCAO relaciona um FUNCIONÁRIO a um registro de serviço [SERVIÇO]. Cada aeronave passa por serviço de manuten­ ção muitas vezes; logo, ela é relacionada por [PASSA_POR) a uma série de registros de SERVIÇO. Um registro de SERVIÇO inclui como atributos a data da manutenção [Data], o número de horas gastas no trabalho [Horas] e o tipo de trabalho realizado [Codigo_trabalho|. Usamos um tipo dc entidade fraca [SERVIÇO) para representar o serviço na aeronave, pois o código de registro da aeronave é usado para identificar um registro de manutenção. Um PROPRIETÁRIO é uma pessoa ou uma corporação. Assim, usamos um tipo de união (categoria) [PROPRIETÁRIO] que é um subconjunto da união dos tipos de

125

126 Sistemas de banco de dados Sa anc

TRABALHA EM>^

(Modelo)^^ ——

Turno

FUNCIONÁRIO |-

N

M

-A7 MANUTFNC AC

MODELO jAERONAVE

úmero icenca

pstncoes

1 ATR R

M

VOA

PILOTO

DO

N

Data/codigo trabalh

Cod registro

Horas

SERVIÇO

N

AERONAVE

PASSA POR

N GUARDADO FM

PROPRIETÁRIO |

-’FRTFNC F

mm

n HANGAR ----- 7-- 1-- ---Numero

Localizacao

Capacidade

PESSOA —7-- 1-- ----

CORPORACAO ------- 7---1-- 'Z--------

Telefone Endereço

Nome

Telefone

Endereço

Figura 4.12 Esquema EER para um banco de dados PEQUE NO_AEROPORTO.

entidade corporação [CORPORACAO] e pessoa [PESSOA].Tanto pilotos [PILOTO] quanto funcionários [FUNCIONÁRIO] são subclasses de PESSOA. Cada PILOTO tem atributos específicos de número de licença [Numerojicenca] e restrições [Restrições]; cada FUNCIONÁRIO tem atributos específicos de salário [Salario] e turno trabalhado [Turno]. Todas as entidades PESSOA no banco de dados possuem dados armazenados sobre seu número de Cadastro de Pessoa Física [Cpf],nomc [Nome],endereço [Endereço] e número dc telefone [Telefone]. Para entidades CORPORACAO, os dados mantidos incluem nome [Nome], endereço [Endereço] e número de telefone [Telefone]. O banco de dados também registra os tipos de aeronaves em que cada piloto é autorizado a voar [VOA] e os tipos de aeronaves cm que cada funcionário pode realizar o trabalho dc manutenção [TRABALHA_EMJ. Mostre como o esquema EER PEQUENO_AEROPORTO da Figura 4.12 pode ser representado em notação UML. (Nota: não discutimos como representar categorias (tipos de união) em UML, de modo que você não precisa mapear as categorias nesta e na próxima questão.) 4.22. Mostre como o esquema EER UNIVERSIDADE da Figura 4.9 pode ser represen­ tado em notação UML.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER)

4.23. Considere os conjuntos de entidades e atributos mostrados na tabela desta página. Coloque uma marcação em uma coluna de cada linha, para indicar o relacionamento entre as colunas mais à esquerda e à direita. a. O lado esquerdo tem um relacionamento com o lado direito. b. O lado direito é um atributo do lado esquerdo. c. O lado esquerdo é uma especialização do lado direito. d. O lado esquerdo c uma generalização do lado direito.

Conjunto de entidades

(a) Tem um relacionamento com

(b) Tem um atributo que é

(c) É uma especialização de

(d) É uma generalização de

Conjunto de entidades ou atributo

1.

MÃE

PESSOA

2.

FILHA

MÃE

3.

ALUNO

PESSOA

4.

ALUNO

Cod.aluno

5.

ESCOLA

ALUNO

6.

ESCOLA

SALA_AULA

7.

ANIMAL

CAVALO

8.

CAVALO

Raça

9.

CAVALO

Idade

10.

FUNCIONÁRIO

CPF

11.

MÓVEL

CADEIRA

12.

CADEIRA

Peso

13.

HUMANO

MULHER

14.

SOLDADO

PESSOA

15.

COMBATENTEJNIMIGO

PESSOA

4.24. Desenhe um diagrama UML para armazenar um jogo de xadrez em um banco dc dados. Você pode examinar cm como fazer uma aplicação semelhante à que você está projetando. Indique daramente quaisquer suposições que você fizer em seu diagrama UML. Uma amostra das suposições que você pode fazer sobre o escopo é a seguinte: 1. O jogo de xadrez é realizado por dois jogadores. 2. O jogo c realizado cm um tabuleiro dc 8 x 8, como o que aparece a seguir:

3. Os jogadores recebem uma cor preta ou branca no início do jogo. 4. Cada jogador começa com as seguintes peças: a. rei d. 2 bispos b. rainha c. 2cavalos c. 2 torres f. 8 peões

127

128 Sistemas de banco de dados

5. Cada peça tem sua própria posição inicial. 6. Cada peça tem o próprio conjunto de jogadas válidas com base no estado do jogo. Você não precisa se preocupar com quais jogadas são válidas ou não, exceto pelas seguintes questões: a. Uma peça pode se mover para um quadrado vazio ou capturar uma peça do oponente. b. Se uma peça for capturada, ela é removida do tabuleiro. c. Se um peão se mover para a última fileira, ele é “promovido”, sendo convertido para outra peça (rainha, torre, bispo ou cavalo). Nota: algumas dessas funções podem se espalhar por várias classes. 4.25. Desenhe um diagrama EER para um jogo de xadrez conforme descrito no Exercício 4.24. Concentre-sc nos aspectos de armazenamento persistente do sistema. Por exemplo, o sistema precisaria recuperar todas as jogadas de cada jogo realizado em ordem sequencial. 4.26. Quais dos seguintes diagramas EER são incorretos e por quê? Indique clara­ mente quaisquer suposições que você fizer.

4.27. Considere o seguinte diagrama EER que descreve os sistemas de computador em uma empresa. Forneça os próprios atributos e chave para cada tipo de enti­ dade. Forneça restrições de cardinalidade max justificando sua escolha. Escreva uma descrição narrativa completa do que esse diagrama EER representa.

Capítulo 4 O modelo Entidade-Relacionamento Estendido (EER) INSTALADO

MONITOR

EXERCÍCIOS DE LABORATÓRIO --------------------------------------------------------------4.28. Considere um banco de dados DIARIO_NOTAS em que os professores de um departamento acadêmico registram pontos ganhos pelos alunos em suas aulas. Os requisitos de dados são resumidos da seguinte forma: ■ Cada aluno é identificado por um identificador exclusivo, nome e sobre­ nome, e por um endereço de e-mail. ■ Cada professor leciona certas disciplinas a cada período. Cada disciplina é identificada por um número, um número de seção e o período em que ela é realizada. Para cada disciplina, o professor especifica o número mínimo de pontos necessários para ganhar conceitos A, B, C, D e F. Por exemplo, 90 pontos para A, 80 pontos para B, 70 pontos para C, e assim por diante. ■ Os alunos são matriculados em cada disciplina lecionada pelo professor. ■ Cada disciplina tem uma série de componentes de avaliação (como exame do meio do período, exame final, projeto, e assim por diante). Cada com­ ponente de avaliação tem um número máximo de pontos (como 100 ou 50) e um peso (como 20% ou 10%). Os pesos de todos os componentes de avaliação de um curso em geral totalizam 100. ■ Finalmente, o professor registra os pontos ganhos por aluno cm cada um dos componentes de avaliação em cada uma das disciplinas. Por exemplo, o aluno 1234 ganha 84 pontos para o componente de avaliação do meio do período da disciplina CCc2310 da seção 2 no período do segundo semestre de 2009. O componente dc avaliação de exame do meio do período pode ter sido definido para ter um máximo de 100 pontos e um peso de 20% da nota da disciplina. Crie um diagrama entidade-relacionamento estendido para o banco de dados do diário de noras e monte o projeto usando uma ferramenta de modelagem como ERwin ou Rational Rose.

129

130 Sistemas de banco de dados 4.29. Considere um sistema de banco de dados LEILAO_ON-LINE em que os membros (compradores e vendedores) participam na venda de itens. Os requisitos de dados para esse sistema estão resumidos a seguir: ■ O site on-line tem membros, e cada um é identificado por um número de membro exclusivo e descrito por um endereço de e-mail, nome, senha, endereço residencial e número de telefone. ■ Um membro pode ser um comprador ou um vendedor. Um comprador tem um endereço de entrega registrado no banco de dados. Um vendedor tem um número de conta bancária e um número de encaminhamento registrados no banco de dados. ■ Os itens são colocados à venda por um vendedor e identificados por um número de item exclusivo, atribuído pelo sistema. Os itens também são descritos por um título de item, uma descrição, um preço de lance inicial, um incremento de lance, a data inicial e a data final do leilão. ■ Os itens também são classificados com base em uma hierarquia de classificação fixa (por exemplo, um mouse pode ser classificado como COMPUTADOR -> HARDWARE -> MOUSE). ■ Os compradores fazem lances para os itens cm que estão interessados. O preço e a hora do lance são registrados. O comprador com o maior preço de lance ao final do leilão é declarado o vencedor e uma transação entre comprador e vendedor pode então prosseguir. ■ O comprador e o vendedor podem registrar uma nota em relação às transações completadas. A nota contém uma pontuação da outra parte na transação (1-10) e um comentário. Crie um diagrama entidade-relacionamento estendido para o banco de dados LEILAO_ON-LINE e monte o projeto usando uma ferramenta de modelagem como ERwin ou Rational Rose. 4.30. Considere um sistema de banco de dados para uma organização de beisebol como as principais ligas nacionais. Os requisitos dc dados estão resumidos a seguir: ■ O pessoal envolvido na liga inclui jogadores, técnicos, dirigentes e árbi­ tros. Cada um tem uma identificação pessoal exclusiva. Eles também são descritos por seu nome c sobrenome, com a data c o local dc nascimento. ■ Os jogadores são descritos ainda por outros atributos, como sua orientação de batida (esquerda, direita ou ambas) e têm uma média de batidas (MB) por toda a vida. ■ Dentro do grupo de jogadores existe um subgrupo de jogadores chamados lançadores. Os lançadores têm uma média decorrida ganha (MCG), por toda a vida associada a eles. ■ As equipes são identificadas exclusiva mente por seus nomes. /\s equipes também são descritas pela cidade em que estão localizadas e pela divisão e liga em que jogam (como a divisão Central da Liga Norte-americana). ■ As equipes possuem um dirigente, uma série de técnicos e uma série de jogadores. ■ Os jogos são realizados entre dois times, um designado como o time da casa e o outro, como o time visitante em determinada data. A pontuação (corridas, batidas e erros) é registrada para cada time. O time com a maioria das corridas é declarado o vencedor do jogo. ■ A cada jogo terminado, um lançador vencedor c um lançador perdedor são registrados. Caso seja concedido um salvamento, o lançador salvo também é registrado.

Capítulo 4 O modelo Entidade-Relaoonamento Estendido (EER) A cada jogo terminado, o número de acertos (simples, duplos, triplos e home runs) obtidos por jogador também é registrado. Crie um diagrama entidade-relacionamento estendido para o banco de dados BEISEBOL e monte o projeto usando uma ferramenta de modelagem como ERwin ou Rational Rose. 431. Considere o diagrama EER para o banco de dados UNIVERSIDADE mostrado na Figura 4.9. Entre com seu projeto usando uma ferramenta de modelagem dc dados como ERwin ou Rational Rose. Faça uma lista das diferenças na notação entre o diagrama no texto e a notação diagramática equivalente que você acabou usando com a ferramenta. 432. Considere o diagrama EER para o pequeno banco dc dados AEROPORTO mostrado na Figura 4.12. Monte esse projeto usando uma ferramenta de modelagem de dados como ERwin ou Rational Rose. Tenha cuidado ao modelar a categoria PROPRIETÁRIO nesse diagrama. (Dica: considere o uso de CORPORACAO_E_PROPRIETARIA e PESSOA_E_PROPRIETARIA como dois tipos de relacionamento distintos.) 433. Considere o banco de dados UNIVERSIDADE descrito no Exercício 3.16. Você já desenvolveu um esquema ER para esse banco dc dados usando uma ferra­ menta de modelagem de dados como ERwin ou Rational Rose no Exercício de Laboratório 3.31. Modifique esse diagrama classificando DISCIPLINAS como DISCIPLINA_GRADUACAO ou DISCIPUNA_POSGRADUACAO e PROFESSORES como PROFESSORES_JUNIOR ou PROFESSORES_SENIOR. Inclua atributos apropriados para esses novos tipos dc entidade. Depois, estabeleça relacionamentos indi­ cando que os professores júnior lecionam disciplinas para alunos em gradua­ ção, ao passo que os professores seniores lecionam disciplinas para alunos de pós-graduação.



BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Muitos artigos propuseram modelos de dados conceituais ou semânticos. Aqui, oferecemos uma lista representativa. Um grupo de artigos, incluindo Abrial (1974), modelo DIAM de Senko (1975), o método NI AM (Verheijen e VanBckkum, 1982) e Bracchi et al. (1976), apresenta modelos semânticos que são baseados no conceito dc relacionamentos binários. Outro grupo dc artigos antigos discute métodos para estender o modelo relacionai para melhorar suas capacidades de modelagem. Isso inclui os artigos de Schmid e Swenson (1975), Navathe e Schkolnick (1978), o modelo RM/T dc Codd (1979), Furtado (1978) e o modelo estrutural de Wiederhold c Elmasri (1979). O modelo ER foi proposto originalmente por Chen (1976) e é formalizado em Ng (1981). Desde então, diversas extensões de suas capacidades de modelagem foram propostas, como em Scheuermann et al. (1979), Dos Santos et al. (1979),Teorey et al. (1986), Gogolla e Hohenstein (1991) e o modelo entidade-categoria-relacionamento (ECR) de Elmasri et al. (1985). Smith e Smith (1977) apresentam os conceitos dc generalização c agregação. O modelo dc dados semântico de Hammer c McLeod (1981) introduziu os conceitos dc rcticulados dc classe/subclassc, bem como outros conceitos de modelagem avançados. Um estudo da modelagem semântica de dados aparece em Hull e King (1987). Eick (1991) discute projeto c transformações dos esquemas conceituais. A análise de restrições para relacionamentos w-ários é dada em Soutou (1998). A UML é descrita

131

132 Sistemas de banco de dados detalhadamente em Booch, Rumbaugh e Jacobson (1999). Fowler e Scott (2000) e Stevens e Pooley (2000) oferecem introduções concisas aos conceitos da UML. Fensel (2000,2003) discute a web semântica e a aplicação de ontologias. Uschold e Gruninger (1996) e Gruber (1995) discutem sobre ontologias. A edição de junho de 2002 de Communications of the ACM é dedicada a conceitos e aplicações da ontologia. Fensel (2003) é um livro que discute as ontologias e o comércio eletrônico.

PARTE 3 Modelo de dados relacionai e SQL

0 modelo de dados relacionai e as restrições em bancos de dados relacionais ste capítulo abre a Parte 3 do livro, que aborda os bancos de dados relacionais. O modelo de dados relacionai foi introduzido inicialmente por Ted Codd, da IBM Research, em 1970, em um artigo clássico (Codd, 1970), que atraiu aten­ ção imediata por sua simplicidade e base matemática. O modelo usa o conceito de relação matemática — que se parece com uma tabela de valores — como seu bloco de montagem básico, e sua base teórica reside em uma teoria de conjunto e lógica de predicado de primeira ordem. Neste capítulo, discutiremos as características básicas do modelo e suas restrições. As primeiras implementações comerciais do modelo relacionai se tomaram dispo­ níveis no início da década de 1980, como o sistema SQL/DS no sistema operacional MVS, da IBM, e o SGBD, da Oracle. Desde então, o modelo foi implantado em uma grande quantidade de sistemas comerciais, assim como em sistemas de código aberto. Os SGBDs relacionais (SGBDRs) populares atuais incluem o DB2 (da IBM), o Oracle (da Oracle), o SGBD Sybase (agora da SAP) e o SQLServer e Microsoft Access (da Microsoft). Além disso, vários sistemas de código aberto, como MySQL e PostgreSQL, estão disponíveis. Por causa da importância do modelo relacionai, toda a Parte 3 é dedicada a esse modelo e algumas das linguagens associadas a ele. Nos capítulos 6 e 7, descreveremos alguns aspectos SQL, um modelo abrangente e linguagem padrão para SGBDs rela­ cionais comerciais. (Outros aspectos da SQL serão abordados em outros capítulos.) O Capítulo 8 abordará as operações da álgebra relacionai c introduzirá o cálculo relacionai — essas são duas linguagens formais associadas ao modelo relacionai. O cálculo relacionai é considerado a base para a linguagem SQL, e a álgebra relacionai é usada nos detalhes internos de muitas implementações de banco de dados para processamento e otimização de consulta (ver Parte 8 do livro). Outros aspectos do modelo relacionai são apresentados em outras partes do livro. O Capítulo 9 vinculará as estruturas de dados do modelo relacionai às construções

E

136 Sistemas de banco de dados dos modelos ER e EER (apresentados nos capítulos 3 e 4), e apresentará algoritmos para projetar um esquema de banco de dados relacionai mapeando um esquema conceituai no modelo ER ou EER para uma representação relacionai. Esses mapea­ mentos são incorporados em muitas ferramentas de projeto de banco de dados e CASE.1 Os capítulos 10 e 11, na Parte 4, discutirão as técnicas de programação usadas para acessar sistemas de banco de dados e a noção de conexão com bancos de dados relacionais por meio dos protocolos-padrão ODBC e JDBC. O Capítulo 11 também apresentará o tópico de programação de banco de dados na web. Os capítulos 14 e 15, na Parte 6, apresentarão outro aspecto do modelo relacionai, a saber, as restrições formais das dependências funcionais e multivaloradas. Essas dependências são usadas para desenvolver uma teoria de projeto de banco de dados relacionai baseada no conceito conhecido como normalização. Neste capítulo, concentramo-nos em descrever os princípios básicos do modelo de dados relacionai. Começamos definindo os conceitos de modelagem e a notação do modelo relacionai na Seção 5.1. A Seção 5.2 é dedicada a uma discussão das restrições relacionais que são consideradas uma parte importante do modelo rela­ cionai e automaticamente impostas na maioria dos SGBDs relacionais. A Seção 5.3 define as operações de atualização do modelo relacionai, discute como as violações de restrições de integridade são tratadas e apresenta o conceito dc uma transação. A Seção 5.4 contém um resumo do capítulo. Este capítulo e o Capítulo 8 abordam as bases formais do modelo relacionai, enquanto os capítulos 6 e 7 abordam o modelo relacionai prático da SQL, que é a base da maioria dos SGBDs relacionais comerciais c dc código aberto. Muitos con­ ceitos são comuns aos modelos formal e prático, mas existem algumas diferenças que iremos sinalizar.

5.1 Conceitos do modelo relacionai O modelo relacionai representa o banco dc dados como uma coleção de relações. Informa Imente, cada relação é semelhante a uma tabela de valores ou, até certo ponto, a um arquivo sequencial de registros. Ele é chamado de arquivo sequencial (flat file) porque cada registro tem uma estrutura simples linear ou plana. Por exemplo, o banco de dados de arquivos mostrado na Eigura 1.2 é semelhante à representação do modelo relacionai básico. No entanto, existem diferenças importantes entre relações e arquivos, conforme veremos em breve. Quando uma relação é considerada uma tabela de valores, cada linha na tabela representa uma coleção de valores de dados relacionados. Uma linha representa um fato que normalmcntc corresponde a uma entidade ou relacionamento do mundo real. Os nomes da tabela e da coluna são usados para ajudar a interpretar o significado dos valores em cada linha. Por exemplo, a primeira tabela da Figura 1.2 é chamada de ALUNO porque cada linha representa fatos sobre uma entidade particular de aluno. Os nomes de coluna — Nome, Numero.aluno, Tipo_aluno e Curso — especificam como interpretar os valores dc dados cm cada linha, com base na coluna cm que cada valor se encontra. Todos os valores em uma coluna são do mesmo tipo dc dado. Na terminologia formal do modelo relacionai, uma linha é chamada de tupla, um cabeçalho da coluna é chamado de atributo e a tabela é chamada de relação. O tipo de dado que descreve os tipos de valores que podem aparecer em cada coluna é representado por um domínio de valores possíveis. Agora, vamos definir esses termos — domínio., tupla, atributo e relação — dc maneira formal. 1 CASE significa computador).

computer-aided software engineering

{engenharia de software auxiliada por

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

5.1.1 Domínios, atributos, tuplas e relações

Um domínio D é um conjunto de valores atômicos. Com atômico, queremos dizer que cada valor no domínio é indivisível em se tratando do modelo relacionai formal. Um método comum de especificação de um domínio é definir um tipo de dado do qual são retirados os valores de dados que formam o domínio. Também é útil especificar um nome para o domínio, para ajudar na interpretação de seus valores. Alguns exemplos de domínios são: ■ Numeros_telefone_nacional. O conjunto de números de telefone com onze dígitos válidos no Brasil. ■ Numeros_telefone_local. O conjunto de números de telefone de nove dígitos válidos dentro de um código de área em particular no Brasil. O uso de números de tele­ fone com oito dígitos está rapidamente se tornando obsoleto, sendo substituído por números-padrão de nove dígitos. ■ Cadastro_pessoa_fisica. O conjunto de números do CPF com onze dígitos. (Esse é um identificador exclusivo atribuído a cada pessoa no Brasil para fins de emprego, impostos e benefícios.) ■ Nomes. O conjunto de cadeia de caracteres que representa nomes de pessoas. ■ Medias_nota. Possíveis valores para calcular a média das notas; cada um deve ser um número real (ponto flutuante) entre 0 e 4. ■ ldades_funcionario. Idades possíveis dos funcionários em uma empresa; cada um deve ser um valor inteiro entre 15 e 80. ■ Nomes_departamento_academico. O conjunto de nomes de departamentos acadê­ micos em uma universidade, como Ciência da Computação, Economia e Física. ■ Codigos_departamento_academico. O conjunto de códigos de departamentos acadêmicos, como ‘CC’, ‘ECON’ e ‘FIS’.

Estas são chamadas definições lógicas de domínios. Um tipo de dado ou for­ mato também é especificado para cada domínio. Por exemplo, o tipo de dado para o domínio Numeros_telefone_nacional pode ser declarado como uma sequência de caracteres na forma (dd)ddddd-dddd, em que cada dé um dígito numérico (decimal) e os dois primeiros dígitos formam um código de área de telefone válido. O tipo de dado para ldades_funcionario é um número inteiro entre 15 e 80. Para Nomes_departamento_academico, o ripo de dado é o conjunto de todas as cadeias de caracteres que representam nomes de departamento válidos. Um domínio, portanto, recebe um nome, tipo de dado e formato. Informações adicionais para interpretar os valores de um domínio também podem ser dadas; por exemplo, um domínio numérico como Pesos_pessoa deveria ter as unidades dc medida, como gramas ou quilos. Um esquema2 de relação R, indicado por R(AP A,,..., An), é composto de um nome de relação R e uma lista de atributos, Ap A„ ..., An. Cada atributo Ai é o nome dc um papel desempenhado por algum domínio D no esquema dc relação R. D é chamado dc domínio dc Ai c indicado por dom(A;). Um esquema dc relação é usado para descrever uma relação; R é chamado dc nome dessa relação. O grau (ou aridade) de uma relação é o número de atributos n desse esquema de relação. Uma relação de grau sete, que armazena informações sobre alunos universitários, teria sete atributos descrevendo cada aluno, da seguinte forma: ALUNO(Nome, Cpf, Telefone_residencial, Endereço, Telefone_comercial, Idade, Media)

Usando o tipo de dado de cada atributo, a definição às vezes é escrita como: ALUNOÍNome: string, Cpf: string, Telefone_residendal: string. Endereço: string, Telefone_comercial: string. Idade: inteiro. Media: real) 2 Um esquema de relação às vezes é chamado de scheme dc relação.

137

138 Sistemas de banco de dados Para esse esquema de relação, ALUNO é o nome da relação, que tem sete atributos. Na definição anterior, mostramos a atribuição de tipos genéricos, como string ou inteiro, aos atributos. Mais precisamente, podemos especificar os seguintes domí­ nios já definidos para alguns dos atributos da relação ALUNO: dom(Nome) = Nomes; dom(Cpf) = Cadastro_pessoa_fisica; dom(Telefone_residencial) = Numeros_telefone_ nacional,3 dom(Telefone_comercial) = Numeros_telefone_nacional e dom(Media) = Medias.nota. Também é possível referenciar atributos de um esquema de relação por sua posição dentro da relação; assim, o segundo atributo da relação ALUNO é Cpf, enquanto o quarto atributo é Endereço. Uma relação (ou estado de relação)4 r do esquema de relação R(Ap A2,..., An), também indicada por r(R),é um conjunto de n tuplasr= {íp Í2,íOT). Cada ntuplas t é uma lista ordenada de n valores t = , em que cada valor ia, 1 £ / £ n é um elemento de dom(Af) ou é um valor especial NULL. (Valores NULL serão dis­ cutidos mais adiante, na Seção 5.1.2.) O valor i-ésimo na tupla í, que corresponde ao atributo é referenciado como f|AJ ou 7.A, (ou ípl> 56 usarmos a notação posicionai). Os termos intenção da relação para o esquema R e extensão da relação para o estado de relação r(R) também são comumente utilizados. A Figura 5.1 mostra um exemplo de uma relação ALUNO, que corresponde ao esquema ALUNO já especificado. Cada tupla na relação representa uma entidade de aluno em particular (ou objeto). Apresentamos a relação como uma tabela, na qual cada tupla aparece como uma linha e cada atributo corresponde a um cabeçalho de coluna, indicando um papel ou interpretação dos valores nesta coluna. Valores NULL representam atributos cujos valores são desconhecidos ou não existem para alguma tupla individual de ALUNO. A definição anterior de uma relação pode ser refeita de maneira mais formal usando os conceitos da teoria de conjunto, como segue. Uma relação (ou estado de relação) r(R) é uma relação matemática de grau n sobre os domínios dom(A]), dom(A2),..., dom(Aw), que é um subconjunto do produto cartesiano (indicado por x) dos domínios que definem R: r(R) Ç (domtAj) X dom(A2) X ... X dom(A„))

O produto cartesiano especifica todas as combinações possíveis de valores dos domínios subjacentes. Logo, se indicarmos o número total de valores, ou

Nome de relação

Atributos

ALUNO

Bruno Braga

Telefone residencial Endereço Telefone comercial Idade Media Cpf 305.610.243-51 (17) 3783-1616 Rua das Paineiras, 2918 NULL 19 3,21

Carlos Kim

361.620.124-45 (17) 3785-4409

Nome

Rua das Goiabeiras, 125 NULL

18

2,89

Daniel Davidson 422.111.232-70 NULL

Avenida da Paz, 3452

(17) 4749-1253

25

3,53

Roberta Passos 489220.110-08 (17) 3476-9821 Barbara Benson 533.690.123-80 (17) 3239-8461

Rua da Consolação, 265 (17) 3749-6492 Rua Jardim, 7384 NULL

28 19

3,93 3,25

Figura 5.1 Atributos e tuplas de uma relação ALUNO.

3 No Brasil, com o grande aumento nos números de telefone causado pela proliferação dos telefones móveis, a maioria das áreas metropolitanas agora possui a discagem local de celular com nove dígitos, de modo que a discagem local de celular com oito dígitos foi descontinuada na maioria das áreas. Mudamos esse domínio para Numeros_*elefone_nacional em vez de Numeros_telefonesjocal, que seria uma opção mais geral. Isso ilustra como os requisitos do banco de dados podem mudar com o tempo. 4 Isso também tem sido chamado de instânda da relação. Não usaremos esse termo porque instância também é usado para se referir a uma única tupla ou linha.

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

139

cardinalidade, em um domínio D como IDI (considerando que todos os domínios sào finitos), o número total de tuplas no produto cartesiano é ldom(A()l x ldom(Á2)l X ... x IdomfAJI Esse produto de cardinalidades de todos os domínios representa o número total dc possíveis instâncias ou tuplas que poderão existir em qualquer estado dc relação r(R). Dc todas as combinações possíveis, um estado dc relação cm um determinado momento — o estado de relação atual — reflete apenas as tuplas válidas que repre­ sentam um estado em particular do mundo real. Em geral, à medida que o estado do mundo real muda, também muda o estado de relação, sendo transformado em outro estado de relação. Contudo, o esquema K é relativamente estático e muda com muito pouca frequência — por exemplo, como resultado da inclusão de um atributo para representar novas informações que não estavam originalmcnte armazenadas na relação. E possível que vários atributos tenham o mesmo domínio. Os nomes dc atributo indicam diferentes papéis, ou interpretações, do domínio. Por exemplo, na rela­ ção ALUNO, o mesmo domínio Numeros_telefone_nacional desempenha o papel dc Telefone_residencial, referindo-se ao telefone residencial de um aluno, e o papel de Telefone_comercial, referindo-se ao telefone comercial do aluno. Um terceiro atributo possível (não mostrado) com o mesmo domínio poderia ser Telefone_celular.

5.1.2 Características das relações A definição dada de relações implica cerras características que tornam uma relação diferente de um arquivo ou uma tabela. Agora, discutiremos algumas dessas características.

Ordenação de tuplas em uma relação. Uma relação é definida como um conjunto de tuplas. Matematicamente, os elementos de um conjunto não possuem ordem entre eles; logo, as tuplas cm uma relação não possuem nenhuma ordem em particular. Em outras palavras, uma relação não é sensível à ordenação das tuplas. Porém, em um arquivo, os registros estão fisicamente armazenados no disco (ou na memória), de modo que sempre existe uma ordem entre eles. Essa ordenação indica primeiro, segundo, i-ésimo e último registros no arquivo. De modo semelhante, quando exi­ bimos uma relação como uma tabela, as linhas são exibidas em certa ordem. A ordenação da tupla não faz parte da definição da relação porque uma relação tenta representar fatos em um nível lógico ou abstrato. Muitas ordens de tupla podem ser especificadas na mesma relação. Por exemplo, as tuplas na relação ALUNO da Figura 5.1 poderiam ser ordenadas pelos valores de Nome, Cpf, Idade ou algum outro atributo. A definição de uma relação não especifica ordem alguma: não existe preferência por uma ou outra ordenação. Logo, a relação apresentada na Figura 5.2 é considerada idêntica à mostrada na Figura 5.1. Quando uma relação é implemen­ tada como um arquivo ou exibida como uma tabela, uma ordenação em particular pode ser especificada sobre os registros do arquivo ou sobre as linhas da tabela.

Figura 5.2 A relação ALUNO da Figura 5.1 com uma ordem de tuplas diferente.

ALUNO Nome

Cpf

Telefone_ residencial

Endereço

Telefone_ comercial

Idade

Media

Daniel Davidson

422.111.232-70

NULL

Avenida da Paz, 3452

(17)4749-1253

25

3,53

Barbara Benson

533.690.123-80

(17)3239-8461

Rua Jardim, 7384

NULL

19

3,25

Roberta Passos

489.220.110-08

(17)3476-9821

Rua da Consolação, 265

(17)3749-6492

28

3,93

Carlos Kim

361.620.124-45

(17)3785-4409

Rua das Goiabeiras, 125

NULL

18

2,89

Bruno Braga

305.610.243-51

(17)3783-1616

Rua das Paineiras, 2918

NULL

19

3,21

140 Sistemas de banco de dados

Ordem dos valores dentro de uma tupla e uma definição alternativa de uma relação. De acordo com a definição anterior de uma relação, uma tupla n é uma lista orde­ nada de n valores, de modo que a ordem dos valores em uma tupla — e, portanto, dos atributos em um esquema de relação — é importante. No entanto, em um nível mais abstrato, a ordem dos atributos e seus valores nào é tão importante, desde que a correspondência entre atributos e valores seja mantida. Uma definição alternativa dc uma relação pode ser dada, tornando desnecessária a ordem dos valores em uma tupla. Nessa definição, um esquema dc relação R = [A A„ ...»AJ é um conjunto de atributos (em vez de uma lista ordenada de atributos), e um estado de relação r{R) é um conjunto finito de mapeamentos r = {íp ím}, em que cada tupla 4 é um mapeamento de R para D, e D é a união (indicada por U) dos domínios dc atributo; ou seja, D = dom(Aj) U dom(A2) U ... U dom(An). Nessa definição, 4AJ deve estar em dom(AJ para 1 < / < w para cada mapeamento t em r. Cada mapeamento í- é chamado de tupla. De acordo com essa definição de tupla como um mapeamento, uma tupla pode ser considerada um conjunto de pares (, ), em que cada par dá o valor do mapeamento a partir de um atributo A- para um valor t’, de dom(Aj. A ordem dos atributos não c importante, pois o nome do atributo aparece com seu valor. Por essa definição, as duas tuplas mostradas na Figura 5.3 são idênticas. Isso faz sentido em um nível abstrato, já que realmente não há motivo para preferir ter um valor de atributo aparecendo antes de outro em uma tupla. Quando o nome e o valor do atributo são incluídos juntos cm uma tupla, isso c conhecido como dados autodcscritivos, pois a descrição de cada valor (nome de atributo) está incluída na tupla. Geralmente, usaremos a primeira definição da relação, em que os atributos e os valores dentro das tuplas são ordenados no esquema de relação e os valores dentro das tuplas são ordenados de modo semelhante, porque isso simplifica grande parte da notação. Porém, a definição alternativa dada aqui é mais geral.5 Valores e NULLs nas tuplas. Cada valor em uma tupla é um valor atômico; ou seja, ele não é divisível em componentes dentro da estrutura do modelo relacionai básico. Logo, atributos compostos ou multivalorados (ver Capítulo 3) não são permitidos. Esse modelo às vezes é chamado de modelo relacionai plano. Grande parte da teoria por trás do modelo relacionai foi desenvolvida com essa suposição em mente, que é chamada pressuposto da primeira forma normal.6 Assim, atributos multivalorados precisam ser representados por relações separadas, e os atributos compostos são representados apenas por seus atributos de componentes simples no modelo relacionai básico.7 Um conceito importante é o dos valores NULL, que são usados para representar os valores de atributos que podem ser desconhecidos ou não se aplicam a uma tupla. Um valor especial, chamado NULL, é usado nesses casos. Por exemplo, na Figura 5.1, algumas tuplas ALUNO têm NULL para seus telefones comerciais, pois eles não trabalham (ou seja, o telefone comercial não se aplica a esses alunos). Outro aluno tem um NULL para o Figura 5.3 Duas tuplas idênticas quando a ordem dos atributos e valores não faz parte da definição da relação.

t = < (Nome, Daniel Davidson), (Cpf,422.111.232-70), (Telefone_residencial NULL), (Endereço, Avenida da Paz, 3452), (Telefone_comercial, (17)4749-1253), (Idade, 25), (Media, 3,53)> t = Usaremos a definição alternativa da relação quando discutirmos o processamento e a otimização da consulta no Capítulo 18. 6 Discutiremos esse pressuposto com mais detalhes no Capítulo 14.

Extensões do modelo relacionai removem essas restrições. Por exemplo, os sistemas objeto-rclacional (Capítulo 12) permitem atributos estruturados complexos, assim como os modelos relacionais não de primeira forma normal ou aninhados.

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais telefone residencial, talvez porque ele nào tenha um telefone residencial ou tenha, mas não o conhecemos (o valor é desconhecido). Em geral, podemos ter vários significados para valores NULL, como valor desconhecido, valor existe, mas não está disponível ou atributo não se aplica a esta tupla (também conhecido como valor indefinido). Um exemplo do último tipo de NULL ocorrerá se acrescentarmos um atributo Tipo.visto (tipo do visto) à relação ALUNO, que se aplica apenas a tuplas que representam alunos estran­ geiros. É possível criar diferentes códigos para diversos significados dc valores NULL. A incorporação de diferentes tipos de valores NULL nas operações do modelo relacionai provou ser muito difícil e, portanto, está fora do escopo de nossa apresentação. O significado exato de um valor NULL determina como ele será aplicado durante agregações aritméticas ou comparações com outros valores. Por exemplo, uma comparação dc dois valores NULL leva a ambiguidades — se os Clientes A c B tem endereços NULL, isso não significa que eles tenham o mesmo endereço. Durante o projeto do banco de dados, é melhor evitar ao máximo valores NULL. Discutiremos isso melhor nos capítulos 7 e 8, no contexto de operações e consultas, e no Capítulo 14, no contexto do projeto e normalização de banco de dados.

Interpretação (significado) de uma relação. O esquema de relação pode ser inter­ pretado como uma declaração ou um tipo de afirmação (ou asserção). Por exemplo, o esquema da relação ALUNO da Eigura 5.1 afirma que, em geral, uma entidade de aluno tem um Nome, Cpf, Telefone_residencial, Endereço, Telefone_comercial, Idade e Media. Cada tupla na relação pode então ser interpretada como um fato ou uma instância em particular da afirmação. Por exemplo, a primeira tupla na Figura 5.1 afirma que existe um ALUNO cujo Nome é Bruno Braga, o Cpf é 305.610.243-51, a Idade é 19, e assim por diante. Observe que algumas relações podem representar fatos sobre entidades, enquanto outras podem representar fatos sobre relacionamentos. Por exemplo, um esquema de relação CURSAR (Cpf_aluno, Codigo_disciplina) afirma que os alunos cursaram disciplinas acadêmicas. Uma tupla nessa relação relaciona um aluno à disciplina cursada. Logo, o modelo relacionai representa fatos sobre entidades e relacionamentos uniformemente como relações. Isso às vezes compromete a compreensão, pois é preciso descobrir se uma relação representa um tipo de entidade ou um tipo de relacionamento. Apresentamos o modelo entidade-relacionamento (ER) com detalhes no Capítulo 3, no qual os conceitos de entidade e relacionamento foram descritos minuciosamente. Os procedimentos de mapeamento no Capítulo 9 mostram como diferentes construções dos modelos de dados conceituais ER e EER (ver na Parte 2) são convertidas em relações. Uma interpretação alternativa dc um esquema dc relação é como um predicado; neste caso, os valores cm cada tupla são interpretados como valores que satisfazem o predicado. Por exemplo, o predicado ALUNO (Nome, Cpf,...) é verdadeiro para as cinco tuplas na relação ALUNO da Eigura 5.1. Essas tuplas representam cinco proposições ou fatos diferentes no mundo real. Essa interpretação é muito útil no contexto das linguagens dc programação lógicas, como Prolog, pois permite que o modelo relacionai seja usado nessas linguagens (ver Seção 26.5). Um pressuposto, chamado pressuposto do mundo fechado, afirma que os únicos fatos verdadeiros no universo são os pre­ sentes dentro da extensão (estado) da(s) relação(ões). Qualquer outra combinação de valores torna o predicado falso. Essa interpretação será útil quando considerarmos as consultas sobre relações baseadas em cálculo relacionai, na Seção 8.6. 5.1.3 Notação do modelo relacionai Usaremos a seguinte notação em nossa representação:

■ Um esquema de relação R dc grau n é indicado por R(A{, A2,..., An). ■ As letras maiúsculas Q, R, S indicam nomes de relação.

141

142 Sistemas de banco de dados ■ As letras minúsculas q, r, s indicam estados de relação. ■ As letras t, u, v indicam tuplas. ■ Em geral, o nome de um esquema de relação, como ALUNO, também indica o conjunto atual de tuplas nessa relação — o estado de relação atual —, enquanto ALUNO(Nome, Cpf,...) refere-se apenas ao esquema de relação. ■ Um atributo A pode ser qualificado com o nome de relação R ao qual pertence usando a notação de ponto R.A — por exemplo, ALUNO.Nome ou ALUNO.Idade. Isso porque o mesmo nome pode ser usado para dois atributos em relações diferentes. Contudo, todos os nomes de atributo em uma relação em particular precisam ser distintos. ■ Uma tupla-H t em uma relação r(R) é indicada por t = da relação ALUNO na Eigura 5.1; temos t[Nome] = e £[Cpf, Media, Idade] = .

5.2 Restrições em modelo relacionai e esquemas de bancos de dados relacionais Até aqui, discutimos as características de relações isoladas. No banco de dados relacionai, normalmente haverá muitas relações, e as tuplas nessas relações costumam estar relacionadas de várias maneiras. O estado do banco de dados inteiro corres­ ponderá aos estados de todas as suas relações em determinado ponto no tempo. Em geral, existem muitas restrições (ou constraints) sobre os valores reais em um estado do banco de dados. Essas restrições são derivadas das regras no minimundo que o banco de dados representa, conforme discutido na Seção 1.6.8. Nesta seção, discutiremos as diversas restrições sobre os dados que podem ser especificadas em um banco de dados relacionai na forma de restrições. As restrições nos bancos de dados geralmente podem ser divididas cm três categorias principais: 1. Restrições inerentes no modelo de dados. Chamamos estas de restrições inerentes baseadas no modelo ou restrições implícitas.

2. Restrições que podem ser expressas diretamente nos esquemas do modelo de dados, em geral especificando-as na DDL (linguagem de definição de dados; ver Seção 2.3.1). Chamamos estas de restrições baseadas em esquema ou restrições explícitas. 3. Restrições que não podem ser expressas diretamente nos esquemas do modelo de dados, e, portanto, devem ser expressas e impostas pelos programas de apli­ cação ou de alguma outra maneira. Chamamos estas dc restrições baseadas na aplicação, restrições semânticas ou regras dc negócios. As características das relações que discutimos na Seção 5.1.2 são as restrições inerentes do modelo relacionai e pertencem à primeira categoria. Por exemplo, a restrição de que uma relação não pode ter tuplas duplicadas é uma restrição inerente. As restrições que discutimos nesta seção são da segunda categoria, a saber, restrições

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

que podem ser expressas no esquema do modelo relacionai por meio da DDL. As restrições da terceira categoria sào mais gerais, relacionando-se ao significado e também ao comportamento dos atributos, e sào difíceis de expressar e impor dentro do modelo de dados, de modo que normalmente sào verificadas nos programas de aplicaçào que realizam as atualizações no banco de dados. Em alguns casos, essas restrições podem ser especificadas como asserções em SQL (ver Capítulo 7). Outra categoria importante de restrições é a dc dependências de dados, que incluem dependências funcionais e dependências multivaloradas. Elas sào usadas principalmcntc para testar a “virtude” do projeto de um banco dc dados relacionai e em um processo chamado normalização, que será discutido nos capítulos 14 e 15. As restrições baseadas em esquema incluem restrições de domínio, restrições de chave, restrições sobre NULLs, restrições de integridade de entidade e restrições de integridade referencial.

5.2.1 Restrições de domínio As restrições de domínio especificam que, dentro de cada tupla, o valor de cada atributo A deve ser um valor indivisível do domínio dom(A). Já discutimos as manei­ ras como os domínios podem ser especificados na Scçào 5.1.1. Os tipos dc dados associados aos domínios normalmente incluem os tipos de dados numéricos padrão para inteiros (como short integer, integer e long integer) e números reais (float e double-precision float). Caracteres, booleanos, cadeia de caracteres de tamanho fixo e cadeia de caracteres de tamanho variável também estão disponíveis, assim como data, hora, marcador de tempo, moeda ou outros tipos de dados especiais. Outros domínios também podem ser descritos por um subintervalo dos valores de um tipo de dados ou como um tipo dc dado enumerado, em que todos os valores possíveis sào listados explicitamente. Em vez de descrevê-los com detalhes aqui, discutiremos os tipos de dados oferecidos pelo padrão relacionai SQL na Seção 6.1.

5.2.2 Restrições de chave e restrições sobre valores NULL No modelo relacionai formal, uma relação é definida como um conjunto de tuplas. Por definição, todos os elementos de um conjunto são distintos; logo, rodas as tuplas em uma relação também precisam ser distintas. Isso significa que duas tuplas não podem ter a mesma combinação de valores para todos os seus atributos. Normalmente, existem outros subconjuntos de atributos de um esquema de relação K com a propriedade de que duas tuplas em qualquer estado dc relação r de R nào deverão ter a mesma combinação de valores para esses atributos. Suponha que indi­ quemos um subconjunto de atributos desse tipo como SCh; então, para duas tuplas distintas quaisquer e í2 em um estado de relação r de R, temos a restrição de que: í,[SCh]

í2[SCh]

Qualquer conjunto de atributos SCh desse tipo é chamado de superchave do esquema de relação R. Uma superchave SCh especifica uma restrição de exclusividade de que duas tuplas distintas em qualquer estado r de R não podem ter o mesmo valor dc SCh. Cada relação tem pelo menos uma superchave padrão — o conjunto dc todos os seus atributos. Contudo, uma superchave pode ter atributos redundantes, de modo que um conceito mais útil é o dc uma chave, que não tem redundância. Uma chave Ch de um esquema de relação R é uma superchave de R com a propriedade adicional de que a remoção de qualquer atributo /I de Ch deixa um conjunto de atributos Ch' que nào é mais uma superchave de R. Logo, uma chave satisfaz duas propriedades: 1. Duas tuplas distintas em qualquer estado da relação não podem ter valores idênticos para (todos) os atributos na chave. Essa propriedade de exclusividade também se aplica a uma superchave.

143

144 Sistemas de banco de dados

2. Ela é uma superchave mínima — ou seja, uma superchave da qual nào podemos remover nenhum atributo e ainda mantemos uma restrição de exclusividade. Essa propriedade é exigida para uma chave, mas nào para uma superchave. Assim, uma chave também é uma superchave, mas nào o contrário. Uma super­ chave pode ser uma chave (se for mínima) ou pode nào ser (se não for mínima). Considere a relação ALUNO da Figura 5.1. O conjunto de atributos (Cpf) é uma chave de ALUNO porque duas tuplas de aluno não podem ter o mesmo valor para Cpf.8 Qualquer conjunto de atributos que inclua Cpf — por exemplo, {Cpf, Nome, Idade) — é uma superchave. No entanto, a superchave {Cpf, Nome, Idade) não é uma chave de ALUNO, pois remover Nome, Idade ou ambos do conjunto ainda nos deixa com uma superchave. Em geral, qualquer superchave formada com base em um único atributo também é uma chave. Uma chave com múltiplos atributos precisa exigir que todos os seus atributos juntos tenham uma propriedade de exclusividade. O valor de um atributo de chave pode ser usado para identificar exclusivamente cada tupla na relação. Por exemplo, o valor de Cpf 305.610.243-51 identifica exclu­ sivamente a tupla correspondente a Bruno Braga na relação ALUNO. Observe que um conjunto dc atributos constituindo uma chave é uma propriedade do esquema de relação; essa é uma restrição que deve ser mantida sobre cada estado de relação válido do esquema. Uma chave é determinada com base no significado dos atributos, e a propriedade é invariável no tempo-, ela precisa permanecer verdadeira quando inse­ rimos novas tuplas na relação. Por exemplo, não podemos e não devemos designar o atributo Nome da relação ALUNO da Figura 5.1 como uma chave, pois é possível que dois alunos com nomes idênticos existam em algum ponto em um estado válido.9 Em geral, um esquema de relação pode ter mais de uma chave. Nesse caso,cada uma das chaves é chamada de chave candidata. Por exemplo, a relação CARRO na Figura 5.4 tem duas chaves candidatas: Placa e Numero_chassi. É comum designar uma das

chaves candidatas como chave primária (ChP, primary key, PK) da relação. Essa é a chave candidata cujos valores são usados para identificar tuplas na relação. Usamos a convenção de que os atributos que formam a chave primária de um esquema de rela­ ção são sublinhados, como mostra a Figura 5.4. Observe que, quando um esquema de relação tem várias chaves candidatas, a escolha de uma para se tomar a chave primária é um tanto quanto arbitrária; porém, normalmente é melhor escolher uma chave pri­ mária com um único atributo ou um pequeno número de atributos. As outras chaves candidatas são designadas como chaves únicas (unique keys), e não são sublinhadas. CARRO

Figura 5.4 A relação CARRO, com duas chaves candidatas: Placa e Numero_chassi.

Ano

Placa

Numero chassi

Marca

Itatiaia ABC-7039

A6935207586

Volkswagen

Gol

02

ltuTVP-3470

B4369668697

Chevrolet

Corsa

05

Santos MPO-2902

X8355447376

Rat

Uno

01

ltanhaemTFY-6858

C4374268458

Chevrolet

Celta

99

Itatiba RSK-6279

Y8293586758

Renault

Clio

04

Atibaia RSK-6298

U0283657858

Volkswagen

Parati

04

Modelo

s Observe que Cpf também c uma superchave. 9 Os nomes às vezes sào usados como chaves, mas, nesse caso, algum artefato — como anexar um nú­ mero ordinal — precisa ser usado para distinguir pessoas com nomes idênticos.

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais Outra restrição sobre os atributos especifica se valores NULL sào permitidos ou não. Por exemplo, se cada tupla de ALUNO precisar ter um valor válido, diferente de NULL, para o atributo Nome, então Nome de ALUNO é restrito a ser NOT NULL.

5.2.3 Bancos de dados relacionais e esquemas de banco de dados

relacionai As definições e as restrições que discutimos até aqui se aplicam a relações isoladas e seus atributos. Um banco de dados relacionai costuma conter muitas relações, com tuplas nas relações que estão relacionadas de várias maneiras. Nesta seção, definimos um banco dc dados relacionai e um esquema de banco de dados relacionai. Um esquema de banco de dados relacionai 5 é um conjunto de esquemas de relação 5 = {Rj, R,, ..., Rw| e um conjunto de restrições de integridade RI. Um estado de banco de dados relacionai10 DB de 5 é um conjunto de estados de rela­ ção DB = (rj, r2> •••> rm), tal que cada rf é um estado de R, e tal que os estados da relação r, satisfazem as restrições de integridade especificadas em RI. A Figura 5.5 mostra um esquema de banco de dados relacionai que chamamos de EMPRESA = {FUNCIONÁRIO, DEPARTAMENTO, LOCALIZACOES.DEPARTAMENTO, PROJETO, TRABALHA_EM, DEPENDENTE}. Em cada esquema de relação, o atributo sublinhado representa a chave primária. A Figura 5.6 mostra um estado de banco de dados relacionai correspondente ao esquema EMPRESA. Usaremos esse esquema e estado de banco dc dados neste capítulo c nos capítulos 6 a 8 para desenvolver consultas dc exemplo em diferentes linguagens relacionais.

FUNCIONÁRIO Primeiro_ nome

Ultimo_ nome

Nome_ meio

Data_ nascimento

Cpf

Endereço

Sexo

Salario

Cpf supervisor

DEPARTAMENTO Nome_departamento

Numero_departamento

Cpf gerente

Data_inicio_gerente

LOCALIZACOES-DEPARTAMENTO Numero_departamento

Local

PROJETO Nome_projeto

Numero projeto

LocaLprojeto

Numero_departamento

TRABALHA-EM Cpf funcionario

Numero-projeto

Horas

DEPENDENTE Cpf_fundonario

Nomedependente

Sexo

Data_nasci mento

Parentesco

Figura 5.5 Diagrama de esquema para o esquema de banco de dados relacionai EMPRESA.

1,1 Um estudo dc banco dc dados rdacionai às vezes c chamado dc instância dc banco dc dados rela­ cionai. No enranro, como mencionamos anreriormenre, nào usaremos o termo instância porque ele também se aplica a tuplas isoladas.

Numero_ departa• mento

145

146 Sistemas de banco de dados FUNCIONÁRIO

Primeiro, Nome_ Ultimo_ nome

meio

Çfif

nome

Numero

Data,

Endereço

nasdmento

Sexo Salario Cpf_supervisor

departa­ mento

João

B

Silva

12345678966 09-01-1965

Rua das Flores, 751. São Paulo, SP

M

30.000

33344555587

5

Fernando

T

Wong

33344555587 08-12-1955

Rua da Lapa, 34, São Paulo, SP

M

40.000

88866555576

5

Alice

J

Zelaya

99988777767 19-01-1968

Rua Souza Uma, 35, Curitiba, PR

F

25.000

98765432168

4

Jennifer

S

Souza

98765432168 20-06-1941

F

43.000

88866555576

4

Ronaldo

K

Uma

66688444476 15-09-1962

Rua Rebouças, 65, Piracicaba, SP

M

38.000

33344555587

5

Joice

A

Leite

45345345376 31-07-1972

Av. Lucas Obes, 74, São ftiulo, SP

F

25.000

33344555587

5

André

V

Pereira

98798798733 29-03-1969

Rua Timbira, 35, São Paulo, SP

M

25.000

98765432168

4

Jorge

E

Brito

88866555576 10-11-1937

Rua do Horto, 35, São Paulo, SP

M

55.000

NULL

1

Av. Arthur de Uma, 54, Santo André, SP

LOCALIZACOES_DEPARTAMENTO

DEPARTAMENTO

Nome, departamento

Numero, departamento

Cpfgerente

Numero_departamento

Data_inido_ gerente

Pesquisa

5

33344555587

22-05-1988

Administração

4

98765432168

01-01-1995

Matriz

1

88866555576

19-06-1981

Local

1

São Paulo

4

Mauá

5

Santo André

5

Itu

5

São Paulo

PROJETO

TRABALHA_EM

Numero,

Numero,

Cpf_funcionario

Numero projeto

Horas

12345678966

1

32,5

ProdutoX

1

Santo André

5

12345678966

2

7,5

ProdutoY

2

itu

5

66688444476

3

40,0

ProdutoZ

3

São Paulo

5

45345345376

1

20,0

Informatização

10

Mauá

4

45345345376

2

20,0

Reorganização

20

São Paulo

1

33344555587

2

10,0

Novosbenefkios

30

Mauá

4

33344555587

3

10,0

33344555587

10

10.0

33344555587

20

10,0

99988777767

30

30,0

Sexo

Data_nasdmento

Parentesco

99988777767

10

10,0

98798798733

10

35,0

98798798733

30

5,0

98765432168

30

20,0

98765432168

20

15,0

88866555576

20

NULL

Nome projeto

projeto

Local projeto

departamento

DEPENDENTE

Cpf_funcionario

Nome, dependente

33344555587

Alicia

F

05-04-1986

Filha

33344555587

Tiago

M

25-10-1983

filho

33344555587

Janaína

F

03-05-1958

Esposa

98765432168

Antonio

M

28-02-1942

Marido

12345678966

Mkhael

M

04-01-1988

filho

12345678966

Alicia

F

30-12-1988

filha

12345678966

Elizabeth

F

05-05-1967

Esposa

Figura 5.6 Um estado de banco de dados possível para o esquema de banco de dados relacionai EMPRESA.

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

Quando nos referimos a um banco de dados relacionai, implicitamente incluímos seu esquema e seu estado atual. Um estado de banco de dados que nào obedece a todas as restrições de integridade é chamado de estado inválido, e um estado que satisfaz todas as restrições no conjunto definido de restrições de integridade RI é chamado de estado válido. Na Figura 5.5, o atributo Numero_departamento em DEPARTAMENTO e LOCALIZACOES_DEPARTAMENTO significa o conceito do mundo real — o número dado a um departamento. O mesmo conceito é chamado Numero_departamento em FUNCIONÁRIO e Numero_departamento em PROJETO. Os atributos que representam o mesmo conceito do mundo real podem ou nào ter nomes idênticos em diferentes relações. Como alternativa, os atributos que representam diferentes conceitos podem ter o mesmo nome em diferentes relações. Por exemplo, poderiamos ter usado o nome de atributo Nome para Nome_projeto de PROJETO e Nome_departamento de DEPARTAMENTO; neste caso, teríamos dois atributos compartilhando o mesmo nome, mas representando diferentes conceitos do mundo real — nomes de projeto e nomes de departamento. Em algumas versões antigas do modelo relacionai, era feita uma suposição de que o mesmo conceito do mundo real, quando representado por um atributo, teria nomes de atributo idênticos em todas as relações. Isso cria problemas quando o mesmo conceito do mundo real é usado em diferentes papéis (significados) na mesma relação. Por exemplo, o conceito de Cadastro de Pessoa Física aparece duas vezes na relação FUNCIONÁRIO da Figura 5.5: uma no papel do CPF do funcionário e outra no papel do CPF do supervisor. Precisamos dar-lhes nomes de atributo distintos — Cpf e Cpf_supervisor, respectivamente — porque eles aparecem na mesma relação e a fim de distinguir seu significado. Cada SGBD relacionai precisa ter uma linguagem de definição de dados (DDL) para estabelecer um esquema de banco de dados relacionai. Os SGBDs relacionais atuais costumam usar principalmente SQL para essa finalidade. Apresentaremos a DDL SQL nas seções 6.1 e 6.2. Restrições de integridade são especificadas em um esquema de banco de dados e espera-se que sejam mantidas em cada estado de banco de dados válido desse esquema. Além das restrições de domínio, chave e NOT NULL, dois outros tipos de restrições são considerados parte do modelo relacionai: integridade de entidade e integridade referencial. 5.2.4 Integridade, integridade referencial e chaves estrangeiras

A restrição de integridade de entidade afirma que nenhum valor de chave pri­ mária pode ser NULL. Isso porque o valor da chave primária é usado para identificar tuplas individuais em uma relação. Ter valores NULL para a chave primária implica que nào podemos identificar algumas tuplas. Por exemplo, se duas ou mais tuplas tivessem NULL para suas chaves primárias, não conseguiriamos distingui-las ao tentar referenciá-las a partir de outras relações. As restrições de chave e as restrições de integridade de entidade sào espe­ cificadas sobre relações individuais. A restrição de integridade referencial é especificada entre duas relações e usada para manter a consistência entre tuplas nas duas relações. Infonnalmcntc, a restrição dc integridade referencial afirma que uma tupla em uma relação que referencia outra relação precisa se referir a uma tupla existente nessa relação. Por exemplo, na Figura 5.6, o atributo Nu mero_departa mento de FUNCIONÁRIO fornece o número de departamento para

147

148 Sistemas de banco de dados o qual cada funcionário trabalha; logo, seu valor em cada tupla FUNCIONÁRIO precisa combinar com o valor de Numero_departamento de alguma tupla na relação DEPARTAMENTO. Para definir a integridade referencial de maneira mais formal, primeiro estabele­ cemos o conceito de uma chave estrangeira (ChE, ou foreign key, LK). As condições para uma chave estrangeira, dadas a seguir, especificam a restrição de integridade referencial entre os dois esquemas de relação R( e R2- Um conjunto de atributos ChE no esquema de relação é uma chave estrangeira de Rj que referencia a relação R, se eia satisfizer as seguintes regras: 1. Os atributos em ChE têm o mesmo domínio (ou domínios) que os atributos de chave primária ChP de R2; diz-se que os atributos ChE referenciam ou referem-se à relação R,.

2. Um valor de ChE em uma tupla í, do estado atual r^RJ ocorre como um valor de ChP para alguma tupla t2 no estado atual r2(R2) ou é NULL. No primeiro caso, temos íJChEJ = rJChPJ, e dizemos que a tupla referencia ou refere-se à tupla í2. Nessa definição, R, é chamada de relação que referencia e R, éa relação refe­ renciada. Se essas condições se mantiverem, diz-se que é mantida uma restrição de integridade referencial de R] para R2. Em um banco de dados de muitas relações, normalmente existem muitas restrições de integridade referencial. Para especificar essas restrições, primeiro devemos ter um conhecimento claro do significado ou papel que cada atributo (ou conjunto de atributos) desempenha nos diversos esquemas de relação do banco de dados. As restrições de integridade referencial surgem com frequência a partir dos relacionamentos entre as entidades representadas pelos esquemas de relação. Por exemplo, considere o banco de dados mostrado na Figura 5.6. Na relação FUNCIONÁRIO, o atributo Numero.departamento refere-se ao departamento para o qual um funcionário trabalha; portanto, designa­ mos Numero_departamento para ser a chave estrangeira dc FUNCIONÁRIO que referen­ cia a relação DEPARTAMENTO. Isso significa que um valor de Numero_departamento em qualquer tupla tx da relação FUNCIONÁRIO precisa combinar com um valor da chave primária de DEPARTAMENTO — o atributo Numero.departamento — em alguma tupla í2 da relação DEPARTAMENTO, ou o valor de Numero_departamento pode ser NULL se o funcionário não pertencer a um departamento ou se mais tarde for atribuído a um departamento. Por exemplo, na Figura 5.6, a tupla para o funcionário ‘João Silva' referencia a tupla para o departamento ‘Pesquisa’, indicando que ‘João Silva' trabalha para esse departamento. Observe que uma chave estrangeira pode se referir à sua própria relação. Por exemplo, o atributo Cpf_supervisor em FUNCIONÁRIO refere-se ao supervisor de um funcionário; esse é outro funcionário, representado por uma tupla na relação FUNCIONÁRIO. Logo, Cpf_supervisor é uma chave estrangeira que referencia a pró­ pria relação FUNCIONÁRIO. Na Figura 5.6, a tupla que o funcionário ‘João Silva' referencia é a do funcionário ‘Fernando Wong’, indicando que ‘Fernando Wong’ é o supervisor de ‘João Silva’. Podemos exibir as restrições de integridade referencial em forma de diagrama, desenhando um arco direcionado de cada chave estrangeira para a relação que ela referencia. Para ficar mais claro, a ponta da seta pode apontar para a chave primá­ ria da relação referenciada. A Figura 5.7 mostra o esquema da Figura 5.5 com as restrições de integridade referencial mostradas dessa maneira.

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

FUNCIONÁRIO Primeiro nome

Ultimo nome

Nome meio

Data nascimento

Endereço

Sexo

Salario

Cpf supervisor

Numero_ departa­ mento

DEPARTAMENTO

Nome departamento

Numero departamento

Cpf gerente

Datajnicio gerente

LOCALIZACOES_DEPARTAMENTO Numero_departamento

Local

1-

PROJETO

Nome projeto

Numero projeto

TRABALHA_EM

t

Cpf_funcionario

LocaLprojeto

Numero_projeto

Numero departamento

Horas

I DEPENDENTE Cpf fundonario

Nome_dependente

Sexo

Data_nascimento

Parentesco

L

Figura 5.7 Restrições de integridade referencial exibidas no esquema de banco de dados relacionai EMPRESA.

Todas as restrições de integridade deverão ser especificadas no esquema de banco de dados relacionai (ou seja, especificadas como parte dc sua definição) se quisermos que o SGBD imponha essas restrições sobre os estados do banco de dados. Logo, a DDL inclui meios para especificar os diversos tipos de restrições de modo que o SGBD possa impô-las automaticamente. Na SQL, o comando CREATE TABLE da DDL SQL permite a definição dc restrições de chave primária, chave única, NOT NULL, integridade de entidade e integridade referencial, entre outras (ver seções 6.1 e 6.2). 5.2.5 Outros tipos de restrições

As restrições de integridade anteriores estão incluídas na linguagem de definição de dados porque ocorrem na maioria das aplicações de banco de dados. No entanto, elas não incluem uma grande classe de restrições gerais, também chamadas de restri­ ções de integridade semântica, que podem ter de ser especificadas e impostas de uma maneira diferente. Alguns exemplos dessas restrições são o salário de um funcionário não deve ser superior ao de seu supervisor e o número máximo de horas que um funcionário pode trabalhar em todos os projetos por semana é 56. Essas restrições podem ser especificadas e impostas em programas de aplicação que atualizam o banco de dados, ou utilizando uma linguagem dc especificação dc restrição de uso geral. Mecanismos chamados triggers (gatilhos) e assertions (afirmações) podem ser usados na SQL, por meio dos comandos CREATE ASSERTION e CREATE TRIGGER, para especificar algumas dessas restrições (ver Capítulo 7). E mais comum verificar esses tipos de restrições cm programas de aplicação que usar linguagens de especificação

149

150 Sistemas de banco de dados de restrição, pois estas às vezes são difíceis e complexas de usar, conforme discuti­ remos na Seção 26.1. Os tipos de restrições que discutimos até aqui podem ser chamados de restrições de estado, pois definem as restrições às quais um estado válido do banco de dados precisa satisfazer. Outro tipo de restrição, chamado restrições de transição, pode ser definido para lidar com mudanças de estado no banco de dados.11 Um exemplo de uma restrição dc transição é: “o salário dc um funcionário só pode aumentar’’. Tais restrições costumam ser impostas pelos programas dc aplicação ou especificadas usando regras ativas e triggers, conforme discutiremos na Seção 26.1.

5.3 Operações de atualização, transações e tratamento de violações de restrição As operações do modelo relacionai podem ser categorizadas em recuperações e atualizações. As operações da álgebra relacionai, que podem ser usadas para espe­ cificar recuperações, serão discutidas com detalhes no Capítulo 8. Uma expressão da álgebra relacionai forma uma nova relação após a aplicação de uma série de operadores algébricos a um conjunto existente de relações; seu uso principal é consultar um banco de dados a fim de recuperar informações. O usuário formula uma consulta que especifica os dados de interesse, e uma nova relação é formada aplicando-se operadores relacionais para recuperar esses dados. Esta relação resul­ tado torna-se a resposta para a (ou resultado da) consulta do usuário. O Capítulo 8 também introduz a linguagem chamada cálculo relacionai, que é usada para definir a nova relação de forma declarati va sem dar uma ordem específica das operações. Nesta seção, concentramo-nos nas operações de modificação ou atualização do banco de dados. Existem três operações básicas que podem mudar os estados das relações: Inserii; Excluir e Alterar (ou Modificar). Elas inserem novos dados, excluem dados antigos ou modificam registros de dados existentes, respectivamente. Inserir (Insert) é usado para inserir uma ou mais novas tuplas em uma relação. Excluir (Delete) é usado para excluir tuplas, e Alterar (Update ou Modificar) é usado para alterar os valores de alguns atributos nas tuplas existentes. Sempre que essas ope­ rações são aplicadas, as restrições dc integridade especificadas sobre o esquema de banco de dados relacionai não devem ser violadas. Nesta seção, discutimos os tipos de restrições que podem ser violadas por cada uma dessas operações e os tipos de ações que podem ser tomados se uma operação causar uma violação. Usamos o banco dc dados mostrado na Figura 5.6 para os exemplos c discutimos apenas as restrições dc domínio, dc chave, dc integridade dc entidade c dc integridade referen­ cial, mostradas na Figura 5.7. Para cada tipo de operação, damos alguns exemplos e discutimos as restrições que cada operação pode violar.

5.3.1 A operação Inserir A operação Inserir (Insert) oferece uma lista dc valores dc atributo para que uma nova tupla t possa ser inserida em uma relação R. Ela pode violar qualquer um dos quatro tipos de restrições discutidos na seção anterior. As restrições de domínio podem ser violadas se for dado um valor de atributo que não aparece no domínio correspondente ou não é do ripo de dado apropriado. As restrições de chave podem ser violadas se um valor de chave na nova tupla t já existir em outra tupla na relação r(R). A integridade dc entidade pode ser violada se qualquer parte da chave primária 11 As restrições de estado também podem ser chamadas de ção também sào chamadas de restrições dinâmicas.

restrições estáticas, e as restrições de transi­

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais

da nova tupla t for NULL A integridade referencial pode ser violada se o valor de qualquer chave estrangeira em í se referir a uma tupla que nào existe na relação referenciada. Aqui estão alguns exemplos para ilustrar esta discussão. ■ Operação: Inserir em FUNCIONÁRIO. Resultado: esta inserção viola a restrição de integridade de entidade (NULL para a chave primária Cpf), de modo que é rejeitada. ■ Operação: Inserir em FUNCIONÁRIO. Resultado: esta inserção viola a restrição de chave porque outra tupla com o mesmo valor de Cpf já existe na relação FUNCIONÁRIO e, portanto, é rejeitada. ■ Operação: Inserir em DEPARTAMENTO. d. Inserir em TRABALHA.EM. c. Inserir em DEPENDENTE. f. Excluir as tuplas de TRABALHA.EM com Cpf.funcionario = ‘33344555587’. g. Excluir a tupla de FUNCIONÁRIO com Cpf = ‘98765432168’. h. Excluir a tupla de PROJETO com Nome_projeto = ‘ProdutoX’. i. Modificar Cpf.gerente e Data_inicio_gerente da tupla DEPARTAMENTO com Numero_departamento = 5 para ‘12345678966’ e ‘01-10-2007’, respectivamente. j. Modificar o atributo Cpf.supervisor da tupla FUNCIONÁRIO com Cpf = ‘* 99988777767 para ‘94377554355’. k. Modificar o atributo Horas da tupla TRABALHA.EM com Cpf.funcionario = ‘* 99988777767 e Numero_projeto =10 para ‘5,0’. 5.12. Considere o esquema do banco dc dados relacionai COMPANHIA.AEREA mostrado na Figura 5.8, que descreve um banco de dados para informa­ ções de voo. Cada VOO é identificado por um Numero.voo, e consiste em um ou mais TRECHOs com Numero.trecho 1, 2, 3, e assim por diante. Cada TRECHO tem horários agendados dc chegada c saída, aeroportos e um ou mais TRECHOs.SOBREVOADOs — um para cada Data em que o voo ocorre. TARIFAs são mantidas para cada VOO. Para cada instância de TRECHO.SOBREVOADO, RESERVAs.ASSENTO são mantidas, assim como a AERONAVE usada no trecho e os horários de chegada e saída reais e aeroportos. Uma AERONAVE é identificada por um Codigo.aeronave e tem um TIPO.AERONAVE em particular. PODE.POUSAR relaciona os MODELOs. AERONAVE aos AEROPORTOS cm que eles podem aterrissar. Um AEROPORTO é identificado por um Codigo_aeroporto. Considere uma atualização para o banco de dados COMPANHIA.AEREA entrar com uma reserva em um voo em particular ou trecho de voo em determinada data. a. Indique as operações para esta atualização. b. Que tipos de restrições você esperaria verificar? c. Quais dessas restrições são de chave, de integridade de entidade e de integridade referencial, e quais não são? d. Especifique rodas as restrições de integridade referencial que se mantêm no esquema mostrado na Figura 5.8. 5.13. Considere a relação AULA(Cod_disciplina, Cod.turma, Nome_professor, Semestre, Codigo.edificio, Num.sala, Turno, Dias.da.semana, Créditos). Isso representa as aulas lecionadas em uma universidade, com Cod.turma único. Identifique quais você acha que devem ser as diversas chaves candidatas e escreva, com suas palavras, as condições ou suposições sob as quais as chaves candidatas seriam válidas.

155

156 Sistemas de banco de dados

AEROPORTO

Nome

Codigo_aeroporto

Cidade 1 Estado

VOO

Numero voo

Companhia.aerea

Dias_da_semana

TRECHO Numero voo

Numero trecho

Codigo_aeroporto_ inicia

Horariojnicia

Codigo_aeroporto_ finaliza

Horário termino

TRECHO-SOBREVOADO Numero.voo

Numerotrecho

Numero, assentos, disponíveis

Data

Codigo, aeronave

Codigo, aeroporto, inicia

Horariojnicia

Codigo, aeroporto, finaliza

Horário, termino

TARIFA Numero voo

Codigo tarifa

Quantidade | Restrições

MODELO-AERONAVE

Maximo assentos |

Nome modelo

Empresa

PODE.POUSAR

Nome,modelo

Codigo_aeroporto

]

AERONAVE

Codigo_aeronave

Numero_total_assentos

Modelo.aeronave

RESERVA,ASSENTO Numero voo

Numero trecho

Data

Numero assentos

Nome_cliente

Telefone.cliente

Figura 5.8 O esquema do banco de dados relacionai COMPANHIA,AEREA.

5.14. Considere as seis relações a seguir para uma aplicação de banco de dados de processamento de pedido em uma empresa:

CLIENTE(Num_cliente, Nome_cliente, Cidade) PEDIDO(Num_pedido, Data_pedido, Num_diente, Valor_pedido) ITEM_PEDIDO(Num_pedido, Numjtem, Quantidade) ITEM(Num_item, Preco_unitario) EXPEDICAO(Num_pedido, Num_deposito, Data.envio) DEPOSITO(Num_deposito, Cidade) Aqui, Valor_pedido refere-se ao valor total em reais de um pedido; Data.pedido é a data em que o pedido foi feito; e Data_envio é a data em que um pedido (ou parte dc um pedido) c despachado do depósito. Suponha que um pedido possa ser despachado de vários depósitos. Especifique chaves estrangeiras para esse esquema, indicando quaisquer suposições que você faça. Que outras restrições você imagina para esse banco dc dados? 5.15. Considere as seguintes relações para um banco dc dados que registra viagens dc negócios dc vendedores cm um escritório dc vendas: VENDEDOR(Cpf, Nome. Anojnicio, Numero.departamento)

Capitulo 5 O modelo de dados relacionai e as restrições em bancos de dados relacionais VIAGEM(Cpf, Cidade_origem, Cidade.destino, Data_partida, Data_retorno, Cod_viaqem) DESPESA(Cod_viagem, Num_conta, Valor)

Uma viagem pode ser cobrada de uma ou mais contas. Especifique as chaves estrangeiras para esse esquema, indicando quaisquer suposições que você faça. 5.16. Considere as seguintes relações para um banco de dados que registra a matrí­ cula do aluno nas disciplinas e os livros adotados para cada disciplina: ALUNO(Cof, Nome, Curso, Data_nascimento) DISCIPLINA(Cod_disciplina, Nome_disciplina, Departamento) INSCRICAO(Çpf, Cod_disciplina, Semestre. Nota) UVRO_ADOTADO(Cod_disciplina, Semestre. ISBNJivro) UVRQ(ISBN_livro, TituloJivro, Editora, Autor)

Especifique as chaves estrangeiras para este esquema, indicando quaisquer suposições que você faça. 5.17. Considere as seguintes relações para um banco de dados que registra vendas dc automóveis cm um revendedor dc carros (OPCIONAL refere-se a algum equipamento opcional instalado em um automóvel):

CARRO(Numero chassi, Modelo, Fabricante, Preco) OPCIONAL(Numero_chassi, Nome_opcional, Preco) VENDA(Cod vendedor, Numero chassi. Data, Preco_venda) VENDEDOR(Cod_vendedor, Nome, Telefone) Primeiro, especifique as chaves estrangeiras para este esquema, indicando quaisquer suposições que você faça. Depois, preencha as relações com algumas tuplas de exemplo, e então mostre um exemplo de uma inserção nas relações VENDA e VENDEDOR que viola as restrições dc integridade referencial c dc outra inserção que não viola as restrições. 5.18. O projeto de banco de dados normalmente envolve decisões sobre o arma­ zenamento de atributos. Por exemplo, o Cadastro de Pessoa Física pode ser armazenado como um atributo ou dividido em quatro atributos (um para cada um dos quatro grupos separados por hífen em um Cadastro de Pessoa Física — XXX-XXX-XXX-XX). Porém, os números do Cadastro de Pessoa Física costumam ser representados como apenas um atributo. A decisão é baseada em como o banco de dados será usado. Este exercício pede para você pensar nas situações específicas nas quais a divisão do CPF c útil. 5.19. Considere uma relação ALUNO em um banco de dados UNIVERSIDADE com os seguintes atributos (Nome, Cpf, Telefonejocal, Endereço, Telefone_celular, Idade, Media). Observe que o telefone celular pode ser dc cidade e estado diferentes do telefone local. Uma tupla possível da relação é mostrada a seguir:

Nome

Cpf

Telefonejocal

Endereço

Telefone_celular

Idade

Media

Jorge Pereira William Ribeiro

123-459-678-97

5555-1234

Rua Cambará, 33, Bauru, SP

8555-4321

19

3,75

Identifique a informação crítica que falta nos atributos Telefonejocal e Telefone_celular. (Dica: como você liga para alguém que mora em um estado diferente?) b. Você armazenaria essa informação adicional nos atributos Telefonejocal e Telefone_celular ou incluiría novos atributos ao esquema para ALUNO? c. Considere o atributo Nome. Quais são as vantagens e desvantagens dc dividir esse campo de um atributo em três atributos (primeiro nome, nome do meio e sobrenome)?

a.

157

158 Sistemas de banco de dados

d. Que orientação geral você daria para decidir quando armazenar informa­ ções em um único atributo e quando separar a informação? e. Suponha que o aluno possa ter entre 0 e 5 telefones. Sugira dois projetos diferentes que permitam esse tipo de informação. 5.20. Mudanças recentes nas leis de privacidade dos EUA não permitem que as organizações usem números de Seguro Social (SSN) para identificar indivíduos, a menos que certas restrições sejam satisfeitas. Como resultado, a maioria das universidades nos EUA não pode usar SSNs como chaves primárias (exceto para dados financeiros). Na prática, Matricula, um identificador exclusivo atribuído a cada aluno, provavelmente será usado como chave primária, em vez do SSN, pois Matricula pode ser usada por todo o sistema. a. Alguns projetistas de banco de dados relutam em usar chaves geradas (também conhecidas como chaves substitutas) para chaves primárias (como Matricula), pois elas são artificiais. Você consegue propor algumas escolhas naturais dc chaves que possam ser usadas para identificar o registro do aluno no banco de dados UNIVERSIDADE? b. Suponha que você consiga garantir a exclusividade de uma chave natural que inclua sobrenome. Você tem garantias dc que ele não mudará durante o tempo de vida do banco de dados? Se o sobrenome puder mudar, quais soluções óbvias você pode propor para criar uma chave primária que ainda o inclua, mas permaneça exclusiva? c. Quais são as vantagens e desvantagens de usar chaves geradas (substitutas)?

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

O modelo relacionai foi introduzido por Codd (1970) em um artigo clássico. Codd também introduziu a álgebra relacionai e estabeleceu as bases teóricas para o modelo rela­ cionai em uma série de artigos (Codd, 1971,1972,1972a, 1974); mais tarde,ele recebeu o Turing Award, a honra mais alta da ACM (Association for Computing Machinery) por seu trabalho sobre o modelo relacionai. Em um artigo posterior; Codd (1979) discutiu a extensão do modelo relacionai para incorporar mais metadados e semântica sobre as relações; ele também propôs uma lógica de três valores para lidar com a incerteza nas relações e incorporar NULLs na álgebra relacionai. O modelo resultante é conhecido como RM/T. Childs (1968) usou inicialmente a teoria dc conjunto para modelar bancos de dados. Mais tarde, Codd (1990) publicou um livro examinando mais de 300 recursos do modelo de dados relacionai e sistemas de banco de dados. Date (2001) oferece uma crítica e análise retrospectiva do modelo de dados relacionai. Desde o trabalho pioneiro de Codd, muita pesquisa tem sido realizada sobre vários aspectos do modelo relacionai. Todd (1976) descreve um SGBD experimental, chamado PRTV, que implementa diretamente as operações da álgebra relacionai. Schmidt e Swenson (1975) apresentam semântica adicional para o modelo relacionai classificando diferentes tipos de relações. O modelo entidade-relacionamento de Chen (1976), que foi discutido no Capítulo 3,é um meio de comunicar a semântica do mundo real de um banco de dados relacionai no nível conceituai. Wiederhold e Elinasri (1979) introduzem diversos tipos de conexões entre relações para aprimorar suas restrições. As extensões do modelo relacionai serão discutidas nos capítulos 11 e 26. Notas bibliográficas adicionais para outros aspectos do modelo relacionai e suas linguagens, sistemas, extensões e teoria serão apresentados nos capítulos 6 a 9, 14,15,23 e 30. Maier (1983) e Atzeni e De Antonellis (1993) oferecem um extenso tratamento teórico do modelo de dados relacionai.

SQL básica linguagem SQL pode ser considerada um dos principais motivos para o sucesso dos bancos de dados relacionais comerciais. Como ela se tornou um padrão para esse tipo de banco de dados, os usuários ficaram menos preocupados com a migração de suas aplicações de outros tipos de sistemas — por exemplo, sistemas de rede e hierárquicos mais antigos — para sistemas relacionais. Isso aconteceu porque, mesmo que os usuários estivessem insatisfeitos com o pro­ duto de SGBD relacionai em particular que estavam usando, a conversão para outro produto de SGBD relacionai não seria tão cara ou demorada, pois os dois sistemas seguiam os mesmos padrões de linguagem. Na prática, é óbvio, existem muitas dife­ renças entre diversos pacotes dc SGBD relacionais comerciais. Porém, se o usuário for cuidadoso em usar apenas os recursos que fazem parte do padrão, e se os dois sistemas relacionais seguirem fielmente o padrão, a conversão entre ambos deverá ser bastante simplificada. Outra vantagem de ter esse padrão é que os usuários podem escrever comandos em um programa de aplicação de banco de dados que pode acessar dados armazenados em dois ou mais SGBDs relacionais sem ter de mudar a sublinguagem de banco de dados (SQL) se os sistemas admitirem a SQL padrão. Este capítulo apresenta o modelo relacionai prático, que é baseado no padrão SQL para SGBDs relacionais comerciais, enquanto o Capítulo 5 apresentou os conceitos mais importantes por trás do modelo de dados relacionai formal. No Capítulo 8 (seções 8.1 a 8.5), discutiremos as operações da álgebra relacionai, que são muito importantes para entender os tipos dc solicitações que podem ser especificadas em um banco de dados relacionai. Elas também são importantes para processamento e otimização de consulta em um SGBD relacionai, como veremos nos capítulos 18 e 19. No entanto, as operações da álgebra relacionai são consideradas muito técnicas para a maioria dos usuários de SGBD comercial, pois uma consulta em álgebra rela­ cionai é escrita como uma sequência de operações que, quando executadas, produz o resultado exigido. Logo, o usuário precisa especificar como — ou seja, em que

A

160 Sistemas de banco de dados ordem — executar as operações de consulta. Por sua vez, a linguagem SQL oferece uma interface de linguagem declaratiia de nível mais alto, de modo que o usuário apenas especifica qual deve ser o resultado, deixando a otimização real e as decisões sobre como executar a consulta para o SGBD. Embora a SQL inclua alguns recursos da álgebra relacionai, ela é em grande parte baseada no cálculo relacionai de tupla, que descrevemos na Seção 8.6. Porém, a sintaxe SQL é mais fácil dc ser utilizada que qualquer uma das duas linguagens formais. O nome SQL hoje é expandido como Structured Query Language (Linguagem de Consulta Estruturada). Originalmente, SQL era chamada de SEQUEL (Structured English QUEry Language) e foi criada e implementada na IBM Research como a interface para um sistema de banco dc dados relacionai experimental, chamado SYSTEM R. A SQL agora é a linguagem padrão para SGBDs relacionais comerciais. A padronização da SQL é um esforço conjunto do American National Standards Institute (ANSI) e da International Standards Organization (ISO),e o primeiro padrão SQL era chamado SQL-86 ou SQL1. Um padrão revisado e bastante expandido, denominado SQL-92 (também conhecido como SQL2), foi desenvolvido mais tarde. O próximo padrão reconhecido foi SQL: 1999, que começou como SQL3. Duas atualizações posteriores ao padrão foram SQL.-2003 e SQL:2006, que acrescentaram recursos dc XML (ver Capítulo 13), entre outras atualizações para a linguagem. Outra atualização em 2008 incorporou mais recursos de banco de dados de objeto na SQL (ver Capítulo 12), e ainda outra atualização foi a SQL:2011. Tentaremos abordar a última versão da SQL ao máximo possível, mas alguns dos recursos mais recentes são discutidos em outros capítulos. Também não é possível abordar a tota­ lidade da linguagem neste texto. É importante observar que, quando novos recursos são acrescentados à SQL, geralmente são necessários alguns anos para que alguns deles façam parte dos SGBDs SQL comerciais. SQL é uma linguagem de banco de dados abrangente: tem instruções para defi­ nição de dados, consultas e atualizações. Logo, ela é uma DDL e uma DML. Além disso, ela tem habilidades para definir visões sobre o banco de dados, para especificar segurança e autorização, para definir restrições de integridade e para especificar controles de transação. Ela também possui regras para embutir instruções SQL em uma linguagem de programação de uso geral, como Java ou C/C++.1 Os padrões SQL mais recentes (começando com SQL: 1999) são divididos cm uma especificação núcleo mais extensões especializadas. O núcleo deve ser imple­ mentado por todos os fornecedores de SGBDR que sejam compatíveis com SQL. As extensões podem ser implementadas como módulos opcionais a serem adquiridos independentemente para aplicações de banco de dados específicas, como minera­ ção de dados, dados espaciais, dados temporais, data warehousing, processamento analítico on-line (OLzXP), dados de multimídia e assim por diante. Como a SQL é muito importante (e muito grande), dedicamos dois capítulos para explicar seus recursos básicos. Neste capítulo, a Seção 6.1 descreve os comandos de DDL da SQL para a criação de esquemas e tabelas, e oferece uma visão geral dos tipos de dados básicos em SQL. A Seção 6.2 explica como são especificadas as restrições básicas, como chave e integridade referencial. A Seção 6.3 descreve as construções básicas da SQL para especificar consultas de recuperação, e a Seção 6.4 descreve os comandos SQL para inserção, exclusão e alteração de dados. No Capítulo 7, descreveremos as consultas de recuperação SQL mais comple­ xas, bem como comandos ALTER para alterar o esquema. Também descreveremos a instrução CREATE ASSERTION, que permite a especificação de restrições mais gerais 1 Originalmente, a SQL tinha instruções para criar e remover índices nos arquivos que representam as relações, mas estas foram retiradas do padrão SQL por algum tempo.

Capitulo 6 SQL básica no banco de dados, e o conceito de triggers, que será abordado com mais detalhes no Capítulo 26. Descrevemos a habilidade SQL para definir views no banco dc dados no Capítulo 7. As views também sào conhecidas como tabelas virtuais ou tabelas derivadas, pois apresentam ao usuário o que parecem ser tabelas; porém, a informação nessas tabelas é derivada de tabelas previamente definidas. A Seção 6.5 lista alguns dos recursos da SQL que serão apresentados em outros capítulos do livro; entre eles estão os recursos orientados a objeto no Capítulo 12, XML no Capítulo 13, controle dc transação no Capítulo 20, bancos de dados ativos (triggers) no Capítulo 26, recursos de processamento analítico on-line (OLAP) no Capítulo 29 e segurança/autorização no Capítulo 30. A Seção 6.6 resume o capítulo. Os capítulos 10 e 11 discutem as diversas técnicas de programação em banco de dados para programação com SQL.

6.1 Definições e tipos de dados em SQL A SQL usa os termos tabela, linha c coluna para os termos do modelo relacionai formal relação, tupla e atributo, respectivamente. Usaremos os termos correspon­ dentes para indicar a mesma coisa. O principal comando SQL para a definição de dados é o CREATE, que pode ser usado para criar esquemas, tabelas (relações), tipos e domínios, bem como outras construções, como views, assertions e triggers. Antes de descrevermos as instruções CREATE relevantes, vamos discutir os conceitos de esquema e catálogo na Seção 6.1.1 para contextualizar nossa discussão. A Seção 6.1.2 descreve como as tabelas são criadas, e a Seção 6.1.3, os tipos de dados mais importantes disponíveis para especificação de atributo. Como a especificação SQL é muito grande, oferecemos uma descrição dos recursos mais importantes. Outros detalhes poderão ser encontrados em diversos documentos dos padrões SQL (ver bibliografia selecionada no final do capítulo).

6.1.1 Conceitos de esquema e catálogo em SQL As primeiras versões da SQL não incluíam o conceito de um esquema de banco de dados relacionai; todas as tabelas (relações) eram consideradas parte do mesmo esquema. O conceito de um esquema SQL foi incorporado inicialmente com a SQL2 a fim dc agrupar tabelas c outras construções que pertencem à mesma apli­ cação de banco de dados (em alguns sistemas, um esquema é chamado de banco de dados). Um esquema SQL é identificado por um nome de esquema, e inclui um identificador de autorização para indicar o usuário ou a conta proprietária do esquema, bem como descritores para cada elemento no esquema. Esses elementos incluem tabelas, tipos, restrições, views, domínios e outras construções (como concessões — grants — de autorização) que descrevem o esquema. Um esquema é criado por meio da instrução CREATE SCHEMA, que pode incluir todas as definições dos elementos do esquema. Como alternativa, o esquema pode receber um nome e identificador de autorização, e os elementos podem ser definidos mais tarde. Por exemplo, a instrução a seguir cria um esquema chamado EMPRESA, pertencente ao usuário com identificador dc autorização ‘Jsilva’. Observe que cada instrução em SQL termina com um ponto e vírgula.

CREATE SCHEMA EMPRESA AUTHORIZATION ‘Jsilva’;

Em geral, nem todos os usuários estão autorizados a criar esquemas e elementos do esquema. O privilégio para criar esquemas, tabelas e outras construções deve ser concedido explicitamente às contas de usuário relevantes pelo administrador do sistema ou DB/\.

161

162 Sistemas de banco de dados Além do conceito de um esquema, a SQL usa o conceito de um catálogo — uma coleção nomeada de esquemas.2 As instalações de banco de dados normalmente possuem um ambiente e um esquema padrão; logo, quando um usuário se conecta à instalação desse banco de dados, ele pode se referir direramenre às tabelas e a outras construções dentro desse esquema sem ter de indicar um nome de esquema em par­ ticular. Um catálogo sempre contém um esquema especial, chamado INFORMATION. SCHEMA, que provê informações sobre todos os esquemas no catálogo e todos os descritores de elemento nesses esquemas. As restrições de integridade, como a integridade referencial, podem ser definidas entre as relações somente se existirem nos esquemas dentro do mesmo catálogo. Os esquemas dentro do mesmo catálogo também podem compartilhar certos elementos, como definições de domínio.

6.1.2 0 comando CREATE TABLE em SQL O comando CREATE TABLE é usado para especificar uma nova relação, dando-Ihe um nome e especificando seus atributos e restrições iniciais. Os atributos são especificados primeiro, e cada um deles recebe um nome, um tipo de dado para especificar seu domínio de valores e quaisquer restrições de atributo, como NOT NULL. As restrições de chave, integridade de entidade e integridade referencial podem ser especificadas na instrução CREATE TABLE, depois que os atributos forem declarados, ou acrescentadas depois, usando o comando ALTER TABLE (ver Capítulo 7). A Figura 6.1 mostra exemplos de instruções de definição de dados em SQL para o esquema de banco de dados relacionai EMPRESA, mostrado na Figura 5.7.

CREATE TABLE FUNCIONÁRIO NOT NULL,

(Primeiro.nome

VARCHAR(15)

Nome.meio

CHAR,

Ultimo.nome

VARCHAR(15)

NOT NULL,

Cpf

CHAR(11),

NOT NULL,

Data.nascimento

DATE,

Endereço

VARCHAR(30),

Sexo

CHAR,

Salario

DECIMAL(10,2),

Cpf.supervisor

CHAR(11),

Numero.departamento

INT

NOT NULL,

(Nome.departa mento

VARCHAR(15)

NOT NULL,

Numero.departamento

INT

NOT NULL,

Cpf.gerente

CHAR(11),

NOT NULL,

Data.inicio.gerente

DATE,

PRIMARY KEY (Cpf));

CREATE TABLE DEPARTAMENTO

PRIMARY KEY (Numero.departamento),

UNIQUE (Nome.departamento), Figura 6.1 Instruções de definição de dados CREATE TABLE da SQL para definição do esquema EMPRESA da Figura 5.7. (continua) - A SQL também inclui o conceito de um grupo

(cluster} de catálogos.

Capitulo 6 SQL básica

FOREIGN KEY (Cpf.gerente) REFERENCES FUNCIONARIO(Cpf)); CREATE TABLE LOCALIZACOES.DEPARTAMENTO

(Numero-departamento

NOT NULL,

INT

Local

NOT NULL,

VARCHAR(15)

PRIMARY KEY (Numero.departamento. Local),

FOREIGN KEY (Numero_departamento) REFERENCES D E PARTAMENTO(N u mero_departa mento)); CREATE TABLE PROJETO

(Nome_projeto

VARCHARQ5)

NOT NULL,

Numero-projeto

INT

NOT NULL

LocaLprojeto

VARCHAR(IS),

Numero_departa mento

INT

NOT NULL

PRIMARY KEY (Numero.projeto),

UNIQUE (Nome_projeto), FOREIGN KEY (Numero.departamento) REFERENCES DEPARTAMENTO(Numero departamento));

CREATE TABLE TRABALHA.EM (Cpf.funcionario

CHAR(11)

NOT NULL

Numero-projeto

INT

NOT NULL

Horas

DECIMAL(3,1)

NOT NULL

PRIMARY KEY (Cpf.funcionario, Numero.projeto),

FOREIGN KEY (Cpf.funcionario) REFERENCES FUNCIONARIO(Cpf), FOREIGN KEY (Numero_projeto) REFERENCES PROJETO(Numero_projeto)); CREATE TABLE DEPENDENTE

(Cpf.funcionario

CHAR(11),

NOT NULL,

Nome.dependente

VARCHARQ5)

NOT NULL,

Sexo

CHAR,

Data.nascimento

DATE,

Parentesco

VARCHAR(8),

PRIMARY KEY (Cpf.funcionario, Nome.dependente), FOREIGN KEY (Cpf.funcionario) REFERENCES FUNCIONARIO(Cpf)); Figura 6.1 Instruções de definição de dados CREATE TABLE da SQL para definição do esquema EMPRESA da Figura 5.7. (continuação)

Em geral, o esquema SQL em que as relações sào declaradas é especificado implicitamente no ambiente em que as instruções CREATE TABLE são executadas. Como alternativa, podemos conectar explicitamente o nome do esquema ao nome da relação, separados por um ponto. Por exemplo, escrevendo CREATE TABLE EMPRESA.FUNCIONARIO

em vez de CREATE TABLE FUNCIONÁRIO como na Figura 6.1, podemos explicitamente (em vez de implicitamente) tornar a tabela FUNCIONÁRIO parte do esquema EMPRESA.

163

164 Sistemas de banco de dados As relações declaradas por meio das instruções CREATE TABLE sào chamadas de tabelas dc base (ou relações de base); isso significa que a relação e suas tuplas sào realmente criadas e armazenadas como um arquivo pelo SGBD. As relações de base são distintas das relações virtuais, criadas por meio da instrução CREATE VIEW (ver Capítulo 7), que podem ou não corresponder a um arquivo físico real. Em SQL, os atributos em uma tabela de base são considerados ordenados na sequência em que são especificados no comando CREATE TABLE. No entanto, as linhas (tuplas) não sào consideradas ordenadas dentro de uma tabela (relação). E importante observar que, na Figura 6.1, existem algumas chaves estrangeiras que podem causar erros, pois sào especificadas por referências circulares ou porque dizem respeito a uma tabela que ainda não foi criada. Por exemplo, a chave estran­ geira Cpf_supervisor na tabela FUNCIONÁRIO é uma referência circular, pois se refere à própria tabela. A chave estrangeira Numero_departamento na tabela FUNCIONÁRIO se refere à tabela DEPARTAMENTO, que ainda não foi criada. Para lidar com esse tipo de problema, essas restrições podem ser omitidas inicialmente do comando CREATE TABLE, e depois acrescentadas usando a instrução ALTER TABLE (ver Capítulo 7). Apresentamos todas as chaves estrangeiras na Figura 6.1, para mostrar o esquema EMPRESA completo em um só lugar.

6.1.3 Tipos de dados de atributo e domínios em SQL Os tipos de dados básicos disponíveis para atributos sào numérico, cadeia ou sequência de caracteres, cadeia ou sequência de bits, booleano, data e hora. ■ Os tipos de dados numéricos incluem números inteiros de vários tamanhos (INTEGER ou INT e SMALUNT) e números de ponto flutuante (reais) de várias precisões (FLOAT ou REAL e DOUBLE PRECISION). Os números formatados podem ser declarados usando DECIMAL^’,/’) — ou DEC(f, /) ou NUMERIC(z,/) — em que i, a precisão, é o número total de dígitos decimais e /, a escala, é o número de dígitos após o ponto decimal. O valor padrão para a escala é zero e, para a precisão, é definido pela implementação. ■ Tipos de dados de cadeia de caracteres (também chamados de string de caracte­ res) são dc tamanho fixo — CHAR(w) ou CHARACTERS), em que n é o número de caracteres — ou de tamanho variável — VARCHAR(n) ou CHAR VARYING(w) ou CHARACTER VARYING(m), em que n é o número máximo de caracteres. Ao especificar um valor literal de cadeia de caracteres, ele é colocado entre aspas simples (apóstrofos), e é case sensitive (diferencia maiúsculas dc minúsculas).3 Para cadeias de caracteres dc tamanho fixo, uma cadeia mais curta é preenchida com caracteres em branco à direita. Por exemplo, se o valor ‘Silva' for para um atributo do tipo CHAR(IO), ele é preenchido com cinco caracteres em branco para se tornar ‘Silva se necessário. Os espaços preenchidos geralmente são ignorados quando as cadeias são comparadas. Para fins de comparação, as cadeias de caracteres são consideradas ordenadas em ordem alfabética (ou lexicográfica); se uma cadeia strl aparecer antes de outra cadeia str2 em ordem alfabética, então strl é considerada menor que str2.4 Também há um operador de concarenaçào indicado por II (barra vertical dupla), que pode concarenar duas cadeias de caracteres em SQL. Por exemplo, ‘abc' II ‘XYZ' resulta em uma única cadeia ‘abcXYZ’. Outro tipo dc dado de cadeia dc caracteres dc

3 Isso não acontece com palavras-chave da SQL. como CREATE ou CHAR. Com as palavras-chave, a SQL é case insensitive, significando que ela trata letras maiúsculas c minúsculas como equivalentes nessas palavras. 4 Para caracteres não alfabéticos, existe uma ordem definida.

Capitulo 6 SQL básica tamanho variável, chamado CHARACTER LARGE OBJECT ou CLOB, também está disponível para especificar colunas que possuem grandes valores de texto, como documentos. O tamanho máximo de CLOB pode ser especificado em kilobytes (K), megabytes (M) ou gigabytes (G). Por exemplo, CLOB(20M) especifica um tamanho máximo de 20 megabytes.

■ Tipos de dados de sequência de bits podem ser de tamanho fixo n — BIT(„) — ou de tamanho variável — BIT VARYING(m), em que n é o número máximo de bits. O valor padrão para w, o tamanho de uma cadeia de caracteres ou sequência de bits, é 1. Os literais de sequência de bits são colocados entre apóstrofos, mas precedidos por um B para distingui-los das cadeias de caracteres; por exemplo, 10101 ’.5 Outro tipo de dados de sequência dc bits de tamanho variável, cha­ B * mado BINARY LARGE OBJECT ou BLOB, também está disponível para especificar colunas que possuem grandes valores binários, como imagens. Assim como para CLOB, o tamanho máximo dc um BLOB pode scr especificado cm kilobits (K), megabits (XI) ou gigabits (G). Por exemplo, BLOB(30G) especifica um tamanho máximo de 30 gigabits. ■ Um tipo de dado boolcano tem os valores tradicionais TRUE (verdadeiro) ou FALSE (falso). Em SQL, cm razão da presença de valores NULL (nulos), uma lógica dc três valores é utilizada, de modo que um terceiro valor possível para um tipo de dado booleano é UNKNOWN (indefinido). Discutiremos a necessidade de UNKNOWN e a lógica de três valores no Capítulo 7. ■ O tipo de dados DATE possui dez posições, e seus componentes são DAY (dia), MONTH (mês) e YEAR (ano), na forma DD-MM-YYYY. O tipo de dado TIME (tempo) tem pelo menos oito posições, com os componentes HOUR (hora), MINUTE (minuto) e SECOND (segundo) na forma HH:MM:SS. Somente datas e horas válidas devem ser permitidas pela implementação SQL. Isso implica que os meses devem estar entre 1 e 12 e os dias devem estar entre 1 e 31; além disso, um dia deve ser uma dara válida para o mês correspondente. A comparação < (menor que) pode ser usada com datas ou horas — uma data anterior é conside­ rada menor que uma dara posterior, c da mesma forma com a hora. Os valores literais são representados por cadeias com apóstrofos precedidos pela palavra-chave DATE ou TIME; por exemplo, DATE ‘27-09-2018’ ou TIME ‘09:12:47’. Além disso, um ripo de dado TIME(r), em que / é chamado de precisão em segundos fracionários de tempo., especifica / + 1 posições adicionais para TIME — uma posição para um caractcrc separador de período adicional (.), e i posições para especificar as frações de um segundo. Um tipo dc dados TIME WITH TIME ZONE inclui seis posições adicionais para especificar o deslocamento com base no fuso horário universal padrão, que está na faixa de +13:00 a -12:59 em unidades de HOURS:MINUTES. Se WITH TIME ZONE não for incluído, o valor padrão é o fuso horário local para a sessão SQL.

Alguns tipos de dados adicionais são discutidos a seguiu A lista apresentada aqui não está completa; diferentes implementações acrescentaram mais tipos de dados à SQL. ■ Um tipo de dado timestamp (TIMESTAMP) inclui os campos DATE e TIME, mais um mínimo de seis posições para frações decimais de segundos e um qualificador opcional WITH TIME ZONE. Valores literais são representados por cadeias entre apóstrofos precedidos pela palavra-chave TI ME STAMP, com um espaço em branco entre data e hora; por exemplo, TIMESTAMP ‘27-09-2018 09:12:47.648302’.

5 Sequências de hits cujo tamanho é um múltiplo de 4 podem ser especificadas em notação hexadeci­ mal, em que a cadeia literal é precedida por X e cada caractere hexadecimal representa 4 bits.

165

166 Sistemas de banco de dados ■ Outro ripo de dado relacionado a DATE, TIME e TIMESTAMP é o INTERVAL. Este especifica um intervalo — um valor relativo que pode ser usado para incrementar ou decrementar um valor absoluto de uma data, hora ou timestamp. Os intervalos sào qualificados para serem YEAR/MONTH ou DAY/TIME. O formato DATE, TIME e TIMESTAMP pode ser considerado um ripo especial de cadeia. Logo, eles geralmente podem ser usados em comparações de cadeias sendo convertidos (cast) em cadeias equivalentes. E possível especificar o tipo de dado de cada atributo diretamente, como na Figura 6.1; como alternativa, um domínio pode ser declarado e seu nome, usado com a especificação de atributo. Isso torna mais fácil mudar o tipo de dado para um domínio usado por diversos atributos em um esquema, e melhora a legibilidade do esquema. Por exemplo, podemos criar um domínio TIPO_CPF com a seguinte instrução:

CREATE DOMAIN TIPO_CPF AS CHAR(11);

Podemos usar TIPO_CPF no lugar de CHAR(11) na Figura 6.1 para os atributos Cpf e Cpf.su pervisor de FUNCIONÁRIO, Cpf.gerente de DEPARTAMENTO, Cpf.funcionario de TRABALHA.EM e Cpf.funcionario de DEPENDENTE. Um domínio também pode ter uma especificação padrão opcional por meio de uma cláusula DEFAULT, conforme discutiremos mais adiante para os atributos. Observe que os domínios podem não estar disponíveis em algumas implementações da SQL. Em SQL, também há um comando CREATE TYPE, que pode ser usado para criar tipos definidos pelo usuário, ou UDTs (User Defined Types). Estes podem ser usados tanto como tipos dc dados para atributos quanto como a base para a criação de tabelas. Explicaremos esse comando em detalhes no Capítulo 12, pois nonnalmentc é usado em conjunto com a especificação dos recursos de banco de dados que foram incorporados em versões mais recentes da SQL.

6.2 Especificando restrições em SQL Esta seção descreve as restrições básicas que podem ser especificadas em SQL como parte da criação de tabela. Estas incluem restrições de chave e inte­ gridade referencial, restrições sobre domínios dc atributo e NULLs c restrições sobre tuplas individuais dentro dc uma relação, usando a cláusula CHECK. Discutiremos a especificação de restrições mais gerais, chamadas asserções (ou assertions), no Capítulo 7.

6.2.1 Especificando restrições de atributo e defaults de atributo Como a SQL permite NULLs como valores dc atributo, uma restrição NOT NULL pode ser especificada se o valor NULL não for permitido para determinado atributo. Isso sempre é especificado de maneira implícita para os atributos que fazem parte da chave primária de cada relação, mas pode ser especificado para quaisquer outros atributos cujos valores não podem ser NULL, como mostra a Figura 6.1. Também é possível definir um valor default (ou padrão) para um atributo ane­ xando a cláusula DEFAULT a uma definição dc atributo. O valor default será incluído em qualquer nova tupla se um valor explícito não for fornecido para esse atributo. A Figura 6.2 ilustra um exemplo de especificação de um gerente default para um novo departamento e um departamento default para um novo funcionário. Se nenhuma cláusula default for especificada, o valor default será NULL para atributos que não possuem a restrição NOT NULL.

Capitulo 6 SQL básica CREATE TABLE FUNCIONÁRIO

(- - -. Numero.departamento INT

NOT NULL

DEFAULT 1,

CONSTRAINT CHAVEPRIMFUNCIONARIO PRIMARY KEY (Cpf),

CONSTRAINT CHAVEESTRFUNC.SUPERVISOR

FOREIGN KEY (Cpf.supervisor) REFERENCES FUNCIONARIO(Cpf) ON DELETE SET NULL

ON UPDATE CASCADE,

CONSTRAINT CHAVEESTRFUNC.DEPARTAMENTO

FOREIGN KEY(Numero.departamento) REFERENCES DE PARTAM ENTO(Numero.departamento) ON DELETE SET DEFAULT

ON UPDATE CASCADE);

CREATE TABLE DEPARTAMENTO

Cpf.gerente CHAR(11)

NOT NULL

DEFAULT ’88866555576',

CONSTRAINT CHAVEPRIMDEPARTAMENTO PRIMARY KEY(Numero.departamento),

CONSTRAINT CHAVEUNICADEPARTAMENTO UNIQUE (Nome_departamento),

CONSTRAINT CHAVEESTRDEPARTAMENTO.FUNC

FOREIGN KEY (Cpf.gerente) REFERENCES FUNCIONARIO(Cpf) ON DELETE SET DEFAULT

ON UPDATE CASCADE);

CREATE TABLE LOCALIZACOES.DEPARTAMENTO

PRIMARY KEY (Numero.departamento, Local), FOREIGN KEY (Numero.departamento) REFERENCES DEPARTAMENTO(Numero.departamento)

ON DELETE CASCADE

ON UPDATE CASCADE);

Figura 6.2 Exemplo ilustrando como especificar os valores de atributo default e as ações disparadas por integridade referencial em SQL.

Outro tipo de restrição pode limitar valores de atributo ou domínio usando a cláusula CHECK após uma definição de atributo ou domínio.6 Por exemplo, supo­ nha que números de departamento sejam restritos a números inteiros entre 1 e 20; então, podemos mudar a declaração de atributo de Numero_departamento na tabela DEPARTAMENTO (ver Figura 6.1) para o seguinte:

Numero.departamento INT NOT NULL CHECK (Numero.departamento > 0 AND Numero.departamento < 21); A cláusula CHECK também pode ser usada em conjunto com a instrução CREATE DOMAIN. Por exemplo, podemos escrever o seguinte comando:

CREATE DOMAIN D.NUM AS INTEGER

CHECK (D.NUM > 0 AND D.NUM < 21); A cláusula CHECK também pode ser usada para outras finalidades, conforme veremos.

167

168 Sistemas de banco de dados Depois, podemos usar o domínio criado D_NUM como o tipo de atributo para todos os atributos que se referem aos números de departamento na Figura 6.1, como Numero.departamento de DEPARTAMENTO, Numero.departamento de PROJETO, Numero.departamento de FUNCIONÁRIO, e assim por diante.

6.2.2 Especificando restrições de chave e integridade referencial Como restrições de chaves e de integridade referencial sào muito importantes, existem cláusulas especiais dentro da instrução CREATE TABLE para especificá-las. Alguns exemplos para ilustrar a especificação dc chaves e integridade referencial aparecem na Figura 6.1.' A cláusula PRIMARY KEY especifica um ou mais atributos que compõem a chave primária de uma relação. Se uma chave primária tiver um único atributo, a cláusula pode acompanhar o atributo diretamente. Por exemplo, a chave primária dc DEPARTAMENTO pode scr especificada da seguinte forma (cm vez do modo como é especificada na Figura 6.1): Numero.departamento INT PRIMARY KEY,

A cláusula UNIQUE especifica chaves alternativas (secundárias), também conhe­ cidas como chaves candidatas, conforme ilustramos nas declarações das tabelas DEPARTAMENTO e PROJETO na Figura 6.1. A cláusula UNIQUE também pode ser especificada diretamente para uma chave secundária se esta for um único atributo, como no exemplo a seguir:

Nome.departamento VARCHAR(15) UNIQUE, A integridade referencial é especificada por meio da cláusula FOREIGN KEY (chave estrangeira), como mostra a Figura 6.1. Conforme discutimos na Seção 5.2.4, uma restrição de integridade referencial pode ser violada quando tuplas são inseridas ou excluídas, ou quando um valor de atributo de chave estrangeira ou chave primária é atualizado. A ação default que a SQL toma para uma violação de integridade é rejeitar a operação de atualização que causará uma violação, o que é conhecido como opção RESTRICT. Porém, o projetista do esquema pode especificar uma ação alternativa para ser tomada conectando uma cláusula de ação de disparo referencial a qualquer restrição de chave estrangeira. As opções incluem SET NULL, CASCADE e SET DEFAULT. Uma opção deve scr qualificada com ON DELETE ou ON UPDATE. Ilustramos isso com os exemplos mostrados na Figura 6.2. Aqui, o projetista escolhe ON DELETE SET NULL e ON UPDATE CASCADE para a chave estrangeira Cpf.su pervisor de FUNCIONÁRIO. Isso significa que, se a tupla para um funcionário supervisor for excluída, o valor de Cpf.supervisor será automaticamente definido como NULL para todas as tuplas de funcionários que estavam referenciando a tupla do funcionário excluído. Por sua vez, se o valor dc Cpf para um funcionário supervisor for atualizado (digamos, porque foi inserido incorretamente), o novo valor será propagado eni cascata de Cpf.supervisor para todas as tuplas de funcionário que referenciam a tupla de funcionário atualizada.78 Em geral, a ação tomada pelo SGBD para SET NULL ou SET DEFAULT é a mesma para ON DELETE e ON UPDATE: o valor dos atributos de referência afetados é mudado para NULL cm caso dc SET NULL e para o valor padrão especificado do atributo dc referência cm caso dc SET DEFAULT. A ação para CASCADE ON DELETE é excluir todas as tuplas de referência, enquanto a ação para CASCADE ON UPDATE é mudar o valor do(s) atributo(s) da chave estrangeira de referência para o (novo) valor de chave pri­ mária atualizado para todas as tuplas dc referência. É responsabilidade do projetista 7 As restrições de chave e integridade referencial não estavam incluídas nas primeiras versões da SQL. 8 Observe que a chave estrangeira Cpf.supervisor na tabela FUNCIONÁRIO c uma referencia circular c, portanto, pode ter de ser incluída mais tarde como uma restrição nomeada, usando a instrução ALTER TABLE, conforme discutimos no final da Seção 6.1.2.

Capitulo 6 SQL básica

escolher a ação apropriada e especificá-la no esquema do banco de dados. Em geral, a opção CASCADE é adequada para relações de “relacionamento” (ver Seção 9.1), como TRABALHA_EM; para relações que representam atributos multivalorados, como LOCALIZACOES_DEPARTAMENTO; e para relações que representam tipos de entidades fracas, como DEPENDENTE.

6.2.3 Dando nomes a restrições A Figura 6.2 também ilustra como uma restrição pode receber um nome dc restrição, seguindo a palavra-chave CONSTRAINT. Os nomes dc todas as restrições dentro de um esquema em particular precisam ser exclusivos. Um nome de restrição é usado para identificar uma restrição em particular caso ela deva ser removida mais tarde e substituída por outra, conforme discutiremos no Capítulo 7. Dar nomes a restrições é algo opcional. Também é possível adiar temporariamente uma restrição até o final de uma transação, conforme veremos no Capítulo 20, quando apresen­ tarmos os conceitos de transação.

6.2.4 Especificando restrições sobre tuplas usando CHECK Além das restrições de chave e integridade referencial, especificadas por pala­ vras-chave especiais, outras restrições de tabela podem ser especificadas por meio de cláusula adicional CHECK ao final de uma instrução CREATE TABLE. Estas podem ser chamadas de restrições baseadas em tupla, pois se aplicam a cada tupla indivi­ dualmente e são verificadas sempre que uma tupla é inserida ou modificada. Por exemplo, suponha que a tabela DEPARTAMENTO da Figura 6.1 tivesse um atributo adicional Data_criacao, que armazena a data em que o departamento foi criado. Então, poderiamos acrescentar a seguinte cláusula CHECK ao final da instrução CREATE TABLE para a tabela DEPARTAMENTO para garantir que a data de início de um gerente seja posterior à data de criação do departamento. CHECK (Data_criacao dista tabelas> ;

em que

■ clista atributos> é uma lista de nomes dc atributo cujos valores devem ser recu­ perados pela consulta. ■ dista tabelas> é uma lista dos nomes de relação exigidos para processar a consulta. ■ é uma expressão condicional (booleana) que identifica as tuplas a serem recuperadas pela consulta.

Em SQL, os operadores básicos de comparação lógicos para comparar valores de atributo entre si e com constantes literais são =, = e o. Estes correspondem aos operadores da álgebra relacionai =, e * , respectiva men te, e aos opera­ dores da linguagem de programação C/C++ =, = e !=. A principal diferença sintática é o operador diferente (ou não igual). A SQL possui outros operadores de comparação, que apresentaremos aos poucos. Ilustramos a instrução SELECT básica em SQL com alguns exemplos de consultas. As consultas são rotuladas aqui com os mesmos números de consulta usados no Capítulo 8 para facilitar a referência cruzada. Consulta 0. Recuperar a data de nascimento e o endereço do(s) funcionário(s) cujo nome seja ‘João B. Silva’.

CO: SELECT Data_nasdmento, Endereço FROM FUNCIONÁRIO WHERE Primeiro_nome='João’ AND Nome_meio='B' AND Uhimo_nome=‘Silva'; Esta consulta envolve apenas a relação FUNCIONÁRIO listada na cláusula FROM. A consulta seleciona as tuplas individuais de FUNCIONÁRIO que satisfazem a condi­ ção da cláusula WHERE, depois projeta o resultado nos atributos Data_nascimento e Endereço listados na cláusula SELECT. A cláusula SELECT da SQL especifica os atributos cujos valores devem ser recu­ perados, chamados atributos dc projeção na álgebra relacionai (ver Capítulo 8), e a cláusula WHERE especifica a condição booleana que deve ser verdadeira para qualquer tupla recuperada, que é conhecida como condição de seleção na álgebra relacionai. A Figura 6.3(a) mostra o resultado da consulta CO sobre o banco de dados da Figura 5.6.

9 As cláusulas SELECT e FROM sào necessárias em todas as consultas SQL O WHERE é opcional (ver Seção 6.3.3).

Capitulo 6 SQL básica (b)

» Data nascimento

Primeiro nome

Endereço Rua das Flores, 751, São Paulo, SP

09-01-1965

Ultimo nome

Endereço

João

Silva

Rua das Flores, 751, São Paulo, SP

Fernando

Wong

Rua da Lapa, 34, São Paulo, SP

Ronaldo

Uma

Rua Rebouças, 65, Piracicaba, SP

Joice

Leite

Av. Lucas Obes, 74, São Paulo, SP

if)

:c) Numero_projeto

171

DEPARTAMENTO. Numero_departamento

Cpf Ultimo nome

Endereço

Nome departamento

Data nascimento

12345678966

Pesquisa

33344555587

ft?squisa

99988777767

Pesquisa

98765432168

Pesquisa

66688444476

Pesquisa

45345345376

Pesquisa

98798798733

Pesquisa

88866555576

Pesquisa

12345678966

Administração

33344555587

Administração

99988777767

Administração

98765432168

Administração

66688444476

Administração

45345345376

Administração

98798798733

Administração

88866555576

Administração

12345678966

Matriz

33344555587

Matriz

99988777767

99988777767

Matriz

98765432168

98765432168

Matriz

66688444476

66688444476

Matriz

45345345376

45345345376

Matriz

98798798733

98798798733

Matriz

88866555576

Matriz

10 30

Souza

4

4

Souza

Av. Artur de Uma,

54, Santo André, SP Av. Artur de Uma, 54, Santo André, SP

20-06-1941 20-06-1941

(d) F.Primeiro nome

F.UItimo nome

S.Primeiro nome

S.UItimo nome

João

Silva

Fernando

Wong

Fernando

Wong

Jorge

Brito

Alice

Zelaya

Jennifer

Souza

Jennifer

Souza

Jorge

Brito

Ronaldo

Uma

Fernando

Wong

Joice

Leite

Fernando

Wong

André

Pereira

Jennifer

Souza

12345678966

33344555587

88866555576

Figura 6.3 Resultados das consultas SQL quando aplicadas ao estado do banco de dados EMPRESA mostrado na Figura 5.6. (a) CO. (b) C1. (c) C2. (d) C8. (e) C9. (f) CIO. (g) C1C. {continua)

172 Sistemas de banco de dados (g)

Primeiro nome

Data nascimento

Nome.meio

Ultimo.nome

João

B

Silva

12345678966

09-01-1965

Fernando

T

Wocg

33344555587

08-12-1955

Ronaldo

K

Lima

66688444476

15-09-1962

Joice

A

Leite

45345345376

31-07-1972

Figura 6.3 Resultados das consultas SQL quando aplicadas ao estado do banco de dados EMPRESA mostrado na Figura 5.6. (a) CO. (b) Cl. (c) C2. (d) C8. (e) C9. (f)C1O. (g)C1C. (continuação)

Cpf

Sexo

Endereço Rua das Flores, 751, São Paulo, SP

M

Rua da Lapa, 34, São M Paulo, SP Rua Rebouças, 65, M Piracicaba, SP

Av. Lucas Obes, 74, São F Paulo, SP

Numero departamento

Salario

Cpf_supervisor

30000

33344555587

5

40000

88866555576

5

38000

33344555587

5

25000

33344555587

5

Podemos pensar em uma variável de tupla implícita (ou iterator} na consulta SQL variando ou repetindo sobre cada tupla individual na tabela FUNCIONÁRIO e avaliando a condição na cláusula WHERE. Somente as tuplas que satisfazem a condi­ ção — ou seja, aquelas tuplas para as quais a condição é avaliada como TRUE após substituir seus valores de atributo correspondentes — são selecionadas. Consulta 1. Recuperar o nome e o endereço dc todos os funcionários que traba­ lham para o departamento‘Pesquisa’. Cl: SELECT Primeiro_nome, Ultimo_nome, Endereço

FROM

FUNCIONÁRIO, DEPARTAMENTO

WHERE Nome_departamento ='Pesquisa' AND DEPARTAMENTO.Numero_ departamento = FUNCIONARIO.Numero_departamento; Na cláusula WHERE de C1, a condição Nome_departamento = ‘Pesquisa’ é uma condição de seleção que escolhe a tupla de interesse em particular na tabela DEPARTAMENTO, pois Nome_departamento é um atributo de DEPARTAMENTO. A condição FUNCIONARIO.Numero_departamento = DE PARTAM ENTO. Nume ro_departamento é chamada condição de junção (ou join), pois combina duas tuplas: uma de DEPARTAMENTO e uma de FUNCIONÁRIO, sempre que o valor de Numero, departamento em DEPARTAMENTO é igual ao valor de Numero.departamento em FUNCIONÁRIO. O resultado da consulta C1 é mostrado na Figura 6.3(b). Em geral, qualquer número de condições de seleção e junção pode ser especificado em uma única consulta SQL. Uma consulta que envolve apenas condições de seleção e junção mais atributos de projeção é conhecida como uma consulta seleção-projeção-junção. O próximo exemplo é uma consulta seleção-projeçâo-junção com duas condições de junção.

Consulta 2. Para cada projeto localizado em ‘Mauá’, liste o número do projeto, o número do departamento que o controla e sobrenome, endereço e data de nasci­ mento do gerente do departamento. C2: SELECT Numero_projeto, DEPARTAMENTO.Numero_departamento, Ultimo, nome. Endereço, Data.nascimento

FROM

PROJETO, DEPARTAMENTO, FUNCIONÁRIO

WHERE PROJETO.Numero.departamento = DEPARTAMENTO.Numero.depar­ tamento AND Cpf.gerente = Cpf AND Local.projeto = 'Mauá';

Capitulo 6 SQL básica

A condição de junção PROJETO.Numero_departamento = DEPARTAMENTO.Numero. departamento relaciona uma tupla de projeto à sua tupla de departamento que o controla, enquanto a condição de junção Cpf.gerente = Cpf relaciona a tupla do departamento que o controla à tupla de funcionário que gerencia esse departamento. Cada tupla no resultado será uma combhiaçào de um projeto, um departamento (que controla o projeto) e um funcionário (que gerencia o departamento). Os atributos de projeção são usados para escolher os atributos a serem exibidos com base em cada tupla combinada. O resultado da consulta C2 aparece na Figura 6.3(c).

6.3.2 Nomes de atributos ambíguos, apelido, renomeação e variáveis

de tupla Em SQL, o mesmo nome pode ser usado para dois (ou mais) atributos, desde que estes estejam em relações diferentes. Se isso acontecer, e uma consulta em múltiplas relações se referir a dois ou mais atributos com o mesmo nome, é preciso qualificar o nome do atributo com o nome da relação para evitar ambiguidade. Isso é feito prefixando o nome da relação ao nome do atributo e separando os dois por um ponto. Para ilustrar isso, suponha que, nas figuras 5.5 e 5.6, o atri­ buto Ultimo_nome da relação FUNCIONÁRIO fosse chamado de Nome, e o atributo Nome.departamento de DEPARTAMENTO também fosse chamado Nome. Então, para evitar ambiguidade, a consulta C1 seria reformulada como mostramos em C1A. Devemos prefixar os nomes dc atributo Nome e Numero.departamento em C1A para especificar a quais estamos nos referindo, pois os mesmos nomes de atributo são usados nas duas relações: C1 A:SELECT Primeiro_nome, FUNCIONARIO.Nome, Endereço FROM

FUNCIONÁRIO, DEPARTAMENTO

WHERE DEPARTAMENTO.Nome = 'Pesquisa' AND DEPARTAMENTO. Numero.departamento = FUNCIONÁRIO.Numero.departamento;

Nomes de atributo totalmente qualificados podem ser usados por clareza mesmo que não haja ambiguidade nos nomes de atributo. C1 aparece dessa maneira como C1 ’ a seguir. Também podemos renomear os nomes de relação para nomes mais curtos, criando um apelido para cada nome de relação, para evitar a digitação repetida de nomes de relação longos (ver C8, a seguir).

Cl': SELECT FUNCIONARIO.Primeiro.nome, FUNCIONÁRIO.Ultimo.nome, FUNCIONÁRIO.Endereço

FROM

FUNCIONÁRIO, DEPARTAMENTO

WHERE DEPARTAMENTO.Nome.departamento = 'Pesquisa' AND DEPARTAMENTO. Numero.departamento = FUNCIONÁRIO.Numero.departamento;

A ambiguidade dos nomes de atributo também surge no caso de consultas que se referem à mesma relação duas vezes, como no exemplo a seguir. Consulta 8. Para cada funcionário, recupere o primeiro e o último nome do fun­ cionário e o primeiro e o último nome de seu supervisor imediato.

C8: SELECT F.Primeiro.nome, F.Ultimo.nome, S.Primeiro.nome, S.UItimo.nome

FROM

FUNCIONÁRIO AS F, FUNCIONÁRIO AS S

WHERE F.Cpf_supervisor=S.Cpf;

173

174 Sistemas de banco de dados Neste caso, precisamos declarar nomes de relação alternativos F e S, chamados apelidos ou variáveis de tupla, para a relação FUNCIONÁRIO. Um apelido pode vir após a palavra-chave AS, como mostramos em C8, ou diretamente após o nome da relação — por exemplo, escrevendo FUNCIONÁRIO F, FUNCIONÁRIO S na cláusula FROM de C8. Também é possível renomear os atributos da relação dentro da consulta em SQL, dando-lhe apelidos. Por exemplo, se escrevermos

FUNCIONÁRIO AS F(Pn, Nm, Un, Cpf, Dn, End, Sexo, Sal, Cpfs, Nd)

na cláusula FROM, Pn torna-se um apelido para Primeiro_nome, Nm para Nome_meio, Un para Ultimo_nome, e assim por diante. Em C8, podemos pensar em F e S como duas cópias diferentes da relação FUNCIONÁRIO; a primeira, F, representa funcionários no papel de supervisionados ou subordinados; a segunda, S, representa os funcionários no papel de supervisores. Agora, podemos juntar as duas cópias. Naturalmente, na realidade existe apenas unia relação FUNCIONÁRIO, e a condição de junção serve para juntar a própria relação, combinando as tuplas que satisfazem a condição de junção F.Cpf_supervisor = S.Cpf. Observe que este é um exemplo de uma consulta recursiva de um nível, conforme discutiremos na Seção 8.4.2. Nas versões anteriores da SQL, não era possível espe­ cificar uma consulta recursiva geral, com um número desconhecido de níveis, em uma única instrução SQL. Uma construção para especificar consultas recursivas foi incorporada na SQL: 1999 (ver Capítulo 7). O resultado da consulta C8 aparece na Figura 6.3(d). Sempre que um ou mais apelidos são dados a uma relação, podemos usar esses nomes para representar dife­ rentes referencias a essa mesma relação. Isso permite múltiplas referencias à mesma relação dentro de uma consulta. Podemos usar esse mecanismo dc nomeação de apelidos cm qualquer consulta SQL para especificar variáveis dc tupla para cada tabela na cláusula WHERE, não importando se a mesma relação precisa ser referenciada mais de uma vez. De fato, essa prática c recomendada, pois resulta cm consultas mais fáceis de compreender. Por exemplo, poderiamos especificar a consulta C1 como em C1B: C1B: SELECT F.Primeiro_nome, EUItimo_nome, F.Endereco FROM

FUNCIONÁRIO AS F, DEPARTAMENTO AS D

WHERE D.Nome_departamento = 'Pesquisa' AND

D. N umero-departamento=F. Numero_departamento;

6.3.3 Cláusula WHERE não especificada e uso do asterisco Vamos discutir aqui mais dois recursos da SQL. A falta dc uma cláusula WHERE indica que não há condição sobre a seleção de tuplas; logo, todas as tuplas da relação especificada na cláusula FROM se qualificam e são selecionadas para o resultado da consulta. Se mais de uma relação for especificada na cláusula FROM e não houver uma cláusula WHERE, então o PRODUTO CARTESIANO — todas as combinações de tuplas possíveis — dessas relações será selecionado. Por exemplo, a Consulta 9 seleciona todos os Cpfs de FUNCIONÁRIO [Figura 6.3(e)! e a Consulta 10 seleciona todas as combinações de um Cpf de FUNCIONÁRIO e um Nome_departamento de DEPARTAMENTO, independentemente de o funcionário trabalhar ou não para o departamento [Figura 6.3(f)]. Consultas 9 e 10. Selecionar todos os Cpfs de FUNCIONÁRIO (C9) e todas as com­ binações de Cpf de FUNCIONÁRIO e Nome_departamento de DEPARTAMENTO (C10) no banco de dados.

Capitulo 6 SQL básica C9: SELECT Cpf

FROM

FUNCIONÁRIO;

C10: SELECT Cpf, Nome_departamento

FROM

FUNCIONÁRIO, DEPARTAMENTO;

E extremamente importante especificar cada condição de seleção e junção na cláusula WHERE. Se alguma condição desse tipo for esquecida, o resultado poderá ser relações incorretas e muito grandes. Observe que C10 é semelhante a uma ope­ ração de PRODUTO CARTESIANO seguida por uma operação PROJEÇÃO na álgebra relacionai (ver Capítulo 8). Se especificarmos todos os atributos de FUNCIONÁRIO e DEPARTAMENTO em C10, obteremos o PRODUTO CARTESIANO real (exceto pela eliminação de duplicatas, se houver). Para recuperar todos os valores dc atributo das tuplas selecionadas, não pre­ cisamos listar os nomes de atributo explicitamente cm SQL; basta especificar um asterisco (* ), que significa todos os atributos. O * também pode ser iniciado pelo nome da relação ou apelido; por exemplo, FUNCIONÁRIO. * refere-se a todos os atributos da tabela FUNCIONÁRIO. A consulta C1C recupera todos os valores dc atributo de qualquer FUNCIONÁRIO que trabalha no DEPARTAMENTO número 5 (Figura 6.3(g)], a consulta Cl D recupera todos os atributos de um FUNCIONÁRIO e os atributos do DEPARTAMENTO em que ele ou ela trabalha para todo funcionário no departamento ‘Pesquisa’, e C10A especifica o PRODUTO CARTESIANO das relações FUNCIONÁRIO e DEPARTAMENTO. C1C: SELECT *

FROM

FUNCIONÁRIO

WHERE Numero_departamento = 5; C1D:SELECT *

FROM

FUNCIONÁRIO, DEPARTAMENTO

WHERE Nome_departamento = 'Pesquisa AND DEPARTAMENTO.Numero. departamento = FUNCIONARIO.Numero_departamento;

* C10A:SELECT FROM

FUNCIONÁRIO, DEPARTAMENTO;

6.3.4 Tabelas como conjuntos em SQL Conforme já dissemos, a SQL normalmcntc trata uma tabela não como um conjunto, mas como um multiconjunto; tuplas duplicadas podem aparecer mais de uma vez em uma tabela e no resultado de uma consulta.SQL não elimina automa­ ticamente tuplas duplicadas nos resultados das consultas, pelos seguintes motivos:

■ A eliminação dc duplicatas c uma operação dispendiosa. Um modo dc implcmcntá-la c classificar as tuplas primeiro c depois eliminar as duplicatas. ■ O usuário pode querer ver as tuplas duplicadas no resultado de uma consulta. ■ Quando uma função agregada (ver Seção 7.1.7) é aplicada às tuplas, na maioria dos casos não queremos eliminar duplicatas. Uma tabela SQL com uma chave é restrita a ser um conjunto, uma vez que o valor de chave precisa ser distinto em cada tupla.10 Se quisermos eliminar tuplas duplicadas do resultado de uma consulta SQL, usamos a palavra-chave DISTINCT 10 Em geral, uma tabela SQL não precisa ter uma chave, embora, na maioria dos casos, exista uma.

175

176 Sistemas de banco de dados na cláusula SELECT, significando que apenas as tuplas distintas deverão permanecer no resultado. Em geral, uma consulta com SELECT DISTINCT elimina duplicatas, enquanto uma consulta com SELECT ALL não elimina. A especificação de SELECT sem ALL ou DISTINCT — como em nossos exemplos anteriores — é equivalente a SELECT ALL. Por exemplo, a C11 recupera o salário de cada funcionário; se vários funcionários tiverem o mesmo salário, esse valor de salário aparecerá muitas vezes no resultado da consulta, como mostra a Figura 6.4(a). Se estivermos interessados apenas cm valores dc salário distintos, queremos que cada valor apareça apenas uma vez, independentemente de quantos funcionários ganham esse salário. Usando a palavra-chave DISTINCT, como em C11 A, conseguimos isso, como mostra a Figura 6.4(b). Consulta 11. Recuperar o salário de cada funcionário (C11) e todos os valores dc salário distintos (Cl 1A). C11:

C11A:

SELECT

ALL Salario

FROM

FUNCIONÁRIO;

SELECT

DISTINCT Salario

FROM

FUNCIONÁRIO;

A SQL incorporou diretamente algumas das operações de conjunto da teoria de conjuntos da matemática, que também fazem parte da álgebra relacionai (ver Capítulo 8). Existem operações de união de conjunto (UNION), diferença de con­ junto (EXCEPT)” c interseção de conjunto (INTERSECT). As relações resultantes dessas operações de conjunto são conjuntos dc tuplas; ou seja, tuplas duplicadas são eliminadas do resultado. Essas operações de conjunto se aplicam apenas a relações compatíveis com o tipo, de modo que precisamos garantir que as duas relações em que aplicamos a operação tenham os mesmos atributos e que os atributos apareçam na mesma ordem nas duas relações. O próximo exemplo ilustra o uso de UNION. Ç) Primeiro_nome

Ultimo_nome

Primeiro_nome

Ultimo_nome

(d)

Fernando

Wong

Figura 6.4 Resultados de consultas SQL adicionais, quando aplicadas ao estado de banco de dados EMPRESA, mostrado na Figura 5.6. (a) C11. (b) C11 A. (c) C12. (d) C12A.

11 Fm alguns sistemas, a palavra chave MINUS é usada para a operação de diferença de conjunto, em vez de EXCEPT.

Capitulo 6 SQL básica Consulta 4. Fazer uma lista de todos os números de projeto para aqueles que envolvam um Funcionário cujo último nome é ‘Silva’, seja como um trabalhador, seja como um gerente do departamento que controla o projeto.

C4A:

: SELECT DISTINCT Numero_projeto

FROM

PROJETO, DEPARTAMENTO, FUNCIONÁRIO

WHERE

PROJETO.Numero.departamento = DEPARTAMENTO. Numero.departamento AND Cpf.gerente = Cpf

AND Ultimo_nome= 'Silva') UNION

( SELECT DISTINCT PROJETO.Numero.projeto FROM

PROJETO, TRABALHA.EM, FUNCIONÁRIO

WHERE

PROJETO.Numero_projeto = TRABALHA_EM.Numero_projeto AND Cpf.funcionario = Cpf AND Ultimo.nome = 'Silva');

A primeira consulta SELECT recupera os projetos que envolvem um ‘Silva’ como gerente do departamento que controla o projeto e a segunda recupera os projetos que envolvem um ‘Silva’ como um trabalhador no projeto. Observe que, se todos os funcionários tiverem o último nome ‘Silva’, os nomes dc projeto envolvendo qualquer um deles seriam recuperados. A aplicação da operação UNION às duas consultas SELECT gera o resultado desejado. A SQL também possui operações multiconjunto correspondentes, que são acom­ panhadas da palavra-chave ALL (UNION ALL, EXCEPT ALL, INTERSECT ALL). Scus resultados são multiconjuntos (duplicatas não são eliminadas). O comportamento dessas operações é ilustrado pelos exemplos da Figura 6.5. Basicamente, cada tupla — seja ela uma duplicata ou não — é considerada uma tupla diferente ao aplicar essas operações. (a)

T

T

R

S

A

A

A

A

a1

a1

al

a2

a2

a2

a1

a3

a2

a4

a2

a3

a5

a2

(b)

a2

(c)

(d)

T

a3

A

a4

al

a5

a2

Figura 6.5 Os resultados das operações multiconjunto da SQL. (a) Duas tabelas, R(A) e S(A). (b) R(A) UNION ALL S(A). (c) R(A) EXCEPT ALL S(A). (d) R(A) INTERSECT ALL S(A).

6.3.5 Combinação de padrão de subcadeias e operadores aritméticos Nesta seção, discutimos vários outros recursos da SQL. O primeiro recurso permite condições de comparação apenas sobre partes dc uma cadeia dc caracteres, usando o operador de comparação LIKE. Isso pode ser usado para combinação de padrão de cadeia de caracteres. Cadeias de caracteres parciais são especificadas com o uso de dois caracteres reservados: % substitui um número qualquer de zero

177

178 Sistemas de banco de dados ou mais caracteres, e o sublinhado (_) substitui um único caractere. Por exemplo, considere a consulta a seguir.

Consulta 12. Recuperar todos os funcionários cujo endereço esteja cm Belo Horizonte, X1G. C12:

SELECT

Primeiro_nome, Ultimo.nome

FROM

FUNCIONÁRIO

WHERE

Endereço LIKE '%Belo Horizonte,MG%';

Para recuperar todos os funcionários que nasceram durante a década de 1950, podemos usar a Consulta C12A. Aqui, ‘5’ precisa ser o nono caractere da cadeia (de acordo com nosso formato para data), de modo que usamos o valor ‘______ ______ 5 com cada sublinhado servindo como um marcador dc lugar para um caractere qualquer. Consulta 12A. Encontrar todos os funcionários que nasceram durante a década de 1950.

C12A:

SELECT

Primeiro.nome, Ultimo.nome

FROM

FUNCIONÁRIO

WHERE

Data nascimento LIKE

5 '

Se um sublinhado ou % for necessário como um caractere literal na cadeia, este deve ser precedido por um caractere de escape, que é especificado após a cadeia usando a palavra-chave ESCAPE. Por exemplo,‘AB\_CD\%F.F’ ESCAPE ‘V representa a cadeia literal 4AB_CD%EF’, pois \ é especificado como o caractere de escape. Qualquer caractere não usado na cadeia pode ser escolhido como caractere dc escape. Além disso, precisamos de uma regra para especificar apóstrofos ou aspas simples C ’) se eles tiverem de ser incluídos em uma cadeia, pois são usados para iniciar e terminar cadeias. Se um apóstrofo (’) for necessário, ele será representado como dois apóstrofos consecutivos (”), de modo que não será interpretado como o término da cadeia. Observe que a comparação de subcadeia implica que os valores de atributo não sejam valores atômicos (indivisíveis), conforme assumimos no modelo relacionai formal (ver Seção 5.1). Outro recurso permite o uso de aritmética nas consultas. Os operadores aritmé­ ticos padrão para adição (+), subtração (-), multiplicação (* ) e divisão (/) podem ser aplicados a valores ou atributos numéricos com domínios numéricos. Por exemplo, suponha que queiramos ver o efeito de dar a todos os funcionários que trabalham no projeto ‘ProdutoX’ um aumento de 10%; podemos fazer a Consulta 13 para ver quais seriam seus novos salários. Este exemplo também mostra como podemos renomear um atributo no resultado da consulta usando AS na cláusula SELECT. Consulta 13. Mostrar os salários resultantes se cada funcionário que trabalha no projeto ‘ProdutoX’ receber um aumento de 10%.

C13: SELECT F.Primeiro.nome, F.Ultimo.nome, 1.1 * F.Salario AS Aumento.salario FROM

FUNCIONÁRIO AS F, TRABALHA.EM AS T, PROJETO AS P

WHERE F.Cpf = TCpf.funcionario AND T.Numero.projeto = P.Numero.projeto AND PNome.projeto = 'ProdutoX';

Para os tipos de dados dc cadeia, o operador dc concatcnação II pode scr usado em uma consulta para anexar dois valores de cadeia. Para tipos de dados date, rime, timestamp e interval, os operadores incluem incremento (+) ou decrement© (-) de uma data, hora ou data c hora por um intervalo. Além disso, um valor dc intervalo é o resultado da diferença entre dois valores dc data, ou hora ou data c hora. Outro

Capitulo 6 SQL básica operador de comparação, que pode ser usado por conveniência, é BETWEEN, que está ilustrado na Consulta 14. Consulta 14. Recuperar todos os funcionários no departamento 5 cujo salário esteja entre RS30.000 e R$40.000. C14: SELECT *

FROM

FUNCIONÁRIO

WHERE (Salario BETWEEN 30000 AND 40000) AND Numero.departamento = 5;

A condição (Salario BETWEEN 30000 AND 40000) em C14 é equivalente à condição ((Salario >= 30000) AND (Salario dista tabelas> ] dista atributos>|;

A cláusula SELECT lista os atributos a serem recuperados, e a cláusula FROM especifica todas as relações (tabelas) necessárias na consulta simples. /\ cláusula WHERE identifica as condições para selecionar as tuplas dessas relações, incluindo condições de junção, se necessário. ORDER BY especifica uma ordem para exibir os

179

180 Sistemas de banco de dados resultados de uma consulta. Duas cláusulas adicionais, GROUP BY e HAVING, serão descritas na Seção 7.1.8. No Capítulo 7, apresentaremos recursos mais complexos das consultas SQL. Estes incluem os seguintes: consultas aninhadas, que permitem que uma consulta seja incluída como parte de outra consulta; funções de agregação, que são usadas para fornecer resumos da informação nas tabelas; duas cláusulas adicionais (GROUP BY e HAVING), que podem ser usadas para fornecer mais poder para as funções agregadas; e vários tipos de junções (joins), que podem combinar registros de várias tabelas de diferentes maneiras.

6.4 Instruções INSERT, DELETE e UPDATE em SQL Em SQL, três comandos podem scr usados para modificar o banco de dados: INSERT, DELETE e UPDATE. Discutiremos cada um deles, um por vez.

6.4.1 0 comando INSERT Em sua forma mais simples, INSERT é usado para acrescentar uma única tupla (linha) a uma relação (tabela). Temos dc especificar o nome da relação c uma lista dc valores para a tupla. Os valores devem ser listados na mesma ordem em que os atributos correspondentes foram especificados no comando CREATE TABLE. Por exemplo, para acrescentar uma nova tupla à relação FUNCIONÁRIO mostrada na Figura 5.5 e especificada no comando CREATE TABLE FUNCIONÁRIO... da Figura 6.1, podemos usar U1:

U1: INSERT INTO VALUES

FUNCIONÁRIO (‘Ricardo’, ‘K’, ‘Marini’, ‘65329865388’, ‘30-12-1962’, ‘Rua Itapira, 44, Santos, SP’, M’, 37000, ‘65329865388’, 4 );

Uma segunda forma da instrução INSERT permite que o usuário especifique nomes dc atributo explícitos que correspondem aos valores fornecidos no comando INSERT. Isso é útil se uma relação tiver muitos atributos, mas apenas alguns deles recebem valores cm uma nova tupla. Porém, os valores precisam incluir todos os atributos com a especificação NOT NULL e nenhum valor padrão. Os atributos com NULL permitido ou com valores DEFAULT são aqueles que podem ser omitidos. Por exemplo, para inserir uma tupla para um novo FUNCIONÁRIO do qual conhecemos apenas os atri­ butos Primeiro.nome, Ultimo_nome, Numero_departamento e Cpf, podemos usar U1 A:

U1A:

INSERT INTO

FUNCIONÁRIO (Primeiro_nome, Ultimo_nome, Numero, departamento, Cpf)

VALUES

(‘Ricardo’,‘Marini’, 4,‘65329865388’);

Os atributos não especificados em U1A são definidos como seu valor DEFAULT ou NULL, e os valores são listados na mesma ordem que os atributos sào listados no próprio comando INSERT. Também é possível inserir cm uma relação múltiplas tuplas separadas por vírgulas em um único comando INSERT. Os valores de atributo que formam cada tupla ficam entre parênteses. Um SGBD que implementa totalmente a SQL deve aceitar e impor todas as restri­ ções de integridade que podem ser especificadas na DDL. Por exemplo, se emitirmos o comando em U2 sobre o banco de dados mostrado na Figura 5.6, o SGBD deve rejeitar a operação, pois não existe uma tupla DEPARTAMENTO no banco de dados com Numero.departamento = 2. De modo semelhante, U2A seria rejeitada porque nenhum valor de Cpf é fornecido e essa é a chave primária, que não pode ser NULL.

Capitulo 6 SQL básica

INSERT INTO FUNCIONÁRIO (Primeiro.nome, Ultimo.nome, Cpf, Numero.departamento) VALUES (‘Roberto’,‘Gomes’,‘98076054011’, 2); (U2 é rejeitado se a verificação da integridade referencial for oferecida pelo SGBD.) U2:

U2A: INSERT INTO FUNCIONÁRIO (Primeiro.nome, Ultimo.nome, Numero.departamento) VALUES (‘Roberto’, ‘Gomes’, 5); (U2A é rejeitado se a verificação de NOT NULL for oferecida pelo SGBD.) Uma variação do comando INSERT inclui várias tuplas cm uma relação em con­ junto com a criação da relação e sua carga com o resultado de uma consulta. Por exemplo, para criar uma tabela temporária que possui o último nome do funcionário, o nome do projeto e as horas por semana para cada funcionário que trabalha cm um projeto, podemos escrever as instruções cm U3A e U3B: U3A:

CREATE TABLE (Nome.fundonario Nome_projeto Horas.semanal

INFORMACOES.TRABALHA.EM VARCHAR(15), VARCHAR(15), DECIMALS, 1));

U3B:

INSERT INTO

INFORMACOES.TRABALHA.EM (Nome.fundonario, Nome_projeto, Horas.por.semana) F.Ultimo.nome, PNome.projeto, T.Horas PROJETO P, TRABALHA.EM T, FUNCIONÁRIO F P.Numero.projeto = T.Numero.projeto AND T.Cpf. fundonario = F.Cpf;

SELECT FROM WHERE

Uma tabela INFORMACOES.TRABALHA.EM é criada por U3A e carregada com a informação da junção recuperada do banco de dados pela consulta em U3B. Agora, podemos consultar INFORMACOES.TRABALHA.EM como faríamos com qualquer outra relação; quando não precisarmos mais dela, poderemos removê-la usando o comando DROP TABLE (ver Capítulo 7). Observe que a tabela INFORMACOES. TRABALHA.EM pode não estar atualizada; ou seja, se atualizarmos qualquer uma das relações PROJETO, TRABALHA.EM ou FUNCIONÁRIO depois de emitir U3B, a informa­ ção em INFORMACOES.TRABALHA.EM pode ficar desatualizada. Temos dc criar uma visão, ou view (ver Capítulo 7), para manter essa tabela atualizada. A maioria dos SGBDs tem ferramentas dc carregamento em massa que permitem que um usuário carregue dados formatados de um arquivo em uma tabela sem ter de escrever um grande número de comandos INSERT. O usuário também pode escrever um programa para ler cada registro no arquivo, formatá-lo como uma linha na tabela e inseri-lo usando as construções de looping de uma linguagem de programação (ver capítulos 10 e 11, nos quais discutimos técnicas de programação de banco de dados). Outra variação para carregar dados é criar uma nova tabela TNOVA que tenha os mesmos atributos da tabela T existente e carregar alguns dos dados atualmente cm T para TNOVA. A sintaxe para fazer isso usa a cláusula LIKE. Por exemplo, se quisermos criar uma tabela FUNC.DEP.5 com uma estrutura semelhante à tabela FUNCIONÁRIO e carregá-la com as linhas dos funcionários que trabalham no departamento 5, podemos escrever a seguinte SQL:

CREATE TABLE (SELECT FROM WHERE

FUNC.DEP.5 LIKE FUNCIONÁRIO * F. FUNCIONÁRIO ASF F.Numero.departamento = 5) WITH DATA;

181

182

Sistemas de banco de dados A cláusula WITH DATA especifica que a tabela será criada e carregada com os dados especificados na consulta, embora, em algumas implementações, ela possa ser omitida.

6.4.2 0 comando DELETE O comando DELETE remove tuplas de uma relação. Ele inclui uma cláusula WHERE, semelhante à que é usada em uma consulta SQL, para selecionar as tuplas a serem excluídas. As tuplas são explicitamente excluídas de apenas uma tabela por vez. No entanto, a exclusão pode se propagar para as tuplas em outras relações, se ações de disparo referencial forem especificadas nas restrições de integridade referencial da DDL (ver Seção 6.2.2).12 Dependendo do número de tuplas sele­ cionadas pela condição na cláusula WHERE, zero, uma ou várias tuplas podem ser excluídas por um único comando DELETE. Uma cláusula WHERE inexistente especifica que todas as tuplas na relação deverão ser excluídas; porém, a tabela permanece no banco de dados como uma tabela vazia. Temos de usar o comando DROP TABLE para remover a definição da tabela (ver Capítulo 7). Os comandos DELETE em U4A a U4D, se aplicados de maneira independente ao banco de dados da Figura 5.6, excluirão zero, uma, quatro e todas as tuplas, respectiva mente, da relação FUNCIONÁRIO: U4A:

U4B: U4C: U4D:

DELETE WHERE DELETE WHERE DELETE WHERE DELETE

FROM FROM FROM FROM

FUNCIONÁRIO Ultimo.nome = ‘Braga’; FUNCIONÁRIO Cpf = ‘12345678966 ’; FUNCIONÁRIO Numero.departamento = FUNCIONÁRIO;

6.4.3 0 comando UPDATE O comando UPDATE é usado para modificar valores de atributo de uma ou mais tuplas selecionadas. Assim como no comando DELETE, uma cláusula WHERE no comando UPDATE seleciona as tuplas a serem modificadas em uma única relação. No entanto, a atualização de uma chave primária pode ser propagada para os valores de chave estrangeira das tuplas em outras relações se tal ação de disparo referencial for especificada nas restrições de integridade referencial da DDL (ver Seção 6.2.2). Uma cláusula SET adicional no comando UPDATE especifica os atributos a serem modificados e seus novos valores. Por exemplo, para alterar o local e o número de departamento que controla o número de projeto 10 para ‘Santo André’ e 5, respectivamente, usamos U5:

U5:

UPDATE SET WHERE

PROJETO Local.projeto = 'Santo André', Numero.departamento = 5 Numero.projeto = 10;

Várias tuplas podem ser modificadas com um único comando UPDATE. Um exem­ plo é dar a todos os funcionários no departamento ‘Pesquisa’ um aumento de 10% no salário, como mostra U6. Nesta solicitação, o valor de Salario modificado depende do valor de Salario em cada tupla, de modo que duas referências ao atributo Salario são necessárias. Na cláusula SET, a referência ao atributo Salario à direita refere-se 12 Outras ações podem ser aplicadas automaticamente através do conceito de triggers (ver Seção 26.1) e outros mecanismos.

Capitulo 6 SQL básica

ao antigo valor de Salario, antes da modificação, e aquele à esquerda refere-se ao novo valor de Salario, após a modificação-. U6:

UPDATE SET WHERE

FUNCIONÁRIO Salario = Salario * 1.1 Numero.departamento = 5;

Também é possível especificar NULL ou DEFAULT como o novo valor do atributo. Observe que cada comando UPDATE refere-se explicitamente a apenas uma única relação. Para modificar várias relações, precisamos emitir vários comandos UPDATE.

6.5 Recursos adicionais da SQL A SQL possui uma série de recursos adicionais que não descrevemos neste capí­ tulo, mas que discutiremos em outras partes do livro. São eles:

■ No Capítulo 7, que é uma continuação deste capítulo, apresentaremos os seguin­ tes recursos da SQL: diversas técnicas para especificar consultas de recuperação complexas, incluindo consultas aninhadas, funções de agregação, agrupamento, tabelas com junções (join), junções externas (outer joins), instruções case e con­ sultas recursivas; visões (vieivs), gatilhos (triggers) e asserções (assertions) da SQL; e comandos para modificação de esquema. ■ A linguagem SQL possui diversas técnicas para a escrita de programas em várias linguagens de programação, que incluem instruções SQL para acessar um ou mais bancos de dados. Estas incluem SQL embutida (e dinâmica), SQL/CLI (Call Level Interface) e seu predecessor ODBC (Open Data Base Connectivity) e SQL/ PSM (Persistent Stored Modules). Discutiremos essas técnicas no Capítulo 10. Também discutiremos como acessar bancos de dados SQL por meio da linguagem de programação Java usando JDBC e SQLJ. ■ Cada SGBDR comercial terá, além dos comandos SQL, um conjunto de coman­ dos para especificar parâmetros de projeto do banco de dados físico, estruturas de arquivo para relações e caminhos de acesso como índices. Chamamos esses comandos de linguagem de definição de armazenamento (SDL) no Capítulo 2. As primeiras versões da SQL tinham comandos para criar índices, mas estes foram removidos da linguagem porque não estavam no nível de esquema conceituai. Muitos sistemas ainda têm comandos CREATE INDEX, mas eles exigem um privi­ légio especial. Discutiremos isso no Capítulo 17. ■ A SQL possui comandos de controle de transação. Estes são usados para espe­ cificar unidades de processamento de banco de dados para fins de controle de concorrência e recuperação. Discutiremos esses comandos no Capítulo 20, depois de discutirmos o conceito de transações com mais detalhes. ■ A SQL possui construções da linguagem para especificar a concessão e revo­ gação de privilégios aos usuários. Os privilégios normalmente correspondem ao direito de usar certos comandos SQL para acessar determinadas relações. Cada relação recebe um owner (proprietário), e este ou o DBA pode conceder a usuários selecionados o privilégio de usar uma instrução SQL — como SELECT, INSERT, DELETE ou UPDATE — para acessar a relação. Além disso, o DBA pode conceder os privilégios para criar esquemas, tabelas ou visões a certos usuários. Esses comandos SQL — chamados de GRANT e REVOKE — serão discutidos no Capítulo 20, no qual falaremos sobre segurança e autorização no banco de dados. ■ A SQL possui construções de linguagem para a criação de triggers. Estas geral­ mente são conhecidas como técnicas dc banco dc dados ativo, pois especificam

183

184 Sistemas de banco de dados ações que sào disparadas automaticamente por eventos, como atualizações no banco de dados. Discutiremos esses recursos na Seção 26.1, na qual abordaremos os conceitos de banco de dados ativo. ■ A SQL incorporou muitos recursos dos modelos orientados a objeto para ter capacidades mais poderosas, levando a sistemas relacionais avançados, conhe­ cidos como objeto-relacional. Capacidades como criar atributos complexos, especificar tipos de dados abstratos (chamados UDTs ou tipos definidos pelo usuário) para atributos e tabelas, criar identificadores de objeto para referenciar tuplas e especificar operações sobre tipos serão discutidas no Capítulo 12. ■ SQL e bancos de dados relacionais podem interagir com novas tecnologias, como XML (ver Capítulo 13) e OLAP (Capítulo 29).

6.6 Resumo Neste capítulo, apresentamos a linguagem de banco de dados SQL. Essa lingua­ gem e suas variações têm sido implementadas como interfaces para muitos SGBDs relacionais comerciais, incluindo Oracle, da Oracle; DB2, da IBM; SQL Servem da Microsoft; e muitos outros sistemas, incluindo Sybase e INGRES. Alguns sistemas de código aberto também oferecem SQL, como MySQL e PostgreSQL. A versão original da SQL foi implementada no SGBD experimental chamado SYSTEM R, que foi desenvolvido na IBM Research. A SQL foi projetada para ser uma linguagem abrangente, que inclui instruções para definição de dados, consultas, atualizações, especificação de restrição e definição de view, ou visão. Neste capítulo, discutimos os seguintes recursos da SQL: comandos de definição de dados para criar tabelas, tipos de dados básicos da SQL, comandos para especificação de restrição, consultas dc recuperação simples e comandos de atualização de banco dc dados. No próximo capítulo, apresentaremos os seguintes recursos da SQL: consultas dc recuperação complexas; views; triggers e assertions; e comandos de modificação de esquema.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

6.1.

Como as relações (tabelas) em SQL diferem das relações definidas formalmente no Capítulo 5? Discuta as outras diferenças na terminologia. Por que a SQL permite tuplas duplicadas cm uma tabela ou cm um resultado dc consulta? 6.2. Liste os tipos dc dados que são permitidos para atributos SQL. 6.3. Como a SQL permite a implementação das restrições de integridade de entidade e de integridade referencial descritas no Capítulo 5? E as ações de disparo referencial? 6.4. Descreva as quatro cláusulas na sintaxe dc uma consulta dc recuperação SQL simples. Mostre que tipo de construção pode ser especificado em cada uma das cláusulas. Quais são obrigatórias e quais são opcionais?

EXERCÍCIOS-----------------------------------------------------------------------------------------------

6.5.

Considere o banco de dados mostrado na Figura 1.2, cujo esquema aparece na Figura 2.1. Quais são as restrições de integridade referencial que devem ser mantidas no esquema? Escreva instruções DDL da SQL apropriadas para definir o banco de dados.

Capitulo 6 SQL básica

6.6. 6.7.

Repita o Exercício 6.5, mas use o esquema de banco de dados COMPANHIA AEREA da Figura 5.8. Considere o esquema de banco de dados relacionai BIBLIOTECA mostrado na Figura 6.6. Escolha a ação apropriada (rejeitar, propagar, SET NULL, SET DEFAULT) para cada restrição de integridade referencial, tanto para a exclusão de uma tupla referenciada quanto para a atualização de um valor de atributo dc chave primária em uma tupla referenciada. Justifique suas escolhas. LIVRO

Figura 6.6 Um esquema de banco de dados relacionai para um banco de dados BIBLIOTECA.

6.8.

Escreva as instruções DDL da SQL apropriadas para declarar o esquema de banco de dados relacionai BIBLIOTECA da Figura 6.6. Especifique as chaves e as ações de disparo referencial. 6.9. Como as restrições de chave e de chave estrangeira podem ser impostas pelo SGBD? A técnica de imposição que você sugere é difícil de implementar? As verificações dc restrição podem ser executadas dc modo eficiente quando as atualizações são aplicadas ao banco dc dados? 6.10. Especifique as seguintes consultas em SQL sobre o esquema de banco de dados relacionai EMPRESA mostrado na Figura 5.5. Mostre o resultado de cada consulta se ela for aplicada ao banco de dados EMPRESA na Figura 5.6. a. Recupere os nomes de rodos os funcionários no departamento 5 que tra­ balham mais de 10 horas por semana no projeto ProdutoX. b. Liste os nomes de todos os funcionários que possuem um dependente com o mesmo primeiro nome que seu próprio. c. Ache os nomes de todos os funcionários que são supervisionados direta­ mente por‘Fernando Wong'.

185

186 Sistemas de banco de dados 6.11. Especifique as atualizações do Exercício 5.11 usando comandos de atualização da SQL. 6.12. Especifique as consultas a seguir em SQL no esquema de banco de dados da Figura 1.2. a. Recupere os nomes de todos os alunos sênior que estão se formando em ‘CC’ (Ciência da Computação). b. Recupere os nomes dc todas as disciplinas lecionadas pelo Professor Kleber cm 2007 c 2008. c. Para cada matéria lecionada pelo Professor Kleber, recupere o número da disciplina, semestre, ano e número de alunos que frequentaram a turma. d. Recupere o nome e o histórico de cada aluno sênior (Tipo_aluno = 4) que está sc formando em CC. Um histórico inclui nome da disciplina, número da disciplina, crédito em horas, semestre, ano e nota para cada disciplina concluída pelo aluno. 6.13. Escreva instruções de atualização SQL para realizar ações sobre o esquema de banco de dados mostrado na Figura 1.2. a. Inserir um novo aluno, , no banco dc dados. b. Alterar o tipo do aluno ‘Silva’ para 2 (segundo ano). c. Inserir uma nova disciplina, . d. Excluir o registro para o aluno cujo nome é ‘Silva’ e cujo número de aluno é 17. 6.14. Crie um esquema dc banco dc dados relacionai para uma aplicação dc banco de dados a sua escolha. a. Declare suas relações, usando a DDL da SQL. b. Especifique algumas consultas em SQL que sejam necessárias para sua aplicação de banco de dados. c. Com base em seu uso esperado do banco de dados, escolha alguns atri­ butos que deverão ter índices especificados. d. Implemente seu banco de dados, se você tiver um SGBD que suporta SQL. 6.15. Considerequea restriçãoCHAVEESTRFUNC.SUPERVISORda tabela FUNCIONÁRIO, conforme especificado na Figura 6.2, seja mudada para:

CONSTRAINT CHAVEESTRFUNC.SUPERVISOR FOREIGN KEY (Cpf.supervisor) REFERENCES FUNCIONARIO(Cpf) ON DELETE CASCADE ON UPDATE CASCADE,

Responda às seguintes questões: a. O que acontece quando o comando a seguir é executado no estado de banco de dados mostrado na Figura 5.6? DELETE FUNCIONÁRIO WHERE Ultimo.nome = 'Brito'

b.

É melhor usar CASCADE ou SET NULL no caso da restrição ON DELETE de

CHAVEESTRFUNC .SUPERVISOR? 6.16. Escreva instruções SQL para criar uma tabela COPIA.FUNCIONARIO para fazer o backup da tabela FUNCIONÁRIO mostrada na Figura 5.6.

Capitulo 6 SQL básica BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

A linguagem SQL, originalmente chamada SEQUEL, foi baseada na linguagem SQUARE (Specifying Queries as Relational Expressions), descrita por Boyce et al. (1975). A sintaxe da SQUARE foi modificada para a SEQUEL (Chamberlin e Boyce, 1974) e depois para SEQUEL 2 (Chamberlin et al., 1976), na qual a SQL é baseada. A implementação original da SEQUEL foi feita na IBM Research, em San Jose, Califórnia. Mostraremos outras referências aos vários aspectos da SQL ao final do Capítulo 7.

187

Mais SQL: consultas complexas, triggers, views e modificação de esquema ste capítulo descreve recursos mais avançados da linguagem SQL padrão para bancos de dados relacionais. Começamos na Seção 7.1 apresentando recursos mais complexos das consultas de recuperação SQL, como consultas aninhadas, tabelas de junções, junções externas, funções de agregação, agrupamento e comandos case. Na Seção 7.2, descrevemos o comando CREATE ASSERTION, que permite a especificação dc restrições mais gerais sobre o banco dc dados. Também apresentamos o conceito de triggers (gatilhos) e o comando CREATE TRIGGER, que será descrito com mais detalhes na Seção 26.1, quando mostraremos os princípios dos bancos de dados ativos. Depois, na Seção 7.3, descrevemos a facilidade da SQL para definir views (visões) no banco dc dados. As views tambcm sào chamadas de tabelas virtuais ou derivadas, pois apresentam ao usuário o que parecem ser tabelas; porém, a informação nessas tabelas é derivada de tabelas previamente definidas. A Seção 7.4 apresenta o comando SQL ALTER TABLE, que é usado para modificar as tabelas e as restrições do banco de dados. A Seção 7.5 contém um resumo do capítulo. Este capítulo é uma continuação do Capítulo 6.0 leitor poderá pular partes dele se desejar uma introdução menos detalhada à linguagem SQL.

E

7.1 Consultas de recuperação SQL mais complexas Na Seção 6.3, descrevemos alguns tipos básicos de consultas de recuperação em SQL. Por causa da generalidade e do poder expressivo da linguagem, existem muitos outros recursos adicionais que permitem que os usuários especifiquem recuperações mais complexas do banco de dados. Discutiremos vários desses recursos nesta seção.

190

Sistemas de banco de dados

7.1.1 Comparações envolvendo NULL e lógica de três valores

A SQL tem diversas regras para lidar com valores NULL Lembre-se, da Seção 5.1.2, que NULL é usado para representar um valor que está faltando, mas que em geral tem uma de três interpretações diferentes — valor desconhecido (o valor nào é conhecido, existindo ou não), valor não disponível (o valor existe, mas é propositadamente retido) ou valor não aplicável (o atributo não se aplica a essa tupla ou é indefinido para essa tupla). Considere os seguintes exemplos para ilustrar cada um dos significados de NULL. 1. Valor desconhecido. A data de nascimento de uma pessoa não é conhecida, e por isso é representada por NULL no banco de dados. Um exemplo do outro caso de desconhecido seria NULL para o telefone residencial de uma pessoa, pois não se sabe se ela tem ou não um telefone residencial.

2. Valor indisponível ou retido. Uma pessoa tem telefone residencial, mas não deseja que ele seja listado, por isso ele é retido e representado como NULL no banco de dados. 3. Atributo não aplicável. Um atributo TituloUniversitario seria NULL para uma pessoa que não tivesse nível universitário, pois isso nào se aplica a ela. Normalmente, nào é possível determinar qual dos significados e intencionado; por exemplo, um NULL para o telefone residencial de uma pessoa pode ter qualquer um dos três significados. Logo, a SQL nào distingue entre os diferentes significados de NULL. Em geral, cada valor NULL individual é considerado diferente de qualquer outro valor NULL nos diversos registros do banco de dados. Quando um registro com NULL em um de seus atributos está envolvido em uma operação de comparação, o resultado é considerado UNKNOWN, ou desconhecido (ele pode ser TRUE ou FALSE). Assim, a SQL usa uma lógica de três valores com os valores TRUE, FALSE e UNKNOWN em vez da lógica de dois valores (booleana) padrão, com os valores TRUE e FALSE. Portanto, é necessário definir os resultados (ou valores-verdade) das expressões lógicas de três valores quando os conectivos lógicos AND, OR e NOT forem usados. Tabela 7.1 mostra os valores resultantes. Tabela 7.1 Conectivos lógicos na lógica de três valores.

:a) AND

TRUE

FALSE

UNKNOWN

TRUE

TRUE

FALSE

UNKNOWN

FALSE

FALSE

FALSE

FALSE

UNKNOWN

UNKNOWN

FALSE

UNKNOWN

[b) OR

TRUE

FALSE

UNKNOWN

TRUE

TRUE

TRUE

TRUE

FALSE

TRUE

FALSE

UNKNOWN

UNKNOWN

TRUE

UNKNOWN

UNKNOWN

:c) NOT

TRUE

FALSE

FALSE

TRUE

UNKNOWN

UNKNOWN

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Nas tabelas 7.1 (a) e 7.1 (b), as linhas e colunas representam os valores dos resulta­ dos das condições de comparação, que normalmente apareceríam na cláusula WHERE de uma consulta SQL. Cada resultado de expressão teria um valor TRUE, FALSE ou UNKNOWN. O resultado da combinação de dois valores usando o conectivo lógico AND é mostrado pelas entradas na Tabela 7.1 (a). A Tabela 7.1(b) mostra o resultado do uso do conectivo lógico OR. Por exemplo, o resultado de (FALSE AND UNKNOWN) é FALSE, ao passo que o resultado de (FALSE OR UNKNOWN) é UNKNOWN. A Tabela 7.1(c) mostra o resultado da operação lógica NOT. Observe que, na lógica booleana padrão, somente valores TRUE e FALSE são permitidos; não existe um valor UNKNOWN. Nas consultas seleção-projeção-junção, a regra é que somente as combinações de tuplas que avaliam a expressão lógica na cláusula WHERE da consulta como TRUE são selecionadas. As combinações de tupla avaliadas como FALSE ou UNKNOWN não são selecionadas. Porém, existem exceções a essa regra para certas operações, como junções externas (outer joins), conforme veremos na Seção 7.1.6. A SQL permite consultas que verificam se o valor de um atributo é NULL Em vez de usar = ou o para comparar o valor de um atributo com NULL, a SQL usa os operadores de comparação IS ou IS NOT. Isso porque ela considera cada valor NULL sendo distinto dc cada outro valor NULL dc modo que a comparação dc igualdade não é apropriada. Acontece que, quando uma condição de junção é especificada, as tuplas com valores NULL para os atributos de junção não são incluídas no resultado (a menos que seja uma OUTER JOIN; ver Seção 7.1.6). A Consulta 18 ilustra a compara­ ção com NULL recuperando quaisquer funcionários que não tenham um supervisor.

Consulta 18. Recuperar os nomes de todos os funcionários que não possuem supervisores. C18: SELECT FROM WHERE

Primeiro_nome, Ultimo_nome FUNCIONÁRIO Cpf.supervisor IS NULL;

7.1.2 Consultas aninhadas, tuplas e comparações de conjunto/ multiconjunto Algumas consultas precisam que os valores existentes no banco de dados sejam buscados e depois usados cm uma condição dc comparação. Essas consultas podem ser formuladas convcnicntcincntc com o uso dc consultas aninhadas, que são blocos select-from-where completos dentro de outra consulta SQL. Essa outra consulta é chamada de consulta externa. Essas consultas aninhadas também podem aparecer na cláusula WHERE, ou na cláusula FROM, ou na cláusula SELECT, ou em outras cláusulas SQL, como for preciso. A Consulta 4 é formulada em C4 sem uma con­ sulta aninhada, mas pode ser reformulada para usar consultas aninhadas, como mostramos em C4A. A C4A introduz o operador de comparação IN, que compara um valor v com um conjunto (ou multiconjunto) dc valores V c avalia como TRUE se v for um dos elementos em V. Na C4A, a primeira consulta aninhada seleciona os números dos projetos que possuem um funcionário com sobrenome ‘Silva’ envolvido como gerente, enquanto a segunda consulta aninhada seleciona os números dos projetos que possuem um funcionário com o sobrenome ‘Silva’ envolvido como trabalhador. Na consulta externa, usamos o conectivo lógico OR para recuperar uma tupla PROJETO se o valor de NUMERO.PROJETO dessa tupla estiver no resultado de qualquer uma das consultas aninhadas.

191

192 Sistemas de banco de dados C4A: SELECT FROM WHERE

DISTINCT Numero_projeto PROJETO Numero_projeto IN (SELECT Numero_projeto FROM PROJETO, DEPARTAMENTO, FUNCIONÁRIO WHERE PROJETO.Numero.departamento = DEPARTAMENTO.Numero.departamento AND Cpf_gerente = Cpf AND Ultimo_nome = 'Silva') OR Numero_projeto IN (SELECT Numero_projeto FROM TRABALHA.EM, FUNCIONÁRIO WHERE Cpf.funcionário = Cpf AND Ultimo, nome = 'Silva');

Se uma consulta aninhada retomar um único atributo e uma única tupla, o resul­ tado da consulta será um único valor (escalar). Nesses casos, é permitido usar = em vez de IN para o operador de comparação. Em geral, a consulta aninhada retornará uma tabela (relação), que é um conjunto ou multiconjunto de tuplas. A SQL permite o uso de tuplas de valores em comparações, colocando-os entre parênteses. Para ilustrar isso, considere a seguinte consulta: SELECT FROM WHERE

DISTINCT Cpf.funcionário TRABALHA.EM (Numero.projeto, Horas) IN

( SELECT FROM WHERE

Numero.projeto, Horas TRABALHA.EM Cpf.funcionario = 12345678966 );

Essa consulta selecionará os Cpfs de todos os funcionários que trabalham na mesma combinação (projeto, horas) em algum projeto no qual o funcionário ‘João Silva’ (cujo Cpf = ‘12345678966’) trabalha. Neste exemplo, o operador IN compara a subtupla de valores entre parênteses (Numero_projeto, Horas) dentro de cada tupla em TRABALHA.EM com o conjunto de tuplas com tipos compatíveis produzidas pela consulta aninhada. Além do operador IN, diversos outros operadores de comparação podem ser usados para comparar um único valor v (em geral, um nome de atributo) com um conjunto ou multiconjunto v (tipicamente, uma consulta aninhada). O operador = ANY (ou = SOME) retorna TRUE se o valor v for igual a algum valor no conjunto V e, portanto, é equivalente a IN. As duas palavras-chave ANY e SOME possuem o mesmo efeito. Outros operadores que podem ser combinados com ANY (ou SOME) incluem >, >=, ALL ( SELECT FROM WHERE

Salario FUNCIONÁRIO Numero.departamento = 5);

Observe que essa consulta também pode ser especificada usando a função de agregação MAX (ver Seção 7.1.7).

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Em geral, podemos ter vários níveis de consultas aninhadas. Podemos mais uma vez lidar com a possível ambiguidade entre nomes de atributo se existirem atributos com o mesmo nome — um em uma relação na cláusula FROM da con­ sulta externa e outro em uma relação na cláusula FROM da consulta aninhada. A regra é que uma referência a um atributo nào qualificado refere-se à relação declarada na consulta aninhada mais interna. Por exemplo, nas cláusulas SELECT e WHERE da primeira consulta aninhada de C4A, uma referencia a qualquer atributo não qualificado da relação PROJETO refere-se à relação PROJETO especificada na cláusula FROM da consulta aninhada. Para se referir a um atributo da relação PROJETO especificada na consulta externa, especificamos e nos referimos a um apelido (ou alias, ou variável de tupla) para essa relação. Essas regras são seme­ lhantes às regras de escopo para variáveis de programa na maioria das linguagens de programação que permitem procedimentos e funções aninhadas. Para ilustrar a ambiguidade em potencial dos nomes de atributo nas consultas aninhadas, considere a Consulta 16. Consulta 16. Recuperar o nome de cada funcionário que tem um dependente com o mesmo nome e o mesmo sexo do funcionário. C16: SELECT EPrimeiro_nome, F.LJltimo_nome FROM FUNCIONÁRIO AS F WHERE F.Cpf IN ( SELECT D.Cpf_funcionario FROM DEPENDENTE AS D WHERE F.Primeiro_nome = D.Nome_ dependente AND F.Sexo = D.Sexo); Na consulta aninhada de C16, temos de qualificar F.Sexo porque se refere ao atributo Sexo de FUNCIONÁRIO da consulta externa, e DEPENDENTE também tem um atributo chamado Sexo. Se houvesse quaisquer referências não qua­ lificadas a Sexo na consulta aninhada, elas se refeririam ao atributo Sexo de DEPENDENTE. No entanto, não tertamos de qualificar os atributos Primeiro_nome e Cpf de FUNCIONÁRIO se eles aparecessem na consulta aninhada, pois a relação DEPENDENTE não tem atributos chamados Primeiro_nome e Cpf, dc modo que não existe ambiguidade. Geralmente, é aconselhável criar variáveis de tupla (apelidos) para todas as tabelas referenciadas em uma consulta SQL, para evitar erros e ambiguidades em potencial, conforme ilustrado cm C16.

7.1.3 Consultas aninhadas correlacionadas Sempre que uma condição na cláusula WHERE de uma consulta aninhada referencia algum atributo de uma relação declarada na consulta externa, as duas consultas são consideradas correlacionadas. Podemos entender melhor uma con­ sulta correlacionada ao considerar que a consulta aninhada é avaliada uma vez para cada tupla (ou combinação de tuplas) na consulta externa. Por exemplo, podemos pensar em C16 da seguinte forma: para cada tupla FUNCIONÁRIO, avalie a consulta aninhada, que recupera os valores de Cpf_funcionario para todas as tuplas de DEPENDENTE com o mesmo sexo e nome que a tupla FUNCIONÁRIO; se o valor de Cpf da tupla FUNCIONÁRIO estiver no resultado da consulta aninhada, então selecione essa tupla FUNCIONÁRIO. Em geral, uma consulta escrita com blocos aninhados select-from-where e usando os operadores de comparação = ou IN sempre pode ser expressa como uma única consulta em bloco. Por exemplo, C16 pode ser escrita como em C16A:

193

194 Sistemas de banco de dados C16A:

SELECT FROM WHERE

F.Primeiro.nome, F.UItimo.nome UNCIONARIO AS F, DEPENDENTE AS D F.Cpf = D.Cpf.funcionario AND F.Sexo = D.Sexo AND F.Primeiro.nome = D.Nome.dependente;

7.1.4 As funções EXISTS e UNIQUE em SQL EXISTS e UNIQUE são funções booleanas que retornam TRUE ou FALSE; logo, elas podem ser usadas em uma condição da cláusula WHERE. A função EXISTS em SQL é usada para verificar se o resultado de uma consulta aninhada correlacionada é vazio (não contém tuplas) ou não. O resultado de EXISTS é um valor booleano TRUE se o resultado da consulta aninhada tiver pelo menos uma tupla, ou FALSE, se o resultado da consulta aninhada não tiver tuplas. Ilustramos o uso de EXISTS — e NOT EXISTS — com alguns exemplos. Primeiro, formulamos a Consulta 16 de uma forma alternativa, que usa EXISTS, como em C16B:

C16B:

SELECT FROM WHERE

F.Primeiro.nome, F.UItimo.nome FUNCIONÁRIO AS F EXISTS ( SELECT FROM DEPENDENTE AS D WHERE F.Cpf = D.Cpf.funcionario AND F.Sexo = D.Sexo AND F.Primeiro.nome = D.Nome.dependente);

EXISTS e NOT EXISTS costumam ser usados em conjunto com uma consulta aninhada correlacionada. Em C16B, a consulta aninhada referencia os atributos Cpf, Primeiro.nome e Sexo da relação FUNCIONÁRIO da consulta externa. Podemos pensar em C16B da seguinte forma: para cada tupla FUNCIONÁRIO, avalie a consulta aninhada, que recupera todas as tuplas DEPENDENTE com os mesmos Cpf.funcio­ nario, Sexo e Nome.dependente que a tupla FUNCIONÁRIO; se existir (EXISTS) em pelo menos uma tupla no resultado da consulta aninhada, então selecionar essa tupla de FUNCIONÁRIO. EXISTS(C) retorna TRUE se existe pelo menos uma tupla no resultado da consulta aninhada C,e retorna FALSE em caso contrário. Por sua vez, NOT EXISTS(C) retorna TRUE se não houver tuplas no resultado da consulta aninhada C, e retorna FALSE em caso contrário. Em seguida, ilustramos o uso de NOT EXISTS.

Consulta 6. Recuperar os nomes de funcionários que não possuem dependentes. C6:

SELECT FROM WHERE

Primeiro.nome, Ultimo.nome FUNCIONÁRIO NOT EXISTS ( SELECT FROM DEPENDENTE WHERE Cpf = Cpf.funcionario);

Em C6, a consulta aninhada correlacionada recupera todas as tuplas de DEPENDENTE relacionadas a uma tupla FUNCIONÁRIO em particular. Se não exis­ tir nenhuma., a tupla FUNCIONÁRIO é selecionada, porque a condição da cláusula WHERE será avaliada como TRUE nesse caso. Podemos explicar C6 da seguinte forma: para cada tupla FUNCIONÁRIO, a consulta aninhada correlacionada seleciona todas as tuplas DEPENDENTE cujo valor de Cpf.funcionario combina com o Cpf de FUNCIONÁRIO; se o resultado for vazio, nenhum dependente estará relacionado ao funcionário, de modo que selecionamos essa tupla FUNCIONÁRIO e recuperamos seu Primeiro.nome e Ultimo.nome. Consulta 7. Listar os nomes dos gerentes que possuem pelo menos um dependente.

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

C7: SELECT Primeiro.nome, Ultimo.nome FROM FUNCIONÁRIO WHERE EXISTS ( SELECT FROM DEPENDENTE WHERE Cpf = Cpf.funcionário) AND EXISTS ( SELECT FROM DEPARTAMENTO WHERE Cpf = Cpf.gerente ); Uma maneira de escrever essa consulta é mostrada em C7, em que especificamos duas consultas aninhadas correlacionadas; a primeira seleciona todas as tuplas de DEPENDENTE relacionadas a um FUNCIONÁRIO, e a segunda seleciona todas as tuplas de DEPARTAMENTO gerenciadas pelo FUNCIONÁRIO. Se pelo menos uma da primeira e pelo menos uma da segunda existirem, selecionamos a tupla FUNCIONÁRIO. Você consegue reescrever essa consulta usando apenas uma única consulta aninhada ou nenhuma consulta aninhada? A consulta C3, recuperar o nome de cada funcionário que trabalha em todos os projetos controlados pelo departamento número 5, pode ser escrita usando EXISTS e NOT EXISTS nos sistemas SQL. Mostramos duas maneiras de especificar essa consulta C3 em SQL como C3A e C3B. Este é um exemplo de certos tipos de consultas que exigem quantificação universal, conforme discutiremos na Seção 8.6.7. Um modo de escrever essa consulta é usar a construção ($2 EXCEPT SI), conforme explicaremos a seguir, e verificar se o resultado é vazio.1 Essa opção aparece como C3A.

C3A: SELECT Primeiro.nome, Ultimo.nome FROM FUNCIONÁRIO WHERE NOT EXISTS (( SELECT Numero_projeto FROM PROJETO WHERE Numero.departamento = 5) EXCEPT (SELECT Numero_projeto FROM TRABALHA.EM WHERE Cpf = Cpf.funcionario));

Em C3A, a primeira subconsulta (que não está correlacionada à consulta externa) seleciona todos os projetos controlados pelo departamento 5, e a segunda subcon­ sulta (que está correlacionada) seleciona todos os projetos cm que o funcionário cm particular trabalha. Se a diferença de conjunto do resultado da primeira subconsulta menos (EXCEPT) o resultado da segunda subconsulta for vazio, significa que o fun­ cionário trabalha em todos os projetos e, portanto, é selecionado. A segunda opção aparece como C3B. Observe que precisamos de aninhamento de dois níveis em C3B e que essa formulação é muito mais complexa que C3A. C3B: SELECT Ultimo.nome, Primeiro.nome FROM FUNCIONÁRIO WHERE NOT EXISTS (SELECT * FROM TRABALHA.EM AS B WHERE( B.NumerO-projeto IN (SELECT Numero_projeto FROM PROJETO WHERE Numero_departamento = 5 )

1 I.embre-se de que EXCEPT é um operador de diferença de conjunto. A palavra-chave MINUS às vezes é usada, por exemplo, no Oracle.

195

196 Sistemas de banco de dados

AND NOT EXISTS

( SELECT FROM WHERE AND

TRABALHA_EM AS C CCpf_funcionario = Cpf C.Numero_projeto = B.Numero_projeto)));

Em C3B, a consulta aninhada externa seleciona quaisquer tuplas de TRABALHA_EM (B) cujo Numero_projeto é de um projeto controlado pelo departamento 5, se não houver uma tupla em TRABALHA_EM (C) com o mesmo Numero_projeto e o mesmo Cpf daquele da tupla FUNCIONÁRIO em consideração na consulta externa. Se não existir tal tupla, selecionamos a tupla FUNCIONÁRIO. A forma de C3B combina com a reformulação da Consulta 3: selecionar cada funcionário de modo que não exista um projeto controlado pelo departamento 5 cm que o funcionário nào trabalha. Isso corresponde ao modo como escreveremos essa consulta no cálculo relacionai de tupla (ver Seção 8.6.7). Existe outra função em SQL, UNIQUE(C), que retorna TRUE se não houver tuplas duplicadas no resultado da consulta C; caso contrário, ela retorna FALSE. Isso pode ser usado para testar se o resultado de uma consulta aninhada é um conjunto (sem duplicatas) ou um multiconjunto (existem duplicatas). 7.1.5 Conjuntos explícitos e renomeação de atributos em SQL

Vimos várias consultas com uma consulta aninhada na cláusula WHERE. Também é possível usar um conjunto explícito de valores na cláusula WHERE, em vez de uma consulta aninhada. Esse conjunto é delimitado por parênteses em SQL. Consulta 17. Recuperar os números do CPF de todos os funcionários que traba­ lham nos projetos de números 1, 2 ou 3. C17: SELECT FROM WHERE

DISTINCT Cpf_funcionario TRABALHA-EM Numero_projeto IN (1,2,3);

Em SQL, é possível renomear qualquer atributo que apareça no resultado de uma consulta acrescentando o qualificador AS, seguido pelo novo nome desejado. Logo, a construção AS pode ser usada para apelidar os nomes tanto do atributo quanto da relação em geral, e ela pode ser usada em partes apropriadas de uma consulta. Por exemplo, a C8A mostra como a consulta C8 da Seção 6.3.2 pode ser ligeiramente alterada para recuperar o último nome de cada funcionário e seu supervisor, enquanto renomeia os atributos resultantes como Nome_fundonario e Nome_supervisor. Os novos nomes aparecerão como cabeçalhos de coluna no resultado da consulta. C8A: SELECT FROM WHERE

F.UItimo_nome AS Nomejuncionario, S.UItimo_nome AS Nome, supervisor FUNCIONÁRIO AS F, FUNCIONÁRIO AS S F.Cpf-Supervisor = S.Cpf;

7.1.6 Tabelas de junção em SQL e junções externas (outerjoins)

O conceito de uma tabela de junção (ou relação de junção) foi incorporado na SQL para permitir aos usuários especificar uma tabela resultante de uma operação de junção na cláusula FROM de uma consulta. Essa construção pode ser mais fácil de compreender que misturar todas as condições de seleção e junção na cláusula WHERE. Por exemplo, considere a consulta C1, que recupera o nome e o endereço de todos os funcionários que trabalham para o departamento'Pesquisa'. Pode ser mais

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

fácil especificar a junção das relações FUNCIONÁRIO e DEPARTAMENTO na cláusula WHERE, e depois selecionar as tuplas e atributos desejados. Isso pode ser escrito em SQL como em C1 A:

C1 A:SELECT Primeiro.nome, Ultimo.nome, Endereço FROM (FUNCIONÁRIO JOIN DEPARTAMENTO ON FUNCIONARIO.Numero. departamento = DEPARTAMENTO.Numero.departamento) WHERE Nome.departamento = 'Pesquisa';

A cláusula FROM em C1A contém uma única tabela de junção. Os atributos dessa tabela sào todos os atributos da primeira tabela, FUNCIONÁRIO, seguidos por todos os atributos da segunda tabela, DEPARTAMENTO. O conceito de uma tabela de junção também permite que o usuário especifique diferentes tipos dc junção, como NATURAL JOIN (junção natural), e vários tipos de OUTER JOIN (junção externa). Em uma NATURAL JOIN sobre duas relações R e S, nenhuma condição de junção é espe­ cificada; cria-se uma condição EQUIJOIN implícita para cada par de atributos com o mesmo nome dc R c S. Cada par dc atributos desse tipo é incluído apenas uma vez na relação resultante (ver seções 8.3.2 c 8.4.4 para obter mais detalhes sobre os vários tipos de operações de junção na álgebra relacionai). Se os nomes dos atributos de junção não forem os mesmos nas relações básicas, é possível renomear os atributos de modo que eles combinem, e depois aplicar a NATURAL JOIN. Nesse caso, a construção AS pode ser usada para renomear uma relação e todos os seus atributos na cláusula FROM. Isso é ilustrado em C1 B,em que a relação DEPARTAMENTO é renomeada como DEP e seus atributos são renomeados como Nome.dep, Numero.departamento (para combinar com o nome do atributo de junção desejado Numero.departamento na tabela FUNCIONÁRIO), Gerente.dep e Inido.gerente.dep. O significado da condição dc junção para esse NATURAL JOIN é FUNCIONÁRIO.Numero.departamento = DEP.Numero.departamento, porque esse é o único par dc atributos com o mesmo nome após a renomeação: C1B:

SELECT FROM

WHERE

Primeiro.nome, Ultimo.nome, Endereço (FUNCIONÁRIO NATURAL JOIN (DEPARTAMENTO AS DEP (Nome.dep, Numero.departamento, Gerente.dep, Inicio.gerente.dep))) Nome.dep = 'Pesquisa';

O tipo padrão de junção em uma tabela de junção é chamado de inner join, em que uma tupla é incluída no resultado somente se uma tupla combinar na outra relação. Por exemplo, na consulta C8A, somente os funcionários que possuem um supervisor são incluídos no resultado; uma tupla FUNCIONÁRIO cujo valor para Cpf.supervisor é NULL é excluída. Se o usuário exigir que todos os funcionários sejam incluídos, uma OUTER JOIN precisa ser usada explicitamente (veja, na Seção 8.4.4, a definição de OUTER JOIN na álgebra relacionai). No padrão SQL, isso é tratado especificando explicitamente a palavra-chave OUTER JOIN em uma tabela de junção, conforme ilustrado cm C8B: C8B: SELECT FROM

F.UItimo.nome AS Nome.funcionario, S.UItimo.nome AS Nome.supervisor (FUNCIONÁRIO AS F LEFT OUTER JOIN FUNCIONÁRIO AS S ON EC pf.supervisor = S.Cpf);

Em SQL, as opções disponíveis para especificar tabelas de junção incluem INNER JOIN (apenas pares de tuplas que combinam com a condição de junção são recupera­ dos, o mesmo que JOIN), LEFT OUTER JOIN (toda tupla na tabela da esquerda precisa aparecer no resultado; se não tiver uma tupla combinando, ela é preenchida com valores NULL para os atributos da tabela da direita), RIGHT OUTER JOIN (toda tupla na

197

198 Sistemas de banco de dados tabela da direita precisa aparecer no resultado; se não tiver uma tupla combinando, ela é preenchida com valores NULL para os atributos da tabela da esquerda) e FULL OUTER JOIN. Nas três últimas opções a palavra-chave OUTER pode ser omitida. Se os atributos de junção tiverem o mesmo nome, também é possível especificar a variação de junção natural das junções externas usando a palavra-chave NATURAL antes da operação (por exemplo, NATURAL LEFT OUTER JOIN). A palavra-chave CROSS JOIN é usada para especificar a operação PRODUTO CARTESIANO (ver Seção 8.2.2), embora isso só deva ser feito com o máximo de cuidado, pois gera todas as combinações de tuplas possíveis. Também é possível aninhar especificações de junção; ou seja, uma das tabelas em uma junção pode ela mesma ser uma tabela de junção. Isso permite a especifi­ cação da junção de três ou mais tabelas como uma única tabela de junção, o que é chamado de junção de tabela múltipla. Por exemplo, a C2A é um modo diferente de especificar a consulta C2, da Seção 6.3.1, usando o conceito de uma tabela de junção:

C2A: SELECT FROM

WHERE

Numero_projeto, PROJETO.Numero.departamento, Ultimo.nome, Endereço, Data.nascimento ((PROJETO JOIN DEPARTAMENTO ON PROJETO. Nu mero, departamento = DEPARTAMENTO.Numero.departamento) JOIN FUNCIONÁRIO ON Cpf.gerente = Cpf) Local.projeto = 'Mauá';

Nem todas as implementações de SQL empregaram a nova sintaxe das tabelas de junção. Em alguns sistemas, uma sintaxe diferente foi usada para especificar junções externas usando os operadores de comparação +=, =+ e +=+ para a junção externa esquerda, direta e completa, respectiva mente, ao especificar a condição de junção. Por exemplo, essa sintaxe está disponível no Oracle. Para especificar a jun­ ção externa esquerda na C8B usando essa sintaxe, poderiamos escrever a consulta C8C, da seguinte forma: C8C: SELECT FROM WHERE

EUItimo.nome, S.UItimo.nome FUNCIONÁRIO F, FUNCIONÁRIO S EC pf.su pervisor += S.Cpf;

7. /. 7 Funções de agregação em SQL

As funções de agregação são usadas para resumir informações de várias tuplas em uma síntese de tupla única. O agrupamento é usado para criar subgrupos de tuplas antes do resumo. O agrupamento e a agregação são exigidos em muitas aplicações de banco dc dados, c apresentaremos seu uso na SQL por meio de exemplos. Existem diversas funções dc agregação embutidas: COUNT, SUM. MAX. MIN c AVG.2 A fun­ ção COUNT retorna o número de tuplas ou valores, conforme especificado em uma consulta. As funções SUM, MAX, MIN e AVG podem ser aplicadas a um conjunto ou multiconjunto de valores numéricos e retomam, respecrivamente, a soma, o valor máximo, o valor mínimo e a média desses valores. Essas funções podem ser usadas na cláusula SELECT ou cm uma cláusula HAVING (que apresentaremos mais adiante). As funções MAX c MIN também podem ser usadas com atributos que possuem domí­ nios não numéricos, se os valores do domínio tiverem uma ordenação total entre si.3 Vamos ilustrar o uso dessas funções com algumas consultas. 2 Funções de agregação adicionais para cálculo estatístico mais avançado foram acrescentadas na SQL-99. ’ Ordenação total significa que, para dois valores quaisquer no domínio, pode ser determinado que um aparece antes do outro na ordem definida; por exemplo, os domínios DATE, TIME e TIMESTAMP pos­ suem ordenações totais em seus valores, assim como as cadeias alfabéticas.

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Consulta 19. Achar a soma dos salários de todos os funcionários, o salário máximo, o salário mínimo e a média dos salários. C19:

SELECT FROM

SUM (Salario), MAX (Salario), MIN (Salario), AVG (Salario) FUNCIONÁRIO;

Esta consulta retorna um resumo em única linha de todas as linhas na tabela FUNCIONÁRIO. Poderiamos usar AS para renomear os nomes de coluna na tabela de única linha resultante; por exemplo, como em C19A.

C19A: SELECT FROM

SUM (Salario) AS Total.Salario, MAX (Salario) AS Maior.Salario, MIN (Salario) AS Menor_Salario, AVG (Salario) AS Media_Salario FUNCIONÁRIO;

Se quisermos obter os valores dessas funções para os funcionários de um depar­ tamento específico — digamos, o departamento ‘Pesquisa’ —, podemos escrever a Consulta 20, na qual as tuplas de FUNCIONÁRIO sào restringidas pela cláusula WHERE aos funcionários que trabalham para o departamento ‘Pesquisa’.

Consulta 20. Achar a soma dos salários de rodos os funcionários do departamento ‘Pesquisa’, bem como o salário máximo, o salário mínimo e a média dos salários nesse departamento. C20:

SELECT FROM

WHERE

SUM (Salario), MAX (Salario), MIN (Salario), AVG (Salario) (FUNCIONÁRIO JOIN DEPARTAMENTO ON FUNCIONARIO.NumerO-departamento = DEPARTAMENTO. Numero.departamento) Nome.departamento = 'Pesquisa';

Consultas 21 e 22. Recuperar o número total de funcionários na empresa (C21) e o número de funcionários no departamento ‘Pesquisa’ (C22). C21:

SELECT FROM

COUNT (*) FUNCIONÁRIO;

C22:

SELECT FROM WHERE

COUNT (*) FUNCIONÁRIO, DEPARTAMENTO FUNCIONÁRIO. Numero.departamento = DEPARTAMENTO.Numero.departamento AND Nome.departamento = 'Pesquisa';

Aqui, o asterisco (* ) refere-se às linhas (tuplas), de modo que COUNT (* ) retoma o número de linhas no resultado da consulta. Também podemos usar a função COUNT para contar os valores em uma coluna, em vez de tuplas, como no exemplo a seguir.

Consulta 23. Contar o número de valores de salário distintos no banco de dados. C23:

SELECT FROM

COUNT (DISTINCT Salario) FUNCIONÁRIO;

Se escrevermos COUNT(SALARIO) em vez de COUNT (DISTINCT SALARIO) na C23, então os valores duplicados não serão eliminados. Porém, quaisquer tuplas com NULL para SALARIO não serão contadas. Em geral, valores NULL são descartados quando as funções de agregação são aplicadas a determinada coluna (atributo). A única exceção é para COUNT( *), pois são contadas tuplas, e não valores. Nos exemplos anteriores, quaisquer valores de Salario que forem NULL não são incluídos no cálculo da função de agregação. zX regra é a seguinte: quando uma função de agregação é aplicada a uma coleção de valores, NULLs são removidos da coleção antes do cálculo; se a coleção se tornar vazia porque todos os valores sào NULL, a função de agregação retornará NULL (exceto no caso de COUNT, que retornará 0 para uma coleção de valores vazia).

199

200 Sistemas de banco de dados

Os exemplos anteriores resumem unia relação inteira (C19, C21, C23) ou um subconjunto selecionado de tuplas (C20, C22), e, portanto, todos produzem uma tabela com uma única linha ou um único valor. Eles ilustram como as funções sâo aplicadas para recuperar um valor de resumo ou uma tupla de resumo de uma tabela. Essas funções também podem ser usadas nas condições de seleção envolvendo consultas aninhadas. Podemos especificar uma consulta aninha­ da correlacionada com uma função de agregação, c depois usar a consulta ani­ nhada na cláusula WHERE dc uma consulta externa. Por exemplo, para recuperar os nomes de todos os funcionários que têm dois ou mais dependentes (Consulta 5), podemos escrever o seguinte: C5:

SELECT FROM WHERE

Ultimo.nome, Primeiro.nome FUNCIONÁRIO (SELECT COUNT (*) FROM DEPENDENTE WHERE Cpf = Cpf.funcionario ) >= 2;

A consulta aninhada correlacionada conta o número de dependentes que cada funcionário tem; se for maior ou igual a dois, a tupla do funcionário é selecionada. A SQL também possui funções agregadas SOME e ALL, que podem ser aplicadas a uma coleção de valores booleanos; SOME retorna TRUE se, pelo menos, um elemento na coleção for TRUE, enquanto ALL retorna TRUE se todos os elementos na coleção forem TRUE. 7.1.8 Agrupamento: as cláusulas GROUP BY e HAVING

Em muitos casos, queremos aplicar as funções de agregação a subgrupos de tuplas em unia relação, na qual os subgrupos são baseados em alguns valores de atributo. Por exemplo, podemos querer achar o salário médio dos funcionários em cada departamento ou o número de funcionários que trabalham em cada projeto. Nesses casos, precisamos particionar a relação cm subconjuntos dc tuplas (ou grupos) não sobrepostos. Cada grupo (partição) consistirá nas tuplas que possuem o mesmo valor de algum(ns) atributo(s), chamado(s) atributo(s) de agrupamento. Podemos, então, aplicar a função a cada grupo desse tipo independentemente, para produzir informações de resumo sobre cada grupo. A SQL tem uma cláusula GROUP BY para essa finalidade. A cláusula GROUP BY especifica os atributos de agrupamento, que também devem aparecer na cláusula SELECT, de modo que o valor resultante da aplicação de cada função de agregação a um grupo de tuplas apareça com o valor do(s) atributo(s) de agrupamento.

Consulta 24. Para cada departamento, recuperar o número do departamento, o número de funcionários no departamento e seu salário médio. C24:

SELECT FROM GROUP BY

Numero.departamento, COUNT (*), FUNCIONÁRIO Numero.departamento;

AVG (Salario)

Na C24, as tuplas FUNCIONÁRIO são divididas em grupos — cada um tendo o mesmo valor para o atributo GROUP BY Numero.departamento. Logo, cada grupo contém os funcionários que trabalham no mesmo departamento. As fun­ ções COUNT e AVG são aplicadas a cada grupo de tuplas. Observe que a cláusula SELECT inclui apenas o atributo de agrupamento e as funções de agregação a serem aplicadas a cada grupo de tuplas. A Figura 7.1(a) ilustra como o agrupamento funciona na C24.

Capítulo 7

Primeiro. nome

Ultimo. nome

Nome, meio

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Salario

Cpf

Numero, departa­ mento

Cpf.supervisor

João

B

Silva

12345678966

30000

33344555587

5

Fernando

T

Wong

33344555587

40000

88866555576

5

Ronaldo

K

Uma

66688444476

38000

33344555587

5

Joice

A

Leite

45345345376

25000

33344555587

5

Alice

J

Zelaya

99988777767

25000

98765432168

4

Jennifer

S

Souza

98765432168

43000

88866555576

4

André

V

Pereira

98798798733

25000

98765432168

4

Jorge

E

Brito

88866555576

55000

NULL

1

Numero de­

201

Avg

Count

partamento

(*)

(Salario)

5

4

33250

4

3

31000

1

1

55000

Resultado de C24

Agrupamento de tuplas FUNCIONÁRIO pelo valor de Numero_departamento

Numero. projeto

Nome_projeto

(b)

Cpf.funcionario

Numero, projeto

ProdutoX

1

12345678966

ProdutoX

1

45345345376

1

20,0

ProdutoY

2

12345678966

2

7,5

ProdutoY

2

45345345376

2

20,0

ProdutoY

2

33344555587

2

10,0

ProdutoZ

3

66688444476

3

40,0

3

33344555587

3

10,0

33344555587

10

10,0

ProdutoZ

32,5

Informatização

10

Informatização

10

99988777767

10

10,0

Informatização

10

98798798733

10

35,0

Reorganização

20

33344555587

20

10,0

Reorganização

20

98765432168

20

15,0

Reorganização

20

88866555576

20

NULL

Novos Benefícios

30

98798798733

30

5,0

Novos Benefícios

30

98765432168

30

20,0

Novos Benefícios

30

99988777767

30

30,0



— Estes grupos nâo sâo sele­ cionados pela condição de HAVING de C26.

Horas



Após aplicar a cláusula WHERE, mas antes de aplicar HAVING

Nome_projeto

Numero.projeto

Cpf.funcionário

Numero.projeto

Horas

ProdutoY

2

12345678966

2

7,5

ProdutoY

2

45345345376

2

ProdutoY

2

33344555587

Informatização

10

Informatização

Count (*)

Nome projeto ProdutoY

3

20,0

Informatização

3

2

10,0

Reorganização

3

33344555587

10

10,0

Novos Benefkios

3

10

99988777767

10

10.0

Informatização

10

98798798733

10

35,0

Reorganização

20

33344555587

20

10,0

Reorganização

20

98765432168

•-

15,0

Reorganização

20

88866555576

20

NULL

Novos Benefícios

30

98798798733

30

5,0

Novos Benefícios

30

98765432168

30

20,0

Novos Benefícios

30

99988777767

30

30,0

Após aplicar a condição da cláusula HAVING

Figura 7.1 Resultados de GROUP BY e HAVING, (a) C24. (b) C26.

Resultado de C26 (Numero_projeto

202 Sistemas de banco de dados Se houver NULLs no atributo de agrupamento, um grupo separado é criado para todas as tuplas com um valor NULL no atributo de agrupamento. Por exemplo, se a tabela FUNCIONÁRIO tivesse algumas tuplas com NULL para o atributo de agru­ pamento Numero_departamento, havería um grupo separado para essas tuplas no resultado da C24.

Consulta 25. Para cada projeto, recuperar o número e o nome do projeto e o número de funcionários que trabalham nesse projeto. C25:

SELECT PROJETO.Numero_projeto, Nome_projeto, COUNT (*) FROM PROJETO, TRABALHA.EM WHERE PROJETO.Numero'.projeto = TRABALHA.EM. Numero.projeto GROUP BY PROJETO.Numero_projeto, Nome.projeto;

A C25 mostra como podemos usar uma condição de junção em conjunto com GROUP BY. Neste caso, o agrupamento e as funções são aplicados após a junção das duas relações na cláusula WHERE. As vezes, queremos recuperar os valores dessas funções somente para grupos que satisfazem certas condições. Por exemplo, suponha que queremos modificar a Consulta 25, de modo que apenas projetos com mais de dois funcionários apareçam no resultado. A SQL oferece uma cláusula HAVING, que pode aparecer cm conjunto com uma cláusula GROUP BY, para essa finalidade. A cláusula HAVING oferece uma condição sobre a informação de resumo referente ao grupo de tuplas associadas a cada valor dos atributos de agrupamento. Somente os grupos que satisfazem a con­ dição são recuperados no resultado da consulta. Isso é ilustrado pela Consulta 26.

Consulta 26. Para cada projeto em que mais de dois funcionários trabalham, recupere o número e o nome do projeto e o número de funcionários que trabalham no projeto. C26: SELECT FROM WHERE GROUP BY HAVING

PROJETO. Numero.projeto, Nome_projeto, COUNT (*) PROJETO, TRABALHA.EM PROJETO. Numero-projeto = TRABALHA_EM.Numero_projeto PROJETO.Numero-projeto, Nome_projeto COUNT (*) > 2,

Observe que, embora as condições de seleção na cláusula WHERE limitem as tuplas às quais as funções são aplicadas, a cláusula HAVING serve para escolher grupos inteiros. A Figura 7.1(b) ilustra o uso de HAVING e apresenta o resultado da C26.

Consulta 27. Para cada projeto, recupere o número e o nome do projeto e o número de funcionários do departamento 5 que trabalham no projeto. C27:

SELECT FROM WH ERE

PROJETO.NumerO-projeto, Nome_projeto, COUNT (*) PROJETO, TRABALHA.EM, FUNCIONÁRIO PROJETO.Numero_projeto = TRABALHA_EM.Numero_projeto AND Cpf = Cpf.funcionario AND FUNCIONÁRIO. Numero.departamento = 5 GROUP BY PROJETO.Numero_projeto, Nome_projeto;

Na C27, restringimos as tuplas na relação (e, portanto, as tuplas em cada grupo) àquelas que satisfazem a condição especificada na cláusula WHERE — a saber, que eles trabalham no departamento número 5. Observe que precisamos ter um cuidado extra quando duas condições diferentes se aplicam (uma para a função de agregação na cláusula SELECT c outra para a função na cláusula HAVING). Por exemplo, suponha que queremos contar o número total de funcionários cujos salários são superiores a RS 40.000 em cada departamento, mas somente para os departamentos em que

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

há mais de cinco funcionários trabalhando. Aqui, a condição (SALARIO > 40000) se aplica apenas à função COUNT na cláusula SELECT. Suponha que escrevamos a seguinte consulta incorreta-. SELECT Numero.departamento, COUNT (*) FROM FUNCIONÁRIO WHERE Salario>40000 GROUP BY Numero.departamento HAVING )>5; * COUNT(

Ela está incorreta porque selecionará somente departamentos que tenham mais dc cinco funcionários que ganham cada um mais de RS 40.000. A regra é que a cláusula WHERE é executada primeiro, para selecionar as tuplas individuais ou tuplas de junção; a cláusula HAVING é aplicada depois, para selecionar grupos individuais de tuplas. Na consulta incorreta, as tuplas já estão restritas a funcio­ nários que ganham mais de RS 40.000 antes que a cláusula HAVING seja aplicada. Um modo de escrever essa consulta corretamente é usar uma consulta aninhada, como mostra a Consulta 28.

Consulta 28. Para cada departamento com mais de cinco funcionários, recuperar o número do departamento e o número de seus funcionários que estão ganhando mais de RS 40.000. C28: SELECT Numero.departamento, COUNT (*) FROM FUNCIONÁRIO WHERE Salario>40000 AND Numero.departamento IN (SELECT Numero.departamento FROM FUNCIONÁRIO GROUP BY Numero.departamento HAVING )>5) * COUNT( GROUP BY Numero.departamento;

7.1.9 Outras construções SQL: WITH e CASE Nesta seção, ilustramos duas outras construções SQL. A cláusula WITH permite que um usuário defina uma tabela que só será usada em uma consulta específica; ela é semelhante à criação de uma visão (ver Seção 7.3), que será usada apenas em uma consulta e depois descartada. Essa construção foi apresentada como uma con­ veniência na SQL:99, e pode nào estar disponível em todos os SGBDs baseados em SQL. As consultas usando WITH costumam ser escritas usando outras construções SQL. Por exemplo, podemos reescrever C28 como C28':

C281:

WITH

DEPARTAMENTO.GRANDE (Numero.departamento) AS ( SELECT Numero.departamento FROM FUNCIONÁRIO GROUP BY Numero.departamento HAVING )>5) * COUNT( SELECT Numero.departamento, COUNT (*) FROM FUNCIONÁRIO WHERE Salario>40000 AND Numero.departamento IN DEPARTAMENTO.GRANDE GROUP BY Numero.departamento;

Em C28', definimos na cláusula WITH uma tabela temporária DEPARTAMENTO. GRANDE, cujo resultado mantém o Numero.departamento dos departamentos com mais de cinco funcionários, depois usamos essa tabela na consulta seguinte.

203

204 Sistemas de banco de dados Quando essa consulta é executada, a tabela temporária DEPARTAMENTO.GRANDE é descartada. SQL também possui uma construção CASE, que pode ser usada quando um valor pode ser diferente, com base em certas condições. Isso pode ser usado em qualquer parte de uma consulta SQL na qual se espera um valor, incluindo quando consultamos, inserimos ou atualizamos tuplas. Vamos ilustrar isso com um exemplo. Suponha que queiramos dar aos funcionários diferentes aumentos de salário, depen­ dendo do departamento para o qual eles trabalham; por exemplo, os funcionários no departamento 5 recebem um aumento de RS 2.000, aqueles no departamento 4 recebem RS 1.500, e aqueles no departamento 1 recebem RS 3.000 (veja as tuplas de funcionários na Figura 5.6). Depois, poderiamos reescrever a operação de atua­ lização U6, da Seção 6.4.3, como U6':

U6': UPDATE SET CASE

FUNCIONÁRIO Salario = WHEN Numero.departamento = 5 WHEN Numero.departamento = 4 WHEN Numero.departamento = 1 ELSE Salario + 0;

THEN Salario + 2000 THEN Salario + 1500 THEN Salario + 3000

Em U6’, o valor do aumento de salário é determinado por meio da construção CASE, com base no número do departamento para o qual o funcionário trabalha. A construção CASE também pode ser usada na inserção de tuplas que podem ter dife­ rentes atributos sendo NULL, dependendo do tipo dc registro inserido em uma tabela, por exemplo, quando uma especialização (ver Capítulo 4) é mapeada para uma única tabela (ver Capítulo 9) ou quando um tipo de união é mapeado para relações.

7.1.10 Consultas recursivas em SQL Nesta seção, ilustramos como escrever uma consulta recursiva na SQL. Essa sin­ taxe foi adicionada na SQL:99 para permitir aos usuários a capacidade de especificar uma consulta recursiva de forma declarativa. Um exemplo de um relacionamento recursive entre as tuplas do mesmo tipo é a relação entre um empregado e um supervisor. Esta relação é descrita pela chave estrangeira Cpf.supervisor da relação FUNCIONÁRIO nas figuras 5.5 e 5.6, c relaciona cada tupla dc funcionário (no papel de supervisionado) com outra tupla dc funcionário (no papel de supervisor). Um exemplo de uma operação recursiva é recuperar todos os supervisionados de um funcionário supervisor e em todos os níveis — isto é, todos os funcionários e' super­ visionados diretamente por e,todos os funcionários e" supervisionados diretamente por cada funcionário e\ todos os funcionários e” supervisionados diretamente por cada empregado e", e assim por diante. Na SQL:99, esta consulta pode ser escrita da seguinte maneira:

C29: WITH RECURSIVE

( SELECT FROM UNION SELECT FROM WHERE *SELECT FROM

SUPERVISIONA.SUPERVISIONADO (Cpf_ supervisiona, Cpf.su pervisiona do) AS Cpf.supervisor, Cpf FUNCIONÁRIO F.Cpf, S.Cpf.supervisiona FUNCIONÁRIO AS F, SUPERVISIONA. SUPERVISIONADO AS S F.Cpf_su pervisor = S. Cpf.su pervisionado)

SUPERVISIONA.SUPERVISIONADO;

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Na C29, estamos definindo uma visão SUPERVISIONA_SUPERVISIONADO que guardará o resultado da consulta recursiva. A visão está inicialmente vazia. Primeiro, ela é carregada com as combinações de CPF do primeiro nível (super­ visor, supervisionado) pela primeira parte (SELECT Cpf.supervisor, Cpf FROM FUNCIONÁRIO), que é chamada de consulta básica. Esta será combinada pela UNION com cada nível sucessivo de supervisionados pela segunda parte, em que o conteúdo da visão é unido novamente com os valores básicos para obter as combinações de segundo nível, que são unidas (UNION) com as de primeiro nível. Isso é repetido por vários níveis sucessivos, até chegar a um ponto fixo, no qual não há mais tuplas adicionadas à visão. Nesse ponto, o resultado da consulta recursiva está na visão SUPERVISIONA.SUPERVISIONADO.

7.1.11 Discussão e resumo das consultas em SQL Uma consulta de recuperação em SQL pode consistir em até seis cláusulas, mas somente as duas primeiras — SELECT e FROM — são obrigatórias. A consulta pode se espalhar por várias linhas, e termina com um sinal de ponto e vírgula. Os termos da consulta são separados por espaços, e parênteses podem ser usados para agrupar partes relevantes de uma consulta na forma padrão. As cláusulas são especificadas na seguinte ordem, e os colchetes [ ... ] são opcionais: SELECT FROM dista de tabelas> [ WHERE ] [ GROUP BY ] [ HAVING l (ORDER BY dista de atributos> ];

A cláusula SELECT lista os atributos ou funções a serem recuperadas. A cláusula FROM especifica todas as relações (tabelas) necessárias na consulta, incluindo as relações de junção, mas não aquelas nas consultas aninhadas. A cláusula WHERE espe­ cifica as condições para selecionar as tuplas dessas relações, incluindo as condições de junção, se necessário. GROUP BY especifica atributos de agrupamento, enquanto HAVING especifica uma condição sobre os grupos selecionados, em vez das tuplas individuais. As funções de agregação embutidas COUNT, SUM, MIN, MAX c AVG são usadas em conjunto com o agrupamento, mas também podem ser aplicadas a todas as tuplas selecionadas em uma consulta sem uma cláusula GROUP BY. Por fim, ORDER BY especifica uma ordem para exibir o resultado de uma consulta. Para formular consultas de maneira correta, é útil considerar as etapas que defi­ nem o significado ou a semântica de cada consulta. Uma consulta é avaliada con­ ceitualmente4 aplicando primeiro a cláusula FROM (para identificar todas as tabelas envolvidas na consulta ou materializar quaisquer tabelas de junção), seguida pela cláusula WHERE para selecionar e juntar tuplas, e depois por GROUP BY e HAVING. Conceitualmente, ORDER BY é aplicado no final para classificar o resultado da con­ sulta. Se nenhuma das três últimas cláusulas (GROUP BY, HAVING e ORDER BY) for especificada, podemos pensar conceitualmente em uma consulta sendo executada da seguinte forma: para cada combinação de tuplas — uma de cada uma das relações especificadas na cláusula FROM —, avaliar a cláusula WHERE; se ela for avaliada como TRUE, colocar os valores dos atributos especificados na cláusula SELECT dessa combinação de tuplas no resultado da consulta. É óbvio que esse não é um modo eficiente de implementar a consulta em um sistema real, e cada SGBD possui rotinas 4 A ordem real de avaliação da consulta depende da implementação; esse é apenas um modo de visuali­ zar conceitualmente uma consulta a fim de formulá-la de maneira correta.

205

206 Sistemas de banco de dados especiais de otimização de consulta para decidir sobre um plano de execução que seja eficiente. Discutiremos sobre o processamento e a otimização da consulta nos capítulos 18 e 19. Em geral, existem várias maneiras de especificar a mesma consulta em SQL. Essa flexibilidade na especificação de consultas possui vantagens e desvantagens. A prin­ cipal vantagem é que os usuários podem escolher a técnica com a qual estão mais acostumados ao especificar uma consulta. Por exemplo, muitas consultas podem ser especificadas com condições de junção na cláusula WHERE, ou usando relações de junção na cláusula FROM, ou com alguma forma de consultas aninhadas e o operador de comparação IN. Alguns usuários podem se sentir mais confiantes usando uma técnica, ao passo que outros podem estar mais acostumados a outra. Do ponto de vista do programador c do sistema com relação à otimização da consulta, é preferí­ vel escrever uma consulta com o mínimo de aninhamento e de ordenação possível, desvantagem de ter várias maneiras de especificar a mesma consulta é que isso pode confundir o usuário, que pode não saber qual técnica usar para especificar tipos de consultas em particular. Outro problema é que pode ser mais eficiente executar uma consulta especificada de uma maneira que a mesma consulta especificada de uma maneira alternativa. O ideal é que isso não aconteça: o SGBD deve processar a mesma consulta da mesma maneira, independentemente de como ela é especificada. Porém, isso é muito difícil na prática, pois cada SGBD possui diferentes métodos para proces­ sar consultas especificadas de diversas maneiras. Assim, uma tarefa adicional sobre o usuário é determinar qual das especificações alternativas é a mais eficiente de executar. O ideal é que o usuário se preocupe apenas em especificar a consulta corretamente, ao passo que o SGBD determinaria como executar a consulta de forma eficiente. Na prática, contudo, ajuda se o usuário souber quais tipos de construções em uma consulta são mais dispendiosos para processar que outros.

7.2 Especificando restrições como asserções e ações como gatilho (triggers) Nesta seção, apresentamos dois recursos adicionais da SQL: o comando CREATE ASSERTION c o comando CREATE TRIGGER. A Seção 7.2.1 discute o CREATE ASSERTION, que pode ser usado para especificar tipos adicionais de restrições que estão fora do escopo das restrições embutidas do modelo relacionai (chaves primá­ ria e única, integridade de entidade e integridade referencial), que apresentamos na Seção 5.2. Essas restrições embutidas podem scr especificadas dentro do comando CREATE TABLE da SQL (ver seções 6.1 c 6.2). Depois, na Seção 7.2.2, apresentamos CREATE TRIGGER, que pode ser usado para especificar ações automáticas que o sistema de banco de dados realizará quando houver certos eventos e condições. Esse ripo de funcionalidade costuma ser conhe­ cido como bancos de dados ativos. Neste capítulo, só apresentamos os fundamentos básicos de gatilhos (triggers), e uma discussão mais completa sobre os bancos de dados ativos pode ser encontrada na Seção 26.1.

7.2.1 Especificando restrições gerais como asserções em SQL Em SQL, os usuários podem especificar restrições gerais — aquelas que não se encaixam em nenhuma das categorias descritas nas seções 6.1 e 6.2 — por meio de asserções declarativas, usando o comando CREATE ASSERTION. Cada asserção recebe um nome dc restrição e é especificada por uma condição semelhante à cláusula WHERE de uma consulta SQL. Por exemplo, para especificar a restrição de que o salário

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

de um funcionário nào pode ser maior que o salário do gerente do departamento para o qual o funcionário trabalha em SQL, podemos escrever a seguinte asserção: CREATE ASSERTION RESTRICAO.SALARIAL CHECK ( NOT EXISTS ( SELECT * FROM FUNCIONÁRIO F, FUNCIONÁRIO G, DEPARTAMENTO D WHERE F.Salario>G.Salario AND F. Numero.departamento = D.Numero.departamento AND D.Cpf.gerente = G.Cpf));

O nome de restrição RESTRICAO.SALARIAL c seguido pela palavra-chave CHECK, que é seguida por uma condição entre parênteses que precisa ser verdadeira em cada estado do banco de dados para que a asserção seja satisfeita. O nome da restrição pode ser usado mais tarde para se referir à restrição ou para modificá-la ou excluí-la. O SGBD c responsável por garantir que a condição não seja violada. Qualquer condição de cláusula WHERE pode ser usada, mas muitas restrições podem ser especificadas usando o estilo EXISTS e NOT EXISTS das condições em SQL. Sempre que alguma tupla no banco de dados fizer com que a condição de um comando ASSERTION seja avaliada como FALSE, a restrição é violada. A restrição é satisfeita por um estado do banco de dados se nenhuma combinação de tuplas nesse estado violar a restrição. A técnica básica para escrever essas asserções c especificar uma consulta que sele­ ciona quaisquer tuplas que violam a condição desejada. Ao incluir essa consulta em uma cláusula NOT EXISTS, a asserção espedficará que o resultado dessa consulta precisa ser vazio para que a condição seja sempre TRUE. Assim, uma asserção é violada se o resultado da consulta não for vazio. No exemplo anterior; a consulta seleciona todos os funcionários cujos salários são maiores que o salário do gerente de seu departamento. Se o resultado da consulta não for vazio, a asserção é violada. Observe que a cláusula CHECK e a condição de restrição também podem ser utilizadas para especificar restrições sobre atributos e domínios individuais (ver Seção 6.2.1) e sobre tuplas individuais (ver Seção 6.2.4). A principal diferença entre CREATE ASSERTION e as restrições de domínio e de tupla individuais é que as cláu­ sulas CHECK sobre atributos, domínios e tuplas individuais são verificadas na SQL somente quando as tuplas sào inseridas ou atualizadas em uma tabela específica. Logo, a verificação de restrição pode ser implementada de maneira mais eficiente pelo SGBD nesses casos. O projetista do esquema deve usar CHECK sobre atributos, domínios e tuplas apenas quando estiver certo de que a restrição só pode ser violada pela inserção ou atualização de tuplas. Por outro lado, o projetista do esquema deve usar CREATE ASSERTION somente em casos em que não é possível usar CHECK sobre atributos, domínios ou tuplas, de modo que verificações simples são implementadas de modo mais eficiente pelo SGBD.

7.2.2 Introdução a gatilhos (triggers) em SQL Outro comando importante em SQL é o CREATE TRIGGER. Em muitos casos, é conveniente especificar um tipo de ação a ser tomada quando certos eventos ocorrem e quando certas condições são satisfeitas. Por exemplo, pode ser útil especificar uma condição que, se violada, faz com que algum usuário seja informado dela. Um gerente pode querer ser informado se as despesas de viagem de um funcionário excederem certo limite, recebendo uma mensagem sempre que isso acontecer. A ação que o SGBD deve tomar nesse caso é enviar uma mensagem apropriada a esse usuário. A condição, portanto, é usada para monitorar o banco de dados. Outras ações podem

207

208 Sistemas de banco de dados ser especificadas, como executar um específico procedimento armazenado (ou stored procedure) ou disparar outras atualizações. O comando CREATE TRIGGER é utilizado para implementar essas ações em SQL. Discutiremos sobre triggers (gatilhos) com detalhes na Seção 26.1, quando descreveremos os bancos de dados ativos. Aqui, vamos apenas dar um exemplo simples de como os gatilhos podem ser usados. Suponha que queiramos verificar se o salário de um funcionário é maior que o salário de seu supervisor direto no banco de dados EMPRESA (ver figuras 5.5 e 5.6). Vários eventos podem disparar esta regra: inserir um novo registro de funcionário, alterar o salário de um funcionário ou alterar o supervisor de um funcionário. Suponha que a ação a ser tomada fosse chamar o procedimento armazenado VIOLACAO-SALARIAL,' que notificará o supervisor. O gatilho poderia então ser escrito como em R5, a seguir. Aqui, estamos usando a sintaxe do sistema de banco de dados Oracle. R5:

CREATE TRIGGER VIOLACAO_SALARIAL BEFORE INSERT OR UPDATE OF SALARIO, CPF_SUPERVISOR ON FUNCIONÁRIO FOR EACH ROW WHEN ( NEW.SALARIO > ( SELECT SALARIO FROM FUNCIONÁRIO WHERE CPF = NEW.CPF_SUPERVISOR )) INFORMAR_SUPERVISOR(NEW.Cpf_supervisor, NEW.Cpf);

O gatilho recebe o nome VIOLACAO_SALARIAL, que pode ser usado para remover ou desativar o gatilho mais tarde. Um gatilho típico, que é considerado um ECA (Evento, Condição, Ação), possui três componentes: 1. O(s) evento(s): estes em geral são operações de atualização no banco de dados, aplicadas explicitamente a ele. Neste exemplo, os eventos são: inserir um novo registro de funcionário, alterar o salário de um funcionário ou alterar o supervisor de um funcionário. A pessoa que escreve o gatilho precisa garantir que todos os eventos possíveis sejam considerados. Em alguns casos, pode ser preciso escrever mais de um gatilho para cobrir todos os casos possíveis. Esses eventos são espe­ cificados após a palavra-chave BEFORE em nosso exemplo, o que significa que o gatilho deve ser executado antes que a operação de disparo seja executada. Uma alternativa é usar a palavra-chave AFTER, que especifica que o gatilho deve ser executado após a operação especificada no evento ser concluída.

2. A condição que determina se a ação da regra deve ser executada: depois que o evento de disparo tiver ocorrido, uma condição opcional pode ser avaliada. Se nenhuma condição for especificada, a ação será executada uma vez que o evento ocorra. Sc uma condição for especificada, ela primeiro c avaliada c, somente se for avaliada como verdadeira, a ação da regra será executada. A condição é especificada na cláusula WHEN do gatilho. 3. A ação a ser tomada: a ação normalmente c uma sequência de instruções em SQL, mas também poderia ser uma transação de banco de dados ou um programa externo que será executado automaticamente. Neste exemplo, a ação é executar o procedimento armazenado INFORMAR_SUPERVISOR. Os gatilhos podem ser usados em várias aplicações, como na manutenção da coerência do banco dc dados, no monitoramento dc atualizações do banco dc dados e na atualização de dados derivados automaticamente. Uma discussão mais completa pode ser vista na Seção 26.1. 5 Suponha que um procedimento externo apropriado renha sido declarado. Discutiremos os procedi­ mentos armazenados no Capítulo 10.

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

7.3 Visões (views) — tabelas virtuais em SQL Nesta seção, apresentamos o conceito de uma visão (view) em SQL. Mostraremos como as visões são especificadas, depois discutiremos o problema de atualizá-las e como elas podem ser implementadas pelo SGBD.

7.3.1 Conceito de uma visão em SQL Uma visão em terminologia SQL é uma única tabela que é derivada de outras tabelas.6 Essas outras tabelas podem ser tabelas básicas ou visões previamente definidas. Uma visão não necessariamente existe em forma física; ela é considerada uma tabela virtual, ao contrário das tabelas básicas, cujas tuplas sempre estão armazenadas fisicamente no banco dc dados. Isso limita as possíveis operações de atualização que podcin ser aplicadas às visões, mas não oferece quaisquer limitações sobre a consulta de uma visão. Pensamos em uma visão como um modo de especificar uma tabela que precisamos referenciar com frequência, embora ela possa não existir fisicamente. Por exemplo, em relação ao banco de dados EMPRESA da Figura 5.5, podemos emitir frequente­ mente consultas que recuperam o nome do funcionário e os nomes dos projetos em que ele trabalha. Em vez de ter de especificar a junção das três tabelas FUNCIONÁRIO, TRABALHA_EM e PROJETO toda vez que emitirmos essa consulta, podemos definir uma visão que é especificada como o resultado dessas junções. Depois, podemos emitir consultas sobre a visão, que são especificadas como leituras de uma única tabela, em vez de leituras envolvendo duas junções sobre três tabelas. Chamamos as tabelas FUNCIONÁRIO, TRABALHA_EM e PROJETO de tabelas dc definição da visão.

7.3.2 Especificação das visões (views) em SQL Em SQL, o comando para especificar uma visão é CREATE VIEW. A visão recebe um nome de tabela (virtual), ou nome de visão, uma lista de nomes de atributo e uma consulta para especificar o conteúdo da visão. Sc nenhum dos atributos da visão resultar da aplicação de funções ou operações aritméticas, não temos dc especificar novos nomes de atributo para a visão, pois eles seriam iguais aos nomes dos atributos das tabelas de definição no caso default. As visões em V1 e V2 criam tabelas virtuais, cujos esquemas são ilustrados na Figura 7.2, quando aplicadas ao esquema dc banco dc dados da Figura 5.5. V1: CREATE VIEW AS SELECT FROM WHERE

TRABALHA_EM1 Primeiro_nome, Ultimo_nome, Nome_projeto, Horas FUNCIONÁRIO, PROJETO, TRABALHA.EM Cpf = Cpf.funcionario AND TRABALHA_EM.Numero_projeto = PROJETO.Numero_projeto;

V2: CREATE VIEW AS SELECT FROM WHERE

GROUP

INFORMACAO_DEP(Nome_departamento, Quantjunc, Total sal) Nome_departamento, COUNT (*), SUM (Salario) DEPARTAMENTO, FUNCIONÁRIO DEPARTAMENTO.Numero.departamento = FUNCIONARIO.Numero_departamento BY Nome_departamento;

6 Conforme usado em SQL, o rermo view é mais limitado que o termo visão do usuário discutido nos capítulos 1 e 2, pois este último possivelmente incluiría muitas relações.

209

210 Sistemas de banco de dados TRABALHA_EM1 Primeiro_nome

Ultimo nome

Nome projeto

Horas

INFORMACAO_DEP Nome departamento

Quant func

TotaLsal

Figura 7.2 Duas vsões especificadas sobre o esquema de banco de dados da Figura 5.5.

Em VI, não especificamos quaisquer novos nomes de atributo para a visão TRABALHA_EM1 (embora pudéssemos tê-lo feito); neste caso, TRABALHA_EM1 herda os nomes dos atributos de visão das tabelas de definição FUNCIONÁRIO, PROJETO e TRABALHA_EM. A visão V2 especifica explicitamente novos nomes de atributo para a visão IN FORMACAO_DEP, usando uma correspondência um para um entre os atributos especificados na cláusula CREATE VIEW e aqueles especificados na cláusula SELECT da consulta que define a visão. Agora, podemos especificar consultas SQL em uma visão — ou tabela virtual — da mesma forma como fazemos consultas envolvendo tabelas básicas. Por exemplo, para recuperar o primeiro e o último nome de todos os funcionários que trabalham no projeto ‘ProdutoX’, podemos utilizar a visão TRABALHA_EM1 e especificar a consulta como na CV1:

CV1: SELECT FROM WHERE

Primeiro.nome, Ultimo_nome TRABALHA_EM1 Nome_projeto = ProdutoX';

A mesma consulta exigiría a especificação de duas junções se fosse realizada diretamente sobre as relações básicas; uma das principais vantagens de uma visão é simplificar a especificação de certas consultas. As visões também são usadas como um mecanismo de segurança e autorização (ver Seção 7.3.4 e Capítulo 30). Supõe-se que uma visão esteja sempre atualizada; se modificarmos as tuplas nas tabelas básicas sobre as quais a visão é definida, esta precisa refletir automatica­ mente essas mudanças. Logo, a visão não é realizada ou materializada no momento de sua definição, mas quando especificamos uma consulta na visão. É responsabili­ dade do SGBD, e não do usuário, cuidar para que a visão mantenha-se atualizada. Discutiremos várias maneiras como o SGBD pode manter uma visão atualizada na próxima subseção. Se não precisarmos mais dc uma visão, podemos usar o comando DROP VIEW para descartá-la. Por exemplo, para descartarmos a visão V1, podemos usar o comando SQL em VIA:

V1 A:

DROP VIEW

TRABALHA.EMl;

7.3.3 Implementação e atualização de visão e visões em linha O problema de como um SGBD pode implementar uma visão de modo eficiente para gerar uma consulta eficaz é muito complexo. Duas técnicas principais foram sugeridas. Uma estratégia, chamada modificação dc consulta, consiste em modificar ou transformar a consulta da visão (submetida pelo usuário) cm uma consulta nas tabelas básicas. Por exemplo, a consulta CV1 seria automaticamente modificada para a seguinte consulta pelo SGBD:

Capítulo 7 SELECT FROM WHERE

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Primeiro.nome, Ultimo.nome FUNCIONÁRIO, PROJETO, TRABALHA.EM Cpf = Cpf.funcionario AND TRABALHA.EM.Numero.projeto = PROJETO.Numero.projeto AND Nome_projeto = 'ProduroX';

A desvantagem dessa técnica é que ela é ineficaz para visões definidas por con­ sultas complexas, que são demoradas de executar, especialmente se várias delas tiverem de ser aplicadas à mesma visão em um curto período. A segunda estratégia, chamada materialização dc visão, consiste cm criar fisicamente uma tabela dc visão temporária quando a visão for criada ou consultada pela primeira vez e manter essa tabela na suposição de que outras consultas na visão acontecerão em seguida. Nesse caso, uma estratégia eficiente para atualizar automaticamente a tabela da visão quando as tabelas básicas forem atualizadas deverá ser desenvolvida para que a visão esteja sempre atualizada. Técnicas que usam o conceito dc atualização incrementai têm sido desenvolvidas para essa finalidade, nas quais o SGBD pode determinar quais novas tuplas devem ser inseridas, excluídas ou modificadas cm uma tabela de visão materializada quando uma atualização dc banco de dados é aplicada a uma das tabelas básicas definidas. A visão geralmenre é mantida como uma tabela materializada (armazenada fisicamente), desde que esteja sendo con­ sultada. Se a visão não for consultada por certo período, o sistema pode então remover automaticamente a tabela física c recalculá-la do zero quando consultas futuras referenciarem a visão. E possível haver diferentes estratégias em relação a quando uma visão materiali­ zada será atualizada. A estratégia de atualização imediata atualiza uma visão assim que as tabelas básicas são alteradas; a estratégia de atualização adiada atualiza a visão quando ela for necessária para uma consulta à visão; e a estratégia de atualização periódica atualiza a visão periodicamente (nesta última estratégia, uma consulta à visão pode obter um resultado desatualizado). Um usuário sempre poderá emitir uma consulta de recuperação contra qualquer visão. Porém, a emissão de um comando INSERT, DELETE ou UPDATE sobre uma visão, em muitos casos, não é possível. Em geral, uma atualização em uma visão definida sobre uma única tabela, sem quaisquer funções de agregação, pode ser mapeada para uma atualização sobre a tabela básica sob certas condições. Para uma visão que envolve junções (joins), uma operação de atualização pode ser mapeada para operações de atualização sobre as relações básicas de múltiplas maneiras. Logo, quase sempre nâo é possível que o SGBD determine qual das atualizações é intencionada. Para ilustrar os problemas em potencial com a atualização de uma visão definida sobre múltiplas tabelas, considere a visão TRABALHA.EM 1 e suponha que emitamos o comando para atualizar o atributo Nome.projeto de ‘João Silva' de ‘ProdutoX’ para ‘ProdutoY’. Essa atualização de visão aparece em UV1: UV1: UPDATE SET WHERE

TRABALHA.EM 1 Nome_projeto = ProdutoY' Ultimo.nome = 'Silva' AND Primeiro.nome = 'João' AND Nome_projeto = ProdutoX';

Essa consulta pode ser mapeada para várias atualizações sobre as relações básicas para gerar o efeito de atualização desejado sobre a visão. Além disso, algumas das atualizações criarão efeitos colaterais adicionais, que afetam o resultado de outras consultas. Por exemplo, aqui estão duas atualizações possíveis, (a) e (b), sobre as relações básicas correspondentes à operação de atualização da visão em UV1:

211

212 Sistemas de banco de dados (a) UPDATE TRABALHA_EM SET Numero-projeto =

WHERE

Cpf_funcionario IN

AND Numero_projeto =

( SELECT FROM WHERE ( SELECT FROM WHERE

Numero-projeto PROJETO Nome_projeto = ProdutoY')

( SELECT FROM WHERE

Numero-projeto PROJETO Nome_projeto = 'ProdutoX');

SET (b) UPDATE PROJETO WHERE Nome_projeto = ProdutoX';

Cpf FUNCIONÁRIO Ultimo_nome = 'Silva' AND Primeiro_nome = 'João')

Nome_projeto = 'ProdutoY'

A atualização (a) relaciona ‘João Silva’ à tupla ‘ProdutoY’ de PROJETO em vez da tupla ‘ProdutoX’ de PROJETO e é a atualização provavelmente mais desejada. Porém, (b) também daria o efeito de atualização desejado sobre a visão, mas realiza isso alterando o nome da tupla ‘ProdutoX’ na relação PROJETO para ‘ProdutoY’. É muito pouco provável que o usuário que especificou a atualização dc visão UV1 queira que ela seja interpretada como em (b), pois isso também tem o efeito colateral de alterar todas as tuplas de visão com Nome_projeto = ‘ProdutoX’. Algumas atualizações de visão podem nào fazer muito sentido; por exemplo, modificar o atributo Total_sal da visão INFORMACAO_DEP não faz sentido porque Total_sal é definido como a soma dos salários dc funcionário individuais. Esta soli­ citação incorreta aparece em UV2:

UV2:

UPDATE SET WHERE

INFORMACAO_DEP TotaLsal = 100000 Nome_departamento = Pesquisa’;

Em geral, uma atualização de visão é viável quando somente unia atualização possível sobre as relações básicas pode realizar o efeito desejado sobre a visão. Sempre que uma atualização sobre a visão puder ser mapeada para mais de uma atualização sobre as relações básicas, isso geralmente não é permitido. Alguns pesquisadores sugeriram que o SGBD tenha um certo procedimento para escolher uma das atualiza­ ções possíveis como a mais provável. Alguns pesquisadores desenvolveram métodos para escolher a atualização mais provável, enquanto outros preferem deixar que o usuário escolha o mapeamento de atualização desejado durante a definição da visão. Porém, essas opções não estão disponíveis na maioria dos SGBDs comerciais. Resumindo, podemos fazer as seguintes observações: ■ Uma visão com uma única tabela de definição é atualizável se seus atributos tiverem a chave primária da relação básica, bem como rodos os atributos com a restrição NOT NULL que não têm valores default especificados. ■ As visões definidas sobre múltiplas tabelas usando junções geralmente não são atualizáveis. ■ As visões definidas usando funções de agrupamento e agregação não são atualizáveis.

Em SQL, a cláusula WITH CHECK OPTION precisa ser acrescentada ao final da definição de visão se uma visão tiver de ser atualizada por comandos INSERT, DELETE ou UPDATE. Isso permite que o sistema rejeite operações que violam as regras da SQL para atualizações de visão. O conjunto completo de regras da SQL para

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

quando uma visão pode ser modificada pelo usuário é mais complexo que as regras já apresentadas. Também é possível definir uma tabela de visão na cláusula FROM de uma consulta SQL. Isso é conhecido como uma visão em linha. Nesse caso, a visão é definida na própria consulta.

7.3.4 Visões como mecanismos de autorização Descreveremos os comandos dc autorização de consulta SQL (GRANT e REVOKE) em detalhes no Capítulo 30, quando apresentarmos mecanismos dc segurança c auto­ rização de banco de dados. Aqui, vamos dar alguns exemplos simples para ilustrar como as visões podem ser usadas para ocultar certos atributos ou tuplas de usuários não autorizados. Suponha que um determinado usuário só tenha permissão para ver informações de funcionários que trabalham para o departamento 5; então, podemos criar a seguinte visão FUNCDEP5 e conceder ao usuário o privilégio de consultá-la, mas não a tabela básica FUNCIONÁRIO. Esse usuário só poderá recuperar as infor­ mações dos funcionários para as tuplas de funcionários cujo Numero_departamento = 5, e não poderá ver outras tuplas de funcionários quando a visão for consultada.

CREATE VIEW SELECT FROM WHERE

FUNCDEP5

AS

FUNCIONÁRIO Numero.departamento = 5;

Da mesma forma, uma visão pode restringir um usuário a ver apenas certas colunas; por exemplo, apenas o primeiro nome, o último nome e o endereço de um funcionário podem ser vistos por meio desta visão:

CREATE VIEW SELECT FROM

DADOS_BASICOS_FUNC AS Primeiro.nome, Ultimo.nome, Endereço FUNCIONÁRIO;

Assim, aocriar uma visão apropriada e conceder acesso para certos usuários a ela, e não às tabelas básicas, eles podem ficar restritos a recuperarem apenas os dados especificados na visão. O Capítulo 30 discute segurança e autorização com mais detalhes, incluindo os comandos SQL GRANT e REVOKE.

7.4 Instruções de alteração de esquema em SQL Nesta seção, oferecemos uma visão geral dos comandos de evolução de esquema disponíveis em SQL, que podem ser usados para alterar um esquema, acrescentando ou removendo tabelas, atributos, restrições e outros elementos dele. Isso pode ser feito enquanto o banco de dados está operando e não exige recompilação do esquema. Certas verificações precisam ser feitas pelo SGBD para garantir que as mudanças não afetarão o restante do banco de dados, tornando-o inconsistente.

7.4.1 0 comando DROP O comando DROP pode ser usado para remover elementos nomeados do esquema, como tabelas, domínios, tipos ou restrições.Também é possível remover um esquema. Por exemplo, se todo um esquema não for mais necessário, o comando DROP SCHEMA pode ser utilizado. Existem duas opções de comportamento de drop: CASCADE e RESTRICT. Por exemplo, para remover o esquema de banco de dados

213

214 Sistemas de banco de dados EMPRESA e todas as suas tabelas, domínios e outros elementos, a opção CASCADE é usada da seguinte forma:

DROP SCHEMA EMPRESA CASCADE;

Se a opção RESTRICT for escolhida no lugar da CASCADE, o esquema é removido somente se ele não tiver elementos; caso contrário, o comando DROP não será execu­ tado. Para usar a opção RESTRICT, o usuário deve primeiro remover individualmente cada elemento no esquema e depois remover o próprio esquema. Se uma relação básica dentro de um esquema não for mais necessária, a relação e sua definição podem ser excluídas usando o comando DROP TABLE. Por exemplo, se não quisermos mais manter os dependentes dos funcionários no banco de dados EMPRESA da Figura 6.1, podemos descartar a relação DEPENDENTE emitindo o seguinte comando: DROP TABLE DEPENDENTE CASCADE;

Se a opção RESTRICT for escolhida em vez da CASCADE, uma tabela é removida somente se ela não for referenciada em quaisquer restrições (por exemplo, por definições de chave estrangeira em outra relação) ou visões (ver Seção 7.3), ou por quaisquer outros elementos. Com a opção CASCADE, todas essas restrições, visões e outros elementos que referenciam a tabela sendo removida também são excluídos automaticamente do esquema, junto com a própria tabela. Observe que o comando DROP TABLE não apenas exclui todos os registros na tabela se tiver sucesso, mas também remove a definição da tabela no catálogo. Se for desejado excluir apenas os registros, mas deixar a definição de tabela para uso futuro, o comando DELETE (ver Seção 6.4.2) deve ser usado no lugar de DROP TABLE. O comando DROP também pode ser empregado para descartar outros tipos de elementos de esquema nomeados, como restrições ou domínios.

7.4.2 0 comando ALTER A definição de uma tabela básica ou de outros elementos de esquema nomeados pode ser alterada usando o comando ALTER. Para as tabelas básicas, as possíveis ações de alteração de tabela incluem acrescentar ou remover uma coluna (atributo), alterar uma definição dc coluna c acrescentar ou remover restrições dc tabela. Por exemplo, para incluir um atributo que mantém as tarefas dos funcionários na relação básica FUNCIONÁRIO no esquema EMPRESA (ver Figura 6.1), podemos usar o comando ALTER TABLE EMPRESA.FUNCIONARIO ADD COLUMN Tarefa VARCHAR(12);

Ainda devemos inserir um valor para o novo atributo Tarefa para cada tupla individual de FUNCIONÁRIO. Isso pode ser feito especificando uma cláusula default ou usando o comando UPDATE individualmente sobre cada tupla (ver Seção 6.4.3). Se nenhuma cláusula default for especificada, o novo atributo receberá o valor NULL em todas as tuplas da relação imediatamente após o comando ser executado; logo, a restrição NOT NULL não é permitida nesse caso. Para remover uma coluna, temos de escolher CASCADE ou RESTRICT para o comportamento de remoção. Se CASCADE for escolhido, todas as restrições e visões que referenciam a coluna são removidas automaticamente do esquema, junto com a coluna. Se RESTRICT for escolhido, o comando só tem sucesso se nenhuma visão ou restrição (ou outro elemento do esquema) referenciar a coluna. Por exemplo, o comando a seguir remove o atributo Endereço da tabela básica FUNCIONÁRIO: ALTER TABLE EMPRESA.FUNCIONARIO DROP COLUMN Endereço CASCADE;

Capítulo 7

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Também é possível alterar uma definição de coluna removendo uma cláusula default existente ou definindo uma nova cláusula default. Os exemplos a seguir ilustram essa cláusula: ALTER TABLE EMPRESA.DEPARTAMENTO ALTER COLUMN Cpf.gerente DROP DEFAULT; ALTER TABLE EMPRESA.DEPARTAMENTO ALTER COLUMN Cpf_gerente SET DEFAULT 33344555587';

Também é possível alterar as restrições especificadas sobre uma tabela ao acres­ centar ou remover uma restrição nomeada. Para ser removida, uma restrição precisa ter recebido um nome quando foi especificada. Por exemplo, para descartar a restri­ ção chamada CHAVEETRFUNC_SUPERVISOR da Figura 6.2 da relação FUNCIONÁRIO, escrevemos: ALTER TABLE EMPRESA.FUNCIONARIO DROP CONSTRAINT CHAVEETRFUNC.SUPERVISOR CASCADE;

Quando isso é feito, podemos redefinir uma restrição substituída acrescentando uma nova restrição à relação, se necessário. Isso é especificado usando a palavra-chave ADD CONSTRAINT na instrução ALTER TABLE seguida pela nova restrição, que pode ser nomeada ou não, e pode ser de qualquer um dos tipos de restrição de tabela discutidos. As subseções anteriores deram uma visão geral dos comandos de evolução de esquema da SQL. Também é possível criar tabelas e visões em um esquema de banco de dados usando os comandos apropriados. Existem muitos outros detalhes e opções; o leitor interessado deverá consultar os documentos sobre SQL listados na Bibliografia selecionada, ao final deste capítulo.

7.5 Resumo Neste capítulo, apresentamos recursos adicionais da linguagem de banco de dados SQL. Começamos na Seção 7.1, apresentando recursos mais complexos das consultas de recuperação SQL, incluindo consultas aninhadas, tabelas de junção, junções externas, funções agregadas e agrupamento. Na Seção 7.2, descrevemos o comando CREATE ASSERTION, que permite a especificação de restrições mais gerais sobre o banco de dados, e apresentamos o conceito de gatilhos e o comando CREATE TRIGGER. Depois, na Seção 7.3, descrevemos a facilidade da SQL para definir visões no banco de dados. As visões também são chamadas de tabelas virtuais ou derivadas, pois apresentam ao usuário o que parecem scr tabelas; no entanto, as informações nessas tabelas são derivadas de outras tabelas, definidas anteriormente. A Seção 7.4 introduziu o comando SQL ALTER TABLE, que é usado para modificar as tabelas e restrições do banco de dados. A Tabela 7.2 resume a sintaxe (ou estrutura) de diversos comandos SQL. Esse resumo não é abrangente, nem descreve cada construção SQL possível; em vez disso, ele serve como uma referência rápida para os principais tipos de construções dispo­ níveis em SQL. Usamos a notação BNF, em que os símbolos não terminais aparecem entre sinais de , as partes opcionais aparecem entre colchetes [...], as repetições aparecem entre chaves (...) e as alternativas aparecem entre parênteses (... I... I ...).7

A sintaxe completa da SQL é descrita em muitos documentos volumosos, com centenas de páginas.

215

216 Sistemas de banco de dados Tabela 7.2 Resumo da sintaxe da SQL.

CREATE TABLE (cnome coluna> [ crestrição atributo> ] {, [ crestrição atributo> ]}

[ crestrição tabela> {, crestrição tabela>) ]) DROP TABLE cnome tabela>

ALTER TABLE cnome tabela> ADD cnome coluna> ctipo coluna> SELECT [ DISTINCT ] clista atributos>

FROM (cnome tabela> {capelido>} | ctabela de junção>) {, (cnome tabela> {capelido>} | ctabela de junção)}

[ WHERE ccondição> ] [ GROUP BY catributos agrupamento> [ HAVING ccondição seleção grupo> ]) [ ORDER BY cnome coluna> [ cordem> ] {, cnome coluna> [ cordem> ]} ] clista atributos> ::= ( * | ( cnome coluna> | cfunção> (([ DISTINCT ] cnome coluna> | * ))) {, (cnome coluna> | cfunção> (([ DISTINCT] cnome coluna> | * )))} )

catributos agrupamento ::= cnome coluna> {, cnome coluna>}

cordem> ::= (ASC | DESC ) INSERT INTO cnome tabela> [ (cnome coluna> {, cnome coluna>}) ]

(VALUES ( cvalor constante> , {cvalor constante>}) {, (cvalor constante> {, cvalor constante>})} | cinstrução seleção>) DELETE FROM cnome tabela> [ WHERE ccondição seleção> ]

UPDATE cnome tabela> SET cnome coluna> = c expressão valor> {, cnome coluna> = cexpressão valor>} I WHERE ccondição seleção> ]

CREATE [ UNIQUE] INDEX cnome índice> ON cnome tabela> (cnome coluna> [ cordem> ] {, cnome coluna> [ cordem> ]})

I CLUSTER ] DROP INDEX cnome índice>

CREATE VIEW cnome view> [ ( cnome coluna> {, cnome coluna>)) ] AS cinstrução seleção>

DROP VIEW cnome view> NOTA: os comandos para criar e exduir índices não fazem parte do padrão SQL

PERGUNTAS DE REVISÃO -------------------------------------------------------------------------

7.1.

Descreva as seis cláusulas na sintaxe dc uma consulta de recuperação SQL. Mostre que tipos de construções podem ser especificados em cada uma das seis cláusulas. Quais das seis cláusulas são obrigatórias e quais são opcionais? 7.2. Descreva conceitualmente como uma consulta de recuperação SQL será exe­ cutada, especificando a ordem conceituai dc execução dc cada uma das seis cláusulas. 7.3. Discuta como os NULLs são tratados nos operadores de comparação em SQL. Como os NULLs são tratados quando funções de agregação são aplicadas em uma consulta SQL? Como os NULLs são tratados quando existem nos atributos de agrupamento?

Capítulo 7

7.4.

Mais SQL: consultas complexas, triggers, views e modificação de esquema

Discuta como cada uma das seguintes construções é usada em SQL e quais sào as diversas opções para cada construção. Especifique a utilidade de cada construção. a. Consultas aninhadas. b. Tabelas de junção e junções externas. c. Funções de agregação e agrupamento. d. Gatilhos (Triggers). e. Asserções e como elas diferem dos gatilhos. f. A cláusula SQL WITH. g. construção SQL CASE. h. Visões e suas formas de atualização. i. Comandos de alteração de esquema.

EXERCÍCIOS -----------------------------------------------------------------------------------------------

7.5.

7.6.

7.7.

7.8.

Especifique as seguintes consultas no banco de dados da Figura 5.5 em SQL. Mostre os resultados da consulta se cada uma for aplicada ao banco de dados da Figura 5.6. a. Para cada departamento cujo salário médio do funcionário seja maior que RS 30.000,00, recupere o nome do departamento e o número de funcionários que trabalham nele. b. Suponha que queiramos o número de funcionários do sexo masculino cm cada departamento que ganhe mais dc RS 30.000,00, cm vez dc todos os funcionários (como no Exercício 7.5a). Podemos especificar essa consulta em SQL? Por quê? Especifique as seguintes consultas em SQL sobre o esquema de banco de dados da Figura 1.2. a. Recupere os nomes e cursos de todos os alunos com notas A (alunos que têm uma nota em todas as disciplinas). b. Recupere os nomes e cursos de todos os alunos que não têm uma nota A em qualquer uma das disciplinas. Em SQL, especifique as seguintes consultas sobre o banco de dados da Figura 5.5 usando o conceito de consultas aninhadas c conceitos descritos neste capítulo. a. Recupere os nomes de todos os funcionários que trabalham no departa­ mento que tem aquele com o maior salário entre todos os funcionários. b. Recupere os nomes de rodos os funcionários cujo supervisor do supervisor tenha como Cpf o número ‘88866555576’. c. Recupere os nomes dos funcionários que ganham pelo menos RS 10.000,00 a mais que o funcionário que recebe menos na empresa. Especifique as seguintes visões em SQL no esquema de banco de dados EMPRESA mostrado na Figura 5.5. a. Uma visão que tem o nome do departamento, o nome do gerente e o salário do gerente para cada departamento. b. Uma visão que tenha o nome do funcionário, o nome do supervisor e o salário de cada funcionário que trabalha no departamento ‘Pesquisa’. c. Uma visão que tenha o nome do projeto, o nome do departamento que o controla, o número de funcionários e o total de horas trabalhadas por semana em cada projeto.

217

218 Sistemas de banco de dados

d.

7.9.

Uma visão que tenha o nome do projeto, o nome do departamento que o controla, o número de funcionários e o total de horas trabalhadas por semana no projeto para cada projeto com mais de um funcionário tra­ balhando nele. Considere a seguinte visão, RESUMO.DEPARTAMENTO, definida sobre o banco de dados EMPRESA da Figura 5.6: CREATE VIEW AS SELECT FROM GROUP BY

RESUMO.DEPARTAMENTO (D, C, Total.sal, Media.sal) Numero.departamento, COUNT (*), SUM (Salario), AVG (Salario) FUNCIONÁRIO Numero.departamento;

Indique quais das seguintes consultas e atualizações seriam permitidas sobre a visão. Se uma consulta ou atualização for permitida, mostre como ficaria a consulta ou atualização correspondente nas relações básicas e seu resultado quando aplicado ao banco de dados da Figura 5.6. ★ a. SELECT FROM RESUMO.DEPARTAMENTO; b. SELECT D,C FROM RESUMO.DEPARTAMENTO WHERE TOTAL.SAL > 100000; c. SELECT D, MEDIA.SAL FROM RESUMO.DEPARTAMENTO WHERE C > ( SELECT C FROM RESUMO.DEPARTAMENTO WHERE D=4); d. UPDATE RESUMO.DEPARTAMENTO SET D=3 WHERE D = 4; e. DELETE FROM RESUMO. DEPARTAMENTO WHERE C>4;

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Reisner (1977) descreve uma avaliação dos fatores humanos da SEQUEL, pre­ cursora da SQL, em que descobriu que os usuários possuem alguma dificuldade para especificar corretamente as condições de junção e agrupamento. Date (1984) contém uma crítica da linguagem SQL que indica seus portos fortes e fracos. Date e Darwen (1993) descrevem a SQL2. ANSI (1986) esboça o padrão SQL original. Diversos manuais de fabricante descrevem as características da SQL implementadas em DB2, SQL/DS, Oracle, INGRES, Informix e outros produtos de SGBD comer­ ciais. Melton e Simon (1993) oferecem um tratamento abrangente do padrão ANSI 1992, chamado SQL2. Horowitz (1992) discute alguns dos problemas relacionados à integridade referencial e propagação das atualizações em SQL2. A questão dc atualizações de visão é abordada por Dayal e Bernstein (1978), Keller (1982) e Langerak (1990), entre outros. A implementação de visão é discu­ tida em Blakeley et al. (1989). Negri et al. (1991) descrevem a semântica formal das consultas SQL. Existem muitos livros que descrevem vários aspectos da SQL. Por exemplo, duas referências que descrevem a SQL-99 são Melton e Simon (2002) e Melton (2003). Outros padrões SQL — SQL 2006 e SQL 2008 — são descritos cm diversos rela­ tórios técnicos, mas não existem rcferências-padrão.

Álgebra e cálculo relacionai este capítulo, discutimos as duas linguagens formais para o modelo relacio­ nai: a álgebra relacionai e o cálculo relacionai. Ao contrário, os capítulos 6 e 7 descreveram a linguagem prática para o modelo relacionai, a saber, o padrão SQL. Historicamente, a álgebra e o cálculo relacionai foram desenvolvidos antes da linguagem SQL. A SQL é baseada principalmente nos conceitos do cálculo relacionai, e também foi estendida para incorporar alguns conceitos da álgebra rela­ cionai. Como a maioria dos SGBDs relacionais utiliza a SQL como linguagem, nós a apresentamos primeiro. Lembre-se, do Capítulo 2, de que um modelo dc dados precisa incluir um conjunto de operações para manipular o banco de dados, além dos conceitos do modelo para definir a estrutura e as restrições do banco de dados. Apresentamos as estruturas e as restrições do modelo relacionai formal no Capítulo 5. O conjunto básico de operações para o modelo relacionai é a álgebra relacionai. Essas operações permitem que um usuário especifique as solicitações de recuperação básicas como expressões da álgebra relacionai. O resultado de uma recuperação é uma nova relação. Assim, as operações da álgebra produzem novas relações, que podem ser manipuladas ainda mais usando operações da mesma álgebra. Uma sequência de operações da álgebra relacionai forma uma expressão da álgebra relacionai, cujo resultado também será uma relação que representa o resultado de uma consulta de banco de dados (ou consulta dc recuperação). A álgebra relacionai é muito importante por diversos motivos. Primeiro, ela oferece um alicerce formal para as operações do modelo relacionai. Segundo, e tal­ vez mais importante, ela é usada como base para a implementação e otimização de consultas nos módulos de otimização e processamento de consulta, que são partes integrais dos sistemas de gerenciamento de banco de dados relacionai (SGBDRs), conforme discutiremos nos capítulos 18 e 19. Terceiro, alguns de seus conceitos são incorporados na linguagem de consulta padrão SQL para SGBDRs. Embora a maioria

N

220 Sistemas de banco de dados

dos SGBDRs comerciais em uso hoje não ofereça interfaces de usuário para consultas da álgebra relacionai, as operações e as funções essenciais nos módulos internos da maioria dos sistemas relacionais sào baseadas nas operações da álgebra relacionai. Definiremos essas operações com detalhes nas seções 8.1 a 8.4 deste capítulo. Embora a álgebra defina um conjunto de operações para o modelo relacionai, o cálculo relacionai oferece uma linguagem declaratiua de nível mais alto para especifi­ car consultas relacionais. Em uma expressão do cálculo relacionai, não existe ordem de operações para especificar como recuperar o resultado da consulta — somente qual informação o resultado deve conter. Esse é o principal fator de distinção entre a álgebra relacionai e o cálculo relacionai. O cálculo relacionai é importante porque tem uma firme base na lógica matemática e porque a linguagem de consulta padrão (SQL) para SGBDRs tem alguns de seus alicerces em uma variação do cálculo rela­ cionai conhecida como cálculo relacionai de tupla.1 álgebra relacionai normalmente é considerada uma parte integral do modelo de dados relacionai. Suas operações podem ser divididas em dois grupos. Um grupo inclui operações de conjunto da teoria matemática de conjuntos; estas são aplicáveis porque cada relação é definida como um conjunto de tuplas no modelo relacionai formal (ver Seção 5.1). As operações de conjunto incluem UNIÃO, INTERSEÇÃO, DIFERENÇA DE CONJUNTO e PRODUTO CARTESIANO (também conhecida como PRODUTO CRUZADO). O outro grupo consiste em operações desenvolvidas especifi­ camente para bancos de dados relacionais — entre elas estão SELEÇÃO, PROJEÇÃO e JUNÇÃO,entre outras. Primeiro, vamos descrever as operações SELEÇÃO e PROJEÇÃO na Seção 8.1, pois elas são operações unárias que ocorrem sobre uma única relação. Depois, discutimos as operações de conjunto na Seção 8.2. Na Seção 8.3, discutimos JUNÇÃO e outras operações binárias complexas, que operam sobre duas tabelas com­ binando tuplas relacionadas (registros) baseadas em condições de junção. O banco de dados relacionai EMPRESA, mostrado na Figura 5.6, é usado para nossos exemplos. Algumas solicitações de banco de dados comuns não podem ser realizadas com as operações originais da álgebra relacionai, de modo que operações adicionais foram criadas para expressá-las. Estas incluem funções de agregação, que são operações que podem resumir dados das tabelas, bem como tipos adicionais de operações JUNÇÃO e UNIÃO, conhecidas como JUNÇÃO EXTERNA e UNIÃO EXTERNA. Essas operações, que foram acrescentadas ã álgebra relacionai cm razão de sua importância para muitas aplicações de banco de dados, são descritas na Seção 8.4. Oferecemos exemplos da especificação de consultas que usam operações relacionais na Seção 8.5. Algumas dessas mesmas consultas foram utilizadas nos capítulos 6 e 7. Ao usar os mesmos números de consulta neste capítulo, o leitor poderá comparar como as mesmas con­ sultas são escritas nas diversas linguagens de consulta. Nas seções 8.6 e 8.7, descrevemos a outra linguagem formal principal para bancos de dados relacionais: o cálculo relacionai. Existem duas variações do cál­ culo relacionai. O cálculo relacionai de tupla é descrito na Seção 8.6, e o cálculo relacionai de domínio, na Seção 8.7. Algumas das construções SQL discutidas nos capítulos 6 e 7 são baseadas no cálculo relacionai de tupla. O cálculo relacionai é uma linguagem formal, fundamentada no ramo da lógica matemática chamado de cálculo de predicado.2 No cálculo relacionai de tupla, variáveis estendem-se por tuplas, enquanto no cálculo relacionai de domínio, variáveis estendem-se por domínios (valores) de atributos. No Apêndice C, oferecemos uma visão geral da

1 A SQL se baseia no cálculo relacionai de rupia, mas rambém incorpora algumas das operações da álgebra relacionai e suas extensões, conforme ilustrado nos capítulos 6, 7 e 9. 2 Neste capítulo, nào supusemos que você tenha qualquer familiaridade com o cálculo de predicado de primeira ordem — que lida com variáveis e valores quantificados.

Capítulo 8 Álgebra e cálculo relacionai linguagem Query-By-Example (QBE), que é uma linguagem relacionai gráfica de uso facilitado, com base no cálculo relacionai de domínio. A Seção 8.8 contém um resumo do capítulo. Para o leitor interessado em uma introdução menos detalhada às linguagens relacionais formais, as seções 8.4, 8.6 e 8.7 podem ser puladas.

8.1 Operações relacionais unárias: SELEÇÃO e PROJEÇÃO 8.1.1 A operação SELEÇÃO A operação SELEÇÃO é usada para escolher um subconjunto das tuplas de uma relação que satisfaça uma condição dc seleção.3 Pode-se considerar que a operação SELEÇÃO seja um filtro que mantem apenas as tuplas que satisfazem uma condição qualificadora. Como alternativa, podemos considerar que essa operação restringe as tuplas em uma relação para apenas aquelas que satisfazem a condição. A operação SELEÇÃO também pode ser visualizada como uma partição horizontal da relação em dois conjuntos de tuplas — aquelas que satisfazem a condição e são seleciona­ das e aquelas que não satisfazem a condição e são descartadas. Por exemplo, para selecionar a tupla FUNCIONÁRIO cujo departamento é 4, ou aquelas cujo salário é maior que RS 30.000,00, podemos especificar individualmente cada uma dessas duas condições com uma operação SELEÇÃO da seguinte maneira: ^^.oep^amen-^tFUNCIONARIO)

a^^FUNCIONARIO)

Em geral, a operação SELEÇÃO é indicada por ^concição de sdeção>^

em que o símbolo a (sigma) é usado para indicar o operador SELEÇÃO e a condi­ ção de seleção é uma expressão booleana (condição) especificada nos atributos da relação R. Observe que R costuma ser uma expressão da álgebra relacionai cujo resultado é uma relação — a mais simples expressão desse tipo é apenas o nome dc uma relação dc banco dc dados. A relação resultante da operação SELEÇÃO tem os mesmos atributos dc R. A expressão booleana especificada em «ccondição de seleção> é composta de uma série de cláusulas da forma ou «cnome atributo> «coperador de comparação> «cnome atributo> em que é o nome de um atributo de R, em geral é um dos operadores (=, , >, x) e «cvalor constante> é um valor cons­ tante do domínio do atributo. As cláusulas podem ser conectadas pelos operadores booleanos padrão and, or c not para formar uma condição dc seleção geral. Por exemplo, para selecionar as tuplas para todos os funcionários que ou trabalham no departamento 4 e ganham mais de RS 25.000,00 por ano, ou trabalham no departamento 5 e ganham mais de RS 30.000,00, podemos especificar a seguinte operação SELEÇÃO: aiNumero_0€paftaniena>=4 AND Saiana>2500Q OR iNumero_Oepaftafnento«5 AND Satena>3000o/FUNC IONARIO)

3 A operaçào SELEÇÃO é diferente da cláusula SELECT da SQL. A operação SELEÇÃO escolhe tu pias de uma tabela, e às vezes é chamada de operação RESTRINGIR ou FILTRAR

221

222 Sistemas de banco de dados O resultado é mostrado na Figura 8.1(a). Observe que todos os operadores de comparação no conjunto {=, , podem ser aplicados aos atributos cujos domínios são valores ordenados, como domínios numéricos ou de data. Os domínios de cadeias de caracteres também são considerados ordenados com base na ordem alfabética dos caracteres. Se o domínio de um atributo for um conjunto de valores desordenados, somente os operadores de comparação no conjunto (=, *} podem ser usados. Um exemplo de domínio desorde­ nado é o domínio Cor = {‘vermelho',‘azul’,‘verde’,‘branco',‘amarelo',...), em que nenhuma ordem é especificada entre as diversas cores. Alguns domínios permitem tipos adicionais de operadores de comparação; por exemplo, um domínio de cadeias de caracteres pode permitir o operador de comparação SUBSTRING_OF. Em geral, o resultado de uma operação SELEÇÃO pode ser determinado da forma mostrada a seguir. A é aplicada independentemente para cada tupla individual t em R. Isso é feito substituindo cada ocorrência de um atributo A( na condição de seleção por seu valor na tupla 4AJ. Se a condição for avaliada como TRUE, então a tupla t é selecionada. Todas as tuplas selecionadas aparecem no resultado da operação SELEÇÃO. As condições booleanas AND, OR e NOT têm sua interpretação normal, da seguinte forma: ■ (condi AND cond2) é TRUE se (condi) e (condi) forem TRUE; caso contrário, é FALSE. ■ (condi OR condi) é TRUE se (condi) ou (condi) ou ambas forem TRUE; caso contrário, é FALSE. ■ (NOT cond) é TRUE se cond é FALSE; caso contrário, é FALSE.

!a) Primeiro- Nome_ Ultimo_

Data_

Çfií

nome

meio

nome

Fernando

T

Wong

33344555587

08-12-1955

Jennifer

S

Souza

98765432168

20-06-1941

Ronaldo

K

Lima

66688444476

15-09-1962

nascimento

Endereço

Rua da Lapa, 34, São Paulo, SP Av. Arthur de Uma,

54, Santo André, SP

Rua Rebouças, 65, Piracicaba, SP

Numero_

Sexo

Salario

Cpf_supervisor

M

40000

88866555576

5

F

43000

88866555576

4

M

38000

33344555587

5

departamento

:o

(b)

Ultimo nome

Primeiro nome

Salario

Sexo

Salario

Silva

João

30000

M

30000

Wong

Fernando

40000

M

40000

Zelaya

Alice

25000

F

25000

Souza

Jennifer

43000

F

43000

Lima

Ronaldo

38000

M

38000

Leite

Joice

25000

M

25000

Pereira

André

25000

M

55000

Brito

Jorge

55000

Figura 8.1

Resultados das operações SELEÇÃO e PROJEÇÃO, (a) me. ^(FUNCIONÁRIO). (c)

^(FUNCIONÁRIO).

Capítulo 8 Álgebra e cálculo relacionai O operador SELEÇÃO é unário; ou seja, ele é aplicado a uma única relação. Além disso, a operação de seleção é aplicada a cada tupla individualmente; logo, as condi­ ções de seleção não podem envolver mais de uma tupla. O grau da relação resultante de uma operação SELEÇÃO — seu número de atributos — é o mesmo que o grau de R. O número de tuplas na relação resultante é sempre menor ou igual ao número de tuplas em R. Ou seja, l25C00 (FUNCIONÁRIO)

correspondería à seguinte consulta SQL:

SELECT FROM WHERE

FUNCIONÁRIO Numero_departamento=4 AND Salario>25000;

8.1.2 A operação PROJEÇÃO Se pensarmos em uma relação como uma tabela, a operação SELEÇÃO escolhe algumas das linhas da tabela enquanto descarta outras. A operação PROJEÇÃO, por sua vez, seleciona certas colunas da tabela e descarta as outras. Se estivermos inte­ ressados apenas em certos atributos de uma relação, usamos a operação PROJEÇÃO para projetara relação apenas por esses atributos. Portanto, o resultado da operação PROJEÇÃO pode ser visualizado como uma partição vertical da relação cm duas rela­ ções: uma tem as colunas (atributos) necessárias e contém o resultado da operação, e a outra contém as colunas descartadas. Por exemplo, para listar último nome, primeiro nome e salário de cada funcionário, podemos usar a operação PROJEÇÃO da seguinte forma: ‘Rjfomo.nome. Pr^ro-^Sa^íFUNCIONARIO)

A relação resultante aparece na Figura 8.1(b). A forma geral da operação PROJEÇÃO é n^

em que n (pi) é o símbolo usado para representar a operação PROJEÇÃO, e dista de atributos> é a sublista desejada de atributos da relação R. Mais uma vez, observe que R, em geral, é uma expressão da álgebra relacionai cujo resultado é uma relação, que no caso mais simples é apenas o nome de uma relação do banco de dados. O resultado da operação PROJEÇÃO tem apenas os atributos especificados em dista de atributos> na mesma ordem em que eles aparecem na lista. Logo, seu grau é igual ao número de atributos em disra de atriburos>. Se a lista de atributos inclui apenas atributos não chave de R, provavelmente haverá tuplas duplicadas. A operação PROJEÇÃO remove quaisquer tuplas duplicadas, dc modo que o resultado dessa operação é um conjunto dc tuplas distintas, e.

223

224 Sistemas de banco de dados

portanto, uma relação válida. Isso é conhecido como eliminação de duplicatas. Por exemplo, considere a seguinte operação PROJEÇÃO: nse.o.saUFUNCIONARIO)

O resultado é mostrado na Figura 8.1(c). Observe que a tupla só aparece uma vez na Figura 8.1(c), embora essa combinação de valores apareça duas vezes na relação FUNCIONÁRIO. A eliminação de duplicatas envolve a classificação ou alguma outra técnica para detectar duplicatas e, portanto, aumenta o processamento. Se as duplicaras não fossem eliminadas, o resultado seria um multiconjunto ou bag de tuplas, em vez de um conjunto. Isso não era permitido no modelo relacionai formal, mas pode ocorrer na SQL (ver Seção 6.3). O número de tuplas em uma relação resultante dc uma operação PROJEÇÃO é sempre menor ou igual ao número de tuplas em R. Se a lista de atributos da projeção é uma superchave de R — ou seja, inclui alguma chave de R —, a relação resultante tem o mesmo número de tuplas que R. Além disso, "«fetal» ("W) = >», * ) e xt e x- são variáveis de domínio. 3. Um átomo da forma x- op c ou c op x^ em que op é um dos operadores de com­ paração no conjunto {=, , * J, xt e xf são variáveis dc domínio, c c é um valor constante. Assim como no cálculo de tupla, os átomos são avaliados como TRUE ou FALSE para um conjunto de valores específico, chamados valores verdade dos átomos. No caso 1, se as variáveis dc domínio receberem valores correspondentes a uma tupla da relação especificada R, o átomo c TRUE. Nos casos 2 e 3, se as variáveis dc domínio receberem valores que satisfazem a condição, então o átomo é TRUE.

Capítulo 8 Álgebra e cálculo relacionai De forma semelhante ao cálculo relacionai de tupla, as fórmulas sào compostas de átomos, variáveis e quantificadores, dc modo que não repetiremos as especificações de fórmulas aqui. A seguir, apresentamos alguns exemplos de consultas especifica­ das no cálculo de domínio. Usaremos as letras minúsculas /, m, w,..., x, y, z para as variáveis de domínio.

Consulta 0. Listar a data de nascimento e o endereço do funcionário cujo nome é ‘João B. Silva’. CO: (w, v I (Bq) (3r) (3s) (3/) (3u-) (3x) (3y) (3z) (FUNC IONARI O(qrstuvwxyz) AND ^='João’ AND r=‘B' AND s='Silva’)}

Precisamos dc dez variáveis para a relação FUNCIONÁRIO, uma para percorrer cada um dos domínios dos atributos de FUNCIONÁRIO em ordem. Das dez variáveis q, r,s,..., z, somente u e v são livres, pois aparecem à esquerda da barra e, portanto, não devem estar ligadas a um quantificador Primeiro, especificamos os atributos solicitados, Data_nascimento e Endereço, pelas variáveis de domínio livres u para DATA_NASCIMENTO e u para ENDEREÇO. Depois, especificamos a condição para sele­ cionar uma tupla após a barra (I) — a saber, que a sequência de valores atribuídos às variáveis qrstuvwxyz seja uma tupla da relação FUNCIONÁRIO e que os valores para q (Primeiro_nome), r (Nome.meio) e s (Ultimo_nome) sejam iguais a ‘João’, ‘B’ e ‘Silva’, respecri vam ente. Por conveniência, quantificaremos apenas as variáveis que realmente aparecem em uma condição (estas seriam q, r e s em CO) no restante dc nossos exemplos.1415 Uma notação abreviada alternativa, usada em QBE, para escrever essa consulta, é atribuir as constantes ‘João’, ‘B’ e ‘Silva’ diretamente como mostramos em COA. Aqui, todas as variáveis que não aparecem à esquerda da barra são implicitamente quantificadas dc maneira existencial:1' COA: {u, v | FUNC IONARIO(‘João’, ‘B’, ‘Silva’, t, u, v, w, x, y, z))

Consulta 1. Recuperar o nome e o endereço de rodos os funcionários que traba­ lham para o departamento ‘Pesquisa’. Cl: {q, s, v I (3z) (3/) (3m) (FUNCIONARIO(^rsZ«Fuzxyz) AND DE PARTAM ENTO(Zmwo) AND /=‘Pesquisa’ AND m=z)\

Uma condição relacionando duas variáveis de domínio que percorra os atribu­ tos de duas relações, como m = z em Cl, é uma condição dc junção, ao passo que uma condição que relaciona uma variável de domínio a uma constante, como / = ‘Pesquisa’, c uma condição dc seleção.

Consulta 2. Para cada projeto localizado em ‘Mauá’, listar o número do projeto, o número do departamento de controle e o último nome, a data de nascimento e o endereço do gerente do departamento. C2: (/, k, s, u, v | (3zX3w)(3n)(3r)(PROJETO(Z7//^) AND FUNCIONARIO(^rsrm/trxyz) AND DEPARTAMENTO(Zwno) AND n=t AND ;=‘Mauá’)|

AND

Consulta 6. Listar os nomes dos funcionários que não têm dependentes. C6: [q. s I (3tXFUNCIONARIO(qrstuvwxyz) AND (NOT(3/)(DEPENDENTE(/mnop) AND T=/)))}

14 Observe que a notação de quantificar apenas as variáveis de domínio realmente usadas nas condi­ ções e de mostrar um predicado como FUNCIONÁRIO (qrstiaivxyz), sem separar as variáveis de domí­ nio com vírgulas, c uma notação abreviada, utilizada por conveniência; essa não é a notação formal correta. 15 Mais uma vez, esta nào é uma notação formalmente precisa.

255

256 Sistemas de banco de dados

C6 pode ser reformulada usando quantificadores universais no lugar dos quan­ tificadores existenciais, como mostramos em C6A: C6A: {q, s | (3r)(FUNCIONARIO(^rsh/p^xy?) AND ((V/XNOT(DEPENDENTE(/w«op)) OR NOT(r=/))))}

Consulta 7. Listar os nomes dos gerentes que têm pelo menos um dependente. C7: {$, q I (3í)(3/)(3/XFUNCIONARIO(^rsíMtwxyz) AND DEPARTAMENTO^// *) AND DEPENDENTE(Zwnop) AND í=/ AND l=t)}

Como dissemos anteriormente, pode-se mostrar que qualquer consulta que pode ser expressa na álgebra relacionai básica também pode ser expressa no cálculo rela­ cionai de domínio ou de tupla. Além disso, qualquer expressão segura no cálculo relacionai de domínio ou de tupla pode ser expressa na álgebra relacionai básica. A linguagem QBE foi baseada no cálculo relacionai de domínio, embora isso fosse observado mais tarde, depois que o cálculo de domínio foi formalizado. A QBE foi uma das primeiras linguagens de consulta gráficas com sintaxe mínima desen­ volvidas para sistemas de banco de dados. Ela foi desenvolvida na IBM Research e está disponível como um produto comercial da empresa como parte da opção de interface Query Management Facility (QMF) para DB2. As idéias básicas usadas na QBE têm sido aplicadas em vários outros produtos comerciais. Em virtude de seu lugar importante na história das linguagens relacionais, incluímos uma visão geral da QBE no Apêndice C.

8.8 Resumo Neste capítulo, apresentamos duas linguagens formais para o modelo de dados relacionai. Elas são usadas para manipular relações e produzir novas relações como respostas às consultas. Discutimos a álgebra relacionai c suas operações, que sào usadas para especificar uma sequência de operações para determinar uma consulta. Depois, apresentamos dois tipos de cálculos relacionais, chamados cálculo de tupla e cálculo de domínio. Nas seções 8.1 a 8.3, apresentamos as operações básicas da álgebra relacionai e ilustramos os tipos de consultas para as quais cada uma é usada. Primeiro, discuti­ mos os operadores relacionais unários SELEÇÃO e PROJEÇÃO, bem como a operação RENOMEAR. Depois, discutimos as operações teóricas do conjunto binário exigindo que as relações sobre as quais são aplicadas sejam compatíveis na união (ou tipo); estas incluem UNIÃO, INTERSEÇÃO e DIFERENÇA DE CONJUNTO. A operação PRODUTO CARTESIANO é uma operação de conjunto que pode ser usada para combinar tuplas de duas relações, produzindo todas as combinações possíveis. Eia raramente é usada na prática. Porém, mostramos como o PRODUTO CARTESIANO seguido por SELEÇÃO pode ser usado para definir tuplas combinadas de duas relações e levar à operação JUNÇÃO. Diferentes operações JUNÇÃO, chamadas JUNÇÃO THETA, EQUIJUNÇÃO e JUNÇÃO NATURAL, foram apresentadas. Arvores de consulta foram apresentadas como uma representação gráfica das consultas da álgebra relacionai, as quais tam­ bém podem ser usadas como base para estruturas de dados internas, que o SGBD pode utilizar para representar uma consulta. Discutimos alguns tipos importantes de consultas que não podem ser declarados com as operações básicas da álgebra relacionai, mas são importantes para situações práticas. Apresentamos a PROJEÇÃO GENERALIZADA para usar funções de atributos na lista de projeção e a operação FUNÇÃO DE AGREGAÇÃO para lidar com tipos de agregação das solicitações estatísticas, que resumem as informações nas tabelas. Discutimos sobre as consultas recursivas, para as quais não existe suporte direto na

Capítulo 8 Álgebra e cálculo relacionai álgebra, mas que podem ser tratadas em uma abordagem passo a passo, conforme demonstramos. Depois, apresentamos as operações JUNÇÃO EXTERNA e UNIÃO EXTERNA, que estendem as operações de JUNÇÃO e UNIÃO e permitem que todas as informações nas relações de origem sejam preservadas no resultado. As duas últimas seções descreveram os conceitos básicos por trás do cálculo rela­ cionai, que é baseado no ramo da lógica matemática chamado cálculo de predicado. Existem dois tipos dc cálculos relacionais: (1) o cálculo relacionai de tupla, que usa variáveis de tupla que percorrem as tuplas (linhas) das relações e (2) o cálculo rela­ cionai de domínio, que usa variáveis de domínio que percorrem os domínios (colu­ nas das relações). No cálculo relacionai, uma consulta é especificada em um único comando declarative, sem determinar qualquer ordem ou método para recuperar o resultado da consulta. Logo, o cálculo relacionai normalmente é considerado como uma linguagem declarativa de nível mais alto que a álgebra relacionai, pois uma expressão do cálculo relacionai declara o que queremos recuperar, independente­ mente de como a consulta pode ser executada. Apresentamos os grafos de consulta como uma representação interna para as consultas no cálculo relacionai. Também discutimos o quantificador existencial (3) e o quantificador universal (V). Discutimos o problema de especificar consultas seguras, cujos resultados são finitos. Também discutimos regras para transformar quantificadores universais em existenciais e vice-versa. São os quantificadores que dão poder expressivo ao cálculo relacionai, tornando-o equivalente à álgebra rela­ cionai básica. Não existe algo semelhante para funções de agrupamento e agregação no cálculo relacionai básico, embora algumas extensões tenham sido sugeridas.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

8.1. 8.2.

8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 8.11. 8.12. 8.13. 8.14.

Liste as operações da álgebra relacionai e a finalidade de cada uma. O que é compatibilidade na união? Por que as operações UNIÃO, INTERSEÇÃO e DIFERENÇA exigem que as relações sobre as quais são aplicadas sejam com­ patíveis na união? Discuta alguns tipos de consultas para as quais a renomeação de atributos é necessária para especificar a consulta de forma não ambígua. Discuta os vários tipos de operações de junção interna. Por que a junção theta é exigida? Que papel é desempenhado pela chave estrangeira ao especificar os tipos mais comuns de operações de junção significativas? O que é a operação de FUNÇÃO? Para que é usada? Como as operações JUNÇÃO EXTERNA diferem das operações JUNÇÃO INTERNA? Como a operação UNIÃO EXTERNA é diferente dc UNIÃO? Em que sentido o cálculo relacionai difere da álgebra relacionai, e em que sentido eles são semelhantes? Como o cálculo relacionai de tupla difere do cálculo relacionai de domínio? Discuta os significados do quantificador existencial (3) e do quantificador universal (V). Defina os seguintes termos com relação ao cálculo de tupla: variável de tupla, relação de intervalo, átomo, fórmula e expressão. Defina os seguintes termos com relação ao cálculo de domínio: variável de domínio, relação de intervalo, átomo, fórmula e expressão. O que significa uma expressão segura no cálculo relacionai? Quando uma linguagem de consulta é chamada de relaciona Imente completa?

257

258 Sistemas de banco de dados EXERCÍCIOS ----------------------------------------------------------------------------------------------8.15. Mostre o resultado de cada um dos exemplos dc consulta na Scçâo 8.5 se fosse aplicado ao estado do banco de dados da Figura 5.6. 8.16. Especifique as seguintes consultas no esquema de banco de dados relacionai EMPRESA mostrado na Figura 5.5, usando os operadores relacionais discutidos neste capítulo. Mostre também o resultado de cada consulta se fosse aplicada ao estado dc banco dc dados da Figura 5.6. a. Recupere o nome dc todos os funcionários no departamento 5 que traba­ lham mais de 10 horas por semana no projeto ProdutoX. b. Liste o nome de todos os funcionários que têm um dependente com o primeiro nome igual ao seu. c. Liste o nome de todos os funcionários que sào supervisionados diretamente por ‘Fernando Wong'. d. Para cada projeto, liste o nome do projeto e o total de horas por semana gastas nesse projeto por todos os funcionários. e. Recupere o nome de todos os funcionários que trabalham em cada projeto. f. Recupere o nome de todos os funcionários que nào trabalham em projeto algum. g. Para cada departamento, recupere o nome do departamento e o salário médio de rodos os seus funcionários. h. Recupere o salário médio de todas as funcionárias. i. Encontre nome e endereço dc todos os funcionários que trabalham cm pelo menos um projeto localizado cm São Paulo, mas cujo depanamento não está localizado lá. j. Liste o último nome de todos os gerentes de departamento que não pos­ suem dependentes. 8.17. Considere o esquema de banco de dados relacionai COMPANHIA.AEREA mostrado na Figura 5.8, descrito no Exercício 5.12. Especifique as seguintes consultas em álgebra relacionai: a. Para cada voo, liste o número do voo, o aeroporto de partida para o pri­ meiro trecho e o aeroporto de chegada para o último trecho. b. Liste os números de voo e dias da semana de todos os voos ou de seus trechos que saem do Aeroporto Internacional dc Guarulhos, em São Paulo (código de aeroporto ‘GRU’) e chegam ao Aeroporto Internacional Salgado Filho, em Porto Alegre (código de aeroporto TOA’). c. Liste o número do voo, o código do aeroporto de partida, a hora de par­ tida programada, o código do aeroporto de chegada, a hora de chegada programada e os dias da semana de todos os voos ou trechos que saem de algum aeroporto na cidade de São Paulo e chegam a algum aeroporto na cidade de Porto Alegre. d. Liste rodas as informações de tarifa para o voo número ‘CO 197 .* e. Recupere o número de assentos disponíveis para o voo número ‘CO197 em‘09-10-2018’. 8.18. Considere o esquema de banco de dados relacionai BIBLIOTECA mostrado na Figura 8.14, que é usado para registrar livros, usuários e empréstimos de livro. As restrições de integridade referencial aparecem como arcos diretos na Figura 8.14, como na notação da Figura 5.7. Escreva as expressões relacionais para as seguintes consultas: a. Quantas cópias do livro intitulado A tribo perdida existem na unidade da biblioteca cujo nome é ‘Central’?

Capítulo 8

Álgebra e cálculo relacionai

LIVRO

Figura 8.14 Um esquema de banco de dados relacionai para um banco de dados BIBLIOTECA.

b.

Quantas cópias do livro intitulado A tribo perdida existem em cada uni­ dade da biblioteca? c. Recupere o nome de todos os usuários que nào possuem livros empres­ tados em seu nome. d. Para cada livro que é emprestado da unidade Central e cuja Data_devolucao é hoje, recupere o título do livro, o nome e o endereço do usuário. e. Para cada unidade da biblioteca, recupere o nome da unidade e o número total dc livros retirados dc lá. f. Rccupcrc o nome, o endereço c o número de livros emprestados para todos os usuários que possuem mais de cinco livros emprestados. g. Para cada livro cujo autor (ou coautor) é Stephen King, recupere o título e o número dc cópias pertencentes à unidade da biblioteca cujo nome c Central. 8.19. Especifique as seguintes consultas na álgebra relacionai sobre o esquema de banco de dados mostrado no Exercício 5.14: a. Liste Num_Pedido e Data_envio para todos os pedidos enviados do Num_ deposito com número 2. b. Liste a informação do DEPOSITO do qual o CLIENTE chamado Jose Lopez recebeu seus pedidos. Produza uma listagem: Num_pedido, Num_deposito. c. Produza uma listagem com Nome_cliente, Quant.pedido, Media_valor_ pedido, em que a coluna do meio seja o número total de pedidos feitos pelo cliente e a última coluna seja o valor médio do pedido para esse cliente.

259

260 Sistemas de banco de dados

d. e.

Liste os pedidos que foram entregues em até 30 dias após sua solicitação. Liste o Num_pedido para os pedidos entregues de todos os depósitos que a empresa tem em Curitiba.

8.20. Especifique as seguintes consultas em álgebra relacionai sobre o esquema de banco de dados mostrado no Exercício 5.15: a. De os detalhes (todos os atributos da relação dc viagem) para as viagens que excederam RS 2.000,00 nas despesas. b. Imprima o Cpf dos vendedores que realizaram viagens para Pernambuco. c. Imprima o total de despesas de viagem contraídas pelo vendedor com CPF = ‘23456789011’. 8.21. Especifique as seguintes consultas na álgebra relacionai sobre o esquema de banco de dados dado no Exercício 5.16: a. Liste o número de cursos realizados por todos os alunos chamados ‘João Silva’ no segundo semestre de 2017 (ou seja, Semestre=17.2). b. Produza uma lista dos livros-texto (inclua Num.disciplina, Isbnjivro, Titulo, livro) para os cursos oferecidos pelo departamento ‘CC’ que usaram mais de dois livros. c. Liste qualquer departamento que tenha todos os livros adotados publi­ cados pela ‘Editora Pearson'. 8.22. Considere as duas tabelas 71 e T2 mostradas na Figura 8.15. Mostre os resultados das seguintes operações: a- Tí™ T'.p=tlaT1 b- T^-n.Q.Ti.BT1 C. / lx n.P = T2A 72 d. 7'lx tiq = T2B72 c. TI U 72 f. TI M (TI P = J2A and n.R = Tl-C 7^2 8.23. Especifique as seguintes consultas na álgebra relacionai sobre o esquema de banco de dados do Exercício 5.17: a. Para a vendedora chamada ‘Jane Dolores’, liste as seguintes informações para todos os carros que ela vendeu: Numero.chassi, Fabricante, Preco.venda. b. Liste o Numero.chassi e o Modelo dos carros que não possuem opcionais. c. Considere a operação JUNÇÃO NATURAL entre VENDEDOR e VENDA. Qual é o significado de uma junção externa esquerda para essas tabelas (não mude a ordem das relações)? Explique com um exemplo. d. Escreva uma consulta na álgebra relacionai envolvendo seleção e uma operação de conjunto e diga, em palavras, o que a consulta faz. 8.24. Especifique as consultas a, b,c, e, f,i e j do Exercício 8.16 no cálculo relacionai de tupla e de domínio. 8.25. Especifique as consultas a, b, c e d do Exercício 8.17 no cálculo relacionai de tupla e de domínio.

TABELA T2

TABELA T1 p

Q

R

A

B

C

10

a

5

10

b

6

15

b

8

25

c

3

25

a

6

10

b

5

Figura 8.15 Um estado do banco de dados para as relações T1 e T2.

Capítulo 8 Álgebra e cálculo relacionai 8.26. Especifique as consultas c, d e f do Exercício 8.18 no cálculo relacionai de tupla e de domínio. 8.27. Em uma consulta de cálculo relacionai de tupla com n variáveis de tupla, qual seria o número mínimo típico de condições de junção? Por quê? Qual é o efeito de ter um número menor de condições de junção? 8.28. Rccscreva as consultas do cálculo relacionai de domínio que seguiram CO na Seção 8.7 no estilo da notação abreviada de COA, em que o objetivo é mini­ mizar o número de variáveis de domínio escrevendo constantes no lugar de variáveis, sempre que possível. 8.29. Considere esta consulta: recupere o Cpf dos funcionários que trabalham pelo menos nos projetos cm que o funcionário com Cpf=12345678966 trabalha. Isso pode ser declarado como (FORALL p) (IF P THEN Q), em que ■ pé uma variável de tupla que percorre a relação PROJETO. ■ P = FUNCIONÁRIO com Cpf=12345678966 trabalha no PROJETO p. ■ Q = FUNCIONÁRIO f trabalha no PROJETO p.

Expresse a consulta no cálculo relacionai de tupla, usando as regras ■ (Vp)(P(p)) = NOTOp)(NOT(P(p))). ■ (IF PTHEN O) = iNOT(P) OR O).

8.30. Mostre como você pode especificar as seguintes operações da álgebra relacionai no cálculo relacionai de tupla e de domínio. a. (NOT (P(x)) AND (NOT (Q(x))) b. NOT (3x) (P(x)J =>Vx (NOT (P(x)) c. (3x)(P(x))=>Vx((P(x))

261

262 Sistemas de banco de dados EXERCÍCIOS DE LABORATÓRIO --------------------------------------------------------------8.34. Especifique e execute as seguintes consultas em álgebra relacionai (RA — Relational Algebra) usando o interpretador RA sobre o esquema de banco de dados EMPRESA da Figura 5.5. a. Liste o nome de todos os funcionários no departamento 5 que trabalham mais de 10 horas por semana no projeto ProdutoX. b. Liste o nome de todos os funcionários que têm um dependente com o primeiro nome igual ao dele. c. Liste o nome dos funcionários que são supervisionados diretamente por Fernando Wong. d. Liste o nome dos funcionários que trabalham em cada projeto. c. Liste o nome dos funcionários que não trabalham cm projeto algum. f. Liste o nome e o endereço dos funcionários que trabalham em pelo menos um projeto localizado em São Paulo, mas cujo departamento não está localizado lá. g. Liste o nome dos gerentes de departamento que não têm dependentes. 8.35. Considere o seguinte esquema relacionai PEDIDO_CORREIO descrevendo os dados para uma empresa de vendas por catálogo.

PECAS(Numero_peca, Nome.peca, Quantidade.disponivel, Preco, Nivel.peca) CLIENTES(Numero_diente, Nome_cliente, Rua, Cep, Telefone)

FUNCIONARIOS:Numero_fLrciQrario, Nome.fundonario, Cep, Data.contrato)

CEPS(Çeo, Cidade) PEDIDOS(Numero pedido, Numero.diente, Numero.funcionario, Recebimento, Envio)

DETALHES_PEDIDO(Numero_pedido, Numero.peca, Quantidade)

Quantidade.disponivel é autoexplicarivo: os outros nomes de atributo são relativamente autoexplicativos. Especifique e execute as seguintes con­ sultas usando o interpretador RA sobre o esquema de banco de dados PEDIDO.CORREIO. a. Recupere o nome das peças que custam menos de RS 20,00. b. Recupere o nome e a cidade dos funcionários que receberam pedidos de peças custando mais de RS 50,00. c. Recupere os pares de valores de número de cliente daqueles que moram no mesmo CEP. d. Recupere o nome dos clientes que pediram peças de funcionários que moram em Brasília. e. Recupere o nome dos clientes que pediram peças que custam menos de R$ 20,00. f. Recupere o nome de clientes que não fizeram nenhum pedido. g. Recupere o nome de clientes que fizeram exatamente dois pedidos. 8.36. Considere o seguinte esquema relacionai DIARIO.NOTAS descrevendo os dados para um diário de um professor em particular. (Nota: os atributos A, B, C e D dc DISCIPLINAS armazenam os limites das notas.)

CATALOG0(Numero_catalogo, Titulo.catalogo) ALUNOS(Cod_aluno, Primeiro.nome, Ultimo.nome, Nome.meio)

DISCIPLINAS(Periodo, Num.turma, Semestre, Numero.catalogo, A, B, C, D)

MATRICULA(Cod_aluno, Período, Num.turma)

Capítulo 8 Álgebra e cálculo relacionai Especifique e execute as seguintes consultas usando o interpretador RA sobre o esquema de banco de dados DIARIO_NOTAS. a. Recupere o nome dos alunos matriculados na disciplina de Autômato durante o primeiro semestre de 2018. b. Recupere os valores de Cod_aluno daqueles que se matricularam em CCc226 e CCc227. c. Recupere os valores dc Cod_aluno daqueles que se matricularam em CCc226 ou CCc227. d. Recupere o nome dos alunos que não se matricularam em nenhuma disciplina. e. Recupere o nome dos alunos que se matricularam em todas as disciplinas da tabela CATALOGO.

8.37. Considere um banco de dados que consiste nas relações a seguir: FORNECEDOR(Numero fornecedor, Nome_fornecedor)

PECA(Numero peca, Nome.peca)

PROJETOÍNumero oroieto, Nome.projeto) FORNECIMENTO(Numero fornecedor. Numero peca. Numero oroieto)

O banco de dados registra informações sobre fornecedores, peças e projetos, e inclui um relacionamento ternário entre fornecedores, peças e projetos. Este é um relacionamento muitos para muitos. Especifique e execute as seguintes consultas usando o interpretador RA. a. Recupere os números de peça fornecidos para exatamente dois projetos. b. Recupere o nome dos fornecedores que fornecem mais de duas peças ao projeto ‘PI’. c. Recupere os números de peça fornecidos por cada fornecedor. d. Recupere os nomes de projeto fornecidos apenas pelo fornecedor ‘Fl’. e. Recupere o nome de cada fornecedor que fornece pelo menos duas peças diferentes a pelo menos dois projetos diferentes. 8.38. Especifique e execute as seguintes consultas para o banco de dados do Exercício 5.16 usando o interpretador RA. a. Recupere o nome dos alunos que se matricularam em uma disciplina que usa um livro-texto publicado pela Editora Pearson. b. Recupere o nome das disciplinas em que o livro-texto foi mudado pelo menos uma vez. c. Recupere o nome dos departamentos que adotam somente livros-texto publicados pela Editora Pearson. d. Recupere o nome dos departamentos que adotam livros-texto escritos por Navathe e publicados pela Editora Pearson. e. Recupere o nome dos alunos que nunca usaram um livro (em uma disci­ plina) escrito por Navathe e publicado pela Editora Pearson. 8.39. Repita os Exercícios de Laboratório 8.34 a 8.38 no cálculo relacionai de domínio (DRC— Domain Relational Calculus} usando o interpretador DRC.

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Codd (1970) definiu a álgebra relacionai básica. Date (1983a) discute as junções externas. O trabalho sobre a extensão das operações relacionais é discutido por Carlis (1986) e Ozsoyoglu et al. (1985). Cammarata et al. (1989) estendem as restrições de integridade e junções do modelo relacionai.

263

264 Sistemas de banco de dados Codd (1971) introduziu a linguagem Alpha, que é baseada nos conceitos do cálculo relacionai de tupla. Alpha também inclui a noção de funções de agregação, que vai além do cálculo relacionai. A definição formal original do cálculo relacio­ nai foi dada por Codd (1972), que também forneceu um algoritmo que transforma qualquer expressão do cálculo relacionai de tupla em álgebra relacionai. A QUEL (Stonebraker et al., 1976) é baseada no cálculo relacionai de tupla, com quantifica­ dores existenciais implícitos, mas sem quantificadores universais, e foi implemen­ tada no sistema INGRES como uma linguagem disponível comercialmente. Codd definiu a totalidade relacionai de uma linguagem de consulta como pelo menos tão poderosa quanto o cálculo relacionai. Ullman (1988) descreve uma prova formal da equivalência da álgebra relacionai com expressões seguras de cálculo relacionai de tupla e domínio. Abitcboul et al. (1995) e Atzeni c deAntonellis (1993) fazem um tratamento detalhado das linguagens relacionais formais. Embora as idéias do cálculo relacionai de domínio tenham sido propostas inicial­ mente na linguagem QBE (Zloof, 1975), o conceito foi definido de maneira formal por Lacroix e Pirotte (1977a). A versão experimental do sistema Query-By-Example é descrita em Zloof (1975). A ILL (Lacroix e Pirotte, 1977b) é baseada no cálculo relacionai de domínio. Whang et al. (1990) estendem a QBE com quantificadores universais. As linguagens de consulta visuais, dentre as quais a QBE é um exemplo, estão sendo propostas como um meio de consultar bancos de dados. Conferências como a Visual Database Systems Working Conference [por exemplo, Arisawa e Catarei (2000) ou Zhou e Pu (2002)) apresentam uma série de propostas para tais linguagens.

Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai ste capítulo discute como projetar um esquema de banco de dados relacionai com base em um projeto de esquema conceituai. A Figura 3.1 apresentou uma visão de alto nível do processo de projeto de banco de dados, e neste capítulo focamos a etapa dc projeto lógico de banco dc dados, que tambcm c conhecido como mapeamento dc modelo dc dados. Apresentamos os procedimentos para criar um esquema relacionai com base em um esquema Entidade-Relacionamento (ER) ou ER estendido (EER). Nossa discussão relaciona as construções dos modelos ER e EER, apresentadas nos capítulos 3 e 4, às construções do modelo relacionai, apresentadas nos capítulos 5 a 8. Muitas ferramentas dc engenharia dc software auxiliada por computador (CASE) são baseadas nos modelos ER c EER, ou outros modelos semelhantes, conforme discutimos nos capítulos 3 e 4. Muitas ferramentas utilizam diagramas ER ou EER, ou suas variações, para desenvolver graficamente um esquema e coletar informações sobre os tipos de dados e restrições, e depois converter o esquema ER/EER de maneira automática em um esquema dc banco de dados relacionai na DDL dc um SGBD relacionai específico. As ferramentas de projeto empregam algoritmos semelhantes aos apresentados neste capítulo. Esboçamos um algoritmo dc sete etapas na Seção 9.1 para converter as cons­ truções básicas do modelo ER — tipos de entidade (forte e fraca), relacionamentos binários (com várias restrições estruturais), relacionamentos w-ários e atributos (simples, compostos c multivalorados) — em relações. Depois, na Seção 9.2, con­ tinuamos o algoritmo dc mapeamento ao descrever como mapear as construções do modelo EER — especialização/generalização e tipos de união (categorias) — em relações. z\ Seção 9.3 resume o capítulo.

E

266 Sistemas de banco de dados

9.1 Projeto de banco de dados relacionai usando o mapeamento ER para relacionai 9.1.1 Algoritmo de mapeamento ER para relacionai Nesta seção, vamos descrever as etapas de um algoritmo para mapeamento ER para relacionai. Usamos o exemplo de banco de dados EMPRESA para ilustrar o pro­ cedimento dc mapeamento. O esquema ER EMPRESA aparece novamente na Figura 9.1, e o esquema de banco de dados relacionai EMPRESA correspondente aparece na Figura 9.2 para ilustrar as etapas de mapeamento. Assumimos que o mapeamento criará tabelas com atributos simples de único valor. As restrições do modelo relacionai definidas no Capítulo 5, que incluem chaves primárias, chaves únicas (se houver) e restrições de integridade referencial sobre as relações, também serão especificadas nos resultados do mapeamento.

Etapa 1: Mapeamento de tipos de entidade regular. Para cada tipo de entidade regular (fone) E no esquema ER, crie uma relação R que inclua todos os atributos simples de E. Inclua apenas os atributos de componente simples de um atributo composto. Escolha um dos atributos-chave de E como chave primária para R. Se a chave escolhida de E for composta, o conjunto de atributos simples que a compõem formarão juntos a chave primária de R.

Jrimeiro

Nome

jata nascimento

Ttmo

nome

inmt wmf

Fnderpco

sa ano

sexo

,pt

oca izacoes IRABAIHA PARA

Numero

Nome

Data inicio

FUNCIONÁRIO

!KNumero_de_tuncionanos

DEPARTAMENTO

lQNTROI A doras

IKAbALHA

Supervisor

rKUJt IU

tM

jpervisionado SUPFRv S ONA.

Nome

N

□ trcINDcM Dc

DEPENDENTE

Figura 9.1 Diagrama do esquema conceituai ER para o banco de dados EMPRESA.

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai FUNCIONÁRIO

Figura 9.2 Resultado do mapeamento do esquema ER EMPRESA para um esquema de

banco de dados relacionai.

Se várias chaves fossem identificadas para E durante o projeto conceituai, a informação que descreve os atributos que formam cada chave adicional é mantida a fim de especificar chaves adicionais (únicas) da relação R. O conhecimento sobre as chaves também é mantido para fins de indexação e outros tipos de análises. Em nosso exemplo, criamos as relações FUNCIONÁRIO, DEPARTAMENTO e PROJETO na Figura 9.2 para corresponder aos tipos de entidade regular FUNCIONÁRIO, DEPARTAMENTO e PROJETO da Figura 9.1. Os atributos de chave estrangeira e rela­ cionamento, se houver, ainda não estão incluídos; eles serão acrescentados durante as etapas seguintes. Estes incluem os atributos Cpf_supervisor e Numero.departamento de FUNCIONÁRIO, Cpf.gerente e Data.inicio.gerente de DEPARTAMENTO, e Numero, departamento de PROJETO. Em nosso exemplo, escolhemos Cpf, Numero.departa­ mento e Numero.projeto como chaves primárias para as relações FUNCIONÁRIO, DEPARTAMENTO e PROJETO, respectivamente. O conhecimento dc que o Nome.departamento de DEPARTAMENTO e o Nome_projeto de PROJETO são chaves únicas é mantido para possível uso posterior no projeto. As relações criadas com base no mapeamento dos tipos de entidade às vezes são chamadas relações dc entidade, pois cada tupla representa uma instância de entidade. O resultado após essa etapa de mapeamento aparece na Figura 9.3(a).

Etapa 2: Mapeamento de tipos de entidade fraca. Para cada tipo dc entidade fraca F no esquema ER com tipo de entidade proprietária £, crie uma relação R e inclua todos os atributos simples (ou componentes simples dos atributos compostos) de F como atributos de R. Além disso, inclua como atributos de chave estrangeira de R os atributos de chave primária da(s) relação(ões) que correspondeim) aos tipos de entidade proprietária. Isso consegue mapear o tipo de relacionamento de identificação de F. A chave primária de R é a combinação das chaves primárias dos proprietários e a chave parcial do tipo de entidade fraca F, se houver. Se houver um

267

268

Sistemas de banco de dados (a) FUNCIONÁRIO Primeiro.nome

Nome.meio

Ultimo.nome

Çfií

Data.nasci mento

Endereço

Sexo

Salario

DEPARTAMENTO

Nome.departamento

Numero_departamento

PROJETO

Nome projeto

Numero projeto

Local-projeto

(b) DEPENDENTE

Cpf funcionário

Nome dependente

Sexo

Data nascimento

Parentesco

(c) TRABALHA.EM

Cpf.funcionario

Numero_projeto

Horas

(d) LOCA LIZACOES .DEPARTAMENTO

Numero.departamento

Local

Figura 9.3 Exemplo de algumas etapas de mapeamento, (a) Relações de entidade após a etapa 1. (b) Relação de entidade fraca após a etapa 2. (c) Relação de relacionamento após a etapa 5. (d) Relação representando atributo multivalorado após a etapa 6.

tipo dc entidade fraca £,,cujo proprietário também é um tipo dc entidade £p então £j deve ser mapeado antes dc £, para determinar primeiro sua chave primária. Em nosso exemplo, nesta etapa criamos a relação DEPENDENTE para correspon­ der ao tipo de entidade fraca DEPENDENTE [ver Figura 9.3(b)). Incluímos a chave primária Cpf da relação FUNCIONÁRIO — que corresponde ao tipo dc entidade proprietária — como um atributo dc chave estrangeira de DEPENDENTE; renomeamos para Cpf.funcionario, embora isso não seja necessário. A chave primária da relação DEPENDENTE é a combinação (Cpf.funcionario, Nome.dependente), pois Nome.dependente (também renomeado como Nome na Figura 9.1) é a chave parcial de DEPENDENTE. É comum escolher a opção dc propagação (CASCADE) para a ação dc disparo referencial (ver Seção 6.2) na chave estrangeira na relação correspondente ao tipo de entidade fraca, pois uma entidade fraca tem uma dependência de existência em sua entidade proprietária. Isso pode ser usado para ON UPDATE e ON DELETE.

Etapa 3: Mapeamento dos tipos de relacionamento binários 1:1. Para cada tipo de relacionamento binário 1:1 R no esquema ER, identifique as relações SeT que correspondem aos tipos de entidade participantes em R. Existem três técnicas possíveis: (1) a técnica dc chave estrangeira, (2) a técnica dc relação combinada c (3) a técnica de relação dc referência cruzada ou relacionamento. A primeira técnica é a mais útil e deve ser seguida, a menos que haja condições especiais, conforme discutimos a seguir 1. T écnica de chave estrangeira: escolha uma das relações — digamos, S — e inclua como chave estrangeira em Sa chave primária dc T. É melhor escolher um tipo

dc entidade com participação total cm R no papel dc S. Inclua todos os atributos simples (ou componentes simples dos atributos compostos) do ripo de relacio­ namento 1:1 R como atributos de S.

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

Em nosso exemplo, mapeamos o tipo de relacionamento 1:1 GERENCIA da Figura 9.1 ao escolher o tipo de entidade de participação DEPARTAMENTO para servir ao papel de S, pois sua participação no tipo de relacionamento GERENCIA é total (cada departamento tem um gerente). Incluímos a chave primária da relação FUNCIONÁRIO como chave estrangeira na relação DEPARTAMENTO e a renomeamos como Cpf.gerente. Também incluímos o atributo simples Data.inicio do tipo de relacionamento GERENCIA na relação DEPARTAMENTO e o renomeamos como Data.inicio.gerente (ver Figura 9.2). Observe que é possível incluir a chave primária de S como uma chave estran­ geira em T em vez disso. Em nosso exemplo, isso significa ter um atributo de chave estrangeira, digamos, Departamento.gerenciado na relação FUNCIONÁRIO, mas terá um valor NULL para as tuplas de funcionários que não gerenciam um departamento. Isso será uma má escolha, pois se apenas 2% dos funcionários gerenciam um departamento, então 98% das chaves estrangeiras seriam NULL neste caso. Outra possibilidade é ter chaves estrangeiras nas relações Se Tde maneira redundante, mas isso cria redundância e agrega uma penalidade para a manutenção da consistência.

2. Técnica de relação combinada: um mapeamento alternativo de um tipo de relacionamento 1:1 é combinar os dois tipos de entidade e o relacionamento cm uma única relação. Isso é possível quando ambas as participações sào totais, pois indicaria que as duas tabelas terão exatamente o mesmo número dc tuplas o tempo inteiro. 3. Técnica de relação de referência cruzada ou relacionamento: a terceira opção é configurar uma terceira relação R para a finalidade de referência cruzada das chaves primárias das duas relações S e T representando os tipos de entidade. Conforme veremos, essa técnica é exigida para relacionamentos M:N binários. A relação R é chamada dc relação dc relacionamento (ou, às vezes, dc tabela dc pesquisa), porque cada tupla em R representa uma instância de relacionamento que relaciona uma tupla de S a uma tupla de T. A relação R incluirá os atributos de chave primária de 5 e T como chaves estrangeiras para SeT.A chave primária de R será uma das duas chaves estrangeiras e a outra chave estrangeira será uma chave única dc R. A desvantagem é ter uma relação extra c exigir uma operação de junção adicional ao combinar tuplas relacionadas das tabelas. Etapa 4: Mapeamento de tipos de relacionamento binário 1:N. Existem duas técnicas possíveis: (1) a técnica de chave estrangeira e (2) a técnica de relação de referência cruzada ou relacionamento. A primeira geralmente é a preferida, pois reduz o número de tabelas.

1. Técnica dc chave estrangeira: para cada tipo dc relacionamento R binário regular 1:N, identifique a relação S que representa o tipo de entidade participante no lado N do tipo de relacionamento. Inclua como chave estrangeira em S a chave primária da relação Tque representa o outro ripo de entidade participante em R; fazemos isso porque cada instância de entidade no lado X está relacionada a, no máximo, uma instância de entidade no lado 1 do tipo de relacionamento. Inclua quaisquer atributos simples (ou componentes simples dos atributos compostos) do tipo dc relacionamento 1:N como atributos dc S. Para aplicar essa técnica ao nosso exemplo, mapeamos os tipos de relaciona­ mento 1:N TRABALHA.PARA, CONTROLA e SUPERVISIONA da Figura 9.1. Em TRABALHA.PARA, incluímos a chave primária Numero.departamento da relação DEPARTAMENTO como chave estrangeira na relação FUNCIONÁRIO e a chamamos de Numero.departamento. Para SUPERVISIONA, incluímos a chave primária da

269

270 Sistemas de banco de dados relação FUNCIONÁRIO como chave estrangeira na própria relação FUNCIONÁRIO — pois o relacionamento é recursivo — e a chamamos de Cpf_supervisor. O rela­ cionamento CONTROLA é mapeado para o atributo de chave estrangeira Numero_ departamento de PROJETO, que referencia a chave primária Numero.departamento da relação DEPARTAMENTO. Essas chaves estrangeiras são mostradas na Figura 9.2.

2. A técnica de relação de relacionamento: uma técnica alternativa é usar a relação de relacionamento (referência cruzada) como na terceira opção para os relacio­ namentos binários 1:1. Criamos uma relação separada R cujos atributos são chaves primárias de S e T, que também serão chaves estrangeiras para SeT.A chave primária de R é a mesma chave primária de S. Esta opção pode ser usada se poucas tuplas em S participarem do relacionamento, para evitar valores NULL excessivos na chave estrangeira. Etapa 5: Mapeamento dos tipos de relacionamento binário M:N. No modelo relacionai tradicional, sem atributos multivalorados, a única operação para rela­ cionamentos M:N é a opção dc relação dc relacionamento (referencia cruzada). Para cada tipo de relacionamento R binário M:N, crie uma nova relação S para representar R. Inclua como atributos de chave estrangeira em S as chaves primárias das relações que representam os tipos de entidade participantes; sua combinação formará a chave primária de S. Inclua também quaisquer atributos simples do tipo de relacionamento M:N (ou componentes simples dos atributos compostos) como atributos de S. Observe que não podemos representar um tipo de relacionamento M:N por um único atributo dc chave estrangeira cm uma das relações participantes (como fizemos para os tipos de relacionamento 1:1 ou 1:N) em virtude da razão de cardinalidade M:N; temos de criar uma relação de relacionamento S separada. Em nosso exemplo, mapeamos o tipo de relacionamento M:N TRABALHA.EM da Figura 9.1 criando a relação TRABALHA_EM na Figura 9.2. Incluímos as chaves primá­ rias das relações PROJETO e FUNCIONÁRIO como chaves estrangeiras cm TRABALHA_EM e renomeamos Cpf para Cpf.funcionario (a renomeação não é obrigatória; essa é uma opção de projeto). Também incluímos um atributo Horas em TRABALHA.EM para representar o atributo Horas do ripo de relacionamento. A chave primária da relação TRABALHA-EM é a combinação dos atributos de chave estrangeira {Cpf.funcionário, Numero.projeto). Essa relação de relacionamento aparece na Figura 9.3(c). /\ opção de propagação (CASCADE) para a ação de disparo referencial (ver Seção 4.2) deve ser especificada sobre as chaves estrangeiras na relação correspondente ao relacionamento R, pois cada instância de relacionamento tem uma dependência de existência sobre cada uma das entidades a que ela se relaciona. Isso pode ser usado tanto para ON UPDATE quanto para ON DELETE. Embora possamos mapear relacionamentos 1:1 ou 1:N de maneira semelhante aos relacionamentos M:N usando a técnica de referência cruzada (relação de rela­ cionamento), conforme discutimos anteriormente, essa alternativa só é recomendada quando existem poucas instâncias de relacionamentos, a fim de evitar valores NULL em chaves estrangeiras. Nesse caso, a chave primária da relação de relacionamento será apenas uma das chaves estrangeiras que referenciam as relações da entidade participante. Para um relacionamento 1:N, a chave primária da relação de relacio­ namento será a chave estrangeira que referencia a relação de entidade no lado N. Para um relacionamento 1:1, qualquer chave estrangeira pode ser usada como chave primária da relação de relacionamento. Etapa 6: Mapeamento de atributos multivalorados. Para cada atributo mulrivalorado A, crie uma nova relação R. Essa relação R incluirá um atributo correspon­ dente a A, mais o atributo da chave primária Ch — como uma chave estrangeira em R — da relação que representa o tipo de entidade ou o tipo dc relacionamento que

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

tem A como atributo mulrivalorado. A chave primária de R é a combinação de A e Ch. Se o atributo mulrivalorado for composto, incluímos seus componentes simples. Em nosso exemplo, criamos uma relação LOCALIZACOES_DEPARTAMENTO [ver Figura 9.3(d)]. O atributo Local representa o atributo mulrivalorado LOCALIZACOES de DEPARTAMENTO, enquanto Numero_departamento — como chave estrangeira — representa a chave primária da relação DEPARTAMENTO. A chave primária de LOCALIZACOES_DEPARTAMENTO é a combinação dc {Numero.departamento, Local]. Uma tupla separada existirá em LOCALIZACOES.DEPARTAMENTO para cada local que um departamento tenha. E importante observar que em versões mais recentes do modelo relacionai, que permitem os tipos de dados de vetor, o atributo mulrivalorado pode ser mapeado para um atributo de vetor, em vez de exigir uma tabela separada. A opção de propagação (CASCADE) para a ação dc disparo referencial (ver Seção 6.2) deve ser especificada na chave estrangeira da relação R correspondente ao atri­ buto mulrivalorado para ON UPDATE e ON DELETE. Também devemos observar que a chave de R, ao mapear um atributo composto, mulrivalorado, requer alguma análise do significado dos atributos componentes. Em alguns casos, quando um atributo mulrivalorado é composto, somente alguns dos atributos componentes precisam fazer parte da chave dc R; esses atributos sào semelhantes à chave parcial de um tipo de entidade fraca que corresponde ao atributo mulrivalorado (ver Seção 3.5). A Figura 9.2 mostra o esquema de banco de dados relacionai EMPRESA obtido com as etapas 1 a 6, e a Figura 5.6 mostra um exemplo de estado do banco de dados. Observe que ainda não discutimos o mapeamento dc tipos de relacionamento w-ário {n > 2), pois ele não existe na Figura 9.1; estes são mapeados de modo semelhante aos tipos de relacionamento M:N, incluindo a etapa adicional a seguir no algoritmo de mapeamento. Etapa 7: Mapeamento de tipos de relacionamento n-ário. Usamos a opção de relação de relacionamento. Para cada tipo de relacionamento w-ário R, em que n > 2, crie uma nova relação S para representar R. Inclua como atributos de chave estran­ geira em 5 as chaves primárias das relações que representam os tipos de entidade participantes. Inclua também quaisquer atributos simples do tipo de relacionamento w-ário (ou componentes simples de atributos compostos) como atributos de 5. A chave primária de 5 normalmente é uma combinação de todas as chaves estrangei­ ras que referenciam as relações representando os tipos de entidade participantes. Porém, se as restrições de cardinalidade sobre qualquer um dos tipos de entidade E participantes em R for 1, a chave primária de S não deve incluir o atributo de chave estrangeira que referencia a relação E' correspondente a E (ver discussão na Seção 3.9.2, referente a restrições sobre relacionamentos w-ários). Considere o tipo de relacionamento FORNECIMENTO da Figura 3.17, que rela­ ciona FORNECEDOR PECA p e PROJETO / sempre que f está fornecendo p para /; este pode ser mapeado para a relação FORNECIMENTO mostrada na Figura 9.4, cuja chave primária é a combinação das três chaves estrangeiras {Nome.fornecedor, Numero_peca, Nome.projeto).

9.1.2 Discussão e resumo do mapeamento para construções no

modelo ER A Tabela 9.1 resume as correspondências entre as construções e restrições dos modelos ER e relacionai. Um dos principais pontos a observar em um esquema relacionai, ao contrário de um esquema ER, é que os tipos de relacionamento não são representados explici­ tamente. Em vez disso, eles são representados com dois atributos, A e B; um é uma chave primária e o outro é uma chave estrangeira (no mesmo domínio) incluída em

271

272 Sistemas de banco de dados FORNECEDOR |—»j Nome.fornecedor

PROJETO

Nome projeto PECA Numero.peca

Figura 9.4 Mapeando o tipo de relacionamento n-ário FORNECIMENTO da Figura 3.17(a).

FORNECIMENTO Nome fornecedor

Nome projeto

Numero peca

Quantidade

duas relações S e T. Duas tuplas em SeT são relacionadas quando têm o mesmo valor para A e B. Usando a operação EQUIJUNÇÃO (ou JUNÇÃO NATURAL, se os dois atributos de junção tiverem o mesmo nome) em S.A e T.B, podemos combinar todos os pares de tuplas relacionadas de Se Te materializar o relacionamento. Quando um tipo de relacionamento binário 1:1 ou 1:N é envolvido, uma única operação de junção costuma ser necessária. Quando a técnica de relação de relacionamento é utilizada, como para um tipo de relacionamento binário M:N, duas operações de junção são necessárias, ao passo que, para tipos de relacionamento n-ários, n jun­ ções sào necessárias para materializar totalmente as instâncias de relacionamento. Por exemplo, para formar uma relação que inclui o nome do funcionário, o nome do projeto e as horas que o funcionário trabalha em cada projeto, precisa­ mos conectar cada tupla FUNCIONÁRIO às tuplas PROJETO relacionadas por meio da relação TRABALHA.EM na Figura 9.2. Logo, precisamos aplicar a operação EQUIJUNÇÃO às relações FUNCIONÁRIO e TRABALHA.EM com a condição de jun­ ção FUNCIONÁRIO.Cpf = TRABALHA.EM.Cpf.funcionário, e depois aplicar outra operação EQUIJUNÇÃO à relação resultante e a relação PROJETO com a condição dc junção TRABALHA.EM.Numero_projeto = PROJETO.Numero.projeto. Em geral, quando vários relacionamentos precisam ser examinados, diversas operações de junção precisam ser especificadas. O usuário sempre precisa estar ciente dos atributos de chave estrangeira para poder usá-los corretamente na combinação Tabela 9.1 Correspondência entre os modelos ER e relacionai. MODELO ER

MODELO RELACIONAL

Tipo de entidade

Relação de entidade

Tipo de relacionamento 1:1 ou 1:N

Chave estrangeira (ou relação de relacionamento)

Tipo de relacionamento M:N

Relação de relacionamento e duas chaves estrangeiras

Tipo de relacionamento n-ário

Relação de relacionamento e n chaves estrangeiras

Atributo simples

Atributo

Atributo composto

Conjunto de atributos componentes simples

Atributo multivalorado

Relação e chave estrangeira

Conjunto de valores

Domínio

Atributo-chave

Chave primária (ou secundária)

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

de tuplas relacionadas de duas ou mais relações. Isso às vezes é considerado uma desvantagem do modelo de dados relacionai, porque as correspondências de chave estrangeira/chave primária nem sempre sào óbvias pela inspeção dos esquemas relacionais. Se uma EQUIJUNÇÃO for realizada entre atributos de duas relações que não representam um relacionamento de chave estrangeira/chave primária, com frequência o resultado pode ser sem sentido e levar a dados falsos (espúrios). Por exemplo, o leitor pode tentar juntar as relações PROJETO e LOCALIZACOES_ DEPARTAMENTO na condição Local = Local_projeto e examinar o resultado. No esquema relacionai, criamos uma relação separada para cada atributo multivalorado. Para uma entidade em particular com um conjunto de valores para o atributo multivalorado, o valor do atributo-chave da entidade é repetido uma vez para cada valor do atributo multivalorado em uma tupla separada, pois o modelo relacionai básico não permite valores múltiplos (uma lista ou um conjunto de valores) para um atributo em uma única tupla. Por exemplo, como o departamento 5 tem três locais, existem três tuplas na relação LOCALIZACOES_DEPARTAMENTO da Figura 5.6; cada tupla especifica um dos locais. Em nosso exemplo, aplicamos EQUIJUNÇÃO a LOCALIZACOES_DEPARTAMENTO e DEPARTAMENTO sobre o atributo Numero_departamento para obter os valores de todas as localizações com outros atributos de DEPARTAMENTO. Na relação resultante, os valores dos outros atributos de DEPARTAMENTO são repetidos em tuplas separadas para cada local que tenha um departamento. A álgebra relacionai básica não tem uma operação ANINHAR ou COMPRIMIR que produziría um conjunto de tuplas na forma {) com base na relação LOCALIZACOES_ DEPARTAMENTO da Figura 5.6. Essa é uma desvantagem séria da versão básica nor­ malizada ou plana do modelo relacionai. O modelo de dados de objeto e os sistemas objeto-relacionai (ver Capítulo 12) permitem atributos multivalorados, usando o tipo de vetor para o atributo.

9.2 Mapeando construções do modelo EER para relações Nesta seção, vamos discutir o mapeamento das construções do modelo EER para relações, estendendo o algoritmo de mapeamento ER para relacionai apresentado na Seção 9.1.1.

9.2.1 Mapeamento da especialização ou generalização Existem várias opções para mapear uma série de subclasses que, juntas, formam uma especialização (ou, como alternativa, que são generalizadas para uma superclasse), como as subclasses {SECRETARIA, TÉCNICO, ENGENHEIRO) de FUNCIONÁRIO na Figura 4.4. As duas opções principais são mapear a especialização inteira para uma única tabela, ou mapeá-la para múltiplas tabelas. Dentro de cada opção existem variações que dependem das restrições sobre a especialização/generalização. Podemos acrescentar outro passo ao nosso algoritmo de mapeamento da Seção 9.1.1, que tem sete etapas, para lidar com o mapeamento da especialização. z\ etapa 8, que vem a seguir, oferece as opções mais comuns; outros mapeamentos também são possíveis. Discutimos as condições sob as quais cada opção deve ser usada. Usamos Atrs(R) para indicar os atributos da relação R e ChP(R) para indicar a chave primária de R. Primeiro vamos descrever o mapeamento formalmentc e depois ilustrar com exemplos.

273

274 Sistemas de banco de dados

Etapa 8: Opções para mapeamento da especialização ou generalização. Converta cada especialização com m subclasses (Sp S2> •••> e superclasse (gene­ ralizada) C, em que os atributos de C são [ch,at, ...an] ech é a chave (primária) para os esquemas da relação usando uma das seguintes opções: ■ Opção 8A: Múltiplas relações — superclasse e subclasses. Crie uma relação L para C com atributos Atrs(L) = [ch, ay,..., an] e ChP(L) = ch. Crie uma relação L- para cada subclasse 1 £ / £ m, com os atributos Atrs(L() = [ch\ U (atributos de S-| e ChPíL,) = ch. Esta opção funciona para qualquer especialização (total ou parcial, disjunta ou sobreposta). ■ Opção 8B: Múltiplas relações — apenas relações dc subclasse. Crie uma relação Lf para cada subclasse 1 < i< m, com os atributos Atrs(L;) = {atributos dc S;| U [ch, al9..., an] e ChP(L.) = ch. Esta opção só funciona para uma especialização cujas subclasses são totais (cada entidade na superclasse deve pertencer a, pelo menos, uma das subclasses). Além disso, isso só é recomendado se a especialização tiver a restrição de disjunção (ver Seção 4.3.1). Se a especialização for sobreposta, a mesma entidade pode ser duplicada em várias relações. ■ Opção 8C: Relação única com um atributo de tipo. Crie uma única relação L com atributos Atrs(L) = [ch, al9..., an] U (atributos de S,| U ... U (atributos de S„,| U {/} e ChP(L) = ch. O atributo t é chamado de atributo dc tipo (ou discriminador), cujo valor indica a subclasse à qual cada tupla pertence, se houver alguma. Essa opção funciona somente para uma especialização cujas subclasses são disjuntas, e tem o potencial para gerar muitos valores NULL se diversos atributos específicos existirem nas subclasses. ■ Opção 8D: Relação isolada com atributos de múltiplos tipos. Crie um único esquema de relação L com atributos Atrs(L) = {ch,at,..., tf„) U (atributos de S,| U ... U (atributos de Sm) U (ín t2,..., tw) e ChP(L) = ch. Cada t-, 1 < i < m, é um atributo dc tipo boolcano indicando se uma tupla pertence à subclasse 5,. Essa opção c usada para uma especialização cujas subclasses são sobrepostas (mas também funcionará para uma especialização disjunta).

As opções 8A e 8B podem ser chamadas de opções de relação múltipla, ao passo que as opções 8C e 8D podem ser chamadas de opções de relação única. A opção 8A cria uma relação L para a superclasse C e seus atributos, mais uma relação Lpara cada subclasse S-; cada L- inclui os atributos específicos (ou locais) de S:-, mais a chave primária da superclasse C, que é propagada para L- e torna-se sua chave primária. Ela também se torna uma chave estrangeira para a relação da superclasse. Uma operação EQUUUNÇÃO na chave primária entre qualquer Lte L produz todos os atributos específicos e herdados das entidades em Sx. Esta opção é ilustrada na Figura 9.5(a) para o esquema EER da Figura 4.4. A opção 8A funciona para quais­ quer restrições sobre a especialização: disjuntas ou sobrepostas, totais ou parciais. Observe que a restrição

precisa ser mantida para cada

Esta especifica uma chave estrangeira de cada /.,

para L. Na opção 8B, a operação EQUUUNÇÃO entre cada subclasse e a superclasse é embutida no esquema e a relação L é abolida, conforme ilustra a Figura 9.5(b) para a especialização EER na Figura 4.3(b). Esta opção funciona bem somente quando ambas as restrições, de disjunção e total, são mantidas. Se a especialização não for total, uma entidade que não pertence a qualquer uma das subclasses S-é perdida. Se a especialização não for disjunta, uma entidade pertencente a mais de uma subclasse terá seus atributos herdados da superclasse C armazenada dc maneira redundante cm

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

275

(a) FUNCIONÁRIO

(b) CARRO

Cod veiculo

Placa

Preco

Velocidade_maxima

Numero_passageiros

Placa

Preco

Numero_eixos

Capacidade_peso

CAMINHAO

Cod veiculo (c)

FUNCIONÁRIO Çfií

Primei ro_

Nome_

Ultimo.

Data,

nome

meio

nome

nascimento

Endereço

Tipo,

Velocidade,

Grau,

Tipo,

emprego

digitacao

técnico

engenheiro

(d) PECA

Numero. peca

Descricao

TipO_ fabricada

Numero.

Data.

Numero.

desenho

fabricacao

lote

Tipo. comprada

Nome.

fornecedor

Figura 9.5 Opções para mapeamento de especialização ou generalização, (a) Mapeando o esquema EER na Figura 4.4 ao usar a opção 8A. (b) Mapeando o esquema EER na Figura 4.3(b) ao usar a opção 8B. (c) Mapeando o esquema EER na Figura 4.4 ao usar a opção 8C. (d) Mapeando a Figura 4.5 ao usar a opção 8D com campos de tipo bodeano Tipo_ fabricada e Tipo_comprada.

mais de uma tabela L-. Com a opção 8B, nenhuma relação mantém todas as entidades na superclasse C; consequentemente, temos de aplicar uma operação UNIÃO EXTERNA (ou JUNÇÃO EXTERNA COMPLETA) (ver Seção 8.4) às relações Li para recuperar todas as entidades em C. O resultado da união externa será semelhante às relações sob as opções 8C e 8D, exceto que os campos de tipo estarão faltando. Sempre que procu­ rarmos uma entidade arbitrária cm C, devemos procurar todas as m relações Lr As opções 8C c 8D criam uma única relação para representar a superclasse C c todas as suas subclasses. Uma entidade que não pertence a nenhuma das subclas­ ses terá valores NULL para os atributos específicos (locais) dessas subclasses. Essas opções não são recomendadas se muitos atributos específicos forem definidos para as subclasses. Contudo, se houver poucos atributos de subclasse, esses mapeamentos sào preferíveis às opções 8A e 8B porque dispensam a necessidade de especificar operações de JUNÇÀO; portanto, eles podem produzir uma implementação mais eficiente para as consultas. A opção 8C é utilizada para lidar com subclasses disjuntas, incluindo um único atributo de tipo (ou de imagem ou discriminador) t para indicar a qual das m subclasses cada tupla pertence; logo, o domínio de t poderia ser (1, 2,..., w}. Se a especialização for parcial, t pode ter valores NULL em tuplas que não pertencem a nenhuma subclasse. Se a especialização for definida por atributo, esse próprio atri­ buto atende à finalidade de t, e t não é necessário; tal opção é ilustrada na Figura 9.5(c) para a especialização EER da Figura 4.4. A opção 8D é projetada para lidar com subclasses sobrepostas, incluindo m campos de tipo booleano (ou flag), um para cada subclasse. Ela também pode ser

Preco

276 Sistemas de banco de dados usada para subclasses disjuntas. Cada campo de tipo pode ter um domínio (sim, nào}, em que um valor sim indica que a tupla é um membro da subclasse 5,. Se usássemos essa opção para a especialização EER na Figura 4.4, incluiriamos três atributos de tipo — tipo_secretaria, tipo_engenheiro e tipo_tecnko — no lugar do atributo Tipo_emprego da Figura 9.5(c). A Figura 9.5(d) mostra o mapeamento da especialização da Figura 4.5 usando a opção 8D. Quando temos uma hierarquia ou reticulado de especialização (ou generalização) multinível, não precisamos seguir a mesma opção dc mapeamento para todas as especializações. Em vez disso, podemos utilizar uma opção de mapeamento para parte da hierarquia ou reticulado e outras opções para outras partes. Figura 9.6 mostra um mapeamento possível para as relações do reticulado EER da Figura 4.7. Aqui, usamos a opção 8A para PESSOA/( FUNCIONÁRIO, EX_ALUNO, ALUNO}, a opção 8C para FUNCIONARIO/{ADMINISTRATIVO, DOCENTE, ALUNO_COLABORADOR), incluindo o atributo de tipo Tipo_funcionario. Depois usamos a opção de única tabela 8D para ALUNO_COLABORADOR/{COLABORADOR_PESQUISA, COLABORADOR.ENSINO}, ao incluir os atributos de tipo Tipo_colaborador_ensino e Tipo_colaborador_pesquisa em FUNCIONÁRIO. Também usamos a opção 8D para ALUNO/ALUNO_COLABORADOR, incluindo os atributos dc tipo Tipo_aluno_colaborador cm ALUNO, e para ALUNO/ {ALUNO_POSGRADUACAO, ALUNO.GRADUACAO}, incluindo os atributos dc tipo Tipo_posgraduacao e Tipo.graduacao em ALUNO. Na Figura 9.6, todos os atributos cujos nomes iniciam com tipo são campos de tipo.

9.2.2 Mapeamento de subclasses compartilhadas (herança múltipla) Uma subclasse compartilhada, como GERENTE_ENGENHEIRO da Figura 4.6, c uma subclasse de várias superclasses, indicando a herança múltipla. Todas essas classes precisam ter o mesmo atributo-chave; caso contrário, a subclasse compartilhada seria modelada como uma categoria (tipo de união), conforme discutimos na Seção 4.4. Podemos aplicar qualquer uma das opções discutidas na etapa 8 a uma subclasse compartilhada, sujeita às restrições discutidas na etapa 8 do algoritmo de mapea­ mento. Na Figura 9.6, as opções 8C e 8D são usadas para a subclasse compartilhada ALUNO_COLABORADOR. A opção 8C é usada na relação FUNCIONÁRIO (atributo Tipo_fundonario) e a opção 8D, na relação ALUNO (atributo Tipo_aluno_colaborador).

PESSOA

Figura 9.6 Mapeando o reticulado de especialização EER da Figura 4.7 usando opções múltiplas.

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

9.2.3 Mapeamento de categorias (tipos de união) Acrescentamos outra etapa ao procedimento de mapeamento — etapa 9 — para lidar com categorias. Uma categoria (ou tipo de união) é uma subclasse da união de duas ou mais superclasses que podem ter diferentes chaves porque podem ser dc diferentes tipos dc entidade (ver Seção 4.4). Um exemplo c a categoria PROPRIETÁRIO, mostrada na Figura 4.8, que é um subconjunto da união de três tipos de entidade PESSOA, BANCO e EMPRESA. A outra categoria nessa figura, VEICULO.REGISTRADO, tem duas superclasses que possuem o mesmo atributo de chave.

Etapa 9: Mapeamento de tipos de união (categorias). Para o mapeamento de uma categoria cuja definição de superclasses tem chaves diferentes,é comum especi­ ficar um novo atributo-chave, chamado chave substituta, ao criar uma relação para corresponder ao tipo de união. As chaves das classes dc definição são diferentes e, portanto, não podemos usar nenhuma delas exclusivamente para identificar todas as entidades na relação. Em nosso exemplo da Figura 4.8, criamos uma relação PROPRIETÁRIO para corresponder à categoria PROPRIETÁRIO, conforme ilustrado na Figura 9.7, c incluímos alguns atributos da categoria nessa relação. A chave primária da relação PROPRIETÁRIO é a chave substituta, que chamamos dc Cod_proprietario. Também incluímos o atributo de chave substituta Cod_proprietano como uma chave estrangeira em cada relação correspondente a uma superclasse da categoria, para especificar a correspondência nos valores entre a chave substituta e a chave original PESSOA

Figura 9.7 Mapeamento das categorias EER (tipos de união) na Figura 4.8 para relações.

277

278 Sistemas de banco de dados de cada superclasse. Observe que, se determinada entidade PESSOA (ou BANCO ou EMPRESA) nào for um membro de PROPRIETÁRIO, ela teria um valor NULL para seu atributo Cod_proprietario em sua tupla correspondente na relação PESSOA (ou BANCO ou EMPRESA), e não teria uma tupla na relação PROPRIETÁRIO. Também é recomendado acrescentar um atributo de tipo (não mostrado na Figura 9.7) à rela­ ção PROPRIETÁRIO para indicar o tipo de entidade em particular ao qual cada tupla pertence (PESSOA, BANCO ou EMPRESA). Para uma categoria cujas superclasses têm a mesma chave, como VEICULO na Figura 4.8, não há necessidade de uma chave substituta. O mapeamento da categoria VEICULO_REGISTRADO, que ilustra esse caso, também aparece na Figura 9.7.

9.3 Resumo Na Seção 9.1, mostramos como um projeto de esquema conceituai no modelo ER pode ser mapeado para um esquema de banco de dados relacionai. Um algoritmo para mapeamento ER para relacionai foi dado e ilustrado por meio de exemplos do banco de dados EMPRESA. A Tabela 9.1 resumiu as correspondências entre as cons­ truções e restrições dos modelos ER e relacionai. Em seguida, acrescentamos as etapas adicionais ao algoritmo da Seção 9.2 para mapear as construções do modelo EER para o modelo relacionai. Algoritmos semelhantes são incorporados nas ferramentas gráficas de banco de dados para criar um esquema relacionai com base em um projeto de esquema conceituai automaticamente.

PERGUNTA DE REVISÃO

9.1.

------------------------------------------------------------------------

(a) Discuta as correspondências entre as construções do modelo ER e as cons­ truções do modelo relacionai. Mostre como cada construção do modelo ER pode ser mapeada para o modelo relacionai e discuta quaisquer mapeamentos alternativos, (b) Discuta as opções para mapear as construções do modelo EER para relações e as condições sob as quais cada operação poderia ser utilizada.

EXERCÍCIOS -----------------------------------------------------------------------------------------------

9.2. 9.3.

9.4.

9.5.

9.6.

Mapeie o esquema de banco de dados UNIVERSIDADE mostrado na Figura 3.20 em um esquema de banco de dados relacionai. Tente mapear o esquema relacionai da Figura 6.6 em um esquema ER. Isso faz parte de um processo conhecido como engenharia reversa^eva que um esquema conceituai é criado para um banco de dados implementado existente. Indique quaisquer suposições que você fizer. A Figura 9.8 mostra um esquema ER para um banco dc dados que pode ser usado para registrar navios de transporte e seus locais para autoridades marí­ timas. Mapeie esse esquema para um esquema relacionai e especifique todas as chaves primárias e estrangeiras. Mapeie o esquema ER BANCO do Exercício 3.23 (mostrado na Figura 3.22) cm um esquema relacionai. Especifique todas as chaves primárias e estrangeiras. Repita para o esquema COMPANHIA.AEREA (Figura 3.21) do Exercício 3.19 e para os outros esquemas dos exercícios 3.16 a 3.24. Mapeie os diagramas EER das figuras 4.9 e 4.12 para esquemas relacionais. Justifique sua escolha de opções de mapeamento.

Capitulo 9 Projeto de banco de dados relacionai por mapeamento ER e EER para relacionai

Figura 9.8 Esquema ER para um banco de dados MONITORAMENTO_NAVIO.

9.7. 9.8.

9.9.

É possível mapear com sucesso um ripo de relacionamento binário M:N sem exigir uma nova relação? Por qué? Considere o diagrama EER da Eigura 9.9 para um revendedor de automóveis. Mapeie o esquema EER para um conjunto de relações. Para a generalização dc VEICULO para CARRO/CAMINHAO/UTILITARIO, considere as quatro opções apresentadas na Seção 9.2.1 e mostre o projeto de esquema relacionai sob cada uma dessas opções. Usando os atributos que você forneceu para o diagrama EER do Exercício 4.27, mapeie o esquema completo para um conjunto de relações. Escolha uma opção apropriada de 8A até 8D, da Seção 9.2.1, fazendo o mapeamento de generalizações, e defenda sua escolha.

EXERCÍCIOS DE LABORATÓRIO --------------------------------------------------------------9.10. Considere o projeto ER para o banco de dados UNIVERSIDADE, modelado usando uma ferramenta como ERwin ou Rational Rose no Exercício de Laboratório 3.31. Utilizando o recurso de geração de esquema SQL da ferra­ menta de modelagem, gere o esquema SQL para um banco de dados Oracle. 9.11. Considere o projeto ER para o banco de dados PEDIDO_CORREIO, modelado usando uma ferramenta como ERwin ou Rational Rose no Exercício dc

279

280 Sistemas de banco de dados

Figura 9.9 Diagrama EER para um revendedor de automóveis.

Laboratório 3.32. Utilizando o recurso de geração de esquema SQL da ferra­ menta dc modelagem, gere o esquema SQL para um banco dc dados Oracle. 9.12. Considere o projeto ER para o banco de dados REVISAO_CONFERENCIA, mode­ lado usando uma ferramenta como ERwin ou Rational Rose no Exercício de Laboratório 3.34. Utilizando o recurso de geração de esquema SQL da ferra­ menta de modelagem, gere o esquema SQL para um banco de dados Oracle. 9.13. Considere o projeto EER para o banco de dados DIARIO_NOTAS, modelado usando uma ferramenta como ERwin ou Rational Rose no Exercício dc Laboratório 4.28. Utilizando o recurso de geração dc esquema SQL da ferra­ menta de modelagem, gere o esquema SQL para um banco de dados Oracle. 9.14. Considere o projeto EER para o banco de dados LEILAO_ONLINE, modelado usando uma ferramenta como ERwin ou Rational Rose no Exercício dc Laboratório 4.29. Utilizando o recurso dc geração dc esquema SQL da ferra­ menta de modelagem, gere o esquema SQL para um banco de dados Oracle.

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

O algoritmo de mapeamento ER para relacionai original foi descrito no artigo clássico de Chen (1976). Batini et al. (1992) discutem uma série de algoritmos de mapeamento de modelos ER e EER para modelos legados, e vice-versa.

PARTE 4 Técnicas de programação de banco de dados

10

Introdução às técnicas de programação SQL os capítulos 6 e 7, descrevemos vários aspectos da linguagem SQL, que é o padrão para bancos de dados relacionais. Descrevemos as instruções SQL para definição de dados, modificação de esquema, consultas, visões e atualizações. Também descrevemos como são especificadas diversas restrições sobre o conteúdo do banco dc dados, como restrições dc chave c integridade referencial. Neste capítulo e no próximo, vamos discutir alguns dos métodos desenvolvidos para acessar bancos de dados a partir dos programas. A maior parte do acesso ao banco de dados em aplicações práticas é realizada por meio de programas de software que implementam aplicações dc banco dc dados. Esse software normal­ mente é desenvolvido em uma linguagem dc programação de uso geral, como Java, C/C++/C#, COBOL (historicamente) ou alguma outra linguagem de programação. z\lém disso, muitas linguagens de scripting, como PHP, Python e JavaScript, também estão sendo usadas para programação de acesso ao banco de dados em aplicações web. Neste capítulo, focalizamos como os bancos de dados podem ser acessados das linguagens dc programação tradicionais C/C++ e Java, enquanto o próximo capítulo vai mostrar como os bancos de dados sâo acessados com linguagens de scripting, como PHP. Lembre-se, da Seção 2.3.1, que, quando instruções de banco de dados são incluídas em um programa, a linguagem de programação de uso geral é chamada de linguagem hospedeira, ao passo que a linguagem de banco de dados — SQL, em nosso caso — é chamada dc sublinguagem de dados. Em alguns casos, linguagens de programação de banco de dados especiais são desenvolvidas espccificamcnte para a escrita de aplicações de banco de dados. Embora muitas delas tenham sido desenvolvidas como protótipos de pesquisa, algumas linguagens de programação de banco de dados notáveis são de uso generalizado, como a PL/SQL (Programming Language/SQL) da Oracle. É importante observar que a programação de banco dc dados é um assunto muito

N

amplo. Existem livros-texto inteiros dedicados a cada técnica de programação de

284 Sistemas de banco de dados banco de dados e como essa técnica é realizada em um sistema específico. Novas técnicas sâo desenvolvidas o tempo todo, e as mudanças nas técnicas existentes sâo incorporadas a versões de sistema e linguagens mais novas. Uma dificuldade adicional na apresentação desse tópico é que, embora existam padrões de SQL, eles mesmos estão conrinuamente evoluindo, e cada vendedor de SGBD pode ter algu­ mas variações de padrão. Por isso, escolhemos fazer uma introdução a alguns dos principais tipos de técnicas de programação de banco dc dados c compará-los, em vez dc estudar um método ou sistema em particular com detalhes. Os exemplos que damos servem para ilustrar as principais diferenças que um programador enfrenta­ ria ao usar cada uma dessas técnicas de programação. Tentaremos usar os padrões de SQL em nossos exemplos no lugar de descrever um sistema específico. Ao usar um sistema específico, o material deste capítulo pode servir como uma introdução, mas deve ser expandido com os manuais do sistema e com livros que descrevem o sistema específico. Iniciamos nossa apresentação da programação de banco de dados na Seção 10.1 com uma visão geral das diferentes técnicas desenvolvidas para acessar um banco dc dados a partir dos programas. Depois, na Seção 10.2, discutimos as regras para embutir instruções SQL cm uma linguagem dc programação dc uso geral, comumcntc conhecida como SQL embutida. Essa seção também discute rapidamente a SQL dinâmica, em que as consultas podem ser construídas dinamicamente em tempo de execução, e apresenta os fundamentos da variante SQLJ da SQL embutida, desen­ volvida especifica mente para a linguagem dc programação Java. Na Seção 10.3, discutimos a técnica conhecida como SQUCLI (Call Levei Interface), em que uma biblioteca de procedimentos e funções é fornecida para acessar o banco de dados. Diversos conjuntos de funções de biblioteca foram propostos. O conjunto de funções da SQUCLI é aquele dado no padrão SQL. Outra biblioteca de funções bastante utilizada é ODBC (Open Data Rase Connectivity), que tem muitas semelhanças com SQUCLI; de fato, SQUCLI pode ser pensada como a versão padronizada da ODBC. Uma terceira biblioteca dc classes — que descrevemos aqui — é a JDBC; esta foi desenvolvida especificamente para acessar bancos de dados baseados a partir da linguagem de programação orientada a objeto (OOPL) Java. Na OOPL, uma biblioteca de classes é usada no lugar de uma biblioteca dc funções e procedimentos, c cada classe tem suas próprias operações e funções. Na Seção 10.4, vamos discutir sobre SQL/PSM (Persistent Stored Modules), que é uma parte do padrão SQL que permite que módulos de programa — procedimentos e funções — sejam armazenados pelo SGBD e acessados através da SQL; isso também especifica uma linguagem de programação de banco de dados procedimental para a escrita de módulos armaze­ nados, persistentes. Comparamos rapidamente as três técnicas de programação de banco de dados na Seção 10.5 e oferecemos um resumo do capítulo na Seção 10.6.

10.1 Programação de banco de dados: técnicas e problemas Agora, vamos voltar nossa atenção para as técnicas que foram desenvolvidas para acessar bancos de dados a partir de programas e, em particular, para a questão de como acessar bancos de dados SQL a partir de programas de aplicação. Nossa apresentação da SQL nos capítulos 6 c 7 focalizou as construções da linguagem para diversas operações do banco dc dados — da definição do esquema e especifica­ ção de restrição até a consulta, atualização e especificação de visões. A maioria dos sistemas de banco de dados possui uma interface interativa na qual esses comandos SQL podem ser digitados diretamente cm um monitor para execução

Capitulo 10 Introdução às técnicas de programação SQL

pelo sistema de banco de dados. Por exemplo, em um sistema de computador em que o SGBD Oracle está instalado, o comando SQLPLUS inicia a interface interativa. O usuário pode digitar comandos ou consultas SQL diretamente em várias linhas, terminadas com um ponto e vírgula e a tecla Enter (ou seja, '). Como alter­ nativa, um arquivo de comandos pode ser criado e executado por meio da interface interativa ao digitar @. O sistema executará os comandos escritos no arquivo e exibirá os resultados, se houver. A interface interativa é muito conveniente para a criação de esquema e restrição ou para consultas ad hoc, ou ocasionais. Porém, na prática, a maioria das interações de banco de dados é executada por programas que foram cuidadosamente projetados e testados. Esses programas costumam ser conhecidos como programas de aplicação ou aplicações dc banco de dados, c são usados como transações programadas pelos usuários finais, conforme discutimos na Seção 1.4.3. Outro uso comum da progra­ mação de banco de dados é para acessar um banco por meio de um programa de aplicação que implementa uma interface web, por exemplo, quando se faz reservas ou de uma companhia aérea ou compras na web. De fato, a grande maioria das aplicações dc comércio eletrônico na web inclui alguns comandos de acesso a banco dc dados. O Capítulo 11 nos dará uma visão geral da programação de banco de dados web usando PHP, uma linguagem de scripting que recentemente se tornou bastante utilizada. Nesta seção, primeiro damos uma visão geral das principais técnicas de progra­ mação dc banco dc dados. Depois, discutimos alguns dos problemas que ocorrem quando se tenta acessar um banco a partir dc uma linguagem dc programação de uso geral, e a sequência típica de comandos para interagir com um banco de dados a partir de um programa de software.

10.1.1 Técnicas para a programação de banco de dados Existem várias técnicas para incluir interações do banco de dados nos programas de aplicação. As principais técnicas para programação são as seguintes: 1. Embutir comandos do banco dc dados cm uma linguagem dc programação dc

uso geral. Nesta técnica, os comandos do banco de dados são embutidos na linguagem de programação hospedeira, mas são identificados por um prefixo especial. Por exemplo, o prefixo para a SQL embutida é a string EXEC SQL, que precede todos os comandos SQL cm um programa da linguagem hospedeira.1 Um pré-compilador ou pré-processador varre o código do programa fonte para identificar os comandos de banco de dados e extraí-los para processamento pelo SGBD. Eles são substituídos no programa por chamadas de função ao código gerado pelo SGBD. Essa técnica geralmente é conhecida como SQL embutida.

2. Usar uma biblioteca de funções ou classes de banco de dados. Há uma biblioteca de funções disponível à linguagem de programação hospedeira, para as chama­ das dc banco dc dados. Por exemplo, poderia haver funções para conectar com um banco de dados, preparar uma consulta, executar uma consulta, executar uma atualização, percorrer o resultado da consulta um registro por vez, e assim por diante. Os comandos reais de consulta e atualização do banco de dados e quaisquer outras informações necessárias são incluídos como parâmetros nas chamadas dc função. Esta técnica oferece o que é conhecido como interface dc programação dc aplicação (API — Application Programming Interface) para acessar um banco de dados de programas de aplicação. Para as linguagens dc programação orientadas a objeto (OOPLs), é utilizada uma biblioteca de classes. * Outros prefixos às vezes são usados, mas este é o mais comum.

285

286 Sistemas de banco de dados Por exemplo, Java possui a biblioteca de classes JDBC, que pode gerar diversos tipos de objetos, como objetos de conexão a um determinado banco de dados, objetos de consulta e objetos de resultado de consulta. Cada tipo de objeto tem um conjunto de operações associado à classe correspondente ao objeto.

3. Projetar uma linguagem totalmente nova. Uma linguagem de programação de banco de dados é projetada do zero para ser compatível com o modelo de banco de dados e a linguagem de consulta. Estruturas de programação adicionais, como loops e instruções condicionais, são acrescentadas à linguagem para convertê-la em uma linguagem de programação completa. Um exemplo dessa técnica é a PL/SQL da Oracle. O padrão SQL tem a linguagem SQL/PSM para especificar procedimentos armazenados. Na prática, as duas primeiras técnicas são mais comuns, pois muitas aplicações já são escritas em linguagens de programação de uso geral, mas exigem algum acesso ao banco de dados. A terceira técnica é mais apropriada para aplicações que pos­ suem intensa interação com o banco de dados. Um dos principais problemas com as duas primeiras técnicas é a divergência de impedância, que não ocorre na terceira.

10.1.2 Divergência de impedância Divergência de impedância é o termo usado para se referir aos problemas que ocorrem cm decorrência das diferenças entre o modelo de banco de dados e o modelo da linguagem de programação. Por exemplo, o modelo relacionai prático tem três construções principais: colunas (atributos) e seus tipos de dados, linhas (também chamadas de tuplas ou registros) e tabelas (conjuntos ou multiconjuntos de registros). O primeiro problema que pode ocorrer é que os tipos de dados da linguagem de pro­ gramação diferem dos tipos de dados de atributo disponíveis no modelo de dados. Logo, é necessário ter um vínculo para cada linguagem de programação hospedeira que especifica, para cada tipo de atributo, os tipos compatíveis na linguagem de pro­ gramação. Um vínculo diferente é necessário para cada linguagem de programação, pois diferentes linguagens possuem tipos de dados variados. Por exemplo, os tipos de dados disponíveis em C/C++ e Java são diferentes, e ambos diferem dos tipos de dados SQL, que são os tipos de dados padrão para bancos de dados relacionais. Outro problema ocorre porque os resultados da maioria das consultas são conjun­ tos ou multiconjuntos de tuplas (linhas), e cada tupla é formada por uma sequência de valores de atributo. No programa, normalmente é necessário acessar os valores dc dados individuais nas tuplas individuais para impressão ou processamento. Logo, é preciso que haja um vínculo para mapear a estrutura de dados do resultado da consulta, que é uma tabela, para uma estrutura de dados apropriada na linguagem de programação. E necessário que haja um mecanismo para percorrer as tuplas em um resultado de consulta a fim de acessar uma única tupla de cada vez e extrair valores individuais dela. Os valores de atributo extraídos costumam ser copiados para as variáveis de programa apropriadas para que o programa continue processando. Um cursor ou variável de iteração normalmente é usado para percorrer as tuplas em um resultado de consulta. Os valores individuais dentro de cada tupla são, então, extraídos para variáveis de programa distintas do ripo apropriado. A divergência de impedância é um problema menor quando uma linguagem de programação de banco de dados especial é projetada para usar o mesmo modelo e tipos de dados do banco. Um exemplo dessa linguagem é a PL/SQL da Oracle. O padrão SQL também tem uma proposta para tal linguagem de programação de banco de dados, conhecida como SQL/PSM. Para bancos de dados de objeto, o modelo de dados de objeto (ver Capítulo 12) é muito semelhante ao modelo de dados da linguagem de programação Java, de modo que a divergência de

Capitulo 10 Introdução às técnicas de programação SQL impedância é bastante reduzida quando Java é usada como linguagem hospedeira para acessar um banco de dados de objeto compatível com ela. Diversas lingua­ gens de programação de banco de dados foram implementadas como protótipos de pesquisa (ver a Bibliografia Selecionada).

10.1.3 Sequência de interação típica na programação de banco de dados Quando um programador ou engenheiro de software escreve um programa que exige acesso a um banco de dados, é muito comum que o programa esteja rodando em um sistema dc computador enquanto o banco de dados está instalado cm outro. Lembre-se, da Seção 2.5, dc que uma arquitetura comum para o acesso ao banco de dados é o modelo cliente/servidor em três camadas, no qual um programa cliente na camada superior exibe a informação cm um notebook ou dispositivo móvel, normalmcntc como um cliente web ou aplicativo móvel, um programa dc aplicação na camada intermediária implementa a lógica de uma aplicação de software comercial, mas inclui algumas chamadas para um ou mais servidores de banco de dados na camada inferior para acessar ou atualizar os dados.- z\o escrever tal programa, uma sequência comum de interação é a seguinte: 1. Quando o programa de aplicação requer acesso a determinado banco dc dados,

o programa precisa primeiro estabelecer ou abrir uma conexão com o servidor de banco de dados. Normalmente, isso envolve especificar o endereço da internet (URL) da máquina em que o servidor de banco de dados está localizado, além de fornecer um nome dc conta de login c senha para o acesso ao banco.

2. Quando a conexão é estabelecida, o programa pode interagir com o banco de dados submetendo consultas, atualizações e outros comandos do banco. Em geral, a maioria dos tipos de instruções SQL pode ser incluída em um programa de aplicação. 3. Quando o programa não precisar mais acessar determinado banco dc dados, ele deverá terminar ou fechar a conexão com o banco. Um programa pode acessar vários bancos de dados, se for preciso. Em algumas técnicas de programação, somente uma conexão pode estar ativa de uma só vez, enquanto em outras, várias conexões podem ser estabelecidas simultaneamente. Nas próximas três seções, vamos discutir exemplos dc cada uma das três prin­ cipais técnicas de programação dc banco de dados. A Seção 10.2 descreve como a SQL é embutida em uma linguagem de programação. A Seção 10.3 discute como as chamadas de função e as bibliotecas de classes são usadas para acessar o banco de dados usando SQL/CLI (semelhante a ODBC) e JDBC, c a Seção 10.4 discute uma extensão à SQL chamada SQL/PSM, que permite construções de programação de uso geral para definir módulos (procedimentos e funções) armazenados no sistema de banco de dados.23 A Seção 10.5 compara essas técnicas.

10.2 SQL embutida, SQL dinâmica e SQLJ Nesta seção, fornecemos uma visão geral da técnica que demonstra como as instruções SQL podem ser embutidas em uma linguagem de programação de uso geral. Focalizamos duas linguagens: C e Java. Os exemplos usados com a linguagem

2 Conforme discutimos na Seção 2.5, existem arquiteturas de duas e três camadas; para simplificar nossa discussão, vamos considerar aqui uma arquitetura cliente/servidor de duas camadas.

3 A SQI7PSM ilustra como as construções típicas da linguagem de programação de uso geral — como loops e estruturas condicionais — podem ser incorporadas à SQL.

287

288 Sistemas de banco de dados C, conhecidos como SQL embutida, sào apresentados nas seções 10.2.1 a 10.2.3, e podem ser adaptados a outras linguagens de programação semelhantes. Os exemplos que usam Java, conhecidos como SQLJ, sào apresentados nas seções 10.2.4 e 10.2.5. Nesta técnica embutida, a linguagem de programação é chamada de linguagem hos­ pedeira (ou host). A maioria das instruções SQL — incluindo definições de dados ou restrições, consultas, atualizações ou definições de visão — pode ser embutida em um programa na linguagem hospedeira.

10.2.1 Recuperando tuplas isoladas com SQL embutida Para ilustrar os conceitos da SQL embutida, usaremos C como linguagem de programação hospedeira.4*Ao usar C dessa maneira, uma instrução SQL embutida é distinguida das instruções da linguagem de programação pelas palavras-chave dc prefixo EXEC SQL, dc modo que um prc-proccssador (ou prc-compilador) possa separar as instruções SQL embutidas do código-fontc da linguagem hospedeira. As instruções SQL em um programa terminam com um END-EXEC correspondente ou com um ponto e vírgula (;). Regras semelhantes se aplicam à SQL embutida em outras linguagens de programação. Em um comando SQL embutido, podemos nos referir a variáveis de programa­ ção C cspccialmcntc declaradas; estas são chamadas dc variáveis compartilhadas, porque são usadas tanto no programa C quanto nas instruções SQL embutidas. As variáveis compartilhadas são iniciadas com um sinal de dois pontos (:) quando aparecem em uma instrução SQL. Isso distingue os nomes de variável do programa dos nomes das construções do esquema dc banco dc dados, como atributos (nomes dc coluna) c relações (nomes dc tabela). Isso tambcm permite que as variáveis do programa tenham os mesmos nomes que os atributos, pois podem ser distinguidos pelo sinal de dois pontos de prefixo na instrução SQL. Os nomes de construções do esquema de banco de dados — como atributos e relações — só podem ser usados nos comandos SQL, mas as variáveis de programa compartilhadas podem ser usadas cm qualquer lugar no programa C sem o prefixo de dois pontos. Suponha que queiramos escrever programas C para processar o banco de dados EMPRESA da Figura 5.5. Precisamos declarar variáveis de programa que correspon­ dam aos tipos dos atributos do banco de dados que o programa processará. O pro­ gramador pode escolher os nomes das variáveis de programa, que podem ou não ter nomes idênticos a seus atributos correspondentes no banco dc dados. Usaremos as variáveis dc programa C declaradas na Figura 10.1 para todos os nossos exemplos, mostrando os segmentos de programa C sem declarações de variável. As variáveis compartilhadas são declaradas em uma seção de declaração no programa, como mostra a Figura 10.1 (linhas 1 a 7)? Alguns dos vínculos comuns dos tipos C com os tipos SQL são os seguintes: os tipos SQL INTEGER, SMALLINT, REAL e DOUBLE são mapeados para os tipos C long, short, float e double, respectivamente. Strings dc tamanho fixo e de tamanho variável (CHAR [z], VARCHAR [z]) em SQL podem ser mapeadas para vetores de caracteres (char (i+1 ], varchar [i+1 ]) em C, que possuem um caractere a mais que o tipo SQL, pois as strings em C terminam com um caractere NULL (\0), que não faz parte da string de caracteres em si.6 Embora varchar não seja um tipo de dado C padrão, ele é permitido quando C é usada para a programação de banco dc dados SQL. 4 Nossa discussão aqui também se aplica às linguagens dc programação C++ ou C#, pois não usamos ne­ nhum dos recursos orientados a objeto, mas focalizamos o mecanismo de programação de banco de dados. ' Usamos números dc linha cm nossos segmentos dc código apenas para facilitar a referência; esses números nào fazem parte do código real.

6 Strings SQL também podem ser mapeadas para tipos char* em C.

Capitulo 10 Introdução às técnicas de programação SQL 0)

int loop ;

1)

EXEC SQL BEGIN DECLARE SECTION ;

2)

varchar nome_departamento[16], primeiro_nome[16], ultimo_nome[ 16], endereco[31 |;

3)

char cpf[ 12], data_nascimento[11 ], sexo[2], nome_meio[2];

4)

float salario, aumento;

5)

int numero_dep_func, numero_dep;

6)

int SQLCODE ; char SQLSTATE[6];

7)

EXEC SQL END DECLARE SECTION ;

Figura 10.1 Variáveis do programa C utilizadas nos exemplos E1 e E2 da SQL embutida.

Observe que os únicos comandos SQL embutidos na Figura 10.1 sào as linhas 1 e 7, que dizem ao pré-compilador para atentar para os nomes de variável C entre BEGIN DECLARE e END DECLARE, pois podem ser incluídos em instruções SQL embu­ tidas — desde que precedidas por um sinal de dois pontos (:). As linhas 2 a 5 sâo declarações normais de programa C. As variáveis dc programa C declaradas nas linhas 2 a 5 correspondem aos atributos das tabelas FUNCIONÁRIO e DEPARTAMENTO do banco de dados EMPRESA da Figura 5.5, que foi declarado pela SQL DDL na Figura 6.1. As variáveis declaradas na linha 6 — SQLCODE e SQLSTATE — são chamadas de variáveis dc comunicação SQL; cias são usadas para comunicar erros c condições de exceção entre o sistema de banco dc dados e o programa cm execução. A linha 0 mostra uma variável de programa loop que não será usada em nenhuma instrução SQL embutida, de modo que é declarada fora da seção de declaração da SQL.

Conectando ao banco de dados. O comando SQL para estabelecer uma conexão com um banco de dados tem a seguinte forma:

CONNECT TO cnome do servidor> AS cnome da conexão> AUTHORIZATION ;

Em geral, como um usuário ou programa podem acessar vários servidores de banco dc dados, diversas conexões podem scr estabelecidas, mas somente uma pode estar ativa cm qualquer ponto no tempo. O programador ou usuário podem usar o para mudar da conexão atualmente ativa para uma diferente, usando o comando a seguir: SET CONNECTION cnome da conexão> ;

Quando uma conexão não é mais necessária, ela pode ser terminada pelo seguinte comando: DISCONNECT ;

Nos exemplos deste capítulo, consideramos que a conexão apropriada já foi estabelecida com o banco de dados EMPRESA e que ela é a conexão atualmente ativa. Variáveis de comunicação SQLCODE e SQLSTATE. As duas variáveis dc comuni­ cação especiais usadas pelo SGBD para comunicar condições dc exceção ou erro ao programa são SQLCODE e SQLSTATE. A variável SQLCODE, mostrada na Figura 10.1, é uma variável inteira. Após cada comando do banco de dados ser executado, o SGBD retorna um valor cm SQLCODE. Um valor 0 indica que a instrução foi executada com sucesso pelo SGBD. Se SQLCODE > 0 (ou, mais cspccificamcntc, se SQLCODE = 100), isso indica que não há mais dados (registros) disponíveis no resultado de uma consulta. Se SQLCODE < 0, isso indica que houve algum erro. Em alguns sistemas — por exemplo, no SGBDR da Oracle —, SQLCODE é um campo em uma estrutura de registro chamada SQLCA (SQL Communication Area), de modo que é referenciado

289

290

Sistemas de banco de dados

como SQLCA.SQLCODE. Nesse caso, a definição da SQLCA precisa ser incluída no programa C utilizando a seguinte linha: EXEC SQL indude SQLCA;

Em versões mais recentes do padrão SQL, uma variável de comunicação chamada SQLSTATE foi acrescentada, que é uma string de cinco caracteres. Um valor ‘00000’ em SQLSTATE indica que não há nenhum erro ou exceção; outros valores indicam diversos erros ou exceções. Por exemplo, ‘02000’ indica ‘sem mais dados’ quando se usa SQLSTATE. Atualmente, tanto SQLSTATE quanto SQLCODE estão disponíveis no padrão SQL. Muitos dos códigos de erro e exceção retomados em SQLSTATE supostamente estão padronizados para todos os vendedores e plataformas SQL,7 ao passo que os códigos retornados em SQLCODE não estão padronizados, mas são definidos pelo vendedor do SGBD. Logo, em geral é melhor usar SQLSTATE, pois isso torna o tratamento de erro nos programas de aplicação independente de um SGBD em particular. Como um exercício, o leitor deverá reescrever os exemplos dados mais adiante neste capítulo usando SQLSTATE em vez de SQLCODE. Exemplo de programação SQL embutida. Nosso primeiro exemplo para ilustrar a programação SQL embutida é um segmento repetitivo (loop) do programa que recupera como entrada o número do Cpf de um funcionário e imprime algumas informações com base no registro de FUNCIONÁRIO correspondente no banco de dados. O código de programa em C aparece como o segmento de programa El na Figura 10.2. O programa lê (solicita) um valor de Cpf e depois recupera a tupla de FUNCIONÁRIO com esse Cpf do banco de dados por meio do comando SQL embutido. A cláusula INTO (linha 5) especifica as variáveis do programa em que os valores de atributo do registro de banco de dados são recuperados. As variáveis do programa em C na cláusula INTO são iniciadas com um sinal de dois pontos (:), conforme discutimos anteriormente. A cláusula INTO só pode ser usada desse modo quando o resultado da consulta é um único registro; se vários registros forem recuperados, será gerado um erro. Veremos como múltiplos registros são tratados na Seção 10.2.2.

//Segmento de programa E1: 0)

loop = 1 ;

1)

while (loop) {

2)

promptCDigite um CPF: ", cpf);

3)

EXEC SQL

4)

SELECT Primeiro.nome, Nome_meio, Ultimo.nome, Endereço, Salario

5)

INTO :primeiro_nome, :nome_meio, :ultimo_nome, :endereco, :salario

6)

FROM FUNCIONÁRIO WHERE Cpf = :cpf ;

7)

if(SQLCODE==0) printf(primeiro.nome, nome.meio, ultimo.nome, endereço, salario); else printf(‘CPF não existe: ", cpf);

8) 9)

promptUMais CPF? (Digite 1 para Sim, 0 para Não): ", loop) ;

10)

}

Figura 10.2 Segmento de programa El, um segmento de programa em C com SQL embutida.

" Em particular, códigos de SQLSTATE começando com os caracteres 0 a 4 ou A a H supostamente sào padronizados, enquanto outros valores podem ser definidos pela implementação.

Capitulo 10 Introdução às técnicas de programação SQL

A linha 7 em El ilustra a comunicação entre o banco de dados e o programa por meio da variável especial SQLCODE. Se o valor retornado pelo SGBD em SQLCODE for 0, a instrução anterior foi executada sem erros ou condições de exceção. A linha 7 verifica isso e considera que, se ocorreu um erro, foi porque não existia nenhuma tupla FUNCIONÁRIO com o Cpf dado; portanto, ela gera uma mensagem de saída indicando isso (linha 8). Quando um único registro é recuperado, como no exemplo El, o programador pode designar seus valores de atributo dirctamente às variáveis do programa em C na cláusula INTO, como na linha 5. Em geral, uma consulta SQL pode recuperar muitas tuplas. Nesse caso, o programa em C costuma percorrer as tuplas recuperadas e as processa uma de cada vez. O conceito de um cursor é usado para permitir o processamento de uma tupla por vez no resultado de uma consulta pelo programa da linguagem hospedeira. A seguir, vamos descrever os cursores.

10.2.2 Processando resultados da consulta por meio de cursores Um cursor é uma variável que se refere a uma única tupla (linha) do resultado de uma consulta que recupera uma coleção de tuplas. Ele é usado para percorrer o resultado da consulta, um registro de cada vez. O cursor é declarado quando a consulta SQL é declarada. Mais adiante no programa, um comando OPEN CURSOR busca o resultado da consulta no banco de dados e define o cursor para uma posição antes da primeira linha no resultado da consulta. Esta se torna a linha atual para o cursor. Depois, comandos FETCH são emitidos no programa. Cada FETCH move o cursor para a linha seguinte no resultado da consulta, tomando-a a linha atual e copiando seus valores de atributo para as variáveis do programa em C (linguagem hospedeira) especificadas no comando FETCH por uma cláusula INTO. A variável do cursor é basicamente um iterador (iterator) que percorre as tuplas (em um loop) no resultado da consulta — uma tupla de cada vez. Para determinar quando todas as tuplas no resultado da consulta foram pro­ cessadas, a variável dc comunicação SQLCODE (ou, como alternativa, SQLSTATE) é verificada. Se um comando FETCH for emitido e resultar na movimentação do cursor além da última tupla no resultado da consulta, um valor positivo (SQLCODE > 0) é retornado em SQLCODE, indicando que nenhum dado (tupla) foi encontrado (ou a string * 02000' é retornada em SQLSTATE). O programador usa isso para terminar um loop sobre as tuplas no resultado da consulta. Em geral, diversos cursores podem ser abertos ao mesmo tempo. Um comando CLOSE CURSOR é emitido para indicar que terminamos com o processamento do resultado da consulta associada a esse cursor. Um exemplo do uso de cursores para processar um resultado de consulta com múltiplos registros é mostrado na Eigura 10.3, em que um cursor chamado FUNC é declarado na linha 4. O cursor FUNC é associado à consulta SQL declarada nas linhas 5 a 6, mas a consulta não é executada até que o comando OPEN FUNC (linha 8) seja processado. O comando OPEN «cnome cursor> executa a consulta e busca seu resultado como uma tabela no workspace do programa, em que o programa pode percorrer as linhas (tuplas) individuais por subsequentes comandos FETCH (linha 9). Consideramos que as variáveis apropriadas no programa em C foram declaradas como na Eigura 10.1. O segmento de programa em E2 lê (solicita) um nome de departamento (linha 0), recupera o número de departamento correspondente do banco de dados (linhas 1 a 3) e depois recupera os funcionários que trabalham nesse departamento por meio do cursor FUNC. Um loop (linhas 10 a 18) passa por cada registro no resultado da consulta, um de cada vez, e imprime o nome do funcionário. O programa então lê (solicita) um valor de aumento para esse funcionário (linha 12) e atualiza o salário dele no banco de dados pelo valor do aumento oferecido (linhas 14 a 16).

291

292 Sistemas de banco de dados

//Segmento de programa E2: 0)

promptCDigite o Nome do Departamento: ", nome_departamento);

1)

EXECSQL

2)

SELECT Numero.departamento INTO :numero_dep

3)

FROM DEPARTAMENTO WHERE Nome.departamento = :nome_departamento;

4)

EXEC SQL DECLARE FUNC CURSOR FOR

5)

SELECT Cpf, Primeiro.nome, Nome.meio, Ultimo.nome, Salario

6)

FROM FUNCIONÁRIO WHERE Numero.departamento = :numero_dep

7)

FOR UPDATE OF Salario;

8)

EXEC SQL OPEN FUNC ;

9)

EXEC SQL FETCH FROM FUNC INTO :cpf, :primeiro_nome, znome.meio, zultimo.nome, :salario ;

10)

while(SQLCODE==0) {

11)

printf(“O nome do funcionário é:", Primeiro.nome, Nome.meio, Ultimo.nome);

12)

prompt "Digite o valor do aumento: ", aumento);

13)

EXECSQL

14)

UPDATE FUNCIONÁRIO

SET Salario = Salario + :aumento

15)

WHERE CURRENT OF FUNC ;

16)

17)

EXEC SQL FETCH FROM FUNC INTO :cpf, :primeiro_nome, :nome_meio, :ultimo_nome, :salario;

18)

}

19)

EXEC SQL CLOSE FUNC ;

Figura 10.3 Segmento de programa E2, um segmento de programa em C que usa cursores com SQL embutida para fins de atualização. Este exemplo também ilustra como o programador pode atualizar registros do banco de dados. Quando um cursor é definido para linhas que devem ser modificadas (atualizadas), temos dc acrescentar a cláusula FOR UPDATE OF na declaração do cursor e listar os nomes dc quaisquer atributos que serão atualizados pelo programa. Isso é ilustrado na linha 7 do segmento de código E2. Se as linhas tiverem de ser excluídas, as palavras-chave FOR UPDATE devem ser acrescentadas sem especificar quaisquer atributos. No comando embutido UPDATE (ou DELETE), a condição WHERE CURRENT OF especifica que a tupla atualmente referenciada pelo cursor é aquela a ser atualizada (ou excluída), como na linha 16 de E2. Não é preciso incluir a cláusula FOR UPDATE OF na linha 7 de E2 se os resultados da consulta tiverem de ser usados apenas para fins de recuperação (sem atualização ou exclusão).

Opções gerais para uma declaração de cursor. Várias opções podem ser especi­ ficadas quando se declara um cursor. O formato geral de uma declaração de cursor é o seguinte: DECLARE [ INSENSITIVE ] [ SCROLL ] CURSOR [ WITH HOLD ] FOR [ ORDER BY ] [ FOR READ ONLY | FOR UPDATE [ OF clista de atributos> 11;

Já discutimos rapidamente as opções listadas na última linha. O padrão é que a consulta seja para fins de recuperação (FOR READ ONLY). Se algumas das tuplas no

Capitulo 10 Introdução às técnicas de programação SQL

resultado da consulta tiverem de ser atualizadas, precisamos especificar FOR UPDATE OF -clista de atributos> e listar os atributos que podem ser atualizados. Se algumas tuplas tiverem de ser excluídas, precisamos especificar FOR UPDATE sem quaisquer atributos. Quando a palavra-chave opcional SCROLL é especificada em uma declaração de cursor, é possível posicionar o cursor de outras maneiras além de simplesmente para acesso sequencial. Uma orientação dc busca pode ser acrescentada ao comando FETCH, cujo valor pode ser NEXT, PRIOR, FIRST, LAST, ABSOLUTE i e RELATIVE /. Nos dois últimos comandos, i precisa ser avaliado como um valor inteiro que especifica uma posição de tupla absoluta no resultado da consulta (para ABSOLUTE /'), ou uma posição de tupla relativa à posição atual do cursor (para RELATIVE /). A orientação dc busca padrão, que usamos cm nossos exemplos, é NEXT. A orientação de busca permite que o programador movimente o cursor pelas tuplas no resultado da consulta com maior flexibilidade, oferecendo acesso aleatório por posição ou acesso na ordem inversa. Quando SCROLL é especificado no cursor, o formato geral de um comando FETCH é o seguinte, com as partes entre colchetes sendo opcionais: FETCH [ [ corientação de busca> ] FROM ] cnome do cursor> INTO clista de destino da busca> ;

A cláusula ORDER BY ordena as tuplas de modo que o comando FETCH as buscará na ordem especificada. Ela é determinada de modo semelhante à cláusula corres­ pondente para consultas SQL (ver Seção 6.3.6). As duas últimas opções quando se declara um cursor (INSENSITIVE e WITH HOLD) referem-se a características de transação dos programas de banco de dados, que discutiremos no Capítulo 20.

10.2.3 Especificando consultas em tempo de execução usando a SQL dinâmica Nos exemplos anteriores, as consultas SQL embutidas foram escritas como parte do código-fonte do programa hospedeiro. Logo, quando quisermos escrever uma consulta diferente, temos de modificar o código do programa c passar por todas as etapas envolvidas (compilação, depuração, teste etc.). Em alguns casos, é conveniente escrever um programa que possa executar diferentes consultas ou atualizações SQL (ou outras operações) dinamicamente em tempo de execução. Por exemplo, podemos querer escrever um programa que aceite uma consulta SQL digitada pelo terminal, execute-a e apresente seu resultado, como as interfaces interativas disponíveis para a maioria dos SGBDs relacionais. Outro exemplo é quando uma interface de fácil utili­ zação gera consultas SQL de maneira dinâmica para o usuário com base na entrada dele por meio de uma interface web ou aplicativo de celular. Nesta seção, apresentamos uma rápida visão geral da SQL dinâmica, que é uma técnica para escrever esse tipo de programa dc banco de dados, dando um exemplo simples para ilustrar como essa linguagem pode funcionar. Na Seção 10.3, descreveremos outra técnica para lidar com consultas dinâmicas, usando bibliotecas de funções ou de classes. O segmento de programa E3 da Figura 10.4 lê uma string inserida pelo usuário (essa string deverá ser um comando de atualização SQL neste exemplo) para a variável de string do programa sqlupdatestring na linha 3. Depois, ele prepara isso como um comando SQL na linha 4, associando-o à variável SQL sqlcommand. A linha 5 então executa o comando. Observe que, nesse caso, nenhuma verificação de sintaxe ou outros tipos de verificações sobre o comando são possíveis em tempo de compilação., pois o comando SQL não está disponível antes da execução. Isso é diferente dos nossos exemplos anteriores de SQL embutida, em que a consulta podia ser verificada em tempo de compilação, pois seu texto estava no código-fonte do programa.

293

294 Sistemas de banco de dados

0) 1) 2)

//Segmento de programa E3: EXEC SQL BEGIN DECLARE SECTION ; varchar sqlupdatestring[256]; EXEC SQL END DECLARE SECTION ;

3) 4) 5)

promptCDigite o comando Update: ", sqlupdatestring); EXEC SQL PREPARE sqlcommand FROM :sqlupdatestring ; EXEC SQL EXECUTE sqlcommand ;

Figura 10.4 Segmento de programa E3, um segmento de programa em C que usa a SQL dinâmica para atualizar uma tabela.

Em E3, o motivo para separar PREPARE e EXECUTE é que, se o comando tiver de ser executado várias vezes em um programa, ele pode ser preparado apenas uma vez. A preparação do comando costuma envolver sintaxe e outros tipos dc verificações pelo sistema, bem como a geração do código para executá-lo. E possível combinar os comandos PREPARE e EXECUTE (linhas 4 e 5 em E3) em um único comando ao escrever EXEC SQL EXECUTE IMMEDIATE :sqlupdatestring ; Isso é útil se o comando tiver de ser executado apenas uma vez. Como alternativa, o programador pode separar as duas instruções para recuperar quaisquer erros após a instrução PREPARE, como em E3. Embora a inclusão de um cornando de atualização dinâmico seja relativamente simples na SQL dinâmica, uma consulta de recuperação dinâmica é muito mais com­ plicada. Isso porque, em geral, não conhecemos os tipos ou o número de atributos a serem recuperados pela consulta SQL quando estamos escrevendo o programa. Às

vezes, c preciso que haja uma estrutura dc dados complexa para permitir diferentes números e tipos de atributos no resultado da consulta, caso não se conheça nenhuma informação anterior sobre a consulta dinâmica. Técnicas semelhantes às que dis­ cutiremos na Seção 10.3 podem ser usadas para atribuir resultados da consulta (e parâmetros da consulta) às variáveis do programa hospedeiro.

10.2.4 SQLJ: embutindo comandos SQL em Java Nas subseções anteriores, demos uma ideia de como os comandos SQL podem ser embutidos em uma linguagem de programação tradicional, usando a linguagem C em nossos exemplos. Agora, voltamos nossa atenção para como a SQL pode ser embutida em uma linguagem de programação orientada a objeto,8 em particular, a linguagem Java. A SQLJ é um padrão adotado por diversos vendedores para embu­ tir SQL em Java. Historicamente, a SQLJ foi desenvolvida após a JDBC, a qual é usada para acessar bancos de dados SQL com a linguagem Java usando bibliotecas de classes e chamadas de função. Vamos discutir a JDBC na Seção 10.3.2. Nesta seção, focamos em SQLJ e como ela é usada no SGBDR Oracle. Um tradutor de SQLJ geralmente converterá comandos SQL para Java, que poderão ser executados por meio da interface JDBC. Logo, é necessário instalar um driver JDBC ao usar a SQLJ.9 Nesta seção, mostramos como usar conceitos de SQLJ para escrever SQL embutida em um programa Java.

s Esta seção pressupõe que o leitor possui alguma familiaridade com conceitos orientados a objeto (ver Capítulo 12) e conceitos básicos de Java. 9 Discutiremos sobre drivers JDBC na Seção 10.3.2.

Capitulo 10 Introdução às técnicas de programação SQL

Antes de ser capaz de processar SQLJ com Java em Oracle, é necessário impor­ tar várias bibliotecas de classes, mostradas na Figura 10.5. Estas incluem as classes JDBC e IO (linhas 1 e 2), além das classes adicionais listadas nas linhas 3, 4 e 5. Além disso, o programa precisa primeiro se conectar ao banco de dados desejado usando a chamada de função getConnection, que é um dos métodos da classe oracle da linha 5 da Figura 10.5. O formato dessa chamada de função, que retorna um objeto do tipo contexto default,10 é o seguinte:

public static Defaultcontext getConnection (String uri. String user. String password. Boolean autoCommit)

throws SQLException; Por exemplo, podemos escrever as instruções nas linhas 6 a 8 da Figura 10.5 para conectar a um banco de dados Oracle localizado no uri usando o login de e com autocommit de cada comando,11 e depois definir essa conexão como o contexto default para os comandos seguintes. Nos exemplos a seguir, não mostraremos as classes ou programas Java comple­ tos, pois não é nossa intenção ensinar Java. Em vez disso, mostraremos segmentos de programa que ilustram o uso da SQLJ. A Figura 10.6 mostra as variáveis de programa Java usadas em nossos exemplos. O segmento de programa J1 na Figura 10.7 lê o Cpf de um funcionário e imprime algumas das informações do funcionário contidas no banco de dados.

1)

import * java.sql. ;

2)

import java.io * ;

3)

import sqlj.* runtime. ;

4)

import sqlj.* runtime.ref. ;

5)

import * oracle.sqlj.runtime. ;

6)

Defaultcontext entxt =

7)

Orade.getConnection(‘", ““, "", true);

8)

DefaultContext.setDefaultContext(cntxt);

Figura 10.5 Importando classes necessárias para incluir SQU em programas Java no Oracle e estabelecendo uma conexão e um contexto default.

1)

string nome_departamento, cpf, primeiro.nome, pnome, ultimo nome, unome, data.nasdmento, endereço ;

2)

char sexo, nome.meio, nmeio;

3)

double salario, sal;

4)

integer numero.dep.func, numero.dep ;

Figura 10.6 Variáveis de programa Java usadas nos exemplos de J1 e J2 de SQU.

10 Um contexto default, quando definido, se aplica a comandos subsequentes no programa até que ele seja mudado. 11 Autocommit significa mais ou menos que cada comando é aplicado ao banco de dados depois de ser executado. A alternativa c que o programador queira executar vários comandos dc banco dc dados re­ lacionados e, depois, os confirme juntos. Discutiremos conceitos de confirmação [commit) no Capítulo 20. quando descrevermos transações do banco de dados.

295

296 Sistemas de banco de dados

//Segmento de programa J1: 1)

cpf = readEntry(" Digite o número do CPF: ");

2)

try {

3)

#sql {SELECT Primeiro.nome, Nome.meio, Ultimo.nome, Endereço, Salario

4)

INTO :primeiro_nome, :nome_meio, :ultimo_nome, :endereco, :salario

5)

FROM FUNCIONÁRIO WHERE Cpf = :cpf};

6)

} catch (SQLException se) {

7)

System.out.printing Número do CPF não existe: " + cpf);

8)

return;

9)

10)

} System.out.println(primeiro_nome + “ " + nome.meio + " " + ultimo.nome + " ’ + endereço + " " + salario)

Figura 10.7 Segmento de programa Jl, um segmento de programa Java com SQLJ.

Observe que, como Java já usa o conceito de exceções para tratamento de erro, uma exceção especial, chamada SQLException, é utilizada para retornar erros ou condições de exceção depois de executar um comando de banco de dados SQL. Isso desempenha um papel semelhante a SQLCODE e SQLSTATE na SQL embutida. A Java tem muitos tipos de exceções predefinidas. Cada operação (função) Java deve especificar as exceções que podem ser lançadas (thrown) — ou seja, as condições de exceção que podem ocorrer enquanto se executa o código Java dessa operação. Se ocorrer uma exceção definida, o sistema transfere o controle ao código Java espe­ cificado para tratamento dessa exceção. Em Jl, o tratamento da exceção para uma SQLException é especificado nas linhas 7 e 8. Em Java, a estrutura a seguir try {} catch () {ccódigo de tratamento de exceção>) ccontinuação do código>

é usada para lidar com exceções que ocorrem durante a execução da . Se não houver exceção, a é processada diretamente. As exceções que podem ser lançadas pelo código em determinada operação devem ser especificadas como parte da declaração da operação ou interface — por exemplo, no formato a seguir: () throws SQLException, lOException ;

Em SQLJ, os comandos SQL embutidos em um programa Java são precedidos por #sql, conforme ilustrado na linha 3 de Jl, dc modo que possam ser identificados pelo pré-processador. O #sql é usado no lugar das palavras-chave EXEC SQL utilizadas na SQL embutida com a linguagem de programação C (ver Seção 10.2.1). SQLJ usa uma cláusula INTO — semelhante àquela da SQL embutida — para retornar os valores de atributo recuperados do banco de dados por uma consulta SQL em variáveis de programa Java. As variáveis dc programa são precedidas por sinais de dois pontos (:) na instrução SQL, assim como na SQL embutida. Em Jl, uma única tupla é recuperada pela consulta SQLJ embutida. E por isso que podemos atribuir seus valores de atributo diretamente a variáveis do programa Java na cláusula INTO, na linha 4 da Eigura 10.7. Para consultas que recuperam mais dc uma tupla, a SQLJ usa o conceito dc um iterador (iterator), que é semelhante a um cursor na SQL embutida.

Capitulo 10 Introdução às técnicas de programação SQL

297

10.2.5 Processando resultados de consulta em SQU por meio de iteradores Em SQLJ, um itcrador c um tipo dc objeto associado a uma coleção (conjunto ou multiconjunto) de registros cm um resultado dc consulta.12 O itcrador está associado às tuplas e aos atributos que aparecem no resultado de uma consulta. Existem dois tipos de iteradores: 1. Um itcrador nomeado é associado a um resultado de consulta ao listar os nomes e os tipos de atributo que aparecem no resultado dela. Os nomes de atributo devem corresponder a variáveis de programa Java apropriadamente declarados, como mostra a Figura 10.6.

2. Um itcrador posicionai lista apenas os tipos de atributo que aparecem no resul­ tado da consulta. Nos dois casos, a lista deveria estar na mesma ordem dos atributos listados na cláusula SELECT da consulta. No entanto, o looping sobre um resultado de consulta é diferente para os dois tipos de iteradores. Primeiro, mostramos um exemplo de uso de um iterador nomeado na Figura 10.8, segmento de programa J2A. A linha 9 na Figura 10.8 mostra como um tipo de iterador nomeado Func é declarado. Observe que os nomes dos atributos em um tipo de iterador nomeado precisam combinar com os nomes dos atributos no resultado da consulta SQL. A linha 10 mostra como um objeto iterador í do tipo Func é criado no programa e depois associado a uma consulta (linhas lie 12).

//Segmento de programa J2A: 0)

nome_departamento = readEntry("Digite o nome do departamento: ");

D 2)

try { #sql {SELECT Numero.departamento INTO :numero_dep

FROM DEPARTAMENTO WHERE Nome.departamento = :nome_departamento};

3) 4)

} catch (SQLException se) {

5) 6)

System.outprintlnCDepartamento não existe: " + nome.departamento); return;

7) 8)

} System.out.printing Informação do funcionário para departamento: ’ + nome_ departamento); #sql iterator Func(String cpf. String primeiro.nome. String nome.meio. String ultimo.nome, double salario);

9)

10) 11)

Func f = null; #sql f = {SELECT cpf, primeiro.nome, nome.meio, ultimo.nome, salario FROM FUNCIONÁRIO WHERE Numero.departamento = :numero_dep};

12)

13) 14)

while (f.next()) { System.out.printing.cpf + " " + f.primeiro.nome + " " + f.nome.meio + " " + f.ultimo.nome + “ " + f.salario);

15)

}

16)

f.dose();

Figura 10.8 Segmento de programa J2A, um segmento de programa Java que usa um iterador nomeado para imprimir informações de funcionário em determinado departamento.

12 Discutiremos sobre iteradores com mais detalhes no Capítulo 12, quando apresentaremos os concei­ tos de banco de dados de objeto.

298 Sistemas de banco de dados

Quando o objeto iterador é associado a uma consulta (linhas 11 e 12 da Figura 10.8), o programa busca o resultado da consulta do banco de dados e define o ite­ rador para uma posição antes da primeira linha no resultado da consulta. Esta se torna a linha atual para o iterador. Subsequentemente, operações next são emitidas sobre o objeto iterador. Cada next move o iterador para a linha seguinte no resul­ tado da consulta, tornando-a a linha atual. Se a linha existir, a operação recupera os valores de atributo para essa linha nas variáveis dc programa correspondentes. Sc não houver mais linhas, a operação next retorna NULL, c pode assim ser usada para controlar o looping. Observe que o iterador nomeado não precisa de uma cláusula INTO, pois as variáveis do programa correspondentes aos atributos recuperados já estão especificadas quando o tipo iterador é declarado (linha 9 da Figura 10.8). Na Figura 10.8, o comando (f.next()) na linha 13 realiza duas funções: recupera a próxima tupla no resultado da consulta e controla o loop while. Quando o programa termina o processamento do resultado da consulta, o comando f.close() (linha 16) fecha o iterador. A seguir, considere o mesmo exemplo usando iteradores posicionais, como mostra a Figura 10.9 (segmento dc programa J2B). A linha 9 da Figura 10.9 mostra como um tipo iterador posicionai Funcpos é declarado. A principal diferença entre ele c o iterador nomeado c que não existem nomes de atributo (correspondentes a nomes de variável de programa) no iterador posicionai — apenas tipos de atributo. Isso pode oferecer mais flexibilidade, mas torna o processamento do resultado da con­ sulta ligeiramente mais complexo. Os tipos dc atributo ainda devem scr compatíveis com os tipos dc atributo no resultado da consulta SQL e estar na mesma ordem. A linha 10 mostra como um objeto iterador posicionai f do tipo Funcpos é criado no programa e depois associado a uma consulta (linhas lie 12).

//Segmento de programa J2B: 0)

nome_departamento = readEntryC Digite o nome do departamento: ");

D

try {

#sql {SELECT Numero.departamento INTO : numero.dep

2)

FROM DEPARTAMENTO WHERE Nome_departamento = :nome_departamento};

3) 4)

} catch (SQLException se) {

5)

System.out.printing Departamento não existe: " + nome.departamento);

6)

return;

7)

)

8)

System.out.println(" Informação do funcionário para departamento: " + nome.departamento);

9)

#sql iterator Funcpos(String, String, String, String, double);

10)

Funcpos f = null;

11)

#sql f = {SELECT cpf, primeiro.nome, nome.meio, ultimo.nome, salario

FROM FUNCIONÁRIO WHERE Numero.departamento = : numero.dep);

12)

13)

#sql { FETCH :f INTO :cpf, :pnome, :nmeio, :unome, :sal};

14)

while (If.endFetch()) { System.out.println(cpf + " ’ + pnome + " " + nmeio + " " + unome + " " + sal);

15)

#sql { FETCH :f INTO :cpf, :pnome,:nmeio, :unome, :sal};

16)

17)

)

18)

f.closef);

Figura 10.9 Segmento de programa J2B, um segmento de programa em Java que usa um iterador posicionai para imprimir informações de funcionário em um determinado departamento.

Capitulo 10 Introdução às técnicas de programação SQL

O iterador posicionai se comporta de uma maneira mais parecida com a SQL embutida (ver Seção 10.2.2). Um comando FETCH INTO cvariáveis do programa> é necessário para colocar a tupla seguinte em um resultado de consulta. Na primeira vez em que fetch é executado, ele recupera a primeira tupla (linha 13 na Figura 10.9). A linha 16 recupera a tupla seguinte até que não haja mais tuplas no resultado da consulta. Para controlar o loop, uma função de iterador posi­ cionai f.endFetch() c utilizada. Essa função é definida para um valor TRUE quando o iterador é associado inicialmente a uma consulta SQL (linha 11), e é definida como FALSE toda vez que um comando de busca retorna uma tupla válida do resultado da consulta. Ela é definida como TRUE novamente quando um comando de busca não encontra mais tuplas. A linha 14 mostra como o looping é controlado pela negação.

10.3 Programação de banco de dados com chamadas de função e bibliotecas de classes: SQL/CLI e JDBC A SQL embutida (ver Seção 10.2) às vezes é chamada de técnica de programação de banco de dados estática, pois o texto da consulta é escrito no código-fonte do programa e não pode ser alterado sem uma nova compilação ou reproccssamento do código-fonte. O uso de chamadas de função é uma técnica mais dinâmica para programação de banco de dados que a SQL embutida. Já vimos uma técnica de progra­ mação dinâmica de banco de dados— SQL dinâmica — na Seção 10.2.3. As técnicas discutidas aqui oferecem outra abordagem para a programação dinâmica de banco de dados. Uma biblioteca de funções, também conhecida como interface dc programa­ ção de aplicação (API), é usada para acessar o banco de dados. Embora isso ofereça mais flexibilidade, pois nenhum pré-processador é necessário, uma desvantagem é que a sintaxe e outras verificações sobre comandos SQL precisam ser feiras em tempo de execução. Outra desvantagem é que isso às vezes requer uma programação mais complexa para acessar resultados da consulta, pois os tipos e os números de atributos cm um resultado dc consulta podem não scr conhecidos previamente. Nesta seção, damos uma visão geral dc duas interfaces dc chamada de função. Primeiro, discutimos a SQL Call Level Interface (SQL/CLI), que é parte do padrão SQL. Ela foi desenvolvida como uma padronização de uma biblioteca de funções, conhecida como ODBC (Open Database Connectivity). Usamos C como linguagem hospedeira cm nossos exemplos de SQL/CLI. Depois, oferecemos uma visão geral da JDBC, que é a interface de chamada de função para acessar bancos de dados com Java. Embora normalmente se considere que JDBC signifique Java Database Connectivity', trata-se apenas de uma marca registrada da Sun Microsystems (agora Oracle), nào de um acrônimo. A principal vantagem do uso de uma interface de chamada de função é que ela facilita o acesso a múltiplos bancos de dados no mesmo programa de aplicação, mesmo que eles sejam armazenados sob diferentes pacotes de SGBD. Discutiremos isso melhor na Seção 10.3.2, quando abordaremos a programação de banco de dados Java com JDBC, embora essa vantagem também se aplique à programação de banco de dados com SQL/CLI e ODBC (ver Seção 10.3.1).

10.3.1 Programação de banco de dados com SQL/CLI usando C como linguagem hospedeira Antes de usar as chamadas de função na SQL/CLI, é necessário instalar os pacotes de bibliotecas apropriados no servidor de banco de dados. Esses pacotes são obtidos

299

300 Sistemas de banco de dados com o vendedor do SGBD em uso. Agora, vamos apresentar uma visão geral de como a SQL/CLI pode ser usada em um programa em CJ3 Ilustraremos nossa apresenta­ ção com um exemplo de segmento de programa CLI1, mostrado na Figura 10.10. Tratamento para registro de ambiente, conexão, instrução e descrição. Ao usar a SQL/CLI, as instruções SQL são criadas dinamicamente e passadas como parâme­ tros de string nas chamadas de função. Logo, é necessário registrar as informações sobre as interações do programa hospedeiro com o banco de dados nas estruturas de dados em tempo de execução, pois os comandos do banco são processados em tempo de execução. A informação é mantida em quatro tipos de registros, repre­ sentados como structs em tipos de dados C. Um registro de ambiente é usado como recipiente para registrar uma ou mais conexões de banco de dados e definir infor­ mações de ambiente. Um registro de conexão registra as informações necessárias para determinada conexão de banco de dados. Um registro de instrução mantém as informações necessárias para uma instrução SQL. Um registro dc descrição mantem as informações sobre tuplas ou parâmetros — por exemplo, o número de atributos e seus tipos em uma tupla, ou o número e os tipos de parâmetros em uma chamada de função. Isso é necessário quando o programador não conhece essa informação sobre a consulta ao escrever o programa. Em nossos exemplos, supomos que o //Programa CLI1:

0)

#indude "sqldi.h"

1)

void imprimeSalarioí) {

2)

SQLHSTMT instl ;

3)

SQLHDBC con1 ;

4)

SQLHENV amb1 ;

5)

SQLRETURN ret1, ret2, ret3, ret4 ;

6)

ret1 = SQLAIIocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &amb1);

7)

if (Iretl) ret2 = SQLAllocHandle(SQL_HANDLE_DBC, amb1, &con1) else exit;

8)

if (Iret2) ret3 = SQLConnect(con1, "dbs", SQL.NTS, "js", SQL.NTS, "xyz", SQL.NTS) else exit;

9)

if (!ret3) ret4 = SQLAIIocHandle(SQL_HANDLE_STMT, coni, &inst1) else exit;

10)

SQLPrepare(inst1, "select Ultimo.nome, Salario from FUNCIONÁRIO where Cpf = ?", SQL_NTS);

11)

promptCDigite um número de CPF: ", cpf);

12)

SQLBindParameter(inst1, 1, SQL.CHAR, &cpf, 11, &fetchlen1);

13)

ret1 = SQLExecute(instl);

14)

if(!ret1){

15)

SQLBindCol(inst1, 1, SQL_CHAR, &ultimo_nome, 15, &fetchlenl);

16)

SQLBindCol(inst1,2, SQL_FLOAT, &salario, 4, &fetchlen2) ;

17)

ret2 = SQLFetch(inst1);

18)

if (1 ret2) printffcpf, ultimo.nome, salario)

else printf("O número do CPF não existe: ", cpf);

19)

}

20) 21)

}

Figura 10.10 Segmento de programa CU1, um segmento de programa em C com SQL/CLI.

13 Nossa discussão aqui também se aplica à linguagem de programação C++ e C#, pois não usamos nenhum dos recursos orientados a objeto, mas focalizamos o mecanismo de programação dc banco dc dados.

Capitulo 10 Introdução às técnicas de programação SQL programador conheça a consulta exata, de modo que nào mostramos quaisquer registros de descrição. Cada registro é acessível ao programa por meio de uma variável de ponteiro C — chamada tratamento (ou handle) do registro. O handle é retornado quando um registro é criado pela primeira vez. Para criar um registro e retomar seu handle, a seguinte função SQL é usada:

SQLAIIocHandle(, , ) Nessa função, os parâmetros são os seguintes: ■ indica o tipo do registro que está sendo criado. Os valores possíveis para este parâmetro são as palavras-chave SQL_HANDLE_ENV, SQL_HANDLE_DBC, SQL_HANDLE_STMT ou SQL_HANDLE_DESC, para um registro de ambiente, cone­ xão, instrução ou descrição, respectivamente. ■ indica o recipiente dentro do qual o novo handle está sendo criado. Por exemplo, para um registro de conexão, este seria o ambiente no qual a conexão está sendo criada, e para um registro de instrução, esta seria a conexão para essa instrução. ■ é o ponteiro (handle) para o registro recém-criado do tipo . Etapas em um programa de banco de dados. Ao escrever um programa em C que incluirá chamadas de banco de dados por meio da SQUCLI, as seguintes etapas típicas são tomadas. Ilustramos as etapas referindo-nos ao exemplo CI.I1 da Figura 10.10, que lê o número de Cpf de um funcionário e imprime seu sobrenome e salário.

1. Incluindo a biblioteca de funções. A biblioteca de funções compreendendo a SQU CLI deve ser incluída no programa C. Esta é chamada de sqlcli.h, e é incluída usando a linha 0 na Figura 10.10.

2.

Declarando variáveis de tratamento. Declare variáveis de tratamento dos tipos SQLHSTMT, SQLHDBC, SQLHENV e SQLHDESC para as instruções, conexões, ambientes e descrições necessárias no programa, respectivamente (linhas 2 a . 14 Também declare variáveis do tipo SQLRETURN (linha 5) para manter os 4) códigos de retorno das chamadas de função da SQUCLI. Um código de retorno 0 (zero) indica execução bem-sucedida da chamada de função.

3. Registro de ambiente. Um registro de ambiente deve ser configurado no pro­ grama usando SQLAIIocHandle. A função para fazer isso aparece na linha 6. Como um registro de ambiente não está contido em qualquer outro registro, o parâmetro é o handle NULL SQL_NULL_HANDLE (ponteiro NULL) quando se cria um ambiente. O handle (ponteiro) para o registro de ambiente recém-criado é retornado na variável amb1 na linha 6. 4. Concctando-sc ao banco dc dados. Um registro de conexão é configurado no programa usando SQLAIIocHandle. Na linha 7, o registro de conexão criado tem o handle coni e está contido no ambiente ambl. Uma conexão é então estabelecida em con1 para um servidor de banco de dados em particular usando a função SQLConnect da SQUCLI (linha 8). Em nosso exemplo, o nome do servidor de banco de dados ao qual estamos nos conectando é dbs e o nome de conta c senha para login são js e xyz, respectivamente. 5.

Registro dc instrução. Um registro de instrução é configurado no programa usando SQLAIIocHandle. Na linha 9, o registro dc instrução criado tem um handle inst! e usa a conexão con1.

14 Para manter nossa apresentação simples, não mostraremos os registros de descrição aqui.

301

302 Sistemas de banco de dados

6.

Preparando uma instrução SQL e parâmetros de instrução. A instrução é prepa­ rada usando a função SQL/CLI SQLPrepare. Na linha 10, isso atribui a string de instrução SQL (a consulta em nosso exemplo) ao handle inst 1. O símbolo de ponto de interrogação (?) na linha 10 representa um parâmetro de instrução, que é um valor a ser determinado em tempo de execução — normalmente, por seu vínculo com uma variável de programa em C. Em geral, poderia haver vários parâmetros na string da instrução. Eles são distinguidos pela ordem de aparecimento dos pontos de interrogação na string de instrução (o primeiro ? representa o parâmetro 1, o segundo ? representa o parâmetro 2, e assim por diante). O último parâmetro em SQLPrepare deveria dar o tamanho da string da instrução SQL em bytes, mas, se entrarmos com a palavra-chave SQL_NTS, isso indica que a string que mantém a consulta é uma string terminada em NULL, de modo que a SQL pode calcular seu tamanho automaticamente. Esse uso de SQL_NTS também se aplica a outros parâmetros de string nas chamadas de função em nossos exemplos.

7. Vinculando os parâmetros de instrução. Antes de executar a consulta, quaisquer parâmetros na string de consulta devem ser vinculados a variáveis do programa usando a função SQL/CLI SQLBindParameter. Na Figura 10.10, o parâmetro (indicado por ?) para a consulta preparada referenciada por inst 1 é vinculado à variável do programa em C cpf na linha 12. Se houver n parâmetros na instrução SQL, devemos ter n chamadas de função SQLBindParameter, cada uma com uma posição de parâmetro diferente (1,2,..., n). 8. Executando a instrução. Após essas preparações, podemos executar a instru­ ção SQL referenciada pelo handle inst 1 usando a função SQLExecute (linha 13). Observe que, embora a consulta seja executada na linha 13, seus resultados ainda não foram atribuídos a quaisquer variáveis do programa em C. 9.

Processando o resultado da consulta. Para determinar onde o resultado da con­ sulta é retornado, uma técnica comum é a abordagem de colunas vinculadas. Aqui, cada coluna em um resultado de consulta é vinculada a uma variável de programa em C usando a função SQLBindCol. As colunas são distinguidas por sua ordem de aparecimento na consulta SQL. Nas linhas 15 e 16 da Figura 10.10, as duas colunas na consulta (Ultimo_nome e Salario) são vinculadas às variáveis do programa em C ultimo_nome e salario, respectiva men te.15

10. Recuperando valores de coluna. Finalmente, para recuperar os valores de coluna nas variáveis de programa em C, usamos a função SQLFetch (linha 17). Essa função é semelhante ao comando FETCH da SQL embutida. Se um resultado de consulta tem uma coleção de tuplas, cada SQLFetch recebe a tupla seguinte e retoma seus valores dc coluna para as variáveis do programa vinculadas. A SQLFetch retorna um código de exceção (diferente de zero) se não houver mais tuplas no resultado da consulta.16

Como podemos ver, o uso de chamadas de função dinâmicas requer muita pre­ paração para configurar as instruções SQL e vincular parâmetros de instrução e resultados de consulta às variáveis de programa apropriadas.

*’ Uma tccnica alternativa, conhecida como colunas desvinculadas, utiliza diferentes funções SQL/CLI, a saber, SQLGetCol ou SQLGetData, para recuperar colunas do resultado da consulta sem vinculá-las previamente; estas são aplicadas após o comando SQLFetch na linha 17.

16 Sc forem usadas variáveis dc programa desvinculadas, a SQLFetch retorna a tupla cm uma área dc programa temporária. Cada SQLGetCol (ou SQLGetData) subsequente retoma um valor de atributo cm ordem. Basicamente, para cada linha no resultado da consulta, o programa deve percorrer os valores de atributo (colunas) nessa linha. Isso é útil se o número de colunas no resultado da consulta for variável.

Capitulo 10 Introdução às técnicas de programação SQL

303

Em CLI1, uma única tupla é selecionada pela consulta SQL. A Figura 10.11 mostra um exemplo da recuperação de múltiplas tuplas. Consideramos que as variáveis apropriadas do programa em C foram declaradas como na Figura 10.1.0 segmento de programa em CLI2 lê (solicita) um número de departamento e depois recupera os funcionários que nele trabalham. Um loop, então, percorre cada registro de funcionário, um de cada vez,e imprime o último nome e o salário do funcionário.

10.3.2 JDBC: biblioteca de classes SQL para programação Java z\gora, vamos voltar nossa atenção para o modo como a SQL pode ser chamada com base na linguagem de programação orientada a objeto Java.1 As bibliotecas de classes para esse acesso sào conhecidas como JDBC.17 18 A linguagem de programação Java foi projetada para ser independente de plataforma — ou seja, um programa //Segmento de programa CU2:

0)

#include "sqldi.h"

1)

void imprimeFuncionariosDep() {

2)

SQLHSTMT instl ;

3)

SQLHDBC con1;

4)

SQLHENV amb1 ;

5)

SQLRETURN ret1, ret2, ret3, ret4 ;

6)

ret1 = SQLAIIocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &amb1);

7)

if (!ret1) ret2 = SQLAIIocHandle(SQL_HANDLE_DBC, amb1, &con1) else exit;

8)

if (!ret2) ret3 = SQLConnect(con1, "dbs“, SQL.NTS, "js", SQL.NTS, "xyz", SQL-NTS) else exit;

9)

if (!ret3) ret4 = SQLAIIocHandle(SQL_HANDLE_STMT, coni, &inst1) else exit;

10)

SQLPrepare(inst1, “select Ultimo.nome, Salario from FUNCIONÁRIO where Numero.departamento = ?", SQL.NTS);

11)

promptí “ Digite o número do Departamento: “, numero_dep_fune);

12)

SQLBindParameter(inst1, 1, SQLJNTEGER, &numero_dep_func, 4, &fetchlen1);

13)

ret1 = SQLExecute(instl);

14)

if(!ret1){

15)

SQLBindCol(inst1, 1, SQL.CHAR, &ultimo_nome, 15, &fetchlen1); SQLBindCol(inst1, 2, SQL.FLOAT, &salario, 4, &fetchlen2);

16) 17)

ret2 = SQLFetch(instl);

18)

while (!ret2){

19)

printf(ultimo_nome, salario);

20)

ret2 = SQLFetch(instl);

}

21)

)

22) 23)

)

Figura 10.11 Segmento de programa CU2, um segmento de programa em C que usa SQL/CU para uma consulta com uma coleção de tuplas em seu resultado.

17 Esta seção pressupõe uma familiaridade com conceitos orientados a objeto (ver Capítulo 1 li e con­ ceitos básicos dc Java. 18 Como já dissemos, JDBC é uma marca registrada da Sun Microsystems, embora normalmente seja considerado um acrônimo para Java Database Connectivity

304 Sistemas de banco de dados deve ser capaz de rodar em qualquer tipo de sistema de computador que tenha um interpretador Java instalado. Em razão dessa portabilidade, muitos fornecedores de SGBDR oferecem drivers JDBC de modo que seja possível acessar seus sistemas por meio de programas Java.

Drivers JDBC. Um driver JDBC é basicamente uma implementação das classes e objetos associados e chamadas de função especificadas na JDBC para o SGBDR de determinado fornecedor. Logo, um programa Java com objetos e chamadas de função JDBC pode acessar qualquer SGBDR que tenha um driver JDBC disponível. Como a Java é orientada a objeto, suas bibliotecas de função são implementadas como classes. Antes de ser capaz dc processar chamadas dc função JDBC com Java, é necessário importar as bibliotecas de classes JDBC, que se chamam java.sql. *. Estas podem ser baixadas e instaladas pela web. A JDBC foi elaborada para permitir que um único programa Java se conecte a vários bancos dc dados diferentes. Estes às vezes são chamados dc fontes dc dados acessadas pelo programa Java, e poderíam ser armazenadas usando SGBDRs dc diferentes vendedores, residindo em diferentes máquinas. Logo, variados acessos a fontes de dados no mesmo programa Java podem exigir drivers JDBC de diferentes vendedores. Para alcançar essa flexibilidade, uma classe JDBC especial, chamada classe gerenciadora de driver, é empregada e registra os drivers instalados. Um dri­ ver deve ser registrado no gerenciador de driver antes de ser usado. As operações (métodos) da classe gerenciadora de driver incluem getDriver, registerDriver e deregisterDriver. Estas podem ser usadas para acrescentar e remover drivers dinamicamente para diferentes sistemas. Outras funções configuram e fecham conexões com fontes de dados. Para carregar um driver JDBC dc maneira explícita, pode scr usada a função Java genérica para carregar uma classe. Por exemplo, para carregar o driver JDBC para o SGBDR da Oracle, o comando a seguir pode ser usado: C lass.forName(" orade.jdbc.driver OracleDriver") Isso registrará o driver no gerenciador e o tornará disponível ao programa. Também é possível carregar c registrar os drivers necessários na linha de comandos que executa o programa, por exemplo, ao incluir o seguinte na linha de comando:

-Djdbc.drivers = oracle .jdbc.d river Etapas de programação em JDBC. A seguir, vemos as etapas típicas realizadas ao escrever um programa de aplicação Java com acesso a banco de dados por meio de chamadas dc função JDBC. Ilustramos as etapas nos referindo ao exemplo JDBC1 da Figura 10.12, que lê um número de Cpf dc um funcionário c imprime o último nome e o salário dele. 1. Importar a biblioteca de classes JDBC. A biblioteca de classes JDBC precisa ser importada para o programa Java. Essas classes são chamadas de * , java.sql. e podem ser importadas usando a linha 1 da Figura 10.12. Quaisquer bibliotecas de classe Java adicionais necessárias pelo programa também devem ser importadas.

2. Carregar o driver JDBC. Isso é mostrado nas linhas 4 a 7. A exceção Java na linha 5 ocorre se o driver não for carregado com sucesso. 3. Criar variáveis apropriadas. Estas são as variáveis necessárias no programa Java (linhas 8 c 9). 4. O objeto Connection. Um objeto dc conexão c criado usando a função getConnection da classe DriverManager do JDBC. Nas linhas 12 c 13, o objeto Connection é criado usando a chamada de função getConnection(urlstring), na qual uristring tem a forma

Capitulo 10 Introdução às técnicas de programação SQL //Programa JDBC 1:

0)

import java.io. * ;

1)

import * java.sql. ;

2)

class ObterlnfFunc {

public static void main (String args []) throws SQLException, lOException {

3) 4)

try {Class.forNameCoracle.jdbc.driver.OracleDriver’)

5)

) catch (ClassNotFoundException x) { System.out.println ("Driver não pode ser carregado');

6) 7)

}

8)

String usuariodb, senha, cpf, ultimo_nome;

9)

Double salario;

10)

usuariodb= readEntry(" Digite o usuário do banco de dados:');

11) 12)

senha = readEntryU Digite a senha:'); Connection con = DnverManager.getConnection ('jdbc:oracle:oci8:' + usuariodb + '/' + senha);

13)

14)

String inst 1 = “select Ultimo_nome, Salario from FUNCIONÁRIO where Cpf = ?" ;

15)

PreparedStatement p = conn.prepareStatement(inst1);

16)

cpf = readEntry(“Digite um número de CPF: ');

17)

p.dearParameters();

18)

p.setString(1, cpf);

19)

ResultSet r = p.executeQuery();

20)

while (r.next()) {

21)

Ultimo.nome = r.getString(1);

22)

salario = r.getDouble(2);

System.outprintln(ultimo_nome + salario);

23)

}

24) 25)

}

Figura 10.12 Segmento de programa JDBC1, um segmento de programa em Java com JDBC.

jdbc:orade::/ Uma forma alternativa é getConnection(url, usuariodb, senha)

Várias propriedades podem ser definidas para um objeto de conexão, mas elas são relacionadas principalmente a propriedades transicionais, que discutiremos no Capítulo 21. 5. O objeto PreparedStatement. Um objeto de instrução é criado no programa. Em JDBC, existe uma classe de instrução básica. Statement, com duas subclas­ ses especializadas: PreparedStatement e CallableStatement. O exemplo da Figura 10.12 ilustra como objetos PreparedStatement são criados e usados. O próximo exemplo (Figura 10.13) ilustra o outro tipo de objetos Statement. Na linha 14 da Figura 10.12, uma string de consulta com um único parâmetro — indicado pelo símbolo ? — é criada na variável de string instl. Na linha 15, um objeto

305

306 Sistemas de banco de dados //Program Segment JDBC2: 0)

import java.io. * ;

1)

import * java.sql. ;

2)

class imprimeFuncsDepartamento {

public static void main (String args [ ]) throws SQLException, lOException {

3) 4)

try {Class.forName(" orade.jdbc.driver.OradeDriver ")

5)

) catch (ClassNotFoundException x) { System.out.println ("Driver nào pode ser carregado");

6)

}

7) 8)

String usuariodb, senha, ultimo.nome;

9)

Double salario;

10)

Integer numero_dep_func ;

11)

usuariodb = readEntry(" Digite o usuário do banco de dados:");

12)

senha = readEntry(" Digite a senha: ’);

13)

Connection con = DriverManager.getConnection

("jdbc:oracle:oci8:“ + usuariodb + “/“ + senha);

14) 15)

numero_dep_func = readEntryC Digite o número do departamento: ");

16)

String q = "select Ultimo.nome, Salario from FUNCIONÁRIO where numero.dep.func = " + numero_dep_func.tostring();

17)

Statement s = con.createStatement();

18)

ResultSet r = s.executeQuery(q);

19)

while (r.next()) {

20)

ultimo.nome = r.getString(1);

21)

salario = r.getDouble(2);

System.out.println(ultimo_nome + salario);

22)

}

23) 24)

}

Figura 10.13 Segmento de programa JDBC2, um segmento de programa que usa JDBC para uma consulta com uma coleção de tuplas em seu resultado. p do tipo PreparedStatement é criado com base na string de consulta em inst 1 e usando o objeto de conexão con. Em geral, o programador deve usar objetos PreparedStatement se uma consulta tiver de ser executada múltiplas vezes, pois ela seria preparada, verificada e compilada apenas uma vez, economizando assim esse custo para execuções adicionais da consulta.

6. Definindo os parâmetros dc instrução. O ponto de interrogação (?) na linha 14 representa um parâmetro dc instrução, que c um valor a ser determinado em tempo de execução, nonnalmcnte vinculando-o a uma variável dc programa Java. Em geral, poderia haver vários parâmetros, distinguidos pela ordem de aparecimento dos pontos de interrogação na string de instrução (o primeiro ? representa o parâmetro 1, o segundo ? representa o parâmetro 2, e assim por diante), conforme discutimos anteriormente. 7. Vinculando os parâmetros dc instrução. Antes de executar uma consulta PreparedStatement, quaisquer parâmetros devem ser vinculados a variáveis do

Capitulo 10 Introdução às técnicas de programação SQL

programa. Dependendo do tipo do parâmetro, diferentes funções, como set-

String, setinteger, setDouble, c assim por diante, podem scr aplicadas ao objeto PreparedStatement para definir seus parâmetros. A função apropriada deve scr usada para corresponder ao tipo dc dado do parâmetro que está sendo definido. Na Figura 10.12, o parâmetro (indicado por ?) no objeto p é vinculado à variável de programa Java cpf na linha 18. A função setString é utilizada porque cpf é uma variável de string. Sc houver n parâmetros na instrução SQL, devemos ter n funções set..., cada uma com uma posição dc parâmetro diferente (1,2,..., n). Geralmente, é aconselhável limpar todos os parâmetros antes de definir quaisquer valores novos (linha 17).

8. Executando a instrução SQL. Após essas preparações, podemos executar a ins­ trução SQL referenciada pelo objeto p usando a função executeQuery (linha 19). Existe uma função genérica execute em JDBC, mais duas funções especializadas: executeUpdate e executeQuery. A executeUpdate c utilizada para instruções insert, delete ou update da SQL, c retorna um valor inteiro indicando o número dc tuplas que foram afetadas. A executeQuery é empregada para instruções de recuperação SQL e retorna um objeto do tipo ResuItSet, que vamos discutir na sequência.

9. Processando o objeto ResuItSet. Na linha 19, o resultado da consulta é retornado em um objeto r do ripo ResuItSet. Isso é semelhante a um array bidimensional ou a uma tabela, na qual as tuplas são as linhas e os atributos retornados são as colunas. Um objeto ResuItSet é semelhante a um cursor na SQL embutida e um iterador em SQLJ. Em nosso exemplo, quando a consulta é executada, r refere-se a uma tupla antes da primeira tupla no resultado da consulta. A função r.nextO (linha 20) se move para a próxima tupla (linha) no objeto ResuItSet e retorna NULL se não houver mais objetos. Isso serve para controlar o looping. O programador pode se referir aos atributos na tupla atual usando diversas funções get..., que dependem do tipo de cada atributo (por exemplo, getString,getlnteger, getDouble, e assim por diante). O programador pode usar tanto as posições dc atributo (1,

2) como os nomes de atributo reais ("Ultimo_nome", "Salario") com as funções get... Em nossos exemplos, usamos a notação posicionai nas linhas 21c 22.

Em geral, o programador pode verificar exceções SQL depois de cada chamada de função JDBC. Não fizemos isso para simplificar os exemplos. Observe que a JDBC não distingue consultas que retornam tuplas isoladas daquelas que retornam múltiplas tuplas, diferentemente de algumas outras técnicas. Isso é justificável porque um conjunto de resultados de única tupla é apenas um caso especial. No Exemplo JDBC1, uma única tupla é selecionada pela consulta SQL, de modo que o loop nas linhas 20 a 24 é executado no máximo uma vez. O exemplo mostrado na Figura 10.13 ilustra a recuperação de múltiplas tuplas. O segmento de programa

em JDBC2 lê (solicita) um número de departamento e depois recupera os funcio­ nários que trabalham nesse departamento. Um loop, então, percorre cada registro de funcionário, um de cada vez, e imprime o sobrenome e o salário de cada um. Esse exemplo também ilustra como podemos executar uma consulta diretamente, sem ter dc prepará-la, como no exemplo anterior. Essa técnica é preferível para consultas que serão executadas apenas uma vez, pois é mais simples de programar. Na linha 17 da Figura 10.13, o programador cria um objeto Statement (em vez de um PreparedStatement, como no exemplo anterior) sem associá-lo a uma string

dc consulta cm particular. A string dc consulta q é passada ao objeto de instrução s ao scr executada na linha 18.

307

308 Sistemas de banco de dados Isso conclui nossa breve introdução à JDBC. O leitor interessado deve consultar o website , que contém muitos outros detalhes sobre essa linguagem.

10.4 Procedimentos armazenados de banco de dados e SQL/PSM Esta seção introduz dois tópicos adicionais relacionados à programação de banco de dados. Na Seção 10.4.1, vamos discutir o conceito de procedimentos armazenados, que são módulos de programa armazenados pelo SGBD no servi­ dor de banco de dados. Depois, na Seção 10.4.2, vamos abordar as extensões à SQL especificadas no padrão para incluir construções de programação de uso geral em SQL. Essas extensões são conhecidas como SQL/PSM (SQL/Persistent Stored Modules) e podem ser usadas para escrever procedimentos armazenados. A SQL/PSM também serve como exemplo de uma linguagem de programação dc banco dc dados que estende um modelo de banco de dados e linguagem — a saber, a SQL — com algumas construções de programação, como instruções condicionais e loops.

10.4.1 Procedimentos e funções armazenados de banco de dados Em nossa apresentação das técnicas de programação de banco de dados até aqui, houve uma suposição implícita dc que o programa de aplicação de banco de dados estava rodando em uma máquina cliente ou, mais provavelmente, no computador do servidor de aplicação na camada intermediária de uma arquite­ tura cliente-servidor de três camadas (ver Seção 2.5.4 e Figura 2.7). Em ambos os casos, a máquina em que o programa está executando é diferente da máquina em que o servidor de banco de dados — e a parte principal do pacote de software de SGBD — está localizado. Embora isso seja adequado para muitas aplicações, às vezes é útil criar módulos de programa dc banco de dados — procedimentos ou funções — que são armazenados e executados pelo SGBD no servidor de banco de dados. Estes são historicamente conhecidos como procedimentos armazenados (ou stored procedures) do banco de dados, embora possam ser funções ou proce­ dimentos. O termo usado no padrão SQL para os procedimentos armazenados é módulos armazenados persistentes, porque esses programas são armazenados persistentemente pelo SGBD, de modo semelhante aos dados persistentes arma­ zenados pelo SGBD. Os procedimentos armazenados são úteis nas seguintes circunstâncias: ■ Sc um programa de banco de dados é necessário por várias aplicações, ele pode ser armazenado no servidor e invocado por qualquer um dos programas de aplicação. Isso reduz a duplicação de esforço e melhora a modularidade do software. ■ A execução de um programa no servidor pode reduzir a transferência de dados e o custo de comunicação entre o cliente e o servidor em certas situações. ■ Esses procedimentos podem melhorar o poder de modelagem fornecido pelas visões ao permitir que tipos mais complexos de dados derivados estejam dispo­ níveis aos usuários do banco de dados por meio de procedimentos armazenados. Além disso, eles podem ser usados para verificar restrições complexas que estão além do poder dc especificação dc asserções c triggers.

Em geral, muitos SGBDs comerciais permitem que procedimentos e funções armazenados sejam escritos em uma linguagem de programação de uso geral. Como

Capitulo 10 Introdução às técnicas de programação SQL

alternativa, um procedimento armazenado pode ser feito de comandos SQL simples, como recuperações e atualizações. O formato geral da declaração de procedimentos armazenados é o seguinte: CREATE PROCEDURE cnome do procedimento> () cdeclarações locais> ccorpo do procedimento;

Os parâmetros e as declarações locais são opcionais e especificados apenas se necessário. Para declarar uma função, um tipo de retorno é necessário, de modo que o formato da declaração é CREATE FUNCTION cnome da função> (cparâmetros>) RETURNS ctipo de retorno> cdeclarações locais> ccorpo da função>; Se o procedimento (ou função) for escrito em uma linguagem de programação de uso geral, é comum especificar a linguagem e também um nome de arquivo em que o código do programa é armazenado. Por exemplo, o formato a seguir pode ser utilizado:

CREATE PROCEDURE cnome do procedimento> (cparâmetros>) LANGUAGE cnome da linguagem de programação> EXTERNAL NAME cnome do caminho do arquivo> ;

Em geral, cada parâmetro deve ter um tipo dc parâmetro, o qual c um dos tipos de dados da SQL. Cada parâmetro também deve ter um modo dc parâmetro, que é um dentre IN, OUT ou INOUT. Estes correspondem a parâmetros cujos valores são apenas de entrada, apenas dc saída (retornados) ou de entrada e saída, respectivamente. Como os procedimentos c funções são armazenados dc maneira persistente pelo SGBD, deve ser possível chamá-los das várias interfaces SQL e linguagens de programação. A instrução CALL no padrão SQL pode ser usada para chamar um procedimento armazenado — ou por uma interface interativa, ou SQLJ ou SQL embutida. O formato da instrução é o seguinte: CALL cnome do procedimento ou funçâo> (clista de argumentos>); Se essa instrução for chamada da JDBC, ela deve ser atribuída a um objeto dc instrução do tipo CalIableStatement (ver Seção 10.3.2).

10.4.2 SQL/PSM: estendendo a SQL para especificar módulos armazenados persistentes A SQL/PSM é a parte do padrão SQL que especifica como escrever módulos armazenados persistentes. Ela inclui as instruções para criar funções e procedimen­ tos que descrevemos na seção anterior. Também inclui construções de programação adicionais para melhorar o poder da SQL com a finalidade de escrever o código (ou o corpo) dos procedimentos c funções armazenados. Nesta seção, vamos discutir as construções SQL/PSM para instruções condicionais (desvio) c para instruções de looping. Estas darão uma ideia do tipo de construção que a SQL/PSM incorporou.19 Depois, oferecemos um exemplo para ilustrar como essas construções podem ser usadas. A instrução de desvio condicional na SQL/PSM tem a seguinte forma:

19 Só oferecemos uma breve introdução à SQL/PSM aqui. Existem muitos outros recursos no padrão SQL/PSM.

309

310 Sistemas de banco de dados IF THEN clista de instruções>

ELSEIF THEN clista de instruções> ELSEIF THEN clista de instruções> ELSE dista de instruções> END IF;

Considere o exemplo da Figura 10.14, que ilustra como a estrutura de desvio condicional pode ser usada em uma função SQL/PSM. A função retoma um valor de string (linha 1) descrevendo o tamanho dc um departamento em uma empresa com base no número de funcionários. Existe um parâmetro inteiro IN, numdep, que indica um número de departamento. Uma variável local Total_de_funcs é declarada na linha 2. A consulta nas linhas 3 e 4 retorna o número de funcionários no departamento, e o desvio condicional nas linhas 5 a 8 então retorna um dos valores (‘ENORME’, ‘* , GRANDE ‘MEDIO’,‘PEQUENO’), com base no número de funcionários. A SQL/PSM tem várias construções para looping. Existem estruturas de looping padrão while c repeat, com as seguintes formas: WHILE ccondição> DO clista de instruções> END WHILE ; REPEAT clista de instruções> UNTIL END REPEAT; Há também uma estrutura de looping baseada em cursor. A lista de instruções em tal loop é executada uma vez para cada tupla no resultado da consulta. Esta tem a seguinte forma:

FOR END FOR ;

Os loops podem ter nomes, e existe uma instrução LEAVE cnome do loop> para parar um loop quando uma condição é satisfeita. A SQL/PSM tem muitos outros recursos, mas eles estão fora do escopo de nossa apresentação. //Função PSM1: 0)

CREATE FUNCTION Tamanho_dep(IN numdep INTEGER)

1)

RETURNS VARCHAR [7]

2)

DECLARE Total_de_funcs INTEGER ;

3)

SELECT *COUNT( )

4)

FROM FUNCIONÁRIO WHERE Numero.departamento = numdep ;

5)

IF Total_de_funcs > 100 THEN RETURN " ENORME"

6)

ELSEIF Total_de_funcs > 25 THEN RETURN “GRANDE “

7)

ELSEIF Total_de_funcs > 10 THEN RETURN “MEDIO-

8)

ELSE RETURN “PEQUENO-

9)

END IF;

INTO Total_de_funcs

Figura 10.14 Declarando uma função em SQL/PSM.

Capitulo 10 Introdução às técnicas de programação SQL

10.5 Comparando as três técnicas Nesta seção, comparamos rapidamente as três técnicas para programação de banco de dados e discutimos as vantagens e desvantagens de cada uma. 1. Técnica da SQL embutida. A principal vantagem desta técnica é que o texto da

consulta faz parte do próprio código-fonte do programa e, portanto, é possível verificar erros de sintaxe e validar contra o esquema do banco de dados em tempo de compilação. Isso também torna o programa bastante legível, pois as consultas são pronramente visíveis no código-fonte. As principais desvantagens são a perda de flexibilidade na mudança da consulta em tempo de execução e o fato de que todas as mudanças nas consultas devem passar pelo processo inteiro de recompilação. Além disso, como as consultas são conhecidas de antemão, a escolha de variáveis de programa para manter os resultados da consulta é uma tarefa simples e, dessa forma, a programação da aplicação costuma ser mais fácil. Porém, para aplicações complexas em que as consultas precisam ser geradas em tempo de execução, a técnica de chamada dc função será mais adequada.

2. Técnica da biblioteca de classes e chamadas de função. Esta técnica oferece mais flexibilidade porque as consultas podem ser geradas em tempo de execução, se necessário. Contudo, isso leva a uma programação mais complexa, visto que as variáveis do programa que combinam com as colunas no resultado da consulta podem não ser conhecidas de antemão. Como as consultas são passadas como strings de instrução nas chamadas de função, nenhuma verificação pode ser feita cm tempo dc compilação. Toda verificação dc sintaxe c validação dc consulta precisa ser feita em tempo de execução, pela preparação da consulta, e o pro­ gramador deve verificar e levar em conta possíveis erros adicionais em tempo de execução no código do programa. 3. Técnica da linguagem dc programação dc banco dc dados. Esta técnica não sofre do problema de divergência de impedância, pois os tipos de dados da linguagem dc programação são os mesmos que os tipos de dados do banco dc dados. Porém, os programadores precisam aprender uma nova linguagem dc programação, cm vez dc usar uma linguagem com a qual já estão familiarizados. Além disso, algumas linguagens de programação de banco de dados são específicas do ven­ dedor, ao passo que as de uso geral podem funcionar facilmente com sistemas de diversos vendedores.

10.6 Resumo Neste capítulo, apresentamos recursos adicionais da linguagem de banco de dados SQL. Em particular, apresentamos uma visão geral das técnicas mais importantes para programação de banco de dados na Seção 10.1. Depois, discutimos as diversas técnicas para a programação de aplicação de banco de dados nas seções 10.2 a 10.4. Na Seção 10.2, discutimos a técnica geral conhecida como SQL embutida, na qual as consultas fazem parte do código-fonte do programa. Um pré-compilador normalmente é usado para extrair comandos SQL do programa, para processamento pelo SGBD, e substituindo-os pelas chamadas de função ao código compilado do SGBD. Apresentamos uma visão geral da SQL embutida, usando a linguagem de programação C como linguagem hospedeira cm nossos exemplos. Também discuti­ mos a técnica SQLJ para embutir SQL em programas Java. Os conceitos de cursor (para a SQL embutida) e iterador (para a SQLJ) foram apresentados e ilustrados com exemplos para mostrar como eles são usados para percorrer as tuplas em um

311

312 Sistemas de banco de dados resultado de consulta e extrair o valor do atributo de variáveis do programa, para processamento posterior. Na Seção 10.3, discutimos como as bibliotecas de chamada de função podem ser usadas para acessar bancos de dados SQL. Essa técnica é mais dinâmica que a SQL embutida, mas requer programação mais complexa porque os tipos e o número de atributos em um resultado de consulta podem ser determinados em tempo de exe­ cução. Uma visão geral do padrão SQL/CLI foi apresentada, com exemplos usando C como a linguagem hospedeira. Discutimos algumas das funções na biblioteca SQL/CLI, como as consultas são passadas como strings, como os parâmetros de consulta são atribuídos em tempo de execução e como os resultados são retornados às variáveis do programa. Depois, demos uma visão geral da biblioteca de classes JDBC, que é usada em Java, e abordamos algumas de suas classes e operações. Em particular a classe ResuItSet é utilizada para criar objetos que mantêm os resultados da consulta, que podem então ser percorridos pela operação next(). As funções get e set, para recuperar valores de atributo e definir valores de parâmetro, também foram discutidas. Na Seção 10.4, falamos rapidamente sobre os procedimentos armazenados e dis­ cutimos a SQL/PSM como um exemplo de linguagem de programação dc banco de dados. Por fim, comparamos brevemente as três técnicas na Seção 10.5. E importante observar que escolhemos dar uma visão geral comparativa das três técnicas principais para programação de banco de dados, pois o estudo de uma técnica em particular cm profundidade é um assunto que mcrccc scr abordado cm um livro inteiro.

PERGUNTAS DE REVISÃO -----------------------------------------------------------------------10.1. 10.2. 10.3. 10.4. 10.5. 10.6.

O que é ODBC? Qual é sua relação com a SQL/CLI? O que é JDBC? Ela é um exemplo de SQL embutida ou de uso de chamadas de função? Liste as três técnicas principais para programação de banco de dados. Quais são as vantagens e desvantagens de cada uma? O que é o problema da divergência de impedância? Qual das três técnicas de programação minimiza esse problema? Descreva o conceito dc um cursor e como ele é usado na SQL embutida. Para que é usada a SQLJ? Descreva os dois tipos dc iteradores disponíveis na SQLJ.

EXERCÍCIOS-----------------------------------------------------------------------------------------------

10.7.

10.8. 10.9.

Considere o banco dc dados mostrado na Figura 1.2, cujo esquema é mos­ trado na Figura 2.1. Escreva um segmento de programa para ler o nome de um aluno e imprimir sua média de notas, considerando que A = 4, B = 3, C = 2 e D = 1 ponto. Use a SQL embutida com C como linguagem hospedeira. Repita o Exercício 10.7, mas use a SQLJ com Java como linguagem hospedeira. Considere o esquema dc banco de dados relacionai de biblioteca da Figura 6.6. Escreva um segmento dc programa que recupere a lista dc livros que ficaram cm atraso ontem e que imprima o título do livro e o nome dc quem pegou cada um emprestado. Use a SQL embutida e C como a linguagem hospedeira.

Capitulo 10 Introdução às técnicas de programação SQL

10.10. Repita o Exercício 10.9, mas use SQLJ com Java como linguagem hospedeira. 10.11. Repita os exercícios 10.7 e 10.9, mas use SQL/CLI com C como linguagem hospedeira. 10.12. Repita os exercícios 10.7 e 10.9, mas use JDBC com Java como linguagem hospedeira. 10.13. Repita o Exercício 10.7, mas escreva uma função em SQL/PSM. 10.14. Crie uma função em PSM que calcule o salário médio para a tabela FUNCIONÁRIO mostrada na Figura 5.5.

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Existem muitos livros que descrevem os diversos aspectos da programação de banco de dados em SQL. Por exemplo, Sunderraman (2007) descreve a programação no SGBD Oracle lOg e Reese (1997) foca a JDBC e a programação Java. Muitos recursos também estão disponíveis na web.

313

Programação de banco de dados web usando PHP o capítulo anterior, fornecemos uma visão geral das técnicas de programa­ ção de banco de dados utilizando linguagens de programação tradicionais, e usamos as linguagens Java e C em nossos exemplos. Agora, vamos voltar nossa atenção para o modo como os bancos de dados são acessados a partir dc linguagens dc scripting. Muitas aplicações da internet, que oferecem interfaces web para acessar informações armazenadas em um ou mais bancos de dados, utilizam linguagens de scripting. Essas linguagens normalmente são usadas para gerar docu­ mentos HTML, que são então exibidos pelo navegador web para interação com o usuário. Em nossa apresentação, consideramos que o leitor já esteja familiarizado com os conceitos básicos de HTX1L. A HTML básica é útil para gerar páginas web estáticas com texto fixo e outros obje­ tos, mas a maioria das aplicações da internet exige páginas web que oferecem recursos interativos com o usuário. Por exemplo, considere o caso de um cliente de companhia aérea que deseja verificar as informações de hora e portão de chegada de um determinado voo. O usuário pode inserir informações como data e número de voo em certos campos da página web. A interface web enviará essa informação ao programa de aplicação, que formula e submete uma consulta ao servidor de banco de dados da companhia aérea para recuperar a informação de que o usuário precisa. A informação do banco de dados é retomada à página web para exibição. Essas páginas, nas quais parte da informação é extraída dc bancos ou de outras fontes dc dados, são denominadas páginas web dinâmicas. Os dados extraídos e exibidos a cada vez serão para diferentes voos c datas. Existem várias técnicas para a programação de recursos dinâmicos nas páginas web. Vamos focar em uma técnica aqui, que é baseada no uso da linguagem de scripting do lado do servidor de código aberto PHP. Originalmente, PHP significava Personal Home Page, mas agora significa PHP Hypertext Processor. A PHP passou a ser bastante utilizada. Os interpretadores para PHP são fornecidos gratuitamente e escritos na linguagem C, de modo que estão disponíveis na maioria das plataformas

N

316 Sistemas de banco de dados de computador. Um interpretador PHP oferece um pré-processador de hipertexto, que executará comandos PHP em um arquivo de texto e criará o arquivo HTML desejado. Para acessar bancos de dados, uma biblioteca de funções PHP precisa ser incluída no interpretador PHP, conforme discutiremos na Seção 11.3. Os programas PHP são executados no servidor web. Isso é diferente de algumas linguagens de scripting, como o JavaScript, que são executadas no computador cliente. Existem muitas outras linguagens de scripting populares, que podem ser usadas para acessar bancos de dados e criar páginas web dinâmicas, como JavaScript, Ruby, Python e PERL, para citar apenas algumas. Este capítulo é organizado da seguinte forma. A Seção 11.1 contém um exemplo simples para ilustrar como a PHP pode ser utilizada. A Seção 11.2 oferece uma visão geral da linguagem PHP e como ela é usada para programar algumas funções básicas para páginas web interativas. A Seção 11.3 focaliza o uso da PHP para interagir com bancos de dados SQL por meio de uma biblioteca de funções conhecida como PEAR DB. A Seção 11.4 lista algumas das tecnologias adicionais associadas a Java para programação web e de banco de dados (já discutimos sobre JDBC e SQLJ no Capítulo 10). Por fim, a Seção 11.5 contém um resumo do capítulo.

11.1 Um exemplo simples em PHP A PHP é uma linguagem de scripting de uso geral com código aberto. O meca­ nismo interpretador da PHP é escrito na linguagem de programação C, de modo que pode ser utilizado em quase todos os tipos de computadores e sistemas opera­ cionais. A PHP normalmente vem instalada com o sistema operacional UNIX. Para plataformas de computação com outros sistemas operacionais, como Windows, Linux ou Nlac OS, o interpretador PHP pode ser baixado em . Assim como outras linguagens de scripting, a PHP é particularmentc adequada para a manipulação de páginas de texto, e em particular para a manipulação de páginas HTML dinâmicas no servidor web. Isso é diferente da JavaScript, que é baixada com as páginas web para execução no computador cliente. A PHP possui bibliotecas dc funções para acessar bancos dc dados armazenados em diversos tipos de sistemas de bancos de dados relacionais, como Oracle, MySQL, SQLServer e em qualquer sistema que suporta o padrão ODBC (ver Capítulo 10). Sob a arquitetura de três camadas (ver Capítulo 2), o SGBD residiría no servidor de banco de dados da camada inferior. A PHP seria executada no servidor web da camada intermediária, cm que os comandos de programa em PHP manipulariam os arquivos HTML para criar as páginas web dinâmicas personalizadas. A HTML é então enviada à camada cliente para exibição e interação com o usuário. Considere o exemplo mostrado na Figura 11.1(a), que pede que um usuário informe o nome e o último nome e depois imprime uma mensagem de boas-vindas a ele. Os números dc linha não fazem parte do código do programa; eles são utilizados a seguir apenas como referência para a explicação: 1. Suponha que o arquivo contendo o script em PHP no segmento de programa PI esteja armazenado no seguinte local da internet: . Então, se um usuário digita esse endereço no navegador; o interpretador PHP começa a interpretar o código e a produzir o formulário mostrado na Figura 11.1(b). Explicaremos como isso acontece enquanto exami­ namos as linhas no segmento dc código Pl.

Capítulo 11

Programação de banco de dados web usando PHP

(a) //Segmento de programa P1:

0)



ProdutoX 1 Santo_Andre 5

12345678966 Silva 32,5

45345345376 Joice 20,0

ProdutoY 2 ltu 5

12345678966 7.5

45345345376 2 0,0

33344555587 10,0



de folha representam elementos simples. E por isso que o modelo XML é conhecido como um modelo de árvore ou modelo hierárquico. Na Figura 13.3, os elementos simples sâo aqueles com nomes de tag , , , , , , e . Os elementos complexos sào aqueles com nomes de tag , e . Em geral, nào existe limite sobre os níveis de aninhamento dos elementos. E possível caracterizar três tipos principais de documentos XML: ■ Documentos XML centrados em dados. Esses documentos possuem muitos itens de dados pequenos que seguem uma estrutura específica e, portanto, podem ser extraídos de um banco de dados estruturado. Eles sào formatados como docu­ mentos XML a fim de trocá-los pela web ou exibi-los nela. Estes normalmente seguem um esquema predefinido, que define os nomes de tag. ■ Documentos XML centrados no documento. Estes sào documentos com grande quantidade de texto, como artigos de notícias ou livros. Há poucos ou nenhum elemento de dado estruturado nesses documentos. ■ Documentos XML híbridos. Esses documentos podem ter partes que contêm dados estruturados e outras partes predominantemente textuais ou nào estrutu­ radas. Podem ou não ter um esquema predefinido.

391

Figura 13.3 Um elemento XML complexo, chamado .

392 Sistemas de banco de dados Documentos XML que nào seguem um esquema predefinido de nomes de ele­ mento e estrutura de árvore correspondente sào conhecidos como documentos XML sem esquema. E importante observar que os documentos XML centrados nos dados podem ser considerados dados semiestruturados ou estruturados, conforme definido na Seção 13.1. Se um documento XML obedece a um esquema XML predefinido ou DTD (ver Seçào 13.3), esse documento pode ser considerado dados estruturados. Além disso, a XML permite documentos que não obedecem a qualquer esquema. Estes seriam considerados dados semiestruturados e são documentos XML sem esquema. Quando o valor do atributo standalone em um documento XML é yes, como na primeira linha da Figura 13.3, o documento é independente e sem esquema. Os atributos XML geralmenre sào usados de maneira semelhante à da HTML (ver Figura 13.2), a saber, para descrever propriedades e características dos elementos (tags) nas quais eles aparecem. Também é possível usar atributos XML para manter os valores de elementos de dados simples; porém, isso não costuma ser recomendado. Uma exceção a essa regra se dá em casos que precisam referenciar outro elemento em outra parte do documento XML. Para fazer isso, é comum usar valores de atri­ buto em um elemento como as referências. Isso é semelhante ao conceito de chaves estrangeiras nos bancos de dados relacionais, e é um modo de contornar o modelo hierárquico estrito que o modelo de árvore XML implica. Discutiremos mais sobre os atributos XML na Seção 13.3, quando falarmos sobre esquema XML e DTD.

13.3 Documentos XML, DTD e esquema XML 13.3.1 Documentos XML bem formados e válidos e XML DTD Na Figura 13.3, vimos como um documento XML simples podería se parecer. Um documento XML é bem formado se seguir algumas condições. Em particular ele precisa começar com uma declaração XML para indicar a versão da linguagem que está sendo usada, bem como quaisquer outros atributos relevantes, como mostra a primeira linha da Figura 13.3. Ele também precisa seguir as diretrizes sintáticas do modelo de dados dc árvore. Isso significa que deve haver um único elemento raiz, e cada elemento precisa incluir um par correspondente de tags de início e de fim dentro das tags de início e de fim do elemento pai. Isso garante que os elementos aninhados especificam uma estrutura de árvore bem formada. Um documento XML bem formado é sintaricamente correto. Isso permite que ele seja processado por processadores genéricos, que percorrem o documento e criam uma representação de árvore interna. Um modelo-padrão com um conjunto associado de funções de API (Application Programming Interface), chamado DOM (Document Object Model), permite que os programas manipulem a representação de árvore resul­ tante correspondente a um documento XML bem formado. No entanto, o documento inteiro precisa ser analisado de antemão quando se usa DOM, para converter o docu­ mento para a representação na estrutura dc dados interna DOM padrão. Outra API, chamada SAX (Simple API for XML), pennite o processamento de documentos XML no ato ao notificar o programa de processamento por meio de chamadas de eventos sempre que uma tag de início ou fim for encontrada. Isso facilita o processamento de grandes documentos e permite o processamento dos chamados documentos XML de streaming, em que o programa de processamento pode processar as tags à medida que forem encontradas. Isso também é conhecido como processamento baseado em evento. Também existem outros processadores especializados que trabalham com diversas linguagens de programação e scripting para analisar documentos XML. Um documento XML bem formado pode não ter esquema; ou seja, ele pode ter quaisquer nomes de tag para os elementos do documento. Nesse caso, nào existe um

Capitulo 13 XML: extensible Markup Language

393

conjunto predefinido de elementos (nomes de tag) que um programa processando o documento saiba esperar. Isso dá ao criador do documento a liberdade de especificar novos elementos, mas limita as possibilidades para interpretar automaticamente o significado ou a semântica dos elementos do documento. Um critério mais forte é que um documento XML seja válido. Nesse caso, o documento deverá ser bem formado e seguir um esquema específico. Ou seja, os nomes de elemento usados nos pares de tag de início c dc fim devem seguir a estru­ tura especificada cm um arquivo XML DTD (Document Type Definition) separado, ou arquivo de esquema XML. Primeiro, vamos discutir aqui a XML DTD, e depois daremos uma visão geral do esquema XML na Seção 13.3.2. A Figura 13.4 mostra um arquivo XML DTD simples, que especifica os elementos (nomes de tag) e suas estruturas aninhadas. Quaisquer documentos válidos, cm conformidade com essa DTD, devem seguir a estrutura especificada. Existe uma sintaxe especial para espe­ cificar arquivos DTD, conforme ilustrado na Figura 13.4(a). Primeiro, um nome é dado à tag raiz do documento, que é chamada de Projetos na primeira linha da Figura 13.4. Depois, os elementos e sua estrutura aninhada são especificados. (a) clDOCTYPE Projetos (

arquivo XML DTD

chamado Projetos, (b)

clATTUST Projeto Code.proj ID «REQUIRED> clELEMENT Nome («PCDATA)>

clELEMENT Numero («PCDATA) clELEMENT Localizacao (#PCDATA)> clELEMENT Num.dep (#PCDATA)> clELEMENT Trabalhadores (Trabalhador *)> clELEMENTTrabalhador (Cpf, Ultimo.nome?, Primeiro.nome?, Horas)>

clELEMENT Cpf (#PCDATA)> clELEMENT Ultimo.nome («PCDATA)> clELEMENT Primeiro.nome (#PCDATA)> clELEMENT Horas (#PCDATA)>

1> (b) clDOCTYPE Empresai

clELEMENT Empresa((Departamento|Funcionario|Projeto) *)> clELEMENT Departamento (Nome.dep, Localizacao+)> clATTUST Departamento

Code.dep ID #REQUIRED>

clELEMENT Funcionário (Nome.func, Cargo, Salario)> clATTUST Funcionário Code.func ID «REQUIRED

Code.dep IDREF «REQUIRED>

clELEMENT Projeto (Nome_proj, Localizacao) clATTUST Projeto Code_proj ID «REQUIRED Trabalhadores IDREFS «IMPLIED>

clELEMENT Nome.dep (#PCDATA)> clELEMENT Nome.func (#PCDATA)> clELEMENT Nome.proj («PCDATA)> clELEMENT Cargo («PCDATA) clELEMENT Localizacao («PCDATA)> clELEMENT Salario (#PCDATA)>

)>

Figura 13.4 (a) Um

Um arquivo XML DTD chamado Empresa.

394 Sistemas de banco de dados Ao especificar elementos, devem ser usadas as seguintes notações: ■ Um ’ após o nome do elemento significa que ele pode ser repetido zero ou mais vezes no documento. Esse tipo de elemento é conhecido como um elemento multivalorado (repetitivo) opcional. ■ Um + após o nome do elemento significa que ele pode ser repetido uma ou mais vezes no documento. Esse tipo de elemento é conhecido como um elemento multivalorado (repetitivo) obrigatório. ■ Um ? após o nome do elemento significa que ele pode ser repetido zero ou uma vez. Esse tipo é um elemento de único valor (nào repetitivo) opcional. ■ Um elemento sem qualquer um dos três símbolos anteriores precisa aparecer exatamente uma vez no documento. Esse ripo é um elemento de único valor (nào repetitivo) obrigatório. ■ O tipo do elemento é especificado por parênteses após ele mesmo. Se os parên­ teses incluírem nomes de outros elementos, estes sào os filhos do elemento na estrutura de árvore. Se os parênteses incluírem a palavra-chave #PCDATA ou um dos outros tipos de dados disponíveis em XML DTD, o elemento é um nó tolha. PCDATA significa parsed character data (dados de caractere analisados), que é mais ou menos equivalente a um ripo de dados de string. ■ A lista de atributos que podem aparecer em um elemento também pode ser espe­ cificada por meio da palavra-chave IATTLIST. Na Figura 13.4, o elemento Projeto tem um atributo Code_proj. Se o ripo de um atributo é ID, ele pode ser referenciado com base em outro atributo cujo ripo é IDREF dentro de outro elemento. Observe que os atributos também podem ser usados para manter os valores de elementos dc dados simples do tipo #PCDATA. ■ Os parênteses podem ser aninhados quando se especificam elementos. ■ Um símbolo de barra (?] I e2) especifica que et ou e, podem aparecer no documento.

Podemos ver que a estrutura de árvore na Figura 13.1 e no documento XML na Figura 13.3 estão cm conformidade com a XML DTD na Figura 13.4(a). Para exigir que um documento XML seja verificado por conformidade com uma DTD, temos de especificar isso na declaração do documento. Por exemplo, poderiamos mudar a primeira linha na Figura 13.3 para:

Quando o valor do atributo standalone em um documento XML é "no", o documento precisa ser verificado contra um documento DTD ou um documento de esquema XML separado (ver a Seção 13.2.2). O arquivo DTD mostrado na Figura 13.4(a) deve ser armazenado no mesmo sistema de arquivos do documento XML, e receber o nome de arquivo proj.dtd. Como alternativa, poderiamos incluir o texto do documento DTD no início do próprio documento XML, para permitir a verificação. A Figura 13.4(b) mostra outro documento DTD chamado Empresa, para ilustrar o uso dc IDREF. Um documento Empresa pode ter qualquer número dc elementos Departamento, Funcionário e Projeto, com IDs Code.dep, Code June e Code.proj, respectivamente. O elemento Funcionário tem um atributo Codejunc do tipo IDREF, que é uma referência ao elemento Departamento cm que o funcionário trabalha; isso é semelhante a uma chave estrangeira. O elemento Projeto tem um atributo Trabalhadores do tipo IDREFS, que manterá uma lista de Codejunc de Funcionários que trabalham nesse projeto; isso é semelhante a uma coleção ou lista de chaves estrangeiras. A palavra-chave #IMPLIED significa que esse atributo é opcional. Também é possível fornecer um valor default para qualquer atributo.

Capitulo 13 XML: extensible Markup Language

395

Embora a XML DTD seja adequada para especificar estruturas de árvore com elementos obrigatórios, opcionais e repetitivos, e com vários tipos de atributos, ela tem diversas limitações. Primeiro, os tipos de dados na DTD não são muito gerais. Em segundo lugar, a DTD tem a própria sintaxe especial e, portanto, requer proces­ sadores especializados. Seria vantajoso especificar documentos de esquema XML usando as regras dc sintaxe da própria XML, dc modo que os mesmos processa­ dores usados para documentos XML pudessem processar descrições dc esquema XML. Em terceiro lugar, todos os elementos DTD são sempre forçados a seguir a ordenação especificada do documento, dc modo que elementos não ordenados nào são permitidos. Essas desvantagens levaram ao desenvolvimento do esquema XML, uma linguagem mais geral, mas também mais complexa, para especificar a estrutura e os elementos dos documentos XML.

13.3.2 XML schema A linguagem XML schema é um padrão para especificar a estrutura de documentos XX1L. Ela usa as mesmas regras de sintaxe dos documentos XML normais, de modo que os mesmos processadores podem ser utilizados em ambos. Para distinguir os dois tipos dc documentos, usaremos o termo documento de instância XML ou documento XAÍL para um documento XML normal, que contém nomes de tag e valores de dados, c documento XML schema para um documento que especifica um esquema XML. Um documento XML schema conteria apenas nomes de tag, informações de estrutura de árvore, restrições e outras descrições, mas nenhum valor de dados. A Figura 13.5 mostra um documento XML schema correspondente ao banco dc dados EMPRESA exibido na Figura 5.5. Embora seja improvável que queiramos exibir o banco de dados inteiro como um único documento, há propostas para armazenar dados em formato XML nativo como uma alternativa ao armazenamento dos dados em bancos de dados relacionais. O documento XML schema da Figura 13.5 atendería à finalidade de especificar a estrutura do banco de dados EMPRESA se ela fosse armazenada em um sistema XML nativo. Vamos discutir melhor esse assunto na Seção 13.4.



Esquema Empresa (Definição Elemento) Criado por Babak Hojabri





















Y é uma dependência funcional total se a remoção de qualquer atributo A de X significar que a dependência não se mantém mais; ou seja, para qualquer atributo A e X, (X - {A}) nào determina Y funcionalmcntc. Uma dependência funcional X -> Y é uma dependência parcial se algum atributo A e X puder ser removido de X c a dependência ainda se mantiver; ou seja, para algum A e X, (X - |A)) —> Y. Na Figura 14.3(b), {Cpf, Numero_projeto| —♦ Horas é uma dependência total (nem Cpf —* Horas nem Numero_projeto —* Horas se mantêm). Contudo, a dependência {Cpf, Numero_projeto| —* Nomejuncionario é parcial porque Cpf —* Nome.fundonario se mantém.

435

436

Sistemas de banco de dados

Definição. Um esquema de relação R está na 2FN se cada atributo nào principal A cm R for total e funcionalmente dependente da chave primária de R. O teste para a 2FN consiste em testar as dependências funcionais cujos atributos do lado esquerdo fazem parte da chave primária. Se esta tiver um único atributo, o reste não precisa ser aplicado. A relação FUNCIONARIO_PROJETO na Figura 14.3(b) está na 1FN, mas não está na 2FN. O atributo não principal Nome.funcionario viola a 2FX por causa da DF2, assim como os atributos não principais Nome_projeto e Local_projeto, por causa da DF3. Cada uma das dependências funcionais DF2 e DF3 viola a 2FN por­ que Nome.funcionario pode ser funcionalmente determinado somente por Cpf, e tanto Nome_projeto quanto Local_projeto podem ser funcional mente determinados somente por Numero.projeto. Os atributos Cpf e Numero_projeto fazem parte da chave primária {Cpf, Numero_projeto} de FUNCIONARIO.PROJETO, violando, assim, o teste da 2FN. Se um esquema de relação não estiver na 2FN, ele pode ser segundo normalizado ou normalizado pela 2FN para uma série de relações 2FN em que os atributos não principais são associados apenas com a parte da chave primária em que eles são total e funcional mente dependentes. Portanto, as dependências funcionais DF1, DF2 e DF3 da Figura 14.3(b) levam à decomposição de FUNCIONARIO.PROJETO nos três esquemas de relação FP1, FP2 e FP3 mostrados na Figura 14.11(a), cada qual estando na 2FN. (a)

FUNCIONÁRIO PROJETO Çbí Numero projeto Horas Nome.funcionario Nome.projeto I Localj)rojeio DF1

_ A

I

DF2 DF3

I

Normalizacao 2FN

I

FP1 Cpf |Numero projeto Horas DF1

____♦

FP2 Nome.funcionario I DF2

___ 1

FP3 Numerojrojeto 1 Nome projeto Local projeto

DF3I______ 1____ 1

(b)

FUNCIONÁRIO DEPARTAMENTO

Nome.funcionario

Cpf

Data.nascimento Endereço Numero.departamento Nome.departamento 1 Cpf.gerente 1

4____ ____ 1_____ ♦_____ ‘

4



Normalizacao 3FN

DF1____________ ________________ ___________________________ Nome_funcionario Cpf Datanascimento| Endereço | Numero departamento

___________________ DF2 _________________ ___________ Numero.departamento | Nome departamento|Cpf_Gerente |

Figura 14.11 Normalizando para 2FN e 3FN. (a) Normalizando FUNCIONARIO.PROJETO em relações 2FN. (b) Normalizando

FUNCIONARIO.DEPARTAMENTO em relações 3FN.

14.3.6 Terceira forma normal A terceira forma normal (3FN) é baseada no conceito de dependência transitiva. Uma dependência funcional X —* Y em um esquema de relação R é uma dependência transitiva se houver um conjunto de atributos Z em R que nem sejam uma chave candidata nem um subconjunto de qualquer chave de R,*11 e tanto X -> Z quanto 11 Essa c a definição geral dc dependência transitiva. Como estamos preocupados apenas com as chaves primárias nesta seção, permitimos dependências transitivas em que X é a chave primária, mas Z pode scr (um subconjunto dc) uma chave candidata.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

437

Z —> ¥ se mantiverem. A dependência Cpf —> Cpf.gerente é transitiva por meio de Numero.departamento em FUNCIONARIO.DEPARTAMENTO na Figura 14.3(a), pois ambas as dependências Cpf —* Numero.departamento e Numero.departamento —* Cpf.gerente se mantêm e Numero.departamento não é nem uma chave por si só nem um subconjunto da chave de FUNCIONARIO.DEPARTAMENTO. Intui ti vam ente, pode­ mos ver que a dependência de Cpf.gerente sobre Numero.departamento é indesejável em FUNCIONARIO.DEPARTAMENTO, pois Numero.departamento nào é uma chave dc FUNCIONARIO.DEPARTAMENTO.

Definição. De acordo com a definição original de Codd, um esquema de relação R está na 3FN se ele satisfizer a 2FN e nenhum atributo não principal dc R for transitivamente dependente da chave primária. O esquema de relação FUNCIONARIO.DEPARTAMENTO da Figura 14.3(a) está na 2FN, pois não existe dependência parcial sobre uma chave. Porém, FUNCIONÁRIO. DEPARTAMENTO não está na 3FN cm razão da dependência transitiva dc Cpf. gerente (c também Nome.departamento) cm Cpf por meio dc Numero.departamento. Podemos normalizar FUNCIONARIO.DEPARTAMENTO decompondo-o nos dois esquemas de relação 3FN DF1 e DF2 mostrados na Figura 14.11(b). Intuitivamente, vemos que DF1 e DF2 representam fatos de entidades independentes sobre fun­ cionários e departamentos, ambos entidades por si sós. Uma operação NATURAL JOIN sobre DF1 e DF2 recuperará a relação original FUNCIONARIO.DEPARTAMENTO sem gerar tuplas falsas. De maneira intuitiva, podemos ver que qualquer dependência funcional de que o lado esquerdo faz parte (é um subconjunto apropriado) da chave primária, ou qualquer dependência funcional dc que o lado esquerdo é um atributo não chave, é uma DF problemática. A normalização 2FN c 3FN remove essas DFs problemá­ ticas ao decompor a relação original cm novas relações. Em relação ao processo de normalização, não é necessário remover as dependências parciais antes das dependências transitivas, porém, historicamente, a 3FN tem sido definida com a suposição de que uma relação é restada primeiro pela 2FN, antes de ser testada pela 3FN. Além disso, a definição geral da 3FN que apresentamos na Seção 14.4.2 abrange automaticamente a condição de que a relação também satisfaz a 2FN. A Tabela 14.1 resume informalmente as três formas normais com base nas chaves primárias, os testes usados em cada uma e a solução ou normalização realizada para alcançar a forma normal. Forma normal Primeira (1FN)

formas normas baseadas

Formar novas relações para cada atributo

em chaves primárias e a

tivalorados ou relações aninhadas.

multivalorado ou relação aninhada.

normalização correspondente.

mária contém múltiplos atributos»

nenhum atributo não chave deverá

ser funcionalmente dependente de uma parte da chave primária.

Decompor e montar uma nova relação para

cada chave parcial com seu(s) atributo(s) dependente(s). Certificar-se de manter uma

relação com a chave primária original e

quaisquer atributos que sejam total e fun­ cionalmente dependentes dela.

A relação não deve ter um atributo não chave determinado funcional­ mente por outro atributo não chave

Terceira (3FN)

Tabela 14.1 Resumo das

Relação não deve ter atributos mul­

Para relações em que a chave pri­

Segunda (2FN)

Solução (normalização)

Teste

(ou por um conjunto de atributos não chave). Ou seja, não deve haver

dependência transitiva de um atributo não chave sobre a chave primária.

Decompor e montar uma relação que inclua

o(s) atributo(s) não chave que determina(m) funcional mente outro(s) atributo(s) não chave.

438

Sistemas de banco de dados

14.4 Definições gerais da segunda e da terceira formas normais Em geral, queremos projetar nossos esquemas dc relação dc modo que não tenham dependências parciais nem transitivas, pois esses tipos dc dependências causam as anomalias de atualização discutidas na Seção 14.1.2. As etapas para normalização para relações 3FN que discutimos até aqui desaprovam dependências parciais e transitivas na chave primária. O procedimento dc normalização descrito é útil para análise em situações práticas para determinado banco dc dados, no qual as chaves primárias já foram definidas. Essas definições, entretanto, não levam cm conta outras chaves candidatas de uma relação, se houver. Nesta seção, mostramos as definições mais gerais da 2FN e da 3FN que levam em conta todas as chaves candidatas de uma relação. Observe que isso não afeta a definição da 1FN, pois ela independe de chaves e dependências funcionais. Como uma definição geral de atributo principal, um atributo que faz parte dc qualquer chave candidata será considerado principal. Dependências funcionais parciais e totais e dependências transitivas agora serão consideradas com relação a todas as chaves candidatas de uma relação.

14.4.1 Definição geral da segunda forma normal Definição. Um esquema de relação R está na segunda forma normal (2FN) se cada atributo não principal A em R não for parcialmente dependente de qualquer chave de R.12 O teste para 2FN consiste em avaliar as dependências funcionais cujos atributos do lado esquerdo façam parte da chave primária. Se esta contiver um único atributo, o teste não precisa ser aplicado. Considere o esquema de relação LOTES mostrado na Figura 14.12(a), que descreve lotes de terreno à venda em diversas cidades de um estado. Suponha que existam duas chaves candidatas: ldentificador_propriedade e (Nome_cidade, Numerojote}; ou seja, números dc lote são únicos apenas dentro dc cada cidade, mas números dc ldentificador_propriedade são únicos entre as cidades do estado inteiro. Com base nas duas chaves candidatas ldentificador_propriedade e (Nome_cidade, Numerojote), as dependências funcionais DF1 e DF2 da Figura 14.12(a) se mantêm. Escolhemos ldentificador_propriedade como a chave primária, por isso ela está subli­ nhada na Figura 14.12(a), mas nenhuma consideração especial será feita a essa chave sobre a outra chave candidata. Suponha que as duas outras dependências funcionais se mantenham em LOTES: DF3: Nome_cidade -> Imposto DF4: Area -* Preco Em palavras, a dependência DF3 diz que Imposto é fixo para determinada cidade (não varia de lote para lote na mesma cidade), enquanto a DF4 diz que o preço de um lote é determinado por sua área, independentemente da cidade em que esteja. (Suponha que esse seja o preço do lote para fins de impostos.) O esquema de relação LOTES viola a definição geral da 2FN porque Imposto é parcialmcntc dependente da chave candidata {Nome_cidade, Numerojote}, por causa da DF3. Para normalizar LOTES na 2FN, decomponha-o nas duas relações LOTES 1 e LOTES2, mostradas na Figura 14.12(b). Construímos LOTES1 ao remover o atributo Imposto que viola a 2FN de LOTES e colocando-o com Nome.cidade (o lado esquerdo da DF3 que causa a dependência parcial) cm outra relação LOTES2.Tanto LOTES 1 quanto LOTES2 estão na 2FN. Observe que a DF4 não viola a 2FN e é transportada para LOTES1. 12 Essa definição pode ser reformulada da seguinte forma: um esquema de relaçào R está na 2FN se cada atributo não principal zt em R for total c funcionalmente dependente de cada chave de R.

Capitulo 14

(a)

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

Figura 14.12 Normalização

Chave candidata I------------------ 1------------------- 1

LOTES

para 2FN e 3FN. (a) A relação

Identificador propnedade Nome cidade 1 Numero lote 1 Area Preco | Imposto _________________ j

DF1

f________________

DF2 DF3

439

LOTES com suas dependências funcionais de DF1 a DF4. (b)

14 4 4 I 1 1 ______________ 4

Decompondo para as relações

2FN LOTES1 e LOTES2. (c) Decompondo LOTES 1 para as relações 3FN LOTES 1A e

L_í

DF4

LOTES1B. (d) Normalização progressiva de LOTES para um

LOTES2

LOTES1 ldentificador propriedade Nome.cidade Numero k)te Area Preco l —

DF2

4 44 ___ 44

4

DF1

'

projeto 3FN.

Nome cidade

DF3

Imposto

|_________ |

DF4 (c)

LOTES1A ldentificador propriedade Nome cidade Numero lote |Area

DF1 DF2

4

4

4

________________ _______________ __________ _________ |

(d)

LOTES1A

LOTES 1B

Preco

DF4 |_______

4

1FN

LOTES

LOTES1

LOTES 1B | Area

LOTES2

2FN

LOTES2

3FN

14.4.2 Definição geral da terceira forma normal Definição. Um esquema de relação R está na terceira forma normal (3FN) se, toda vez que uma dependência funcional nào trivial X —* A se mantiver em R, ou (a) X for uma superchave de R ou (b) A for um atributo principal de R.’' De acordo com essa definição, LOTES2 (Figura 14.12(b)] está na 3FN. No entanto, DF4 em LOTES 1 viola a 3FN, pois Area não é uma superchave e Preco não é um atributo principal em LOTES 1. Para normalizar LOTES1 para a 3FN, nós a decompomos nos esquemas de relação LOTES1A e LOTES 1B mostrados na Figura 14.12(c). Construímos LOTES 1A removendo o atributo Preco que viola a 3FN de LOTES 1 e colocando-o com Area (o lado esquerdo de DF4 que causa a dependência transitiva) em outra relação LOTES 1B. Tanto LOTES 1A quanto LOTES 1B estão na 3FN. Dois pontos precisam ser observados sobre esse exemplo e a definição geral da 3FN:

■ LOTES1 viola a 3FN porque Preco é transitivamente dependente cm cada uma das chaves candidatas de LOTES 1 por meio do atributo não principal Area. ■ Essa definição geral pode ser aplicada diretamente para testar se um esquema de relação está na 3FN; este não precisa passar pela 2FN primeiro. Em outras palavras, se uma relação passa pelo teste geral da 3FN, ela automaticamente passa pelo teste da 2FN.

Observe que. com base nas DFs deduzidas (que serão discutidas na Seção 15.1), a DF Y —• YA tam­ bém se mantém sempre que Y —• A for verdadeiro. Portanto, um modo ligeiramenre melhor de fazer essa afirmação é que {A-X) é um atributo principal de K.

440

Sistemas de banco de dados

Se aplicarmos a definição da 3FN dada a LOTES com as dependências de DF1 a DF4, descobriremos que tanto a DF3 quanto a DF4 violam a 3FN pela definição geral anterior, pois o Nome_cidade do lado esquerdo na DF3 não é uma superchave. Portanto, poderiamos decompor LOTES em L0TES1 A, L0TES1B e L0TES2 diretamente. Logo, as dependências transitiva e parcial que violam a 3FN podem ser removidas em qualquer ordem.

14.4.3 Interpretando a definição geral da terceira forma normal Um esquema de relação R viola a definição geral da 3FN se uma dependência funcional X —* A, que se mantém em R, não atender a qualquer condição — signifi­ cando que ela viola ambas as condições gerais (a) e (b) da 3FN. A primeira condição “apanha” dois tipos de dependências problemáticas: ■ Um atributo não principal determina outro atributo não principal. Aqui, em geral, temos uma dependência transitiva que viola a 3FN. ■ Um subconjunto apropriado de uma chave de R determina funcionalmente um atributo não principal. Aqui, temos uma dependência parcial que viola a 2FN.

Assim, a condição (a) sozinha resolve as dependências problemáticas que foram causas para a segunda e terceira normalizações, conforme discutimos. Portanto, podemos indicar uma definição alternativa geral da 3FN da seguinte forma:

Definição alternativa. Um esquema de relação R está na 3FN se cada atributo não principal de R atender às duas condições a seguir: ■ Ele é total e funcionalmente dependente de cada chave de R. ■ Ele é dependente não transi tivamen te de cada chave de R.

Entretanto, observe a cláusula (b) na definição geral da 3FN. Ela permite que certas dependências funcionais escapem, no sentido de que são válidas com a defini­ ção da 3FN e, portanto, não são “apanhadas” pela definição da 3FN, mesmo sendo potencialmente problemáticas. A forma normal de Boyce-Codd “apanha” essas dependências porque não as permite. Discutimos essa forma normal em seguida.

14.5 Forma Normal de Boyce-Codd A forma normal dc Boyce-Codd (FNBC) foi proposta como uma forma mais simples da 3FN, mas descobriu-se que ela era mais rigorosa. Ou seja, cada relação na FNBC também está na 3FN. Porém, uma relação na 3FN nào necessariamente está na FNBC. Dissemos, na subseção anterior, que embora a 3FN permita dependências funcionais em conformidade com a cláusula (b) da definição da 3FN, a FNBC as desaprova e, portanto, é uma definição mais estrita de uma forma normal. Intuitivamente, podemos ver a necessidade de uma forma normal mais forte que a 3FN ao voltar ao esquema de relação LOTES da Figura 14.12(a) com suas quatro dependências funcionais, de DF1 a DF4. Suponha que tenhamos milhares de lotes na relação, mas que eles sejam de apenas duas cidades: Ribeirão Preto e Analândia. Suponha também que os tamanhos de lote em Ribeirão Preto sejam de apenas 0,5,0,6, 0,7,0,8,0,9 e 1,0 hectare, enquanto os tamanhos de lote em Analândia sejam restritos a 1,1, 1,2,..., 1,9 e 2,0 hectares. Em tal situação, teriamos a dependência funcional adicional DF5: Area —» Nome.cidade. Se acrescentamos isso às outras dependências, o esquema de relação L0TES1A ainda estará na 3FN,pois essa DF está em conformidade com a cláusula (b) na definição geral da 3FN, e Nome_cidade é um atributo principal.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

441

A área de um lote que determina a cidade, conforme especificada pela DF5, pode ser representada por 16 tuplas em uma relação separada R(Area. Nome_cidade), pois existem apenas 16 valores de Area possíveis (ver Figura 14.13). Essa repre­ sentação diminui a redundância de repetir a mesma informação em milhares de tuplas LOTES1A. A FNBC é uma forma normal mais forte, que reprovaria LOTES1A e sugeriria a necessidade de sua decomposição. Definição. Um esquema de relação R está na FNBC se toda vez que uma dependên­ cia funcional nào trivial X —> A se mantiver em R, então X é uma superchave de R. A definição formal da FNBC difere da definição da 3FN porque a condição (b) da 3FN, que permite que as DFs com o lado direito sejam um atributo principal, está ausente da FNBC. Isso torna a FNBC uma forma normal mais forte em comparação com a 3FN. Em nosso exemplo, a DF5 viola a FNBC em LOTES1A porque Area não é uma superchave de LOTES1 A. Podemos decompor LOTES1A em duas relações FNBC, LOTES1AX e LOTES1AY, mostradas na Figura 14.13(a). Essa decomposição perde a dependência funcional DF2 porque seus atributos não coexistem mais na mesma relação após a decomposição. Na prática, a maioria dos esquemas de relação que estão na 3FN também estão na FNBC. Somente se existir alguma DF X —*A que seja mantida em um esquema de relação R com X não sendo uma superchave e A sendo um atributo principal é que R estará na 3FN, mas não na FNBC. O esquema de relação R mostrado na Figura 14.13(b) ilustra o caso geral de tal relação. Tal DF leva a uma potencial redundância de dados, conforme ilustramos anteriormente no caso da DF5: Area —* Nome_ddade, na relação LOTES1A. O ideal é que o projeto de banco de dados relacionai lute para alcançar a FNBC ou a 3FN para cada esquema de relação. Obter o status de normalização apenas de 1FN ou 2FN não é considerado adequado, visto que eles foram desenvolvidos historicamente para serem formas normais intermediárias, como trampolins para a 3FN e a FNBC. LOTES 1A Identificador propriedade 1 Nome ddade Numero lote Area

(a)

♦ 1

DF1

DF2

'

DF5

4 4 1

'

DF2 sendo perdida na decomposição, (b) Uma relação

esquemática com DFs; ela está

na 3FN, mas não na FNBC, em LOTES 1 AY

Area

Nome_ddade

R

(b)

A

c

B

4 DF2 L

14.5.1 Decomposição de relações que não estão na FNBC Como outro exemplo, considere a Figura 14.14, que mostra uma relação ENSINA com as seguintes dependências: DF1:

{Aluno, Disciplina} * Professor

DF2:’4

Professor * Disciplina

Boyce-Codd. (a) Normalização FNBC deLOTESIAcom

a dependência funcional

Normalização FNBC LOTES 1AX ldentificador_propriedade Area Numerojote

Figura 14.13 Forma normal de

14 Essa dependência significa que cada professor ensina uma disciplina c uma restrição para essa aplicação.

virtude da DF C -> B.

442

Sistemas de banco de dados

Figura 14.14 Uma relação

ENSINA que está na 3FN, mas não na FNBC.

ENSINA

Disciplina

Aluno

Professor

Uma

Banco de dados

Marcos

Silva

Banco de dados

Navathe

Silva

Sistemas operacionais

Ornar

Silva

Teoria

Charles

Souza

Banco de dados

Marcos

Souza

Sistemas operacionais

Antonio

Wong

Banco de dados

Gomes

Zelaya

Banco de dados

Navathe

Uma

Sistemas operacionais

Ornar

Observe que {Aluno, Disciplina} é uma chave candidata para essa relação e que as dependências mostradas seguem o padrão da Figura 14.13(b), com Aluno como A, Disciplina como fí e Professor como C. Logo, essa relação está na 3FN, mas não na FNBC. A decomposição desse esquema de relação em dois esquemas não é direta, pois ele pode ser decomposto cm um dos três pares possíveis a seguir:

1. R1 (Aluno, professor) e R2(Alun.Q, Disciplina) 2. RI (Disciplina, Professor) e R2(Disciplina, Aluno) 3. RI (Professor, Disciplina) e R2(Professor. Aluno) Todas as três decomposições perdem a dependência funcional DF1. questão, então, passa a ser: qual dos três acima é uma decomposição desejável? Conforme indicamos anteriormente (Seção 14.3.1), lutamos para alcançar duas propriedades de decomposição durante o processo de normalização: a propriedade de junção não aditiva c a propriedade de preservação da dependência funcional. Não conseguimos atender à preservação da dependência funcional para qualquer uma das decomposi­ ções FNBC anteriores conforme apresentadas; mas devemos atender à propriedade da junção não aditiva. Um teste simples é muito prático para testar a decomposição binária de uma relação em duas relações: Propriedade NJB (junção não aditiva para decomposições binárias). Uma decom­ posição D = {Rj, R,J de R tem a propriedade de junção sem perda (não aditiva) cm relação a um conjunto dc dependências funcionais F sobre R se, e somente se, ■ A DF ((R! C R2) —♦ (R] - R2)) estiver em F',1' ou ■ A DF ((Rj C R2) —» (R2 - Rj)) estiver em F *

Se aplicarmos esse teste às três decomposições anteriores, veremos que somente a terceira decomposição atende aos requisitos do teste. Na terceira decomposição, R| A R, para o teste acima é Professor e Rx - R, é Disciplina. Como Professor -> Disciplina, o teste NJB é satisfeito c a decomposição c não aditiva. (Fica como exer­ cício, para o leitor, mostrar que as duas primeiras decomposições não atendem ao teste NJB.) Logo, a decomposição apropriada de ENSINA para relações FNBC é: ENSINA1 (Professor, Disciplina) e ENSINA2 (Professor, Aluno)

Temos de garantir que essa propriedade seja mantida, pois a decomposição não aditiva é essencial durante a normalização. Você precisa verificar se essa propriedade é mantida em relação aos nossos exemplos informais de normalização sucessiva. *’ A notação F* rcfcrc-sc à cobertura do conjunto dc dependências funcionais c inclui todas as DFs im­ plicadas por F. Isso é discutido em detalhes na Seção 15.1. Aqui, basta garanrir que uma das duas DFs realmente seja mantida para que a decomposição não aditiva cm Rt e R, passe nesse teste.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

nas seções 14.3 e 14.4, e também pela decomposição de LOTES1A em duas relações na FNBC, LOTES1AX e LOTES1 AY. Em geral, uma relação R não estando na FNBC pode ser decomposta de modo a atender à propriedade de junção não aditiva pelo procedimento a seguir.1617 Ele decompõe R sucessivamente em um conjunto de relações que estão na FNBC: Considere que Ré a relação que não está na FNBC, que X Ç R e que X -> A seja a DF que causa uma violação da FNBC. R pode ser decomposta em duas relações: R-A XA

Se R - A ou XA não estiver na FNBC, repita o processo. O leitor deverá verificar que, se aplicássemos esse procedimento a LOTES 1 A, obteríamos as relações LOTES 1AX e LOTES 1 AY, como antes. De modo semelhante, a aplicação desse procedimento a ENSINA resulta nas relações ENSINA1 e ENSINA2. Observe que, se designarmos (Aluno, Professor) como chave primária da relação ENSINA, a DF Professor —♦ Disciplina causa uma dependência parcial (não total mente funcional) de Disciplina sobre uma parte dessa chave. Essa DF pode ser removida como uma parte da segunda normalização (ou por uma aplicação direta do procedimento anterior para alcançar a FNBC), produzindo exata­ mente as mesmas duas relações no resultado. Esse é um exemplo de caso em que podemos atingir o mesmo projeto definitivo na FNBC por meio de caminhos de normalização alternativos.

14.6 Dependência multivalorada e quarta forma normal Considere a relação FUNCIONÁRIO mostrada na Figura 14.15(a). Uma tupla nessa relação FUNCIONÁRIO representa o fato de que um funcionário cujo nome é Nome_ funcionário trabalha no projeto cujo nome é Nome_projeto e tem um dependente cujo nome é Nome_dependente. Um funcionário pode atuar em vários projetos e ter vários dependentes, e seus projetos e dependentes são independentes um do outro.1 Para manter o estado da relação coerente, e para evitar quaisquer relacionamentos falsos entre os dois atributos independentes, devemos ter uma tupla separada para repre­ sentar cada combinação dc dependente c de projeto de um funcionário. No estado de relação mostrado na Figura 14.15(a), o funcionário com Nome_funcionario Silva trabalha em dois projetos, ‘X' e ‘Y’, e possui dois dependentes, João e Ana; portanto, existem quatro tuplas para representar esses fatores juntos. A relação FUNCIONÁRIO c uma relação dc todas as chaves (sua chave são todos os seus atributos juntos) e, portanto, não possui dependências funcionais e se qualifica para ser uma relação FNBC. Podemos ver que existe uma redundância óbvia na relação FUNCIONÁRIO — a informação do dependente é repetida para cada projeto e a informação do projeto é repetida para cada dependente. Conforme ilustrado pela relação FUNCIONÁRIO, algumas relações possuem res­ trições que não podem scr especificadas como dependências funcionais c, portanto, não estão violando a FNBC. Para resolver essa situação, foi proposto o conceito dc dependência multivalorada (DMV) e, com base nessa dependência, foi definida a quarta forma normal. Uma discussão mais formal das D.MVs e suas propriedades 16 Observe que esse procedimento é baseado no Algoritmo 15.5, do Capítulo 15, para a produção de esquema FNBC pela decomposição de um esquema universal. 17 Em um diagrama ER. cada um seria representado como um atributo multivalorado ou como um tipo de entidade fraca (ver Capítulo 3).

443

444

Sistemas de banco de dados

Figura 14.15 Quarta e quinta formas normais, (a) A relação

FUNCIONÁRIO com duas DMVs:

(a)

FUNCIONÁRIO Nome_funcionario

Nome_projeto

projeto e Nome_funcionario

Silva

X

João

—*♦ Nome.dependente.

Silva

Y

Ana

(b) Decompondo a relação

Silva

X

Ana

FUNCIONÁRIO em duas relações 4FN FUNCIONARIO-PROJETOS e

Silva

Y

João

Nome_funconano —** Nome_

FUNCIONARIO_DEPENDENTES. (c) A relação FORNECE sem

DMVs está na 4FN, mas não na 5FN se tiver a DJ(/?,, R2,

Nome_dependente

(b)

FUNCIONÁRIO PROJETOS

FUNCIONÁRIO DEPENDENTES Nome dependente

Nome funcionario

Nome, projeto

Nome funcionário

Silva

X

Silva

João

Silva

Y

Silva

Ana

RJ. (d) Decompondo a relação FORNECE nas relações 5FN Rv r2.r3. (c)

FORNECE

Nome fornecedor

Nome peca

Nome projeto

Silva

Parafuso

ProjX

Silva

Porca

ProjY

Adam

Parafuso

ProjY

Walter

Porca

ProjZ

Adam

Prego

ProjX

Adam

Parafuso

ProjX

Silva

Parafuso

ProjY

(d)

3 Nome_

fornecedor

Nome peca

Nome_

Nome_

Nome.

Nome_

fornecedor

Projeto

peca

projeto

Si Na

Parafuso

SiNa

ProjX

fórafuso

ProjX

Si Na

Porca

Si Na

ProjY

Porca

ProjY

Adam

Parafuso

Adam

ProjY

Rarafuso

ProjY

Walter

Porca

Walter

ProjZ

Porca

ProjZ

Adam

Prego

Adam

ProjX

Prego

ProjX

ficará para o Capítulo 15. As dependências mulrivaloradas sào uma consequência da primeira forma normal (1FN) (ver Seçào 14.3.4), que nào aprova que um atributo em uma tupla tenha um conjunto de valores. Se tivermos mais de um atributo multivalorado, a segunda opção de normalização da relação (ver Seção 14.3.4) introduz uma dependência multivalorada. Informalmente, sempre que dois relacionamentos 1:N independentes A:B e A:C são misturados na mesma relação, R(A, B, C), uma DMV pode surgir.18

18 Essa DMV c indicada como A — S|C.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

14.6.1 Definição formal de dependência multivalorada Definição. Uma dependência multivalorada X —» Yespecificada sobre o esquema de relação R, em que X e Y são subconjuntos de R, determina a seguinte restrição sobre qualquer estado de relação r de R: se duas tuplas íj e f, existirem em r tais que íJX] = t,[X], então duas tuplas t3 e t4 também deverão existir em r com as seguintes propriedades,19 nas quais usamos Z para indicar (R - (X U Y)):20

■ Í3[X)=Í4[X] = /11XJ = Z2[X| ■ G[V] = í1[Y|er4[Yl

=í2[Y]

■ í3[Z] = t,[Z] e r4[Z] = tJZ] Sempre que X —» Y se mantiver; diremos que X muitidetermin a Y. Em razão da simetria na definição, toda vez que X —** Y for mantido em R, o mesmo acontecerá com X —** Z. Logo, X —►* Y implica X —►* Z, e, portanto, às vezes é escrito como X -» YIZ. Uma DMV X —►> Y em R é chamada de DMV trivial se (a) Y for um subcon­ junto de X, ou (b) X U Y = R. Por exemplo, a relação FUNCIONARIO_PROJETOS da Figura 14.15(b) tem a DMV trivial Nomejundonario —*♦ Nome_projeto e a relação FUNCIONARIO_DEPENDENTES tem a DMV trivial Nomejundonario —*♦ Nome.dependente. Uma DMV que não satisfaz nem (a) nem (b) é chamada de DMV não trivial. Uma DMV trivial será mantida em qualquer estado de relação r de R. Ela é chamada dessa maneira porque nào especifica qualquer restrição significativa sobre R. Se tivermos uma DMV não trivial em uma relação, talvez precisemos repetir valores redundantemente nas tuplas. Na relação FUNCIONÁRIO da Figura 14.15(a), os valores ‘X’ e‘Y’ de Nome_projeto são repetidos com cada valor de Nome_dependente (ou, por simetria, os valores ‘João’ e ‘Ana’ de Nome_dependente são repetidos com cada valor de Nome_projeto). Essa redundância certamente é indesejável. Contudo, o esquema FUNCIONÁRIO está na FNBC porque nenhuma dependência funcional se mantém em FUNCIONÁRIO. Portanto, precisamos definir uma quarta forma normal que é mais forte que a FNBC e desaprova esquemas de relação como FUNCIONÁRIO. Observe que as relações com DMVs não triviais tendem a ser relações de todas as chaves — ou seja, sua chave são todos os seus atributos juntos. Além disso, é raro que essas relações de todas as chaves com uma ocorrência combinatória de valores repetidos sejam projetadas na prática. Porém, o reconhecimento das DMVs como uma dependência problemática em potencial é essencial no projeto relacionai. Agora, apresentamos a definição da quarta forma normal (4FN), que é violada quando uma relação tem dependências multivaloradas indesejáveis e, portanto, pode ser usada para identificar e decompor essas relações. Definição. Um esquema de relação R está na 4FN com relação a um conjunto de dependências F (que inclui dependências funcionais e dependências multivalora­ das) se, para cada dependência multivalorada não trivial X —» Y em F *, 21 X é uma superchave para R. Podemos declarar os seguintes pontos:

■ Uma relação de todas as chaves está sempre na FNBC, pois não tem DFs. ■ Uma relação de todas as chaves, como a relação FUNCIONÁRIO da Figura 14.15(a), que não tem DFs mas tem a DMV Nomejuncionario ►> Nome_projeto | Nome_ dependente, não está na 4FN.

19 As tuplas

í,, r. e

não sâo necessariamente distintas.

2,1 Z é uma forma abreviada para os atributos em R após os atributos em |XU V) serem removidos dc R.

21 F refere-se à cobertura das dependências funcionais F,ou rodas as dependências que sào implicadas por F. Isso será definido na Seção 15.1.

445

446

Sistemas de banco de dados

■ Uma relação que nào está na 4FN em razão de uma DMV não trivial precisa ser decomposta para convertê-la em um conjunto de relações na 4FN. ■ A decomposição remove a redundância causada pela DMV.

O processo de normalização dc uma relação envolvendo DMVs não triviais, que não está na 4FN, consiste em decompô-la de modo que cada DMV seja representada por uma relação separada, em que se torna uma DMV trivial. Considere a relação FUNCIONÁRIO da Figura 14.15(a). FUNCIONÁRIO não está na 4FN porque, nas DMVs não triviais, Nome.funcionario -» Nome.projeto e Nome.funcionario -» Nome.dependente, e Nome.funcionario não é uma superchave de FUNCIONÁRIO. Decompomos FUNCIONÁRIO em FUNCIONARIO.PROJETOS e FUNCIONARIO.DEPENDENTES, mos­ trados na Figura 14.15(b). Tanto FUNCIONARIO.PROJETOS quanto FUNCIONÁRIO. DEPENDENTES estão na 4FN, porque as DMVs Nome.funcionario —Nome.projeto em FUNCIONARIO.PROJETOS e Nome.funcionario —» Nome.dependente em FUNCIONARIO.DEPENDENTES são DMVs triviais. Nenhuma outra DMV nào trivial é mantida em FUNCIONARIO.PROJETOS ou FUNCIONARIO.DEPENDENTES,assim como nenhuma DF é mantida nesses esquemas de relação.

14.7 Dependências de junção e quinta forma normal Em nossa discussão até aqui, indicamos as dependências funcionais problemáticas e mostramos como elas foram eliminadas por um processo de decomposição binária repetido para removê-las durante o processo de normalização, para obter 1FN, 2FN, 3FN e FNBC. Essas decomposições binárias precisam obedecer à propriedade NJB que apresentamos na Seção 14.5, ao discutir a decomposição para alcançar a FNBC. Obter a 4FN normalmente consiste em eliminar as DMVs por decomposições biná­ rias repetidas. Entretanto, em alguns casos pode não haver decomposição de junção não aditiva de R em dois esquemas de relação, mas pode haver uma decomposição dc junção não aditiva cm mais de dois esquemas de relação. Além disso, pode nào haver dependência funcional cm R que viole qualquer forma normal até a FNBC, e também pode não haver DMV não trivial presente em R que viole a 4FN. Então, lançamos mão de outra dependência, chamada dependência de junção e, se estiver presente, executamos uma decomposição multivias para a quinta forma normal (5FN). É importante observar que tal dependência é uma restrição semântica bas­ tante peculiar, que é muito difícil de detectar na prática; portanto, a normalização para a 5FN raramente é feita na prática.

Definição. Uma dependência de junção (DJ), indicada por DJ(Rp R2, ..., RJ, especificada no esquema de relação R, determina uma restrição sobre os estados r de R. restrição indica que cada estado válido r de R deve ter uma decomposição de junção não aditiva para Rp R2,..., R„. Logo, para cada r desse tipo, temos

*(%('), ^R2(r),...» nRJr)J = r Observe que uma DMV é um caso especial de DJ em que n = 2. Ou seja, uma DJ indicada como DJ(Rp R,) implica uma DMV (Rj D R7) —>► (Rj - R,) (ou, por simetria, (R, O R2) —** (R, - RJ). Uma dependência de junção DJ(RP R2,..., R„), especificada sobre o esquema de relação R, é uma DJ trivial se um dos esquemas de relação R. em DJ(RP R2,..., R„) for igual a R.Tal dependência é chamada de trivial porque tem a propriedade de junção não aditiva para qualquer estado de relação r de R e, portanto, não especifica qualquer restrição sobre R. Agora, podemos definir a quinta forma normal, que também é chamada forma normal projeção-junção. Definição. Um esquema de relação R está na quinta forma normal (5FN) (ou forma normal projeção-junção — FNPJ), com relação a um conjunto F de dependências

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

funcionais, multivaloradas e de junção se, para cada dependência de junção não trivial DJ(Rp R2,..., Rn) em F’ (ou seja, implicada por F),22 cada R; é uma super­ chave de R. Para ver um exemplo de DJ, considere mais uma vez a relação de rodas as chaves FORNECE da Eigura 14.15(c). Suponha que a seguinte restrição adicional sempre seja mantida: toda vez que um fornecedor /'fornece a peça p, e um projeto / usa a peça p, e o fornecedor / fornece pelo menos uma peça para o projeto /, então o fornecedor /tambcm estará fornecendo a peça p ao projeto /. Essa restrição pode ser declarada de outras maneiras e especifica uma dependência de junção DJ(RP R„ R?) entre as três projeções R^Nome.fornecedor, Nome_peca), R2(Nome_fornecedor, Nome_projeto) e R3(Nome_peca, Nome_projeto) de FORNECE. Se essa restrição for mantida, as tuplas abaixo da linha tracejada na Figura 14.15(c) devem existir cm algum estado válido da relação FORNECE, que também contém as tuplas acima da linha tracejada. A Figura 14.15(d) mostra como a relação FORNECE com a dependência de junção é decomposta em três relações Rp R2 e R3 que estão, cada uma, na 5FN. Observe que a aplicação de uma junção natural a duas quaisquer dessas relações produz tuplas falsas, mas a aplicação de uma junção natural a todas as três juntas nào as produz. O leitor deverá verificar isso no exemplo dc relação da Figura 14.15(c) c suas projeções na Figura 14.15(d). Isso porque somente a DJ existe, mas nenhuma DMV é especificada. Observe, também, que a DJ(RP R2, R;) é especificada em todos os estados de relação válidos, não apenas naquele mostrado na Figura 14.15(c). A descoberta dc DJs em bancos dc dados práticos com centenas dc atributos é quase impossível. Isso só pode ser feito com um grande grau dc intuição sobre os dados da parte do projetista. Portanto, a prática atual do projeto de banco de dados não presta muita atenção a elas. Um resultado atribuído a Date e Fagin (1992) está relacionado às condições detectadas usando apenas DFs, e ignora completamente as DJs. Ele declara: “Se um esquema de relação está na 3FN e cada uma de suas chaves consiste em um único atributo, ele também está na 5FN.”

14.8 Resumo Neste capítulo, discutimos várias armadilhas no projeto de banco de dados relacio­ nai usando argumentos intuitivos. Identificamos informalmente algumas das medidas para indicar se um esquema dc relação é bom ou ruim, e fornecemos diretrizes infor­ mais para um bom projeto. Essas diretrizes são baseadas na realização de um projeto conceituai cuidadoso no modelo ER e EER, seguindo o procedimento de mapeamento do Capítulo 9 corretamente, para mapear entidades e relacionamentos em relações. A imposição apropriada dessas diretrizes c a falta dc redundância evitarão as anomalias dc inscrção/cxclusão/atualização, além da geração dc dados falsos. Recomendamos limitar os valores NULL, que causam problemas durante operações SELECT, JOIN e dc agregação. Depois, apresentamos alguns conceitos formais que nos permitem reali­ zar o projeto relacionai de uma maneira de cima para baixo ao analisar as relações individualmente. Definimos esse processo dc projeto pela análise e decomposição, introduzindo o processo de normalização. Definimos o conceito de dependência funcional, que é a ferramenta básica para analisar esquemas relacionais, e discutimos algumas de suas propriedades. As dependências funcionais especificam as restrições semânticas entre os atributos de um esquema de relação. Em seguida, descrevemos o processo de normalização para obter bons projetos ao testar relações para tipos indesejáveis dc dependências — Novamenre, P refere-se à cobertura de dependências funcionais F, ou rodas as dependências implica­ das por F. Isso será definido na Seção 15.1.

447

448

Sistemas de banco de dados

funcionais problemáticas. Oferecemos um tratamento da normalização sucessiva com base em uma chave primária predefinida em cada relação, e depois relaxamos esse requisito e fornecemos definições mais gerais da segunda forma normal (2FN) e da terceira forma normal (3FN), que levam em conta todas as chaves candidatas de uma relação. Apresentamos exemplos para ilustrar como, usando a definição geral da 3FN, determinada relação pode ser analisada e decomposta para eventualmente gerar um conjunto de relações na 3FN. Apresentamos a Forma Normal de Boyce-Codd (FNBC) e discutimos como ela é uma forma mais forte da 3FN. Também ilustramos como a decomposição de uma relação não FNBC deve ser feita considerando o requisito de decomposição não aditiva. Apresentamos um teste para a propriedade de junção não aditiva de decomposições binárias c também demos um algoritmo geral para converter qualquer relação que não está na FNBC em um conjunto de relações na FNBC. Explicamos a necessidade de uma restrição adicional além das dependências funcionais, com base na mistura de atributos multivalorados independentes em uma única relação. Apresentamos a dependência multivalorada (DMV) para resolver tais condições e definimos a quarta forma normal com base nas DMVs. Por fim, apresentamos a quinta forma normal, que é fundamentada na dependência dc junção c que identifica uma restrição peculiar que faz com que uma relação seja decomposta em vários componentes, de modo que eles sempre produzam a relação original de volta, após uma junção. Na prática, a maioria dos projetos comerciais seguiu as formas normais até a FNBC. A necessidade de decomposição para a 5FN raramente surge na prática, e as dependências de junção são difíceis dc detectar para a maioria das situações práticas, tornando a 5FN de valor mais teórico. O Capítulo 15 apresentará a síntese e também a decomposição de algoritmos para o projeto de banco de dados relacionai fundamentado em dependências fun­ cionais. Em relação à decomposição, discutimos os conceitos de junção nào aditiva (ou sem perdas) e preservação de dependência^ que são impostos por alguns desses algoritmos. Outros tópicos no Capítulo 15 incluem um tratamento mais detalhado das dependências funcionais e mulrivaloradas, além de outros tipos de dependências.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

14.1. 14.2. 14.3.

14.4. 14.5.

14.6. 14.7.

14.8.

Discuta a semântica dc atributo como uma medida informal de boas práticas para um esquema de relação. Discuta as anomalias de inserção, exclusão e modificação. Por que elas são consideradas ruins? Ilustre com exemplos. Por que os NULLs em uma relação devem ser evitados ao máximo possível? Discuta o problema das tuplas falsas e como podemos impedi-lo. Indique as diretrizes informais para o projeto de esquema de relação que discutimos. Ilustre como a violação dessas diretrizes pode ser prejudicial. O que é uma dependência funcional? Quais são as possíveis fontes da infor­ mação que definem as dependências funcionais que se mantêm entre os atributos de um esquema de relação? Por que não podemos deduzir uma dependência funcional automaticamente com base cm um estado de relação em particular? A que se refere o termo relação não normalizada? Como as formas normais se desenvolveram historicamente desde a primeira forma normal até a forma normal de Boyce-Codd? Defina a primeira, a segunda c a terceira formas normais quando somente chaves primárias são consideradas. Como as definições gerais de 2FN e 3FN,

Capitulo 14

14.9.

14.10. 14.11. 14.12.

14.13. 14.14. 14.15. 14.16. 14.17. 14.18.

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

que consideram todas as chaves de uma relação, diferem das que consideram apenas chaves primárias? Que dependências indesejáveis sào evitadas quando uma relação está na 2FN? Que dependências indesejáveis sào evitadas quando uma relação está na 3FN? Dc que maneira as definições generalizadas de 2FN c 3FN estendem as definições além das chaves primárias? Defina a forma normal de Boyce-Codd. Como ela difere da 3FN? Por que ela é considerada uma forma mais forte de 3FN? O que é dependência multivalorada? Quando ela surge? Uma relação com duas ou mais colunas sempre tem uma DMV? Mostre com um exemplo. Defina a quarta forma normal. Quando ela é violada? Quando ela costuma ser aplicada? Defina a dependência de junção e a quinta forma normal. Por que a 5FN também é chamada de forma normal projeção-junção (FNPJ)? Por que os projetos de banco dc dados práticos normalmcntc visam à FNBC, e não às formas normais mais altas?

EXERCÍCIOS ----------------------------------------------------------------------------------------------14.19. Suponha que tenhamos os seguintes requisitos para um banco de dados de universidade, que é usado para registrar os históricos dos alunos: a. universidade registra o nome de cada aluno (Nome.aluno), a matrícula do aluno (Matricula_aluno),o número do Cadastro de Pessoa Física (Cpf),o endereço de moradia (Endereco_moradia) e o número do telefone (Telefone, moradia), endereço família (Endereco.familia) e telefone (Telefone.familia), data de nascimento (Data_nascimento),sexo (Sexo),tipo_aluno (‘calouro’, ‘veterano’,...,‘graduado’), departamento principal (Departamento_principal), departamento secundário (Departamento.secundario) (se houver) e pro­ grama dc título (Titulacao) (‘bacharel’,‘mestrado’,...,‘doutorado’).Tanto Cpf quanto a matrícula do aluno possuem valores únicos para cada um. b. Cada departamento é descrito por um nome (Nome.departamento), código de departamento (Codigo.departamento), número da sala (Sala_ departamento), telefone de departamento (Telefone.departamento) e ins­ tituto (lnstituto_departamento).Tanro o nome quanto o código possuem valores únicos para cada departamento. c. Cada disciplina tem um nome (Nome.disciplina), descrição (Descricao.disciplina), número (Numero.disciplina), número de horas semestrais (Credito), nível (Nivel) e departamento de oferta (Numero.departamento). O número da disciplina é único para cada curso. d. Cada turma tem um professor (Ultimo.nome), semestre (Semestre), ano (Ano), disciplina (Numero.disciplina) e número de turma (Numero_turma). O número dc turma distingue diferentes turmas da mesma disciplina que são lecionadas durante o mesmo semestre/ano; seus valores são 1, 2,3,..., até o número total de turmas lecionadas durante cada semestre. e. Um registro dc nota refere-se a um aluno (Cpf), uma turma em particular c uma nota (Nota). Crie um esquema de banco de dados relacionai para essa aplicação. Primeiro, mostre rodas as dependências funcionais que devem ser mantidas entre os

449

450

Sistemas de banco de dados

14.20. 14.21.

14.22. 14.23.

14.24.

14.25. 14.26.

atributos. Depois, projete esquemas de relação para o banco de dados que estejam, cada uma, na 3FN ou na FNBC. Especifique os principais atribu­ tos de cada relação. Observe quaisquer requisitos não especificados e faça suposições apropriadas para tornar a especificação completa. Que anomalias de atualização ocorrem nas relações FUNCIONARIO_PROJETO e FUNCIONARIO.DEPENDENTE das figuras 14.3 e 14.4? Em que forma normal está o esquema de relação LOTES da Figura 14.12(a) com relação às interpretações restritivas da forma normal que levam em conta apenas a chave primária? Ela estaria na mesma forma normal se as definições gerais da forma normal fossem usadas? Prove que qualquer esquema de relação com dois atributos está na FNBC. Por que ocorrem tuplas falsas no resultado da junção das relações FUNCIONARIO_PROJET01 e FUNCIONARIO_LOCAL da Figura 14.5 (resultado mostrado na Figura 14.6)? Considere a relação universal R = {A, B, C, D, £, F, G, H, /,/) e o conjunto de dependências funcionais F = ( {A, B}—>{C), {A)->{D, £|, {B|->{F), {F)->{G, H}, {D} ->{/,/} }. Qual é a chave para R? Decomponha R em relações na 2FN e depois na 3FN. Repita o Exercício 14.24 para o seguinte conjunto de dependências funcionais G = {{A, B}—>{CJ, (B, D}-{£, F), {A, D}->{G, H), {A}{I}, * ). Considere a seguinte relação:

a.

A

B

C

NUM TUPLA

10

bl

Cl

1

10

b2

c2

2

11

b4

C1

3

12

b3

c4

4

13

b1

C1

5

14

b3

c4

6

Dada a extensão (estado) anterior, qual das seguintes dependências pode ser mantida na relação acima? Se a dependência não puder ser mantida, explique por que, especificando as tuplas que causam a violação.

i. A —> B, ii. B —> C, iii. C —> B, iv. B —* A, v. C —► A

b. A relação anterior tem uma chave candidata em potencial? Se tiver, qual é? Sc não, por quê? 14.27. Considere uma relação R(A, B, C, D, £) com as seguintes dependências: AB -> C, CD — E, DE — B

AB é uma chave candidata dessa relação? Se não for, ABD é? Explique sua resposta. 14.28. Considere a relação R, que tem atributos que mantêm horários de discipli­ nas e turmas em uma universidade; R = (Numero_disdplina, Numero.turma, Numero.departamento, Horas.creditos, Nivel.disciplina, Cpf.professor. Semestre, Ano, Dias.horas, Numero.sala, Numero.alunos). Suponha que as seguintes dependências funcionais sejam mantidas em R: {Numero.disdplina} —* {Numero.departamento, Horas.creditos, Nível.disciplina}

{Numero.disciplina, Numero.turma, Semestre, Ano} — {Dias.horas, Numero.sala, Numero.alunos, Cpf.professor} {Numero.sala, Dias.horas, Semestre, Ano} -»{Cpf.professor, Numero.disciplina, Numero.turma}

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

Tente determinar quais conjuntos de atributos formam chaves de R. Como você normalizaria essa relação? 14.29. Considere as seguintes relações para um banco de dados de aplicação de processamento de pedido na ABC, Inc. PEDIDO (Numero-pedido, Data_pedido, Numero_diente, Valor_total) ITEM-PEDIDO (Numero-pedido, Numero_item, Quantidade_pedida, Preco_ total, Porcentagem_desconto)

Suponha que cada item tenha um desconto diferente. Precojotal refere-se a um item, Data_pedido é a data em que o pedido foi feito e Valor_total é o valor do pedido. Se aplicarmos uma junção natural nas relações ITEM_PEDIDO e PEDIDO nesse banco de dados, como será o esquema de relação resultante? Qual será sua chave? Xlostre as DFs nessa relação resultante. Ela está na 2FN? Está na 3FN? Por quê? (Indique as suposições, se você fizer alguma.) 14.30. Considere a seguinte relação: VENDA-CARRO (Numero_carro, Data_venda, Numero_vendedor, Porcentagem.comissao, Valor_desconto)

Suponha que um carro possa ser vendido por vários vendedores e, portanto, (Numero_carro, Numero_vendedor) é a chave primária. Dependências adicio­ nais são Data_venda > Valor_desconto e NumerO-Vendedor —> Porcentagem_comissao

Com base na chave primária dada, essa relação está na 1FN, na 2FN ou na 3FN? Por quê? Como você a normalizaria completamcntc com sucesso? 14.31. Considere a seguinte relação para livros publicados: LIVRO (Titulojivro, Nome_autor, Tipojivro, Precojivro, Afiliacao_autor, Editora)

Afiliacao_autor refere-se à afiliação do autor. Suponha que existam as seguintes dependências: Titulojivro — Editora, Tipojivro

Tipojivro -* Precojivro Nome.autor —* Afiliacao_autor

a. Em que forma normal essa relação está? Explique sua resposta. b. Aplique a normalização até não poder mais decompor a relação. Indique os motivos por trás de cada decomposição. 14.32. Este exercício lhe pede para converter declarações de negócios em depen­ dências. Considere a relação DISCO.RIGIDO (Numero_de_serie, Fabricante, Modelo, Lote, Capacidade, Revendedor). Cada tupla na relação DISCO_RIGIDO contém informações sobre uma unidade de disco com um Numero_de_serie exclusivo, criada por um fabricante, com um número de modelo em particular, lançada em certo lote, contendo determinada capacidade de armazenamento e vendida por certo revendedor. Por exemplo, a tupla Disco_rigido (‘1978619’, ‘WestemDigital’, ‘A2235X’, ‘765234’, 500, ‘CompUSA’) especifica que a WestemDigital fabricou uma unidade de disco com número dc série 1978619 e número de modelo A2235X, lançada no lote 765234; ela tem 500 GB e é vendida pela CompUSA. Escreva cada uma das seguintes dependências como uma DF: a. O fabricante e o número dc série identificam a unidade com exclusividade.

451

452

Sistemas de banco de dados

b. Um número de modelo é registrado por um fabricante e, portanto, não pode ser usado por outro fabricante. c. Todas as unidades de disco em determinado lote sào do mesmo modelo. d. Todas as unidades de disco de certo modelo de um fabricante em parti­ cular possuem exatamente a mesma capacidade. 14.33. Considere a seguinte relação: R (Numero.medico, Numero_paciente, Data, Diagnostico, Codigo_tratamento, Gasto)

Nela, uma tupla descreve uma visita de um paciente a um médico com o código de tratamento e gasto diário. Suponha que o diagnóstico seja determi­ nado (exclusivamente) para cada paciente por um médico. Suponha que cada código de tratamento tenha um custo fixo (independente do paciente). Essa relação está na 2FN? Justifique sua resposta e decomponha, se necessário. Depois, argumente se é necessária uma maior normalização para a 3FN e, se preciso, realize-a. 14.34. Considere a seguinte relação: VENDA.CARRO (ld_carro, Tipo.opcao, Opcao_preco, Data.venda,

Opcao.descontopreco)

Essa relação se refere às opções instaladas nos carros (por exemplo, controle de navegação) que foram vendidas em um revendedor, e os preços normais e com desconto das opções. Se Id.carro —»Data.venda e Tipo_opcao —* Opcao.preco e Id.carro, Tipo.opcao —» Opcao.descontopreco, argumente usando a definição generalizada da 3FN de que essa relação não está na 3FN. Depois, argumente com base em seu conhecimento da 2FN, por que ela nem sequer está na 2FN. 14.35. Considere a relação: LIVRO (Nomejivro, Autor, Edicao, Ano)

com os dados: Nomejivro

Autor

Edicao

Ano

Sistemas BD

Navathe

4

2004

Sistemas BD

Elmasri

4

2004

Sistemas BD

Elmasri

5

2007

Sistemas BD

Navathe

5

2007

Com base em um conhecimento de senso comum dos dados acima, quais são as chaves candidatas possíveis dessa relação? b. Justifique que essa relação tem a DMV {Livro) —** {Autor) I {Edicao, Ano). c. Qual seria a decomposição dessa relação com base na DMV acima? Avalie cada relação resultante para a forma normal mais alta que ela possui. 14.36. Considere a seguinte relação: a.

VIAGEM (Id.viagem, Datajnicio, Cidades.visitadas, Cartoes.usados)

Essa relação refere-se a viagens de negócios feitas por vendedores da empresa. Suponha que VIAGEM tenha uma única Data.inicio, mas envolva muitas Cidades, e os vendedores podem usar múltiplos cartões de crédito na viagem. Crie uma população fictícia da tabela. a. Discuta quais DFs e/ou DMVs existem na relação. b. Xlostre como você tratará de sua normalização.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

EXERCÍCIO DE LABORATÓRIO------------------------------------------------------------------

Nota: o exercício a seguir usa o sistema DBD (Data Base Designer), descrito no manual do laboratório (disponível em inglês na Sala Virtual do livro). O esquema relacionai R e o conjunto de dependências funcionais F precisam ser codi­ ficados como listas. Como exemplo, Re F para este problema são codificados como: R= [a, b, c, d,e,f,gyh,i,i\

f=

[M.M],

[!/],[£,/’)], ÍM.Í',/1]] Como o DBD é implementado em Prolog, o uso de termos em maiusculas c reservado para variáveis na linguagem e, portanto, constantes cm minúsculas sào usadas para codificar os atributos. Para obter mais detalhes sobre o sistema DBD, por favor, consulte o manual do laboratório. 14.37. Usando o sistema DBD, verifique suas respostas para os seguintes exercícios: a. 14.24 (3FN apenas) b. 14.25 c. 14.27 d. 14.28

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

As dependências funcionais foram introduzidas originalmcnte por Codd (1970). As definições originais da primeira, segunda e terceira formas normais também foram definidas em Codd (1972a), em que pode ser encontrada uma discussão sobre anomalias de atualização. A Forma Normal dc Boycc-Codd foi definida cm Codd (1974). A definição alternativa da terceira forma normal é dada cm Ullman (1988), assim como a definição da FNBC que mostramos aqui. Ullman (1988), Maier (1983) e Atzeni e De Antonellis (1993) contêm muitos dos teoremas e provas referentes a dependências funcionais. Date e Fagin (1992) oferecem alguns resultados simples e práticos relacionados a formas normais mais altas. Outras referências à teoria do projeto relacionai serão dadas no Capítulo 15.

453

Algoritmos de projeto de banco de dados relacionai e demais dependências Capítulo 14 apresentou uma técnica de projeto relacionai de cima para baixo (top-down) e conceitos relacionados usados extensivamente nos projetos de bancos de dados comerciais atuais. O procedimento envolve projetar um esquema conceituai ER ou EER, depois mapeá-lo para o modelo relacionai por um procedimento como o descrito no Capítulo 9. As chaves primárias sâo atribuídas a cada relação com base nas dependências funcionais conhecidas. No processo subse­ quente, que pode ser chamado de projeto relacionai por análise, relações projetadas inicialmente pelo procedimento citado — ou as herdadas de arquivos anteriores, formulários e outras fontes — são analisadas para detectar dependências funcionais indesejáveis. Essas dependências são removidas por sucessivos procedimentos de normalização que descrevemos na Seção 14.3, com as definições das formas normais relacionadas, as quais são estados de projeto sucessivamente melhores das relações individuais. Na Seção 14.3, consideramos que as chaves primárias eram atribuídas a relações individuais; na Seção 14.4, foi apresentado um tratamento mais genérico da normalização, no qual todas as chaves candidatas são consideradas para cada relação, e a Seção 14.5 discutiu outra forma normal, chamada FNBC. Depois, nas seções 14.6 e 14.7, discutimos mais dois tipos de dependências — dependências multivaloradas e dependências de junção —, que também podem causar redundâncias, e mostramos como elas podem ser eliminadas com mais normalização. Neste capítulo, usamos a teoria das formas normais e dependências funcionais, multivaloradas e de junção desenvolvidas no capítulo anterior e nos baseamos nela enquanto mantemos três investidas diferentes. Primeiro, discutimos o conceito de deduzir novas dependências funcionais com base em um conjunto dado e discuti­ mos noções que incluem fechamento, cobertura, cobertura mínima e equivalência. Conceitualmente, precisamos capturar a semântica dos atributos em uma relação de maneira completa e sucinta, e a cobertura mínima nos permite fazer isso. Segundo, discutimos as propriedades desejáveis das junções não aditivas (sem perdas) e a

O

456

Sistemas de banco de dados

preservação de dependências funcionais. Apresentamos um algoritmo geral para testar a nào aditividade das junções entre um conjunto de relações. Terceiro, apresen­ tamos uma técnica para o projeto relacionai por síntese das dependências funcionais. Essa é uma abordagem de baixo para cima (bottom-up) para o projeto, que pressu­ põe que as dependências funcionais conhecidas entre os conjuntos de atributos no Universo de Discurso (UoD) foram dadas como entrada. Apresentamos algoritmos para obter as formas normais desejáveis, a saber, 3FN c FNBC, e alcançamos uma ou ambas as propriedades desejáveis da não aditividade de junções e preservação da dependência funcional. Embora a técnica de síntese seja teoricamente atraente como uma técnica formal, ela nào tem sido usada na prática para grandes projetos de banco de dados, em razão da dificuldade de oferecer todas as dependências fun­ cionais possíveis antes que o projeto possa ser experimentado. Como alternativa, com a técnica apresentada no Capítulo 14, decomposições sucessivas e refinamentos contínuos ao projeto tornam-se mais tratáveis e podem evoluir com o tempo. O objetivo final deste capítulo é discutir melhor o conceito de dependência multivalorada (DMV) que apresentamos no Capítulo 14 e indicar rapidamente outros tipos de dependências que foram identificados. Na Seção 15.1, vamos discutir as regras de inferência para dependências fun­ cionais e usá-las para definir os conceitos de cobertura, equivalência e cobertura mínima entre dependências funcionais. Na Seção 15.2, primeiro vamos descrever as duas propriedades das decomposições, a saber, a propriedade de preservação de dependência e a propriedade dc junção não aditiva (ou sem perdas), utilizadas pelos algoritmos de projeto para alcançar decomposições desejáveis. E importante observar que não é suficiente testar os esquemas de relação independentemente um do outro para compatibilidade com formas normais mais altas, como 2FN, 3FN e FNBC. As relações resultantes precisam satisfazer coletivamente essas duas propriedades adi­ cionais para que se qualifiquem como um bom projeto. A Seção 15.3 é dedicada ao desenvolvimento de algoritmos de projeto relacionai que começam com um esquema de relação gigante, chamada relação universal, a qual é hipotética c contém todos os atributos. Essa relação é decomposta (ou, em outras palavras, as dependências funcionais dadas são sintetizadas) em relações que satisfazem certa forma normal, como 3FN ou FNBC, e também atendem a uma ou ambas as propriedades desejáveis. Na Seção 15.5, discutimos o conceito de dependência multivalorada (DMV) ainda mais, aplicando as noções de inferência e equivalência às DMVs. Por fim, na Seção 15.6, completamos a discussão sobre dependências entre dados ao introduzir depen­ dências de inclusão e de modelo. As dependências de inclusão podem representar restrições de integridade referencial e restrições de classe/subclasse entre as relações. Também descrevemos algumas situações nas quais um procedimento ou função é necessário para declarar e verificar uma dependência funcional entre atributos. Depois, vamos discutir rapidamente a forma normal de domínio-chave (FNDC), considerada a forma normal mais genérica. A Seção 15.7 é um resumo do capítulo. Em um curso introdutório de banco de dados, é possível pular algumas ou todas as seções 15.3,15.4 e 15.5.

15.1 Outros tópicos em dependências funcionais: regras de inferência, equivalência e cobertura mínima Apresentamos o conceito de dependências funcionais (DFs) na Seção 14.2, ilus­ tramos com alguns exemplos e desenvolvemos uma notação para indicar múltiplas DFs em uma única relação. Identificamos e discutimos dependências problemá­ ticas funcionais nas seções 14.3 e 14.4, e mostramos como eliminá-las com uma

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

decomposição de uma relação apropriada. Esse processo foi descrito como nor­ malização e mostramos como conseguir da primeira até a terceira formas normais (1FN até 3FN), dadas as chaves primárias na Seção 14.3. Nas seções 14.4 e 14.5, oferecemos testes generalizados para 2FN, 3FN e FNBC, dado qualquer número de chaves candidatas em uma relação, e mostramos como alcançá-las. Agora, retomamos ao estudo das dependências funcionais, mostramos como novas dependências podem ser deduzidas dc determinado conjunto e discutimos os conceitos de fechamento, equivalência e cobertura mínima de que precisaremos mais tarde ao considerar uma técnica de síntese para o projeto de relações dado um conjunto de DFs.

75.7.7 Regras de inferência para dependências funcionais

Indicamos com F o conjunto de dependências funcionais especificadas no esquema de relação R. Em geral, o projetista do esquema especifica as dependências funcionais que são semanticamente óbvias. Porém, diversas outras dependências funcionais são mantidas em todas as instâncias de relação válidas entre os conjuntos de atributos que podem ser derivados de e satisfazem as dependências em F. Essas outras depen­ dências podem ser deduzidas das DFs em F. Nós as chamamos de dependências funcionais deduzidas ou implicadas. Definição. Uma DF X —* Y é deduzida ou implicada por um conjunto de depen­ dências F especificado em R se X —♦ Y se mantiver em cada estado de relação válido r de R; ou seja, sempre que r satisfizer todas as dependências em F, X —* Y também se mantém em r. Na vida real, é impossível especificar todas as dependências funcionais possíveis para determinada situação. Por exemplo, se cada departamento tem um gerente, de modo que Numero.departamento determina unicamente Cpf.gerente (Numero.depar­ tamento ♦ Cpf.gerente), e um gerente tem um número de telefone único, chamado Telefone.gerente (Cpf.gerente —> Telefone.gerente), essas duas dependências juntas implicam que Numero.departamento —* Telefone.gerente. Essa é uma DF deduzida ou implicada e nào precisa ser explicitamente declarada além das duas DFs dadas. Portanto, é útil definir formalmcnte um conceito chamado fechamento^ que inclui todas as eventuais dependências que podem ser deduzidas do conjunto F indicado. Definição. Formalmente, o conjunto de todas as dependências que incluem F, bem como todas as dependências que podem ser deduzidas de F, é chamado dc fechamento dc F, sendo indicado por F *. Por exemplo, suponha que especifiquemos o seguinte conjunto F dc dependências funcionais sobre o esquema de relação na Figura 14.3(a):

F = (Cpf —> (Nome.funcionario, Data.nascimento, Endereço, Numero.departa­ mento}, Numero.departamento ► (Nome.departamento, Cpf.gerente}} Algumas das dependências funcionais adicionais que podemos deduzir de F são as seguintes:

Cpf -* (Nome.departamento, Cpf.gerente} Cpf — Cpf Numero.departamento -* Nome.departamento

O fechamento F* de F é o conjunto de todas as dependências funcionais que podem ser deduzidas de F. Para determinar um modo sistemático de deduzir depen­ dências, temos de descobrir um conjunto de regras de inferência que podem ser usadas para deduzir novas dependências de determinado conjunto de dependências. Consideramos algumas dessas regras de inferência em seguida. Usamos a notação F l=X —♦ Y para indicar que a dependência funcional X —♦ Yé deduzida do conjunto de dependências funcionais F.

457

458

Sistemas de banco de dados

Na discussão a seguir, usamos uma notação abreviada ao discutirmos as dependências funcionais. Concatenamos as variáveis de atributo e removemos as vírgulas por conve­ niência. Logo, a DF (X,Y| —* Z é abreviada para XY —> Z,ea DF (X, Y,Z| —* (U, V) é abreviada para XYZ —> UV. As três regras a seguir, de R11 a RI3, são regras de inferência bem conhecidas para as dependências funcionais. Elas foram propostas inicialmente por Armstrong (1974) e, portanto, são conhecidas como axiomas de Armstrong. 1 Rll (regra reflexiva):2 seXD Y, então X —* Y. RI2 (regra do aumento):3 (X —* Y| 1= XZ —* YZ. RI3 (regra transitiva): (X —* Y, Y —* Z| 1= X —» Z.

Armstrong (1974) mostrou que as regras de inferência de RI1 a RI3 são legítimas e completas. Por legítimas queremos dizer que, dado um conjunto de dependências funcionais F especificadas em um esquema de relação R, qualquer dependência que possamos deduzir de F usando de RI1 a RI3 se mantém em cada estado de relação r de R que satisfaz as dependências em F. Por completas queremos dizer que usar RI1 a RI3 repetidamente para deduzir dependências até que nenhuma outra dependência possa ser deduzida resulta no conjunto completo de todas as dependências possíveis que podem ser deduzidas de F. Em outras palavras, o conjunto de dependências , que chamamos dc fechamento de F, pode ser determinado a partir dc F ao usar * F apenas regras de inferência de RI1 a RI3. A regra reflexiva (Rll) declara que um conjunto de atributos sempre determina a si mesmo ou a qualquer um de seus subconjuntos, o que é óbvio. Como Rll gera depen­ dências que são sempre verdadeiras, elas são chamadas de triviais. Formalmente, uma dependência funcional X —> Y é trivial se X D Y; caso contrário, ela é não trivial. A regra do aumento (RI2) diz que a inclusão do mesmo conjunto dc atributos aos lados esquerdo e direito de uma dependência resulta em outra dependência válida. De acordo com a RI3, as dependências funcionais são transitivas. Cada uma das regras de inferência anteriores pode ser provada pela definição da dependência funcional, seja pela prova direta, seja por contradição. Uma prova por contradição considera que a regra não se mantém c mostra que isso não é pos­ sível. Agora, vamos provar que as três primeiras regras, de RI1 até RI3, são válidas. A segunda prova é por contradição. Prova de RI1. Suponha que X D Y c que duas tuplas Z( e t2 existam cm alguma instância dc relação r de R, tal que Z, [X] = Z, |X|. Então, Zj Y] = /,[Y] porque X D Y; logo, X —* Y deverá se manter em r.

Prova de RI2 (por contradição). Suponha que X —* Yse mantenha em uma instância de relação r de R, mas que XZ —* YZ não se mantenha. Então, devem existir duas tuplas e t2 em r, tais que (1) í, [X] = t2 [X], (2) tj [Y] = t2 [Y], (3) z, [XZ] = t2 [XZ] e (4) t] [YZ] * t2 [YZ]. Isso não é possível porque, com base em (1) e (3), deduzimos (5) Z, |Z| = Z2 [Z],cdc (2) e (5) deduzimos (6) í1 [YZ| = t2 [YZ], contradizendo (4). Prova de RI3. Suponha que (1) X —> Ye (2) Y—»Z se mantenham em uma relação r. Então, para quaisquer duas tuplas í, e t2 em r tais que tx [X] = t2 [X], devemos ter (3) Zj | Y| = t2 [Y], pela suposição (1). Daí, também devemos ter (4) Zj [Z| = Z2 [Z| com base em (3) e na suposição (2); assim, X —* Z deve se manter em r. Existem três outras regras de inferência que vêm após RI1, RI2 e RI3. São elas:

1 Na realidade, elas sào regras de inferência em vez de axiomas. No senrido esrriramenre matemático, axiomas (fatos dados) sào as dependências funcionais em F, pois consideramos que eles estào corretos, ao passo que Rll a RI3 são as regras de inferência para deduzir novas dependências funcionais (novos fatos).

2 A regra reflexiva também pode ser declarada como X -* X; ou seja, qualquer conjunto de atributos determina funcionalmente a si mesmo. 3 A regra do aumento também pode ser declarada como X —• Y1= XZ —• Y; ou seja, aumentar os atri­ butos do lado esquerdo de uma DF produz outra DF válida.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

RI4 (regra da decomposição, ou projetiva): (X —> YZ] l=X —> Y. RI5 (regra da união, ou aditiva): {X —> V, X -> Z] l=X -> YZ. RI6 (regra pseudotransitiva): {X —* Y, WY —* Z) l=WX —* Z.

A regra da decomposição (RI4) diz que podemos remover atributos do lado direito de uma dependência. A aplicação dessa regra de maneira repetida pode decompor a DF X —* {A t, A2,...»AJ no conjunto de dependências |X —* An X —* A2,..., X —* AJ. A regra da união (RI5) nos permite fazer o contrário. Podemos combinar um conjunto de dependências {X -> Ap X -> A2,..., X —> AJ em uma única DF X -> {Aj, A2,..., AJ. A regra pseudotransitiva (RI6) nos permite substituir um conjunto de atributos Y no lado esquerdo de uma dependência por outro conjunto X que determina Y funcionalmente, e pode ser derivado de RI2 e RI3 se aumentarmos a primeira dependência funcional X —* Y com W (a regra do aumento) e depois apli­ carmos a regra transitiva. Uma nota de cuidado com relação ao uso dessas regras: embora X —* A e X —> B impliquem X —♦ AB pela regra da união dada, X —* A e Y —* B não implicam XY —* AB. Além disso, XY —* A não necessariamente implica X —* A ou Y —* A. Usando argumentos de prova semelhantes, podemos demonstrar as regras de inferência RI4 a RI6 e quaisquer outras regras de inferência válidas. Porém, um modo mais simples de provar a validade de uma regra de inferência para dependências funcionais é usando regras de inferência que já se mostraram válidas. Assim, RI4, RI5 e RI6 são considerados como um corolário das regras dc inferência básicas de Armstrong. Por exemplo, podemos provar de RI4 a RI6 usando de RI1 até RI3. Apresentamos a prova de RI5 a seguir. As provas de RI4 e RI6 usando R11 a RI3 ficam como exercício para o leitor. Prova de RI5 (usando de RI1 a RI3).

1. X —*Y (dado).

2. X —* Z (dado). 3. X —> XY (usando RI2 em 1 ao aumentar com X; observe que XX = X). 4. XY —> YZ (usando RI2 em 2 ao aumentar com Y). 5. X —* YZ (usando RI3 em 3 e 4). Normalmente, os projetistas de banco de dados primeiro especificam o conjunto de dependências funcionais F que podem scr facilmente determinadas pela semântica dos atributos de R. Então, RI1, RI2 e RI3 são usados para deduzir dependências funcionais adicionais que também se manterão em R. Um modo sistemático de determinar essas dependências funcionais adicionais consiste em inicialmente determinar cada conjunto de atributos X que aparece como um lado esquerdo de alguma dependência funcional em F e, depois, determinar o conjunto de todos os atributos dependentes de X. Definição. Para cada conjunto de atributos X, especificamos o conjunto X * de atributos funcionalmcnte determinados por X com base em F; X * é chamado de fechamento de X sob F. O Algoritmo 15.1 pode ser usado para calcular X’.

Algoritmo 15.1. Determinando X’, o fechamento de X sob F Entrada: um conjunto F de DFs em um esquema de relação R, e um conjunto de atributos X, que é um subconjunto de R. X := X; * repita * oldX := X *; para cada dependência funcional Y —* Z em F faça se X+ D Y, então X+ := X * U Z; até (X * = oldX’);

459

460

Sistemas de banco de dados

O Algoritmo 15.1 começa definindo X’ para todos os atributos em X. Com RI1, sabemos que todos esses atributos sào fiincionalmente dependentes de X. Usando as regras de inferência RI3 e RI4, acrescentamos atributos a X+, utilizando cada depen­ dência funcional em F. Continuamos por todas as dependências em F (o loop repita) até que nenhum outro atributo seja acrescentado a X * durante um ciclo completo (do loop para cada) pelas dependências em F. O conceito dc fechamento é útil para compreender o significado e as implicações dos atributos ou conjuntos de atributos em uma relação. Por exemplo, considere o esquema dc relação a seguir, sobre aulas mantidas em uma universidade em determinado ano acadêmico: AULA (IdAula, Numero.disciplina, Nome.professor, Horas_credito, Livro.texto, Editora, Sala_aula, Capacidade).

Considere que F, o conjunto dc dependências funcionais para a relação acima, inclua as seguintes dependências funcionais: DF1: IdAula -*■ Numero_disciplina, Nome.professor, Horas.credito, Livro.texto, Editora, Sala_aula, Capacidade;

DF2: Numero_disciplina — Horas_credito; DF3: {Numero.disciplina, Nome_professor} — Livro_texto, Sala.aula; DF4: Livro_texto —» Editora DF5: Sala.aula * Capacidade

Observe que as DFs acima expressam certa semântica a respeito dos dados na relação AULA. Por exemplo, a DF1 declara que cada aula tem um IdAula exclusivo. A DF3 declara que, quando determinada disciplina é oferecida por um certo professor, o livro texto é fixado e o professor leciona essa aula em uma sala fixa. Usando as regras de inferência sobre as DFs e aplicando a definição de fechamento, podemos definir os seguintes fechamentos: {IdAula} * = {IdAula, Numero_disdplina, Nome_professor, Horas_credito, Livro, texto. Editora, Sala_aula, Capacidade} = AULA

{ Numero_disciplina} ♦ = {Numero_disciplina, Horas.credito} { NumerO-disciplina, Nome.professor} * = { Numero.disciplina, Horas.credito, Livro_ texto. Editora, Sala.aula, Capacidade)

Observe que cada fechamento acima tem uma interpretação reveladora sobre o(s) atributo(s) no lado esquerdo. Por exemplo, o fechamento de Numero_disciplina tem apenas Horas_credito além de si mesmo. Ele não inclui Nome_professor porque diferentes professores poderíam lecionar a mesma disciplina; ele não inclui Livro.texto porque diferentes professores podem usar diferentes livros textos para a mesma dis­ ciplina. Observe também que o fechamento de {Numero.disciplina, Nome.professor) não inclui IdAula, significando que ele não é uma chave candidata. Isso significa ainda que uma disciplina com determinado Numero.disciplina poderia ser oferecida por diferentes professores, o que tornaria as disciplinas aulas distintas.

15.1.2 Equivalência de conjuntos de dependências funcionais Nesta seção, discutimos a equivalência de dois conjuntos de dependências fun­ cionais. Primeiro, damos algumas definições preliminares.

Definição. Diz-se que um conjunto de dependências funcionais F cobre outro conjunto de dependências funcionais E se cada DF em E também estiver em F , ou * seja, se cada dependência em E puder ser deduzida de F. Como alternativa, podemos dizer que E é coberto por F.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

Definição. Dois conjuntos de dependências funcionais E e F sào equivalentes se * =F £ *. Portanto, a equivalência significa que cada DF em £ pode ser deduzida dc F, e cada DF em F pode ser deduzida de £; ou seja, £ é equivalente a F se as duas condições — E cobre F e F cobre £ — se mantiverem. Podemos determinar se F cobre £ calculando X+ com relação a F para cada DF X —> Y em E, e depois verificando se esse X * inclui os atributos em Y. Se isso acon­ tecer para cada DF cm £, então F cobre £. Determinamos se £ e F são equivalentes verificando se £ cobre Fc se F cobre £. Fica como um exercício para o leitor mostrar que os dois conjuntos de DFs a seguir são equivalentes:

F=}A^C,AC->D,E->AD,E->H] e G = {A -* CD, E -> AH}.

15.1.3 Conjuntos mínimos de dependências funcionais Assim como aplicamos regras de inferência para expandir um conjunto Fde DFs para chegar a F , seu fechamento, é possível pensar no sentido oposto para ver se * poderiamos encolher ou reduzir o conjunto F à sua forma mínima, de modo que o conjunto mínimo ainda seja equivalente ao conjunto original F. Informalmente, uma cobertura mínima de um conjunto de dependências funcionais £ é um conjunto de dependências funcionais F que satisfaz a propriedade dc que cada dependência cm £ está no fechamento F~ dc F. Além disso, essa propriedade se perde se qualquer dependência do conjunto F for removida; F não deve ter redundâncias e as depen­ dências em F estão em um formato-padrão. Usaremos o conceito de um atributo externo em uma dependência funcional para definir a cobertura mínima. Definição. Um atributo em uma dependência funcional é considerado um atributo externo se pudermos removê-lo sem alterar o fechamento do conjunto de dependên­ cias. Formalmente, dado F, o conjunto de dependências funcionais, e uma dependência funcional X —♦ A em F, o atributo Y é externo em X se Y c X, e F implica logicamente (F-(X—* A) o( (X-Y)—* A)). Podemos definir formalmente um conjunto de dependências funcionais F como mínimas se ele satisfizer as seguintes condições:

1. Cada dependência em F tem um único atributo para seu lado direito.

2. Não podemos substituir qualquer dependência X —> A em F por uma dependência Y > A, em que Y é um subconjunto apropriado de X, e ainda ter um conjunto de dependências que seja equivalente a F. 3. Não podemos remover qualquer dependência de F e ainda ter um conjunto de dependências que seja equivalente a F. Podemos pensar em um conjunto mínimo de dependências como um conjunto de dependências em uma forma-padrão ou canônica e sem redundâncias. A condição 1 apenas representa cada dependência em uma forma canônica com um único atributo no lado direito, e é um passo preparatório antes que possamos avaliar se as condi­ ções 2 e 3 são atendidas.4 As condições 2 e 3 garantem que não haja redundâncias nas dependências, com atributos redundantes (conhecidos como atributos externos) no lado esquerdo de uma dependência (Condição 2) ou com uma dependência que pode ser deduzida pelas DFs restantes em F (Condição 3).

4 Esse c o formato-padrão para simplificar as condições c os algoritmos que garantem que não haja redun­ dância em F. Ao usar a regra de inferência RM, podemos convener uma única dependência com vários atri­ butos no lado direito para um conjunto de dependências com atributos isolados nesse mesmo lado.

461

462

Sistemas de banco de dados

Definição. Uma cobertura mínima de um conjunto de dependências funcionais E é um conjunto mínimo de dependências (na forma canônica padrão5 e sem redundân­ cia) equivalente a E. Sempre podemos encontrar pelo menos uma cobertura mínima F para qualquer conjunto de dependências E usando o Algoritmo 15.2. Se vários conjuntos de DFs se qualificam como coberturas mínimas de E pela definição dada, é comum usar critérios adicionais de minimalidade. Por exemplo, podemos escolher o conjunto mínimo com o menor número de dependências ou com o menor tamanho total (o tamanho total de um conjunto de dependências é calculado ao concatenar as dependências e tratando-as como uma sequência de caracteres longa).

Algoritmo 15.2. Encontrando uma cobertura mínima F para um conjunto de dependências funcionais E Entrada: um conjunto de dependências funcionais E. Nota: comentários explicativos são dados ao final de algumas das etapas. Eles seguem o formato: (* comentário ). * 1. Defina F := E.

2. Substitua cada dependência funcional X —* {Aj, A,,...»AJ em F pelas n depen­ dências funcionais X —♦A], X —*A 2,..., X —* A„. * (Isso coloca as DFs em uma forma canônica para teste * ) subsequente 3. Para cada dependência funcional X —* A em F para cada atributo B que é um elemento de X se ( (F - (X —♦ A| | U { (X - |B| ) —> A) | for equivalente a F então substitua X —> A por (X - {B) ) —♦ A em F. Isso constitui a remoção de um atributo externo B contido no lado esquerdo (* X de uma dependência funcional X —»A, quando possível ) * 4. Para cada dependência funcional restante X —♦A em F se {F - {X —* A) ) for equivalente a F, então remova X —* A de F. (* Isso constitui a remoção de uma dependência funcional redundante X —* A de F, quando possível ) * Ilustramos o algoritmo anterior com os seguintes exemplos: Exemplo 1: Seja o conjunto dado de DFs E: {B —> A, D —* A, AB —» D|. Temos de encontrar a cobertura mínima de E. ■ Todas as dependências citadas estão na forma canônica (ou seja, elas têm apenas um atributo no lado direito), de modo que completamos a etapa 1 do Algoritmo 15.2 e podemos prosseguir para a etapa 2. Na etapa 2, precisamos determinar se AB —* D tem algum atributo redundante (externo) no lado esquerdo; ou seja, ele pode ser substituído por B —* D ou A —♦ D? ■ Como B —> A, ao aumentar com B nos dois lados (RI2), temos BB —> AB, ou B —* AB (i). Contudo, AB —» D conforme indicado (ii). ■ Logo, pela regra transitiva (RI3), obtemos de (i) e (ii), B —* D. Assim, AB —* D pode ser substituído por B —* D. ■ Agora, temos um conjunto equivalente ao E original, digamos £': {B —* A, D ->A,B —* D). Nenhuma outra redução é possível na etapa 2, pois todas as DFs têm um único atributo no lado esquerdo. ■ Na etapa 3, procuramos uma DF redundante em E'. Ao usar a regra transitiva em B —* D e D —* A, derivamos B —* A. Logo, B —* A é redundante em E' e pode ser eliminada. 5 É possível usar a regra dc inferência RI5 c combinar as DFs com o mesmo lado esquerdo para formar uma única DF na cobertura mínima em um formaro não padronizado. O conjunto resultante ainda é uma cobertura mínima, conforme ilustrado no exemplo.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

■ Portanto, a cobertura mínima de E é F: {B —* D, D —> A).

O leitor pode verificar que o conjunto original F pode ser deduzido a partir de £; em outras palavras, os dois conjuntos F e E são equivalentes. Exemplo 2: Seja o conjunto dado de DFs G: {A —* BCDE, CD —» £|. ■ Aqui, as DFs indicadas NÃO estão na forma canônica. Logo, primeiro as con­ vertemos para:

£: {A —► B, A —► C, A —* D, A —* £, CD -> £|. ■ Na etapa 2 do algoritmo, para CD * - £, nem C nem D é externo no lado esquerdo, pois não podemos mostrar que C—>£ouD—»£a partir das DFs indicadas. Logo, não podemos substituí-la por nada. ■ Na etapa 3, queremos ver se alguma DF é redundante. Visto que A -» CD e CD ► £, pela regra transitiva (RI3), obtemos A —»£. Assim, A —♦ £ é redundante cm G. ■ Logo, ficamos com o conjunto f, equivalente ao conjunto original G, como: (A- B,A-> C,A -> D, CD —* £]. F é a cobertura mínima. Conforme indicamos * na nota de rodapé 5, podemos combinar as três primeiras DFs usando a regra da união (RI5) e expressar a cobertura mínima como:

Cobertura mínima de G, F: {A —♦ BCD, CD —> £}. Na Seçào 15.3, veremos algoritmos que sintetizam relações 3FN ou FNBC com base cm determinado conjunto dc dependências £ achando primeiro a cobertura mínima F para £. Em seguida, apresentamos um algoritmo simples para determinar a chave de uma relação.

Algoritmo 15.2(a). Encontrando uma chave Ch para R dado um conjunto F dc dependências funcionais Entrada: uma relação R e um conjunto de dependências funcionais F nos atri­ butos de R.

1. Defina Ch := R.

2. Para cada atributo A em Ch {calcule (Ch - A) * em relação a F; se (Ch - A) * contiver todos os atributos em R, defina Ch := Ch — {A) |; No Algoritmo 15.2(a), começamos pela definição de Ch para todos os atributos dc R; podemos dizer que o próprio R c sempre uma superchave default. Depois, removemos um atributo de cada vez e verificamos se os atributos restantes ainda formam uma superchave. Observe, também, que o Algoritmo 15.2(a) determina apenas uma chave das possíveis chaves candidatas para R; a chave retornada depende da ordem em que os atributos são removidos de R na etapa 2.

15.2 Propriedades de decomposições relacionais Agora, voltamos nossa atenção para o processo de decomposição que usamos ao longo do Capítulo 14 para decompor relações a fim de nos livrarmos de depen­ dências indesejadas e alcançarmos formas normais maiores. Na Seção 15.2.1, damos exemplos para mostrar que examinar uma relação individual para testar se ela está cm uma forma normal mais alta, por si só, não garante um bom projeto. Em vez disso, um conjunto de relações, que juntas formam o esquema de banco de dados relacionai, deve possuir certas propriedades adicionais para garantir um bom projeto. Nas seções 15.2.2 e 15.2.3, discutimos duas dessas propriedades: a propriedade dc preservação de dependência e a propriedade de junção não aditiva

463

464

Sistemas de banco de dados

(ou sem perdas). A Seçào 15.2.4 discute as decomposições binárias e a Seçào 15.2.5 discute as decomposições sucessivas de junção nào aditiva.

15.2.1 Decomposição da relação e insuficiência de formas normais Os algoritmos do projeto de banco de dados relacionai que apresentaremos na Seção 15.3 começam de um único esquema de relação universal R = {Af, A,,..., AJ, que inclui todos os atributos do banco de dados. Implicitamente, tornamos a suposição dc relação universal, que declara que cada nome dc atributo é exclusivo. O conjunto F dc dependências funcionais que devem scr mantidas nos atributos dc R é especificado pelos projetistas de banco de dados e se torna disponível aos algo­ ritmos de projeto. Ao utilizar as dependências funcionais, os algoritmos decompõem o esquema de relação universal R cm um conjunto dc esquemas dc relação D = {RV R2,..., Rm}, que se tornará o esquema do banco dc dados relacionai; D c chamado de decomposição de R. Temos de garantir que cada atributo em R aparecerá em pelo menos um esquema de relação R- na decomposição, de modo que nenhum atributo seja perdido. Formalmente, temos

m \JR,= R j=l

Esta é chamada dc condição dc preservação dc atributo de uma decomposição. Outro objetivo é fazer que cada relação individual Rt na decomposição D esteja na FNBC ou na 3FN. Contudo, essa condição não é suficiente para garantir um bom projeto de banco de dados por si só. Temos de considerar a decomposição da relação universal como um todo, além de examinar as relações individuais. Para ilustrar esse ponto, considere a relação LOCALIZACOES_FUNCIONARIO(Nome_funcionario, Local_projeto) da Figura 14.5, que está na 3FN c também na FNBC. Dc fato, qualquer esquema de relação com apenas dois atributos está automaticamente na FNBC.6 Embora LOCALIZACOES.FUNCIONARIO esteja na FNBC, ela ainda faz surgir tuplas falsas quando juntada com FUNCIONARIO_PROJETO(Cpf, Numero_projeto, Horas, Nome_projeto, Local_projeto), que não está na FNBC (ver o resultado da junção natural na Figura 14.6). Logo, LOCALIZACOES.FUNCIONARIO representa um esquema de relação particularmente ruim por sua semântica complicada, pela qual Local_projeto dá o local de um dos projetos em que um funcionário trabalha. Juntar LOCALIZACOES.FUNCIONARIO com PROJETO(Nome_projeto, Numero_projeto, Local.projeto, Numero.departamento) na Figura 14.2 — que está na FNBC —, usando Local.projeto como um atributo de junção, também faz surgir tuplas falsas. Isso enfatiza a necessidade de outros critérios que, com as condições da 3FN ou FNBC, impedem tais projetos ruins. Nas próximas três subseções, discutiremos essas con­ dições adicionais que devem ser mantidas em uma decomposição D como um todo.

15.2.2 Propriedade de preservação de dependência de uma decomposição Seria útil se cada dependência funcional X—>Y especificada em F aparecesse dirctamente em um dos esquemas de relação Rf- na decomposição D ou pudesse ser deduzida das dependências que aparecem em alguma Rr Informalmente, essa é a condição de preservação de dependência. Queremos preservar as dependências porque cada uma delas em F representa uma restrição no banco de dados. Se uma Como exercício, o leitor deverá provar que essa afirmação é verdadeira.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

das dependências nào for representada em alguma relação individual R] da decom­ posição, não podemos impor essa restrição ao lidar com uma relação individual. Podemos ter de juntar várias relações a fim de incluir todos os atributos envolvidos nessa dependência. Não é necessário que as dependências exatas especificadas em F apareçam elas mesmas nas relações individuais da decomposição D. É suficiente que a união das

dependências que se mantêm nas relações individuais em D seja equivalente a F. Agora, vamos definir esses conceitos de maneira mais formal. Definição. Dado um conjunto de dependências F em R, a projeção de F em R(, indicada por nRJF), cm que Rf é um subconjunto de R, é o conjunto das dependências X —* Y em F+ tal que os atributos em X U Y estejam todos contidos em Rr Logo, a projeção de F sobre cada esquema de relação Rf na decomposição D é o conjunto de dependências funcionais em F‘, o fechamento de F, tal que todos os atributos dos lados esquerdo c direito estejam cm R-. Dizemos que uma decomposição D = {Rj, R2, Rw} de R está preservando a dependência em relação a F se a união das projeções de F em cada R, em D for equivalente a F; ou seja, ({nR (F)) U ... U (nR (F)))+ = F *. Se uma decomposição não for do tipo que preserva a dependência, alguma depen­ dência é perdida na decomposição. Para verificar se uma dependência perdida se mantém, temos de obter a junção (JOIN) de duas ou mais relações na decomposição para obter uma relação que inclua todos os atributos dos lados esquerdo e direito da dependência perdida, e depois verificar se a dependência se mantém no resultado do JOIN — uma opção que não é prática. Um exemplo de decomposição que não preserva dependências aparece na Figura 14.13(a), em que a dependência funcional DF2 é perdida quando LOTES1A é decom­ posto em {LOTES1AX, LOTES1AYJ. As decomposições da Figura 14.12, no entanto, estão preservando a dependência. De modo semelhante, para o exemplo da Figura 14.14, não importa que decomposição seja escolhida para a relação ENSINAfAluno, Disciplina, Professor), das três fornecidas no texto, uma ou ambas as dependências originalmenre presentes na certa serão perdidas. Fazemos uma afirmação a seguir relacionada a essa propriedade sem fornecer qualquer prova.

Afirmação 1. Sempre é possível encontrar uma decomposição de preservação de dependência D em relação a F, de modo que cada relação Rf em D esteja na 3FN.

15.2.3 Propriedade de junção não aditiva (sem perdas) de uma decomposição Outra propriedade que uma decomposição D deve possuir é a de junção não aditiva, que garante que nenhuma tupla falsa é gerada quando uma operação de junção natural (NATURAL JOIN) é aplicada às relações resultantes da decomposição. Já ilustramos esse problema na Seção 14.1.4 com o exemplo das figuras 14.5 e 14.6. Como essa é uma propriedade de uma decomposição de esquemas de relação, a condição de nenhuma tupla falsa deve ser mantida em cada estado de relação válido — ou seja, cada estado dc relação que satisfaça as dependências funcionais em F. Logo, a propriedade dc junção sem perda é sempre definida em relação a um conjunto específico F de dependências.

Definição. Formalmcntc, uma decomposição D = (Rp R„..., Rm) dc R tem a pro­ priedade dc junção sem perdas (não aditiva) cm relação ao conjunto de dependências F em R se, para cada estado de relação r de R que satisfaça F, o seguinte for mantido, em que * é o NATURAL JOIN de todas as relações em D: * (n Ri(r),..., 7tR^(r)) = r. A palavra “perdas” cm sem perdas refere-se à perda de informação, c não à perda dc tuplas. Se uma decomposição não tem a propriedade dc junção sem perdas, pode­ mos obter tuplas falsas adicionais após as operações PROJECT (n) e NATURAL JOIN (* )

465

466

Sistemas de banco de dados

serem aplicadas; essas tuplas adicionais representam informações errôneas ou inválidas. Preferimos o termo junção não aditiva porque ele descreve a situação com mais precisão. Embora o termo junção sem perdas seja popular na literatura, usamos o termo junção não aditiva na descrição da propriedade XJB da Seção 14.5.1. Daqui'por diante usare­ mos o termo junção não aditivay que é autoexplicarivo e não é ambíguo. A propriedade de junção não aditiva garante que não haverá tuplas falsas após a aplicação das ope­ rações PROJECT e JOIN. Porém, às vezes podemos usar o termo projeto sem perdas para nos referirmos a um projeto que representa uma perda de informação. A decomposição de FUNCIONARIO_PROJETO(Cpf, Numero_projeto, Horas, Nomejuncionario, Nome_projeto, Local_projeto) na Figura 14.3 para LOCAUZACOES_FUNCIONARIO(Nome_funcionario, Local_projeto) e FUNCIONARIO_PROJETO1(Cpf, Numero_projeto, Horas, Nome_projeto, LocaLprojeto) na Figura 14.5 obviamente não tem a propriedade de junção não aditiva, conforme ilustrado pelo resultado parcial do NATURAL JOIN na Figura 14.6. Fornecemos um teste mais simples no caso das decomposições binárias para verificar se a decompo­ sição é não aditiva — ela foi chamada de propriedade XJB na Seção 14.5.1. Usaremos um procedimento geral para testar se qualquer decomposição D de uma relação em n relações é não aditiva com relação a um conjunto de dependências funcionais dadas F na relação; ele é apresentado como o Algoritmo 15.3.

Algoritmo 15.3. Testando a propriedade de junção não aditiva Entrada: uma relação universal R, uma decomposição D = {Rp R2,..., Rw| de R e um conjunto F de dependências funcionais. Nota: comentários explicativos são dados ao final de algumas das etapas. Eles seguem o formato: (* comentário ). * 1. Crie uma matriz inicial S com uma linha i para cada relação R; em D, e uma coluna / para cada atributo A: em R.

2. Defina S(/,/'):= blf para todas as entradas de matriz. * (Cada distinto associado aos índices * ). (/,/)

b~ é um símbolo

3. Para cada linha i representando o esquema de relação R, {para cada coluna j representando o atributo A{se (relação R( inclui atributo A-) então defina S(i,j):= a-;};}; (* cada um símbolo distinto associado ao índice (/) ). *

é

4. Repita o loop a seguir ate que uma execução de loop completa resulte em nenhuma mudança para 5 {para cada dependência funcional X —» Y em F {para todas as linhas em 5 que têm os mesmos símbolos nas colu­ nas correspondentes aos atributos em X {faça que os símbolos em cada coluna que corresponde a um atributo em Y sejam iguais em todas essas linhas da seguinte forma: se qualquer uma das linhas tiver um símbolo a para a coluna, defina as outras linhas com esse mesmo símbolo a na coluna. Se nenhum símbolo a existir para o atributo em qualquer uma das linhas, escolha um dos símbolos b que aparecem em uma das linhas para o atributo e defina as outras linhas com o mesmo símbolo b na coluna ;);) 5. Se uma linha for composta inteiramente de símbolos ay então a decomposição tem a propriedade de junção não aditiva; caso contrário, ela não tem.

Dada uma relação R decomposta em uma série de relações Rp R2, ..., R,n, o Algoritmo 15.3 inicia a matriz 5 que consideramos ser algum estado de relação r de R. A linha i em 5 representa uma tupla f, (correspondente à relação R.) que tem

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

símbolos a nas colunas que correspondem aos atributos de Rt e símbolos b nas colu­ nas restantes. O algoritmo então transforma as linhas dessa matriz (durante o loop na etapa 4), de modo que representem tuplas que satisfazem todas as dependências funcionais em F. Ao final da etapa 4, duas linhas quaisquer em 5 — as quais repre­ sentam duas tuplas em r— que combinam em seus valores para os atributos do lado esquerdo de X de uma dependência funcional X -> Y em F também combinarão em seus valores para os atributos do lado direito Y. Pode-se demonstrar que, depois de aplicar o loop da etapa 4, se qualquer linha em S acabar com todos os símbolos a, então a decomposição D tem a propriedade de junção não aditiva em relação a F. Se, ao contrário, nenhuma linha acabar com todos os símbolos a, D não satisfaz a propriedade de junção sem perdas. Nesse caso, o estado de relação r representado por 5 ao final do algoritmo será um exemplo de um estado de relação r de R que satisfaz as dependências em F, mas não a condição de junção não aditiva. Portanto, essa relação serve como um contraexemplo que prova que D não tem a propriedade de junção não aditiva em relação a F. Observe que os símbolos a e b não possuem significado especial ao final do algoritmo. A Figura 15.1(a) mostra como aplicamos o Algoritmo 15.3 à decomposição do esquema da relação FUNCIONARIO.PROJETO da Figura 14.3(b) para os dois esque­ mas de relação FUNCIONARIO.PROJETOl e LOCALIZACOES.FUNCIONARIO da Figura 14.5(a). O loop na etapa 4 do algoritmo não pode mudar quaisquer símbolos b para símbolos a. Logo, a matriz resultante 5 não tem uma linha com todos os símbolos a e, portanto, a decomposição não tem a propriedade de junção não aditiva. A Figura 15.1(b) mostra outra decomposição de FUNCIONARIO.PROJETO (para FUNCIONÁRIO, PROJETO e TRABALHA.EM) que tem a propriedade de junção não aditiva, e a Figura 15.1(c) mostra como aplicamos o algoritmo a essa decomposição. Quando uma linha consiste apenas em símbolos a, concluímos que a decomposição tem a propriedade de junção não aditiva e podemos parar de aplicar as dependências funcionais (etapa 4 no algoritmo) à matriz 5.

15.2.4 Testando decomposições binárias para a propriedade de junção não aditiva O Algoritmo 15.3 nos permite testar se determinada decomposição D em w relações obedece à propriedade de junção não aditiva em relação a um conjunto de dependências funcionais F. Existe um caso especial de decomposição, chamado decomposição binária — decomposição de uma relação R em duas relações. Um teste, chamado teste de propriedade NJB, mais fácil de aplicar que o Algoritmo 15.3, mas c limitado apenas a decomposições binárias, foi apresentado na Seção 14.5.1. Ele foi usado para realizar a decomposição binária da relação ENSINA, que atendeu a 3FN, mas não atendeu a FNBC, em duas relações que satisfizeram essa propriedade.

15.2.5 Decomposições sucessivas de junção não aditiva Vimos a decomposição sucessiva de relações durante o processo de segunda e terceira normalização nas seções 14.3 e 14.4. Para verificar se essas decomposições são não aditivas, precisamos garantir outra propriedade, conforme estabelecido na Afirmação 2.

Afirmação 2 (preservação da não aditividade nas decomposições sucessivas). Sc uma decomposição D = |Rp R2,..., Rm} dc R tem a propriedade dc junção não aditiva (sem perdas) em relação a um conjunto de dependências funcionais F em R, e se uma decomposição D, = (Qp Q2,...» QJ de R, tem a propriedade de junção não aditiva em relação à projeção de F em R:, então a decomposição D» = (R1? R2,..., R^, QI? Q2,..., Qk, R^t,..., Rm] de R tem a propriedade de junção não aditiva em relação a F.

467

468

Sistemas de banco de dados

(a) R = {Cpf, Nomejuncionario, Numero_projeto, Nome_projeto, LocaLprojeto, Horas}

D = {/?,, R2}

R} = LOCALIZACOES_FUNCIONARIO {Nomejuncionario, Local_projeto} R2 = FUNCIONARIO_PROJETO1{Cpf, Numero.projeto, Horas, Nome_projeto, Local_projeto}

F= {Cpf —> Nomejuncionario; Numero_projeto —> {Nome.projeto, LocaLprojeto}; {Cpf, Numero_projeto) —> Horas} Cpf «1

«2

Nome, funcionário

Numero, projeto

Nome, projeto

Local, projeto

Horas

í>,4

â5

*>16

34

*5

a6

d2 ai

t>22

a3

(Nenhuma mudança na matriz após aplicar as dependências funcionais)

(b) FUNCIONÁRIO

Cpf

(c)

PROJETO

TRABALHA EM

Numero. projeto

Nome_ funcionário

Nome. projeto

Local. projeto

Cpf

R = {Cpf, Nomejuncionario, Numero_projeto, Nome_projeto, LocaLprojeto, Horas}

Numero, projeto

Horas

D = {R.,R2,RJ

R, = FUNCIONÁRIO = {Cpf, Nomejuncionario}

R2 = PROJETO = {Numero_projeto, Nome_projeto, LocaLprojeto} R3 = TRABALHA.EM = {Cpf, Numero_projeto, Horas} F = {Cpf —* Nomejuncionario; Numero.projeto —* {Nome.projeto, LocaLprojeto}; {Cpf, Numero_projeto} —* Horas}

Cpf

Nome, funcionário

a-

a2

«2

*>21

«3

a.

Nome, projeto

Local. projeto

Horas

*>13

*>14

*>15

*>16

*>22

â3

a4

a5

*>32

â3

*>34

*>35

Nome . projeto

Local _ projeto

Numero, projeto

%

(Matriz original S no início do algoritmo)

Cpf

Nome funcionário

a.

a2

«2

*>21

*>22

«3

a.

X,-5?

Numero. projeto *>13

*>14

*>15

*3

*4

*5

X,a4

X16

*>26

a6

(Matriz original S depois de aplicar as duas primeiras dependências funcionais;

a última linha tem apenas símbolos 'a' e, por isso, paramos) Figura 15.1 Teste de junção não aditiva para decomposições n-árias. (a) Caso 1: decomposição de FUNCIONARIO-PROJETO

em FUNCIONARIO-PROJET01 e LOCALIZACOES-FUNCIONARIO falha no teste, (b) Uma decomposição de FUNCIONARIOPROJETO que tem a propriedade de junção sem perdas, (c) Caso 2: decomposição de FUNCIONARIO-PROJETO em

FUNCIONÁRIO, PROJETO e TRABALHA.EM satisfaz o teste.

15.3 Algoritmos para projeto de esquema de banco de dados relacionai Agora, apresentamos dois algoritmos para criar uma decomposição relacionai com base em uma relação universal. O primeiro algoritmo decompõe uma relação

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

universal em relações na 3FN que preservam a dependência, que também possui a propriedade da junção nào aditiva. O segundo algoritmo decompõe um esquema de relação universal em esquemas na FNBC que possuem a propriedade de junção não aditiva. Não é possível projetar um algoritmo para produzir relações FNBC que satisfaçam a decomposição tanto de preservação de dependência quanto de junção não aditiva.

15.3.1 Decomposição de preservação de dependência e junção não aditiva (sem perdas) em esquemas 3FN Até aqui, sabemos que não é possível ter todos os três itens a seguir: (1) projeto sem perdas (não aditivo) garantido, (2) preservação dc dependência garantida c (3) todas as relações na FNBC. Conforme já enfatizamos algumas vezes, a primeira condição é essencial e não pode ser comprometida. A segunda condição é desejável, mas não essencial, e pode ser deixada de lado se insistirmos em alcançar a FNBC. As DFs originais perdidas podem ser recuperadas por uma operação JOIN sobre os resultados da decomposição. Agora, vamos apresentar um algoritmo no qual con­ seguimos obter as condições 1 e 2 e somente garantir a 3FN. O Algoritmo 15.4 cria uma decomposição D dc R que faz o seguinte:

■ Preserva dependências. ■ Tem a propriedade de junção não aditiva. ■ E tal que cada esquema de relação resultante na decomposição está na 3FN. Algoritmo 15.4. Síntese relacionai para a 3FN com preservação de dependência e propriedade de junção não aditiva Entrada: uma relação universal R e um conjunto dc dependências funcionais F nos atributos de R.

1. Ache uma cobertura mínima G para F (use o Algoritmo 15.2).

2. Para cada X do lado esquerdo de uma dependência funcional que aparece em G, crie um esquema de relação em D com atributos (X U (AJ U (A2) ... U (AJ), em que X —* Ap X —* A2,...» X —* Ak são as únicas dependências em G com X como lado esquerdo (X é a chave dessa relação). 3. Se nenhum dos esquemas de relação em D tiver uma chave de R, crie mais um esquema de relação em D que contenha atributos que formam uma chave de R. (O Algoritmo 15.2(a) pode ser usado para descobrir uma chave.) 4. Elimine relações redundantes do conjunto de relações resultante no esquema de banco de dados relacionai. Uma relação R é considerada redundante se R for uma projeção de outra relação 5 no esquema; como alternativa, R é substituída por S.7 A etapa 3 do Algoritmo 15.4 consiste em identificar uma chave Ch de R. O Algoritmo 15.2(a) pode ser usado para identificar uma chave Ch de R com base no conjunto de dependências funcionais F dadas. Observe que o conjunto de depen­ dências funcionais usadas para determinar uma chave no Algoritmo 15.2(a) poderia ser F ou G, pois são equivalentes. Exemplo 1 do Algoritmo 15.4. Considere a seguinte relação universal: U(Cpf_funcionario, Numero_projeto, Salariojuncionario, Telefonejuncionario,

Numero.departamento, Nome.projeto, LocaLprojeto)

Observe que existe um tipo adicional de dependência: R é uma projeção da junção de duas ou mais relações no esquema. Esse tipo dc redundância c considerado uma dependência dc junção, conforme discutimos na Seção 14.7. Daí, tecnicamente, ela pode continuar a existir sem atrapalhar o status 3FN para o esquema.

469

470

Sistemas de banco de dados

Cpf.fundonario, Salario.funcionario e Telefone_funcionario referem-se ao número do Cadastro dc Pessoa Física, salário e número de telefone do funcionário. Numero, projeto, Nome.projeto e Local.projeto referem-se a número, nome e local do projeto. Numero.departamento é o número do departamento. As seguintes dependências estão presentes: DF1: Cpf.funcionario -♦ {Salario.funcionario, Telefone.fundonario, Numero.departamento)

DF2: Numero_projeto —*(Nome_projeto, Local_projeto) DF3: Cpf.fundonario, Numero.projeto —* {Salario.funcionario, Telefone.funcionario, Numero.departamento, Nome.projeto, Local.projeto)

Em virtude de DF3, o conjunto de atributos {Cpf.funcionário, Numero.projeto) representa uma chave da relação universal. Logo, F, o conjunto de DFs dadas, inclui {Cpf.funcionario -> Salario.funcionario, Telefone.funcionario, Numero.departamento; Numero_projeto —» Nome_projeto, Local.projeto; Cpf.funcionario, Numero.projeto —» Salario.funcionario, Telefone.funcionario, Numero.departamento, Nome_projeto, Local.projeto). Ao aplicar o Algoritmo 15.2 de cobertura mínima, na etapa 3 vemos que Numero, projeto é um atributo redundante em Cpf.funcionario, Numero_projeto —> Salario.fun­ cionario, Telefone.fundonario, Numero.departamento. Além disso, Cpf.funcionario é externo em Cpf.funcionario, Numero_projeto —* Nome.projeto, Local_projeto. Logo, a cobertura mínima consiste em DF1 e DF2 apenas (DF3 sendo completamente redundante) da seguinte forma (se agruparmos atributos com o mesmo lado direito em uma DF): Cobertura mínima G: {Cpf.funcionario -> Salario_funcionario,Telefone_funcionario, Numero.departamento; Numero.projeto —* Nome.projeto, Local.projeto) A segunda etapa do Algoritmo 15.4 produz as relações Rt e R2 como: Rj (Cpf_funcionario, Salario.funcionario, Telefone.fundonario, Numero.departamento) R2 (Numero_proieto, Nome_projeto, Local_projeto) Na etapa 3, geramos uma relação correspondente à chave {Cpf.funcionario, Numero.projeto) de U. Logo, o projeto resultante contém:

Rt (Cpf.funcionario, Salario.funcionario, Telefone.funcionario, N u mero.depa rtamento) R2 (Numero-projeto, Nome_projeto, Local.projeto) R3 (Cof funcionário. Numero projeto)

Esse projeto alcança as propriedades desejáveis de preservação de dependência e junção não aditiva.

Exemplo 2 do Algoritmo 15.4 (caso X). Considere o esquema de relação L0TES1A mostrado na Figura 14.13(a). Suponha que essa relação seja dada como uma relação universal U (Propriedade, Cidade, Lote, Area) com as seguintes dependências funcionais: DF1: Propriedade —* Lote, Cidade, Area DF2: Lote, Cidade —♦ Area, Propriedade DF3: Area -> Cidade

Chamamos LOTES 1 A(ldentificador_propriedade, Nome.cidade, Numero.lote, Area) de DF1, DF2 e DF5 na Figura 14.13(a). Os significados desses atributos e a impli­ cação das dependências funcionais acima foram explicados na Seção 14.4. Para facilitar a referência, vamos abreviar esses atributos com uma letra de cada um e representar as dependências funcionais como o conjunto

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

F: { P —> LCA, LC —» AP, A —» C }

A relação universal com os atributos abreviados é U (P, C, L, A). Se aplicarmos o Algoritmo 15.2 de cobertura mínima a F (na etapa 2), primeiro representamos o conjunto F como F: {P — L, P -* C, P — A, LC -> A, LC — P, A — C)

No conjunto F, P —* A pode ser deduzido de P —* LC e LC —* A; logo, P —* A por transitividade e, portanto, é redundante. Assim, uma cobertura mínima possível é Cobertura mínima GX: {P —> LC, LC —♦ AP, A -> C) Na etapa 2 do Algoritmo 15.4, produzimos o projeto X (antes de remover as relações redundantes) usando a cobertura mínima como Projeto X: Rj (B L, C), R2 (L £/ A, P) e R3 (A, C) Na etapa 4 do algoritmo, descobrimos que R3 está incluído em R, (ou seja, R3 sempre é uma projeção de R, e R, tambémé uma projeção de RJ. Logo, essas duas relações são redundantes. Assim, o esquema 3FN que alcança as duas propriedades desejáveis é (depois de remover as relações redundantes)

Projeto X: R2 (L, C, A, P) ou, em outras palavras, ele é idêntico à relação LOTES1A (ldentificador_propriedade, Numerojote, Nome_cidade, Area) que determinamos, na Seção 14.4.2, que se encon­ tra na 3FN.

Exemplo 2 do Algoritmo 15.4 (caso Y). Começando com LOTES1A como a relação universal e com o mesmo conjunto dado de dependências funcionais, a segunda etapa do Algoritmo 15.2 de cobertura mínima produz, como antes, F: {P —* C, P —> A, P —► L, LC -> A, LC -> P, A -► C)

A DF LC —* A pode ser considerada redundante porque LC —* P e P —* A implica LC —* A por transitividade. Além disso, P -► C pode ser considerado redundante porque P —> A e A —> C implica P —> C por transitividade. Isso gera uma cobertura mínima diferente, como

Cobertura mínima GY: ( P —* LA, LC —* P, A —* C ) O projeto alternativo Y produzido pelo algoritmo agora é Projeto Y: 5| (£ A, L), S, (L, Ç, P) e S3 (A, C) Observe que esse projeto tem três relações 3FN, nenhuma delas podendo ser considerada redundante pela condição na etapa 4. Todas as DFs no conjunto ori­ ginal F são preservadas. O leitor notará que, das três relações anteriores, Sj e S3 foram produzidas como o projeto FNBC pelo procedimento dado na Seção 14.5 (implicando que S2 é redundante na presença de S] e S3). No entanto, não podemos eliminar a relação S2 do conjunto de três relações 3FN acima, visto que ela não é uma projeção de S| ou S3. É fácil ver que S2 é uma relação válida e significativa, que possui as duas chaves candidatas (L, C) e P colocadas lado a lado. Observe ainda que $2 preserva a DF LC —> P, que é perdida se o projeto final tiver apenas e S3.0 projeto Y, portanto, permanece como um resultado final possível da aplicação do Algoritmo 15.4 à relação universal dada, que oferece relações na 3FN. As duas variações acima da aplicação do Algoritmo 15.4 à mesma relação uni­ versal com determinado conjunto dc DFs ilustrou duas coisas:

■ E possível gerar projetos 3FN alternativos começando com o mesmo conjunto de DFs.

471

472

Sistemas de banco de dados

■ É concebível que, em alguns casos, o algoritmo realmente produza relações que

satisfaçam a FNBC e pode incluir relações que também mantenham a propriedade de preservação de dependência.

15.3.2 Decomposição de junção não aditiva para esquemas FNBC O próximo algoritmo decompõe um esquema de relação universal R = (Ap A2, ...»AJ em uma decomposição D = (R,, R2,..., Rm], tal que cada R-está na FNBC e a decomposição D tem a propriedade de junção sem perda em relação a F. O Algoritmo 15.5 utiliza a propriedade NJB e a afirmação 2 (preservação dc não aditividade cm decomposições sucessivas) para criar uma decomposição de junção não aditiva D = (Rp R2,...»Rm) de uma relação universal R baseada em um conjunto de dependências funcionais F, tal que cada Ry em D esteja na FNBC. Algoritmo 15.5. Decomposição relacionai para FNBC com propriedade de junção não aditiva Entrada: uma relação universal R c um conjunto de dependências funcionais F nos atributos de R. 1. Defina D := {R|;

2. Enquanto existe um esquema dc relação Q em D que não esteja na FNBC, faça ( escolha um esquema de relação Q em D que não esteja na FNBC; determine uma dependência funcional X —* Y em Q que viole a FNBC; substitua Q em D pelos dois esquemas de relação (Q - Y) e (X U Y);

);

cada passagem pelo loop no Algoritmo 15.5, decompomos um esquema de relação Q que não está na FNBC cm dois esquemas de relação. De acordo com a propriedade NJB para decomposições binárias e a afirmação 2, a decomposição D tem a propriedade de junção não aditiva. Ao final do algoritmo, todos os esquemas de relação em D estarão na FNBC. Ilustramos a aplicação desse algoritmo ao esquema de relação ENSINA da Figura 14.14; ele é decomposto em ENSINA1 (Professor, Disciplina) e ENSINA2 (Professor. Aluno), pois a dependência DF2 Professor —»Disciplina viola a FNBC. Na etapa 2 do Algoritmo 15.5, é necessário determinar se um esquema de relação Q está ou não na FNBC. Um método para fazer isso é testar, para cada dependência funcional X —♦ Y em Q, se X’deixa de incluir todos os atributos em Q, determinando assim se X é ou não uma (super) chave em Q. Outra técnica está fundamentada em uma observação de que, sempre que um esquema de relação Q tem uma violação da FNBC, existe um par dc atributos A c B em Q, tal que {Q - {A, B}) > A. Ao calcular o fechamento {Q - {A, B} }* para cada par de atributos {A, B} de Q, e verificar se o fechamento inclui A (ou B), podemos determinar se Q está na FNBC. E importante observar que a teoria das decomposições por junção não aditiva se baseia na suposição de que nenhum valor NULL é permitido para os atributos de junção. A próxima seção discute alguns dos problemas que os NULLs podem causar nas decomposições relacionais e contém uma discussão geral dos algoritmos para o projeto relacionai por síntese, apresentado nesta seção.

15.4 Sobre NULLs, tuplas suspensas e projetos relacionais alternativos Nesta seção, discutiremos algumas questões gerais relacionadas aos problemas que surgem quando o projeto relacionai não é abordado corretamente.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

15.4.1 Problemas com valores NULL e tuplas suspensas Temos de considerar com cuidado os problemas associados a NULLs ao projetar um esquema de banco de dados relacionai. Ainda nào existe uma teoria de projeto relacionai totalmente satisfatória e que inclua valores NULL Um problema ocorre quando algumas tuplas têm valores NULL para atributos que serão usados para jun­ tar relações individuais na decomposição. Para ilustrar isso, considere o banco de dados mostrado na Figura 15.2(a), no qual mostramos duas relações, FUNCIONÁRIO e DEPARTAMENTO. As duas últimas tuplas de funcionários — ‘Borges' e ‘Bentes’ — representam funcionários recém-contratados, que ainda nào foram atribuídos a um departamento (suponha que isso não viole quaisquer restrições dc integridade). Agora, suponha que queiramos recuperar uma lista de valores (Nome.funcionario, Nome.departamento) para todos os funcionários. Se aplicarmos a operação NATURAL JOIN sobre FUNCIONÁRIO e DEPARTAMENTO [Figura 15.2(b)], as duas tuplas mencio­ nadas nào aparecerão no resultado. A operação OUTER JOIN, discutida no Capítulo 8, pode lidar com esse problema. Lembre-se de que, se apanharmos a OUTER LEFT JOIN de FUNCIONÁRIO com DEPARTAMENTO, as tuplas em FUNCIONÁRIO que possuem NULL para o atributo de junção aparecerão no resultado, com uma tupla imaginá­ ria em DEPARTAMENTO, que rem NULLs para rodos os valores de atributo. A Figura 15.2(c) mostra o resultado. Em geral, sempre que um esquema de banco de dados relacionai é projetado, em que duas ou mais relações são intcr-rclacionadas por chaves estrangeiras, deve-se dedicar um cuidado em particular para observar os valores NULL em potencial nas chaves estrangeiras. Isso pode causar perda de informação inesperada nas consultas que envolvem junções sobre essa chave estrangeira. Além disso, se houver NULLs em outros atributos, como Salario, seu efeito sobre funções embutidas como SUM e AVERAGE deve ser cuidadosamente avaliado. Um problema relacionado é o das tuplas suspensas, que pode ocorrer se execu­ tarmos uma decomposição em demasia. Suponha que decomponhamos a relação FUNCIONÁRIO da Figura 15.2(a) ainda mais para FUNCIONÁRIO-1 e FUNCIONARIO_2, como mostram as figuras 15.3(a) e 15.3(b). Se aplicarmos a operação NATURAL JOIN a FUNCIONARIO.1 e FUNCIONARIO_2, obtemos a relação FUNCIONÁRIO origi­ nal. Porém, podemos usar a representação alternativa, mostrada na Figura 15.3(c), na qual nào incluímos uma tupla em FUNCIONARIO_3 se o funcionário não tiver sido atribuído a um departamento (em vez de incluir uma tupla com NULL para Numero.departamento, como em FUNCIONARIO.2). Sc usarmos FUNCIONARIO.3 no lugar dc FUNCIONARIO.2 c aplicarmos uma NATURAL JOIN cm FUNCIONARIO.1 c FUNCIONARIO.3, as tuplas para Borges e Bentes não aparecerão no resultado. Estas são chamadas tuplas suspensas em FUNCIONARIO.1 porque são representadas em apenas uma das relações que representam funcionários, e por isso se perdem se aplicarmos uma operação (INNER) JOIN.

15.4.2 Discussão sobre algoritmos de normalização e projetos relacionais alternativos Um dos problemas com os algoritmos de normalização que descrevemos é que o projetista primeiro precisa especificar todas as dependências funcionais relevantes entre os atributos do banco dc dados. Essa não é uma tarefa simples para um banco dc dados grande, com centenas dc atributos. Deixar dc especificar uma ou duas depen­ dências importantes pode resultar em um projeto indesejável. Outro problema é que, cm geral, esses algoritmos nào sào determinísticos. Por exemplo, os algoritmos de síntese (algoritmos 15.4 c 15.6) exigem a especificação de uma cobertura mínima G

473

474

Sistemas de banco de dados

(a) FUNCIONÁRIO Numero_ departamento

Q2Í

Data_ nascimento

Silva. João B.

12345678966

09-01-1965

Rua das Flores, 751, Sào Paulo. SP

5

Wong, Fernando T.

33344555587

08-12-1955

Rua da Lapa, 34. São Paulo, SP

5

Zelaya, Alice 1

99988777767

19-07-1968

Rua Souza Lima. 35. Curitiba, PR

4

Souza, Jennifer S.

98765432168

20-06-1941

Av. Arthur de Lima, 54, Santo André, SP

4

Lima, Ronaldo K.

66688444476

15-09-1962

Rua Rebouças, 65. Piracicaba, SP

5

Leite. Joice A.

45345345376

31-07-1972

Av. Lucas Obes» 74, São Paulo. SP

5

Pereira, André V.

98798798733

29-03-1969

Rua Timbira, 35. São Paulo, SP

4

Brito, Jorge E.

88866555576

10-11-1937

Rua do Horto, 35, São Paulo, SP

1

Borges, Anderson C.

99977555511

26-04-1965

Rua Brás Leme, 6530, Santo André, SP

NULL

Bentes, Carlos M.

88866444433

09-01-1963

Av. Paes de Barros, 7654. São Paulo, SP

NULL

Numero, departamento

Gerente_ departamento

Pesquisa

5

33344555587

Administração

4

98765432168

Matriz

1

88866555576

Nome_funcionario

Endereço

DEPARTAMENTO Nome departamento

(b) Numero_ departamento

Çfií

Data_ nascimento

Silva. João B.

12345678966

09-01-1965

Rua das Flores» 751, São Paulo, SP

5

Pesquisa

33344555587

Wong, Fernando T.

33344555587

08-12-1955

Rua da Lapa, 34. São Paulo, SP

5

Pesquisa

33344555587

Zelaya, Alice J.

99988777767

19-07-1968

Rua Souza Uma, 35, Curitiba, PR

4

Administração

98765432168

Souza, Jennifer S.

98765432168

20-06-1941

Av. Arthur de Uma, 54. Santo André, SP

4

Administração

98765432168

Lima, Ronaldo K.

66688444476

15-09-1962

Rua Rebouças, 65, Piracicaba, SP

5

Pesquisa

33344555587

Leite, Joice A.

45345345376

31-07-1972

Av. Lucas Obes 74, São Paulo, SP

5

Pesquisa

33344555587

Pereira. André V.

98798798733

29-03-1969

Rua Timbira, 35, São Paulo, SP

4

Administração

98765432168

Brito, Jorge E.

88866555576

10-11-1937

Rua do Horto, 35, São Paulo, SP

1

Matriz

88866555576

Nome_ funcionário

Endereço

Nome_ departamento

Gerente_ departamento

(c) Nome funcionário

Numero departamento

Nome departamento

Çfif

Data nascimento

Silva. João B.

12345678966

09-01-1965

Rua das Flores, 751, São Paulo, SP

5

Pesquisa

33344555587

Wong. Fernando T.

33344555587

08-12-1955

Rua da Lapa, 34. São Paulo, SP

5

Pesquisa

33344555587

Zelaya, Aíce J.

99988777767

19-07-1968

Rua Souza Uma, 35, Curitiba, PR

4

Administração

98765432168

Souza, Jennifer S.

98765432168

20-06-1941

Av. Arthur de Uma, 54, Santo André, SP

4

Administração

98765432168

Lima, Ronaldo K.

66688444476

15-09-1962

Rua Rebouças» 65. Piracicaba, SP

5

Pesquisa

33344555587

Leite, Joice A.

45345345376

31-07-1972

Av. Lucas Obes, 74. São Paulo. SP

5

Pesquisa

33344555587

Pereira, André V.

98798798733

29-03-1969

Rua Timbira, 35, Sào Paulo, SP

4

Administração

98765432168

Brito, Jorge E.

88866555576

10-11-1937

Rua do Horto, 35, São Paulo, SP

1

Matriz

88866555576

Borges, Anderson C.

99977555511

26-04-1965

Rua Brás Leme, 6530, Santo André, SP

NULL

NULL

NULL

Bentes, Carlos M.

88866444433

09-01-1963

Av. Paes de Barros» 7654, São Paulo, SP

NULL

NULL

NULL

Endereço

Gerente departamento

Figura 15.2 Problemas com junções de valor NULL (a) Algumas tuplas de FUNCIONÁRIO têm NULL para o atributo de junção Numero.departamento. (b) Resultado da aplicação do NATURAL JOIN às relações FUNCIONÁRIO e

DEPARTAMENTO, (c) Resultado da aplicação de OUTER LEFT JOIN a FUNCIONÁRIO e DEPARTAMENTO.

Capítulo 15

(a)

Algoritmos de projeto de banco de dados relacionai e demais dependências

FUNCIONÁRIO 1 Nome funcionário

Cpf

Data,

Endereço

nascimento

Silva, João B.

12345678966

09-01-1965

Rua das Flores, 751, São Paulo, SP

Wong, Fernando T.

33344555587

08-12-1955

Rua da Lapa, 34, São Paulo, SP

Zelaya, Alice 1

99988777767

19-07-1968

Rua Souza Lima, 35, Curitiba, PR

Souza, Jennifer S.

98765432168

20-06-1941

Av. Arthur de Uma, 54, Santo André, SP

Uma, Ronaldo K.

66688444476

15-09-1962

Rua Rebouças, 65, Piracicaba, SP

Leite, Joice A

45345345376

31-07-1972

Av. Lucas Obes, 74, São Paulo, PR

Pereira, André V.

98798798733

29-03-1969

RuaTimbira, 35, São Paulo, SP

Brito, Jorge E.

88866555576

10-11-1937

Rua do Horto, 35, São Paulo, SP

Borges, Anderson C.

99977555511

26-04-1965

Rua Brás Leme, 6530, Santo André, SP

Bentes, Carlos M.

88866444433

09-01-1963

Av. Paes de Barros, 7654, São Paulo, SP

(b) FUNCI0NARI0.2

(c)

FUNCIONÁRIO 3

Numero,

Numero,

Cpf

departamento

Cpf

departamento

12345678966

5

12345678966

5

33344555587

5

33344555587

5

99988777767

4

99988777767

4

98765432168

4

98765432168

4

66688444476

5

66688444476

5

45345345376

5

45345345376

5

98798798733

4

98798798733

4

88866555576

1

88866555576

1

99977555511

NULL

88866444433

NULL

Figura 15.3 O problema de tupla suspensa, (a) A relação FUNCIONÁRIO-1 (inclui todos os atributos de FUNCIONÁRIO da Figura 15.2(a) exceto Numero_departamento). (b) A

relação FUNCIONARIO_2 (inclui o atributo Numero.departamento com valores NULL), (c) A relação FUNCIONARIO_3 (inclui o atributo Numero.departamento, mas não as tuplas

para as quais Numero.departamento tem valores NULL).

para o conjunto dc dependências funcionais F. Como costuma haver muitas coberturas mínimas correspondentes a F, conforme ilustramos no Exemplo 2 do Algoritmo 15.4, o algoritmo pode dar origem a diferentes projetos, dependendo da cobertura mínima em particular utilizada. Alguns desses projetos podem nào ser desejáveis. O algoritmo de decomposição para alcançar a FNBC (Algoritmo 15.5) depende da ordem em que as dependências funcionais são fornecidas ao algoritmo para verificar a violação da FNBC. Novamente, c possível que surjam muitos projetos diferentes. Alguns dos projetos podem ser preferidos, ao passo que outros podem ser indesejáveis. Nem sempre é possível encontrar uma decomposição para esquemas de relação que preserve dependências e permita que cada esquema de relação na decomposição

475

476

Sistemas de banco de dados

esteja na FNBC (em vez de na 3FN, como no Algoritmo 15.4). Podemos verificar os esquemas de relação 3FN na decomposição individualmente para ver se cada um satisfaz a FNBC. Se algum esquema de relação Rt não estiver na FNBC, pode­ mos decidir decompô-la ainda mais e deixá-la como se encontra na 3FN (com algumas possíveis anomalias de atualização). Mostramos, usando a abordagem de projeto de baixo para cima, que diferentes coberturas mínimas nos casos X e Y do Exemplo 2, sob o Algoritmo 15.4, produziam diferentes conjuntos de relações com base na cobertura mínima. O projeto X produziu o projeto 3FN como a relação LOTES1A (ldentificador_propriedade, Nome_cidade, Numerojote, Area), que está na 3FN, mas não na FNBC. Como alternativa, o projeto Y produziu três relações: S( (ldentificador_propriedade. Area, Numerojote), S, (Numerojote, Nome_cidade, ldentificador_propriedade) e S3 (Area, Nome_cidade). Se testarmos cada uma dessas três relações, descobriremos que estão na FNBC. Também vimos anteriormente que, se aplicarmos o Algoritmo 15.5 a LOTES1Y para decompô-la em relações FNBC, o projeto resultante contém apenas S| e S3 como projeto FNBC. Resumindo, os projetos acima dos casos (chamados Caso X e Caso Y), controlados por diferentes coberturas mínimas para o mesmo esquema universal, ilustram amplamente que o resultado serão projetos alternativos pela aplicação dos algoritmos de projeto de baixo para cima, que apresentamos na Seção 15.3. A Tabela 15.1 resume as propriedades dos algoritmos discutidos até aqui neste capítulo.

Tabela 15.1 Resumo dos algoritmos discutidos neste capítulo. Algoritmo

15.1

15.2

Entrada

Saída

Um atributo ou um con­

Um conjunto de atributos

Determinar todos os atributos

junto de atributos Xe

no fechamento de X com

que podem ser funáonal mente

um conjunto de DFs F

relação a F

determinados com base em X

Um conjunto de depen­

A cobertura mínima de

dências funcionais F

dependências funcionais

Esquema de relação R 15.2a

com um conjunto de de­

Chave Ch de R

pendências funcionais F

15.3

Uma decomposição D

Resultado booleano: sim

de R e um conjunto F de

ou não para a propriedade

dependências funcionais

de junção não aditiva

Uma relação R e um

15.4

conjunto de dependên­ cias funcionais F Uma relação R e um

15.5

conjunto de dependên­ cias funcionais F

Propriedades/Finalidade

Determinar a cobertura mínima de um conjunto de dependên­ cias F

Comentários

0 fechamento de uma chave é a relação inteira Pode haver múltiplas cober­

turas mínimas — depende

da ordem de seleção das

dependências funcionais

Encontrar uma chave Ch (que

A relação R inteira é sempre

seja um subconjunto de R)

uma superchave padrão

Testar para a decomposição da

junção não aditiva

Veja uma NJB de teste mais

simples na Seção 14.5 para

decomposições binárias

Decomposição de junção

Pode não alcançar a FNBC,

não aditiva e preservação de

mas alcança todas as pro­

dependência

priedades desejáveis e a 3FN

Um conjunto de relações

Decomposição por junção não

Não há garantia de preser­

na FNBC

aditiva

vação de dependência

Um conjunto de relações

na3FN

Uma relação R e um

15.6

conjunto de depen­

Um conjunto de relações

Decomposição por junção não

Não há garantia de preser­

dências funcionais e

na4FN

aditiva

vação de dependência

multivaloradas

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

15.5 Discussão adicional sobre dependências multivaloradas e 4FN Apresentamos e definimos o conceito de dependências multivaloradas c o usamos para definir a quarta forma normal na Seçào 14.6. Agora, retornamos às DMVs para completar nosso tratamento, indicando as regras de inferência sobre elas.

15.5.1 Regras de inferência para dependências funcionais e multivaloradas Assim como as dependências funcionais (DFs), as regras de inferência para dependências multivaloradas (DMVs) também foram desenvolvidas. Porém,é melhor desenvolver uma estrutura unificada que inclua tanto DFs quanto DMVs, de modo que os dois tipos de restrições possam ser considerados juntos. As regras de infe­ rência R11 a RI8 a seguir formam um conjunto confiável e completo para deduzir dependências funcionais e multivaloradas de determinado conjunto de dependên­ cias. Suponha que todos os atributos estejam incluídos em um esquema de relaçào universal R = {A,, A2,..., AJ e que X, Y, Z e W sejam subconjuntos de R. RI1 (regra reflexiva para DFs): se X D Y, então X —* Y. RI2 (regra de aumento para DFs): {X —♦ Y) l= XZ —* YZ. RI3 (regra transitiva para DFs): {X —* Y, Y —* Z) l= X —* Z. RI4 (regra de complemenração para DMVs): (X —*♦ Y| l= (X —*♦ (R - (X U Y))|. RI5 (regra de aumento para DMVs): se X —>-> Ye W D Z, então \VX -*> YZ. RI6 (regra transitiva para DMVs): {X —>-> Y, Y >>Z} |= X —►> (X - Y). RI7 (regra de replicação para DF para DMV): {X —> Y} l= X —*-» Y. RI8 (regra de coalescência para DFs e DMVs): se X —*-Y e houver Wcom as propriedades de que (a) WA Y é vazio, (b) W —> Z e (c) Y D Z, entào X —> Z. De RI1 até RI3 são as regras de inferência de Armstrong apenas para DFs. De RI4 até RI6 são as regras de inferência pertencentes somente às DMVs. As RI7 e RI8 rela­ cionam DFs e DMVs. Em particular, a RI7 diz que uma dependência funcional é um caso especial dc uma dependência multivalorada; ou seja, cada DF também é uma DMV', pois satisfaz a definição formal de uma DMV. No entanto, essa equivalência tem um problema: uma DF X —* Y é uma DMV X —*♦ Y com a restrição adicional implícita de que no máximo um valor de Yé associado a cada valor de X.8 Dado um conjunto F de dependências funcionais e multivaloradas, especificadas em R = |Ap A2,AJ, podemos usar de R11 a RI8 para deduzir o conjunto (completo) de todas as dependências (funcionais e multivaloradas) F * que serão mantidas em cada estado de relação r de R que satisfaça F. Novamente chamamos de F * o fechamento de F.

15.5.2 Revisão da quarta forma normal Reproduzimos a definição da quarta forma normal (4FN) da Seção 14.6:

Definição. Um esquema de relação R está na 4FN com relação a um conjunto de dependências F (que inclui dependências funcionais e multivaloradas) se, para cada dependência multivalorada nào trivial X —►* Y em F , X em F * é uma super­ * chave para R. Para ilustrar a importância da 4FN, a Figura 15.4(a) mostra a relação FUNCIONÁRIO da Figura 14.15 com um funcionário adicional,‘Braga’, que tem três dependentes

s Ou seja, o conjunto de valores de Y determinados por um valor de X é restrito a ser um conjunto sin­ gular, com apenas um valor. Logo, na prática, nunca vemos uma DF como uma DMV.

477

478

Sistemas de banco de dados

‘Joana’ e ‘Roberto’) e trabalha em quatro projetos diferentes (‘W’, ‘X’, ‘Y’ e ‘Z’). Existem 16 tuplas em FUNCIONÁRIO na Figura 15.4(a). Se decompusermos FUNCIONÁRIO em FUNCIONARIO.PROJETOS e FUNCIONARIO.DEPENDENTES, como mostra a Figura 15.4(b), precisamos armazenar um total de apenas 11 tuplas nas duas relações. Nào apenas a decomposição economizaria armazenamento, mas as anomalias de atualização associadas a dependências multivaloradas também seriam evitadas. Por exemplo, sc ‘Braga’ começar a trabalhar em um novo projeto adicional ‘P’, temos de inserir três tuplas em FUNCIONÁRIO — uma para cada dependente. Sc nos esquecermos de inserir qualquer um deles, a relação viola a DMV e torna-se incoe­ rente porque implica incorretamente um relacionamento entre projeto e dependente. Se a relação tiver DMVs não triviais, as operações de inserção, exclusão e atua­ lização cm tuplas isoladas podem fazer que as tuplas adicionais sejam modificadas além daquela em questão. Se a atualização for tratada incorretamente, o significado da relação pode mudar. No entanto, após a normalização para a 4FN, essas anoma­ lias de atualização desaparecem. Por exemplo, para acrescentar a informação de que ‘Braga’ será atribuído ao projeto‘P’, somente uma única tupla precisa ser inserida na relação 4FN FUNCIONARIO_PROJETOS.

(a)

FUNCIONÁRIO Nome funcionário

(b)

N°me projeto

Nome dependente

Silva

X

João

Silva

Y

Ana

Silva

X

Ana

Silva

Y

João

Braga

W

Jim

Braga

X

Jim

Braga

Y

Jim

Braga

Z

Jim

Braga

w

Joana

Braga

X

Joana

Braga

Y

Joana

Braga

Z

Joana

Braga

w

Roberto

Braga

X

Roberto

Braga

Y

Roberto

Braga

Z

Roberto

FUNCIONARIO_DEPENDENTES

FUNCIONARIO_PROJETOS Nome funcionário

Nome projeto

Nome_funcionario

Silva

X

Silva

Ana

Silva

Y

Silva

João

Braga

W

Braga

Jim

Braga

X

Braga

Joana

Braga

Y

Braga

Roberto

Braga

Z

Nome_dependente

Figura 15.4 Decompondo um estado de relação de FUNCIONÁRIO que não está na 4FN. (a) Relação FUNCIONÁRIO com tuplas adicionais, (b) Duas relações 4FN correspondentes

FUNCIONARIO_PROJETOS e FUNCIONARIO.DEPENDENTES.

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

A relação FUNCIONÁRIO da Figura 14.15(a) não está na 4FN porque representa dois relacionamentos 1:N independentes — um entre funcionários e os projetos em que trabalham e um entre funcionários e seus dependentes. Às vezes, temos um relacionamento entre três entidades, que é um relacionamento ternário legítimo, e não uma combinação de dois relacionamentos binários entre três entidades par­ ticipantes, como a relação FORNECE mostrada na Figura 14.15(c). (Por enquanto, considere apenas as tuplas na Figura 14.5(c) acima da linha tracejada.) Nesse caso, uma tupla representa um fornecedor que entrega uma peça específica a um projeto em particular, de modo que nào existem DMVs não triviais. Logo, a relação de todas as chaves FORNECE já está na 4FN e não deve ser decomposta.

15.5.3 Decomposição de junção não aditiva para relações 4FN Sempre que decompomos um esquema de relação R em Rj = (X U Y) e R2 = (R - Y) com base em uma DMV X —>♦ Y que se mantém em R, a decomposição tem a propriedade de junção não aditiva. Pode-se mostrar que essa é uma condição necessária e suficiente para decompor um esquema em dois esquemas que têm a propriedade de junção não aditiva, como dado pela Propriedade NJB', que é mais uma generalização da Propriedade NJB dada anteriormente na Seção 14.5.1. A propriedade NJB tratava apenas de DFs, ao passo que a NJB' trata de DFs e DMVs (lembre-se de que uma DF também é uma DMV).

Propriedade NJB'. Os esquemas de relação R, e R2 formam uma decomposição de junção não aditiva de R em relação a um conjunto F de dependências funcionais e multivaloradas se, e somente se, (R, PR.)-(R,-R,) ou, por simetria, se, e somente se,

(R, AR,)-(R2 - R,) Podemos usar uma pequena modificação do Algoritmo 15.5 para desenvolver o Algoritmo 15.7, que cria uma decomposição de junção não aditiva para esquemas de relação que estão na 4FN (em vez de na FNBC). Assim como no Algoritmo 15.5, o Algoritmo 15.7 não necessariamente produz uma decomposição que preserva DFs.

Algoritmo 15.7. Decomposição relacionai em relações 4FN com propriedade de junção não aditiva Entrada: uma relação universal R e um conjunto de dependências funcionais e multivaloradas F

1. Defina D:= { R };

2. Enquanto houver um esquema de relação Q em D que não esteja na 4FN, ( escolha um esquema de relação Q em D que não está na 4FN; ache uma DMV não trivial X —*- Y em Q que viola a 4FN; substitua Q em D por dois esquemas de relação (Q - Y) e (X U Y); );

15.6 Outras dependências e formas normais 15.6.1 Dependências de junção e a quinta forma normal Já apresentamos outro tipo de dependência, chamada dependência de junção (DJ), na Seção 14.7. Ela surge quando uma relação pode ser decomposta em um conjunto de relações projetadas, que podem ser reunidas de volta para gerar a relação origi­ nal. Depois dc estabelecer a DJ, definimos a quinta forma normal com base nela, na

479

480

Sistemas de banco de dados

Seção 14.7. A quinta forma normal também é conhecida como a forma normal de projeçào-junçào, ou FNPJ (Fagin, 1979). Um problema prático com esta e algumas outras dependências (e formas normais relacionadas, como a FNDC, definida na Seção 15.6.4), é que elas são difíceis de serem descobertas. Além disso, não existem conjuntos de regras de inferência legítimas e completas para raciocinar sobre elas. Na parte restante desta seção, apresentamos alguns outros tipos dc dependências que foram identificadas. Entre elas, as dependências de inclu­ são e as baseadas em funções aritméticas e semelhantes são usadas com frequência.

15.6.2 Dependências de inclusão As dependências de inclusão foram definidas a fim de formalizar dois tipos de restrições entre relações: ■ A restrição de chave estrangeira (ou integridade referencial) não pode ser espe­ cificada como uma dependência funcional ou multivalorada, pois se relaciona aos atributos entre as relações. ■ A restrição entre duas relações que representam um relacionamento de classe/ subclasse (ver capítulos 4 e 9) também não tem definição formal nos termos das dependências funcionais, multivaloradas e de junção.

Definição. Uma dependência de inclusão R.X < S.Y entre dois conjuntos de atri­ butos — X do esquema de relação R e Y do esquema de relação 5 — especifica a restrição dc que, a qualquer momento específico em que r for um estado de relação de R e $ um estado dc relação dc 5, devemos ter

nx(r(R)) Ç ny R, pois faz cada registro começar em um local conhecido no bloco, simplificando o processamento do registro. Para registros de tamanho variável, pode-se usar uma organização espalhada ou nào espalhada. Sc o registro médio for grande, é vantajoso usar o espalhamento para reduzir o espaço perdido em cada bloco. A Figura 16.6 ilustra a organização espalhada versus a não espalhada. Para registros de tamanho variável que usam a organização espalhada, cada bloco pode armazenar um número diferente de registros. Nesse caso, o fator dc blocagem bfr representa o número médio dc registros por bloco para o arquivo. Podemos usar bfr para calcular o número de blocos b necessários para um arquivo de r registros:

b = [(r/bfr)\ blocos em que o I (x)

(função ceiling) arredonda para cima o valor de x até o próximo

inteiro. 10 Outros esquemas também são possíveis para representar registros de tamanho variável.

509

510

Sistemas de banco de dados

Figura 16.6 Tipos de

(a)

Bloco /

Registro 1

Registro 3~[

Registro 2

organização de registro, (a)

Não espalhada, (b) Espalhada.

Bloco / +1 (b)

Bloco i

Registro 5

Registro 4

Registro 1

| Registro 2

Registro 6

| RegistroT Registro 4



Bloco i + 1 | Registro 4 (restante) | Registro 5| Registro 6

P —

Registro 7

P

16.4.4 Alocando blocos de arquivo no disco Existem várias técnicas-padrão para alocar os blocos de um arquivo no disco. Na alocação contígua, os blocos de arquivo são alocados a blocos de disco consecuti­ vos. Isso torna a leitura do arquivo inteiro muito rápida usando o buffering duplo, mas dificulta a expansão do arquivo. Na alocação ligada, cada bloco de arquivo contem um ponteiro para o próximo bloco. Isso facilita a expansão do arquivo, mas torna sua leitura mais lenta. Uma combinação dos dois aloca clusters de blocos de disco consecutivos, e os clusters são ligados. Os clusters às vezes são chamados de segmentos ou extensões de arquivo. Outra possibilidade é usar a alocação indexada, em que um ou mais blocos de índice contém ponteiros para os blocos de arquivo reais. Também é comum usar combinações dessas técnicas.

16.4.5 Cabeçalhos de arquivo Um cabeçalho de arquivo ou descritor de arquivo contém informações sobre um arquivo, que são exigidas pelos programas do sistema que acessam os registros do arquivo. O cabeçalho inclui informações para determinar os endereços de disco dos blocos de arquivo, bem como para registrar descrições de formato, que podem incluir tamanhos de campo e a ordem dos campos em um registro, para registros não espalhados de tamanho fixo, e códigos de ripo de campo, caracteres separadores e códigos de tipo dc registro, para registros dc tamanho variável. Para procurar um registro no disco, um ou mais blocos sào copiados para os buffers da memória principal. Os programas então procuram o registro ou registros desejados nos buffers, usando a informação no cabeçalho de arquivo. Se o ende­ reço do bloco que contém o registro desejado não for conhecido, os programas de pesquisa devem realizar uma pesquisa linear pelos blocos de arquivo. Cada bloco é copiado para um buffer c pesquisado até que o registro seja localizado e todos os blocos tenham sido pesquisados sem sucesso. Isso pode ser muito demorado para um arquivo grande. O objetivo de uma boa organização de arquivo é evitar pesquisa linear ou preencher a varredura do arquivo e localizar o bloco que contem um registro desejado com um número mínimo de transferências de bloco.

16.5 Operações em arquivos Operações em arquivos costumam ser agrupadas em operações de recuperação e operações de atualização. O primeiro grupo não muda quaisquer dados no arquivo, apenas localiza certos registros de modo que seus valores de campo possam ser examinados e processados. O segundo muda o arquivo pela inserção ou exclusão dc registros, ou pela modificação dos valores de campo. De qualquer forma, podemos ter de selecionar um ou mais registros para recuperação, exclusão ou modificação com base em uma condição de seleção (ou condição de filtragem), que especifica critérios que o registro ou registros desejado(s) deve(m) satisfazer. Considere um arquivo FUNCIONÁRIO com os campos Nome, Cpf, Salario, Codigo_cargo e Departamento. Uma condição de seleção simples pode envolver

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

uma comparação de igualdade em algum valor de campo — por exemplo, (Cpf = ‘12345678966’) ou (Departamento = ‘Pesquisa’). Condições mais complexas podem envolver outros tipos de operadores de comparação, como > ou £; um exemplo é (Salario £30000). O caso geral é ter uma expressão booleana qualquer nos campos do arquivo como condição de seleção. As operações de pesquisa em arquivos geralmente são baseadas em condições de seleção simples. Uma condição complexa deve scr decomposta pelo SGBD (ou pelo programador) para extrair uma condição simples que pode ser usada para localizar os registros no disco. Cada registro localizado é então verificado para determinar se satisfaz a condição de seleção inteira. Por exemplo, podemos extrair a condição simples (Departamento = ‘Pesquisa’) da condição complexa ((Salario £ 30000) AND (Departamento = ‘Pesquisa’)); cada registro satisfazendo (Departamento = ‘Pesquisa’) é localizado e depois testado para ver se também satisfaz (Salario £ 30000). Quando vários registros de arquivo satisfazem uma condição de pesquisa, o primeiro registro — em relação à sequência física de registros de arquivo — é inicialmente localizado e designado como o registro atual. Operações de busca subsequentes começam desse registro e localizam o próximo registro no arquivo que satisfaz a condição. As operações reais para localizar e acessar registros de arquivo variam de um sistema para outro. Na lista a seguir, apresentamos um conjunto de operações repre­ sentativas. Normalmente, programas de alto nível, como programas de software de SGBD, acessam registros usando esses comandos, de modo que às vezes nos referimos a variáveis dc programa nas descrições a seguir: ■ Open. Prepara o arquivo para leitura ou gravação. Aloca buffers apropriados (em geral, pelo menos dois) para manter blocos de arquivo do disco e recupera o cabeçalho do arquivo. Define o ponteiro de arquivo para o início do arquivo. ■ Reset. Define o ponteiro do arquivo aberto para o início do arquivo. ■ Find (ou Locate). Procura o primeiro registro que satisfaça uma condição de pesquisa. Transfere o bloco que contém esse registro para o buffer da memória principal (se ainda não estiver lá). O ponteiro de arquivo aponta para o registro no buffer e este se torna o registro atual. Às vezes, diferentes verbos são usados para indicar se o registro localizado deve ser lido ou atualizado.

■ Read (ou Get). Copia o registro atual do buffer para uma variável de programa no programa do usuário. Este comando também pode avançar o ponteiro do registro atual para o próximo registro no arquivo, que pode precisar ler o pró­ ximo bloco de arquivo do disco. ■ FindNext. Procura o próximo registro no arquivo que satisfaz a condição de pesquisa. Transfere o bloco que contém esse registro para um buffer da memória principal (se ainda não estiver lá). O registro está localizado no buffer e torna-se o registro atual. Várias formas de FindNext (por exemplo, encontrar próximo regis­ tro dentro de um registro pai atual, encontrar próximo registro de determinado tipo ou encontrar próximo registro em que uma condição complexa é atendida) estão disponíveis em SGBDs legados com base nos modelos hierárquico e de rede. ■ Delete. Exclui o registro atual e (no fim) atualiza o arquivo no disco para refletir a exclusão. ■ .Modify. Modifica alguns valores de campo para o registro atual e (no fim) atualiza o arquivo no disco para refletir a modificação. ■ Insert. Insere um novo registro no arquivo ao localizar o bloco em que o registro deve ser inserido, transferindo esse bloco para um buffer da memória principal (se ainda não estiver lá), gravando o registro no buffer e (no fim) gravando o buffer em disco para refletir a inserção.

511

512

Sistemas de banco de dados

■ Close. Completa o acesso ao arquivo liberando os buffers e realizando quaisquer outras operações de fechamento necessárias.

Estas (exceto por Open e Close) são chamadas operações de um registro por vez, pois cada uma se aplica a um único registro. É possível resumir as operações Find, FindNext e Read cm uma única operação. Scan, cuja descrição c a seguinte: ■ Scan. Se o arquivo já tiver sido aberto ou reiniciado. Scan retoma o primeiro registro; caso contrário, retorna o próximo registro. Se uma condição for especi­ ficada com a operação, o registro retomado é o primeiro ou o próximo registro que satisfaz a condição.

Em sistemas de banco de dados, operações adicionais de nível mais alto, de um con­ junto de cada vez, podem ser aplicadas a um arquivo. Alguns exemplos são os seguintes: ■ FindAll. Localiza todos os registros no arquivo que satisfazem uma condição dc pesquisa. ■ Find (ou Locate) n. Procura o primeiro registro que satisfaz uma condição de pesquisa e depois continua a localizar os próximos w - 1 registros que satisfazem a mesma condição. Transfere os blocos que contêm os n registros para o buffer da memória principal (se ainda não estiverem lá). ■ FindOrdcrcd. Recupera todos os registros no arquivo em alguma ordem especificada. ■ Reorganize. Inicia o processo de reorganização. Conforme veremos, algumas organizações dc arquivo exigem reorganização periódica. Um exemplo é reordenar os registros do arquivo classificando-os em um campo especificado.

Neste ponto, vale a pena notar a diferença entre os termos organização de arquivo e método de acesso. Uma organização de arquivo refere-se à organização dos dados dc um arquivo em registros, blocos e estruturas de acesso; isso inclui o modo como registros e blocos são colocados no meio de armazenamento e interli­ gados. Um método de acesso, por sua vez, oferece um grupo de operações — como as listadas anreriormente — que podem ser aplicadas a um arquivo. Em geral, é possível aplicar vários métodos de acesso a um arquivo organizado com uma certa organização. Alguns métodos de acesso, porém, só podem ser aplicados a arquivos organizados de certas maneiras. Por exemplo, não podemos aplicar um método de acesso indexado a um arquivo sem um índice (ver Capítulo 17). Normalmente, esperamos usar algumas condições de pesquisa mais do que outras. Certos arquivos podem ser estáticos, significando que operações de atualização raramente são realizadas; outros arquivos, mais dinâmicos, podem mudar com frequência, de modo que as operações de atualização são constantemente aplicadas a eles. Se um arquivo não for atualizável pelo usuário final, ele é considerado um arquivo somente leitura. A maioria dos data warehouses (ver Capítulo 29) contém predominantemenre arquivos somente leitura. Uma organização de arquivo bem-sucedida deve realizar, do modo mais eficiente possível, as operações que esperamos aplicar frequentemente ao arquivo. Por exemplo, considere o arquivo FUNCIONÁRIO, mostrado na Figura 16.5(a), que armazena os registros para os funcionários atuais em uma empresa. Esperamos inserir registros (quando os funcionários são contratados), excluir registros (quando os funcionários saem da empresa) e modificar registros (por exemplo, quando o salário ou cargo de um funcionário é alterado). A exclusão ou modificação de um registro requer uma condição de seleção para identificar um registro em particular ou um conjunto de registros. A leitura de um ou mais registros também requer uma condição de seleção. Se os usuários esperam principalmente aplicar uma condição de pesquisa com base no Cpf, o projetista precisa escolher uma organização de arquivo que facilite a

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

localização de um registro, dado seu valor de Cpf. Isso pode envolver a ordenação física dos registros pelo valor do Cpf ou a definição de um índice sobre o número do Cpf (ver Capítulo 17). Suponha que uma segunda aplicação utilize o arquivo para gerar contracheques de funcionários e exija que os contracheques sejam agrupados por departamento. Para essa aplicação, é melhor ordenar os registros de funcioná­ rios por departamento e depois por nome dentro de cada departamento. O agrupa­ mento de registros em blocos e a organização dc blocos em cilindros agora seriam diferentes. Porém, esse arranjo entra em conflito com a ordenação dos registros por valores de Cpf. Se as duas aplicações são importantes, o projetista deve escolher uma organização que permita que as duas operações sejam realizadas de modo eficiente. Infelizmente, em muitos casos, uma única organização não permite que todas as operações necessárias sobre um arquivo sejam implementadas de maneira eficiente. Como um arquivo só pode ser armazenado uma vez, usando uma organização em particular, os DBAs geralmente precisam fazer uma difícil escolha de projeto sobre a organização do arquivo. Eles fazem isso escolhendo um meio-termo que leve em conta a importância esperada e a mistura de operações de leitura e atualização. Nas próximas seções e no Capítulo 17, discutiremos métodos para organizar registros de um arquivo no disco. Várias técnicas gerais, como ordenação, hashing e indexação, são usadas para criar métodos dc acesso. Além disso, diversas técnicas gerais para lidar com inserções e exclusões funcionam com muitas organizações de arquivo.

16.6 Arquivos de registros desordenados (arquivos de heap) Neste tipo de organização mais simples e mais básico, os registros são arquivados na ordem cm que são inseridos, dc modo que novos registros são inseridos ao final do arquivo. Essa organização é chamada arquivo de heap ou pilha.11 Normalmente ela é usada com caminhos de acesso adicionais, como os índices secundários dis­ cutidos no Capítulo 17. Ela também é usada para coletar e armazenar registros de dados para uso futuro. A inserção dc um novo registro é muito eficiente. O último bloco de disco do arquivo é copiado para um buffer, o novo registro é acrescentado c o bloco é então regravado de volta no disco. O endereço do último bloco de arquivo é mantido no cabeçalho do arquivo. No entanto, procurar um registro usando qualquer condição de pesquisa envolve uma pesquisa linear pelo bloco de arquivo por bloco — um procedimento dispendioso. Sc apenas um registro satisfizer a condição dc pesquisa, então, na média, um programa lerá a memória e pesquisará metade dos blocos de arquivo antes de encontrar o registro. Para um arquivo de b blocos, isso exige pes­ quisar (b/2) blocos, em média. Se nenhum registro ou vários registros satisfizerem a condição de pesquisa, o programa deve ler e pesquisar todos os b blocos no arquivo. Para excluir um registro, um programa deve primeiro encontrar seu bloco, copiá-lo para um buffet; excluir o registro do buffer e, finalmente, regravar o bloco de volta ao disco. Isso deixa um espaço livre no bloco de disco. exclusão de um grande número de registros dessa maneira resulta em espaço de armazenamento desperdiçado. Outra técnica usada para exclusão de registro é ter um byte ou bit extra, chamado marcador dc exclusão, armazenado em cada registro. Um registro é excluído ao definir o marcador de exclusão com determinado valor. Um valor diferente para o marcador indica um registro válido (não excluído). Os programas de pesquisa consideram apenas registros válidos em um bloco quando realizam sua

11 As vezes, essa organização é chamada de arquivo sequencial.

513

514

Sistemas de banco de dados

busca. Essas duas técnicas de exclusão exigem reorganização periódica do arquivo para retomar o espaço nào usado dos registros excluídos. Durante a reorganiza­ ção, os blocos de arquivo são acessados de maneira consecutiva e os registros são compactados pela remoção de registros excluídos. Depois dessa reorganização, os blocos são preenchidos até a capacidade mais uma vez. Outra possibilidade é usar o espaço dos registros excluídos ao inserir novos registros, embora isso exija uma manutenção extra para se manter informado sobre os locais vazios. Podemos usar a organização espalhada ou não espalhada para um arquivo desordenado, e ela pode ser utilizada com registros de tamanho fixo ou variável. A modificação de um registro de tamanho variável pode exigir a exclusão do registro antigo e a inserção de um registro modificado, pois este pode não se encaixar em seu antigo espaço no disco. Para ler todos os registros na ordem dos valores de algum campo, criamos uma cópia classificada do arquivo. A classificação é uma operação cara para um arquivo de disco grande, e técnicas especiais para classificação externa são utilizadas (ver Capítulo 18). Para um arquivo de registros de tamanho fixo desordenados usando blocos nào espalhados e alocação contígua * é simples acessar qualquer registro por sua posição no arquivo. Se os registros dc arquivo forem numerados com 0, 1,2,..., r - 1 c os registros em cada bloco forem numerados com 0,1,..., bfr - 1, em que bfr é o fator de blocagem, então o f-ésimo registro do arquivo está localizado no bloco L(í/b/r)J

e é o (/ mod bfr) * registro nesse bloco. Tal arquivo costuma ser chamado dc arquivo relativo ou direto, pois os registros podem ser facilmente acessados por suas posições relativas. O acesso a um registro por sua posição não ajuda a localizá-lo com base em uma condição de busca; contudo, facilita a construção de caminhos de acesso no arquivo, como os índices discutidos no Capítulo 17.

16.7 Arquivos de registros ordenados (arquivos classificados) Podemos ordenar fisicamente os registros de um arquivo no disco com base nos valores de um de seus campos — chamado de campo dc ordenação. Isso leva a um arquivo ordenado ou sequencial.’2 Sc o campo de ordenação também for um campo-chave do arquivo — um campo com garantias de ter um valor exclusivo em cada registro —, então o campo é chamado de chave de ordenação para o arquivo. A Figura 16.7 mostra um arquivo ordenado com Nome como campo-chave de ordenação (supondo que os funcionários tenham nomes distintos). Os registros ordenados têm algumas vantagens em relação aos arquivos desorde­ nados. Primeiro, a leitura dos registros na ordem dos valores da chave de ordenação toma-se extremamente eficiente porque nenhuma classificação é necessária. A condição de pesquisa pode ser do tipo , e < no campo de ordenação é muito eficiente, pois a ordenação física dos registros significa que todos os registros que satisfazem a condição são contíguos no arquivo. Por exemplo, com relação à Figura 16.7, se o critério de pesquisa for (Nome > ‘G’) — em que > significa alfabeticamente antes de —-, os registros que satisfazem o critério de pesquisa são os do início do arquivo até o registro antes daquele que tem um valor Nome começando com a letra ‘G’. A ordenação não oferece quaisquer vantagens para o acesso aleatório ou orde­ nado dos registros com base nos valores dos outros campos não ordenados do arquivo. Nesses casos, realizamos uma pesquisa linear para acesso aleatório. Para acessar os registros em ordem baseados em um campo não ordenado, é necessário criar outra cópia ordenada — em uma ordem diferente — do arquivo. A inserção e a exclusão dc registros são operações dispendiosas para um arquivo ordenado, pois os registros devem permanecer fisicamente ordenados. Para inserir um registro, temos de encontrar sua posição correta no arquivo, com base no valor de seu campo de ordenação, e depois criar espaço no arquivo para inserir o registro nessa posição. Para um arquivo grande, isso pode ser muito demorado porque, na média, metade dos registros no arquivo precisa ser movida para criar espaço para o novo registro. Isso significa que metade dos blocos de arquivo deve ser lida e regravada depois que os registros forem movidos entre eles. Para exclusão de registro, o problema é menos grave se forem usados marcadores de exclusão e reorganização periódica. Uma opção para tornar a inserção mais eficiente é manter algum espaço não usado em cada bloco para novos registros. Porém, quando esse espaço é totalmente utilizado, o problema original reaparece. Outro método frequentemente empregado é criar um arquivo desordenado temporário, chamado arquivo de overflow ou tran­ sação. Com essa técnica, o arquivo ordenado real é chamado de arquivo principal ou mestre. Novos registros são inseridos no final do arquivo de overflow, em vez de em sua posição correra no arquivo principal. De tempos em tempos, o arquivo de

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

overflow é classificado e mesclado ao arquivo mestre durante a reorganização do arquivo. A inserção torna-se muito eficiente, mas ao custo de maior complexidade no algoritmo de pesquisa. Uma opção é manter o valor mais alto da chave em cada bloco em um campo separado, após levar em consideração as chaves que foram retiradas desse bloco. Caso contrário, o arquivo de overflow precisa ser pesquisado usando uma pesquisa linear se, após a pesquisa binária, o registro não for encontrado no arquivo principal. Para aplicações que nào exigem a informação mais atualizada, os registros de overflow podem ser ignorados durante uma pesquisa. A modificação do valor de um campo de registro depende de dois fatores: a con­ dição de pesquisa para localizar o registro e o campo a ser modificado. Se a condição de pesquisa envolver o campo da chave de ordenação, podemos localizar o registro com uma pesquisa binária; caso contrário, temos de realizar uma pesquisa linear. Um campo não ordenado pode ser modificado ao alterar o registro e regravá-lo no mesmo local físico no disco — considerando registros de tamanho fixo. A modificação do campo de ordenação significa que o registro pode alterar sua posição no arquivo. Isso requer a exclusão do registro antigo, seguida pela inserção do registro modificado. A leitura dos registros do arquivo na ordem do campo de ordenação é muito eficiente se ignorarmos os registros no overflow, pois os blocos podem ser lidos con­ secutivamente ao usar o buffering duplo. Para incluir os registros no overflow, temos de mesclá-los em suas posições atuais; nesse caso, primeiro podemos reorganizar o arquivo, e depois ler seus blocos na sequência. Para reorganizar o arquivo, classifi­ camos os registros no arquivo de overflow c, depois, os mesclamos com o arquivo mestre. Os registros marcados para exclusão são removidos durante a reorganização. A Tabela 16.3 resume o tempo de acesso médio em acessos de bloco para encon­ trar um registro específico em um arquivo com b blocos. Os arquivos ordenados raramente são usados em aplicações de banco de dados, a menos que um caminho de acesso adicional, chamado índice primário, seja utilizado; isso resulta em um arquivo scqucndal-indcxado. Isso melhora ainda mais o tempo de acesso aleatório ao campo-chave dc ordenação. (Discutiremos índices no Capítulo 17.) Sc o atributo de ordenação não for uma chave, o arquivo é chamado de arquivo agrupado. Tabela 16.3 Tempos de acesso médios para um arquivo de b blocos sob organizações de arquivo básicas.

Média de blocos para acessar um registro específico

Tipo de organização

Método de acesso/pesquisa

Heap (não ordenado)

Varredura sequencial (pesquisa linear)

b/2

Ordenado

Varredura sequencial

b/2

Ordenado

Pesquisa binária

log2 b

16.8 Técnicas de hashing Outro tipo dc organização de arquivo principal é baseado no hashing, que oferece acesso muito rápido aos registros sob certas condições de pesquisa. Essa organização costuma ser chamada dc arquivo dc hash.13 A condição dc pesquisa precisa ser uma condição dc igualdade cm um único campo, chamado campo dc hash. Na maior parte dos casos, o campo de hash também é um campo-chave do arquivo, quando é chamado de chave hash. zV ideia por trás do hashing é oferecer uma função h, cha­ mada função de hash ou função de randomização, que é aplicada ao valor do campo

Um arquivo de hash também c chamado dc arquivo direto.

517

518

Sistemas de banco de dados

de hash de um registro e gera o endereço do bloco de disco em que o registro está armazenado. Uma pesquisa pelo registro no bloco pode ser executada em um buffer da memória principal. Para a maioria dos registros, só precisamos de um acesso de único bloco para recuperar esse registro. O hashing também é utilizado como uma estrutura de pesquisa interna em um programa sempre que um grupo de registros é acessado exclusivamente pelo uso do valor dc um campo. Descrevemos o uso do hashing para arquivos internos na Seção 16.8.1; depois, mostramos como ele é modificado para armazenar arquivos exter­ nos no disco na Seção 16.8.2. Na Seção 16.8.3, discutimos técnicas para estender o hashing a arquivos dinamicamente crescentes.

16.8.1 Hashing interno Para arquivos internos, o hashing normalmentc é implementado como uma tabela de hash por meio do uso de um vetor de registros. Suponha que o intervalo de índice de vetor seja de 0 a M - 1, como mostra a Figura 16.8(a). Então, temos Af slots cujos endereços correspondem aos índices de vetor. Escolhemos uma função de hash que transforma o valor de campo de hash em um inteiro entre 0 e M - 1. Uma função de hash comum é h(K) = K mod M, que retorna o resto de um valor de campo de hash inteiro K após a divisão por Aí; esse valor é então usado para o endereço do registro.

Nome

(a)

Cargo

Cpf

Salario

0

1 2 3

1 M-2

M-y

Campos de dados (b)

Ponteiro de overflow

0

-1

1

M

2

-1

3

-1

4

M+2



Espaço de endereços M+ 1

-1 M+5

-1 M+4



Espaço de overflow

Figura 16.8 Estruturas de

dados de hashing interno.

(a) Vetor de M posições para uso no hashing interno.

(b) Resolução de colisão ao

encadear registros.

M + 0 - 2___________________________________________________________________ M + 0- 1

• ponteiro de nulo = -1 • ponteiro de overflow refere-se à posição do próximo registro na lista encadeada

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

Os valores de campo de hash não inteiros podem ser transformados em inteiros antes que a função mod seja aplicada. Para cadeias de caracteres, os códigos numé­ ricos (ASCII) associados aos caracteres podem ser usados na transformação — por exemplo, ao multiplicar esses valores de código. Para um campo de hash cujo tipo de dado é uma cadeia (string) de 20 caracteres, o Algoritmo 16.2(a) pode ser utilizado para calcular o endereço de hash. Consideramos que a função de código retorna o código numérico de um caractere c que recebemos um valor dc campo de hash K do tipo K: array [1 ..20] of char (em Pascal) ou char K[20] (em C).

Algoritmo 16.2. Dois algoritmos de hashing simples: (a) aplicando a função de hash mod a uma cadeia de caracteres K. (b) Resolução de colisão por endereçamento aberto. (a) temp 1; para / . Isso funciona bem para arqui­ vos com um número relativamente pequeno de registros e um tamanho de registro pequeno. Caso contrário, o fan-out e o número de níveis tornam-se muito grandes para permitir um acesso eficiente. Resumindo, as B-trees oferecem uma estrutura de acesso mulrinível que é uma estrutura de árvore balanceada em que cada nó está cheio pelo menos até a metade. Cada nó em uma B-tree dc ordem p pode ter no máximo p - 1 valores de pesquisa.

17.3.2 B--trees A maioria das implementações dc um índice mulrinível dinâmico utiliza uma variação da estrutura de dados da B-tree chamada B -tree. * Em uma B-tree, cada valor do campo de pesquisa aparece uma vez em algum nível na árvore, com um ponteiro dc dados. Em uma B‘-tree, os ponteiros dc dados são armazenados apenas nos nós folha da árvore; logo, a estrutura dos nós folha difere da estrutura dos nós internos. Os nós folha têm uma entrada para cada valor do campo dc pesquisa, com um ponteiro de dados para o registro (ou para o bloco que contém esse registro), se o campo de pesquisa for um campo de chave. Para um campo de pesquisa não chave, o ponteiro aponta para um bloco que contém ponteiros para os registros do arquivo de dados, criando um nível de indireção extra. Os nós folha da B -tree normalmente são ligados para oferecer acesso ordenado * aos registros sobre o campo de pesquisa. Esses nós folha são semelhantes ao pri­ meiro nível (base) de um índice. Os nós internos da B+-tree correspondem aos outros níveis de um índice mulrinível. Alguns valores de campo de pesquisa dos nós folha são repetidos nos nós internos da B+-tree para guiar a pesquisa. A estrutura dos nós internos dc uma B -trce * dc ordem p [Figura 17.11(a)] é a seguinte: 1. Cada nó interno tem a forma

em que q

( SELECT MAX (Salario) FROM FUNCIONÁRIO WHERE Numero_departamento=5);

Essa consulta recupera os nomes dos funcionários (de qualquer departamento na empresa) que ganham um salário maior que o maior salário no departamento 5. A consulta inclui uma subconsulta aninhada e, portanto, seria decomposta em dois blocos. O bloco mais interno é: (

SELECT MAX (Salario) FROM FUNCIONÁRIO WHERE Numero_departamento=5)

Isso recupera o salário mais alto no departamento 5. O bloco de consulta mais externo é:

SELECT FROM WHERE

Ultimo.nome, Primeiro.nome FUNCIONÁRIO Salario >c

em que c representa o resultado retomado do bloco interno. O bloco interno poderia ser traduzido para a seguinte expressão da álgebra relacionai estendida:

SMAXSa^^N^o.departament^iFUNCIONARIO)) e o bloco externo para a expressão:

,lUltimo_nome Pnmero,-nome^SalanocíFUNCIONARIO)) O otimizador de consulta^ então, escolheria um plano de execução para cada bloco de consulta. Observe que, no exemplo anterior, o bloco interno só precisa ser avaliado uma vez para produzir o salário máximo dos funcionários no departamento 5, que é então utilizado — como a constante c — pelo bloco externo. Chamamos isso de um bloco de subconsulta aninhado (sem correlação com a consulta externa) na Seção 7.1.2. E muito mais difícil otimizar as subconsultas aninhadas correlacio­ nadas mais complexas (ver Seção 7.1.3), em que uma variável de tupla do bloco de consulta externo aparece na cláusula WHERE do bloco de consulta interno. Muitas técnicas são usadas em SGBDs avançados para remover o aninhamento e otimizar as subconsultas aninhadas correlacionadas.

18.1.1. Operadores adicionais de semijunção e antijunção A maioria dos SGBDRs atualmente processa consultas SQL que surgem de vários tipos de aplicações corporativas, incluindo consultas ocasionais, consultas padrão com parâmetros e consultas para geração de relatório. Além disso, as consultas SQL originam-se de aplicações OLAP (on-line analytical processing) sobre data warehouses (discutiremos sobre data warehousing com detalhes no Capítulo 29). Algumas dessas consultas são transformadas em operações que não fazem parte da álgebra relacionai padrão que discutimos no Capítulo 8. Duas operações comumente utilizadas são semijunção e antijunção. Observe que essas duas operações são um tipo de junção. A semijunção geralmente é usada para desaninhar subconsultas EXISTS, IN e ANY.4 Aqui, representamos a semijunção pela seguinte sintaxe não

4 Em alguns casos em que linhas duplicadas não são relevantes, a junção interna também pode ser usada para desaninhar subconsultas EXISTS e ANY.

Capitulo 18

Estratégias para processamento de consulta

padronizada: T1.X 5 = T2.Y, em que TI é a tabela da esquerda e T2 é a tabela da direita da semijunçào. A semântica da semijunçào é a seguinte: uma linha dc TI é retornada assim queTl.X encontrar uma combinação com qualquer valor deT2.Y sem procurar outras combinações. Isso é o oposto de localizar todas as combinações possíveis na junção interna. Considere uma versão ligeiramente modificada do esquema da Figura 5.5, como a seguir: FUNCIONÁRIO (Cpf, Data.nascimento, Endereço, Sexo, Salario, Numero.departamento) DEPARTAMENTO ( Numero.departamento, Nome.departamento, Cpf.gerente, Cep)

em que um departamento está localizado cm um código postal (Cep) específico. Vamos considerar a seguinte consulta:

Q(SJ): SELECT COUNT(-) FROM DEPARTAMENTO D WHERE D.Numero.departamento IN ( SELECT FROM WHERE

F.Numero.departamento FUNCIONÁRIO F F.Salario > 200000)

Aqui, remos uma consulta aninhada que é unida pelo conector IN. Remover a consulta aninhada:

(

SELECT FROM WHERE

F.Numero.departamento FUNCIONÁRIO F F.Salario > 200000)

c chamado dc desaninhar. Isso leva à seguinte consulta com uma operação chamada semijunçào,' que mostramos com uma notação não padronizada “S=” a seguir: SELECT FROM WHERE

COUNT» FUNCIONÁRIO F, DEPARTAMENTO D D.Numero.departamento S= F.Numero.departamento and F.Salario > 200000;

A consulta acima está contando o número de departamentos que possuem funcio­ nários que ganham mais de RS 200.000,00 anualmente. Aqui, a operação é localizar o departamento cujo atributo Numero.departamento corresponde ao(s) valor(es) para o atributo Numero.departamento de FUNCIONÁRIO com esse salário alto. Na álgebra, existem notações alternativas. Uma notação comum pode ser vista na figura a seguir. Semijunçào

Agora, considere outra consulta:

Q (AJ): FROM WHERE

SELECT COUNT *) FUNCIONÁRIO FUNCIONARIO.Numero.departamento NOT IN (SELECT DEPARTAMENTO.Numero.departamento FROM DEPARTAMENTO WHERE Cep = 03033211)

5 Observe que esse operador de semijunçào nào é o mesmo do usado no processamento de consulta distribuída.

597

598

Sistemas de banco de dados

Essa consulta conta o número de funcionários que nào trabalham em departamen­ tos localizados no Cep 03033211. Aqui, a operaçào é localizar as tuplas de funcionário cujo atributo Numero.departamento nào corresponde ao(s) valor(es) para o atributo Numero.departamento em DEPARTAMENTO para o código postal indicado. Só estamos interessados em produzir uma contagem desses funcionários, e realizar apenas uma junção interna das duas tabelas, logicamente, produziría resultados errados. Neste caso, portanto, o operador de antijunção c usado para desaninhar essa consulta. A antijunção é usada para desaninhar subconsultas NOT EXISTS, NOT IN e ALL. Representamos a antijunção por meio da seguinte sintaxe fora do padrão: Tl.x A = T2.y, em que TI é a tabela da esquerda e T2 é a tabela da direita da antijunção. A semântica da antijunção é a seguinte: uma linha de TI é rejeitada assim que T 1.x encontrar uma correspondência com qualquer valor dc T2.y. Uma linha de TI é retornada, somente se Tl.x não corresponder a qualquer valor de T2.y. No resultado de desaninhamento a seguii; mostramos a antijunção anteriormente mencionada com o símbolo fora do padrão “A=” a seguir: SELECT COUNTÍ *) FROM WHERE

FUNCIONÁRIO, DEPARTAMENTO FUNCIONARIO.Numero.departamento A= DEPARTAMENTO.Numero.departamento AND Cep =03033211

Na álgebra, existem notações alternativas. Uma notação comum aparece na figura a seguir.

Antijunção

18.2 Algoritmos para ordenaçao externa A ordenação (sorting) é um dos principais algoritmos utilizados no processamento de consulta. Por exemplo, sempre que uma consulta SQL especifica uma cláusula ORDER BY, o resultado da consulta precisa ser ordenado. A ordenação também é um componente-chave nos algoritmos ordenação-intercalação (sort-tnerge) usados para JOIN e outras operações (como UNION e INTERSECTION), e cm algoritmos dc eliminação dc duplicata para a operação PROJECT (quando uma consulta SQL especifica a opção DISTINCT na cláusula SELECT). Discutiremos um desses algoritmos nesta seção. Observe que a ordenação de determinado arquivo pode ser evitada se um índice apropriado — como um índice primário ou de agrupamento (ver Capítulo 17) — existir no atributo de arquivo desejado para permitir o acesso ordenado aos registros do arquivo. Ordenação externa refere-se a algoritmos de ordenação adequados para grandes arquivos dc registros armazenados no disco que não cabem inteiramente na memó­ ria principal, como a maioria dos arquivos de banco de dados.6 O algoritmo de ordenação externa típico usa uma estratégia merge-sort (ordenação-intercalação), que começa ordenando pequenos subarquivos — chamados pedaços — do arquivo principal e depois mescla os pedaços ordenados, criando subarquivos ordenados maiores, que, por sua vez, são intercalados. O algoritmo merge-sort, como outros

6 Algoritmos de ordenação interna são adequados para ordenação dc estruturas dc dados, como tabe­ las e listas, que podem caber inteiramente na memória principal. Esses algoritmos são descritos com detalhes cm livros dc estruturas dc dados c algoritmos, c incluem técnicas como quick sort, heap sort, bubble sort e muitas outras. Não discutiremos esses algoritmos aqui. Além disso, os SGBDs da memó­ ria principal, como HANA, empregam suas próprias técnicas de ordenação.

Capitulo 18 Estratégias para processamento de consulta

algoritmos de banco de dados, exige espaço de buffer na memória principal, em que a ordenação e a mesclagem reais dos pedaços sào realizadas. O algoritmo básico, esboçado na Figura 18.2, consiste em duas fases: a fase de ordenação e a fase de intercalação. O espaço de buffer na memória principal faz parte do cache de SGBD — uma área na memória principal do computador que é controlada pelo SGBD. O espaço de buffer é dividido em buffers individuais, em que cada buffer tem o mesmo tamanho em bytes que o tamanho dc um bloco de disco. Assim, um buffer pode manter o conteúdo de exatamente um bloco de disco. Na fase de ordenação, os pedaços (ou partes) do arquivo que podem caber no espaço de buffer disponível são lidos para a memória principal, ordenados usando um algoritmo de ordenação interno e gravados de volta para o disco como subarquivos ordenados (ou pedaços) temporários. O tamanho dc cada pedaço e o número de pedaços iniciais (hr) são ditados pelo número de blocos de arquivo {b) e o espaço de buffer disponível (wfi). Por exemplo, se o número de buffers disponíveis da memória principal nR = 5 blocos de disco e o tamanho do arquivo b = 1.024 blocos de disco, então nR = F(b/nB)\ ou 205 pedaços iniciais cada, com tamanho de cinco blocos (exceto o último pedaço, que terá apenas quatro blocos). Logo, após a fase dc ordenação, 205 pedaços ordenados (ou 205 subarquivos ordenados do arquivo original) são armazenados como subarquivos temporários no disco. Na fase de intercalação, os pedaços ordenados são intercalados usando um ou mais passos de intercalação. Cada passo de intercalação pode ter uma ou mais etapas dc intercalação. O grau dc intercalação (, >=, < ou 5 em 0P2 —, use o índice para encontrar o registro que satisfaz a condição dc igualdade correspondente (Numero.departa­ mento = 5); depois recupere todos os registros subsequentes no arquivo (ordenado). Para a condição Numero.departamento < 5, recupere todos os registros anteriores. ■ S5 — Usando um índice dc agrupamento para recuperar vários registros. Se a condição dc seleção envolver uma comparação dc igualdade sobre um atributo não chave com um índice de agrupamento — por exemplo, Numero.departamento = 5 em 0P3 —, use o índice para recuperar todos os registros que satisfazem a condição. ■ S6 — Usando um índice secundário * -trcc) (B cm uma comparação dc igualdade. Este método de pesquisa pode ser utilizado para recuperar um único registro se o campo de índice for uma chave (tiver valores únicos) ou para recuperar múltiplos registros se o campo dc índice não for uma chave. Este tambcm pode ser usado para comparações envolvendo >, >=, < ou 31-12-1957';

A árvore de consulta inicial para C aparece na Figura 19.2(a). A execução dessa árvore primeiro cria um arquivo muito grande contendo o PRODUTO CARTESIANO dos arquivos FUNCIONÁRIO, TRABALHA_EM e PROJETO inteiros. É por isso que a árvore de consulta inicial nunca é executada, mas sim transformada em outra árvore equi­ valente, que é eficiente para executar. Essa consulta em particular só precisa de um registro da relação PROJETO — para o projeto ‘Aquarius' — e apenas os registros de FUNCIONÁRIO para aqueles cuja data de nascimento se dá após‘31-12-1957 . * A Figura 19.2(b) mostra uma árvore de consulta melhorada, que primeiro aplica as operações SELEÇÃO para reduzir o número dc tuplas que aparecem no PRODUTO CARTESIANO. (a)

^F.UItimO-nome I °P.Nome_projeto='Aquarius' AND P.Numero_projeto=T.Numero_projeto AND T.CpOundonario=F.Cpf AND F.Data_nascimento>'31-12-1957'

nP.Numero projeto=T.Numero projeto I Figura 19.2 Etapas na conversão de uma árvore de consulta durante a otimização heurística, (a) Árvore de consulta inicial (canônica) para a consulta SQL C. (b) Movendo as operações SELEÇÃO mais para baixo na árvore de consulta, (continua)

630

Sistemas de banco de dados

r

71 F.UItimo.nome

(c)

° T.Cpf.f uncionario=F.Cpf I X

° P. Nu mero_projeto= T.Numero_ projeto

° F. Data.nasci mento>'31 -12-1957' I

I

F.UItimo.nome

(d)

bd

T.Cpf_funcionario=F.Cpf

P. N u mero_projeto= T. N u mero.proi eto

" F.Data nascimento>'31-12-1957'

PROJETO P

F.UItimo nome

(e)

T.Cpf_funcionario=F.Cpf

Figura 19.2 Etapas na

conversão de uma árvore de consulta durante a otimização

heurística, (c) Aplicando a operação SELEÇÃO mais

restritiva primeiro, (d) Substituindo PRODUTO CARTESIANO e SELEÇÃO

7 T.Cpf_funcionario M I P.Numero projeto= T.Numero.projeto

P.NumerO-projeto

por operações JUNÇÃO.

(e) Movendo operações PROJEÇÃO mais para baixo

na árvore de consulta.

(continuação)

F.Cpf, F.UItimo.nome

°F.Data nascimento>'31-12-1957'

71 T.Cpf.f uncionario, T. N u mero_projeto

"P.Nome projeto ='Aquarius' TRABALHA EM T

PROJFTO P Outra melhora é alcançada trocando as posições das relações FUNCIONÁRIO e PROJETO na árvore, como mostra a Figura 19.2(c). Isso usa a informação de que Numero.projeto é um atributo de chave da relação PROJETO e, portanto, a operação SELEÇÃO na relação PROJETO recuperará um único registro. Podemos melhorar ainda mais a árvore de consulta ao substituir qualquer operação de PRODUTO CARTESIANO que seja acompanhada por uma condição de junção por uma operação JOIN, como mostra a Figura 19.2(d). Outra melhora é manter apenas os atributos necessários pelas operações subsequentes nas relações intermediárias, incluindo operações PROJEÇÃO (x) o mais cedo possível na árvore de consulta, como mostra a Figura

Capitulo 19

Otimização de consulta

19.2(e). Isso reduz os atributos (colunas) das relações intermediárias, enquanto as operações SELEÇÀO reduzem o número de tuplas (registros). Conforme mostra o exemplo anterior, uma árvore de consulta pode ser transfor­ mada passo a passo em uma árvore de consulta equivalente que é mais eficiente de executar. Porém, temos de garantir que as etapas de transformação sempre levem a uma árvore de consulta equivalente. Para fazer isso, o otimizador de consulta pre­ cisa saber quais regras dc transformação preservam essa equivalência. Discutiremos algumas dessas regras dc transformação a seguir.

Regras gerais de transformação para operações da álgebra relacionai Existem muitas regras para transformar operações da álgebra relacionai cm equivalentes. Para fins de otimização dc consulta, estamos interessados no significado das opera­ ções e das relações resultantes. Logo, se duas relações tiverem o mesmo conjunto de atributos em uma ordem diferente., mas ambas representarem a mesma informação, consideramos que as relações sâo equivalentes. Na Seção 5.1.2, demos uma definição alternativa da relação que torna a ordem dos atributos não importante; usaremos essa definição aqui. Vamos expressar algumas regras de transformação que são úteis na otimização da consulta, sem prová-las: 1. Cascata dc ct. Uma condição dc seleção conjuntiva pode ser desmembrada cm uma cascata (ou seja, uma sequência) dc operações o individuais: a«-,

(—(^(R))...))

ANDc2AND...AND50 AND NomeProduto = "Anel_234" AND C.Pais = "França";

A visão VI pode ser avaliada primeiro, e seus resultados temporariamente mate­ rializados, depois a consulta CG pode ser avaliada usando a visão materializada como uma das tabelas na junção. Usando a transformação de mesclagem, essa consulta torna-se: CT: SELECT C.Codigo_diente, C.NomeCliente, C.Email FROM CLIENTE C, PRODUTO P, VENDAS V WHERE RCodigO-produto = V.codigo_produto AND C.Codigo.diente = V.Codigo_diente AND NomeProduto = "Anel_234" AND C.Pais = "França"

Capitulo 19

Otimização de consulta

P.Codigo_produto, P.rowid, C.rowid, C.Codigo.diente, C.NomeCliente, GEmail HAVING SUM (V.Qtd-Vendida) > 50;

GROUP BY

Após a mesclagem, a consulta resultante CT é muito mais eficiente e menos dis­ pendiosa de ser executada. O raciocínio é o seguinte. Antes da mesclagem, a visão V1 agrupa toda a tabela VENDAS e materializa o resultado, e isso é dispendioso. Na consulta transformada, o agrupamento é aplicado à junção das três tabelas; nessa operação, uma única tupla de produto é envolvida na tabela PRODUTO, filtrando assim os dados de VENDAS consideravelmente. A junção na CT após a transfor­ mação pode ser um pouco mais dispendiosa na medida em que a relação VENDAS inteira está envolvida, em vez da tabela de visão agregada VISÃO.COMPRA na CG. Observe, no entanto, que a operação GROUP BY na VI produz uma tabela cuja cardinalidade não é consideravelmente menor que a cardinalidade de VENDAS, pois o agrupamento é sobre , que pode não ter alta repetição em VENDAS. Observe também o uso de P.rowid e C.rowid, que se referem aos identificadores de linha únicos que são acrescentados para manter a equivalência com a consulta original. Reiteramos que a decisão de mesclar as visões GROUP BY deve ser feita pelo otimizador com base nos custos estimados.

19.2.4 Visões materializadas Discutimos o conceito de visões na Seção 7.3, introduzindo também o conceito de materialização de visões. Uma visão é definida no banco de dados como uma consulta, e uma visão materializada armazena os resultados dessa consulta. O uso de visões materializadas para evitar parte da computação envolvida em uma consulta é outra técnica de otimização de consulta. Uma visão materializada pode ser armaze­ nada temporariamente, para permitir que mais consultas sejam processadas contra ela, ou de forma permanente, como é comum nos data warehouses (ver Capítulo 29). Uma visão materializada é constituída de dados derivados, pois seu conteúdo pode ser computado como um resultado do processamento da consulta que define a visão. A principal ideia por trás da materialização é que é muito menos dispendioso consultá-la quando necessário que refazê-la do zero. A economia pode ser significativa quando a visão envolve operações dispendiosas, como junção, agregação e outras. Considere, por exemplo, a visão V2 na Seção 7.3, que define a visão como uma relação juntando as relações DEPARTAMENTO e FUNCIONÁRIO. Para cada departa­ mento, ela calcula o número total de funcionários e o salário total pago aos fun­ cionários nesse departamento. Se essa informação for frequentemente necessária em relatórios ou consultas, esta visão pode ser armazenada permanenremente. A visão materializada pode conter dados relacionados a apenas um fragmento ou subexpressão da consulta do usuário. Portanto, é preciso que haja um algoritmo para substituir apenas os fragmentos relevantes da consulta com uma ou mais visões materializadas e calcular o restante da consulta de um modo convencional. Na Seção 7.3, também mencionamos três estratégias de atualização (também conhecida como refresh) para atualizar a visão:

■ Atualização imediata, que atualiza a visão assim que qualquer uma das relações que participam da visão seja atualizada. ■ Atualização adiada, que recompõe a visão somente por demanda. ■ Atualização periódica (ou atualização diferida), que atualiza a visão mais tarde, possivelmente com frequência regular.

Quando a atualização imediata está em vigor, ela constitui uma grande quantidade de sobrecarga para manter a visão atualizada quando qualquer uma das relações de

639

640

Sistemas de banco de dados

base subjacentes tiver uma alteração na forma de inserção, exclusão ou modificação. Por exemplo, excluir um funcionário do banco de dados, alterar o salário de um funcionário ou contratar um novo funcionário afeta a tupla correspondente a esse departamento na visão e, portanto, exige que a visão V2 da Seção 7.3 seja atualizada imediatamente. Essas atualizações às vezes são tratadas manualmente por programas que atualizam todas as visões definidas em cima de uma relação básica sempre que essa relação básica é atualizada. Mas, obviamente, não há garantias dc que todas as visões possam ser levadas em consideração. Triggers (ver Seção 7.2), que são ati­ vados após uma atualização na relação básica, podem ser usadas para atuar e fazer as mudanças apropriadas nas visões materializadas. A abordagem direta e ingênua é recalcular toda a visão a cada atualização em qualquer tabela básica, mas isso é proibitivamente dispendioso. Portanto, a manutenção incrementai da visão é feita atualmente na maioria dos SGBDRs. Discutiremos isso a seguir. Manutenção incrementai da visão. A ideia básica por trás da manutenção incre­ mentai da visão é que, em vez dc criar a visão a partir do zero, ela pode ser atualizada de forma incrementai, considerando apenas as mudanças que ocorreram desde a última vez em que ela foi criada/atualizada. O truque é descobrir exatamente qual é a mudança resultante na visão materializada com base em um conjunto de tuplas inseridas ou excluídas na relação básica. Descrevemos a seguir as técnicas gerais para a manutenção de visão incrementai para visões que envolvem junção, seleção, projeção e alguns tipos de agregação. Para lidar com a modificação, podemos con­ siderar essas técnicas como uma combinação de exclusão da tupla antiga, seguida de uma inserção da nova tupla. Considere uma visão V definida sobre as relações R e S. As instâncias respectivas são v^r es.

Junção: se uma visão contém junção interna de relações r e s, = r x $, e existe um novo conjunto de tuplas inseridas: rf, em r, então o novo valor da visão contém (r vj rf) x s. A mudança incremental para a visão pode ser calculada como t'nova = r 5 r( m s. De modo semelhante, dcletar um conjunto dc tuplas rd de r resulta na nova visão como t/n Qel (R) pode ser reescrito como andcZ e a (d1) CREATE (f3) - [: TrabalhaPara ] -> (d2) CREATE (dl) - [: Gerente ] -> (f2) CREATE (d2) - [: Gerente ] -> (f4) CREATE (dl) - [: LocalizadoEm ] -> (Ioc1) CREATE (dl) - [: LocalizadoEm ] -> (Ioc3) CREATE (dl) - [: LocalizadoEm ] -> (Ioc4) CREATE (d2) - [: LocalizadoEm ] -> (Ioc2) Figura 24.4 Exemplos em

CREATE (f 1) - (: TrabalhaEm, {Horas: '32.5'} ] -> (p1)

Neo4j usando a linguagem

CREATE (f 1) - [: TrabalhaEm, {Horas: '7.5'} ] -> (p2)

Cypher, (a) Criando alguns

CREATE (f2) - [: TrabalhaEm, {Horas: '10.0'} ] -> (p1)

nós. (b) Criando alguns

CREATE (f2) - [: TrabalhaEm, {Horas: 10.0} ] -> (p2)

relacionamentos, (c) Sintaxe

CREATE (f2) - [: TrabalhaEm, {Horas: '10.0'} ] -> (p3)

básica das consultas em

CREATE (f2) -1: TrabalhaEm, {Horas: 10.0} ] -> (p4)

Cypher, (continua)

(c) Sintaxe básica simplificada de algumas cláusulas comuns em Cypher: Encontrando nós e relacionamentos que combinam com um padrão: MATCH

Especificando agregados e outras variáveis de consulta: WITH Especificando condições sobre os dados a serem recuperados: WHERE Especificando os dados a serem retornados: RETURN Ordenando os dados a serem retornados: ORDER BY

Umitando o número de itens de dados retornados: LIMIT cnúmero máximo> Criando nós: CREATE Criando relacionamentos: CREATE crelacionamento, tipo de relacionamento e propriedades opcionais> Exclusão: DELETE

Especificando valores e rótulos de propriedade: SET cvalores e rótulos de propriedade> Removendo valores e rótulos de propriedade: REMOVE

816 Sistemas de banco de dados Figura 24.4 Exemplos em Neo4j usando a linguagem Cypher, (d) Exemplos de consultas em Cypher. (continuação)

(d) Exemplos de consultas simples em Cypher: 1. MATCH (d : DEPARTAMENTO {Numero.departamento: '5'}) - [: LocalizadoEm ] * - (loc) RETURN d.Nome.departamento, loc.Local 2. MATCH (f: FUNCIONÁRIO {Funcld: '2'}) -11 TrabalhaEm ] — (p) RETURN f.Primeiro.nome , t.Horas, p.Nome_projeto 3. MATCH (f) - [ t: TrabalhaEm ] -> (p: PROJETO {Pnr: 2)) RETURN p.Nome_projeto, f.Primeiro.nome, t.Horas 4. MATCH (f) - [ t: TrabalhaEm ] — (p) RETURN f.Primeiro.nome , t.Horas, p.Nome.projeto ORDER BY f.Primeiro.nome 5. MATCH (f) — [ t: TrabalhaEm ] * - (p) RETURN f.Primeiro.nome , t.Horas, p.Nome_projeto ORDER BY f.Primeiro.nome LIMIT 10 6. MATCH (f) - (t: TrabalhaEm ] — (p) WITH f, COUNT(p) AS Numero.De.Projetos WHERE Numero.De.Projetos > 2 RETURN f.Primeiro.nome, Numero.De.Projetos ORDER BY Numero.De.Projetos 7. MATCH (f)-[ t: TrabalhaEm ]—* (p) RETURN f , t, p ORDER BY f.Primeiro.nome LIMIT 10 8. MATCH (f: FUNCIONÁRIO {Funcld: '2'}) SET f.Cargo = 'Engenheiro'

■ Etiquetas e propriedades. Quando um nó é criado, seu rótulo pode ser especifi­ cado. Também é possível criar nós sem rótulos. Na Figura 24.4(a), os rótulos dos nós sào FUNCIONÁRIO, DEPARTAMENTO, PROJETO e LOCALIZACOES. DEPARTAMENTO, e os nós criados correspondem a alguns dos dados do banco de dados EMPRESA na Figura 5.6 com algumas modificações; por exemplo, usamos Funcld em vez de CPF e incluímos apenas um pequeno subconjunto dos dados para fins de ilustração. As propriedades sào colocadas entre chaves É possível que alguns nós tenham vários rótulos; por exemplo, o mesmo

nó pode ser rotulado como PESSOA, FUNCIONÁRIO e GERENTE, listando todos os rótulos separados pelo símbolo de dois pontos da seguinte forma: PESSOA:FUNCIONARIO:GERENTE. Ter vários rótulos é semelhante a uma entidade que pertence a um tipo de entidade (PESSO/X) mais algumas subclasses de PESSOA (a saber, FUNCIONrXRIO e GERENTE) no modelo EER (veja o Capítulo 4), mas que também pode ser usada para outras finalidades. ■ Relacionamentos e tipos de relacionamento. A Figura 24.4(b) mostra alguns exemplos de relacionamentos no Neo4j, com base no banco de dados EMPRESA na Figura 5.6. A —* especifica a direção do relacionamento, mas o relacionamento pode ser percorrido em qualquer direção. Os tipos de relacionamento (rótulos) na Figura 24.4(b) são TrabalhaPara, Gerente, LocalizadoEm e TrabalhaEm; somente relacionamentos com o ripo de relacionamento TrabalhaEm possuem propriedades (Horas) na Figura 24.4(b). ■ Caminhos. Um caminho especifica um percurso de parte do grafo. Normalmente é usado como parte de uma consulta para especificar um padrão, em que a con­ sulta será recuperada dos dados do gráfico que correspondem ao padrão. Um caminho normalmente é especificado por um nó inicial, seguido por um ou mais relacionamentos, levando a um ou mais nós finais que satisfazem o padrão. Ele é semelhante aos conceitos de expressões de caminho que discutimos nos capítulos

Capitulo 24

Bancos de dados NOSQL e sistemas de armazenamento Big Data

12 e 13 no contexto de linguagens de consulta para bancos de dados de objetos (OQL) e XML (XPath e XQuery).

■ Esquema opcional. Um esquema c opcional no Neo4j. Os gráficos podem ser criados e usados sem um esquema, mas, no Neo4j versão 2.0, algumas funções relacionadas ao esquema foram adicionadas. Os principais recursos relacionados à criação de esquemas envolvem a criação de índices e restrições com base nos rótulos e proprie­ dades. Por exemplo, é possível criar o equivalente a uma restrição de chave sobre uma propriedade de um rótulo, portanto, todos os nós na coleção de nós associados ao rótulo devem ter valores exclusivos para essa propriedade. ■ Indexação e identificadores de nó. Quando um nó é criado, o sistema Neo4j cria um identificador interno único, definido pelo sistema, para cada nó. Para recuperar nós individuais usando outras propriedades dos nós de maneira eficiente, o usuário pode criar índices para a coleção de nós que possuem um rótulo específico. Normalmente, uma ou mais das propriedades dos nós nessa coleção podem ser indexadas. Por exemplo, Funcld pode ser usado para indexar nós com o rótulo FUNCIONÁRIO, Numero.departamento para indexar os nós com o rótulo DEPARTAMENTO e Numero.projeto para indexar os nós com o rótulo PROJETO.

24.6.2 Linguagem de consulta Cypher do Neo4j Neo4j tem uma linguagem de consulta de alto nível. Cypher. Existem comandos declarativos para criar nós e relacionamentos [veja as figuras 24.4(a) e (b)], bem como para encontrar nós e relacionamentos baseados na especificação de padrões. A exclusão e a modificação de dados também são possíveis no Cypher. Introduzimos o comando CREATE na seção anterior, então vamos dar uma breve visão geral de alguns dos outros recursos do Cypher. Uma consulta Cypher é composta de cláusulas. Quando uma consulta tem várias cláusulas, o resultado de uma delas pode ser a entrada para a próxima cláusula na consulta. Vamos dar uma rápida ideia da linguagem, discutindo algumas das cláusulas por meio de exemplos. Nossa apresentação não pretende ser uma exposição deta­ lhada sobre o Cypher, apenas uma introdução a alguns dos recursos da linguagem. A Figura 24.4(c) resume algumas das principais cláusulas que podem fazer parte de uma consulta em Cyber. A linguagem Cyber pode especificar consultas e atualizações complexas em um banco de dados de grafo. Vamos apresentar alguns exemplos para ilustrar consultas simples em Cyber na Figura 24.4(d). A consulta 1 na Figura 24.4(d) mostra como usar as cláusulas MATCH e RETURN em uma consulta, e a consulta recupera os locais para o departamento número 5. MATCH especifica o padrão e as variáveis de consulta (d e loc) e RETURN especi­ fica o resultado da consulta a ser recuperado referindo-se às variáveis dc consulta. A consulta 2 tem três variáveis (f,tep)e retorna os projetos e horas por semana em que o funcionário com Funcld = 2 trabalha. A consulta 3, por outro lado, retorna os funcionários e a quantidade de horas por semana que trabalham no projeto com Numcro.projeto = 2. A consulta 4 ilustra a cláusula ORDER BY e retorna todos os funcionários e os projetos nos quais eles trabalham, classificados por Primeiro.nome. Também é possível limitar o número de resultados retornados usando a cláusula LIMIT, como na consulta 5, que retorna apenas as 10 primeiras respostas. A consulta 6 ilustra o uso de WITH e agregação, embora a cláusula WITH possa ser usada para separar cláusulas em uma consulta, mesmo que não haja agregação. A consulta 6 também ilustra a cláusula WHERE para especificar condições adicionais e a consulta retorna os funcionários que trabalham em mais de dois projetos, bem como o número de projetos em que cada funcionário trabalha.Também é comum retornar

817

818

Sistemas de banco de dados

os próprios nós e relacionamentos no resultado da consulta, em vez dos valores de propriedade dos nós, como nas consultas anteriores. A consulta 7 é semelhante à consulta 5, mas retorna apenas os nós e os relacionamentos, portanto, o resultado da consulta pode ser exibido como um grafo, usando a ferramenta de visualização do Neo4j. Também é possível adicionar ou remover rótulos e propriedades dos nós. A consulta 8 mostra como adicionar mais propriedades a um nó, adicionando uma propriedade Cargo a um nó de funcionário. O relato anterior oferece uma rápida introdução à linguagem de consulta Cypher do Neo4j. O manual completo está disponível on-line (veja a Bibliografia selecionada ao final do capítulo).

24.6.3 Interfaces do Neo4j e características do sistema distribuído O Neo4j possui outras interfaces que podem ser usadas para criar, recuperar e atualizar nós e relacionamentos em um banco de dados de grafo. Ele também tem duas versões principais: a edição corporativa, que vem com recursos adicionais, e a edição comunitária. Nesta subseção, discutimos alguns dos recursos adicionais do Neo4j. ■ Edição empresarial versus edição comunitária. Ambas as edições suportam o modelo dc dados de grafo c o sistema dc armazenamento do Nco4j, bem como a linguagem de consulta de grafo Cypher e várias outras interfaces, incluindo uma API nativa de alto desempenho, drivers de linguagem para várias linguagens de programação populares, como Java, Python, PHP e a API REST (Representational State Transfer). Além disso, ambas as edições suportam propriedades ACID. A edição empresarial suporta recursos adicionais para aprimorar o desempenho, como caching e clusterização de dados e bloqueio. ■ Interface dc visualização dc grafos. O Nco4j possui uma interface de visualização de grafos, para que um subconjunto de nós e bordas em um dc banco de dados dc grafo possa ser exibido como um grafo. Essa ferramenta pode ser usada para visualizar os resultados da consulta em uma representação de grafos. ■ Replicação mestre-escravo. O Neo4j pode ser configurado em um cluster de nós de sistema distribuído (computadores), em que um nó é designado como o nó mestre. Os dados e os índices são totalmente replicados em cada nó no cluster. Diversas formas de sincronismo dos dados entre os nós mestre c escravo podem ser configuradas no cluster distribuído. ■ Caching. Um cache na memória principal pode ser configurado para armazenar os dados do grafo, a fim dc melhorar o desempenho. ■ Logs lógicos. Logs podem ser mantidos para a recuperação de falhas.

Uma discussão completa dc todos os recursos e interfaces do Neo4j está fora do escopo de nossa apresentação. A documentação completa do Neo4j está disponível on-line (veja a Bibliografia selecionada ao final do capítulo).

24.7 Resumo Neste capítulo, discutimos a classe de sistemas de banco de dados conhecidos como sistemas NOSQL, que se concentram no armazenamento e recuperação efi­ cientes de grandes quantidades de “big data”. As aplicações que usam esses tipos de sistemas incluem mídias sociais, links da web, perfis de usuários, marketing e vendas, postagens c tweets, mapas de estradas, dados espaciais e e-mail. O termo NOSQL é gcralmentc interpretado como Not Only SQL — em vez de NO to SQL — e tem por finalidade transmitir a ideia de que muitas aplicações precisam de

Capitulo 24

Bancos de dados NOSQL e sistemas de armazenamento Big Data

sistemas diferentes dos sistemas SQL relacionais tradicionais para aumentar suas necessidades de gerenciamento de dados. Esses sistemas sâo bancos de dados dis­ tribuídos ou sistemas de armazenamento distribuído, com foco no armazenamento de dados semiestruturados, alto desempenho, disponibilidade, replicação de dados e escalabilidade, em vez de ênfase na consistência de dados imediata, linguagens de consulta poderosas e armazenamento de dados estruturados. Na Seção 24.1, começamos com uma introdução aos sistemas NOSQL, suas características e como eles diferem dos sistemas SQL. Quatro categorias gerais de sistemas NOSQL são baseadas em documentos, armazenamentos de chave-valog em colunas e em grafos. Na Seção 24.2, discutimos como os sistemas NOSQL abordam a questão da consistência entre múltiplas réplicas (cópias) usando o paradigma conhe­ cido como consistência eventual. Discutimos o teorema CAP, que pode ser usado para entender a ênfase dos sistemas NOSQL na disponibilidade. Nas seções 24.3 a 24.6, apresentamos uma visão geral de cada uma das quatro categorias principais de sistemas NOSQL — começando com sistemas baseados em documentos na Seção 24.3, seguidos por armazenamentos chave-valor na Seção 24.4, depois sistemas baseados em coluna na Seção 24.5, e finalmente sistemas baseados em grafos na Seção 24.6. Também notamos que alguns sistemas NOSQL podem não se enquadrar em uma única categoria, mas usar técnicas que abrangem duas ou mais categorias.

PERGUNTAS DE REVISÃO ------------------------------------------------------------------------

24.1. 24.2. 24.3. 24.4. 24.5. 24.6. 24.7. 24.8. 24.9. 24.10.

24.11. 24.12. 24.13. 24.14. 24.15. 24.16.

Para quais tipos dc aplicações os sistemas NOSQL foram desenvolvidos? Quais são as principais categorias dos sistemas NOSQL? Relacione alguns dos sistemas NOSQL em cada categoria. Quais são as principais características dos sistemas NOSQL nas áreas rela­ cionadas aos modelos de dados e linguagens de consulta? Quais são as principais características dos sistemas NOSQL nas áreas rela­ cionadas a sistemas distribuídos e bancos de dados distribuídos? O que é o teorema CAP? Quais das três propriedades (consistência, disponi­ bilidade, tolerância à partição) são mais importantes nos sistemas NOSQL? Quais são as semelhanças e diferenças entre o uso de consistência no CAP versus o uso da consistência no ACID? Quais são os conceitos dc modelagem dc dados usados no MongoDB? Quais são as principais operações CRUD do MongoDB? Discuta como a replicação e o sharding são realizados no MongoDB. Discuta os conceitos de modelagem de dados no DynamoDB. Descreva o esquema de hashing consistente para distribuição de dados, replicação c sharding. Como a consistência c o versionamento são tratados no Voldermort? Quais são os conceitos de modelagem de dados usados nos sistemas NOSQL baseados em coluna e no Hbase? Quais são as principais operações CRUD no Hbase? Discuta os métodos dc armazenamento e sistema distribuído usados no Hbase. Quais são os conceitos dc modelagem dc dados usados no sistema NOSQL Neo4j orientado a grafos? Qual é a linguagem de consulta para o Neo4j? Discuta as interfaces e as características dc sistema distribuído do Nco4j.

819

820

Sistemas de banco de dados

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

O artigo original que descreveu o sistema dc armazenamento distribuído Google BigTable é Chang et ai. (2006), e o artigo original que descreveu o sistema de armaze­ namento chave-valor Dynamo da Amazon é DeCandia et al. (2007). Existem inúme­ ros artigos que comparam diversos sistemas NOSQL com SQL (sistemas relacionais); por exemplo, Parker et al. (2013). Outros artigos comparam sistemas NOSQL com outros sistemas NOSQL; por exemplo, Cattell (2010), Hecht e Jablonski (2011) e Abramova c Bernardino (2013). A documentação, os manuais do usuário e os tutorials para muitos sistemas NOSQL podem ser encontrados na web. Aqui estão alguns exemplos: Tutorials do MongoDB: Manual do MongoDB: Site web do Cassandra: Site web do Hbase: Documentação do Neo4j: Além disso, diversos sites web categorizam os sistemas NOSQL em outras subcategorias, com base na finalidade; é um exemplo de um site desse tipo.

25

Tecnologias Big Data baseadas em MapReduce e Hadoop1 quantidade de dados disponível em todo o mundo tem crescido desde o sur­ gimento da World Wide Web, por volta de 1994. Os primeiros mecanismos de busca — a saber, AltaVista (adquirido pela Yahoo em 2003 e que depois se tornou o mecanismo de busca Yahoo!) e Lycos (que era um mecanismo dc busca e também um portal web) — foram estabelecidos logo depois que surgiu a web. Eles mais tarde foram ofuscados pelo Google e pelo Bing. Depois, surgiu uma série de redes sociais, como Facebook, inaugurado em 2004, e Twitter, em 2006. Linkedln, uma rede profissional inaugurada em 2003, possui mais de 250 milhões de usuá­ rios no mundo inteiro. O Facebook tem mais de 1,3 bilhão de usuários atualmente cm todo o mundo; destes, cerca dc 800 milhões sâo ativos na rede diariamente. O Twitter teve uma estimativa de 980 milhões dc usuários no início de 2014 c chegou a atingir 1 bilhão de tweets por dia em outubro de 2012. Essas estatísticas estão continuamente sendo atualizadas e podem ser encontradas facilmente na web. Uma implicação importante do estabelecimento e crescimento exponencial da web, que levou a computação para leigos de todo o mundo, é que pessoas comuns começaram a criar todos os tipos de transações e conteúdo que geram novos dados. Esses usuários e consumidores de dados multimídia exigem que os sistemas forne­ çam dados específicos do usuário instantaneamente, a partir de armazenamentos de dados gigantescos, ao mesmo tempo em que criam enormes quantidades de dados. O resultado é um crescimento explosivo na quantidade de dados gerados e comunica­ dos em redes em todo o mundo. Além disso, empresas e instituições governamentais registram eletronicamente todas as transações de cada cliente, vendedor e fornecedor e, portanto, acumulam dados nos chamados “data warehouses” (a serem discutidos no Capítulo 29). Adicionados a essa montanha de dados estão os dados gerados por

A

1 Agradecemos a contribuição significativa, para este capítulo, de Harish Butani, membro do Hive Program .Management Committee, e Balaji Palanisamy. da Universidade de Pittsburgh.

822

Sistemas de banco de dados

sensores embutidos em dispositivos como smartphones, medidores inteligentes de energia, automóveis e em todos os tipos de dispositivos e máquinas que detectam, criam e comunicam dados na “internet das coisas". E, claro, temos de considerar os dados gerados diariamente a partir de imagens de satélite e redes de comunicação. Esse crescimento fenomenal da geração de dados significa que a quantidade de dados em um único repositório pode ser calculada em petabytes (IO15 bytes, o que equivale a 2'° bytes) ou terabytes (por exemplo, 1.000 terabytes). O termo big data entrou em nossa linguagem comum e refere-se a quantidades de dados nessa magni­ tude. O relatório McKinsey2*define o termo big data como conjuntos de dados cujo tamanho excede o alcance típico de um SGBD para capturar, armazenar, gerenciar e analisar esses dados. O significado e as implicações dessa enxurrada de dados se refletem em alguns dos fatos mencionados no relatório McKinsey: ■ Um disco de USS 600 pode armazenar toda a música do mundo atualmente. ■ Todos os meses, 30 bilhões de itens de conteúdo são armazenados no Facebook. ■ Há mais dados armazenados em 15 dos 17 setores da economia dos Estados Unidos que na Biblioteca do Congresso norte-americano, que, a partir de 2011, armazenou 235 terabytes de dados. ■ Atualmente, são necessários mais dc 140.000 cargos de análise profunda de dados e mais de 1,5 milhão dc gerentes com experiência em dados nos Estados Unidos. A análise profunda de dados envolve mais análises do tipo descoberta do conhecimento.

O big data está em toda parte, de modo que todos os setores da economia se bene­ ficiam ao aproveitá-lo de forma adequada com tecnologias que ajudarão usuários e gerentes dc dados a tomar melhores decisões com base cm evidências históricas. Dc acordo com o relatório McKinsey:

Se o [sistema] de saúde dos EUA pudesse usar big dara de forma criativa e eficaz para impulsionar a eficiência e a qualidade, estimamos que o valor em potencial dos dados no setor poderia ser superior a US$ 300 bilhões a cada ano. O big data criou inúmeras oportunidades para prestar informações aos consumi­ dores em tempo hábil — informações que serão úteis para tomar decisões, descobrir necessidades e melhorar o desempenho, personalizar produtos e serviços, fornecer aos tomadores de decisão ferramentas algorítmicas mais eficazes e agregar valor com inovações em termos de novos produtos, serviços e modelos de negócios. A IBM corroborou essa afirmação em um livro recente,' que descreve por que embarcou em uma missão mundial de análise de big dara por roda a empresa. O livro da IBM descreve vários tipos de aplicações analíticas: ■ Análise descritiva c preditiva: a análise descritiva deve relatar o que aconteceu, analisar os dados que contribuíram para descobrir por que isso aconteceu e monitorar novos dados para descobrir o que está acontecendo agora. A análise preditiva usa técnicas estatísticas e de mineração de dados (veja no Capítulo 28) para fazer previsões sobre o que acontecerá no futuro. ■ Análise prescritiva: refere-se a análises que recomendam ações. ■ Análise de mídia social: consiste em fazer uma análise de opinião para avaliar a opinião pública sobre temas ou eventos. Ela também permite que os usuários descubram os padrões de comportamento e os gostos dos indivíduos, o que pode ajudar a indústria a direcionar bens e serviços dc maneira personalizada. 2 A introdução é, em grande parte, baseada no relatório McKinsey (2012) sobre big dara, do McKinsey Global Instituto.

} Veja IBM (2014): Analytics Across the Enterprise: How IBM Realizes Business Value from Big Data and Analytics.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

■ Análise de entidade: esta é uma área relativamente nova, que agrupa dados sobre entidades de interesse e aprende mais sobre elas. ■ Computação cognitiva: refere-se a uma área dc desenvolvimento dc sistemas dc computação que interagirão com as pessoas para lhes fornecer melhor com­ preensão e conselhos úteis.

Em outro livro. Bill Franks, da Teradata,4 expressa um tema semelhante; ele afirma que a utilização de big data para obter melhores análises é essencial para obter uma vantagem competitiva em qualquer setor atual, e mostra como desenvolver um “ecossistema dc análise avançada de big data” em qualquer organização, para descobrir novas oportunidades nos negócios. Como podemos ver em todas essas publicações de especialistas, baseadas na indústria, o big data está entrando em uma nova fronteira na qual os big dara serão aproveitados para fornecer aplicações orientadas à análise, que levarão ao aumento da produtividade e a maior qualidade e crescimento cm todos os setores. Este capítulo discute a tecnologia criada na última década para aproveitar o big data. Vamos nos concentrar nas tecnologias que podem ser atribuídas ao ecossistema MapReduce/ Hadoop, que abrange a maior parte do território de projetos de código aberto para aplicações de big data. Não poderemos entrar nas aplicações da tecnologia de big data para análise. Por si só, essa c uma área gigantesca. Alguns dos conceitos básicos de mineração de dados são mencionados no Capítulo 28; no entanto, as ofertas dc análise de hoje vão muito além dos conceitos básicos que descreveremos naquele capítulo. Na Seção 25.1, apresentamos os recursos essenciais do big data. Na Seção 25.2, fornecemos o histórico da tecnologia MapReduce/Hadoop e comentamos sobre as diversas versões do Hadoop. A Seção 25.3 discute o sistema de arquivos subja­ cente chamado Hadoop Distributed File System, para o Hadoop. Discutimos sua arquitetura, as operações de E/S aceitas e sua escalabilidade. A Seção 25.4 fornece mais detalhes sobre MapReduce (MR), incluindo seu ambiente de runtime e suas interfaces de alto nível, chamadas Pig e Hive. Também mostramos o poder do MapReduce cm termos da junção relacionai implementada de várias maneiras. A Seção 25.5 é dedicada ao desenvolvimento posterior, chamado Hadoop v2 ou MRv2 ou YARN, que separa o gerenciamento de recursos do gerenciamento dc tarefas. Seu raciocínio é explicado primeiro, e em seguida sua arquitetura e outros frameworks sendo desenvolvidos no YARN são abordados. Na Seção 25.6, discutimos alguns problemas gerais relacionados à tecnologia MapRcduce/Hadoop. Primeiro, discu­ timos essa tecnologia cm comparação à tecnologia dc SGBD paralela. Em seguida, discutimos isso no contexto da computação em nuvem e mencionamos os problemas de localidade de dados para melhorar o desempenho. O YARN como plataforma de serviços de dados é discutido a seguir, seguido pelos desafios da tecnologia big dara em geral. Terminamos este capítulo na Seção 25.7, mencionando alguns projetos em andamento e resumindo o capítulo.

25.1 O que é Big Data? Big data está se tornando um termo popular e até elegante. As pessoas usam esse termo sempre que está envolvida uma grande quantidade de dados em alguma análise; elas acham que usar esse termo fará com que a análise se pareça com uma aplicação avançada. No entanto, o termo big data refere-se legitimamente a con­ juntos de dados cujo tamanho está além da capacidade típica das ferramentas de software de banco de dados: capturar, armazenar, gerenciar e analisar. No ambiente 4 Veja Franks (2013): Taming The Big Data Tidal Wave.

823

824

Sistemas de banco de dados

atual, o tamanho dos conjuntos de dados que podem ser considerados como big data varia de terabytes (IO12 bytes) ou petabytes (IO15 bytes) ou até exabytes (IO18 bytes). A noção do que é big data dependerá do setor, de como os dados são usados, de quantos dados históricos estão envolvidos e de muitas outras características. O Gartner Group, uma organização popular de nível corporativo que a indústria pesquisa para descobrir sobre tendências, em 2011 caracterizou big data pelos três Vs: volume, velocidade e variedade. Outras características, como veracidade e valog foram adicionadas à definição por outros pesquisadores. Vejamos rapidamente o que significam. Volume. O volume dc dados obviamente se refere ao tamanho total dos dados gerenciados pelo sistema. Dados gerados automaticamente costumam ser volumosos. Alguns exemplos incluem dados de sensores, como os dados em fábricas ou usinas de processamento, gerados por sensores; dados de equipamentos de varredura, como leitores de cartão inteligente (smart card) c de cartão dc credito; c dados dc disposi­ tivos dc medição, como medidores inteligentes ou dispositivos dc registro ambiental. Espera-se que a internet industrial das coisas (HOT ou 1OT — Internet of Things) promova uma revolução que melhore a eficiência operacional das empresas e abra novas fronteiras para o aproveitamento de tecnologias inteligentes. A IOT fará com que bilhões de dispositivos sejam conectados à internet, visto que geram dados continuamente. Por exemplo, no scquenciamento dc genes, a tecnologia dc sequenciamento da nova geração (NGS — Next Generation Sequencing} significa que o volume de dados de sequência genérica será aumentado exponencialmente. Muitas aplicações adicionais estão sendo desenvolvidas e lentamente se tor­ nando realidade. Essas aplicações incluem o uso de sensoriamento remoto para detectar fontes subterrâneas de energia, monitoramento ambiental, monitoramento e regulação de tráfego por sensores automáticos montados em veículos e estradas, monitoramento remoto de pacientes com scanners e equipamentos especiais, e controle e reposição mais rigorosos de estoques, usando identificação por radio­ frequência (RFID — Radio-frequency Identification) e outras tecnologias. Todos esses desenvolvimentos geram um grande volume dc dados. As redes sociais, como o Twitter e o Facebook, têm centenas de milhões de assinantes em todo o mundo, gerando novos dados em cada mensagem que enviam ou publicam. O Twiner atingiu meio bilhão de tweets diariamente em outubro de 2012.5 A quantidade de dados necessários para armazenar um segundo de vídeo de alta definição pode ser igual a 2.000 páginas dc dados de texto. Assim, os dados dc multimídia que estão sendo carregados no YouTube c em plataformas dc hospedagem de vídeo semelhantes sâo significativamente mais volumosos que simples dados numéricos ou de texto. Em 2010, as empresas armazenaram mais de 13 exabytes (1018 bytes) de dados, o que equivale a mais de 50.000 vezes a quantidade de dados armazenados pela Biblioteca do Congresso norte-americano.6

Velocidade. A definição de big data vai além da dimensão do volume; inclui os tipos e a frequência de dados que afetam as ferramentas tradicionais de gerencia­ mento dc banco dc dados. O relatório McKinsey sobre big data7 descreveu a veloci­ dade como a taxa na qual os dados são criados, acumulados, ingeridos c processados. A alta velocidade é atribuída aos dados quando consideramos a velocidade típica das transações nas bolsas de valores; essa velocidade atinge bilhões de transações por dia em determinados dias. Se tivermos de processar essas transações para detectar fraudes em potencial ou precisarmos processar bilhões de registros de chamadas em

Veja Terdiman (2012): 6 De Jagadish et al. (2014) 7 Veja McKinsey (2013).

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

telefones celulares diariamente para detectar atividades maliciosas, enfrentaremos a dimensão da velocidade. Dados em tempo real e dados de streaming são acumu­ lados pelas curtidas (likes) do Twitter e do Facebook a uma velocidade muito alta. A velocidade é útil na detecção de tendências entre pessoas que estão twitando um milhão de tweets a cada três minutos. O processamento de dados streaming para análise também envolve a dimensão de velocidade. Variedade. As fontes de dados nas aplicações tradicionais foram principal mente transações envolvendo finanças, seguros, viagens, saúde, indústrias de varejo e pro­ cessamento governamental e judicial. Os tipos de fontes expandiram-se drasticamente e agora incluem dados da internet (por exemplo, fluxo dc cliques e mídia social), dados de pesquisa (por exemplo, levantamentos e relatórios da indústria), dados de localização (por exemplo, dados de dispositivos móveis e geoespaciais), imagens (por exemplo, vigilância, satélites e varredura na medicina), e-mails, dados da cadeia de suprimentos (por exemplo, EDI — intercâmbio eletrônico de dados, catálogos de fornecedores), dados dc sinais (por exemplo, sensores e dispositivos dc RFID) e vídeos (o YouTube insere centenas de minutos de vídeo a cada minuto). Big data inclui dados estruturados, semiestruturados e não estruturados (veja a discussão no Capítulo 26) em diferentes proporções com base no contexto. Os dados estruturados apresentam um modelo de dados formalmente estruturado, como o modelo relacionai, no qual os dados estão na forma de tabelas contendo linhas e colunas, e um banco de dados hierárquico no IMS, que apresenta tipos de registro como segmentos e campos em um registro. Dados não estruturados não possuem estrutura formal identificável. Discutimos sistemas como o MongoDB (no Capítulo 24), que armazena dados não estrutu­ rados orientados a documentos, e o Neo4j, que armazena dados na forma dc um grafo. Outras formas de dados não estruturados incluem e-mails e blogs, arquivos PDF, áudio, vídeo, imagens, fluxos de cliques e conteúdo da web. O advento da World Wide Web, em 1993-1994, levou a um enorme crescimento na quantidade de dados não estruturados. Algumas formas de dados não estruturados podem se encaixar cm um formato que permite tags bem definidas, que separam os elementos semânticos; esse formato pode incluir a capacidade de impor hierarquias dentro dos dados. XML é hierárquico em seu mecanismo descritivo, e várias formas de XML surgiram em diversos domínios; por exemplo, biologia (bio.ML — linguagem de marcação de biopolímero), GIS (g.ML — linguagem de marcação geográfica) e cervejeira (BeerXML — linguagem para troca de dados de fermentação), para citar apenas alguns. Dados não estruturados constituem o maior desafio nos grandes sistemas de dados atuais. Veracidade. A dimensão da veracidade do big data é um acréscimo mais recente que o advento da internet. A veracidade tem dois recursos integrados: a credibilidade da fonte e a adequação dos dados ao público-alvo. Está intimamente relacionada à confiança; listar a veracidade como uma das dimensões do big dara equivale a dizer que os dados que chegam às chamadas aplicações de big data têm uma variedade de confiabilidade e, portanto, antes dc aceitarmos os dados para aplicações analíticas ou outras, eles precisam passar por algum grau de teste de qualidade c análise de credibilidade. Muitas fontes geram dados incertos, incompletos e imprecisos, tor­ nando sua veracidade questionável. Agora voltamos nossa atenção para as tecnologias consideradas pilares das tec­ nologias de big data. Previa-se que, até 2016, mais da metade dos dados no mundo poderia ser processada por tecnologias relacionadas a Hadoop. Portanto, é impor­ tante para nós rastrear a revolução do MapReduce/Hadoop e entender como essa tecnologia está posicionada nos dias atuais. O desenvolvimento histórico começa com o paradigma de programação chamado de programação MapReduce.

825

826

Sistemas de banco de dados

25.2 Introdução a MapReduce e Hadoop Nesta seção, apresentaremos a tecnologia para análise de big data e processamento de dados conhecida como Hadoop, uma implementação em código aberto do modelo de programação MapReduce. Os dois principais componentes do Hadoop são o para­ digma de programação MapReduce e o HDFS, o Hadoop Distributed File System. Vamos explicar brcvemcnte o histórico por trás do Hadoop e, cm seguida, o MapReduce. Depois, faremos algumas breves observações sobre o ecossistema Hadoop e suas versões.

25.2.1 Antecedentes históricos

Hadoop originou-se da pesquisa por um mecanismo de busca em código aberto. A primeira tentativa foi feita pelo então diretor dc arquivamento da internet, Doug Cutting, c pelo estudante Mike Carafella, da Universidade dc Washington. Cutting c Carafella desenvolveram um sistema chamado Nutch, que poderia rastrear e indexar centenas de milhões de páginas da web. Esse é um projeto Apache de código aberto.8 Depois que a Google lançou o Google File System,9 em outubro dc 2003, e o docu­ mento do paradigma dc programação MapReduce,10 cm dezembro dc 2004, Cutting c Carafella perceberam que várias coisas que estavam fazendo poderíam ser melhoradas com base nas idéias desses dois artigos. Eles criaram um sistema de arquivos subjacente e um framework de processamento que veio a ser conhecido como Hadoop (que usava a linguagem Java, em vez da C++ usada no MapReduce) e colocaram o Nutch em ama dele. Em 2006, Cutting juntou-se ao Yahoo, onde havia um trabalho em andamento para construir tecnologias dc código aberto usando idéias do Google File System c do paradigma de programação MapReduce. A Yahoo queria aprimorar seu processamento de pesquisa e criar uma infraestrutura de código aberto com base no Google File System e no MapReduce. Assim, a Yahoo desmembrou o mecanismo de armazenamento e as partes dc processamento do Nutch como Hadoop (cm homenagem ao brinquedo dc elefante do filho de Cutting). Os requisitos iniciais para o Hadoop eram executar o processamento cm lote usando casos com alto grau de escalabilidade. No entanto, o Hadoop de 2006 só podia ser executado em alguns poucos nós. Mais tarde, a Yahoo criou um fórum de pesquisa para os cientistas de dados da empresa; isso aprimorou a relevância da pesquisa e a receita vinda de anúncios do mecanismo de pesquisa e, ao mesmo tempo, ajudou a amadurecer a tecnologia Hadoop. Em 2011, a Yahoo criou a Hortonworks como uma empresa de software centrada no Hadoop. Na época, a infraestrutura da Yahoo continha centenas de petabytes de armazenamento e 42.000 nós no cluster. Nos anos desde que o Hadoop se tornou um projeto Apache de código aberto, milhares de desenvolvedores em todo o mundo haviam contribuído para isso. Um esforço conjunto das empresas Google, IBM e NSF usou um cluster Hadoop dc 2.000 nós em um data center cm Seattle c ajudou na pesquisa acadêmica sobre o Hadoop. Este teve um enorme crescimento desde o lançamento da Cloudcra cm 2008, como a primeira empresa comercial de Hadoop, e o subsequente desenvolvimento rápido de um grande número de startups. AIDC, uma empresa de análise de mercado da indústria dc software, previu que o mercado do Hadoop superaria USS 800 milhões cm 2016; a IDC previu que o mercado de big data como um todo atingiría USS 23 bilhões em 2016. Para mais detalhes sobre a história do Hadoop, consulte um artigo em quatro partes de Harris.11 8 Para ver a documentação sobre o Nutch, consulte cnutch.apache.org>. 9 Ghemawat, Gbioff e leung (2003).

10 Dean e Ghemawat (2004). 11 Derreck Harris: “The history of Hadoop: from 4 nodes to the future of data," em .

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

Uma parte integral do Hadoop é a estrutura de programação MapReduce. Antes de prosseguirmos, vamos tentar entender o que é o paradigma de programação MapReduce. Deixamos uma discussão detalhada do sistema de arquivos HDFS para a Seção 25.3.

25.2.2 MapReduce O modelo de programação MapReduce e seu ambiente de runtime foram descritos pela primeira vez por Jeffrey Dean e Sanjay Ghemawat (Dean e Ghemawat, 2004), com base em seu trabalho no Google. Os usuários escrevem seus programas cm um estilo funcional de tarefas de mapear e reduzir, automaticamente paralelizadas e executadas em grandes clusters de hardware. O paradigma de programação já existia desde a linguagem LISP, projetada por John McCarthy no final da década dc 1950. No entanto, a reencarnação desse modo dc realizar programação paralela e a maneira como esse paradigma foi implementado no Google deram origem a uma nova onda de pensamento que contribuiu para os desenvolvimentos subsequentes de tecnologias como o Hadoop. O sistema de runtime lida com muitos dos aspectos complicados de engenharia da paralelização, tolerância a falhas, distribuição de dados, balanceamento de carga e gerenciamento de comunicação de tarefas. Desde que os usuários aceitaram os contratos estabelecidos pelo sistema MapReduce, eles podem se concentrar apenas nos aspectos lógicos desse programa; isso permite que os programadores sem experiência em sistemas distribuídos realizem análises em conjuntos de dados muito grandes. A motivação por trás do sistema MapReduce foram os anos gastos pelos autores c outros no Google implementando centenas dc cálculos para fins especiais sobre grandes conjuntos de dados (por exemplo, calculando índices invertidos de con­ teúdo da web coletado por meio de crawling da web; construindo gráficos da web e extraindo estatísticas de logs da web, como distribuição de frequência de solicitações de busca por tópico, por região, por tipo de usuário etc.). Conceitualmente, essas tarefas não são difíceis de expressar; no entanto, dada a escala dos dados em bilhões de páginas da web e com os dados espalhados por milhares de máquinas, a tarefa de execução não foi trivial. Questões de controle de programa e gerenciamento de dados, distribuição de dados, paralelismo de computação e tratamento de falhas tornaram-se extremamente importantes. O modelo dc programação MapReduce e o ambiente de runtime foram projetados para lidar com a complexidade anteriormente citada. A abstração c inspirada pelas primitivas map e reduce presentes na linguagem LISP e em muitas outras lingua­ gens funcionais. Considerou-se um modelo subjacente de dados; esse modelo trata um objeto dc interesse na forma de uma chave única que tenha conteúdo ou valor associados. Este c o par chave-valor. Surpreendentemente, muitos cálculos podem ser expressos como a aplicação de uma operação map a cada “registro” lógico que pro­ duz um conjunto de pares de chave-valor intermediários e depois a aplicação de uma operação reduce a todos os valores que compartilharam a mesma chave (o objetivo do compartilhamento é combinar os dados derivados). Esse modelo permite que a infraestrutura paralelize grandes cálculos com facilidade e use a reexecução como o mecanismo principal para a tolerância a falhas. A ideia de fornecer um modelo de programação restrito para que o runtime possa executar cálculos cm paralelo automaticamente não é nova. MapReduce é o aprimoramento dessas idéias existen­ tes. Conforme é compreendido hoje, MapReduce é uma implementação tolerante a falhas e um ambiente de runtime dimensionado para milhares de processadores. O programador evita a preocupação com o tratamento dc falhas. Nas próximas seções, abreviaremos MapReduce como MR.

827

828

Sistemas de banco de dados

O modelo de programação MapReduce. Na descrição a seguir, usamos o forma­ lismo e a descrição como foram originalmente descritos por Dean e Ghemawat (2010).12 As funções map e reduce possuem o seguinte formato geral: map[K1,V1 ] que é (chave, valor): List[K2,V2] e reduce(K2, List[V2D : List[K3,V3]

Map é uma função genérica que usa uma chave do tipo Kl e um valor do tipo V1, e retorna uma lista de pares de chave-valor do ripo K2 e V2. Reduce é uma função genérica que usa uma chave do ripo K2 e uma lista de valores do tipo V2 e retorna pares do tipo (K3, V3). Em geral, os tipos K1, K2, K3 etc. são diferentes, com o único requisito dc que os tipos de saída da função Map devem corresponder ao tipo dc entrada da função Reduce. O fluxo de trabalho básico da execução do MapReduce é mostrado na Figura 25.1. Suponha que tenhamos um documento e queiramos fazer uma lista de palavras com as respectivas frequências. Este conhecido exemplo de contagem de palavras, citado dirctamente por Dean e Ghemawat (2004), é o seguinte em pseudocódigo: Map (String chave. String valor):

para cada Palavra p em valor Emissaolntermediaria (p, "1");

Aqui, a chave é o nome do documento, e o valor é o conteúdo dc texto do documento. Então, a lista dc pares (p, 1) é somada aos contadores de total dc saída dc todas as palavras encontradas no documento, da seguinte forma: Reduce (String chave. Iterator valores): // aqui, a chave é uma palavra, e os valores são as listas de seus contadores // int resultado = 0;

para cada v in valores :

resultado += Parselnt (v); Emissão (chave, AsString (resultado));

O exemplo anterior na programação XlapRcduce se parece com: Entrada

Figura 25.1 Visão geral da execução do MapReduce. (Adaptado de T. White, 2012)

12 Jeffrey Dean e Sanjay Ghemawat,“MapReduce: Simplified Dara Processing on Large Clusters", em OSDI (20041.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

map[LongWritable,TextKchave, valor):List[Text, LongWritable] = {

String!] palavras = split(valor)

for(p: palavras) { context.out(Text(p), LongWritable(1))

} } reduce[Text, lterable[LongWritable]Kchave, valores):List[Text, LongWritable] = {

LongWritable c = 0 for( v : valores) {

c += v

} context.out(chave,c)

} Os tipos dc dados usados no exemplo anterior sào LongWritable e Text. Cada job em MapReduce deve registrar uma função Map c Reduce. A função Map recebe cada par de chave-valor e, em cada chamada, pode gerar 0 ou mais pares de chave-valor A assinatura da função Map especifica os tipos de dados de seus pares de chave-valor de entrada e saída. A função Reduce recebe uma chave e um iterador de valores associa­ dos a essa chave. Ela pode gerar um ou mais pares dc chave-valor cm cada chamada. Novamente, a assinatura da função Reduce indica os tipos de dados de suas entradas e saídas. O tipo de saída de Map deve corresponder ao tipo de entrada da função Reduce. No exemplo do contador de palavras, a função map recebe cada linha como um valor, divide-a em palavras e emite (por meio da função contexr.out) uma linha para cada palavra com frequência 1. Cada chamada da função Reduce recebe, para uma determinada palavra, a lista de frequências calculadas no lado Map. Ela soma esses valores e envia cada palavra c sua frequência como saída. As funções interagem com um contexto. O contexto é usado para interagir com o framework. Ele é usado por clientes para enviar informações de configuração para as tarefas; e as tarefas podem usá-lo para obter acesso ao HDFS e ler dados diretamente dele, para emitir pares dc chave-valor e para enviar status (por exemplo, contadores dc tarefas) dc volta ao cliente. A forma MapReduce de implementar algumas outras funções, baseada cm Dean e Ghemawat (2004), é a seguinte: Grep distribuído Grcp procura por um determinado padrão em um arquivo. A função Map emite uma linha se corresponder a um padrão fornecido. A função Reduce c uma função de identidade que copia os dados intermediários fornecidos para a saída. Este é um exemplo de uma tarefa apenas de Map; não há necessidade de incorrer no custo de um Shuffle. Daremos mais informações quando explicarmos o runtime do MapReduce.

Grafo invertido dc link da web O objetivo aqui é gerar pares dc saída (URL de destino, URL de origem) para cada link a uma página de destino encontrada em uma página denominada origem. A função Reduce concatena a lista de todos os URI.S de origem associados a um determinado URL de destino e emite o par . índice invertido O objetivo é construir um índice invertido com base em todas as palavras presen­ tes em um repositório de documentos. A função Map analisa cada documento e emite uma sequência de pares (palavra, id_documento). A função Reduce apanha todos os pares para uma determinada palavra, ordena-os por id_documento e emite um par (palavra, lista(id_documcnto)). O conjunto de todos esses pares forma um índice invertido.

829

830

Sistemas de banco de dados

Essas aplicações ilustrativas dào uma ideia da ampla aplicabilidade do modelo de programação MapReduce e da facilidade de expressar a lógica da aplicação usando as fases Map e Reduce. Um job em MapReduce compreende o código para as fases Map e Reduce (geralmente empacoradas como um jar), um conjunto de artefatos necessários para executar as tarefas (como arquivos, outros jars e arquivos) e, mais importante, um conjunto dc propriedades especificadas em uma configuração. Existem centenas de propriedades que podem ser especificadas, mas as principais são as seguintes:

■ a tarefa Map; ■ a tarefa Reduce; ■ a entrada na qual o job c executado: gcralmcnte especificada como caminhofs) HDFS; ■ o formato (Estrutura) da entrada; ■ o caminho da saída; ■ a estrutura de saída; ■ o paralelismo no lado Reduce.

Um job é submetido ao JobTracker, que então escalona e gerencia a execução do job. Ele fornece um conjunto de interfaces para monitorar os jobs em execução. Veja a Wiki13 do Hadoop para obter mais detalhes sobre o funcionamento do JobTracker.

25.2.3 Versões do Hadoop Desde o advento do Hadoop como um novo framework distribuído para executar programas XlapReduce, várias versões foram produzidas:

As versões 1.x do Hadoop são uma continuação da base original 0.20 do código. As versões secundárias a essa linha adicionaram segurança, melhorias adicionais no HDFS e no MapReduce para dar suporte ao HBase, um modelo melhor de programação MR, bem como outras melhorias. /\s versões 2.x incluem os seguintes recursos principais:

■ YARN (Yet Another Resource Navigator) é um gerenciador geral de recursos extraído do JobTracker da MR versão 1. ■ Um novo runtime MR que c executado em cima do YARN.

■ HDFS aprimorado, que tem suporte para federação e maior disponibilidade. No momento em que este livro foi escrito, o Hadoop 2.0 já existia havia cerca de um ano. Sua adoção está aumentando rapidamente; mas uma porcentagem sig­ nificativa de implementações Hadoop ainda é executada sobre Hadoop vl.

25.3 Hadoop Distributed File System (HDFS) Como já dissemos, além do MapReduce, o outro componente básico do Hadoop é o sistema de arquivos HDFS subjacente. Nesta seção, primeiro vamos explicar a arquitetura do HDFS, para depois descrever as operações de entrada/saída de arquivo admitidas no HDFS e, por fim, comentar sobre a escalabilidade do HDFS.

25.3.1 Aspectos preliminares do HDFS O Hadoop Distributed File System (HDFS) é o componente do sistema de arquivos do Hadoop e foi projetado para ser executado em um cluster de hardware comum. O

13 A Wiki do Hadoop está em .

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

HDFS rem por modelo o sistema de arquivos UNIX; no entanto, ele relaxa alguns requi­ sitos POSIX (Portable Operating System Interface) para permitir o acesso por streaming aos dados do sistema de arquivos. O HDFS fornece acesso de alto rendimento a grandes conjuntos de dados. O HDFS armazena metadados do sistema de arquivos e dados da aplicação separadamente. Enquanto os metadados são armazenados em um servidor dedicado, chamado de NameNode, os dados da aplicação são armazenados em outros servidores, chamados DataNodes. Todos os servidores estão totalmente conectados e se comunicam entre si usando protocolos baseados em TCP. Para tornar os dados duráveis, o conteúdo do arquivo é replicado em vários DataNodes, como no Google File System. Isso não só aumenta a confiabilidade, mas também multiplica a largura de banda para transferência de dados e permite a junção de computação e dados no mesmo local. Ele foi projetado com as seguintes suposições e metas:

Falha de hardware: usando hardware comum, a falha de hardware é normal em vez de uma exceção. Portanto, com milhares de nós, detecção e recuperação automáticas de falhas tornam-se essenciais. Processamento cm lote: o HDFS foi projetado principalmcntc para uso cm lote, cm vez dc uso interativo. A alta taxa dc transferência é enfatizada pela baixa latência do acesso aos dados. Varreduras completas de arquivos são muito comuns. Grandes conjuntos de dados: o HDFS foi projetado para suportar arquivos enormes, da casa das centenas de gigabytes até a faixa dos terabytes. Modelo dc coerência simples: as aplicações HDFS precisam de um escritor e muitos modelos dc acesso de leitura para arquivos. O conteúdo do arquivo não pode ser atualizado, mas apenas incrementado. Este modelo impede os problemas de coerência entre as cópias dos dados.

25.3.2 Arquitetura do HDFS O HDFS possui uma arquitetura mestre-escravo. O servidor mestre, chamado NameNode, gerencia a área dc armazenamento do sistema dc arquivos, ou names­ pace. Os clientes acessam o namespace por meio do NameNode. Os escravos, cha­ mados DataNodes, são executados em um cluster de máquinas comuns, geralmente um por máquina. Eles gerenciam o armazenamento anexado ao nó em que são executados. O namespace cm si compreende arquivos e diretórios. Os NameNodcs mantêm inodes (nós dc índice) sobre Arquivos c Diretórios com atributos como propriedade, permissões, tempos de criação e acesso e cotas de espaço em disco. Usando inodes, o mapeamento de blocos de arquivos para DataNodes é determi­ nado. Os DataNodes são responsáveis por atender solicitações de leitura e gravação de clientes. Os DataNodes executam operações de criação, exclusão e replicação de blocos, conforme instruído pelo NameNode. Um cluster pode ter milhares de DataNodes c dezenas dc milhares dc clientes HDFS conectados simultaneamente. Para ler um arquivo, um cliente primeiro se conecta ao NameNode e obtém os locais dos blocos de dados no arquivo que deseja acessar; em seguida, ele se conecta diretamente com os DataNodes que hospedam os blocos e lê os dados. A arquitetura do HDFS tem os seguintes destaques: 1. O HDFS permite desacoplar os metadados das operações de dados. As opera­ ções com metadados são rápidas, ao passo que as transferências de dados são muito mais lentas. Se a localização dos metadados e a transferência de dados não forem desacopladas, a velocidade sofrerá em um ambiente distribuído, porque a transferência dc dados é dominante e atrasa a resposta.

2. A replicação é usada para fornecer confiabilidade e alta disponibilidade. Cada bloco é replicado (o padrão é de três cópias) para um número de nós no cluster.

831

832

Sistemas de banco de dados

Arquivos altamente controversos, como as bibliotecas de job do MapReduce, teriam um número maior de réplicas para reduzir o tráfego da rede.

3. O tráfego da rede c mantido no mínimo. Para leituras, os clientes são direcionados para o DataNode mais próximo. Tanto quanto possível, uma leitura do sistema de arquivos local é tentada e não envolve tráfego de rede; a próxima opção é uma cópia em um nó no mesmo rack antes de passar para outro rack. Para gravações, a fim de reduzir a utilização da largura de banda da rede, a primeira cópia é gravada no mesmo nó que o cliente. Para as outras cópias, o percurso entre os racks é minimizado. NameNode. O NameNode mantém uma imagem do sistema de arquivos, incluindo Anodes e localizações de blocos correspondentes. As alterações no sistema de arquivos são mantidas em um log de confirmação W’ritc-ahcad (consulte a discussão sobre logs Write-ahead no Capítulo 22), chamado Journal. Checkpoints (pontos de verificação) são tomados para fins de recuperação; eles representam um registro persistente da imagem sem as informações dinâmicas relacionadas ao posicionamento do bloco. As informações de posicionamento de blocos são obtidas periodicamente dos DataNodes, conforme descrito a seguir. Durante o reinicio, a imagem é restaurada para o último Checkpoint e as entradas do Journal são aplicadas a essa imagem. Um novo Checkpoint e um Journal vazio são criados para que o NameNode possa começar a aceitar novas solicitações de clientes. O tempo de inicialização de um NameNode é proporcional ao tamanho de arquivo do Journal. Mesclar o ponto de verificação com o Journal reduz periodicamente o tempo de reinicialização. Observe que, com a arquitetura descrita, é catastrófico ter qualquer dano no Checkpoint ou no Journal. Para proteger contra danos, ambos são gravados em vários diretórios de diferentes volumes.

NameNodes secundários. Estes são NameNodes adicionais que podem ser cria­ dos para executar a função de ponto de verificação ou uma função de backup. Um nó do Checkpoint combina periodicamente os arquivos existentes de Checkpoint e Journal. No modo de backup, ele atua como outro local de armazenamento para o Journal do NameNode principal. O NameNode de backup permanece atualizado com o sistema de arquivos e pode assumir em caso de falha. No Hadoop vl, esse repasse deve ser feito manualmente. DataNodes. Os blocos são armazenados em um DataNode no sistema de arquivos nativo do nó. O NameNode direciona os clientes para os DataNodes que contêm uma cópia do bloco que eles desejam ler. Cada bloco tem sua representação em dois arquivos no sistema de arquivos nativo: um arquivo contendo os dados e um segundo contendo os metadados, que inclui as somas dc verificação para os dados do bloco e o carimbo de geração do bloco. DataNodes e NameNodes não se comu­ nicam diretamente, mas por meio do chamado mecanismo heartbeat, que se refere a um relatório periódico do estado do DataNode para o NameNode; o relatório é chamado de Block Report (relatório de blocos). O relatório contém o id do bloco, o carimbo de geração e o comprimento de cada bloco. Os locais dos blocos não fazem parte da imagem do namespace. Eles devem ser obtidos a partir dos relatórios dc blocos, e mudam conforme os blocos são movidos. O JobTracker do MapReduce, com o NameNode, usa as últimas informações do relatório de blocos para fins de escalonamento. Em resposta a um heartbeat do DataNode, o NameNode envia um dos seguintes tipos de comandos para o DataNode: ■ Replicar um bloco para outro nó. ■ Remover uma réplica dc bloco. ■ Registrar novamente o nó ou encerrá-lo. ■ Enviar um relatório de bloqueios imediato.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

25.3.3 Organizações de E/S de arquivo e gerenciamento de réplicas no HDFS O HDFS fornece um modelo dc gravador único c vários leitores. Os arquivos não podem ser atualizados, mas apenas incrementados. Um arquivo consiste em blocos. Os dados sào gravados em pacotes de 64 KB em um pipeline de gravação, configurado para minimizar a utilização da rede, conforme descrito anteriormente. Os dados gravados no último bloco ficam disponíveis somente após uma operação hflush explícita. E possível haver leitura simultânea pelos clientes enquanto os dados estão sendo gravados. Uma soma de verificação é gerada e armazenada para cada bloco, sendo verificada pelo cliente para detectar adulteração de dados. Após a detecção de um bloco adulterado, o NameNode é notificado; ele inicia um processo para replicar o bloco e instrui o DataNode a remover o bloco adulterado. Durante a operação de leitura, é feita uma tentativa de buscar uma réplica de um nó o mais próximo possível, ordenando os nós em ordem crescente de distância do cliente. Uma leitura falha quando o DataNode está indisponível, quando o teste da soma de verificação falha ou quando a réplica não está mais no DataNode. O HDFS foi otimizado para processamento em lote, semelhante ao MapReduce. Posicionamento de blocos. Os nós de um cluster Hadoop geralmente estão espalha­ dos por vários racks. Eles normalmente são organizados de forma que os nós de um rack compartilhem um switch e os switches do rack estejam conectados a um switch de alta velocidade no nível superior. Por exemplo, o nível do rack pode ter um switch de 1 Gb, ao passo que no nível superior pode haver um switch de 10 Gb. O HDFS estima a largura de banda da rede entre DataNodes com base em sua distância. DataNodes no mesmo nó físico têm uma distância de 0, no mesmo rack estão a uma distância de 2, e cm racks diferentes estão a uma distância de 4. A política dc posicionamento do bloco default do HDFS se equilibra entre minimizar o custo dc gravação c maxi­ mizar a confiabilidade e a disponibilidade dos dados, bem como a largura de banda de leitura agregada. A largura de banda da rede consumida é estimada com base na distância entre os DataNodes. Assim, para DataNodes no mesmo nó físico, a distância é 0, ao passo que no mesmo rack é 2 e em um rack diferente é 4. O objetivo final do posicionamento de blocos é minimizar o custo de gravação e, ao mesmo tempo, maxi­ mizar a disponibilidade c a confiabilidade dos dados, bem como a largura dc banda disponível para leitura. As réplicas são gerenciadas para que haja pelo menos uma no nó original do cliente que a criou e outras sejam distribuídas entre outros racks. De preferência, as tarefas sào executadas nos nós onde os dados residem; três réplicas dão ao cscalonador uma margem suficiente para colocar as tarefas onde os dados cstào. Gerenciamento de réplicas. Com base nos relatórios de blocos dos DataNodes, o NameNode rastreia o número de réplicas e a localização de cada bloco. Uma fila dc prioridade de replicação contém blocos que precisam ser replicados. Um thread dc segundo plano monitora essa fila c instrui um DataNode a criar répli­ cas e distribuí-las entre os racks. O NameNode prefere ter tantos racks diferentes quanto possível para hospedar as réplicas de um bloco. Os blocos replicados em excesso fazem com que algumas réplicas sejam removidas com base na utilização dc espaço dos DataNodes.

25.3.4 Escalabilidade do HDFS Como estamos discutindo tecnologias de big data neste capítulo, é importante discutir alguns limites de escalabilidade no HDFS. Shvachko, membro do comitê de gerenciamento de programas do Hadoop, comentou que o cluster HDFS do Yahoo alcançou os níveis mostrados a seguir, em oposição aos alvos pretendidos (Shvachko,

833

834

Sistemas de banco de dados

2010). Os números entre parênteses sào os alvos que ele listou. Capacidade: 14 petabytes (contra 10 petabytes); número de nós: 4.000 (contra 10.000); clientes: 15.000 (contra 100.000); e arquivos: 60 milhões (contra 100 milhões). Assim, o Yahoo chegou muito perro de suas meras pretendidas em 2010, com um cluster menor de 4.000 nós e menos clientes; mas o Yahoo realmente excedeu a meta com relação à quantidade total de dados manipulados. Algumas das observações feitas por Shvachko (2010) merecem destaque. Elas são baseadas na configuração do HDFS usada no Yahoo em 2010. A seguir; apresentamos os números reais e estimados para dar ao leitor uma noção do que está envolvido nesses gigantescos ambientes de processamento de dados. ■ O tamanho do bloco usado foi 128K e um arquivo médio continha 1,5 bloco. O NameNode usava cerca de 200 bytes por bloco e 200 bytes adicionais para um /-node. Cem milhões dc arquivos referentes a 200 milhões de blocos exigiríam capacidade de memória RAM superior a 60 GB. ■ Para 100 milhões de arquivos com tamanho de 200 milhões de blocos e um fator de replicação de 3, o espaço em disco necessário é de 60 PB. Assim, uma regra prática foi proposta, segundo a qual 1 GB de RAM em NameNode corresponde aproximadamente a 1 PB de armazenamento de dados com base na suposição de 128K dc tamanho dc bloco c dc 1,5 bloco por arquivo. ■ Para armazenar 60 PB de dados em um cluster de 10.000 nós, cada nó precisa dc uma capacidade de 6 TB. Isso pode ser obtido com oito drives dc 0,75 TB. ■ A carga de trabalho interna do NameNode é um relatório de blocos. Cerca de 3 relatórios por segundo contendo informações de blocos cm 60K blocos por relatório foram recebidos pelo NameNode. ■ A carga externa no NameNode consistia cm conexões externas c tarefas de jobs do MapReduce. Isso resultou cm dezenas de milhares de conexões simultâneas. ■ A leitura do cliente consistia em realizar uma pesquisa de blocos para obter localizações dc blocos do NameNode, seguido do acesso à replica mais próxima do bloco. Um cliente típico (o job Xlap dc uma tarefa XÍR) leria dados de 1.000 arquivos com uma leitura média de metade de um arquivo cada, totalizando 96 X1B de dados. Estimou-se que isso levava 1,45 segundo. Nessa taxa, 100.000 clientes enviariam 68.750 solicitações de localização de bloco por segundo para o NameNode. Isso foi considerado bem dentro da capacidade do NameNode, que poderia lidar com 126 mil solicitações por segundo. ■ A carga de trabalho dc gravação: considerando uma taxa dc transferencia de gravação dc 40 XlB/s, um cliente em média grava 96 X1B em 2,4s. Isso cria mais de 41 mil solicitações de “criar bloco" a partir de 100.000 nós no NameNode. Isso foi considerado muito acima da capacidade do NameNode.

A análise apresentada considerou que havia apenas uma tarefa por nó. Na realidade, pode haver várias tarefas por nó, como no sistema real do Yahoo, que executou quatro tarefas MapReduce (MR) por nó. O resultado foi um gargalo no NameNode. Questões como essas foram tratadas no Hadoop v2, que discutiremos na próxima seção.

25.3.5 0 ecossistema do Hadoop O Hadoop é mais conhecido pelo modelo de programação MapReduce, sua infraestrutura de runtime c pelo HDFS (Hadoop Distributed File System). No entanto, o ecossistema do Hadoop possui um conjunto de projetos relacionados que fornecem funcionalidade adicional em cima desses projetos centrais. Muitos deles são projetos Apache de código aberto de alto nível e têm uma grande comunidade de usuários contribuintes. Listamos alguns importantes aqui:

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

Pig e Hive: fornecem uma interface de nível superior para trabalhar com o fra­ mework Hadoop.

■ Pig fornece uma linguagem de fluxo de dados. Um script escrito em PigScript se traduz em um grafo acíclico direcionado de jobs MapReduce. ■ Hive fornece uma interface SQL em cima do MapReduce. O suporte para SQL no Hive inclui a maioria dos recursos da SQL-92 e muitos dos recursos de análise avançada dc padrões SQL posteriores. Hive também define a abs­ tração SerDc (Serialização/Desscrialização), que define um modo dc modelar a estrutura dc registros cm conjuntos de dados no HDFS além de apenas pares de chave-valor. Discutiremos ambos em detalhes na Seção 25.4.4.

Oozie: serviço para escalonamento e execução de fluxos de trabalho de jobs; etapas individuais podem ser jobs MR, consultas do Hive, scripts do Pig e assim por diante. Sqoop: biblioteca e ambiente de runtime para mover dados com eficiência entre bancos de dados relacionais e HDFS. HBase: armazenamento de chave-valor orientado à coluna, que usa o HDFS como seu armazenamento subjacente. (Consulte o Capítulo 24 para ver uma discussão mais detalhada sobre o HBasc.) Ele suporta o processamento em lote usando MR e pesquisas baseadas em chave. Com o projeto adequado do esquema de chave-valoi; diversas aplicações são implementadas usando o HBase. Entre elas estão análise de séries temporais, data warehousing, geração de cubos e pesquisas multidimensionais, e streaming de dados.

25.4 MapReduce: detalhes adicionais .Apresentamos o paradigma MapReduce na Seção 25.2.2. zXgora, vamos analisá-lo um pouco mais em termos do runtime MapReduce. Discutimos como a operação relacionai de junção (join) pode ser tratada por meio do MapReduce. Examinamos as interfaces dc alto nível do Pig c do Hive. Por fim, discutimos as vantagens da combinação MapReduce/Hadoop.

25.4.1 Runtime do MapReduce O objetivo desta seção é fornecer uma visão geral ampla do ambiente de run­ time do MapReduce. Para obter uma descrição detalhada, o leitor poderá consultar White (2012). MapReduce é um sistema mcstre-escravo que geralmente é executado no mesmo cluster que o HDFS. Normalmente, clusters de médio a grande porte do Hadoop consistem em uma arquitetura de dois ou três níveis construída com servidores montados em rack. JobTracker. O processo mestre é chamado de JobTracker. Ele é responsável por gerenciar o ciclo de vida dos jobs e escalonar tarefas (Tasks) no duster. É respon­

sável por:

■ Enviar o job, inicializando-o, fornecendo seu status e estado para os clientes e os TaskTrackers (os escravos), e concluir o job. ■ Escalonar tarefas Map e Reduce no cluster Ele faz isso usando um plugin de escalonador. TaskTracker. O processo escravo é chamado de TaskTracker. Existe um em execução em todos os nós Worker do cluster. As tarefas Map-Reduce são executadas nos nós Worker. Os daemons do TaskTrackerem execução nesses nós se registram no JobTracker

835

836

Sistemas de banco de dados

na inicialização. Eles executam tarefas que o Job Tracker lhes atribui. As tarefas são executadas em um processo separado no nó; o ciclo de vida do processo é gerenciado pelo TaskTracker. O TaskTracker cria o processo da tarefa, monitora sua execução, envia heartbeats de status periódicos para o JobTracker e, sob condições de falha, pode encerrar o processo a pedido do JobTracker. O TaskTracker fomece serviços para as tarefas, o mais importante dos quais é o Shuffle, que descreveremos mais adiante. A. Fluxo geral de um job MapReduce

Um job MapReduce passa pelos processos de Submissão do job. Inicialização do job. Atribuição de tarefa. Execução de tarefa e, finalmente. Conclusão do job. O JobTracker e o TaskTracker; que descrevemos anteriormente, estão ambos envolvidos nestes processos. A seguir, vamos apresentar uma rápida explicação de cada um. Submissão do job: Um cliente submete um job para o JobTracker. O pacote do job contém os executáveis (como jar), quaisquer outros componentes (arquivos, arquivamentos jars) necessários para executar o job e as divisões de entrada (InputSplits) para o job. Inicialização do job: O JobTracker aceita o job e o coloca em uma fila de jobs. Com base nas divisões de entrada, cria tarefas de mapeamento para cada divi­ são. O número de tarefas dc redução c criado com base na configuração do job. Atribuição dc tarefa: O cscalonador do JobTracker atribui a tarefa ao TaskTracker a partir de um dos jobs cm execução. No Hadoop vl, os TaskTrackers têm um número fixo de slots para tarefas de mapeamento e para tarefas de redução. O cscalonador considera as informações de localização dos arquivos de entrada ao escalonar tarefas nos nós do cluster. Execução dc tarefas: Uma vez que uma tarefa foi escalonada em um slot, o TaskTracker gerencia a execução dela: disponibilizando todos os artefatos dc tarefa ao processo da tarefa, iniciando a tarefa JVM, monitorando o processo e coordenando com o JobTracker para executar operações de gerenciamento, como limpeza na saída de tarefas e exclusão de tarefas em condições de falha. O TaskTracker tambcm fornece o Serviço de Shuffle às tarefas; descreveremos isso quando discutirmos o Procedimento de Shuffle, mais adiante. Conclusão do job: Quando a última tarefa em um job é concluída, o JobTracker executa a tarefa de limpeza do job (que é usada para limpar arquivos interme­ diários no HDFS e nos sistemas de arquivos locais dos TaskTrackers).

B. Tolerância a falhas no MapReduce Existem três tipos de falhas: falha da tarefa, falha do TaskTracker e falha do JobTracker. Falha da tarefa: Esta pode ocorrer se o código da tarefa lançar uma exceção de Runtime ou se a Java Virtual Machine falhar inesperadamente. Outro problema é quando o TaskTracker não recebe atualizações do processo da tarefa por um tempo (o período de tempo é configurável). Em todos esses casos, o TaskTracker notifica o JobTracker de que a tarefa falhou. Quando o JobTracker for notificado da falha, ele reprogramará a execução da tarefa. Falha do TaskTracker: Um processo do TaskTracker pode falhar ou ser desconectado do JobTracker. Depois que o JobTracker marca um TaskTracker como rendo uma falha, todas as tarefas de mapeamento concluídas pelo TaskTracker são colocadas de volta na fila para serem reescalonadas. Da mesma forma, qualquer tarefa de mapeamento ou tarefa de redução em andamento em um TaskTracker com falha tambcm c rccscalonada.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

Falha do JobTracker: No Hadoop vl, a falha do JobTracker nào é recuperável. O JobTracker é um ponto único de falha. O JobTracker precisa ser reiniciado manualmente. Na reinicialização, todos os jobs em execução devem ser ressubmetidos. Esse é um dos inconvenientes do Hadoop vl, que foi tratado pela próxima geração do Hadoop MapReduce, chamado de YARN. Semântica na presença de falha: Quando os operadores de mapeamento e redução fornecidos pelo usuário são funções determinísticas de seus valores dc entrada, o sistema MapReduce produz a mesma saída que teria sido produzida por uma execução sequencial sem falhas do programa inteiro. Cada tarefa grava sua saída em um diretório de tarefas particular Se o JobTracker receber várias conclusões para a mesma tarefa, ele ignorará rodas, exceto a primeira. Quando um job é concluído, as saídas da tarefa são movidas para o diretório dc saída do job.

C. O procedimento Shuffle

Um recurso importante do modelo dc programação MapReduce (MR) é que os redutores juntam todas as linhas dc uma determinada chave. Isso c entregue pelo chamado shuffle do MR. O shuffle é dividido nas fases Map, Copy c Reduce. Fase Map: quando as linhas são processadas em tarefas de mapeamento, elas são inicialmente mantidas em um buffer na memória, cujo tamanho é configurável (o padrão c 100 MB). Uma thread cm segundo plano particiona as linhas cm buffer com base no número dc redutores no job e no Particionador. O Particionador é uma interface plugin que é solicitada a escolher um redutor para um determi­ nado valor de chave e o número de redutores no job. As linhas particionadas são classificadas em seus valores de chave. Elas podem ser classificadas em um Compandor (Comparator) fornecido, para que as linhas com a mesma chave tenham uma ordem dc classificação estável. Isso é usado para junção a fim dc garantir que, para linhas com o mesmo valor dc chave, as linhas da mesma tabela estejam agrupadas. Outra interface que pode ser conectada é a interface Combinadora (Combiner). Esta é usada para reduzir o número de linhas de saída por chave de um mapeador e é feita aplicando uma operação de redução cm cada mapeador para todas as linhas com a mesma chave. Durante a fase de mapeamento, várias iterações dc particionamento, classificação e combinação podem acontecer. O resultado final é um único arquivo local por redutor, que é classificado sobre a chave. Fase de cópia (copy): os redutores extraem seus arquivos de todos os mapeadores assim que estiverem disponíveis. Estes são fornecidos pelo JobTracker em respostas heartbeat. Cada mapeador possui um conjunto de threads de escuta que atendem a solicitações do redutor por esses arquivos. Fase de redução (reduce): o redutor lê rodos os seus arquivos dos mapeadores. Todos os arquivos são mesclados antes de serem transmitidos para a função de redução. Pode haver vários estágios de mesclagem, dependendo de como os arquivos do mapeador se tomam disponíveis. O redutor evitará mcsclagcns desnecessárias; por exemplo, os últimos N arquivos serão mesclados conforme as linhas estiverem sendo transmitidas para a função de redução. D. Escalonamento de jobs

O JobTracker no MR 1.0 é responsável por escalonar o trabalho nos nós do clus­ ter. Os jobs submetidos dos clientes são adicionados à fila de jobs do JobTracker. As versões iniciais do Hadoop usavam um escalonador FIFO que escalonava jobs sequencial mente conforme eram submetidos. A qualquer momento, o cluster exe­ cutaria as tarefas de um único job. Isso causava atrasos indevidos cm jobs curtos,

837

838

Sistemas de banco de dados

como consultas hive ocasionais, se tivessem de esperar por tarefas tipo aprendizado de máquina, de longa duração. Os tempos de espera excederíam os tempos de execução, e a taxa de transferência no cluster sofreria. Além disso, o cluster também permaneceria subutilizado. Descrevemos de forma sucinta dois outros tipos de escalonadores, chamados de Escalonador Fair e Escalonador Capacity, que aliviam essa situação. Escalonador Fain o objetivo do Escalonador Fair é fornecer um tempo de resposta rápido para pequenos jobs cm um cluster compartilhado do Hadoop. Para esse escalonador, os jobs são agrupados cm pools. A capacidade do cluster é unifor­ memente compartilhada entre os pools. Em qualquer momento, os recursos do cluster são divididos igualmente entre os pools, utilizando assim a capacidade do cluster uniformemente. Uma maneira típica de configurar pools é atribuir um pool a cada usuário c atribuir a determinados pools um número mínimo de slots. Escalonador Capacity’: o Escalonador Capacity’ é voltado para atender às necessi­ dades de grandes clientes corporativos. Ele foi projetado para permitir que vários locatários compartilhem recursos de um grande cluster Hadoop alocando recursos de maneira oportuna sob um determinado conjunto de restrições de capacidade. Em grandes empresas, os departamentos individuais estão preocupados em usar um cluster Hadoop centralizado por preocupações de que talvez não consigam atender aos SLAs (service-level agreements — contratos de nível de serviço) de suas aplicações. O Escalonador Capacity foi projetado para oferecer garantias a cada locatário sobre a capacidade do cluster, usando as seguintes provisões: ■ Há suporte para várias filas, com limites rígidos e flexíveis em termos de fração de recursos. ■ Listas de controle de acesso são usadas para determinar quem pode submeter, visualizar e modificar os jobs em uma fila. ■ A capacidade em excesso é distribuída uniformemente entre as filas ativas.

■ Locatários têm limites de uso; tais limites impedem que eles monopolizem o cluster.

25.4.2 Exemplo: alcançando junções no MapReduce Para compreender o poder e a utilidade do modelo de programação MapReduce, é instrutivo considerar a operação mais importante da álgebra relacionai, chamada Join (junção), que introduzimos no Capítulo 6. Discutimos seu uso por meio de con­ sultas SQL (capítulos 7 e 8) e sua otimização (capítulos 18 e 19). Vamos considerar o problema de juntar duas relações R(A, B) com S(B, C) com a condição dc junção R.A = S.B. Suponha que ambas as tabelas residam no HDFS. Aqui, listamos as diversas estratégias que foram criadas para realizar equijunções no ambiente MapReduce.

Junção merge-sort. A estratégia mais ampla para executar uma junção é utilizar o Shuffle para particionar c classificar (sort) os dados c fazer com que os redutores façam a mesclagem (merge) e gerem a saída. Podemos configurar um job MR que lê blocos de ambas as tabelas na fase de mapeamento. Configuramos um Particionador para as linhas de partição hash de R c S sobre o valor da coluna B. A saída de chave da fase de mapeamento inclui uma tag de tabela. Então a chave tem o formato (tag, (chave)). Em MR, podemos configurar uma classificação personalizada para o shuffle do job; o Sort personalizado classifica as linhas que possuem a mesma chave. Nesse caso, classificamos as linhas com o mesmo valor B com base na tag. Damos à tabela menor uma tag de 0 e à tabela maior uma tag de 7. Assim, um reduror verá rodas as linhas com o mesmo valor B na ordem: linhas da tabela menor primeiro, depois as linhas da tabela maior. O redutor pode armazenar em buffer as linhas da tabela menor; uma vez começando a receber as linhas da tabela maiog ele pode fazer um produto cartesiano na memória com as linhas da tabela menor em buffer para gerar a saída

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

da junção. O custo dessa estratégia é dominado pelo custo do shuffle, que grava e lê cada linha várias vezes.

Junção de hash do lado de mapeamento. Para o caso em que uma das relações dc R ou Sé uma tabela pequena, que pode ser carregada na memória de cada tarefa, podemos fazer com que a fase de mapeamento funcione somente nas grandes divisões de tabela. Cada tarefa de mapeamento pode ler a tabela pequena inteira e criar um mapeamento de hash da memória com base em B como a chave de hash. Em seguida, pode executar uma junção de hash. Isso é semelhante aos Hash Joins nos bancos de dados. O custo dessa tarefa é aproximadamente o custo de ler a tabela grande. Junção de partição. Suponha que ReS estejam armazenadas de tal forma que sejam particionadas pelas chaves de junção. Então, todas as linhas em cada divisão pertencem a um determinado intervalo identificável do domínio do campo de junção, que é B em nosso exemplo. Suponha que ReS sejam armazenados com p arquivos. Suponha que o arquivo (/) contenha linhas tais que (Valor B)mod p = i. Então só precisamos unir o z-ésimo arquivo de \R\)R com o i-ésimo arquivo correspondente de S. Uma maneira de fazer isso é executar uma variação da junção do lado de mapeamento que discutimos anteriormente: fazer com que o Mapper que manipula a z-ésima partição da tabela maior leia a z-ésima partição da tabela menor. Essa estratégia pode ser expandida para funcionar mesmo quando as duas tabelas não tiverem o mesmo número de partições. Basta que uma seja um múltiplo da outra. Por exemplo, se a tabela A é dividida em duas partições e a tabela B é dividida em quatro partições, então a partição 1 da tabela A precisa unir-se às partições 1 e 3 de B, e a partição 2 de A precisa unir-se às partições 2 e 4 de B. A oportunidade de executar Junção com Bucket (veja a seguir) também é comum: por exemplo, suponha que ReS sejam as saídas de junções merge-sort ante­ riores. A saída da junção merge-sort é particionada nas expressões de junção. Outra junção desse conjunto de dados nos permitirá evitar um shuffle.

Junções com Bucket. Esta é uma combinação de junções do lado de mapeamento e de junções de particionamento. Neste caso, apenas uma relação, digamos a relação do lado direito, é particionada. Podemos, então, executar Mappers na relação do lado esquerdo e executar uma junção de mapeamento contra cada partição do lado direito. Junções de N vias do lado de mapeamento. Uma junção em R(A, B, C, D), S(B, E) e T(C, F) pode ser obtida em um job MR, desde que as linhas de uma chave para todas as tabelas pequenas possam ser armazenadas na memória. A junção é típica em Data Warehouses (consulte o Capítulo 29), em que R é uma tabela de fatos e S e T são tabelas de dimensões cujas chaves são B e C, respectivamente. Em geral, em um data warehouse, os filtros de consulta são especificados em atributos dimensio­ nais. Portanto, cada tarefa de mapeamento possui memória suficiente para manter o mapeamento hash de várias tabelas dimensionais pequenas. Como as linhas da tabela de Fato estão sendo lidas na tarefa dc mapeamento, elas podem ser juntadas com todas as tabelas dimensionais que a tarefa de mapeamento leu para a memória. Junções simples de N vias. Uma junção em R(A, B), S(B, C) e T(B, D) pode ser obtida em um job MR, desde que as linhas de uma chave para todas as tabelas pequenas possam ser armazenadas em buffers na memória. Suponha que R seja uma tabela grande e S e T sejam tabelas relativamente menores. Então é comum que, para qualquer valor dc chave B, o número dc linhas cm S ou T caiba na memória dc uma tarefa. Em seguida, dando à tabela grande a tag maior, é fácil generalizar a junção Merge-Sort para uma junção de N vias em que as expressões de junção são as mesmas. Em um redutor para um valor de chave B, o redutor receberá primeiro as linhas de S, depois as linhas de T e, finalmente, as linhas de R. Como a suposição é dc que não há um grande número dc linhas cm S c T, o redutor pode armazená-las em cache. À medida que ele recebe linhas de R, pode fazer um produto cartesiano com as linhas de S e T armazenadas em cache e gerar o resultado da junção.

839

840

Sistemas de banco de dados

Além das estratégias anteriores para executar junções usando o paradigma MapReduce, algoritmos foram propostos para outros tipos de junções (por exemplo, a junção natural geral de multivias com casos especiais de junção de cadeia ou junção de estrela em data warehouses foram manipuladas como um único job MR).14 Da mesma forma, foram propostos algoritmos para lidar com a distorção nos atributos de junção (por exemplo, em uma tabela de fatos de vendas, alguns dias podem ter um número desproporcional de transações). Para junções em atributos com viés, um algoritmo modificado deixaria o Particionador atribuir valores exclusivos aos dados que possuem um grande número de entradas e deixá-los ser manipulados por tarefas de redução, enquanto o restante dos valores pode passar pelo particionamento de hash, como de costume. Essa discussão deverá dar ao leitor um bom senso das muitas possibilidades de implementar estratégias de junção sobre o MapReduce. Há outros fatores que afetam o desempenho, como o armazenamento de linha versus coluna e o envio de predicados para os manipuladores de armazenamento. Estes estão fora do escopo da nossa discussão aqui. Os leitores interessados encontrarão publicações de pesquisa em andamento nessa área que são semelhantes a Afrati e Ullman (2010). O objetivo desta seção é destacar dois desenvolvimentos importantes que impactaram a comunidade de big data fornecendo interfaces de alto nível em cima da tecnologia básica de Hadoop e MapReduce. Vamos dar uma breve visão geral da linguagem Pig Latin e do sistema Hive.

Apache Pig. Pig15 era um sistema que foi projetado no Yahoo Research para preencher a lacuna entre interfaces de estilo declarative como SQL, que estudamos no contexto do modelo relacionai, e o estilo de programação procedural dc baixo nível, mais rígido, exigido pelo MapReduce, que descrevemos na Seção 25.2.2. Embora seja possível expressar uma análise muito complexa em MR, o usuário deve expressar programas como um processo de uma entrada e dois estágios (mapear e reduzir). Além disso, o MR não oferece métodos para descrever um fluxo de dados complexo, que aplica uma sequência dc transformações na entrada. Não há uma maneira padrão de realizar operações comuns de transformação de dados, como Projeções, Filtragem, Agrupamento e Junção. Vimos todas essas operações sendo expressas declara ri vamen te em SQL nos capítulos 7 e 8. No entanto, existe uma comunidade de usuários e programadores que pensa mais em forma de procedimento. Então os desenvolvedores do Pig inventaram a linguagem Pig Latin para preencher o “ponto ideal” entre SQL e MR. Mostramos um exemplo dc uma consulta Group By simples expressa em Pig Latin cm Olston ct al. (2008):

Existe uma tabela de uris: (uri,categoria,pagerank). Desejamos encontrai; para categorias com um grande número dc URLs, a média dc pagerank dc URLs com pagerank alta nessa categoria. Isso requer um agrupa­ mento de URLs por categoria. A consulta SQL que expressa esse requisito pode ser semelhante a: SELECT categoria, AVG(pagerank) FROM uris WHERE pagerank > 0.2

GROUP BY categoria HAVING COUNT( *)>

6 ** 10

A mesma consulta em Pig Latin é escrita como:

14 Veja Aírati e Ullman (2010). 15 Veja Olston et al. (2008).

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

bons.urls = FILTER uris BY pagerank > 0.2;

grupos = GROUP bons.urls BY categoria; grandes.grupos = FILTER grupos BY COUNT(bons.urls) >10 6; **

resultado = FOREACH grandes.grupos GENERATE categoria, AVG(bons_urls.pagerank);

Como mostrado nesse exemplo, um Pigscript escrito usando a linguagem de script Pig Latin é uma sequência de etapas de transformação de dados. Em cada etapa, é indicada uma transformação básica, como Filter, Group By ou Projection. O script se assemelha a um plano de consulta para a consulta SQL, semelhante aos planos que discutimos no Capítulo 19. A linguagem suporta a operação sobre estruturas de dados aninhadas, como JSON (Java Script Object Notation) e XML. Ele tern uma biblioteca de funções extensa e extensível e também uma capacidade de vincular o esquema aos dados bem mais tarde, ou não vincular de forma alguma. O Pig foi projetado para resolver problemas como análises ad hoc de logs da web e clickstreams. Os logs e os clickstreams geralmente exigem processamento customizado em nível da linha, bem como em nível de agregação. O Pig acomoda funções definidas pelo usuário (UDFs) extensivamente. Ele também suporta um modelo de dados aninhados com os quatro tipos a seguir:

Átomos: valores indivisíveis simples, como um número ou uma cadeia de caracteres. Tuplas: uma sequência de campos, cada um dos quais podendo ter qualquer tipo permitido. Bag: uma coleção de tuplas, com possíveis duplicatas. Map: uma coleção dc itens de dados cm que cada item tem uma chave e que permite o acesso direto a ela. Olston et al. (2008) demonstram aplicações interessantes em logs usando Pig. Um exemplo é a análise de registros de atividades de um mecanismo de busca por qualquer período dc tempo (dia, semana, mês etc.) para calcular a frequência dos termos dc busca pela localização geográfica do usuário. Aqui, as funções necessárias incluem o mapeamento de endereços IP às localizações geográficas e a utilização dc extração de histogramas. Outro aplicativo consiste em agrupar consultas de busca de um período com as de outro período no passado, com base nos termos de busca. Pig foi arquitetado para poder rodar em diferentes ambientes dc execução. Ao implementar Pig, Pig Latin foi compilado em planos físicos que foram traduzidos em uma série de jobs MR e executados no Hadoop. Pig foi uma ferramenta útil para melhorar a produtividade dos programadores no ambiente do Hadoop.

25.4.3 Apache Hive Hive foi desenvolvido no Facebook16 com um propósito semelhante — fornecer uma interface de nível superior para o Hadoop usando consultas semelhantes à SQL e dar suporte ao processamento de consultas analíticas de agregação que são típicas em data warehouses (veja no Capítulo 29). Hive continua sendo uma interface principal para acessar dados em Hadoop no Facebook; ele foi amplamente adotado na comu­ nidade de código aberto e está passando por melhorias contínuas. O Hive foi além do Pig Latin porque ofereceu não apenas uma interface dc linguagem dc alto nível para o Hadoop, mas também uma camada que faz o Hadoop se parecer com um SGBD com DDL, repositório de metadados, acesso por JDBC/ODBC e um compilador de SQL. A arquitetura e os componentes do Hive são mostrados na Figura 25.2.

16 Veja Thusoo et al. (2010).

841

842

Sistemas de banco de dados

HIVE Interface da linha de comandos (CLI)

JDBC

ODBC

Interface Thrift

Mecanismo de Consulta

Analisar—► Compilar-► Otimizar -► Executar

Armazenamento de Metadados

Serviço de Metadados

CLUSTER HADOOP (MAP REDUCE + HDFS)

Figura 25.2 Arquitetura e componentes do sistema Hive.

A Figura 25.2 mostra o Apache Thrift como interface no Hive. O Apache Thrift define uma linguagem de definição de interface (IDL — interface definition language) e um protocolo de comunicação usado para desenvolver serviços remotos. Ele vem com um mecanismo de runtime e geração de código que pode ser usado para desenvolver serviços remotos em muitas linguagens, incluindo Java, C++, Python e Ruby. O Apache Thrift suporta protocolos binários e baseados em JSON; ele suporta transportes H 1'1 P, socket e arquivo. A linguagem de consulta do Hive, HiveQL, inclui um subconjunto da SQL que inclui todos os tipos de junções e operações Group By, bem como funções úteis relacionadas a tipos de dados primitivos e complexos. A seguir, comentamos alguns dos destaques do sistema Hive.

Interface com HDFS: ■ As tabelas no Hive estão vinculadas a diretórios no HDFS. Os usuários podem definir partições dentro de tabelas. Por exemplo, uma tabela de log da web pode ser particionada por dia e, dentro do dia, por hora. Cada nível de partição introduz um nível de diretórios no HDFS. Uma tabela também pode ser armazenada como buckets em um conjunto de colunas. Isso significa que os dados armazenados são particionados fisicamente pela(s) coluna(s). Por exemplo, dentro de um diretório dc hora, os dados podem ser bucketed por Userid; isso significa que os dados de cada hora são armazenados em um conjunto dc arquivos, cada arquivo represen­ tando um bucket de usuários, e o bucket baseia-se no hashing da coluna Userid. Os usuários podem especificar em quantos buckets os dados devem ser divididos. ■ A arquitetura do plug-in SerDe (Serialização/Desserialização) permite que os usuários especifiquem como os dados em formatos de arquivo nativos são expos­ tos como linhas para operadores Hive SQL. O Hive vem com um rico conjunto dc funções SerDe c formatos dc arquivo suportados (por exemplo, CSV, JSON, SequcnceFile); formatos colunares (por exemplo, RCFile, ORCFilc, Parquet); e suporte para o Avro — outro sistema de serialização de dados. Os diferentes StorageHandlers expandem o mecanismo SerDe para permitir o comportamento plugável de como os dados são lidos/gravados e a capacidade de enviar predicados para o StorageHandlcr para realizar uma avaliação antecipada. Por exemplo, o JDBC StorageHandler permite que um usuário do Hive defina uma tabela que está, na verdade, armazenada em algum SGBD relacionai e é acessada usando o protocolo JDBC (veja no Capítulo 10) durante a execução da consulta.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

Suporte de SQL e otimizações no Hive. O Hive incorporou os conceitos de Otimizações Lógicas e Físicas semelhantes aos utilizados na otimização de consultas SQL, que dis­ cutimos nos capítulos 18 e 19. Anteriormente, havia suporte para otimizações lógicas, como a remoção de colunas desnecessárias e o transporte dos predicados de seleção para baixo na árvore de consultas. Também foram incorporadas otimizações físicas da conversão de junções merge-sort em junções do lado do mapeamento, com base nas dicas do usuário e nos tamanhos dos arquivos de dados. O Hive começou com suporte para um subconjunto da SQL-92 que incluía SELECT, JOIN, GROUP BY e filtros com base nas condições da cláusula WHERE. Os usuários podem expressar comandos SQL complexos no Hive. No início de seu desenvolvimento. Hive era capaz de executar as 22 consultas do benchmark TPCH (benchmark do Transaction Processing Performance Council para suporte à decisão), embora com uma reescrita manual considerável. Avanços significativos foram feitos no suporte a linguagens e nas técnicas do otimizador e do runtime. Aqui estão alguns exemplos dessas melhorias:

■ Hive SQL acrescentou muitos recursos analíticos da SQL, como predicados de sub­ consulta, expressões Common Table (essa é a cláusula WITH da SQL que permite aos usuários nomear blocos de subconsultas comuns e referenciá-los várias vezes na consulta; essas expressões podem ser consideradas visões em nível de consulta), agregação em determinada janela nos dados. Rollups (que se referem a níveis de agregação mais altos) e Grouping sets (esse recurso permite expressar vários níveis de agregação em um nível de Group by). Considere, por exemplo, conjunto de agrupamento Group By ((ano, mês), (diadasemana)); isso expressa agregação tanto no nível (Ano, Mês) quanto no DiaDaSemana. Um conjunto completo de tipos de dados SQL, incluindo varchars, tipos numéricos e datas, agora é aceito. O Hive também admite o fluxo ETL comum do Change Data Capture por meio das instruções Insert e Update. Em um data warehouse, o processo de entrega de dimensões que mudam lentamente (por exemplo, clientes em um data warehouse de varejo) exige um fluxo de dados complexo para identificar registros novos e atualizados nessa dimensão. Isso é chamado de processo Change Data Capture (CDC). Adicionando instruções Insert e Update no Hive, é possível modelar e executar processos CDC no Hive SQL. ■ O Hive agora tem um conjunto bastante expandido de DDLs para expressar concessões e privilégios em termos de controle de acesso discricionário (consulte a Seção 30.2). ■ Várias otimizações de banco de dados padrão foram incorporadas, incluindo remoção de partições, rcordenaçâo de junção, reescrita de índice e redução do número de jobs MR. Tabelas muito grandes, como tabelas de fatos cm data warehouses, geralmente são particionadas. O tempo é provavelmente o atributo mais comum usado para particionamento. Com o HDFS sendo usado como camada dc armazenamento, os usuários tendem a reter dados por longos períodos. Mas um warehouse típico incluirá apenas os períodos dc tempo mais atuais (por exemplo, o último trimestre ou o ano atual). Os períodos são especificados como filtros na consulta. A remoção de partição é a técnica de extrair predicados rele­ vantes dos filtros dc consulta c traduzi-los para uma lista dc partições dc tabela que precisam ser lidas. Obviamente, isso tem um enorme impacto no desempenho e na utilização do cluster: em vez de verificar todas as partições retidas nos últi­ mos N anos, apenas as partições das últimas scmanas/mcscs são verificadas. O trabalho em andamento inclui a coleta de estatísticas no nível de coluna e tabela e a geração dc planos com base em um modelo dc custo que usa essas estatísticas (semelhante ao que consideramos para os SGBDRs no Capítulo 19). ■ O Hive agora suporta o Tez como um ambiente de runtime que possui vantagens significativas sobre o MR, incluindo que não há necessidade dc gravar no disco

843

844

Sistemas de banco de dados

entre os jobs; e nào há restrição em processos de uma entrada e dois estágios. Há também um trabalho ativo para suportar o Hive no Spark, uma nova tecnologia que mencionaremos rapidamente na Seção 25.6.

25.4.4 Vantagens da tecnologia Hadoop/MapReduce Hadoop versão 1 foi otimizado para processamento em lote em conjunto de dados muito grandes. Diversos fatores contribuem para o seu sucesso: 1. A taxa de busca de disco é um fator limitante quando lidamos com cargas de trabalho em nível de petabytes. A busca é limitada pela estrutura mecânica do disco, enquanto a taxa de transferência é um recurso eletrônico e aumenta constantemente. (Consulte a Seção 16.2 para ver uma discussão sobre unidades de disco.) O modelo MapReduce de varredura de conjunto de dados em paralelo alivia essa situação. Por exemplo, a varredura de um conjunto de dados de 100 TB sequencialmente usando uma máquina a uma taxa de 50 Mbps levará cerca de 24 dias para ser concluída. Por outro lado, a varredura dos mesmos dados usando 1.000 máquinas em paralelo levará apenas 35 minutos. Hadoop reco­ menda tamanhos de bloco muito grandes, com 64 MB ou mais. Portanto, ao varrer conjuntos dc dados, a porcentagem de tempo gasta nas buscas de disco é insignificante. Taxas de busca de disco ilimitadas combinadas com o processa­ mento de grandes conjuntos de dados em partes e em paralelo é o que impulsiona a escalabilidade e a velocidade do modelo MapReduce.

2. O modelo MapReduce permite o tratamento de dados semiestruturados e con­ juntos de dados chave-valor mais facilmente em comparação com os SGBDRs tradicionais, que exigem um esquema predefinido. Arquivos como arquivos de log muito grandes apresentam um problema específico nos SGBDRs porque precisam ser percorridos de várias maneiras antes de poderem ser analisados. 3. O modelo MapReduce tem escalabilidade linear, na qual os recursos podem ser adicionados para melhorar a latcncia de trabalho e o rendimento dc maneira linear. O modelo de falha é simples e os jobs individuais com falha podem ser executados novamente sem um grande impacto sobre o job inteiro.

25.5 Hadoop v2, também chamado YARN Nas seções anteriores, discutimos o desenvolvimento do Hadoop com detalhes. Nossa discussão incluiu os conceitos fundamentais do paradigma MapReduce para progra­ mação e infraestrutura de armazenamento subjacente do HDFS. Também discutimos interfaces de alto nível, como Pig c Hive, que possibilitam o processamento dc dados de alto nível, semelhantes a SQL, no topo da estrutura do Hadoop. Agora, voltamos nossa atenção para desenvolvimentos subsequentes, que em grande parte são chamados de Hadoop v*2 ou MRv2 ou YARN (yet another resource negotiator). Primeiro, destacamos as deficiências da plataforma Hadoop vl e a lógica e o raciocínio por trás do YARN. 25.5.1 Raciocínio por trás do YARN

Apesar do sucesso do Hadoop vl, a experiência do usuário com ele em aplicações corporativas enfatizou algumas deficiências e sugeriu que poderia ser necessário um upgrade do Hadoop vl: ■ A medida que o tamanho dos clusters e o número de usuários cresceram, o JobTracker tornou-se um gargalo. Ele sempre foi conhecido por ser o ponto dc falha isolado.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

■ Com uma alocação estática de recursos para as funções de mapeamento e redução, a utilização do cluster de nós ficou abaixo do desejável. ■ O HDFS foi considerado como um sistema dc armazenamento simples para dados corporativos. Os usuários queriam executar diferentes tipos de aplicativos que não se encaixariam facilmente no modelo de MR. Os usuários tendiam a contornar essa limitação executando jobs somente de mapeamento, mas isso apenas agravava problemas de escalonamento e utilização. ■ Em grandes clusters, tornou-se problemático acompanhar as novas versões de código aberto do Hadoop, as quais eram lançadas a cada poucos meses. Essas razões explicam a justificativa para o desenvolvimento da versão 2 do Hadoop. Alguns dos pontos mencionados na lista anterior merecem uma discussão mais detalhada, que apresentamos em seguida.

Multilocação: multilocação refere-se a acomodar vários inquilinos/usuários simul­ taneamente para que eles possam compartilhar recursos. A medida que o tamanho dos clusters e o número de usuários aumentavam, várias comunidades de usuários compartilhavam o cluster Hadoop. No Yahoo, a solução original para esse problema foi o Hadoop on Demand, que era baseado no gerenciador de recursos Torque e no escalonador Maui. Os usuários podem configurar um cluster separado para cada job ou conjunto de jobs. Isso teve várias vantagens: ■ Cada cluster pôde executar sua própria versão do Hadoop. ■ As falhas do JobTracker foram isoladas em um único cluster. ■ Cada usuário/organização pôde tomar decisões independentes sobre o tamanho e a configuração de seu cluster, dependendo das cargas de trabalho esperadas. Mas o Yahoo abandonou o Hadoop on Demand pelos seguintes motivos:

■ A alocação dc recursos não era baseada na localidade dos dados. Portanto, a maioria das leituras e gravações do HDFS eram acessos remotos, o que anulou um dos principais benefícios do modelo MR de acessos a dados principalmente locais. ■ A alocação de um cluster era estática. Isso significava que grandes partes de um cluster estavam praticamente ociosas: ■ Dentro de um job MR, os slots de redução não eram utilizáveis durante a fase de mapeamento e os slots de mapeamento não eram utilizáveis durante a fase dc redução. Ao usar linguagens dc mais alto nível, como Pig e Hive, cada script ou consulta gerava vários jobs. Como a alocação de clusters era estática, o máximo de nós necessários em qualquer tarefa precisava ser adquirido antecipadamente. ■ Mesmo com o uso do escalonador Fair ou Capacity (veja nossa discussão na Seção 25.4.2), dividir o cluster em slots fixos de mapeamento e redução significava que o cluster era subutilizado.

■ A latência envolvida na aquisição de um cluster era alta — um cluster só seria concedido quando houvesse um número suficiente dc nós disponíveis. Os usuários começaram a estender a vida útil dos clusters c mantê-los por mais tempo do que precisavam. Isso afetou negativamente a utilização do cluster. Escalabilidade do JobTracker. A medida que os tamanhos de clusters aumenta­ vam para mais de 4.000 nós, problemas com gerenciamento de memória e bloqueio dificultavam o aprimoramento do JobTracker para lidar com a carga de trabalho. Várias opções foram consideradas, como a retenção de dados sobre jobs na memória, limitação do número dc tarefas por job, limitação do número de jobs submetidos por usuário c limitação do número de jobs cm execução simultânea. Nada disso

845

846

Sistemas de banco de dados

parecia satisfazer plenamente todos os usuários; o JobTracker muitas vezes ficava sem memória. Um problema relacionado dizia respeito a jobs concluídos. Os jobs concluídos eram mantidos no JobTracker e ocupavam memória. Muitos esquemas tentaram reduzir o número e a pegada de memória de jobs concluídos. Por fim, uma solução viável foi deixar essa função a cargo de um daemon separado do Job History. A medida que o número dc TaskTrackers crescia, as latências para heartbeats (sinais do TaskTracker para o JobTracker) foram dc quase 200 ms. Isso significava que os intervalos de heartbeat dos TaskTrackers poderíam ser de 40 segundos ou mais quando houvesse mais de 200 rastreadores de tarefas no cluster. Foram feitos esforços para consertar isso, mas acabaram sendo abandonados.

JobTracker: ponto de falha isolado. O modelo de recuperação do Hadoop vl era muito fraco. Uma falha do JobTracker derrubaria todo o cluster. Nesse caso, o estado de execução de jobs foi perdido c todos os jobs precisariam ser reenviados e o JobTracker, reiniciado. Os esforços para fazer com que as informações sobre jobs persistissem não tiveram êxito. Um problema relacionado foi implantar novas ver­ sões do software. Isso exigia o agendamento de um tempo de inatividade do cluster, o que resultava em acúmulo de jobs e uma sobrecarga subsequente no JobTracker na reinicialização. Uso indevido do modelo de programação MapReduce. O runtime do MR não se encaixava bem no processamento iterative; isso foi particularmente verdadeiro para algoritmos de aprendizado de máquina em cargas de trabalho analíticas. Cada iteração é tratada como um job MR. Os algoritmos gráficos são mais bem expressos com o uso de um modelo paralelo síncrono em massa (BSP), que usa a passagem de mensagens, cm oposição às primitivas Map e Reduce. Os usuários contornaram esses impedimentos por meio de alternativas ineficientes, como a implementação de algoritmos de aprendizado de máquina como tarefas apenas de mapeamento de longa duração. Esses tipos de jobs inicialmente liam dados do HDFS e executavam a primeira passada em paralelo; mas depois trocaram dados uns com os outros fora do controle do framework. Além disso, a tolerância a falhas foi perdida. O JobTracker não sabia como esses jobs funcionavam; essa falta de consciência levou à má utilização e instabilidade no cluster. Problemas do modelo de recursos. No Hadoop vl, um nó é dividido em um número fixo de slots de mapeamento e redução. Isso levava à subutilização do cluster, porque os slots inativos não podiam ser usados. Jobs diferentes de MR não podiam ser executados facilmente nos nós porque a capacidade do nó permanecia imprevisível. Os problemas mencionados anteriormente ilustram por que o Hadoop vl preci­ sava dc atualização. Embora tenham sido feitas tentativas para correção de muitos dos problemas listados no Hadoop vl, ficou claro que era necessário um novo projeto. Os objetivos do novo projeto foram definidos da seguinte forma:

■ Levar adiante a conscientização dc escalabilidade e localidade do Hadoop vl. ■ Ter multilocação e alta utilização de cluster. ■ Não ter um ponto de falha isolado e ser altamente disponível. ■ Dar suporte a mais do que apenas jobs MapReduce. Os recursos do cluster não deveriam ser modelados como slots estáticos de mapeamento e redução. ■ Para ser compatível com versões anteriores, os jobs existentes deveriam ser exe­ cutados conforme são atualmente e, possivelmente, sem qualquer recompilação.

O resultado de tudo isso foi o YARN, ou Hadoop v2, que discutimos com deta­ lhes na próxima seção.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

25.5.2 Arquitetura do YARN Visão geraL Depois de apresentar a motivação por trás da atualização do Hadoop vl, vamos agora discutir a arquitetura detalhada da próxima geração do Hadoop, que é popularmente conhecida como MRv2, MapReduce 2.0, Hadoop v2 ou YARN.17 A ideia central do YARN é a separação do gerenciamento de recursos do cluster do gerenciamento de jobs. Além disso, o YARN introduz a noção de um ApplicationMaster, que agora é responsável por gerenciar o trabalho (fluxos de dados de tarefas, ciclos de vida de tarefas, recuperação de falhas nas tarefas etc.). O MapReduce agora está disponível como um serviço/aplicativo fornecido pelo MapReduce ApplicationMaster. As implicações dessas duas decisões são de longo alcance e fundamentais para a noção de um sistema operacional de serviço de dados. A Figura 25.3 mostra um diagrama esqucmático de alto nível do Hadoop vl e do Hadoop v2 lado a lado. O Gerenciador de Recursos (ResourccManager) e o nó por trabalhador NodeManager, juntos, formam a plataforma na qual qualquer aplicação pode ser hospedada no YARN. O Gerenciador de Recursos gerencia o cluster, distribuindo recursos com base em uma política dc escalonamento plugável (como uma política de justiça ou de otimização de utilização do cluster). Ele também é responsável pelo ciclo de vida dos nós no cluster, pois rastreará quando os nós forem desativados, quando eles se tornarem inacessíveis ou quando novos nós se juntarem. Falhas de nó são relatadas aos Application Masters que tinham contêineres no nó que falhou. Novos nós ficam disponíveis para uso por Application Masters. ApplicationMasters enviam ResourccRcquests para o ResourccManager que, em seguida, responde com locações de Container de cluster. Um Container é uma locação feira pelo ResourccManager ao AppIicarionManager para usar determinada quantidade de recursos em um nó do cluster. O ApplicationMaster apresenta um Container Launch Context ao NodeManager para o nó ao qual essa locação faz referencia. O Launch Context, além de conter a locação, também especifica como executar o processo para a tarefa e como obter recursos como jars, libs para o pro­ cesso, variáveis de ambiente e tokens de segurança. Um nó tem um cerro poder de processamento em termos de número de núcleos, memória, largura de banda de rede etc. Atualmente, o YARN considera apenas a memória. Com base em seu poder de processamento, um nó pode ser dividido em um conjunto intercambiável de contêineres. Uma vez que um ApplicationMaster recebe uma locação de contêiner, é livre para escalonar o trabalho da maneira que lhe convier. ApplicationMasters, com base em sua carga de trabalho, podem alterar conrinuamente seus requisitos de

Hadoop v2

Hive

Pig

Map Reduce Tez Application Master I Application Master Gerenciamento de Recursos do YARN

HDFS

Figura 25.3 Esquema comparativo entre Hadoop v! e Hadoop v2.

17 Veja o website do Apache: para documentação atualizada sobre o YARN.

847

848

Sistemas de banco de dados

recursos. O ResourceManager baseia suas decisões de escalonamento apenas nessas solicitações, no estado do cluster e na política de escalonamento de clusters. Ele nào está ciente das tarefas reais que estão sendo executadas nos nós. A responsabilidade por gerenciar e analisar o trabalho real é deixada para os Application Masters. O Mode Manager é responsável por gerenciar contêineres em seus nós. Os contêineres sào responsáveis por relatar a integridade do nó. Também lidam com o proce­ dimento dc junção dos nós ao cluster. Os contêineres fornecem o serviço Container Launch aos ApplicationMasters. Outros serviços disponíveis incluem um cache local, que pode ser em nível de usuário, nível de aplicação ou nível de contêinen Os contêineres também podem ser configurados para fornecer outros serviços para as tarefas executadas neles. Por exemplo, para tarefas MR, o shuffle agora é fornecido como um serviço no nível dc nó. O ApplicationMaster agora é responsável pela execução de tarefas no cluster Com base em seus jobs, os clusters negociam recursos com o ResourceManager. O próprio ApplicationMaster é executado no cluster; no momento da inicialização, um cliente envia uma aplicação ao ResourceManager, que então aloca um contêiner para o ApplicationMaster e o inicia nesse contêiner. No caso do MR, o ApplicationMaster assume a maioria das tarefas do JobTracker: ele inicia as tarefas de mapeamento c redução, toma decisões sobre seu posicionamento, gerencia a recuperação dc falhas das tarefas, mantém contadores semelhantes aos contadores de estado do job e for­ nece uma interface de monitoramento para a execução de jobs. O gerenciamento e a interface de jobs concluídos foram movidos para um Job History Server separado. As vantagens a seguir advêm da separação do gerenciamento dc recursos do gerenciamento de aplicativos na arquitetura YARN: ■ Uma rica diversidade de serviços de dados está disponível para utilizar o cluster. Cada um deles pode expor seu próprio modelo dc programação. ■ Os zXpplicationMasters são livres para negociar recursos em padrões otimizados para seu trabalho: por exemplo, aplicativos de aprendizado de máquina podem manter contêineres por longos períodos. ■ O modelo de Recurso e Contêiner permite que os nós sejam utilizados de maneira dinâmica, o que aumenta a utilização geral do cluster. ■ O ResourceManager faz apenas uma coisa — gerenciar recursos; por isso, é altamente escalável para dezenas de milhares de nós. ■ Com ApplicationMasters gerenciando os jobs, é possível ter várias versões de uma aplicação em execução no cluster. Não há necessidade dc uma atualização de cluster global, o que exigiria a interrupção de todos os jobs.

falha de um ApplicationMaster afeta apenas os trabalhos gerenciados por ele. O ResourceManager fornece algum grau de gerenciamento de ApplicationMasters. Vejamos rapidamente cada um dos componentes do ambiente YARN. ResourceManager (RM). O ResourceManager está preocupado apenas em alo­ car recursos para as aplicações, e não em otimizar o processamento dentro delas. A política de alocação de recursos é plugável. Application Masters devem solicitar recursos que otimizem sua carga dc trabalho. O ResourceManager expõe as seguintes interfaces: 1. Uma API para clientes iniciarem ApplicationMasters.

2. Um protocolo para ApplicationMasters negociarem recursos de cluster 3. Um protocolo para NodeManagers relatarem os recursos do nó c serem geren­ ciados pelo ResourceManager. O escalonador no ResourceManager compara as solicitações de recursos enviadas pelas aplicações com o estado global dos recursos de cluster. A alocação é baseada

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

nas políticas do escalonador plugável (como Capacity ou Fair). Recursos sào solici­ tados por AppIicationMasters como Solicitações de Recursos (Resource Requests). Uma Solicitação de Recurso especifica:

■ O número de contêineres necessários. ■ Os recursos físicos (CPU, memória) necessários por contêiner. ■ As preferências de localidade (nó físico, rack) dos contêineres. ■ A prioridade do pedido para a aplicação.

O cscalonador satisfaz essas solicitações com base no estado do cluster conforme relatado pelos heartbeats do NodeManager. A localidade e a prioridade orientam o escalonador em direção às alternativas: por exemplo, se um nó solicitado estiver ocupado, a próxima melhor alternativa é outro nó no mesmo rack. O escalonador também tem a capacidade de solicitar recursos de volta de uma aplicação, se necessário, e pode até mesmo recuperar os recursos à força. As apli­ cações, ao retornar um contêiner, podem migrar o trabalho para outro contêiner ou criar um checkpoint do estado e restaurá-lo em outro contêiner. É importante ressaltar que o Resource Manager nào é responsável por: manipular a execução de tarefas dentro de uma aplicação, fornecer informações de status sobre as aplicações, fornecer histórico dos jobs concluídos e fornecer qualquer recuperação para as tarefas que falharam. ApplicationMaster (AM). O AppIicationMaster é responsável por coordenar a execução de uma aplicação no cluster. Uma aplicação pode ser um conjunto de processos, como um job MR, ou pode ser um serviço de longa duração, como um cluster Hadoop on Demand (HOD) que atende a vários jobs MR. Isso é deixado para o Application Writer. O ApplicationMaster notificará periodicamente o ResourceManager dc suas solicitações dc recursos atuais por meio de um mecanismo de heartbeat. Os recursos são entregues ao ApplicationMaster como locações de contêineres. Os recursos usados por uma aplicação são dinâmicos: eles são baseados no progresso da apli­ cação e no estado do cluster. Considere um exemplo: o ApplicationMaster MR executando um job MR solicitará um contêiner em cada um dos ni nós cm que reside um InputSplit. Sc obtiver um contêiner em um dos nós, o ApplicationMaster removerá a solicitação de contêineres no restante dos m-1 nós ou, pelo menos, reduzirá sua prioridade. Por outro lado, se a tarefa de mapeamento falhar, é o AM que verifica essa falha e solicita contêineres em outros nós que possuem uma réplica do mesmo InputSplit. NodeManager. Um NodeManager é executado em todos os nós de trabalho do cluster. Ele gerencia contêineres c fornece serviços plugáveis para contêineres. Com base cm uma especificação detalhada do Container Launch Context, um NodeManager pode iniciar um processo em seu nó com o ambiente e os diretórios locais configurados. Ele também monitora para garantir que a utilização de recursos não exceda as especificações. Ele também reporta periodicamente o estado dos con­ têineres e a integridade do nó. Um NodeManager fornece serviços locais para todos os contêineres em execução. O serviço Log Aggregation é usado para encaminhar a saída padrão c o erro padrão dc cada tarefa (stdout c stderr) para o HDFS. Um NodeManager pode ser configurado para executar um conjunto de serviços auxiliares plugáveis. Por exemplo, o MR Shuffle é fornecido como um serviço NodeManager. Um contêiner executando uma tarefa de mapeamento produz a saída do mapeamento e a grava no disco local. A saída é disponibilizada aos Reducers do job por meio do serviço Shuffle cm execução no nó.

Tolerância a falhas e disponibilidade. O RM continua sendo o ponto dc falha isolado no YARN. Na rcinicialização, o RM pode recuperar seu estado a partir de

849

850

Sistemas de banco de dados

um armazenamento persistente. Ele encerra todos os contêineres no duster e reinicia cada ApplicationMaster. Atualmente há um esforço para fornecer um modo ativo/ passivo para RMs. A falha de um ApplicationMaster nào é um evento catastrófico; ela afeta apenas uma aplicação. É responsável por recuperar o estado de sua aplicação.

Por exemplo, o MR ApplicationMaster recuperará sua tarefa concluída e executará novamente todas as tarefas em execução. A falha dc um contcincr por problemas com o nó ou por causa do código do Aplicativo é rastreada pelo framework e reportada ao ApplicationMaster. E de responsabilidade do ApplicationMaster recuperar-se da falha.

25.5.3 Outros frameworks no YARN A arquitetura YARN descrita anteriormente tornou possível que outros fra­ meworks de aplicação sejam desenvolvidos, bem como outros modelos dc progra­ mação sejam admitidos, que podem fornecer serviços adicionais no cluster Hadoop compartilhado. Aqui, listamos alguns dos frameworks que estavam disponíveis no YARN no momento em que este texto foi escrito. Apache Tez. Tez é uma estrutura extensível que está sendo desenvolvida na Hortonworks para criar aplicações de alto desempenho no YARN; essas aplica­ ções manipularão grandes conjuntos de dados, até petabytes. O Tez permite que os usuários expressem seu fluxo dc trabalho como um grafo acíclico direcionado (DAG) de tarefas. Os jobs são modelados como DAGs, em que vértices são tarefas ou operações e arestas representam dependências interoperação ou fluxos de dados. O Tez suporta os padrões de fluxo de dados comuns, como pipeline, scatter-gather e broadcast. Os usuários podem especificar a concorrência em um DAG, bem como as características de recuperação de falhas, como armazenar a saída da tarefa em armazenamento persistente ou recalculá-la. O DAG pode ser alterado em tempo de execução com base no estado do job c do cluster. O modelo DAG é uma escolha mais natural (do que executar como um ou mais jobs MapReduce) para scripts Pig e planos físicos da SQL. Tanto Hive quanto Pig agora fornecem um modo para serem executados no Tez. Ambos se beneficiaram cm termos dc planos mais simples e melhorias dc desempenho significativas. Uma otimização dc desempenho frequentemente citada é o padrão Map-Reduce-Reduce; uma consulta SQL que tenha uma junção seguida por uma Group By normalmente é convertida em dois jobs MR: um para a junção e outro para o Group By. No primeiro estágio MR, a saída da junção será gravada no HDFS e lida de volta na fase de mapeamento do segundo MR para o job Group By. No Tez, essa gravação e leitura extra de/ para o HDFS pode ser evitada fazendo com que o Join Vertex do DAG transmita as linhas resultantes para o vértice Group By.

Apache Giraph. Apache Giraph é a implementação de código aberto do sistema Pregei do Google,1 s que era um sistema de processamento de grafos em grande escala usado para calcular o PageRank. (Veja na Seção 27.7.3 uma definição de PageRank.) O Pregei foi baseado no modelo de computação de processamento síncrono em massa (BSP).18 19 O Giraph adicionou vários recursos ao Pregei, incluindo agregadores fragmentados (sharding, conforme definido no Capítulo 24, refere-se a uma forma dc particionamento) c entrada orientada à aresta. A versão Hadoop vl do Giraph era executada como jobs MR, que se encaixavam muito bem. Ela fazia isso executando jobs apenas de mapeamento de longa duração. No YARN, a implementação Giraph expõe um modelo dc processamento iterative. Giraph é

18 O Pregei é descrito em Malewicz et al. (2010). 19 BSP é um modelo para o projeto de algoritmos paralelos, e foi proposto inicialmente por Valiant (1990).

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

usado atualmente no Facebook para analisar o grafo de usuários da rede social, que tem usuários como nós e suas conexões como arestas; o número atual de usuários é de aproximadamente 1,3 bilhão.

Hoya: HBase no YARN. O projeto Hortonworks Hoya (HBasc no YARN) fornece clusters HBase elásticos em execução no YARN com o objetivo de alcançar maior flexibilidade e melhor utilização do cluster. Na Seção 24.5, discutimos o HBase como um banco de dados não relacionai distribuído de código aberto que gerencia tabelas com bilhões de linhas e milhões de colunas. O HBase é moldado no BigTable do Google,20 mas é implementado usando Hadoop e HDFS. O Hoya está sendo desenvolvido para atender à necessidade de criar clusters HBasc por demanda, possivelmente com diferentes versões do HBasc em execução no mesmo cluster. Cada uma das instâncias do HBasc pode ser configurada individualmente. O Hoya ApplicationMaster inicia o HBase Master localmente. O Hoya AM também solicita ao RM do YARN um conjunto dc contêineres para iniciar o HBase RegionServcrs no cluster. Os RegionServcrs do HBasc são os processos de trabalho do Hbase; cada ColumnFamily (que é como um conjunto de colunas em uma tabela relacionai) é distribuído por um conjunto de RegionServcrs. Isso pode ser usado para iniciar uma ou mais instâncias do HBase no cluster, sob demanda. Os clusters são elásticos e podem crescer ou encolher com base na demanda. Os três exemplos das aplicações desenvolvidas no YARN apresentados devem dar ao leitor uma noção das possibilidades que foram abertas pelo desacoplamento entre Resource Management e /Application Management na arquitetura geral Hadoop/ MapReduce pelo YARN.

25.6 Discussão geral Até agora, discutimos o desenvolvimento da tecnologia big data que ocorreu aproximadamente no período de 2004-2014 e enfatizamos o Hadoop vl e o YARN (também conhecido como Hadoop v2 ou MRv2). Nesta seção, devemos primeiro afirmar o seguinte: há vários projetos em andamento anunciados como código aberto do Apache, bem como em empresas dedicadas ao desenvolvimento de produtos nessa área (por exemplo, Hortonworks, Cloudera, XlapR), além de muitas empresas startup. Da mesma forma, o Amplab da Universidade da Califórnia e outras instituições acadêmicas estão contribuindo fortemente para o desenvolvimento de tecnologia, e não conseguimos abordar todas elas em detalhes. Há também uma série de problemas associados ao conceito de nuvem, como a execução do MapReduce no ambiente de nuvem e data warehousing na nuvem, que não discutimos. Diante desse pano de fundo, agora abordamos alguns tópi­ cos gerais que merecem ser mencionados no contexto das descrições elaboradas que apresentamos até agora neste capítulo. Apresentamos questões relacionadas à disputa entre a abordagem tradicional de aplicativos de alto desempenho em implementações de SGBDR paralelas c tecnologias baseadas cm Hadoop c YARN. Em seguida, apresentamos alguns pontos relacionados à maneira que o big data e as tecnologias de nuvem serão complementares por natureza. Descrevemos os problemas relacionados à localidade dos dados e aos problemas de otimização inerentes às nuvens dc armazenamento e às de computação. Também discutimos o YARN como uma plataforma de serviços de dados e o movimento contínuo para aproveitar big data para fins de análise. Por fim, apresentamos alguns desafios atuais enfrentados por todo o movimento big data.

20 BigTable c descrita em Chang et al. (2006).

851

852

Sistemas de banco de dados

25.6.1 Hadoop/MapReduce e SGBDRs paralelos Uma equipe de especialistas em dados, incluindo Abadi, DeWitt, Madden e Sronebracker, fez um estudo metodológico comparando um par de sistemas de banco de dados paralelos com a versão open source do Hadoop/MR (veja, por exemplo. Pavio et al., 2009). Esses especialistas mediram o desempenho dessas duas abordagens no mesmo benchmark usando um cluster de 100 nós. Eles admitem que o banco de dados paralelo demorou mais para carregar e ajustar em comparação com MR, mas o desempenho de SGBDs paralelos foi “notavelmente melhor". Listamos as áreas que os especialistas compararam no estudo e tentamos mostrar o progresso feito nos SGBDs e no Hadoop desde então.

Desempenho. Em seu artigo. Pavio et al. concluíram que SGBDs paralelos foram de três a seis vezes mais rápidos que MR. O documento lista muitas razões pelas quais os SGBDs tiveram melhor desempenho. Entre as razões apresentadas estão as seguintes: (i) indexação com árvores B *. que agiliza a seleção e a filtragem; (ii) nova orientação de armazenamento (por exemplo, o armazenamento baseado em coluna tem certas vantagens); (iii) técnicas que permitem operações em dados com­ pactados diretamente; e (iv) técnicas de otimização de consultas paralelas comuns em SGBDs paralelos. Desde a época da comparação de Pavio et al., que envolveu a versão 0.19 do Hadoop, grandes avanços foram feitos no runtime do MR, nos formatos de armazenamento e nos recursos de planejamento para escalonamento de job e otimização de fluxos de dados complexos no ecossistema Hadoop. Os formatos de arquivo ORC e Parquet são formatos colunares sofisticados, que possuem as mesmas técnicas de compactação agressiva, a capacidade de enviar predicados para a camada de armazenamento e a capacidade de responder a consultas agregadas sem varrer os dados. Vamos falar rapidamente sobre as melhorias no HDFS e no MR; o Apache Hive fez grandes avanços tanto no tempo de execução quanto nas otimizações baseadas cm custo dc SQLs complexas. Em sua busca por trans­ formar o Hadoop de batch para o modo de consulta interativa e em tempo real, Hortonworks (2014) reporta ganhos de uma ordem de grandeza no desempenho de consultas com um benchmark do tipo TPC-DS (apoio à decisão). O produto Impala da Cloudera, conforme relatado em Cloudera (2014), usa o Parquet (o formato de dados colunares em código aberto) e afirma-se que é executado de forma comparável aos SGBDRs tradicionais.

Vantagem de custo inicial Hadoop manteve sua vantagem de custo. Com poucas exceções, ele continua sendo basicamente uma plataforma de código aberto. YARN, Hive e Spark são todos desenvolvidos como projetos Apache e estão disponíveis como pacotes gratuitos para download. Manipulação de dados não estruturados/semiestruturados. MR lê dados apli­ cando a definição do esquema; isso permite lidar com conjuntos de dados semiestruturados, como documentos CSV, JSON e XML. O processo de carga é relativamente pouco dispendioso para os sistemas Hadoop/MR. No entanto, o suporte para dados não estruturados está definitivamente aumentando nos SGBDRs. O PostgreSQL agora suporta armazenamentos de chave-valor e JSON; a maioria dos SGBDRs tem suporte para XML. Por outro lado, um dos motivos para os ganhos de desempenho no lado do Hadoop tem sido o uso de formatos de dados especializados, como ORC (Optimized Row Columnar) e Parquet (outro formato colunar de código aberto). O último talvez não permaneça uma característica fortemente diíerenciadora entre SGBDRs c sistemas baseados em Hadoop por muito tempo, visto que os SGBDRs também podem incorporar formatos de dados especiais.

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

Suporte para linguagem de mais alto nível SQL era um recurso diferencial que favorecia os SGBDRs para escrever consultas analíticas complexas. No entanto, o Hive incorporou um grande número de recursos SQL no HiveQL, incluindo agrupa­ mento e agregação, bem como subconsultas aninhadas e múltiplas funções que são úteis em data warehouses, como discutimos anteriormente. O Hive 0.13 é capaz de executar cerca de 50 consultas a partir do benchmark TPC-DS sem qualquer reescrita manual. Novas bibliotecas dc funções orientadas a aprendizado dc máquina estão surgindo (por exemplo, a biblioteca de funções em madlib.net suporta SGBDRs tradicionais como o PostgreSql, bem como a distribuição da Pivotal do banco de dados Hadoop — PHD). HAWQ da Pivotal afirma ser o mecanismo SQL paralelo mais recente e mais poderoso, combinando as vantagens de SQL e Hadoop. Além disso, a arquitetura de plugins do YARN que discutimos simplifica o processo dc estender a estrutura com novos componentes e novas funções. Pig e Hive possuem extensibilidade com UDFs (funções definidas pelo usuário). Vários serviços de dados estão agora disponíveis no YARN, como Revolution R e Apache .Mahout para aprendizado de máquina e Giraph para processamento de gráficos. Muitos SGBDs tradicionais agora são executados na plataforma YARN; por exemplo, a plataforma analítica Vortex, da Actian,e BigSQL, 3.0 da IBM.2122 Tolerância a falhas. A tolerância a falhas continua sendo uma vantagem decisiva dos sistemas baseados em MR. O painel de autores em Pavio et al. (2009) também reconheceu que “MR faz um trabalho superior ao minimizar a quantidade de tra­ balho perdido quando ocorre um defeito de hardware". Como apontado por esses autores, essa capacidade tem o custo de materializar arquivos intermediários entre as fases de mapeamento e redução. Mas, à medida que o Hadoop começa a lidar com fluxos dc dados muito complexos (como no Apache Tez) e com a diminuição da necessidade dc latências, os usuários podem compensar desempenho com tolerância a falhas. Por exemplo, no Apache Spark, é possível configurar um RDD (resilient distributed dataset)21 intermediário para ser materializado no disco ou na memória, ou mesmo para ser recalculado a partir de sua entrada. Como podemos ver nesta discussão, mesmo que o MR tenha começado com o objetivo de suportar cargas de trabalho orientadas a batch, ele não conseguia acompanhar os SGBDRs paralelos tradicionais em termos de cargas de trabalho de consulta interativa, conforme exemplificado por Pavio et al. (2009). No entanto, os dois campos se aproximaram muito mais um do outro em capacidade. As forças do mercado, como a necessidade de capital de risco para novas startups, exigem um mecanismo SQL para novos aplicativos que lidam bastante com datasets semies­ truturados muito grandes; e o interesse e envolvimento da comunidade de pesquisa trouxeram melhorias substanciais na capacidade do Hadoop de lidar com cargas de trabalho analíticas tradicionais. Mas ainda há uma recuperação significativa a ser feita em todas as áreas apontadas em Pavio et al. (2009): tempo de execução, planejamento c otimização, e conjuntos de recursos analíticos.

25.6.2 Big data na computação em nuvem O movimento de computação em nuvem e o movimento de big data estão ocorrendo simultaneamente há mais de uma década. Não é possível abordar os detalhes dos problemas de computação em nuvem no contexto atual. No entanto, apresentamos algumas razões convincentes pelas quais a tecnologia de big data é.

21 Veja a apresentação cm para obter uma descrição atual. 22 Veja Zaharia et al. (2012).

853

854

Sistemas de banco de dados

de certa forma, dependente da tecnologia de nuvem, nào apenas para sua expansão posterior, mas também para sua existência continuada. ■ O modelo de nuvem oferece um alto grau de flexibilidade em termos de geren­ ciamento de recursos: “escalabilidade", que se refere à adição de mais nós ou recursos; “ampliação”, que se refere à adição de mais recursos a um nó no sis­ tema; ou mesmo downgrading são facilmente tratados quase instantaneamente. ■ Os recursos são intercambiáveis; esse fato, aliado ao projeto de software distri­ buído, cria um bom ecossistema em que as falhas podem scr facilmente absorvidas e as instâncias dc computação virtual podem ser deixadas imperturbáveis. Pelo custo de algumas centenas de dólares, é possível realizar operações de mineração de dados que envolvem varreduras completas de bancos de dados da ordem de terabytes e rastrear imensos sites da web, que contêm milhões de páginas. ■ Não é incomum que os projetos de big data exibam necessidades imprevisíveis ou de pico de capacidade e armazenamento de computação. Esses projetos enfrentam o desafio dc atender a essa demanda dc pico conforme a necessidade, e não necessariamente de forma contínua. Ao mesmo tempo, as partes interes­ sadas nos negócios esperam produtos e resultados de projeto rápidos, baratos e confiáveis. Para atender a esses requisitos conflitantes, os serviços em nuvem oferecem uma solução ideal. ■ Uma situação comum na qual os serviços de nuvem e big data andam lado a lado é a seguinte: os dados são transferidos para ou coletados em um sistema de armazenamento de dados em nuvem, como o Amazon S3, com o objetivo de coletar arquivos de log ou exportar dados em arquivos de texto formatados. Como alternativa, adaptadores de banco de dados podem ser utilizados para acessar dados de bancos de dados na nuvem. Frameworks de processamento de dados como Pig, Hive e MapReduce, que descrevemos na Seção 25.4, são usados para analisar dados brutos (que podem ter se originado na nuvem). ■ Empresas de projetos de big data e startups se beneficiam muito do uso de um serviço de armazenamento em nuvem. Elas podem negociar gastos de capital para despesas operacionais; este é um excelente negócio, porque não requer dispêndio de capital ou risco. O armazenamento em nuvem fornece soluções dc armazenamento confiáveis c cscalonávcis com uma qualidade que, de outra forma, seria inatingível. ■ Os serviços e recursos em nuvem são distribuídos globalmente. Eles garantem alta disponibilidade e durabilidade inatingíveis pela maioria, exceto as maiores organizações.

0 caso Netflix para o casamento de nuvem e big data.23 Netflix é uma grande organização caracterizada por um modelo de negócios muito lucrativo e um ser­ viço extremamente barato e confiável para os consumidores. A Netflix oferece hoje serviços dc streaming dc vídeo para milhões dc clientes, graças a um sistema de informações e data warehouse altamente eficaz. A empresa usa o Amazon S3 em vez do HDFS como plataforma de processamento e análise de dados por vários motivos. Atualmente, ela usa a distribuição Hadoop Elastic XlapReduce (EMR) da Amazon. A Netflix cita o principal motivo para sua escolha: S3 é projetado para 99,999999999% de durabilidade e 99,99% de disponibilidade de objetos em um determinado ano, e o S3 pode sustentar a perda simultânea de dados em duas instalações. O S3 fornece controle de versão de bucket, o que permite que a Netflix recupere dados apagados inadvertidamente. A elasticidade do S3 permitiu à Netflix uma capacidade de armazenamento praticamente ilimitada; essa capacidade Baseado em .

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

permitiu à empresa ampliar seu armazenamento de algumas centenas de terabytes para petabytes sem qualquer dificuldade ou planejamento prévio. O uso do S3 como data warehouse permite que a Netflix trabalhe com vários clusters do Hadoop que sejam tolerantes a falhas e possam suportar o excesso de carga. Os executivos da Netflix alegam que não têm preocupações sobre a redistribuiçào ou perda de dados durante expansão ou encolhimento do warehouse. Embora os clusters de produção e consulta da Netflix sejam clusters dc longa duração na nuvem, eles podem ser tratados essencialmente como sendo coinpletamcnte transitórios. Se um cluster ficar inativo, a Netflix pode simplesmente substituí-lo por outro cluster de tamanho idêntico, possivelmente em uma zona geográfica diferente, em poucos minutos, sem sustentar qualquer perda de dados.

25.6.3 Problemas de localidade de dados e otimização de recursos para aplicações big data em uma nuvem O crescente interesse pela computação em nuvem, combinado com as demandas da tecnologia big data, significa que os data centers devem ser cada vez mais econô­ micos e voltados para o consumidor. Além disso, muitas infraestruturas cm nuvem não são projetadas de forma intrínseca para lidar com a escala de dados necessária para a análise de dados atual. Os provedores de serviços de nuvem enfrentam desafios assustadores cm termos de gerenciamento de recursos e planejamento de capacidade para fornecer aplicações dc tecnologia de big data. A carga na rede dc muitas aplicações big data, incluindo Hadoop/MapReduce, é uma preocupação especial em um data center pois grandes quantidades de dados podem ser geradas durante a execução do job. Por exemplo, em um job MapReduce, cada tarefa de redução precisa ler a saída de todas as tarefas de mapeamento, e uma explosão repentina de tráfego de rede pode deteriorar significativamente o desempenho da nuvem. Além disso, quando os dados estão localizados em uma infraestrutura (digamos, em uma nuvem de armazenamento como o /Ymazon S3) e processados em uma nuvem de computação (como Amazon EC2), o desempenho do job sofre atrasos significativos em virtude da carga de dados. Projetos de pesquisa propuseram24 uma estrutura de gerenciamento de dados e de máquinas virtuais autoconfigurável, baseada cm localidade, a partir do modelo armazena mento-computação. Essa estrutura permite que os jobs MapReduce acessem a maioria de seus dados localmente ou de nós próximos, incluindo todos os dados de entrada, saída e intermediários gerados durante o mapeamento, e reduzam as fases de mapeamento e redução dos jobs. Esses frameworks categorizam os jobs usando um classificador sensível ao tamanho dc dados cm quatro classes baseadas cm um patamar relativo ao tamanho dos dados. Em seguida, eles provisionam clusters MapReduce virtuais de uma maneira que reconhece a localidade, o que permite o emparelhamento e a alocação eficientes de máquinas virtuais (VMs) MapReduce para reduzir a distância da rede entre nós de armazenamento e computação, para o processamento de mapeamento e redução. Rcccntcmentc,as técnicas dc armazenamento cm cache têm demonstrado melho­ rar o desempenho dc tarefas MapReduce para várias cargas de trabalho.25 O fra­ mework PACXlan fornece suporte para caching na memória, e o sistema MixApart fornece suporte para o caching baseado em disco, quando os dados são armazenados em um servidor dc armazenamento corporativo dentro do mesmo site. As técnicas de

24 Veja Palanisamy et al. (2011). 25 Veja o framework PACMAN de Ananrhanarayanan er al. (2012) e o sistema MixApart de Mihailescu et al. (2013).

855

856

Sistemas de banco de dados

caching permitem flexibilidade em que os dados são armazenados em uma infraes­ trutura de armazenamento separada, que permite a pré-busca e o caching dos dados mais essenciais. Trabalhos recentes26 abordaram o problema do cache de big data no contexto de cenários conscientes da privacidade, em que os dados armazenados em formato criptografado em uma nuvem pública devem ser processados em um site corporativo seguro e separado. Além do problema dc localização dc dados, uma das metas mais desafiadoras para os provedores dc nuvem c otimizar o provisionamento de clusters virtuais para jobs, minimizando o custo geral de consumo do data center em nuvem. Um foco importante da otimização de recursos da nuvem é otimizar global­ mente em rodas as tarefas na nuvem, em oposição às otimizações de recursos por job. Um bom exemplo dc sistema globalmente otimizado gerenciado pela nuvem é o recente sistema Google BigQuery,2 que permite que o Google execute consultas semelhantes à SQL em relação a conjuntos de dados muito grandes, com bilhões de linhas, usando uma interface semelhante ao Excel. No serviço BigQuery, os clientes só enviam as consultas para serem processadas nos grandes datasets, e o sistema em nuvem gerencia dc maneira inteligente os recursos para as consultas, semelhante à SQL. Da mesma forma, o modelo Cura dc otimização dc recursos28 proposto para o MapReduce em uma nuvem permite a otimização global de recursos, minimizando a utilização geral de recursos na nuvem, ao contrário da otimização de recursos por job ou por cliente.

25.6.4 YARN como plataforma de serviço de dados A separação do gerenciamento dc recursos do gerenciamento dc aplicativos levou o Hadoop para outro nível como uma plataforma. O Hadoop vl tinha tudo a ver com o MapReduce. No Hadoop v2, MapReduce é um dos muitos frameworks de aplicação que podem ser executados no cluster. Como discutimos na Seção 25.5, isso abriu a porta para muitos serviços (com seus próprios modelos dc programação) serem fornecidos no YARN. Não há necessidade de traduzir todas as técnicas e algo­ ritmos de processamento de dados em um conjunto de jobs MapReduce. Atualmente, o MapReduce está sendo usado apenas para processamento orientado a batch, como o processo ETL (extract, transform, load — extrair, transformar, carregar) em dara warehouses (veja no Capítulo 29). A tendência emergente é ver o Hadoop como um data lake, em que reside uma parte significativa dos dados da empresa e acontece o processamento.Tradicionalmente, o HDFS tem sido o local onde os dados históricos de uma empresa residem porque ele pode lidar com a escala de tais dados. A maioria das novas fontes de dados, que nos aplicativos de redes sociais e de pesquisa atuais são provenientes de logs da web e da máquina, dados dc fluxo de cliques, dados de mensagens (como no Twitter) e dados dc sensores também estão sendo armazenados em grande parte no HDFS. O modelo Hadoop vl era o modelo de federação: embora o HDFS fosse a camada de armazenamento para a empresa, o processamento era uma mistura de MapReduce e outros mecanismos. Uma alternativa era extrair dados do armazenamento HDFS para os mecanismos em execução fora do cluster em seus próprios silos; esses dados foram movidos para mecanismos gráficos, aplicações analíticas de aprendizado de máquina c assim por diante. As mesmas máquinas usadas para o cluster do Hadoop estavam sendo usadas para aplicativos roralmcnre diferentes, como o processamento

26 Veja Palanisamy et al. (2014a). 27 Para o sistema Google BigQuery, veja . 28 Palanisamy et al. (2014b).

Capítulo 25

Tecnologias Big Data baseadas em MapReduce e Hadoop

de stream fora do Hadoop. Esse cenário estava longe de ser ideal, já que os recursos físicos precisavam ser divididos de maneira estática e era difícil migrar e atualizar para novas versões quando vários frameworks rodavam nas mesmas máquinas. Com o YARN, os problemas citados sâo resolvidos. Os serviços tradicionais estão aproveitando o ResourceManager do YARN e estão fornecendo seus serviços no mesmo cluster Hadoop em que os dados residem. Embora o suporte para SQL no Hadoop tenha sido prometido por vários for­ necedores, o suporte real tem sido menor que completamente desejável. Alguns fornecedores exigiram que os dados do HDFS fossem movidos para outro banco de dados para executar a SQL; alguns exigiram “wrappers" para ler os dados do HDFS antes de uma consulta SQL ser executada. Uma nova tendência entre SGBDRs e sistemas de bancos de dados tradicionais considera um cluster YARN como uma plataforma viável. Um exemplo é a plataforma de análise do Actian, que fornece SQL no Hadoop e que é considerada uma implementação SQL completa e robusta usando o banco de dados colunar Actian Vectorwise (que é executado como uma aplicação YARN). O Big SQL 3.029 da IBM é um projeto que faz com que um SGBD nada compartilhado da IBM seja executado em um duster YARN. O Apache Storm é um mecanismo de streaming cscalávcl distribuído que permite aos usuários processar feeds dc dados cm tempo real. E amplamente utilizado pelo Twitter Storm no YARN () e SAS no YARN () são aplicações que tratam Storm (uma apli­ cação dc processamento dc fluxo distribuído) c SAS (software dc análise estatística) como aplicações na plataforma YARN. Como já dissemos, Giraph c HBasc Hoya são esforços contínuos que estão adotando rapidamente o YARN. Uma ampla varie­ dade de sistemas de aplicativos usa o cluster Hadoop para armazenamento; alguns exemplos incluem serviços como streaming, aprendizado de máquina/estarística, processamento de grafos, OLAP e armazenamentos de chave-valor. Esses serviços vão muito além do MapReduce. O objetivo/promessa do YARN é que esses serviços coexistam no mesmo cluster c tirem vantagem da localidade dos dados no HDFS, enquanto o YARN orquestra o uso dos recursos do cluster.

25.6.5 Desafios enfrentados por tecnologias big data Em um artigo recente,30 vários especialistas em banco de dados expressaram suas preocupações sobre os desafios iminentes enfrentados pelas tecnologias big data quando estas são usadas principalmente para aplicações analíticas. Essas preo­ cupações incluem o seguinte: ■ Heterogeneidade de informações: a heterogeneidade em termos de tipos de dados, formatos de dados, representação de dados e semântica é inevitável quando se trata dc fontes dc dados. Uma das fases do ciclo dc vida do big data envolve a integração desses dados. O custo de fazer um trabalho limpo de integração para reunir todos os dados em uma única estrutura é proibitivo para a maioria das aplicações, como saúde, energia, transporte, planejamento urbano e modelagem ambiental. A maioria dos algoritmos dc aprendizado dc máquina espera que os dados sejam alimentados cm uma estrutura uniforme. A provcniência dc dados (que sc refere às informações sobre a origem e a propriedade dos dados) normalmente não é mantida na maioria dos aplicativos analíticos. A interpretação adequada dos resultados da análise de dados requer grandes quantidades de metadados.

29 A documentação atual w-325p230-azubirigrayatv4>. 50 Veja Jagadish et al. (2014).

está

disponível

em

(

SELECT Salario FROM FUNCIONÁRIO

WHERE Cpf = NEW Cpf.supervisor )) informar.supervisor (NEW Cpf.supervisor, NEW.Cpf);

As quatro triggers (regras ativas) R1, R2, R3 e R4 ilustram uma série de recursos das regras ativas. Primeiro, os eventos básicos que podem ser especificados para disparar as regras são os comandos dc atualização da SQL padrão: INSERT, DELETE e UPDATE. Eles são especificados pelas palavras-chave INSERT, DELETE e UPDATE na notação Oracle. No caso de UPDATE, podem-se especificar os atributos a serem atualizados — por exemplo, ao escrever UPDATE OF Salario, Numero.departamento. Segundo, o projetista da regra precisa ter um modo de se referir às tuplas inseridas, excluídas ou modificadas pelo evento de disparo. As palavras-chave NEW e OLD são empregadas na notação Oracle; NEW é utilizada para se referir a uma tupla recém-inserida ou recém-atualizada, enquanto OLD é usada para se referir a uma tupla excluída ou a uma tupla antes que ela seja atualizada. Assim, a regra R1 c disparada após uma operação INSERT scr aplicada à relação FUNCIONÁRIO. Em R1 ,a condição (NEW.Numero.departamento IS NOT NULL) é verificada c, se for avaliada como verdadeira, significando que a tupla dc funcionário rcccm-inserida está relacionada a um departamento, então a ação é executada. A ação atualiza a(s) nipla(s) de DEPARTAMENTO relacionada(s) ao funcionário recém-inserido, acrescentando seu salário (NEW.Salario) ao atributo Salario.total dc seu departamento relacionado.

notação do Oracle, (a) Triggers

de DEPARTAMENTO, (b) Trigger para comparar o salário

de um funcionário com o de seu supervisor.

872

Sistemas de banco de dados

A regra R2 é semelhante à R1, mas é disparada por uma operação UPDATE que atualiza o SALARIO de um funcionário, em vez de por um INSERT. A regra R3 é dispa­ rada por uma atualização no atributo Numero.departamento de FUNCIONÁRIO, o que significa alterar a designação de um funcionário de um departamento para outro. Não existe condição a verificar em R3, de modo que a ação é executada sempre que o evento de disparo ocorre. A ação atualiza tanto o departamento antigo quanto o novo dos funcionários redesignados, somando seu salário a Salario.total de seu novo departamento e subtraindo seu salário do Salario.total dc seu antigo departamento. Observe que isso deve funcionar mesmo que o valor de Numero.departamento seja NULL, pois nesse caso nenhum departamento será selecionado para a ação da regra.5 É importante notar o efeito da cláusula FOR EACH ROW, que significa que a regra é disparada separadamente para cada tupla. Isso é conhecido como uma trigger dc nível de linha. Se essa cláusula fosse omitida, a trigger seria conhecida como uma trigger em nível de sentença, e seria disparada uma vez para cada comando de dis­ paro. Para ver a diferença, considere a seguinte operação de atualização, que gera um aumento de 10% para todos os funcionários designados para o departamento 5. Essa operação seria um evento que dispara a regra R2:

UPDATE FUNCIONÁRIO SET Salario = 1,1 * Salario WHERE Numero.departamento = 5;

Como o comando anterior poderia atualizar vários registros, uma regra que usa a semântica em nível de linha, como R2 na Figura 26.2, seria disparada unia vez para cada linha, ao passo que uma regra que utiliza a semântica em nível de sentença é disparada apenas uma vez. O sistema Oracle permite que o usuário escolha qual dessas opções deve scr usada para cada regra. A inclusão da cláusula opcional FOR EACH ROW cria uma trigger em nível dc linha, e omiti-la cria uma trigger em nível de sentença. Observe que as palavras-chave NEW e OLD só podem ser utilizadas com triggers em nível de linha. Como um segundo exemplo, suponha que queiramos verificar sempre se o salário de um funcionário é maior que o salário de seu supervisor direto. Vários eventos podem disparar essa regra: inserir um novo funcionário, alterar o salário dc um funcionário ou alterar o supervisor dc um funcionário. Suponha que a ação a tomar seja chamar um procedimento externo informa r.supervisor,6 que notificará o supervisor. A regra poderia, então, ser escrita como em R5 [ver Figura 26.2(b)]. A Figura 26.3 mostra a sintaxe para especificar algumas das principais opções disponíveis nas triggers do Oracle. Na Seção 26.1.5, descreveremos a sintaxe para as triggers no padrão SQL-99. Figura 26.3 Um resumo de

sintaxe para especificar triggers no sistema Oracle (apenas

opções principais).

::= CREATE TRIGGER cnome trigger> (AFTER I BEFORE ) ceventos disparo ON cnome tabela> | FOR EACH ROW ] [ WHEN econdição) cacoes trigger> ; ceventos disparo ::= cevento trigger> {OR cevento trigger> ) cevento trigger > ::= INSERT I DELETE I UPDATE [ OF cnome coluna> {, cnome coluna> } 1 c acoes trigger > ::= ebloco PL/SQL>

5 R1, R2 e R4 também podem ser escritas sem uma condição. Porém, pode ser mais eficiente executá-las com a condição, pois a ação não c chamada, a menos que seja exigida. 6 Considerando que um procedimento externo apropriado tenha sido declarado. Esse é um recurso que está disponível na SQL-99 e em padrões posteriores.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

26.1.2 Questões de projeto e implementação para bancos de dados ativos A seção anterior forneceu uma visão geral de alguns dos principais conceitos para especificar regras ativas. Nesta seção, discutimos algumas questões adicionais referen­ tes à forma como as regras são projetadas e implementadas. A primeira questão está relacionada à ativação, desativação e agrupamento de regras. Além de criar regras, um sistema de banco de dados ativo deve permitir que os usuários ativem., desativem e removam regras ao referir-se a seus nomes de regra. Uma regra desativada não será disparada pelo evento de disparo. Esse recurso permite que os usuários seletivamente desativem regras por certos períodos quando elas não forem necessárias. O comando de ativação tomará a regra ativa novamente. O comando de remoção exclui a regra do sistema. Outra opção é agrupar as regras em conjuntos de regras nomeados, de modo que o conjunto inteiro de regras possa ser ativado, desativado ou removido. Também é útil ter um comando que possa disparar uma regra ou conjunto de regras por meio de um comando PROCESS RULES explícito, emitido pelo usuário. A segunda questão diz respeito a se a ação disparada deve ser executada antes, depois, no lugar de ou juntamente com o evento de disparo. Uma trigger before executa a trigger antes de executar o evento que a causou. Ela pode ser usada em aplicações como a verificação de violações de restrição. Uma trigger after executa a trigger depois de executar o evento, e pode ser usada em aplicações como a manu­ tenção de dados derivados e o monitoramento de eventos e condições específicas. Uma trigger instead of executa a trigger em vez de executar o evento, e pode ser utilizada cm aplicações como executar atualizações correspondentes sobre relações básicas em resposta a um evento que é uma atualização de uma visão. Uma questão relacionada é se a ação que está sendo executada deve ser conside­ rada como uma transação separada ou se deve fazer parte da mesma transação que disparou a regra. Tentaremos categorizar as diversas opções. É importante observar

que nem todas as opções podem estar disponíveis para determinado sistema de banco de dados ativo. De fato, a maioria dos sistemas comerciais é limitada a uma ou duas das opções que discutiremos cm seguida. Vamos supor que o evento de disparo ocorra como parte da execução de uma transação. Devemos considerar primeiro as diversas opções de como o evento de disparo está relacionado à avaliação da condição da regra. A avaliação de condição da regra também é conhecida como consideração da regra, pois a ação deve ser executada somente depois de considerar se a condição é avaliada como verdadeira ou falsa. Existem três possibilidades principais para a consideração da regra: 1. Consideração imediata. A condição é avaliada como parte da mesma transação que o evento de disparo, e é avaliada imediatamente. Este caso pode ser catego­ rizado ainda cm três opções: ■ Avaliar a condição antes de executar o evento de disparo. ■ Avaliar a condição depois de executar o evento de disparo. ■ Avaliar a condição em vez de executar o evento de disparo.

2. Consideração adiada. A condição é avaliada ao final da transação que incluiu o evento de disparo. Neste caso, pode haver muitas regras disparadas esperando para ter suas condições avaliadas. 3. Consideração separada. A condição é avaliada como uma transação separada, gerada com base na transação de disparo. O próximo conjunto de opções refere-se ao relacionamento entre a avaliação da condição de regra c a execução da ação da regra. Aqui, novamente, três opções são possíveis: execução imediata, adiada ou separada. A maioria dos sistemas ativos

873

874

Sistemas de banco de dados

utiliza a primeira opção. Ou seja, assim que a condição é avaliada, se ela retornar verdadeiro, a ação é executada hnediatamente. O sistema Oracle (ver Seção 26.1.1) utiliza o modelo de consideração imediata, mas permite que o usuário especifique para cada regra se a opção before ou after deve ser usada com a avaliação de condição imediata. Ele também usa o modelo de execução imediata. O sistema STARBURST (ver Seção 26.1.3) tem a opção de consideração adiada, significando que todas as regras disparadas por uma transa­ ção esperam até que a transação de disparo alcance seu fim e emita seu comando COMMIT WORK antes que as condições da regra sejam avaliadas. Outra questão referente a regras de banco de dados ativo é a distinção entre regras em nível de linha e regras em nível de sentença. Como as instruções de atualização SQL (que atuam como eventos de disparo) podem especificar um conjunto de tuplas, é preciso distinguir se a regra deve ser considerada uma vez para o comando inteiro ou se deve ser considerada separadamente para cada linha (ou seja, tupla) afetada pelo comando. O padrão SQL-99 (ver Seção 26.1.5) e o sistema Oracle (ver Seção 26.1.1) permitem que o usuário escolha qual das opções deve ser usada para cada regra, enquanto o STARBURST utiliza apenas a semântica em nível de comando. Daremos exemplos de como as triggers em nível dc sentença podem ser especificadas na Seção 26.1.3. Uma das dificuldades que podem ter limitado o uso generalizado de regras ativas, apesar dc seu potencial para simplificar o desenvolvimento de banco dc dados e software, é que não existem técnicas de fácil utilização para projetar, escrever e verifi­ car regras. Por exemplo, é muito difícil verificar se um conjunto de regras é consistente, significando que duas ou mais regras no conjunto não contradizem uma à outra. É difícil garantir o término de um conjunto de regras sob todas as circunstâncias. Para ilustrar o problema do término resumidamente, considere as regras da Figura 26.4. Aqui, a regra R1 é disparada por um evento INSERT na TABELA1, e sua ação inclui um evento de atualização em Atributol de TABELA2. Porém, o evento de disparo da regra R2 é um evento UPDATE em Atributol de TABELA2, e sua ação inclui um evento INSERT na TABELA1. Nesse exemplo, é fácil ver que essas duas regras podem disparar uma à outra indefinidamente, levando a um ciclo sem fim. Contudo, se dezenas de regras forem escritas, é muito difícil determinar se o término é garantido ou não. Se as regras ativas tiverem de alcançar seu potencial, é necessário desenvolver ferramentas para o projeto, depuração e monitoramento de regras ativas que possam ajudar os usuários a projetar e a depurar suas regras. Figura 26.4 Um exemplo para

R1: CREATE TRIGGER T1

ilustrar o problema de término

AFTER INSERT ON TABELA 1

para regras ativas.

FOR EACH ROW UPDATE TABELA2

SET Atributol = ...;

R2: CREATE TRIGGER T2

AFTER UPDATE OF Atributol ON TABELA2 FOR EACH ROW INSERT INTO TABELA 1 VALUES ( ...);

26.1.3 Exemplos de regras ativas em nível de sentença no STARBURST Agora, oferecemos alguns exemplos para ilustrar como as regras podem ser especificadas no SGBD experimental STARBURST. Isso nos permitirá demonstrar como as regras em nível de sentença podem ser escritas, pois estes são os únicos tipos de regras permitidas no STARBURST.

7 O STARBURST também permite que o usuário inicie a consideração da regra explicita mente por meio do comando PROCESS RULES.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

875

As três regras ativas R1S, R2S e R3S da Figura 26.5 correspondem às três primei­ ras regras da Figura 26.2, mas elas usam a notação do STARBURST e a semântica em nível de sentença. Podemos explicar a estrutura da regra com a regra R1S. O comando CREATE RULE especifica um nome de regra — Salario_total1 para R1S. A cláusula ON especifica a relação na qual a regra é especificada — FUNCIONÁRIO para R1S. A cláusula WHEN é usada para especificar os eventos que disparam a regra.8 A cláusula IF opcional é utilizada para especificar quaisquer condições que precisam ser verificadas. Finalmente, usa-se a cláusula THEN para especificar as ações a serem tomadas, que normalmente são um ou mais comandos SQL. No STARBURST, os eventos básicos que podem ser especificados para disparar as regras são os comandos de atualização SQL padrão: INSERT, DELETE e UPDATE. R1S:

CREATE RULE Salario.total 1 ON FUNCIONÁRIO

Figura 26.5 Regras ativas

WHEN

usando semântica em nível

IF

INSERTED EXISTS

( SELECT * FROM INSERTED WHERE Numero.departamento IS NOT NULL)

THEN

UPDATE

SET

DEPARTAMENTO AS D

D. Salario.total = D. Salario.total +

( SELECT SUM (1.Salario) FROM INSERTED AS 1 WHERE D.Numero.departamento = 1. Numero.departamento) WHERE

D.Numero.departamento IN ( SELECT Numero. departamento FROM INSERTED);

R2S:

CREATE RULE Salario total2 ON FUNCIONÁRIO WHEN IF

UPDATED

EXISTS

(

Salario)

( SELECT * FROM NEW-UPDATED WHERE Numero.departamento IS NOT NULL)

OR EXISTS!SELECT * FROM OLD-UPDATED

WHERE Numero.departamento IS NOT NULL)

THEN

UPDATE SET

DEPARTAMENTO AS D

D. Salario.total = D. Salario.total +

( SELECT SUM (N.Salario) FROM NEW-UPDATED AS N WHERE D.Numero.departamento = N.Numero.departamento) -

( SELECT SUM (O.Salario) FROM OLD-UPDATED AS 0 WHERE D.Numero.departamento = O.Numero.

departamento)

WHERE

D.Numero.departamento IN (SELECT Numero.departamento FROM NEW-UPDATED) OR

D.Numero.departamento IN ( SELECT Numero,

departamento FROM OLD-UPDATED); R3S:

CREATE RULE Salario_total3 ON FUNCIONÁRIO WHEN THEN

UPDATED UPDATE

SET

(

Numero.departamento)

DEPARTAMENTO AS D

D. Salario.total = D. Salario.total +

( SELECT SUM (N.Salario) FROM NEW-UPDATED AS N WHERE D.Numero.departamento = N. Numero.departamento)

WHERE

D.Numero.departamento IN ( SELECT Numero, departamento FROM NEW-UPDATED );

UPDATE

SET

DEPARTAMENTO AS D

D.Salario.total = D.Salario.total -

( SELECT SUM (O.Salario) FROM OLD-UPDATED AS 0 WHERE D.Numero.departamento = 0.Numero.departamento )

WHERE

D. Numero.departamento IN (SELECT Numero, departamento FROM OLD-UPDATED);

1 Observe que a palavra-chave WHEN especifica eventos no STARBURST, mas serve para especificar a regra condição em SQL e triggers Oracle.

de sentença na notação do STARBURST

876

Sistemas de banco de dados

Estes são especificados pelas palavras-chave INSERTED, DELETED e UPDATED na notação do STARBURST. Segundo, o projetista de regra precisa ter um modo de referenciar as tuplas que foram modificadas. As palavras-chave INSERTED, DELETED, NEW-UPDATED e OLD-UPDATED são empregadas na notação do STARBURST para se referirem a quatro tabelas de transição (relações) que incluem as tuplas recém-inseridas, as tuplas excluídas, as tuplas atualizadas antes que fossem atualizadas e as tuplas atualizadas depois que foram atualizadas, respectivamente. Obviamente, dependendo dos eventos de disparo, somente algumas dessas tabelas de transição podem estar disponíveis. O escritor da regra pode se referir a essas tabelas ao escrever suas partes de condição e ação. As tabelas de transição contêm tuplas do mesmo tipo que aquelas na relação especificada na cláusula ON da regra — para R1S, R2S e R3S, esta é a relação FUNCIONÁRIO. Na semântica em nível de sentença, o projetista da regra só pode se referir às tabelas de transição como um todo, e a regra é disparada apenas uma vez, de modo que as regras precisam ser escritas de forma diferente daquela para a semântica em nível de linha. Como várias tuplas de funcionários podem ser inseridas em um único comando de inserção, temos de verificar se pelo menos uma das tuplas de funcionário recém-inseridas está relacionada a um departamento. Em R1S, a condição

EXISTS (SELECT * FROM INSERTED WHERE Numero.departamerito IS NOT NULL) é verificada e, se for avaliada como verdadeiro, a ação é executada. A ação atualiza em um único comando as tuplas de DEPARTAMENTO relacionadas aos funcionários recém-inseridos ao acrescentar seus salários ao atributo Salario_total de cada depar­ tamento relacionado. Como mais de um funcionário recém-inserido pode pertencer ao mesmo departamento, usamos a função de agregação SUM para garantir que todos os seus salários sejam atualizados. A regra R2S é semelhante à R1S, mas c disparada por uma operação UPDATE que atualiza o salário de um ou mais funcionários, em vez de um INSERT. A regra R3S é disparada por uma atualização no atributo Numero_departamento de FUNCIONÁRIO, que significa alterar a designação de um ou mais funcionários de um departamento para outro. Não existe condição em R3S, de modo que a ação é executada sempre que o evento de disparo ocorre.9 A ação atualiza tanto o(s) departamento(s) antigo(s) quanto o(s) departamento(s) novo(s) dos funcionários redesignados, somando seu salário a Salario_total de cada departamento novo e subtraindo-o de Salario_total de cada departamento antigo. Em nosso exemplo, é mais complexo escrever as regras em nível de sentença que cm nível de linha, como pode ser ilustrado ao se comparar as figuras 26.2 e 26.5. No entanto, essa não c uma regra, e outros tipos de regras ativas podem ser mais fáceis de especificar quando se usa a notação em nível de sentença do que quando se usa a notação em nível de linha. O modelo de execução para regras ativas no STARBURST usa a consideração adiada. Ou seja, todas as regras disparadas em uma transação são colocadas em um conjunto — chamado conjunto de conflito — que não é considerado para a avalia­ ção de condições e execução até que a transação termine (emitindo seu comando COMMIT WORK). O STARBURST também permite que o usuário inicie explicita­ mente a consideração da regra no meio de uma transação por meio de um comando PROCESS RULES explícito. Como várias regras precisam ser avaliadas, é necessário especificar uma ordem entre as regras. A sintaxe para a declaração da regra no STARBURST permite a especificação da ordenação entre as regras para instruir o ’ Assim como nos exemplos do Oracle, as regras RIS c R2S podem ser escritas sem uma condição. Porém, pode ser mais eficiente executá-las com a condição, já que a ação não é chamada a menos que seja exigida.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

sistema sobre a ordem em que um conjunto de regras deve ser considerado.10 Além disso, as tabelas de transição — INSERTED, DELETED, NEW-UPDATED e OLD-UPDATED — contêm o efeito de entrelaçamento (net effect) de todas as operações na transação que afetaram cada tabela, pois múltiplas operações podem ter sido aplicadas a cada tabela durante a transação.

26.1.4 Aplicações em potencial para bancos de dados ativos Agora, discutimos rapidamente algumas das aplicações em potencial das regras ati­ vas. Obviamente, uma aplicação importante c permitir a notificação dc certas condições que ocorrem. Por exemplo, um banco de dados ativo pode ser usado para monitorar, digamos, a temperatura de uma fornalha industrial. A aplicação pode inserir periodi­ camente no banco dc dados os registros dc leitura de temperatura vindos diretamente dos sensores de temperatura, c regras ativas podem scr escritas, que são disparadas sempre que um registro dc temperatura for inserido, com uma condição que verifica se a temperatura excede o nível de perigo e resulta na ação para disparar um alarme. As regras ativas também podem ser usadas para impor restrições de integridade ao especificar os tipos de eventos que podem fazer que as restrições sejam violadas e, depois, avaliar condições apropriadas que verificam se as restrições são realmente violadas pelo evento ou não. Logo, restrições complexas da aplicação, normalmcntc conhecidas como regras de negócios, podem ser impostas dessa forma. Por exemplo, na aplicação de banco de dados UNIVERSIDADE, uma regra pode monitorar a média dos alunos sempre que uma nova nota for inserida, e pode alertar o orientador se a média dc um aluno ficar abaixo de certo patamar. Outra regra pode verificar se os pré-requisitos da disciplina são satisfeitos antes de permitir que um aluno matricule-se em uma disciplina; e assim por diante. Outras aplicações incluem a manutenção automática de dados derivados, como os exemplos das regras de Rl a R4 que mantêm o atributo derivado Salario.total sempre que tuplas de funcionário individual são modificadas. Uma aplicação seme­ lhante é usar regras ativas para manter a consistência dc visões materializadas (ver Seção 5.3) sempre que as relações básicas são modificadas. Como alternativa, uma operação de atualização especificada em uma visão pode ser um evento de disparo, que pode ser convertido para atualizações nas relações básicas ao usar uma trigger instead of. Essas aplicações também são relevantes para as novas tecnologias de data warehousing (ver Capítulo 29). Uma aplicação relacionada mantém que tabelas replicadas são consistentes ao especificar regras que modificam as réplicas sempre que a tabela mestre é modificada.

26.1.5 Triggers na SQL-99 As triggers na SQL-99 e padrões posteriores são muito semelhantes aos exemplos que discutimos na Seção 26.1.1, com algumas pequenas diferenças sintáticas. Os eventos básicos que podem scr especificados para disparar as regras são os comandos de atualização SQL padrão: INSERT, DELETE e UPDATE. No caso de UPDATE, podem-se especificar os atributos a serem atualizados. Tanto as triggers em nível de linha quanto em nível de comando são permitidas, indicadas na trigger pelas cláusulas FOR EACH ROW e FOR EACH STATEMENT, respectivamente. Uma diferença sintática é que a trigger pode especificar nomes de variável de tupla cm particular para as tuplas antiga e nova em vez de usar as palavras-chave NEW e OLD, como mostrado na Figura 26.2. trigger TI da Figura 26.6 mostra como a trigger em nível de linha R2 10 Se nenhuma ordem for especificada enrre um par de regras a ordem default do sistema é baseada na colocação da regra declarada primeiro, antes da outra regra.

877

878

Sistemas de banco de dados

Figura 26.6 Trigger T1

T1: CREATE TRIGGER Salario_total1

ilustrando a sintaxe para definir

AFTER UPDATE OF Salario ON FUNCIONÁRIO

triggers na SQL-99.

REFERENCING OLD ROW AS 0, NEW ROW AS N

FOR EACH ROW

WHEN ( N.NumerO-departamento IS NOT NULL) UPDATE DEPARTAMENTO SET Salario-total = Salario_total + N.Salario - O.Salario

WHERE Numero_departamento = N.Numero_departamento; T2: CREATE TRIGGER Salario_total2

AFTER UPDATE OF Salario ON FUNCIONÁRIO REFERENCING OLD TABLE AS 0, NEW TABLE AS N

FOR EACH STATEMENT

WHEN

EXISTS

( SELECT * FROM N WHERE N.Numero_departamento IS NOT

EXISTS

( SELECT ’ FROM 0 WHERE O.Numero_departamento IS NOT

NULL) OR NULL) UPDATE DEPARTAMENTO AS D SET D.SalariO-total = D.Salario_total

+(

SELECT SUM (N.Salario) FROM N

WHERE D.Numero_departamento=N.Numero_departamento) -(

SELECT SUM (O.Salario) FROM 0

WHERE D.Numero_departamento=O.Numero_departamento) WHERE NumerO-departamento IN (( SELECT Numero.departamento FROM N)

UNION (SELECT Numero.departamento FROM O));

da Figura 26.2(a) pode ser especificada na SQL-99. Dentro da cláusula REFERENCING, nomeamos variáveis de tupla (apelidos) O e N para nos referirmos à tupla OLD (antes da modificação) e à tupla NEW (após a modificação), respectiva men te. A trigger T2 da Figura 26.6 mostra como a trigger em nível de sentença R2S da Figura 26.5 pode ser especificada na SQL-99. Para uma trigger em nível de sentença, a cláusula REFERENCING é usada para se referir à tabela de todas as tuplas novas (recém-inseridas ou recém-atualizadas) como N, enquanto a tabela de todas as tuplas antigas (tuplas excluídas ou tuplas antes que sejam atualizadas) é referenciada como 0.

26.2 Conceitos de banco de dados temporal Bancos de dados temporais, no sentido mais amplo, abrangem todas as aplicações de banco de dados que exigem algum aspecto de tempo quando organizam suas infor­ mações. Logo, eles oferecem um bom exemplo para ilustrar a necessidade de desen­ volver um conjunto de conceitos de unificação para os desenvolvedores de aplicação usarem. Aplicações de banco de dados temporal têm sido desenvolvidas desde o início do uso do banco de dados. Porém, na criação dessas aplicações, fica principalmente a cargo dos projetistas e desenvolvedores de aplicação descobrir, projetar, programar e implementar os conceitos temporais de que eles necessitam. Existem muitos exemplos de aplicações em que algum aspecto de tempo é necessário para manter as informa­ ções em um banco de dados. Entre eles estão a área de saúde, em que históricos de pacientes precisam ser mantidos; seguro, em que históricos de reivindicações e sinis­ tros são necessários, bem como informações sobre as datas em que as apólices estão em vigor; sistemas de reservas em geral (hotéis, companhias aéreas, aluguel de carros etc.), em que informações sobre datas e horários das reservas são necessárias; bancos de dados científicos, em que os dados coletados de experimentos incluem o horário em que cada dado é medido; e assim por diante. Até mesmo os dois exemplos usados neste livro podem ser facilmente expandidos para aplicações temporais. No banco de dados EMPRESA, podemos querer manter históricos de SALARIO, CARGO e PROJETO

Capítulo 26 Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos 879

sobre cada funcionário. No banco de dados UNIVERSIDADE, a dimensão de tempo já está incluída em SEMESTRE e ANO de cada TURMA de uma DISCIPLINA, o histórico dc notas de um ALUNO e as informações sobre concessões de pesquisa. De fato, é correto concluir que a maioria das aplicações de banco de dados possui alguma informação temporal. Porém, os usuários normalmente tentam simplificar ou ignorar os aspectos temporais por causa da complexidade que eles acrescentam às suas aplicações. Nesta seção, apresentaremos alguns dos conceitos desenvolvidos para lidar com a complexidade das aplicações dc bancos dc dados temporais. A Seção 26.2.1 contem uma visão geral de como o tempo é representado nos bancos de dados, os diferentes tipos de informações temporais e algumas das diferentes dimensões do tempo que podem ser necessárias. A Seção 26.2.2 discute como o tempo pode ser incorporado nos bancos dc dados relacionais. A Seção 26.2.3 oferece algumas opções adicionais para representar o tempo, possíveis nos modelos de banco de dados que permitem objetos estruturados complexos, como bancos de dados de objeto. A Seção 26.2.4 introduz operações para consulta de bancos de dados temporais e oferece uma breve visão geral da linguagem TSQL2, que estende a SQL com conceitos temporais. A Seção 26.2.5 focaliza os dados dc série temporal, que é um tipo dc dado temporal muito importante na prática.

26.2.1 Representação de tempo, calendários e dimensões de tempo Para bancos de dados temporais, o tempo é considerado uma sequência orde­ nada de pontos em alguma granularidade determinada pela aplicação. Por exemplo, suponha que alguma aplicação temporal nunca exija unidades de tempo menores que um segundo. Então, cada ponto no tempo representa um segundo usando essa granularidade. Na realidade, cada segundo é uma (curta) duração de tempo, c não um ponto, pois ele pode ser dividido ainda em milissegundos, microssegundos, e assim por diante. Os pesquisadores de banco de dados temporal têm usado o termo crônon em vez de ponto para descrever essa granularidade mínima para determinada aplicação. A principal consequência da escolha de uma granularidade mínima — digamos, um segundo — é que os eventos que ocorrem no mesmo segundo serão considerados eventos simultâneos, embora na realidade eles possam não ser. Como não existe um início ou fim conhecido para o tempo, é preciso que haja um ponto de referência para medir pontos específicos no tempo. Diversos calendários são usados por várias culturas (como o gregoriano ou ocidental, o chinês, o islâmico, o hindu, o judeu, o cóptico etc.), com diferentes pontos de referência. Um calendário organiza o tempo cm diferentes unidades por conveniência. A maioria dos calendários agrupa 60 segundos em um minuto, 60 minutos em uma hora, 24 horas em um dia (com base no tempo físico da rotação da Terra em relação a seu eixo) e sete dias em uma semana. Outros agrupamentos de dias em meses e de meses em anos seguem o fenômeno natural solar ou lunar c gcralmentc são irregulares. No calendário grego­ riano, usado na maioria dos países ocidentais, os dias são agrupados em meses, que têm 28,29,30 ou 31 dias, e 12 meses são agrupados em um ano. Fórmulas complexas são utilizadas para mapear as diferentes unidades de tempo entre si. Na SQL2, os tipos de dados temporais (ver Capítulo 6) incluem DATE (especifi­ cando dia, mês e ano como DD-MM-AAAA), TIME (especificando hora, minuto e segundo como HH:MM:SS), TIMESTAMP (especificando uma combinação dc data/ hora, com opções para incluir divisões dc subsegundo, se forem necessárias), INTERVAL (uma duração de tempo relativa, como 10 dias ou 250 minutos) e PERIOD (uma duração de tempo ancorada com um ponto de partida fixo, como o período de 10 dias desde 1 de janeiro dc 2019 até 10 de janeiro dc 2019, inclusive).11 11 Intelizmente, a terminologia não tem sido usada de forma consistente. Por exemplo, o termo intenul normalmente é usado para indicar uma duração ancorada. Por coerência, usaremos a terminologia da SQL.

880

Sistemas de banco de dados

Informação de evento versus informação de duração (ou estado). Um banco de dados temporal ainda armazenará informações referentes a quando certos eventos ocorrem, ou quando certos fatos sào considerados verdadeiros. Existem vários tipos de informações temporais. Eventos ou fatos pontuais em geral sào associados no banco de dados a um único ponto no tempo em alguma granularidade. Por exemplo, um evento de depósito bancário pode ser associado ao rótulo de tempo de quando o depósito foi feito, ou as vendas totais mensais dc um produto (fato) podem scr associadas a determinado mês (digamos, fevereiro de 2019). Observe que, embora tais eventos ou fatos possam ter diferentes níveis de granularidade, cada um ainda é associado a um único valor de tempo no banco de dados. Esse tipo de informação costuma ser representado como dado de série temporal, conforme discutiremos na Seção 26.2.5. Eventos ou fatos dc duração, por sua vez, são associados a um período específico no banco de dados.12 Por exemplo, um funcionário pode ter trabalhado em uma empresa desde 15 de agosto de 2013 até 20 de novembro de 2018. Um período de tempo é representado por seus pontos inicial e final[START-TIME, END-TIME]. Por exemplo, o período que acabamos de indicar é representado como [15-08-2013, 20-11-2018]. Esse período normalmente é interpretado para indicar o conjunto de todos os pontos de tempo desde a data inicial até a data final, inclu­ sive na granularidade especificada. Logo, considerando a granularidade de dia, o período [15-08-2013,20-11-2018] representa o conjunto de todos os dias desde 15 de agosto de 2013 até 20 de novembro de 2018, inclusive.13 Dimensões de tempo válido e tempo de transação. Dado um evento ou fato em particular, associado a um ponto no tempo ou período em particular no banco de dados, a associação pode ser interpretada para indicar coisas diferentes. A interpre­ tação mais natural é que o tempo associado é a hora cm que o evento ocorreu, ou o período durante o qual o fato foi considerado como verdadeiro no mundo real. Sc essa interpretação for usada, o tempo associado com frequência é conhecido como tempo válido. Um banco de dados temporal que usa essa interpretação é chamado de banco de dados de tempo válido. Contudo, uma interpretação diferente pode scr utilizada, na qual o tempo asso­ ciado refere-se ao momento em que a informação foi realmente armazenada no banco de dados; ou seja, é o valor do clock de tempo do sistema quando a informação é válida no sistema.14 Nesse caso, o tempo associado é chamado de tempo de transa­ ção. Um banco de dados temporal que usa essa interpretação é chamado de banco dc dados de tempo dc transação. Outras interpretações também podem scr intencionadas, mas essas são considera­ das as mais comuns c conhecidas como dimensões de tempo. Em algumas aplicações, somente uma das dimensões é necessária e, em outros casos, as duas dimensões de tempo sào necessárias, quando o banco de dados temporal é chamado de banco de dados bitemporal. Sc outras interpretações forem intencionadas para o tempo, o usuário pode definir a semântica c programar as aplicações devidamente, e ele é chamado de tempo definido pelo usuário. /\ próxima seção mostra como esses conceitos podem ser incorporados aos bancos de dados relacionais, e a Seção 26.2.3 aborda uma técnica para incorporar os conceitos temporais em bancos de dados de objeto.

12 Isso é o mesmo que uma duração ancorada. Também cem sido constantemente chamado de intervalo de tempo, mas, para evitar confusão, usaremos período para sermos coerentes com a terminologia da SQI_ 15 A representação [15-08-2013, 20-11-2018| é chamada de representação de intervalo fechado. Também é possível usar um intertuIo aberto, indicado como [15-08-2013, 21-11-2018), em que o conjunto dc pontos não inclui o ponto final. Embora essa última representação às vezes seja mais con­ veniente, usaremos os intervalos fechados, exceto quando indicado de outra forma.

14 A explicação é mais extensa, conforme veremos na Seção 26.2.3.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

881

26.2.2 Incorporando o tempo nos bancos de dados relacionais com versionamento de tupla Relações de tempo válidas. Vamos agora ver como diferentes tipos de bancos de dados temporais podem ser representados no modelo relacionai. Primeiro, suponha que queiramos incluir o histórico das mudanças conforme ocorrem no mundo real. Considere novamente o banco de dados da Figura 26.1, e vamos supor que, para essa aplicação, a granularidade seja em nível de dia. Então, poderiamos converter as duas relações FUNCIONÁRIO e DEPARTAMENTO para relações de tempo válidas ao acrescentar os atributos Tiv (Tempo Inicial Válido) e Tfv (Tempo Final Válido), cujo tipo dc dado é DATE, a fim de oferecer granularidade de dia. Isso é mostrado na Figura 26.7(a), cm que as relações foram renomeadas para FUNCIONARIO_TV e DEPARTAMENTO_TV, respectivamente. Considere como a relação FUNCIONARIO_TV difere da relação não temporal FUNCIONÁRIO (Figura 26.1).15 Em FUNCIONARIO_TV, cada tupla V representa uma versão da informação de um funcionário que c válida (no mundo real) apenas durante o período [V.Tiv, V.Tfv], ao passo que em FUNCIONÁRIO cada tupla representa apenas o estado ou a versão atual de cada funcionário. Em FUNCIONARIO_TV, a versão atual de cada funcionário normalmente tem um valor especial, now, como seu tempo final válido. Esse valor especial, now, é uma variável temporal que implicitamente representa a hora atual à medida que o tempo progride. A relação não temporal FUNCIONÁRIO só incluiría as tuplas da relação FUNCIONARIO_TV cujo Tfv c now. A Figura 26.8 mostra algumas versões dc tupla nas relações dc tempo válido FUNCIONARIO_TV e DEPARTAMENTO_TV. Existem duas versões de Silva, três versões de Wong, uma versão de Braga c uma versão de Lima. Agora, podemos ver como uma relação dc tempo válida deve se comportar quando as informações sâo trocadas. Sempre que um ou mais atributos dc um funcionário são atualizados, em vez de simplesmente sobrcscreverem os valores antigos, como aconteceria em uma relação não temporal, o sistema deve criar outra versão e fechar a versão atual ao alterar seu Tfv para o tempo final. Logo, quando o usuário emitiu o comando para atualizar o salário de Silva a partir de 1 de junho de 2013 para R$30.000, a segunda versão

(a)

Figura 26.7 Diferentes

FUNCIONARIO_TV Nome

Cpf | Salario

Numero departamento

tipos de bancos de dados

| Tfv

Cpf supervisor

relacionais temporais, (a)

DEPARTAMENTO TV_______________________________________________________________ Nome_departamento | Numero_departamento | Salario_total | Cpf_gerente | Tiv | Tfv |

Esquema de banco de

dados de tempo válido, (b) Esquema de banco

(b)

de dados de tempo de

FUNCIONARIO_TT_______________________________________________________ Nome | Cpf

Salario | Numero_departamento

Cpf_supervisor

transação, (c) Esquema

Tit | Tft |

de banco de dados

bitemporal.

DEPARTAMENTO TT Nome departamento

(c)

Numero-departamento

Salario total 1 Cpf gerente

Id

Tft

FUNCIONARIOBT

Nome

Cpf

Salario 1 Numero-departamento

Cpf supervisor

Tiv

Tfv

lit iTftl

DEPARTAMENTO BT Nome departamento | Numero departamento | Salario total | Cpf gerente | Hv | Tfv

15 Uma relação não temporal também é chamada de relação de snapshot, pois mostra apenas o snapshot atual ou o estado atual do banco de dados.

üt | Tft |

882

Sistemas de banco de dados

FUNCIONARIO TV Nome

£CÍ

Salario

Numero, departamento

Cpf_su pervisor

Ik

Tfv

Silva

12345678966

25.000

5

33344555587

15-06-2012

31-05-2013

Silva

12345678966

30.000

5

33344555587

01-06-2013

Now

Wong

33344555587

25.000

4

99988777767

20-08-2009

31-01-2011

Wong

33344555587

30.000

5

99988777767

01-02-2011

31-03-2012

Wong

33344555587

40.000

5

88866555576

01-04-2012

Now

Braga

22244777711

28.000

4

99988777767

01-05-2011

10-08-2012

Lima

66688444476

38.000

5

33344555587

01-08-2013

Now

DE PARTAM ENTO TV Nome departamento

Numero-departamento

Cpf gerente

Tiv

Tfv

Pesquisa

5

88866555576

20-09-2011

31-03-2012

Pesquisa

5

33344555587

01-04-2012

Now

Figura 26.8 Algumas versões de tupla nas relações de tempo válidas FUNCIONARIO_TV e DEPARTAMENTO_TV.

de Silva foi criada (ver Figura 26.8). No momento dessa atualização, a primeira versão de Silva era a versão atual, com now como seu Tfv, mas após a atualização now foi alterado para 31 de maio de 2013 (um a menos que 1 de junho de 2013, com granularidade de dia), para indicar que a versão se tomou uma versão fechada ou histórica e que a nova (segunda) versão de Silva agora é a atual. E importante observar que, cm uma relação dc tempo válida, o usuário gcralmentc precisa oferecer o tempo válido de uma atualização. Por exemplo, a atualização de salário de Silva pode ter sido inserida no banco de dados em 15 de maio de 2013, às 8:52:12, digamos, embora a mudança de salário no mundo real tenha sido efetivada cm 1 dc junho dc 2013. Isso c chamado dc atualização proativa. pois c aplicada ao banco de dados antes que se torne efetiva no mundo real. Se a atualização for aplicada ao banco de dados após ter se tomado efetiva no mundo real, é chamada de atualização retroativa. Uma atualização aplicada ao mesmo tempo em que se torna efetiva é chamada de atualização simultânea. A ação que corresponde a excluir um funcionário em um banco de dados não temporal em geral seria aplicada a um banco de dados de tempo válido ao fechar a versão atual do funcionário sendo excluído. Por exemplo, se Silva tivesse deixado a empresa a partir de 19 de janeiro de 2014, então isso seria aplicado ao alterar o Tfv da versão atual de Silva de now para 19-01-2014. Na Figura 26.8, não existe uma versão atual para Braga, pois presume-se que ele saiu da empresa em 10-08-2012, e foi excluído logicamente. Mas, como o banco dc dados c temporal, a informação antiga sobre Braga ainda está lá. A operação para inserir um novo funcionário correspondería a criar a primeira versão de tupla para esse funcionário e torná-la a versão ativa, com o Tiv sendo o tempo dc efetivação (mundo real) em que o funcionário começa a trabalhar. Na Figura 26.7, a tupla em Lima ilustra isso, pois a primeira versão ainda não foi atualizada. Observe que, em uma relação de tempo válida, a chave não temporal, como Cpf em FUNCIONÁRIO, não é mais única em cada tupla (versão). A nova chave da relação para FUNCIONARIO_TV é uma combinação da chave não temporal e o atributo de

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

hora de início válido Tiv,16 de modo que usamos (Cpf,Tiv) como chave primária. Isso porque, em qualquer ponto no tempo, deve haver no máximo uma versão válida de cada entidade. Logo, a restrição de que duas versões de tupla quaisquer repre­ sentando a mesma entidade devem ter períodos válidos sem interseção que deve ser mantida nas relações de tempo válidas. Observe que, se o valor da chave primária nào temporal puder mudar com o tempo, é importante ter um atributo dc chave substituta único, cujo valor nunca muda para cada entidade do mundo real, a fim de relacionar todas as versões da mesma entidade do mundo real. Relações de tempo válidas basicamente acompanham o histórico das mudanças à medida que são efetivadas no mundo real. Assim, se todas as mudanças do mundo real são aplicadas, o banco de dados mantém um histórico dos estados do mundo real que são representados. No entanto, como atualizações, inserções e exclusões podem ser aplicadas de maneira retroativa ou proativa, não há registro do estado do banco de dados real em qualquer ponto no tempo. Se os estados reais do banco de dados forem importantes para uma aplicação, é preciso usar relações de tempo de transação.

Relações de tempo de transação. Em um banco de dados de tempo de transação, sempre que uma mudança é aplicada ao banco de dados, o rótulo de tempo (times­ tamp) real da transação que aplicou a mudança (inserção, exclusão ou atualização) é registrado. Esse banco de dados é mais útil quando as mudanças são aplicadas simultaneamente na maioria dos casos — por exemplo, em transações de negocia­ ções de ações ou bancárias em tempo real. Se convertermos o banco de dados não temporal da Figura 26.1 em um banco de dados de tempo de transação, as duas relações FUNCIONÁRIO e DEPARTAMENTO são convertidas para relações de tempo de transação ao acrescentar os atributos Tit (Tempo Inicial de Transação) e Tft (Tempo Final de Transação), cujo tipo dc dados normalmcntc é TIMESTAMP. Isso aparece na Figura 26.7(b), em que as relações foram renomeadas como FUNCIONARIO_TT e DEPARTAMENTO_TT, respectivamente. Em FUNCIONARIO_TT, cada tupla Vrepresenta uma versão das informações de um funcionário, que foi criada no tempo real V.Tit e (logicamente) removida no tempo real V.Tft (porque a informação não estava mais correta). Em FUNCIONARIO_TT, a versão atual de cada funcionário costuma ter um valor especial, uc (Until Changed — até ser alterada), como seu tempo final de transação, que indica que a tupla repre­ senta informações corretas até que seja alterada por alguma outra transação.1718 Um banco de dados de tempo de transação também é chamado de banco de dados de rollback,,s pois um usuário pode reverter logicamente para o estado real do banco dc dados cm qualquer ponto do passado no tempo T ao recuperar todas as versões de tupla V cujo período de transação 1 V.Tit, V.Tft) inclui o ponto no tempo T. Relações bitemporais. Algumas aplicações exigem tanto o tempo válido quanto o tempo dc transação, levando a relações bitemporais. Em nosso exemplo, a Figura 26.7(c) mostra como as relações não temporais FUNCIONÁRIO e DEPARTAMENTO na Figura 26.1 apareceríam como relações bitemporais FUNCIONARIO.BT e DEPARTAMENTO.BT, respectiva mente. A Figura 26.9 mostra algumas tuplas nes­ sas relações. Nessas tabelas, as tuplas cujo tempo final dc transação Tft é uc são aquelas que representam informações atualmente válidas, enquanto as tuplas cujo

16 Uma combinação da chave não temporal c do atributo dc tempo final válido Tfv também poderia ser usada.

1 •' A variável uc nas relações de tempo de transação corresponde à variável now nas relações de tempo válido. Contudo, a semântica é ligeiramente diferente. 18 Aqui, o termo rollback não tem o mesmo significado que rollback de transação (ver Capítulo 23) du­ rante a recuperação, cm que as atualizações dc transação são desfeitas fisicamente. Em vez disso, aqui as atualizações podem ser desfeitas logicamente, permitindo que o usuário examine o banco de dados conforme ele apareceu em um ponto anterior no tempo.

883

884 Sistemas de banco de dados FUNCIONARIO.BT

Salario Numero_ Cpf_ departamento supervisor

Tfv

Nome

Cpí

Silva

12345678966 25.000

5

33344555587

15-06-2012 Atual

Silva

12345678966 25.000

5

33344555587

15-06-2012 31-05-2013 04-06-2013, 08:56:12

uc

Silva

12345678966 30.000

5

33344555587

01-06-2013 Atual

04-06-2013, 08:56:12

uc

Wong

33344555587

25.000

4

99988777767

20-08-2009 Atual

20-08-2009, 11:18:23

07-01-2011, 14:33:02

Wong

33344555587

25.000

4

99988777767

20-08-2009 31-01-2011

07-01-2011, 14:33:02

uc

Wong

33344555587

30.000

5

99988777767

01-02-2011

Atual

07-01-2011, 14:33:02

28-03-2012, 09:23:57

Wong

33344555587

30.000

5

99988777767

01-02-2011

31-03-2012 28-03-2012, 09:23:57

Wong

33344555587 40.000

5

88866777767

01-04-2012 Atual

28-03-2012, 09:23:57

uc

Braga

22244777711

28.000

4

99988777767

01-05-2011

Atual

27-04-2011, 16:22:05

12-08-2012, 10:11:07

Braga

22244777711

28.000

4

99988777767

01-05-2011

10-08-2012

12-08-2012, 10:11:07

uc

Lima

66688444476 38.000

5

33344555587

01-08-2013 Atual

28-07-2013, 09:25:37

uc

ÜM

Iii

Tft

08-06-2012, 13:05:58

04-06-2013, 08:56:12

uc

DEPARTAMENTOJJT

Nome_ Numero Cpf.gerente departamento departamento

ÜY

Tft

Tfv



15-09-2011, 28-03-2011, 09:23:57 14:52:12

Pesquisa

5

88866555576 20-09-2011

Atual

Pesquisa

5

88866555576 20-09-2011

31-03-2007 28-03-2012, uc 09:23:57

Pesquisa

5

33344555587

01-04-2012 Atual

28-03-2012, uc 09:23:57

Figura 26.9 Algumas versões de tupla nas relações bitemporais FUNCIONARIO.BT e DE PARTAM ENTO.BT.

Tft é um rótulo de tempo (timestamp) absoluto sào tuplas que eram válidas até (imediatamente antes de) esse rótulo de tempo. Logo, as tuplas com uc da Figura 26.9 correspondem às tuplas de tempo válidas da Figura 26.7. O atributo de tempo de início de transação Tit em cada tupla é o rótulo de tempo de transação que criou essa tupla. Agora, considere como uma operação dc atualização seria implementada cm uma relação bitemporal. Nesse modelo de bancos de dados bitemporais,19 nenhum atributo é fisicamente alterado em qualquer tupla, exceto pelo atributo de tempo

19 Tem havido muitos modelos de banco de dados temporais propostos. Descrevemos modelos específi­ cos aqui como exemplos para ilustrar os conceitos.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

final de transação Tft com um valor de wc.20 Para ilustrar como as tuplas são criadas, considere a relação FUNCIONARIO_BT. A versão atual V de um funcionário tem uc em seu atributo Tft e now em seu atributo Tfv. Se algum atributo — digamos, Salario — for atualizado, a transação T que realiza a atualização deverá ter dois parâmetros: um novo valor de Salario e o tempo válido TV quando o novo salário foi efetivado (no mundo real). Suponha que TV- seja o ponto no tempo antes de TV na granularidade de tempo válido indicada e que a transação T tenha um rótulo de tempo RT(T). Então, as mudanças físicas a seguir seriam aplicadas à tabela FUNCIONARIO_BT:

1. Faça uma cópia V, da versão atual V; defina V2.Tfv para TV-, V,.Tit para RT(T), V2.Tft para mc, e insira V2 em FUNCIONARIO_BT; V2 é uma cópia da versão atual e anterior V depois de ser fechada no tempo válido TV-.

2. Faça uma cópia V3 da versão atual V; defina V3.Tiv como IV, V3.Tft como now, Vj.Salario como o novo valor do salário, V3.Tit como RT(T), V3.Tft como uc e insira V. em FUNCIONARIO_BT; V3 representa a nova versão atual. 3. Defina V.Tft como RT(T), pois a versão atual nâo está mais representando a informação correta. Como um exemplo, considere as três primeiras tuplas Vp V, e V3 em FUNCIONARIO_BT da Figura 26.9. Antes da atualização do salário de Silva de 25000 para 30000, somente V! estava em FUNCIONARIO.BT, essa era a versão atual c seu Tft era uc. Depois, uma transação T cujo rótulo de tempo RT(T) é‘04-06-2013,08:56:12' atualiza o salário para 30000 com o tempo válido efetivo de ‘01-06-2013'. A tupla V2 é criada, que é uma cópia de Vp exceto que seu Tfv é definido como ‘31-05-2013’, um dia a menos que o novo tempo válido, e seu Tit é o rótulo de tempo de transação em atualização. A tupla V3 também é criada, que tem o novo salário, seu Tiv é definido como ‘01 -06-2013’ e seu Tit também é o rótulo de tempo de transação em atualização. Por fim, o Tft de Vj é definido como o rótulo de tempo da transação em atualização,‘04-06-2013, 08:56:12'. Observe que essa é uma atualização retroativa, pois a transação de atualização rodou em 4 de junho de 2013, mas a mudança de salário é efetivada em 1 de junho de 2013. De modo semelhante, quando o salário e o departamento de Wong são atualizados (ao mesmo tempo) para 30000 e 5, o rótulo de tempo da transação dc atualização é ‘07-01-2011,14:33:02', e o tempo válido efetivo para a atualização é‘01-02-2011’. Logo, essa é uma atualização proativa, pois a transação rodou em 7 de janeiro de 2011, mas a data de efetivação foi 1 de fevereiro de 2011. Nesse caso, a tupla V4 é logicamente substituída por V5 e V6. Em seguida, vamos ilustrar como uma operação dc exclusão seria implementada em uma relação bitemporal ao considerar as tuplas V9 e VI0 na relação FUNCIONARIO_ BT da Figura 26.9. Aqui, o funcionário Braga saiu da empresa efetivamente em 10 de agosto de 2012, e a exclusão lógica é executada por uma transação T com RT(T) = 12-08-2012,10:11:07. Antes disso, V9 era a versão atual de Braga, e seu Tft era uc. A exclusão lógica é implementada ao definir V9.Tft como 12-08-2012,10:11:07 para invalidá-la, c ao criar a versão final V10 para Braga, com seu Tfv = 10-08-2012 (ver Figura 26.9). Finalmente, uma operação dc inserção é implementada ao criar a primeira versão, conforme ilustrada por Vn na tabela FUNCIONARIO_BT. Considerações de implementação. Existem diversas opções para armazenar as tuplas em uma relação temporal. Uma é armazenar todas as tuplas na mesma tabela, como mostram as figuras 26.8 e 26.9. Outra opção é criar duas tabelas: uma para a informação atualmente válida e a outra para o restante das tuplas. Por exemplo, na

20 Alguns modelos bitemporais permirem que o atributo Tfv também seja alterado, mas as interpreta­ ções das tuplas são diferentes nesses modelos.

885

886

Sistemas de banco de dados

relação bitemporal FUNCIONARIO_BT, as tuplas com uc para seu Tft e now para seu Tfv estariam em uma relação, a tabela atual, pois elas sào as atualmente válidas (ou seja, representam o snapshot atual), e todas as outras tuplas estariam em outra relação. Isso permite que o administrador de banco de dados tenha diferentes caminhos de acesso, como índices para cada relação, e mantenha o tamanho da tabela atual razoável. Outra possibilidade é criar uma terceira tabela para as tuplas corrigidas cujo Tft não é uc. Outra opção disponível é particionar verticalmente os atributos da relação tem­ poral em relações separadas, de modo que, se uma relação tem muitos atributos, uma nova versão de tupla inteira é criada sempre que qualquer um dos atributos for atua­ lizado. Se os atributos forem atualizados assincronamente, cada nova versão pode diferir apenas em um dos atributos, repetindo assim, de maneira desnecessária, os outros valores dc atributo. Se uma relação separada for criada para conter apenas os atributos que sempre mudam sincronamente, com a chave primária replicada em cada relação, diz-se que o banco de dados está em forma normal temporal. Contudo, para combinar a informação, uma variação de junção conhecida como junção de interseção temporal seria necessária, que geralmente é dispendiosa de implementar. É importante observar que os bancos de dados bitemporais permitem um regis­ tro completo das mudanças. Até mesmo um registro de correções c possível. Por exemplo, é possível que duas versões de tupla do mesmo funcionário possam ter o mesmo tempo válido, mas diferentes valores de atributo, desde que seus tempos de transação sejam disjuntos. Nesse caso, a tupla com o tempo de transação mais recente é uma correção da outra versão dc tupla. Até mesmo tempos válidos incorrctamcnte inseridos podem ser corrigidos dessa maneira. O estado incorreto do banco de dados ainda estará disponível como um estado de banco de dados anterior para fins de consulta. Um banco de dados que mantém tal registro completo de mudanças e correções às vezes é chamado de banco de dados apenas de inserção.

26.2.3 Incorporando o tempo nos bancos de dados orientados a

objeto com o versionamento de atributo A seção anterior discutiu a técnica de versionamento de tupla para implementação de bancos de dados temporais. Nessa técnica, sempre que um valor de atributo é mudado, uma nova versão de tupla inteira é criada, embora todos os outros valores dc atributo sejam idênticos à versão de tupla anterior. Uma técnica alternativa pode ser usada nos sistemas de banco de dados que dão suporte a objetos estruturados complexos, como bancos de dados de objeto (ver Capítulo 12) ou sistemas objeto-relacional. Essa técnica é chamada de versionamento de atributo. No versionamento dc atributo, um único objeto complexo é usado para armaze­ nar todas as mudanças temporais do objeto. Cada atributo que muda com o tempo é chamado de atributo variável com o tempo, e ele tem seus valores versionados com o tempo pela inclusão de períodos temporais ao atributo. Os períodos temporais podem representar tempo válido, tempo de transação ou bitemporal, dependendo dos requisitos da aplicação. Os atributos que não mudam com o tempo são chamados dc não variáveis com o tempo c não são associados a períodos temporais. Para ilus­ trar isso, considere o exemplo da Figura 26.10, que é uma representação dc tempo válido versionada por atributo de FUNCIONÁRIO que usa a notação da linguagem de definição de objeto (ODL) para bancos de dados de objeto (ver Capítulo 12). Aqui, consideramos que nome c número dc CPF são atributos não variáveis com o tempo, ao passo que salário, departamento c supervisor são atributos variáveis com o tempo (eles podem mudar com o tempo). Cada atributo variável com o tempo é representado como uma lista de tuplas , ordenada por tempo inicial válido.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

class SALARIO-TEMPORAL { attribute Date

attribute Date attribute float

Figura 26.10 Esquema ODL

Tempo_inicial_valido; Tem po_fi nal.val ido; Salario;

possível para uma classe de

objeto FUNCIONARIO-TV de tempo válido temporal usando

1;

versionamento de atributo.

class DEPARTAMENTO-TEMPORAL

{

887

attribute Date attribute Date attribute DEPARTAMENTO_TV

Tempojnicial-valido; Tem po_fi na l_vaI ido;

Dep;

1; class SUPERVISOR-TEMPORAL { attribute Date

attribute Date

Tempojnicial-valido; Tem po_fi nal.val ido;

attribute FUNCIONARIOJV

Supervisor;

}; class EXPECTATIVA_VIDA_TEMPORAL { attribute Date Tempo_inidal_valido; attribute Date Tempo_final_valido; };

class FUNCIONARIO_TV ( extent FUNCIONÁRIO )

attribute list vida.util; Nome; attribute string Cpf; attribute string attribute list attribute list attribute list

Historico_sal; Historico_dep; Historico_su pervisor;

Sempre que um atributo é mudado nesse modelo, a versão do atributo atual é fechada e uma nova versão de atributo é apenas anexada à lista. Isso permite que os atributos mudem assincronamcntc. O valor atual para cada atributo tem now para seu Tempo_final_valido. Ao usar o versionamento de atributo, é útil incluir um atributo temporal dc expectativa dc vida associado ao objeto inteiro cujo valor c um ou mais períodos válidos, que indicam o tempo válido de existência para o objeto inteiro. A exclusão lógica do objeto é implementada ao fechar a expectativa de vida. A restrição dc que qualquer período dc tempo dc um atributo em um objeto deva ser um subconjunto de sua expectativa de vida precisa ser imposta. Para bancos de dados bitemporais, cada versão de atributo teria uma tupla com cinco componentes:

A expectativa de vida do objeto também incluiria dimensões de tempo válidas e dc transação. Portanto, as capacidades completas dos bancos dc dados bitemporais podem estar disponíveis com o versionamento de atributo. Mecanismos semelhantes aos discutidos anteriormente para atualização de versões de tupla podem ser apli­ cados à atualização de versões de atributo.

26.2.4 Construções de consulta temporal e a linguagem TSQL2 Ate aqui, discutimos como os modelos de dados podem scr estendidos com cons­ truções temporais. Agora, oferecemos uma breve visão geral de como as operações

888

Sistemas de banco de dados

de consulta precisam ser estendidas para a consulta temporal. Vamos discutir rapida­ mente a linguagem TSQL2, que estende a SQL para a consulta de tabelas de tempo válido e tempo de transação, além da consulta de tabelas relacionais bitemporais. Em bancos de dados relacionais não temporais, as condições de seleção típi­ cas envolvem condições de atributo, e tuplas que satisfazem essas condições são selecionadas com base no conjunto de tuplas atuais. Seguindo isso, os atributos de interesse à consulta são especificados por uma operação de projeção (ver Capítulo 8). Por exemplo, na consulta para recuperar os nomes de todos os funcionários que trabalham no departamento 5 cujo salário é maior que 30.000, a condição de seleção seria a seguinte: ((Salario > 30000) AND (Numero.departamento = 5))

O atributo projetado seria Nome. Em um banco de dados temporal, as condições podem envolver o tempo além dos atributos. Uma condição de tempo pura envolve apenas tempo — por exemplo, para selecionar todas as versões de tupla de funcioná­ rio que eram válidas em certo ponto no tempo T ou que eram válidas durante certo período [Tp T»]. Nesse caso, o período especificado é comparado com o período válido de cada versão de tupla [T.Tiv, T.Tfv], e somente as tuplas que satisfazem a condição são selecionadas. Nessas operações, um período é considerado equivalente ao conjunto de pontos de tempo de T, a T, inclusive, de modo que as operações de comparação do conjunto-padrão podem ser usadas. Operações adicionais, como se um período termina antes dc outro começar, também são necessárias.21* Algumas das operações mais comuns usadas nas consultas são as seguintes: | T.Tiv, TTfv| [T.Tiv, T.Tfv] [T.Tiv, TTfv| [T.Tiv, TTfv] [T.Tiv, TTfv] [T.Tiv, T.Tfv]

INCLUDES |TP T,| INCLUDED IN [Tp T,| OVERLAPS |T„ T,| BEFORE (T„ T,| AFTER |T,,T2| MEETS_BEFÓRE [Tp T,]

[T.Tiv, TTfv| MEETS AFTER [Tp TJ

Equivalente a T, è TTiv AND T, £ T.Tfv Equivalente a Tj TTiv AND T, £ T.Tfv Equivalente a (T, S TTfv AND f, £ T.Tiv)— Equivalente a Equivalente a Equivalente a Equivalente a

T, T, T, T,

£ S = +

TTfv TTiv T.Tfv + 123 1 = T.Tiv

Além disso, são necessárias operações para manipular períodos de tempo, como para calcular a união ou a interseção de dois períodos de tempo. Os resultados dessas operações podem não ser períodos, mas sim elementos temporais — uma coleção de um ou mais períodos disjuntos, de modo que dois períodos dc tempo cm um elemento temporal não sejam dirctamcntc adjacentes. Ou seja, para dois períodos quaisquer [Tp T,| e [Tj, T4| em um elemento temporal, as três condições a seguir devem ser mantidas: ■ A interseção de [Tp T,] com [T3, T4] é vazia. ■ T? não é o ponto no tempo após T, na granularidade indicada. ■ T] não é o ponto no tempo após T4 na granularidade indicada.

Essas últimas condições são necessárias para garantir representações únicas dos elementos temporais. Se dois períodos de tempo [Tp T,] e [T3, TJ são adjacentes, cies são combinados cm um único período dc tempo [Tp T4]. Isso é chamado de aglutinação de períodos de tempo. A aglutinação também combina períodos de tempo que possuem interseção.

21 Um conjunto completo de operações conhecido como álgebra de Allen (Allen, 1983), tem sido defi­ nido para a comparação de períodos de tempo. — Esta operação retorna verdadeiro se a interseção dos dois períodos não for vazia; ela também tem sido chamada de INTERSECTS_WITH.

2} Aqui, 1 refere-se a um ponto no tempo na granularidade especificada. As operações MEETS basica­ mente especificam se um período começa imediatamente após outro período terminar.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

Para ilustrar como as condições de tempo puras podem ser usadas, suponha que um usuário queira selecionar todas as versões dc funcionário que foram válidas em qualquer ponto durante 2012. A condição de seleção apropriada aplicada à relação na Figura 26.8 seria

[TTiv, TTTfv] OVERLAPS (01-01-2012, 31-12-2012] Normalmcnte, a maioria das seleções temporais c aplicada à dimensão dc tempo válida. Para um banco de dados bitemporal, em geral se aplicam as condições às tuplas atualmente corretas com wc como seus tempos finais de transação. Contudo, se a consulta precisa ser aplicada a um estado dc banco de dados anterior, uma cláusula AS_OF T é anexada à consulta, o que significa que a consulta é aplicada às tuplas de tempo válido que estavam corretas no banco dc dados no tempo T. Além das condições de tempo puras, outras seleções envolvem condições de atributo e tempo. Por exemplo, suponha que queiramos recuperar todas as versões de tupla T de FUNCIONARIO_TV para funcionários que trabalharam no departamento 5 em qualquer momento durante 2012. Nesse caso, a condição é

[TTiv, rrfvl OVERLAPS [01-01-2012, 31-12-2012] AND (TNumero_departamento = 5) Finalmenre, damos uma breve visão geral da linguagem de consulta TSQL2, que estende a SQL com construções para bancos de dados temporais. A ideia principal por trás da TSQL2 é permitir que os usuários especifiquem se uma relação é não temporal (ou seja, uma relação SQL padrão) ou temporal. O comando CREATE TABLE é estendido com uma cláusula opcional AS para permitir que os usuários declarem diferentes opções temporais. As seguintes opções estão disponíveis:

■ AS VAUD STATE (relação de tempo válida com período válido) ■ AS VALID EVENT (relação de tempo válida com ponto no tempo válido) ■ AS TRANSACTION (relação dc tempo de transação com período de transação) ■ AS VAUD STATE AND TRANSACTION (relação bitemporal, período de tempo válido) ■ AS VALID EVENT AND TRANSACTION (relação bitemporal, ponto de tempo válido) As palavras-chave STATE e EVENT são usadas para especificar se um período ou ponto no tempo está associado à dimensão de tempo válido. Em TSQL2, cm vez de um usuário realmente ver como as tabelas temporais são implementadas (conforme discutimos nas seções anteriores), a linguagem TSQL2 acrescenta construções da linguagem de consulta para especificar diversos tipos de seleções temporais, proje­ ções temporais, agregações temporais, transformação entre granularidades e muitos outros conceitos. O livro de Snodgrass et al. (1995) descreve a linguagem.

26.2.5 Dados de série temporais Os dados de série temporais são usados com muita frequência em aplicações financeiras, de vendas e economia. Eles envolvem valores de dados registrados de acordo com uma sequência predefinida de pontos no tempo. Portanto, eles são um tipo especial de dados de evento válidos, cm que os pontos no tempo do evento são predeterminados dc acordo com um calendário fixo. Considere o exemplo do preço de fechamento diário das ações de determinada empresa na Bovespa. A granularidade aqui é o dia, mas os dias em que a bolsa de valores está aberta são conhecidos (dias de semana que não sejam feriados). Logo, tem sido comum especificar um procedi­ mento computacional que calcula o calendário em particular associado à série dc

889

890

Sistemas de banco de dados

tempo. Consultas típicas sobre séries de tempo envolvem agregação temporal em intervalos de granularidade maior — por exemplo, encontrar o preço de fechamento de ação médio ou máximo semanal, ou o preço de fechamento de ação máximo e mínimo mensal com base na informação diária. Como outro exemplo, considere as vendas diárias em reais em cada loja de uma cadeia de supermercados pertencente a determinada empresa. Novamente, as agregações temporais típicas estariam recuperando as vendas semanais, mensais ou anuais da informação de vendas diárias (usando a função de agregação de soma), ou comparando algumas vendas mensais da loja com as vendas mensais anteriores, e assim por diante. Em virtude da natureza especializada dos dados de série de tempo e da falta dc suporte para isso nos SGBDs mais antigos, tem sido comum usar sistemas dc gerenciamento de série de tempo especializados em vez de SGBDs de uso geral para gerenciar tais informações. Nesses sistemas, tem sido comum armazenar valores de série de tempo em ordem sequencial em um arquivo e aplicar procedimentos de série de tempo especializados para analisar as informações. O problema com essa técnica é que o poder total da consulta de alto nível em linguagens como SQL não estará disponível cm tais sistemas. Xlais recentemente, alguns pacotes dc SGBD comerciais estão oferecendo exten­ sões de série de tempo, como o cartridge de tempo da Oracle e a data blade de dados de série temporal do Informix Universal Server. Além disso, a linguagem TSQL2 oferece algum suporte para a série dc tempo na forma dc tabelas dc evento.

26.3 Conceitos de banco de dados espacial24 26.3.1 Introdução aos bancos de dados espaciais Os bancos de dados espaciais incorporam a funcionalidade que oferece suporte para bancos de dados que registram objetos em um espaço multidimensional. Por exemplo, bancos de dados cartográficos que armazenam mapas incluem descrições espaciais bidimensionais dc seus objetos — de países e estados até rios, cidades, estradas, mares, c assim por diante. Os sistemas que gerenciam dados geográficos e aplicações relacionadas são conhecidos como sistemas de informações geográficas (GIS —geographic information systems), e são usados em áreas como aplicações ambientais, sistemas de transporte, sistemas de resposta à emergência e gerencia­ mento de batalha. Outros bancos de dados, como os meteorológicos para infor­ mações de clima, são tridimensionais, pois as temperaturas e outras informações meteorológicas estão relacionadas a pontos espaciais tridimensionais. Em geral, um banco de dados espacial armazena objetos que possuem características espaciais que os descrevem e que possuem relacionamentos espaciais entre eles. Os relacionamentos espaciais entre os objetos são importantes, e eles costumam ser necessários quando se consulta o banco dc dados. Embora um banco dc dados espacial cm geral possa se referir a um espaço ^-dimensional para qualquer n, limitaremos nossa discussão a duas dimensões como um exemplo. Um banco de dados espacial é otimizado para armazenar e consultar dados relacionados a objetos no espaço, incluindo pontos, linhas c polígonos. Imagens dc satélite são um exemplo dc destaque para os dados espaciais. As consultas impostas nesses dados espaciais, em que os predicados para seleção lidam com parâmetros espaciais, são chamadas consultas espaciais. Por exemplo, “Quais são os nomes de todas as livrarias que estão até cinco quilômetros do prédio da Faculdade de Agradecemos a contribuição de Pranesh Parimala Ranganathan a esta seção.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

Computação na USP?" é uma consulta espacial. Enquanto os bancos de dados típicos processam dados numéricos e de caractere, uma funcionalidade adicional precisa ser acrescentada aos bancos de dados para que processem tipos de dados espaciais. Uma consulta como “Liste todos os clientes localizados até 20 quilômetros da sede da empresa'’ exigirá o processamento de tipos de dados espaciais normalmente fora do escopo da álgebra relacionai padrão, e pode envolver a consulta a um banco dc dados geográfico externo, que mapeia a sede da empresa e cada cliente cm um mapa 2-D com base cm seu endereço. Efetivamente, cada cliente estará associado a uma posição de P(NRID). Descartando a constante P(D), isso é equivalente a dizer que um documento é relevante se:

P(DIR) x P(R) > P(DINR) x P(NR)

A razão de probabilidade P(DIR)/P(DINR) é usada como uma nora para deter­ minar a probabilidade de o documento com representação D pertencer ao conjunto relevante.

10 Ver Rocchio (1971). 11 Para obter uma descrição do sistema Cheshire II, ver Robertson (1997).

12 O teorema de Bayes é uma técnica-padrão para medir a probabilidade; ver Howson e Urbach (1993), por exemplo.

Capítulo 27

Introdução à recuperação de informações e busca na web

A independência de termo ou suposição naive Bayes é utilizada para estimar P(DIR) usando o cálculo de P(t}R) para o termo tr As razões de probabilidade P(D\R)/P(D\NR) dos documentos são usadas como um substituto para o ranqueamento com base na suposição de que documentos altamente ranqueados terão uma probabilidade alta de pertencerem ao conjunto relevante.13 Com algumas suposições e estimativas razoáveis sobre o modelo probabilístico ao longo das extensões para incorporar pesos de termo dc consulta c pesos dc termo dc documento no modelo, um algoritmo dc ranqueamento probabilistic© chamado BM25 (Best Match 25) é bastante popular. Esse esquema de pesos evoluiu de várias versões do sistema Okapi.14 O peso do Okapi para o documento d; e consulta q é calculado pela fórmula a seguir Eis algumas anotações adicionais:

■ ti é um termo. ■ f^é a contagem de frequência bruta do termo tf do documento d,. ■

c a contagem dc frequência bruta do termo Z, na consulta q.

■ Néo número total de documentos na coleção. ■ dfté o número total de documentos que contêm o termo Zr ■ dlfé o tamanho do documento (em bytes) de d,. ■ avdl é o tamanho dc documento médio da coleção.

A pontuação de relevância Okapi de um documento d para uma consulta q é dada pela equação a seguir, em que (entre 1,0 e 2,0), b (normalmente, 0,75) e k2 (entre 1 e 1.000) são parâmetros: >+1)^ (*

Okapiíd-.^) = y

'q Á,

4(+05

MÁ \

*■ l-b+bú

_z__ '■/ *2+4

27.2.4 Modelo semântico Por mais sofisticados que os modelos estatísticos se tornem, eles podem perder muitos documentos relevantes, pois não capturam o significado completo ou a necessidade de informação transmitida pela consulta de um usuário. Nos modelos semânticos, o processo de combinação de documentos com determinada consulta é baseado no nível de conceito e combinação semântica, em vez de na combinação do termo de índice (palavra-chave). Isso permite a recuperação de documentos relevantes que compartilham associações significativas com outros documentos no resultado da consulta, mesmo quando essas associações não são inerentemente observadas ou estatisticamente capturadas. Abordagens semânticas incluem diferentes níveis de análise, como as análises morfológica, sintática e semântica, para recuperar documentos com mais eficiência. Na análise morfológica. raízes e afixos são analisados para determinar as partes do discurso (substantivos, verbos, adjetivos etc.) das palavras. Seguindo a análise morfólógica, a análise sintática divide e analisa as frases completas nos documentos. Por fim, os métodos semânticos precisam resolver ambiguidades de palavra e/ou gerar sinôni­ mos relevantes com base nos relacionamentos semânticos entre níveis dc entidades estruturais em documentos (palavras, parágrafos, páginas ou documentos inteiros). O desenvolvimento de um sistema semântico sofisticado requer bases de conhe­ cimento complexas da informação semântica, bem como heurísticas de recuperação. 13 Os leitores deverão consultar Croft et al. (2009), páginas 246-247, para obter uma descrição detalhada. 14 City University of London Okapi System, de Robertson. Walker e Hancock-Beaulieu (1995).

933

934

Sistemas de banco de dados

Esses sistemas normalmenre exigem técnicas de inteligência artificial e sistemas especialistas. Bases de conhecimento como Cyc15 e WordNet16 têm sido desenvolvi­ das para uso nos sistemas de RI baseados em conhecimento, com base nos modelos semânticos. A base de conhecimento Cyc, por exemplo, é uma representação de uma vasta quantidade de conhecimento comum. Atualmente, ela contém 15,94 milhões de asserções, 498.271 conceitos atômicos e 441.159 conceitos derivados nào atômicos para a conclusão sobre os objetos e eventos da vida cotidiana. WordNet é um tesauro extenso (mais de 117.000 conceitos) muito popular, usado por diversos sistemas e que está em desenvolvimento contínuo (ver Seção 27.4.3).

27.3 Tipos de consultas em sistemas de RI Diferentes palavras-chave são associadas ao conjunto de documentos durante o processo de indexação. Essas palavras-chave geralmente consistem em palavras, frases e outras caracterizações de documentos, como data de criação, nomes de autor e tipo dc documento. Elas são usadas por um sistema dc RI para montar um índice invertido (ver Seção 27.5), que é, então, consultado durante a pesquisa. As consultas formuladas pelos usuários são comparadas com o conjunto de palavras-chave de índice. maioria dos sistemas de RI também permite o uso de operadores booleanos e outros para montar uma consulta complexa. A linguagem de consulta com esses operadores enriquece a expressividade da necessidade de informação de um usuário.

27.3.1 Consultas por palavra-chave As consultas baseadas em palavra-chave são as formas mais simples e mais utili­ zadas de consultas RI: o usuário apenas informa combinações de palavra-chave para recuperar documentos. Os termos da palavra-chave são implicitamente conectados por um operador lógico AND. Uma consulta como “conceitos SGBD” recupera documentos que contêm as palavras “conceitos” e “SGBD” no topo dos resultados recuperados. Além disso, a maioria dos sistemas também recupera documentos que contêm apenas “conceitos” ou apenas “SGBD” em seu texto. Alguns sistemas remo­ vem as palavras que ocorrem com mais frequência (como um, o/a, de etc., chamadas stopwords) como uma etapa de pré-processamento antes de enviar as palavras-chave de consulta filtradas ao mecanismo dc RI. A maioria dos sistemas dc RI não presta atenção à ordenação dessas palavras na consulta. Todos os modelos dc recuperação oferecem suporte para consultas por palavra-chave.

27.3.2 Consultas booleanas Alguns sistemas de RI permitem o uso dos operadores booleanos AND, OR, NOT, ( ), + e - em combinações de formulações de palavra-chave. AND requer que os dois termos sejam encontrados. OR permite que um dos termos seja encontrado. NOT signi­ fica que qualquer registro contendo o segundo termo seja excluído. “()” significa que os operadores booleanos podem ser aninhados usando parênteses. “+” é equivalente a AND, e exige o termo; o “+” deve ser colocado diretamenre na frente do termo de pesquisa. “-” é equivalente a AND NOT e significa excluir o termo; o “-” deve ser colo­ cado diretamente na frente do termo dc pesquisa não desejado. Consultas booleanas complexas podem scr montadas com base nesses operadores e suas combinações, c eles são avaliados de acordo com as regras clássicas da álgebra booleana. Nenhuma 15 Ver Lenar (1995).

16 Ver em Miller (19901 uma descrição detalhada do WordNet.

Capítulo 27

Introdução à recuperação de informações e busca na web

escala de ranqueamento é possível, pois um documento ou satisfaz tal consulta (é “rele­ vante”) ou nào a satisfaz (é “nào relevante”). Um documento é recuperado para uma consulta booleana se a consulta for logicamente verdadeira como uma combinação exata no documento. Os usuários não costumam usar combinações desses operadores booleanos complexos, e os sistemas de RI admitem uma versão restrita desses opera­ dores de conjunto. Os modelos de recuperação booleanos podem aceitar diretamente implementações diferentes dc operador booleano para esses tipos dc consultas.

27.3.3 Consultas por frase Quando os documentos são representados usando-se um índice de palavra-chave invertida para pesquisa, a ordem relativa dos termos no documento é perdida. Para realizar uma recuperação dc frase exata, essas frases devem ser codificadas no índice invertido ou implementadas dc modo diferente (com posições relativas dc ocorrências de palavra nos documentos). Uma consulta por frase consiste cm uma sequência dc palavras que compõem uma frase. A frase geralmente é delimitada por aspas. Cada documento recuperado precisa conter pelo menos uma ocorrência da frase exata. A consulta por frase é uma versão mais restrita e específica da pesquisa por proxi­ midade, que mencionaremos a seguir. Por exemplo, uma consulta por frase poderia ser “projeto conceituai banco dc dados”. Se as frases forem indexadas pelo modelo de recuperação, qualquer modelo de recuperação pode ser usado para esses tipos de consulta. Um resauro de frases também pode ser usado nos modelos semânticos para uma rápida pesquisa de frases no dicionário.

27.3.4 Consultas por proximidade A consulta por proximidade considera a proximidade em um registro com que múltiplos termos devem estar um do outro. A opção de consulta por proximidade mais utilizada é uma consulta de frase que requer que os termos estejam na ordem exata. Outros operadores de proximidade podem especificar a proximidade com que os termos devem estar uns dos outros. Alguns também especificarão a ordem dos termos dc pesquisa. Cada mecanismo de pesquisa pode definir operadores dc proximidade de forma diferente, e os mecanismos de pesquisa utilizam vários nomes de operadoi; como NEAR (próximo), ADJ (adjacente) ou AFTER (depois). Em alguns casos, é dada uma sequência de palavras isoladas, com uma distância máxima per­ mitida entre elas. Os modelos de espaço de vetor, que também mantêm informações sobre posições e deslocamentos de tokens (palavras), possuem implementações robustas para esse tipo dc consulta. Contudo, oferecer suporte para operadores de proximidade complexos torna-se compuracionalmente dispendioso, pois requer o pré-processamento demorado dos documentos, e assim é mais adequado para cole­ ções de documentos menores, e nào para a web.

27.3.5 Consultas por curinga A consulta por curinga em geral significa dar suporte a expressões regulares c à pesquisa com base na combinação de padrões no texto. Em sistemas dc RI, certos tipos de suporte para consulta por curinga podem ser implementados — normal­ mente, palavras com caracteres iniciais (por exemplo, “data * ” recuperaria ddta, database, datapoint, dataset etc.). Fornecer suporte para consultas por curinga cm sistemas de RI envolve o custo adicional do pré-processamento, e isso geralmente não é implementado por muitos dos mecanismos atuais de busca na web.17 Os modelos • Consulte para obter mais detalhes.

935

936

Sistemas de banco de dados

de recuperação não oferecem suporte direto para esse tipo de consulta. I.ucene18 oferece suporte para certos tipos de consultas por curinga. O analisador de consulta no Lucene calcula uma consulta booleana grande juntando todas as combinações e expansões de palavras a partir do índice.

27.3.6 Consultas em linguagem natural Existem alguns mecanismos de consulta em linguagem natural que visam a enten­ der a estrutura e o significado das consultas escritas com texto em linguagem natural, geralmentc como uma pergunta ou narrativa. Essa é uma área de pesquisa ativa, que emprega técnicas como análise semântica superficial do texto, ou reformulações de consulta com base no conhecimento da linguagem natural. O sistema tenta formular respostas para tais consultas baseando-se nos resultados recuperados. Alguns sistemas de consulta estão começando a oferecer interfaces de linguagem natural para fornecer respostas a tipos específicos de perguntas, como as de definição e fatos interessantes, que pedem as definições de termos técnicos ou fatos comuns que podem ser recupe­ rados de bancos de dados especializados. Essas perguntas costumam ser mais fáceis de responder porque existem padrões linguísticos fortes que oferecem dicas para tipos específicos de sentenças — por exemplo, “definido como" ou “refere-se a”. Os modelos semânticos podem oferecer suporte para esse tipo de consulta.

27.4 Pré-processamento de textos Nesta seção, analisamos as técnicas de pré-processamento de textos mais usadas que fazem parte da tarefa de processamento de textos da Figura 27.1.

27.4.1 Remoção de stopwords Stopwords são muito utilizadas em um idioma e desempenham um papel impor­ tante na formação de uma sentença, mas raramente contribuem para o significado dessa sentença. Palavras que se espera que ocorram em 80% ou mais dos documentos em uma coleção costumam ser chamadas de stopivords, e elas se tornam poten­ cialmente inúteis. Por serem muito comuns e pela função dessas palavras, elas não contribuem muito para a relevância de um documento para uma pesquisa. Alguns exemplos são palavras como ola, de, para, uni, e, em, diz, que, ser, sobre, ele, é, com e por. Essas palavras são apresentadas aqui com uma frequência de ocorrência decrescente, vindas de um grande corpo de documentos, chamado AP89.19 As seis primeiras dessas palavras são responsáveis por 20% de todas as palavras na lista­ gem, e as 50 palavras mais frequentes são responsáveis por 40% de todo o texto. A remoção de stopwords de um documento deve ser realizada antes da indexação. Artigos, preposições, conjunções e alguns pronomes geralmente são classificados como stopwords. As consultas também devem ser pré-processadas para a remoção de stopwords antes do processo de recuperação real. A remoção de stopwords resulta na eliminação de possíveis índices falsos, reduzindo assim o tamanho de uma estru­ tura de índice em cerca de 40% ou mais. Contudo, isso poderia afetar a pesquisa se a stopword for parte integral de uma consulta (por exemplo, uma pesquisa pela frase “Ser ou não ser”, em que a remoção de stopwords torna a consulta imprópria, pois todas as palavras na frase são stopwords). Muitos mecanismos dc pesquisa não empregam a remoção de stopwords na consulta por esse motivo. 18 19 Para mais detalhes, consultar Croft et al. (2009), páginas 75-90.

Capítulo 27

Introdução à recuperação de informações e busca na web

27.4.2 Raízes A raiz de uma palavra é definida como a palavra obtida depois de remover o sufixo e o prefixo de uma palavra original. Por exemplo, “comput” é a palavra raiz para computador, computação e computadorizado. Esses sufixos e prefixos são muito comuns na língua portuguesa, para dar suporte à noção dc verbos, tempos e formas no plural. As raízes reduzem as diferentes formas da palavra formada por inflexão (decorrente de plurais e tempos verbais) e derivação a uma raiz comum. Um algoritmo dc raiz pode scr aplicado para reduzir qualquer palavra à sua raiz. Em inglês, o algoritmo dc raiz mais famoso é o dc Martin Porter. O Porter stemmer20 é uma versão simplificada da técnica de Lovin que usa um conjunto reduzido de cerca de 60 regras (dos 260 padrões de sufixo da técnica de Lovin) e as organiza em conjuntos; conflitos em um subconjunto de regras são resolvidos antes de passar para o seguinte. O uso de raízes para o pré-processamento de dados resulta em uma diminuição no tamanho da estrutura de indexação e cm um aumento no conjunto retornado, possivelmente à custa da precisão.

27.4.3 Utilizando um tesauro Um tesauro compreende uma lista pré-compilada de conceitos importantes e a palavra principal que descreve cada conceito para determinado domínio de conhecimento. Para cada conceito nessa lista, um conjunto dc sinônimos c palavras relacionadas também é compilado.21 Assim, um sinônimo pode ser convertido para seu conceito correspondente durante o pré-processamento. Essa etapa de pré-processamento auxilia no fornecimento de um vocabulário padrão para indexação c pesquisa. O uso dc um tesauro, também conhecido como uma coleção de sinôni­ mos, tem um impacto substancial no retorno obtido pelos sistemas dc informação. Esse processo pode scr complicado porque muitas palavras possuem significados diferentes em variados contextos. O UMLS22 é um grande tesauro biomédico com milhões de conceitos (chamado metathesaurus) e uma rede semântica de metaconceitos e relacionamentos que organizam o metathesaurus (ver Figura 27.3). Os conceitos recebem rótulos da rede semântica. Esse tesauro de conceitos contém sinônimos de termos médicos, hierarquias de termos mais amplos e mais estritos, e outros relacionamentos entre palavras e conceitos, que o tornam um recurso muito extenso para a recuperação de informações de documentos no domínio médico. A Figura 27.3 ilustra parte da UMLS Semantic Network. O WordNet23 é um tesauro construído manualmente, que agrupa palavras em conjuntos de sinônimos estritos, chamados Esses synsets são divididos em categorias de substantivo, verbo, adjetivo e advérbio. Em cada categoria, tais synsets são vinculados por relacionamentos apropriados, como classe/subclasse ou relacio­ namentos “é-um” para substantivos. O WordXct está baseado na ideia dc uso dc um vocabulário controlado para indexação, eliminando assim as redundâncias. Ele também é útil para oferecer assis­ tência a usuários com a localização de termos para uma formulação de consulta apropriada.

20 Ver Poirer (1980).

21 Ver Baeza-Yares e Ribeiro-Neto (1999). 22 Unified Medical Language System da National Library of Medicine. 25 Ver cm Fellbaum (1998) uma descrição detalhada do WordNet.

937

938

Sistemas de banco de dados

Figura 27.3 Uma parte da UMLS Semantic Network: hierarquia "Função biológica". Fonte: UMLS Reference

Manual. National Library of Medicine.

27.4.4 Outras etapas de pré-processamento: dígitos, hifens, sinais de

pontuação, maiúsculas/minúsculas Dígitos, datas, números de telefone, endereços de e-mail, URLs e outros tipos padrão de texto podem ou não ser removidos durante o pré-processamento. Mecanismos de busca da web, porém, os indexam a fim dc usar esse tipo dc infor­ mação nos metadados do documento, para melhorar a precisão e a revocação (veja definições detalhadas de precisão e revocação na Seção 27.6). Hifens e sinais de pontuação podem ser tratados de maneiras diferentes. A frase inteira pode ser usada com os hifens/sinais de pontuação, ou então eles podem ser eliminados. Em alguns sistemas, o caractere que representa o hífen/sinal de pontuação pode scr removido, ou pode scr substituído por um espaço. Diferentes sistemas dc recuperação dc informações seguem diferentes regras dc processamento. Tratar dc hifens de maneira automática pode ser complexo: pode ser feito como um problema dc classificação ou, mais comumente, por algumas regras heurísticas. Por exemplo, o StandardTokcnizcr’4 no Luccnc trata o hífen como um delimitador para quebrar palavras — com a exceção dc que, se houver um número no token, as palavras não são divididas (por exemplo, palavras como AK-47, números de telefone etc.). Muitos termos específicos do domínio, como catálogos de produtos, diferentes versões de um produto e assim por diante possuem hifens embutidos. Quando os mecanismos de busca vasculham a web em busca de indexação, fica difícil tratar os hifens automaticamente de forma correta; portanto, estratégias mais simples são elaboradas para processá-los. A maioria dos sistemas dc recuperação dc informações realiza pesquisa sem con­ siderar maiúsculas/minúsculas, convertendo todas as letras do texto para maiúsculas ou minúsculas. Também é preciso observar que muitas dessas etapas de pré-proces­ samento de textos são específicas da linguagem, como as que envolvem acentos e diacríticos, e as idiossincrasias que estão associadas a determinado idioma.

27.4.5 Extração de informações A extração dc informações (IE — information extraction) é um termo genérico usado para extrair conteúdo estruturado do texto. Tarefas analíticas de texto.

-■* Ver mais detalhes sobre o StandardTokenizer em .

Capítulo 27

Introdução à recuperação de informações e busca na web

como identificar frases substantivas, fatos, eventos, pessoas, lugares e relaciona­ mentos são exemplos de tarefas de IE. Essas tarefas também são chamadas de tarefas nomeadas de reconhecimento de entidade e usam abordagens baseadas em regra com um tesauro, expressões regulares e gramáticas, ou técnicas probabilísticas. Para RI e aplicações de pesquisa, as tecnologias de 1E são usadas prin­ cipalmente para identificar entidades nomeadas, que envolvem análise de texto, combinação e categorização, para melhorar a relevância dos sistemas dc pesquisa. As tecnologias da linguagem que utilizam marcação de parte da voz são aplicadas para anotar semanticamente os documentos com recursos extraídos e auxiliar na relevância da pesquisa.

27.5 Indexação invertida A forma mais simples de procurar ocorrências de termos de consulta em coleções de texto pode ser realizada ao varrer o texto sequencialmente. Esse tipo de consulta on-line só é apropriado quando coleções de texto são pequenas. A maioria dos siste­ mas dc recuperação dc informações processa as coleções dc texto para criar índices e operar sobre a estrutura de dados de índice invertido (consulte a tarefa de indexa­ ção na Figura 27.1). Uma estrutura de índice invertido compreende informações de vocabulário e documento. Vocabulário é um conjunto de termos de consulta distintos no conjunto de documentos. Cada termo em um conjunto de vocabulário tem uma coleção associada de informações sobre os documentos que contêm o termo, como id dc documento, contagem dc ocorrência c deslocamentos no documento cm que o termo ocorre. A forma mais simples de termos de vocabulário consiste cm palavras de tokens individuais dos documentos. Em alguns casos, esses termos de vocabulário também consistem em frases, w-gramas, entidades, links, nomes, datas ou termos descritores atribuídos manualmcntc com base cm documentos c/ou páginas web. Para cada termo no vocabulário, as ids dc documento correspondentes, os locais c número de ocorrências do termo em cada documento e outras informações relevantes podem ser armazenados na seção de informações do documento. Pesos são atribuídos a termos do documento para representar uma estimativa da utilidade de determinado termo como um descritor para distinguir um documento de outros na mesma coleção. Um termo pode ser um descritor melhor de um docu­ mento do que de outro, pelo processo de pesos (ver Seção 27.2). Um índice invertido de uma coleção de documentos é uma estrutura de dados que anexa termos distintos a uma lista de todos os documentos que contêm o termo. O processo de construção de índice invertido envolve as etapas de extração e pro­ cessamento mostradas na Figura 27.2. O texto adquirido é primeiro pré-processado e os documentos são representados com os termos do vocabulário. As estatísticas dos documentos são coletadas em tabelas de pesquisa de documento. Elas geral­ mente incluem contadores de termos de vocabulário em documentos individuais, bem como diferentes coleções, suas posições de ocorrência nos documentos e os tamanhos destes. Os termos do vocabulário são pesados em tempo de indexação, de acordo com diferentes critérios para coleções. Por exemplo, em alguns casos, os termos nos títulos dos documentos podem ter peso maior que os termos que ocorrem em outras partes dos documentos. Um dos esquemas de peso mais populares é a métrica TF-IDF (term frequency-inverse document frequency}, descrita na Seção 27.2. Para determinado termo, esse esquema de peso distingue até certo ponto os documentos em que o termo ocorre com mais frequência daqueles em que o termo ocorre muito pouco ou nunca. Esses pesos são normalizados para considerar tamanhos de documento variáveis, garantindo

939

940

Sistemas de banco de dados

ainda mais que os documentos maiores, proporcionalmente com mais ocorrências de uma palavra, nào sejam favorecidos para recuperação em relação a documentos menores, com ocorrências proporcionalmente menores. Esses fluxos (matrizes) de documento-termo processados são então invertidos para fluxos (matrizes) de termo-documento, para outras etapas de RI. A Figura 27.4 mostra um exemplo dos vetores de termo-documento-posição para os quatro termos ilustrativos — exemplo, invertido, índice c mercado — que se referem aos três documentos e à posição em que ocorrem nesses três documentos. As diferentes etapas envolvidas na construção do índice invertido podem ser resumidas da seguinte forma: 1. Divida os documentos em termos de vocabulário ao criar tokens, limpar, remo­ ver stopwords, definir a raiz c/ou usar um tesauro adicional como vocabulário.

2. Reúna estatísticas de documento e armazene-as em uma tabela de pesquisa de documento. 3. Inverta o fluxo documento-termo para um fluxo termo-documento, com infor­ mações adicionais como frequências, posições e pesos de termo. A pesquisa por documentos relevantes com base no índice invertido, dado um conjunto de termos de consulta, geralmente é um processo em três etapas. 1. Pesquisa de vocabulário. Se a consulta compreende múltiplos termos, eles são separados e tratados como termos independentes. Cada termo é pesquisado no vocabulário. Diversas estruturas de dados, como variações da * -tree B ou hashing, podem ser usadas para otimizar o processo de pesquisa. Termos de consulta também podem ser organizados em ordem lexicográfica para melhorar a eficiência do espaço.

2. Recuperação de informações do documento. As informações do documento para cada termo são recuperadas. Documento 1

Este exemplo mostra um exemplo de

ID

Termo

Documento: posição

indice invertido.

1.

exemplo

12,1:5

2.

invertido

1:8,22

3.

indice

1:7,2:1,3:1

4.

mercado

35,3:13

Documento 2

índice invertido é

uma estrutura de

dados para associar termos aos documentos.

Documento 3 índice de ação do

mercado é usado para capturar os sentimentos do mercado financeiro.

Figura 27.4 Exemplo de um índice invertido.

Capítulo 27

Introdução à recuperação de informações e busca na web

3. Manipulação de informações recuperadas. O vetor de informações do docu­ mento para cada termo obtido na etapa 2 agora é processado ainda mais para incorporar diversas formas de lógica da consulta. Vários tipos de consultas, como consultas de prefixo, abrangência, contexto e proximidade, são proces­ sados nesta etapa para construir o resultado final com base nas coleções de documentos retornadas na etapa 2. 27.5.1 Introdução ao Lucene

Lucene é um mecanismo dc indexação/pesquisa dc software livre, mantido ativa­ mente, que se tornou popular em ambientes acadêmicos e comerciais. A indexação é o foco principal do Lucene, mas ele usa indexação para facilitar a pesquisa. A biblioteca do Lucene é escrita em Java e já vem com recursos escaláveis e de alto desempenho, prontos para o uso. Lucene c o mecanismo que impulsiona outro aplicativo de busca corporativa bastante popular, chamado Solr.25 O Solr oferece muitos recursos complementares ao Lucene, como o fornecimento de interfaces da web para indexar muitos formatos de documentos diferentes. Um livro de Moczar (2015) discute a respeito do Lucene e do Solr.

Indexação. No Lucene, os documentos devem passar por um processo de indexa­ ção antes de se tornarem disponíveis para pesquisa. Um documento Lucene é com­ posto por um conjunto dc campos. Os campos mantêm o tipo dc dados no índice c são vagamente comparáveis às colunas cm uma tabela de banco dc dados. Um campo pode ser do tipo de dados binários, numéricos ou de texto. Os campos de texto consistem em um trecho inteiro de texto sem tokens ou em uma série de unidades léxicas processadas, chamadas fluxos de tokens. Os fluxos de tokens são criados por meio da aplicação de diferentes tipos dc algoritmos de filtragem e tokenização disponíveis. Por exemplo, o StandardTokcnizcr é um dos tokenizadores disponíveis no Lucene, o qual implementa a segmentação dc texto Unicode para separar as palavras. Existem outros tokenizadores, como o WhitespaceTokenizer, que dividem o texto em espaços em branco. Também é fácil estender esses tokenizadores e filtros no Lucene para criar algoritmos dc análise de texto personalizados para tokenização c filtragem. Esses algoritmos de análise são fundamentais para alcançar os resultados dc pesquisa desejados. Lucene fornece APIs e várias implementações para muitos algoritmos de filtragem e tokenização de alta velocidade e eficientes. Esses algorit­ mos foram estendidos para várias linguagens e domínios diferentes, e apresentam implementações de algoritmos de processamento de linguagem natural para extrair raízes, realizar lematização conduzida por dicionário, análise morfológica, análise fonética e assim por diante. Pesquisa. Com uma poderosa API de pesquisa, as consultas são comparadas com os documentos e uma lista classificada dc resultados é recuperada. As consul­ tas são comparadas com os vetores de termos em índices invertidos para calcular as pontuações de relevância com base no modelo de espaço de vetor (consulte a Seção 27.2.2). O Lucene fornece uma API de pesquisa altamente configurável, na qual é possível criar consultas para pesquisas por curingas, exatas, booleanas, de proximidade e dc abrangência. O algoritmo de pontuação default do Lucene usa variantes de pontuação TF-IDF para ranquear os resultados da pesquisa. Para acelerar a pesquisa, o Lucene mantém pré-calculados os fatores de normalização dependentes do documento em tempo de indexação; estas são chamadas normas de vetores de termo nos campos dos documentos. Essas normas pré-calculadas agilizam o processo de pontuação no Lucene. Os algoritmos dc correspondência

25 Veja em .

941

942

Sistemas de banco de dados

de consulta reais usam funções que fazem muito pouco cálculo em tempo de cor­ respondência de consulta.

Aplicações. Um dos motivos da imensa popularidade do Lucene é a facili­ dade de disponibilidade dos aplicativos Lucene para lidar com várias coleções de documentos e sistemas de implantação para indexar grandes coleções de documentos nào estruturados. A aplicação de pesquisa corporativa criada sobre o Lucene é chamada de Solr. Solr é uma aplicação de servidor web que oferece suporte para busca facetada (consulte a respeito de busca facetada na Seção 27.8.1), suporte a processamento de documentos em formato personali­ zado (como PDF, HTML etc.) e serviços web para várias funções de API para indexação e pesquisa em Lucene.

27.6 Medidas de avaliação de relevância da pesquisa Sem técnicas de avaliação apropriadas, nào se pode comparar e medir a relevância de diferentes modelos de recuperação e sistemas dc RI a fim dc fazer melhorias. As técnicas de avaliação dos sistemas de RI medem a relevância tópica e a relevância do usuário. A relevância tópica mede a extensão à qual o tópico dc um resultado combina com o tópico da consulta. O mapeamento da necessidade dc informação de alguém com consultas “perfeitas” é uma tarefa cognitiva, e muitos usuários não são capazes de efetivamente formar consultas que recuperem resul­ tados mais adequados a sua necessidade de informação. Além disso, como uma parte importante das consultas do usuário é informativa por natureza, nào existe um conjunto fixo de respostas corretas para mostrar ao usuário. A relevância do usuário é um termo utilizado para descrever a adequação de um resultado recupe­ rado com relação à necessidade de informação do usuário. A relevância do usuário inclui outros fatores implícitos, como a percepção do usuário, o contexto, o senso de oportunidade, o ambiente do usuário e as necessidades da tarefa em mãos. A avaliação da relevância do usuário também pode envolver a análise subjetiva e o estudo das tarefas dc recuperação do usuário, a fim dc capturar algumas das propriedades dos fatores implícitos envolvidos na consideração da tendência dos usuários para julgar o desempenho. Na recuperação de informações da web, nenhuma decisão de classificação binária é feira sobre se um documento é relevante ou nào para uma consulta (enquanto o modelo dc recuperação booleano, ou binário, usa esse esquema, conforme discutimos na Seção 27.2.1). Ao contrário, um ranqueamento dos documentos é produzido para o usuário. Portanto, algumas medidas de avaliação focalizam a comparação de diferentes pontuações produzidas por sistemas de RI. Discutimos algumas dessas medidas em seguida.

27.6.1 Revocação e precisão Métricas de revocação e precisão sào baseadas na suposição de relevância binária (se cada documento é relevante ou não para a consulta). A revocação é definida como o número de documentos relevantes recuperados por uma pesquisa dividido pelo número total de documentos relevantes existentes no banco de dados. A precisão é definida como o número de documentos relevantes recuperados por uma pesquisa dividido pelo número total de documentos recuperados por essa pesquisa. A Figura 27.5 é uma representação gráfica dos termos recuperado e relevante, mostrando como os resultados da pesquisa se relacionam com quatro conjuntos diferentes de documentos.

Capítulo 27

Introdução à recuperação de informações e busca na web

Relevante?

Sim

Não

Acertos

Alarmes

©

Sim

falsos VP

FP

Perdas

Rejeições

Recuperado?

corretas Não

FN

VN

©

Figura 27.5 Resultados de pesquisa recuperados versus relevantes.

A notação para a Figura 27.5 é a seguinte:

■ VP: verdadeiro positivo. ■ FP: falso positivo. ■ FN: falso negativo. ■ VN: verdadeiro negativo. Os termos verdadeiro positivo, falso positivo, falso negativo e verdadeiro negativo costumam ser usados em qualquer tipo de tarefa de classificação para comparar determinada classificação dc um item com a classificação correta desejada. Usando o termo acertos para os documentos que verdadeiramente ou ‘‘corretamente’' cor­ respondem à solicitação do usuário, podemos definir: Revocação = lAcertosl/IRelevantesI Precisão = lAccrtosl/IRecuperadosl Revocação e precisão também podem ser definidos em um ambiente de recu­ peração ranqueado. Vamos supor que haja um documento em cada posição de ranqueamento. A revocação na posição do rank i para o documento d * (indicado por r(i)) (d * é o documento recuperado na posição i para a consulta q) é a fração de documentos relevantes de d^ a df * no conjunto de resultados para a consulta. Considere o conjunto de documentos relevantes de d^ a d? nesse conjunto como 5, com cardinalidade I 5, I. Considere que (IDJ seja o tamanho dos documentos relevantes para a consulta. Nesse caso, IS, I < IDJ). Então:

Revocação_Recuperação_ranqueada: r(7) = 15,I/ID^I A precisão na posição de ranqueamento i ou documento d# (indicada por p(i)) é a fração dos documentos de d^ a d? no conjunto de resultados que são relevantes:

Precisão_Recuperação_ranqueada: p{i\ = 15,1/7 A Tabela 27.2 ilustra as métricas de p(z), r(z) e a precisão média (a ser discutida na próxima seção). Vê-se que a revocação pode ser aumentada ao apresentar mais resultados ao usuário, mas essa técnica corre o risco de diminuir a precisão. No exemplo, o número de documentos relevantes para alguma consulta = 10. A posição de ranqueamento e a relevância de um documento individual são mostradas. Os valores de precisão e revocação podem ser calculados em cada posição dentro da lista ranqueada, como mostram as duas últimas colunas. Como vemos na Tabela 27.2, a precisão da recuperação ranqueada aumenta de modo linear, ao passo que a precisão é passível de flutuação.

943

944

Sistemas de banco de dados Tabela 27.2 Precisão e revocação para a recuperação ranqueada.

Posição de ranqueamento /

Relevante

10

1

2

Número documento

PrecisãofO

Revocaçãofí)

Sim

1/1 = 100%

1/10= 10%

2

Sim

2/2 = 100%

2/10 = 20%

3

3

Sim

3/3 = 100%

3/10 = 30%

5

4

Não

3/4 = 75%

3/10 = 30%

17

5

Não

3/5 = 60%

3/10 = 30%

34

6

Não

3/6 = 50%

3/10 = 30%

215

7

Sim

4/7 = 57,1%

4/10 = 40%

33

8

Sim

5/8 = 62,5%

5/10 = 50%

45

9

Não

5/9 = 55,5%

5/10 = 50%

16

10

Sim

6/10 = 60%

6/10 = 60%

27.6.2 Precisão média

A precisão média é calculada com base na precisão em cada documento relevante no ranqueamento. Essa medida é útil para calcular um único valor de precisão ao comparar diferentes algoritmos dc recuperação cm uma consulta q.

Considere os valores dc precisão dc exemplo dos documentos relevantes da Tabela 27.2. z\ precisão média (valor de Pmcy) Para ° exemplo da Tabela 27.2 é P( 1) + P(2) + P(3) + P(7) + P(8) + P(10)/6 = 79,93% (somente documentos relevantes são considerados nesse cálculo). Muitos algoritmos bons tendem a ter alta precisão média dos k primeiros resultados para valores pequenos de ky com valores de retorno correspondentemente baixos.

27.6.3 Curva de revocação/precisão Uma curva de revocação/precisão pode ser desenhada com base nos valores de precisão e revocação em cada posição de ranqueamento, em que o eixo x é a revoca­ ção e o eixo y é a precisão. Em vez de usar a precisão e a revocação em cada posição de ranqueamento, a curva gcralmentc é desenhada usando níveis dc revocação r(z) em 0%, 10%, 20%... 100%.curva normalmente tem uma inclinação negativa, refletindo o relacionamento inverso entre precisão e revocação.

27.6.4 F-Score F-scorc (F) é a média harmônica dos valores dc precisão (p) e revocação (r), ou seja:

1 1 —+— 1 =P ' F 2

A alta precisão é alcançada quase sempre à custa da revocação e vice-versa. O sistema pode ser ajustado para alta precisão ou alta revocação, dependendo do contexto da aplicação. F-score normalmente é usado como uma única medida que combina precisão e revocação para comparar diferentes conjuntos de resultados: F=^ p+r

Capítulo 27

Introdução à recuperação de informações e busca na web

Uma das propriedades da média harmônica é que aquela de dois números tende a ser mais próxima da menor das duas. Assim, F é automaticamente propenso para o menor entre os valores de precisão e revocação. Portanto, para um F-score alto, a precisão e a revocação devem ser altas.

—+P r

27.7 Pesquisa e análise na web26 O surgimento da web levou milhões de usuários a procurar informações, que sâo armazenadas em um número muito grande de sites ativos. Para tornar essas informações acessíveis, mecanismos de busca como Google e Yahoo! precisam sondar e indexar esses sites e documentar coleções em seus bancos de dados de índice. Além disso, os mecanismos de busca precisam atualizar seus índices regu­ larmente, dada a natureza dinâmica da web, à medida que novos sites web são criados e os atuais são atualizados ou removidos. Como existem muitos milhões de páginas disponíveis na web sobre diferentes tópicos, os mecanismos de busca precisam aplicar diversas técnicas sofisticadas, como análise de link, para identificar a importância dessas páginas. Existem outros tipos de mecanismos de busca além dos que regularmente son­ dam a web e criam índices automáticos: estes são mecanismos de busca verticais, operados por humanos, ou mecanismos de metabusca. São desenvolvidos com a ajuda de sistemas auxiliados por computador para ajudar os tutores com o pro­ cesso de atribuir índices. Eles consistem em diretórios web especializados criados manualmente, organizados de maneira hierárquica para guiar a navegação do usuário a diferentes recursos na web. Os mecanismos de busca verticais são meca­ nismos personalizados, específicos do tópico, que sondam e indexam uma coleção específica de documentos na web e oferecem resultados de busca dessa coleção espe­ cífica. Mecanismos de metabusca são criados em cima dos mecanismos de busca: eles consultam diferentes mecanismos de busca simultaneamente, agregam e oferecem resultados de busca dessas fontes. Outra fonte de documentos web pesquisáveis são as bibliotecas digitais. Bibliotecas digitais podem ser definidas dc modo geral como coleções de recursos e serviços eletrônicos para a entrega dc materiais cm uma série dc formatos. Essas coleções podem incluir o catálogo da biblioteca de uma universidade, os catálogos de um grupo de universidades participantes do sistema universitário estadual, ou uma compilação de vários recursos externos na World Wide Web, como o Google Scholar ou o índice IEEE/ACM. Essas interfaces oferecem acesso universal a diferentes tipos de conteúdo — como livros, artigos, áudios e vídeos — situados em vários sistemas de banco de dados e repositórios remotos. Semelhantes a bibliotecas reais, essas cole­ ções digitais são mantidas por meio de um catálogo e organizadas em categorias para referência on-line. Bibliotecas digitais “incluem coleções pessoais, distribuídas e centralizadas, como catálogos de acesso público on-line (OPACs — on-line public access catalogs) e bancos de dados bibliográficos, bancos de dados de documentos distribuídos, listas de discussão acadêmicas c profissionais e periódicos eletrônicos, outros bancos de dados on-line, fóruns e quadros de avisos”.27

26 Agradecemos às contribuições de Pranesh P. Ranganathan e Hari P. Kumar para esta seção. 27 Covi c Kling Í1996), página 672.

945

946

Sistemas de banco de dados

27.7.1 Análise da web e seu relacionamento com a recuperação de

informações Além da navegação c busca na web, outra atividade importante, bastante rela­ cionada com a recuperação dc informações, é analisar ou minerar informações na web para novas informações de interesse. (Discutiremos a mineração de dados baseada em arquivos e bancos de dados no Capítulo 28.) A aplicação de técnicas de análise de dados para descoberta c análise de informações úteis da web é conhecida como análise da web. Durante os últimos anos, a World Wide Web surgiu como um repositório importante de informações para muitas aplicações do dia a dia para consumidores individuais, bem como uma plataforma significativa para comércio eletrônico (e-commerce) e redes sociais. Essas propriedades a tomam um alvo inte­ ressante para aplicações de análise de dados. O campo de mineração e análise da web é uma integração de uma grande gama de campos que se espalham por recuperação de informações, análise de texto, processamento em linguagem natural, mineração de dados, aprendizado de máquina e análise estatística. Os objetivos da análise da web são melhorar e personalizar a relevância dos resultados de pesquisa e identificar tendências que possam ser valiosas para diversas empresas e organizações. Elaboramos esses objetivos a seguir: ■ Encontrando informações relevantes. As pessoas normalmente procuram informa­ ções específicas na web inserindo palavras-chave em um mecanismo de busca ou navegando por portais de informação e usando serviços. Os serviços de busca são bastante restritos pelos problemas de relevância de pesquisa, pois precisam mapear c aproximar a necessidade dc informação dc milhões dc usuários como uma tarefa a priori. Ocorre uma baixa precisão (ver Seção 27.6) em decorrên­ cia dos resultados que não são relevantes ao usuário. No caso da web, a alta revocação (ver Seção 27.6) é impossível de se determinar pela incapacidade de indexar todas as páginas na web. Além disso, a medição da revocação não faz sentido, pois o usuário se preocupa apenas com os poucos documentos do topo. Os resultados mais relevantes para o usuário costumam ser apenas os primeiros poucos resultados. ■ Personalização da informação. Diferentes pessoas têm preferências distintas de conteúdo e apresentação. Diversas ferramentas de personalização usadas em aplicações e serviços baseados na web (como a monitoração por meio de clique, rastreamento de globo ocular, aprendizado do perfil de usuário explícito ou implícito c composição dinâmica dc serviço usando APIs da web) são usadas para adaptação e personalização de serviço. Um mecanismo de personaliza­ ção em geral tem algoritmos que utilizam a informação de personalização do usuário — coletada por várias ferramentas — para gerar resultados de busca específicos dele. A web tornou-se um horizonte rico, no qual as pessoas deixam seus vestígios enquanto navegam, clicam, “curtem”, comentam e compram coisas nesse espaço virtual. Essa informação tem alto valor comercial, c as empresas dc todos os tipos de bens dc consumo mincram c vendem essas informações para a segmentação de clientes. ■ Encontrar informações dc valor social. Com mais dc 1 bilhão de downloads do aplicativo Facebook em vários dispositivos Android, pode-se imaginar quão populares as diversas redes sociais se tornaram nos últimos tempos. As pessoas constroem o que é chamado de capital social nesses mundos virtuais, como o Twitter c o Facebook. O capital social refere-se às características das organizações sociais, como redes, normas e confiança social, que facilitam a coordenação c a cooperação para benefício mútuo. Os cientistas sociais estão estudando o capital

Capítulo 27

Introdução à recuperação de informações e busca na web

social e como aproveitar esse rico recurso para beneficiar a sociedade de várias maneiras. Abordamos brevemente os aspectos da pesquisa social na Seçào 27.8.2. Podemos classificar a análise da web em três categorias: análise de estrutura da web, que descobre conhecimento de hiperlinks que representam a estrutura da web; análise dc conteúdo da web, que lida com a extração dc iníormaçõcs/conhccimcnto útil do conteúdo da página web; c análise dc uso da web, que extrai os padrões dc acesso do usuário de logs de uso que registram a atividade de cada usuário. 27.7.2 Análise de estrutura da web A World Wide Web é um imenso corpo de informações, mas a localização de recursos que sejam de alta qualidade e relevantes às necessidades do usuário é muito difícil. O conjunto de páginas web tomadas como um todo quase não possui uma estrutura unificada, com variabilidade no estilo de autoria e conteúdo, tornando assim mais difícil localizar com precisão a informação necessária. Mecanismos de busca baseados em índices têm sido uma das principais ferramentas pelas quais os usuários procuram informações na web. Mecanismos de busca na web sondam a rede c criam um índice para fins de pesquisa. Quando um usuário especifica sua necessidade dc informação ao fornecer palavras-chave, esses mecanismos de busca consultam seu repositório de índices e produzem links ou URLs com conteúdo abreviado como resultados de pesquisa. Pode haver milhares de páginas relevantes a determinada consulta. Surge um problema quando somente alguns poucos resultados mais relevantes são retornados ao usuário. A discussão que tivemos sobre consulta e ranqueamento baseado em relevância nos sistemas de RI, nas seções 27.2 e 27.3, se aplica a mecanismos de busca na web. Esses algoritmos de ranqueamento exploram a estrutura de links da web. As páginas web, diferenremente das coleções de texro-padrão, contêm conexões com outras páginas web ou documentos (por meio do uso de hiperlinks), permi­ tindo que os usuários naveguem de uma página para outra. Um hiperlink tem dois componentes: uma página dc destino c um texto dc âncora que descreve o link. Por exemplo, uma pessoa pode vincular o site do Yahoo! em sua página web com um texto de âncora como “Meu site favorito na web”. Os textos de âncora podem ser imaginados como endossos implícitos. Eles oferecem uma anotação humana em potencial muito importante. Supõe-se que uma pessoa que vincula outras páginas web a partir de sua página web tenha alguma relação com essas páginas. Os mecanismos de busca na web visam a destilar resultados por sua relevância e autoridade. Existem muitos hiperlinks redundantes, como os links para a página principal (homepage) em cada página web de um site. Os mecanismos de busca precisam eliminar esses links dos resultados da busca. Um hub c uma página web ou um site que se vincula a uma coleção dc sites proeminentes (autoridades) sobre um assunto comum. Uma boa autoridade é uma página que é apontada por muitos bons hubs, ao passo que um bom hub é uma página que aponta para muitas boas autoridades. Essas idéias são usadas pelo algoritmo dc ranqueamento HITS. A próxima seção analisa rapidamente alguns dos algoritmos dc ranqueamento.

27.7.3 Analisando a estrutura de link das páginas web O objetivo da análise de estrutura da web é gerar um resumo estrutural sobre o website e as páginas web. Ela focaliza a estrutura interna dos documentos e lida com a estrutura de link usando hiperlinks entre documentos. A estrutura c o conteúdo das páginas web normalmcntc são combinados para recuperação dc informações

947

948

Sistemas de banco de dados

pelos mecanismos de busca na web. Dada uma coleção de documentos web interconectados, fatos interessantes e informativos descrevendo sua conectividade no subconjunto da web podem ser descobertos. A análise de estrutura da web também é usada para revelar a estrutura das páginas, que ajuda com a navegação e possibilita a comparação/integração de esquemas de página web. Esse aspecto da análise de estrutura da web facilita a classificação de documentos da web e o agrupamento com base na estrutura.

0 algoritmo de ranqueamento PageRank. Conforme já discutimos, os algoritmos de ranqueamento são usados para ordenar resultados de busca com base em relevância e autoridade. O Google usa o conhecido algoritmo PagcRank,28 que e baseado na “importância” dc cada página. Cada página web tem uma série dc links adiante (arestas de saída) e links de volta (arestas de entrada). É muito difícil determinar todos os links dc volta de uma página web, ao passo que é relativamente simples determinar seus links adiante. Dc acordo com o algoritmo PagcRank, páginas altamente vinculadas são mais importantes (possuem maior autoridade) que páginas com menos links. No entanto, nem todos os links de volta são importantes. Um link de volta a uma página de uma fonte confiável é mais importante que um link de alguma fonte qualquer. Assim, uma página tem um rank alto se a soma dos ranks de seus links de volta for alta. O PageRank foi uma tentativa de ver com que facilidade uma aproximação da “importância” dc uma página pode ser obtida a partir da estrutura do link. O cálculo do rank de página segue uma técnica iterativa. O PageRank de uma página web é calculado como uma soma dos PageRanks de rodos os seus links de volta. O PageRank trata a web como um modelo de Markov. Um navegador web imaginário visita uma sequência infinita de páginas clicando aleatoriamente. O PagcRank dc uma página c uma estimativa da frequência com que o navegador entra em determinada página. Ele é uma medida da importância de uma página/ nó, independente da consulta. Por exemplo, considere que P(X) seja o PagcRank de qualquer página X e C(X) seja o número de links de saída da página X, e considere que d seja o fator de amortecimento no intervalo 0 < d < 1. Em geral, d é definido como 0,85. Então, o PagcRank para uma página A pode scr calculado como:

P(A) = (1 - d) + díPíTJ/QTJ + P(T2)/C(T2) + ... + P(T„)/C(T„))

Aqui, Tp T„..., Tn são as páginas que apontam para a Página A (ou seja, são cita­ ções para a página A). O PageRank forma uma distribuição de probabilidade sobre páginas web, de modo que a soma dos PageRanks de todas as páginas web seja um.

0 algoritmo de ranqueamento HITS. O algoritmo HITS,29 proposto por Jon Kleinberg, é outro tipo de algoritmo dc ranqueamento que explora a estrutura de link da web. O algoritmo presume que um bom hub é um documento que aponta para muitos hubs, e uma boa autoridade é um documento que é apontado por muitas outras autoridades. O algoritmo contém duas etapas principais: um componente de amostragem e um componente de propagação de peso. O componente de amostra­ gem constrói uma coleção focalizada 5 dc páginas com as seguintes propriedades: 1. Sé relativamente pequena.

2. S é rica cm páginas relevantes. 3. S contém a maioria das autoridades mais fortes. O componente de peso calcula recursivamente os valores de hub e autoridade para cada documento da seguinte forma:

28 O algoritmo PagcRank foi proposto por Lawrence Page {1998) c Sergey Brin, fundadores do Google. Para obter mais informações, consulte . 29 Ver Kleinberg (1999).

Capítulo 27

Introdução à recuperação de informações e busca na web

1. Inicializa valores de hub e autoridade para todas as páginas em S ao defini-los como 1.

2. Enquanto (valores de hub e autoridade não convergem): a. Para cada página em S, calcule o valor de autoridade = soma dos valores de hub de todas as páginas apontando para a página atual. b. Para cada página cm S, calcule valor do hub = soma dos valores de autoridade dc todas as páginas apontadas pela página atual. c. Normalize os valores de hub c autoridade dc modo que a soma de todos os valores de hub cm S seja igual a 1 c a soma dc todos os valores dc autoridade em S seja igual a 1.

27.7.4 Análise de conteúdo da web Como já dissemos, a análise dc conteúdo da web refere-se ao processo de descobrir informações úteis dc conteúdo/dados/documcntos da web. Os dados dc conteúdo da web consistem cm dados desestruturados, como texto livre de documentos arma­ zenados eletronicamente, dados semiestruturados normalmente encontrados como documentos HTML, com dados de imagem embutidos, e dados mais estruturados, como dados tabulares e páginas em HTML, XML ou outras linguagens de marcação, geradas como saída de bancos de dados. De maneira mais geral, o termo conteúdo tveb refere-se a quaisquer dados reais na página web que sejam voltados para o usuário que acessa essa página. Isso costuma consistir cm texto e gráficos, mas não se limita a isso. Primeiro, discutiremos algumas tarefas preliminares de análise de conteúdo web e, depois, veremos as tarefas de análise tradicionais da classificação e agrupamento de página web.

Extração de dados estruturados. Os dados estruturados na web normalmente são muito importantes, pois representam informações essenciais, como uma tabela estruturada que mostra os horários de voo entre duas cidades. Existem várias técnicas para a extração de dados estruturados. Uma inclui a escrita dc um wrapper, ou um programa que procura diferentes características estruturais da informação na página e extrai o conteúdo correto. Outra técnica é escrever manualmente um programa de extração para cada website com base nos padrões dc formato observados do site, o que é muito trabalhoso e demorado. Isso não funciona com um número muito grande dc sites. Uma terceira técnica é a indução de wrapper ou aprendizado dc wrapper, em que o usuário primeiro rotula manualmente um conjunto de páginas de treinamento, e o sistema de aprendizado gera regras — com base nas páginas de aprendizado — que são aplicadas para extrair itens-alvo de outras páginas web. Uma quarta técnica é a automática, que visa a encontrar padrões/gramáticas das páginas web e depois usa a geração de wTapper para produzir um wrapper a fim de extrair dados automaticamente. Integração de informações da web. A web é imensa e tem milhões de documen­ tos, criados por pessoas e organizações diferentes. Por causa disso, as páginas web que contêm informações semelhantes podem ter uma sintaxe diferente e palavras distintas para descrever os mesmos conceitos. Isso cria a necessidade de integrar informações de diversas páginas web. Duas técnicas populares para a integração de informação da web são:

1. Integração dc interface dc consulta web, para habilitar a consulta de múltiplos bancos de dados na web que não são visíveis nas interfaces externas e estão ocultos na “deep web”. A deep web50 consiste nas páginas que não existem até que sejam

A deep web, conforme definida por Bergman {2001).

949

950

Sistemas de banco de dados

criadas dinamicamente como resultado de uma pesquisa de banco de dados espe­ cífica, que produz algumas das informações na página (ver Capítulo 11). Como os crawlers de mecanismo de busca tradicionais nào podem sondar c coletar informa­ ções de tais páginas, a deep web até agora tem ficado escondida deles.

2. Combinação dc esquema, como a integração dc diretórios e catálogos para chegar a um esquema global para aplicações. Um exemplo de tal aplicação seria combinar um registro de saúde pessoal de um indivíduo ao combinar e coletar dados de várias fontes dinamicamente, cruzando registros dc saúde de múltiplos sistemas. O resultado seria um registro global de saúde do indivíduo. Essas técnicas continuam sendo uma área de pesquisa ativa, e uma discussão detalhada delas está além do escopo deste livro. Consulte a bibliografia selecionada, ao final deste capítulo, para obter mais detalhes. Integração de informações baseada em ontologia. Esta tarefa envolve o uso de ontologias para efetivamente combinar informações de diversas fontes heterogêneas. Ontologias — modelos de representação formais com conceitos definidos explici­ tamente e relacionamentos nomeados vinculando-os — são usadas para resolver as questões de heterogeneidade semântica nas fontes de dados. Diferentes classes de técnicas para integração de informações usam ontologias: ■ Técnicas dc ontologia única utilizam uma ontologia global que oferece um vocabulário compartilhado para a especificação da semântica. Elas funcionam se todas as fontes de informação a serem integradas oferecerem quase a mesma visão cm um domínio dc conhecimento. Por exemplo, o UMLS (descrito na Seção 27.4.3) pode servir como uma ontologia comum para aplicações bioinédicas. ■ Em uma técnica dc ontologia múltipla, cada fonte de informação é descrita pela própria ontologia. Em princípio, a “ontologia dc origem” pode ser uma combi­ nação de várias outras ontologias, mas não se pode garantir que as diferentes “ontologias de origem” compartilham o mesmo vocabulário. Lidar com onto­ logias múltiplas, parcialmcnte sobrepostas e potcncialmcntc em conflito, é um problema muito difícil enfrentado por muitas aplicações, incluindo aquelas na área de bioinformática e outros tópicos de estudo complexos.

Criando hierarquias de conceito. Um modo comum dc organizar os resultados da pesquisa é por meio dc uma lista ranqueada linear dc documentos. Mas, para alguns usuários e aplicações, uma maneira melhor dc exibir resultados seria criar agrupamentos de documentos relacionados no resultado da busca. Um modo de organizar documentos em um resultado de pesquisa, e organizar informações em geral, é criando uma hierarquia de conceito. Os documentos em um resultado de pesquisa são organizados em grupos, em um padrão hierárquico. Outras técnicas relacionadas para organizar documentos são a classificação e o agrupamento (ver Capítulo 28). O agrupamento cria grupos de documentos, nos quais os documentos em cada grupo compartilham muitos conceitos comuns. Segmentação de páginas web e detecção de ruído. Existem muitas partes supér­ fluas em um documento web, como anúncios e painéis de navegação. A informação e o texto nessas partes supérfluas devem ser eliminados como ruído antes de classi­ ficar os documentos com base em seu conteúdo. Logo, antes de aplicar algoritmos de classificação ou agrupamento a um conjunto de documentos, as áreas ou blocos dos documentos que contêm ruído devem ser removidos.

27.7.5 Técnicas de análise do conteúdo web As duas técnicas principais para análise do conteúdo web são: (1) baseada em agente (visão RI); e (2) baseada em banco de dados (visão BD).

Capítulo 27

Introdução à recuperação de informações e busca na web

A técnica baseada em agente envolve o desenvolvimento de sistemas sofisticados de inteligência artificial que podem atuar de forma autônoma ou semiautônoma em favor de um usuário em particular, para descobrir e processar informações baseadas na web. Em geral, os sistemas de análise web baseados em agente podem ser colo­ cados nas três categorias a seguir:

■ Agentes web inteligentes são agentes de software que procuram informações relevantes usando características de um domínio de aplicação em particular (e possivelmente um perfil de usuário) para organizar e interpretar a informação descoberta. Por exemplo, um agente inteligente que recupera informações de produto de uma série de sites de vendedor utilizando apenas informações gerais sobre o domínio de produto. ■ Filtragem/categorização de informações é outra técnica que utiliza agentes web para categorizar documentos web. Esses agentes web empregam métodos da recuperação de informações e informações semânticas com base nos links entre vários documentos para organizar documentos em uma hierarquia de conceito. ■ .Agentes web personalizados são outro tipo de agentes web que utilizam as preferên­ cias pessoais dos usuários para organizar resultados de pesquisa ou descobrir infor­ mações e documentos que podem ter valor para determinado usuário. As preferências do usuário podem ser descobertas com base em escolhas de usuário anteriores, ou de outros indivíduos que se considera terem preferências semelhantes para o usuário.

A técnica baseada cm banco dc dados visa a deduzir a estrutura do website ou a transformá-lo para organizá-lo como um banco de dados de modo que possibilite melhor gerenciamento de informações e consulta na web. Essa técnica de análise de conteúdo web tenta principalmenre modelar os dados e integrá-los de modo que consultas mais sofisticadas que a pesquisa por palavra-chave possam ser realizadas. Estas poderiam ser obtidas ao encontrar o esquema de documentos web, montar um warehouse de documento web, uma base de conhecimento da web ou um banco de dados virtual. A técnica baseada em banco de dados pode usar um modelo como o Object Exchange Model (OEM),31 que representa dados semiestruturados por um grafo rotulado. Os dados no OEM são vistos como um grafo, com objetos como vértices e rótulos como arestas. Cada objeto é identificado por um identificador de objeto e um valor que é atômico — como inteiro, string, imagem G1F ou documento HTX1L — ou complexo, na forma de um conjunto de referências de objeto. O foco da técnica baseada em banco de dados tem sido com o uso de bancos de dados mulrinível e sistemas de consulta web. Um banco de dados multinível em seu nível mais baixo contém informações seiniestruturadas primitivas armazenadas em diversos repositórios da web, como documentos de hipertexto. Nos níveis mais altos, metadados ou generalizações são extraídos dos níveis mais baixos e organizados em coleções estruturadas, como bancos de dados relacionais ou orientados a objeto. Em um sistema de consulta web, as informações sobre o conteúdo e a estrutura dos documentos web são extraídas e organizadas usando técnicas tipo banco de dados. Linguagens de consulta similares à SQL podem então ser utilizadas para pesquisar c consultar documentos web. Esses tipos de consultas combinam consultas estruturais, baseadas na organização de documentos de hipertexto, e consultas baseadas em conteúdo.

27.7.6 Análise de uso da web Análise de uso da web é a aplicação das técnicas de análise dc dados para desco­ brir padrões de uso com base cm dados da web, a fim de entender e atender melhor

31 Ver Kosala e Blockeel (2000J.

951

952

Sistemas de banco de dados

às necessidades das aplicações baseadas na web. Essa atividade nào contribui dire­ tamente para a recuperação de informações, mas é importante para melhorar ou aprimorar a experiência de pesquisa dos usuários. Os dados de uso da web descrevem o padrão de uso das páginas web, como endereços IP, referências de página, data e hora dos acessos para um usuário, grupo de usuários ou uma aplicação. A análise de uso da web normalmente consiste em três fases principais: pré-processamento, descoberta dc padrão c análise de padrão. 1. Pré-processamento. O pré-processamento converte a informação coletada sobre estatísticas e padrões de uso para um formato que possa ser utilizado pelos métodos de descoberta de padrão. Por exemplo, usamos o termo visão de página para nos referir às páginas vistas ou visitadas por um usuário. Existem vários tipos dc técnicas dc pré-proccssamcnto disponíveis:

■ Pré-processamento de uso analisa os dados coletados disponíveis sobre padrões de uso dc usuários, aplicações e grupos de usuários. Como esses dados normalmente são incompletos, o processo é difícil. Técnicas de lim­ peza de dados são necessárias para eliminar o impacto de itens irrelevantes no resultado da análise. Erequentemente, os dados de uso são identificados por um endereço IP c consistem cm fluxos de diques coletados no servidor. Dados melhores estão disponíveis se um processo dc rastreamento dc uso for instalado no site do cliente. ■ Pré-proccssamcnto de conteúdo é o processo de converter texto, imagem, scripts c outro conteúdo para um formato que possa scr utilizado pela aná­ lise de uso. Em geral, isso consiste em realizar a análise de conteúdo como classificação ou agrupamento. As técnicas de agrupamento ou classificação podem agrupar informações de uso para tipos semelhantes de páginas web, dc modo que os padrões de uso podem scr descobertos para classes especí­ ficas dc páginas que descrevem tópicos em particular. As visões dc página também podem ser classificadas de acordo com seu uso intencionado, como para vendas, descoberta ou outros usos. ■ Pré-proccssamcnto dc estrutura: o pré-proccssamcnto de estrutura pode ser feito ao analisar e reformatar a informação sobre hiperlinks e estrutura entre as páginas vistas. Uma dificuldade é que a estrutura do site pode ser dinâmica e ter de ser construída para cada sessão do servidor.

2. Descoberta de padrão. As técnicas usadas na descoberta de padrão são baseadas nos métodos dos campos de estatística, aprendizado de máquina, reconhecimento dc padrão, análise de dados, mineração de dados e outras áreas semelhantes. Essas técnicas são adaptadas de modo que levem em consideração o conhecimento espe­ cífico e as características para análise da web. Por exemplo, na descoberta da regra de associação (ver Seção 28.2), a noção de uma transação para análise de cesta de mercado considera que os itens estejam desordenados. Mas a ordem de acesso das páginas web é importante, c por isso deve ser considerada na análise dc uso da web. Logo, a descoberta de padrão envolve sequências de mineração das visões de página. Em geral, ao usar dados de uso da web, os tipos de atividades de mineração de dados a seguir podem ser realizados para descoberta de padrão: ■ Análise estatística. Técnicas estatísticas são o método mais comum de extrair conhecimento sobre os visitantes de um website. Ao analisar o log da sessão, é possível aplicar medidas estatísticas como média, mediana e contagem de frequência a parâmetros como páginas vistas, tempo dc visualização por página, extensão dos caminhos de navegação entre páginas c outros parâ­ metros relevantes à análise de uso da web.

Capítulo 27

Introdução à recuperação de informações e busca na web

■ Regras de associação. No contexto da análise de uso da web, regras de asso­ ciação referem-se a conjuntos de páginas que são acessadas com um valor de suporte que excede algum limite especificado. (Veja a Seção 28.2, sobre regras de associação.) Essas páginas podem não estar conectadas direta­ mente umas às outras por hiperlinks. Por exemplo, a descoberta da regra de associação pode revelar uma correlação entre os usuários que visitaram uma página contendo produtos eletrônicos e os que visitam uma página sobre equipamento esportivo. ■ Clustering (agrupamento). No domínio de uso da web, existem dois tipos dc grupos interessantes a serem descobertos: grupos dc usuários e grupos de páginas. O agrupamento dc usuários tende a estabelecer grupos de usuários exibindo padrões de navegação semelhantes. Esse conhecimento é útil especial­ mente para deduzir as demografias dc usuários a fim de realizar segmentação dc mercado cm aplicações de comercio eletrônico (e-commcrce) ou para for­ necer conteúdo web personalizado aos usuários. O agrupamento dc páginas é baseado no conteúdo das páginas, e páginas com conteúdo semelhante são agrupadas. Este tipo de agrupamento pode ser utilizado em mecanismos de busca da internet e em ferramentas que oferecem assistência à navegação web. ■ Classificação. No domínio web, um objetivo é desenvolver um perfil de usuários pertencentes a determinada classe ou categoria. Isso exige extração e seleção de recursos que melhor descrevam as propriedades de determinada classe ou categoria de usuários. Como exemplo, um padrão interessante que pode ser descoberto seria: 60% dos usuários que fazem um pedido on-line em /Product/Books estão na faixa etária de 18 a 25 anos e moram em apar­ tamentos alugados. ■ Padrões sequenciais. Esses tipos de padrões identificam sequências de acessos à web, que podem ser usados para prever o próximo conjunto de páginas a serem acessadas por cerra classe de usuários. Esses padrões podem ser uti­ lizados por marqueteiros para produzir anúncios direcionados nas páginas web. Outro tipo de padrão sequencial pertence a quais itens normalmente são adquiridos após a compra de determinado item. Por exemplo, depois de comprar um computador, costuma-se comprar uma impressora. ■ Modelagem de dependência. A modelagem de dependência visa a determinar e a modelar dependências significativas entre as diversas variáveis no domínio da web. Como exemplo, pode-se estar interessado em montar um modelo que represente os diferentes estágios pelos quais um visitante passa enquanto compra em uma loja on-line, com base nas ações do usuário (por exemplo, ser um visitante casual ou um comprador serio em potencial).

3. Análise dc padrão. A última etapa c retirar as regras ou padrões que não são considerados de interesse com base nos padrões descobertos. Uma técnica comum para análise de padrão é usar uma linguagem de consulta como a SQL para detec­ tar diversos padrões e relacionamentos. Outra técnica envolve carregar dados de uso em um data warehouse com ferramentas de ETL e realizar operações OLAP para vê-los por várias dimensões (ver Seção 29.3). E comum utilizar técnicas de visualização, como padrões gráficos, ou atribuir cores para diferentes valores, para destacar padrões ou tendências nos dados.

27.1.1 Aplicações práticas da análise da web Análise da web. O objetivo da análise da web é entender e otimizar o desempenho do uso da web. Isso requer coleta, análise e monitoramento do desempenho dos dados

953

954

Sistemas de banco de dados

de uso da internet. A análise da web no site mede o desempenho de urn website em um contexto comercial. Esses dados normalmente são comparados com os principais indicadores de desempenho para medir a eficácia ou o desempenho do website como um todo, e podem ser usados para melhorar um site ou as estratégias de marketing. Web Spamming. Tem se tornado cada vez mais importante para empresas e indi­ víduos ter seus sites/páginas web aparecendo nos principais resultados de busca. Para conseguir isso, é essencial entender os algoritmos de ranqueamento dos mecanismos de busca e apresentar a informação na primeira página de alguém de modo que a página tenha um rank alto quando as respectivas palavras-chave forem consulta­ das. Existe uma linha tênue separando a otimização de página legítima para fins comerciais e o spamming. Web spamming, portanto, é definido como uma atividade deliberada de promover a página de alguém ao manipular os resultados retornados pelos mecanismos de busca. A análise da web pode ser usada para detectar tais páginas e descartá-las dos resultados da busca.

Segurança da web. A análise da web pode ser utilizada para encontrar padrões de uso interessantes dos websites. Se qualquer falha em um site tiver sido explorada, isso pode ser deduzido com a análise da web, permitindo assim o projeto dc sites mais robustos. Por exemplo, backdoor ou o vazamento de informações dos servidores podem ser detectados usando-se técnicas de análise da web sobre alguns dados anormais no log da aplicação web. Técnicas de análise de segurança, como detecção de intrusão e ataques de negação de serviço, são baseadas na análise de padrão de acesso da web. Web crawlers. Estes são programas que visitam páginas web e criam cópias de todas as páginas visitadas, para que possam ser processadas por um mecanismo de busca para indexação das páginas baixadas, oferecendo buscas rápidas. Outro uso dos crawlers é para verificar e manter automaticamente os websites. Por exemplo, o código HTML e os links em um website podem ser verificados e validados pelo crawler. Outro uso infeliz dos crawlers é a coleta de endereços de e-mail das páginas web, de modo que posreriormente possam ser utilizados para e-mails de spam.

27.8 Tendências na recuperação de informações Nesta seção, revisamos alguns conceitos que estão sendo considerados no trabalho de pesquisa mais recente sobre a recuperação de informações.

27.8.1 Busca facetada A busca facetada é uma técnica que permite a experiência integrada de busca e navegação, ao permitir que os usuários explorem filtrando a informação disponível. Esta técnica de busca é usada com frequência em sites de e-commerce e aplicações que permitem que usuários naveguem por um espaço de informações multidimen­ sional. Facetas geralmente são usadas para manipular três ou mais dimensões de classificação. Essas múltiplas dimensões de classificação permitem que o esquema dc classificação facetada classifique um objeto dc várias maneiras com base nos diferentes critérios taxonômicos. Por exemplo, uma página web pode ser classificada de várias maneiras: por conteúdo (companhias aéreas, música, notícias etc.); por uso (vendas, informações, registro etc.); por local; por linguagem utilizada (HTML, XML etc.) c dc outras maneiras ou facetas. Logo, o objeto pode ser classificado de várias maneiras com base cm diversas taxonomias. Uma faceta define propriedades ou características de uma classe de objetos. As pro­ priedades devem ser mutuamente exclusivas e completas. Por exemplo, uma coleção de objetos de arte podería ser classificada usando uma faceta do artista (seu nome), uma

Capítulo 27

Introdução à recuperação de informações e busca na web

faceta de época (quando a arte foi criada), uma faceta de ripo (pintura, escultura, mural etc.), uma faceta de país de origem, uma faceta dc mídia (óleo, aquarela, pedra, metal, mídia mista etc.), uma faceta de coleção (onde a arte se localiza), e assim por diante. A busca facetada utiliza a classificação facetada, que permite que um usuário navegue por informações ao longo de múltiplos caminhos, correspondentes a dife­ rentes ordenações das facetas. Isso é diferente das taxonomias tradicionais, em que a hierarquia das categorias c fixa e inalterável. O projeto Flamenco da Universidade da Califórnia em Berkeley32 é um dos primeiros exemplos de um sistema de busca facetada. A maioria dos sites de e-commerce atualmente, como Amazon ou Expedia, utiliza a busca facetada em suas interfaces, para comparar e navegar rapidamente por diversos aspectos relacionados aos critérios de busca.

27.8.2 Busca social A visão tradicional da navegação na web considera que um único usuário está procurando informações. Essa visão é contrária à pesquisa anterior por cientistas de biblioteca, que estudavam os hábitos de busca de informação dos usuários. Tal pesquisa demonstrou que outros indivíduos podem ser recursos de informação valiosos durante a busca de informações por um único usuário. Mais recentemente, a pesquisa indicou que com frequência existe cooperação direta do usuário durante a busca por informações baseada na web. zXlguns estudos informam que segmentos significativos da população de usuários estão engajados na colaboração explícita sobre tarefas de busca conjunta na web. A colaboração ativa por várias partes também ocorre em certos casos (por exemplo, ambientes dc empresa); em outras ocasiões, e talvez para a maioria das buscas, os usuários costumam interagir com outros remota, assíncrona e até mesmo involuntária e implicitamente. A busca de informações on-line habilitada socialmente (busca social) é um novo fenômeno facilitado pelas recentes tecnologias web. z\ busca social colaborativa envolve diferentes formas de envolvimento ativo nas atividades relacionadas à pesquisa, como busca colocalizada, colaboração remota em tarefas de busca, uso de rede social para busca, uso de redes especialistas, envolvimento em mineração de dados sociais ou inteligência coletiva para melhorar o processo de busca e até mesmo interações sociais para facilitar a busca de informações e a lógica. Essa atividade de busca social pode ser feita síncrona, assincronamente, colocalizada ou em espaços de trabalho compartilhados remotos. Psicólogos sociais têm experimentalmcnte validado que o ato das discussões sociais facilita o desempenho cognitivo. As pessoas nos grupos sociais podem oferecer soluções (respostas a perguntas), ponteiros para bancos de dados ou para outras pessoas (metaconhecimento), validação e legitima­ ção de idéias, e podem servir como auxílio à memória e ajuda com a reformulação de problema. A participação orientada é um processo em que as pessoas constroem conhecimento com colegas em sua comunidade. A busca de informações é em grande parte uma atividade solitária na web hoje em dia. Algum trabalho recente sobre busca colaborativa relata vários achados interessantes e o potencial dessa tecnologia para melhor acesso à informação. É cada vez mais comum ter pessoas usando redes sociais, como o Facebook, para buscar opiniões e esclarecimentos sobre diversos assuntos, além de ler críticas sobre produtos antes de fazer uma compra.

27.8.3 Acesso à informação conversational O acesso à informação conversacional é uma interação interativa e colaborativa para a localização de informações. Os participantes se engajam em uma conversação ’- Yee (20031 descreve os meradados facetados para busca por imagem.

955

956

Sistemas de banco de dados

natural de humano para humano, e agentes inteligentes escutam a conversação em segundo plano e realizam a extração dc intenções, a fim de prestar informações espe­ cíficas às necessidades dos participantes. Os agentes usam interações diretas e sutis com os participantes por intermédio de dispositivos de comunicação móveis ou de vestir. Essas interações exigem tecnologias como identificação do usuário, localização de palavras-chave, reconhecimento automático de voz, conhecimento semântico das conversas c análise de discurso como um meio de dar aos usuários indicadores mais rápidos e relevantes para as conversas. Por meio de tecnologias como as que mencio­ namos, o acesso às informações é transformado de uma atividade solitária para uma participativa. Além disso, o acesso às informações torna-se mais específico ao objetivo à medida que agentes utilizam várias tecnologias para obter informações relevantes e os participantes oferecem feedback aos agentes durante as conversações.

27.8.4 Modelagem probabilística de tópicos O crescimento sem precedentes de informações geradas com o advento da web levou a questões sobre como organizar os dados em categorias que facilitarão a disseminação correta e eficiente da informação. Por exemplo, agências de notícias internacionais,como a Reuters e a Associated Press, diariamente coletam notícias do mundo inteiro sobre negócios, esportes, política, tecnologia c assim por diante. É um

tremendo desafio organizar efetivamente essa grande quantidade de informações. Os mecanismos de pesquisa têm palavras organizadas convencionalmente e links entre documentos para torná-los acessíveis na web. Organizar as informações de acordo com os tópicos e temas dos documentos permite que os usuários naveguem pela grande quantidade de informações com base nos tópicos em que estão interessados. Para resolver esse problema, uma classe de algoritmos de aprendizado de máquina, conhecida como modelos de tópicos probabilísticos, surgiu na última década. Esses algoritmos podem organizar automaticamente grandes coleções de documentos em temas relevantes. A beleza desses algoritmos é que eles são totalmente não super­ visionados, o que significa que não precisam de nenhum conjunto de treinamento ou anotação humana para realizar essa extrapolação temática. O conceito dessa classe de algoritmos é o seguinte: todo documento é inerentemente organizado por remas. Por exemplo, documentos sobre Barack Obama podem mencionar outros presidentes, outras questões relacionadas ao governo ou um tema político específico. Um artigo sobre um dos filmes do Homem de ferro pode conter referências a outros personagens de ficção científica da serie Marvel ou geralmente tem um tema de ficção científica. Essas estruturas inerentes em documentos podem ser extraídas por métodos probabilísticos de modelagem e estimativa. Como outro exemplo, vamos supor que todo documento seja composto de uma coleção de diferentes tópicos em diferentes proporções (por exemplo, um documento sobre política também pode ser sobre presidentes e história estadunidense). Além disso, cada tópico é composto por uma coleção de palavras. Ao considerar a Figura 27.6, podemos supor que o documento D, que menciona os presidentes dos EUA Barack Obama e George W. Bush, pode pertencer aos tópicos Presidentes, Políticos, Democratas, Republicanos e Governantes. Em geral, os tópi­ cos compartilham um vocabulário fixo de palavras. Esse vocabulário é extraído da coleção de documentos para os quais desejamos treinar os modelos de tópicos. Em geral, escolhemos o número de tópicos que desejamos extrair da coleção. Cada tópico classifica as palavras de maneira diferente, de acordo com a frequência com que uma palavra é representada sob um determinado tópico em diferentes documentos. Na Figura 27.6, as barras que representam as proporções do tópico devem totalizar 1. O Documento D pertence principalmente ao tópico Presidentes, conforme mostrado

Capítulo 27

Introdução à recuperação de informações e busca na web

Presidentes (Tópico)

Barack Obama George W. Bush Bill Clinton politica defesa militares casa branca Ronald Reagan Jimmy Carter Richard Nixon

Documento D

Barack Obama membro do Partido Republicano é o 4

959

960

Sistemas de banco de dados

27.9 Resumo Neste capítulo, analisamos uma área importante, chamada recuperação de informa­ ções (RI), que está intimamente relacionada com bancos de dados. Com o advento da web, dados desestruturados contendo texto, imagens, áudio e vídeo estão se proliferando em velocidades fenomenais. Embora os sistemas de gerenciamento de banco de dados tenham uma boa relação com dados estruturados, os dados desestruturados que contêm diversos tipos de dados estão sendo armazenados principalmente em repositórios de informações ocasionais na web, que estão disponíveis para consumo principalmente por meio de sistemas de RI. Google, Yahoo e mecanismos de busca semelhantes são sistemas de RI que tomam os avanços nesse campo prontamente disponíveis para o usuário final comum, dando-lhes uma experiência de busca mais rica, com melhoria contínua. Começamos, na Seção 27.1, introduzindo o campo de RI na Seção 27.1.1 e comparando a RI e as tecnologias de banco de dados na Seção 27.1.2. Um breve histórico da RI foi apresentado na Seção 27.1.3,e os modos de consulta e navegação da interação nos sistemas RI foram apresentados na Seção 27.1.4. Na Seção 27.2, apresentamos os diversos modelos de recuperação, incluindo mode­ los booleanos, espaço de vetor, probabilístico e semântico. Eles permitem medir se um documento é relevante a uma consulta de usuário e oferecer heurísticas de medição de semelhança. Xa Seção 27.3, apresentamos diferentes tipos de consultas — além de con­ sultas baseadas em palavra-chave, que são dominantes, existem outros tipos, incluindo booleano, frase, proximidade, linguagem natural e outros, para os quais precisa ser fornecido um suporte explícito pelo modelo de recuperação. O pré-processamento de textos é importante nos sistemas de RI, e na Seção 27.4 foram discutidas diversas atividades, como remoção de stopword, raízes e o uso de tesauro. Depois, discutimos a construção e o uso dc índices invertidos na Seção 27.5, que estão no núcleo dos sistemas de RI c contribuem para fatores que envolvem eficiência da busca. Depois, na Seção 27.6 discutimos diversas métricas de avaliação, como a precisão da revoca­ ção e F-score, para medir a adequação dos resultados das consultas em RI. Também discutimos sobre o mecanismo de código livre para indexação e busca, Lucene, e sua extensão, chamada Solr. O feedback de relevância foi analisado rapidamente — é importante modificar e melhorar a recuperação dc informações pertinentes para o usuário por meio dc sua interação c engajamento no processo dc busca. Na Seção 27.7, fizemos uma introdução um tanto detalhada à análise da web, relacionada à recuperação de informações. Dividimos esse tratamento na análise dc conteúdo, estrutura e uso da web. A busca na web foi discutida, incluindo uma análise da estrutura dc link da web (Seção 27.7.3), seguida por uma introdução aos algoritmos para ranqueamento dos resultados dc uma busca na web, como PageRank e HITS. Por fim, na Seção 27.8, discutimos rapidamente as tendências atuais, incluindo buscas facetada, social e conversacional. Também apresentamos a modelagem probabilísrica de tópicos de documentos e uma técnica popular, chamada alocação latente de Dirichlet (LDA). Terminamos o capítulo com uma discussão dos sistemas de resposta a perguntas (Seção 27.8.5), que estão se tornando muito populares, e o uso de ferramentas como Siri da Apple e Cortana da Xlicrosoft. Este capítulo ofereceu um tratamento introdutório a um campo muito vasto, e o leitor interessado deverá consultar o material especializado em recuperação de informações e mecanismos de busca, na bibliografia ao final deste capítulo.

PERGUNTAS DE REVISÃO -----------------------------------------------------------------------27.1.

O que são dados estruturados e dados desestruturados? Dê um exemplo de cada um conforme sua experiência.

Capítulo 27

27.2. 27.3. 27.4. 27.5. 27.6. 27.7. 27.8.

27.9.

27.10. 27.11. 27.12. 27.13. 27.14. 27.15. 27.16. 27.17. 27.18. 27.19. 27.20. 27.21. 27.22. 27.23. 27.24. 27.25.

27.26. 27.27. 27.28. 27.29. 27.30. 27.31.

Introdução à recuperação de informações e busca na web

Dê uma definição geral de recuperação de informações (RI). O que a recu­ peração de informações envolve quando consideramos informações na web? Discuta os tipos de dados e os tipos de usuários nos sistemas de recuperação de informações de hoje. O que significa busca navegacional, informativa e transforniativa? Quais são os dois modos principais de interação com um sistema de RI? Descreva com exemplos. Explique as principais diferenças entre banco de dados e sistemas de RI mencionados na Tabela 27.1. Descreva os principais componentes do sistema de RI mostrado na Figura 27.1. O que são bibliotecas digitais? Que tipos de dados normalmente são encon­ trados nelas? Cite algumas bibliotecas digitais que você acessou. O que elas contêm e até que ponto no passado os dados vão? Cite um rápido histórico da RI e mencione os marcos no desenvolvimento nessa área. O que é o modelo booleano de RI? Quais são suas limitações? O que é o modelo dc espaço de vetor da RI? Como um vetor é construído para representar um documento? Defina o esquema TF-IDF de determinação do peso de uma palavra-chave em um documento. Qual é a necessidade de incluir IDF no peso dc um termo? O que são os modelos probabilistic© e semântico da RI? Defina revocação e precisão nos sistemas de RI. Dê a definição de precisão e revocação em uma lista ranqueada de resultados na posição /. De que forma o F-score é definido como uma medida de recuperação de informação? De que modo ele considera precisão e revocação? Quais são os diferentes tipos de consultas em um sistema de RI? Descreva cada um com um exemplo. Quais são as técnicas para o processamento de consultas por frase e proximidade? Descreva o processo de RI detalhado mostrado na Figura 27.2. O que sâo remoção de stopword c uso dc raízes? Por que esses processos são necessários para uma melhor recuperação dc informação? O que é um tesauro? Como ele é benéfico à RI? O que é extração de informação? Quais são os diferentes tipos de extração de informação do texto estruturado? O que são vocabulários nos sistemas de RI? Que papel eles desempenham na indexação de documentos? Recupere cinco documentos com cerca de três sentenças cada um com algum conteúdo relacionado. Construa um índice invertido de todas as raízes importantes (palavras-chave) desses documentos. Descreva o processo de construção do resultado de uma solicitação de pes­ quisa usando um índice invertido. Defina feedback de relevância. Descreva os três tipos de análises da web discutidos neste capítulo. Liste as tarefas importantes mencionadas que estão envolvidas na análise do conteúdo da web. Descreva cada uma com algumas sentenças. Quais são as três categorias de análise dc conteúdo da web baseada em agente mencionadas neste capítulo? O que é a técnica baseada em banco de dados para a análise do conteúdo da web? O que são sistemas de consulta da web?

961

962

Sistemas de banco de dados

27.32. Quais algoritmos sào populares no ranqueamento ou na determinação da importância das páginas web? Que algoritmo foi proposto pelos fundadores da Google? 27.33. Qual é a ideia básica por trás do algoritmo PageRank? 27.34. O que são hubs e páginas de autoridade? Como o algoritmo HITS usa esses conceitos? 27.35. O que você pode descobrir com a análise dc uso da web? Que dados ela gera? 27.36. Que operações de mineração costumam ser realizadas sobre os dados de uso da web? Dê um exemplo de cada. 27.37. Quais são as aplicações da mineração de uso da web? 27.38. O que é relevância dc busca? Como cia é determinada? 27.39. Defina busca facetada. Crie um conjunto de facetas para um banco de dados que contenha todos os tipos de prédios. Por exemplo, duas facetas poderiam ser “valor ou preço do prédio” e “tipo de prédio (residencial, comercial, depósito, fábrica etc.)”. 27.40. O que é busca social? O que a busca social colaborativa envolve? 27.41. Defina c explique busca conversational. 27.42. Defina modelagem de tópicos. 27.43. Como funcionam os sistemas de resposta a perguntas?

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

As tecnologias de recuperação e busca de informações são áreas de pesquisa e desenvolvimento ativas nos setores industrial e acadêmico. Existem muitos livros-texto sobre Rl que oferecem uma discussão detalhada sobre o material que apresentamos rapidamente neste capítulo. O livro intitulado Search Engines: Information Retrieval in Practice, de Croft, Metzler e Strohman (2009), oferece uma visão geral prática dos conceitos e princípios de mecanismo de busca. Introduction to Information Retrieval, de Manning, Raghavan e Schutze (2008), é um livro definitivo sobre recuperação de informações. Outro livro-texto introdutório em Rl é Modern Information Retrieval, de Ricardo Baeza-Yates e Berthier Ribeiro-Neto (1999), que oferece uma cobertura detalhada dos diversos aspectos da tecnologia de Rl. Os livros clássicos de Gerald Salton (1968) e Van Rijsbergen (1979) sobre recuperação de informações fornecem excelentes descrições da pesquisa de base feita no campo de RI até o final da década de 1960. Salton também introduziu o modelo de espaço de vetor como um modelo de RI. Manning e Schutze (1999) oferecem um bom resumo das tecnologias de lin­ guagem natural e pré-processamento de texto. “Interactive Information Retrieval in Digital Environments”, de Xie (2008), oferece uma boa abordagem centrada em seres humanos para a recuperação de informações. O livro Managing Gigabytes, de Witten, Moffat e Bell (1999), oferece discussões detalhadas para técnicas de indexação. O livro TREC, de Voorhees e Harman (2005), faz uma descrição dos procedimentos de coleta e avaliação de teste no contexto das competições TREC. Broder (2002) classifica consultas da web cm três classes distintas — navegacio­ nal, informativa e transacional — e apresenta uma taxonomia detalhada da busca na web. Covi e Kling (1996) dão uma definição ampla para bibliotecas digitais e discutem as dimensões organizacionais do uso eficaz da biblioteca digital. Luhn (1957) realizou algum trabalho iniciai cm RI na IBM, na década dc 1950, sobre autoindexação e inteligência dc negócios. O sistema SMART (Salton et al., 1993), desenvolvido na Cornell, foi um dos primeiros sistemas dc RI avançados que usavam

Capítulo 27

Introdução à recuperação de informações e busca na web

indexação de termo totalmente automática, clustering (agrupamento) hierárquico e pontuação de documentos por grau de semelhança com a consulta. O sistema SMART representava documentos e consultas como vetores de termo ponderados de acordo com o modelo de espaço de vetor. Porter (1980) tem o crédito pelos algoritmos de raízes fracas e fortes que se tornaram padrões. Robertson (1997) desenvolveu um esquema de peso sofisticado no sistema Okapi da City University dc Londres, que se tornou muito popular nas competições TREC. Lenat (1995) iniciou o projeto Cyc na década de 1980 para incorporar lógica formal e bases de conhecimento nos sistemas de processamento de informações. Os esforços para a criação do tesauro WordNet continuaram na década de 1990 e ainda estão em andamento. Os conceitos e princípios do WordNet são des­ critos no livro de Fellba um (1998). Rocchio (1971) descreve o algoritmo dc feedback de relevância, que é abordado no livro dc Salton (1971) sobre The SMART Retrieval System-Experiments in Automatic Document Processing (O sistema de recuperação SMART — experimentos em processamento automático de documentos). Abiteboul, Buneman e Suciu (1999) oferecem uma discussão extensa dos dados na web em seu livro que enfatiza dados semiestruturados. Atzeni e Mendclzon (2000) escreveram um editorial no jornal VLDB sobre bancos dc dados c a web. Atzeni et al. (2002) propuseram modelos e transformações para dados baseados na web. Abiteboul et al. (1997) propuseram a linguagem de consulta Lord para gerenciar dados semiestruturados. Chakrabarti (2002) é um excelente livro sobre descoberta dc conhecimento com base na web. O livro dc Liu (2006) consiste cm várias partes, cada uma oferecendo uma visão geral abrangente dos conceitos envolvidos na análise de dados da web e suas aplicações. Excelentes artigos de estudo sobre análise da web são Kosala e Blockeel (2000) e Liu et al. (2004). Etzioni (1996) oferece um bom ponto de partida para entender a mineração da web e descreve as tarefas e as questões relacionadas com a World Wide Web. Uma excelente visão geral das questões dc pesquisa, téc­ nicas c esforços dc desenvolvimento associados ao conteúdo da web c análise de uso é apresentada por Cooley et al. (1997). Cooley (2003) focaliza a mineração de padrões de uso da web por meio do uso da estrutura da web. Spiliopoulou (2000) descreve a análise de uso da web com detalhes. A mineração da web baseada na estrutura dc página é descrita cm Madria et al. (1999) c Chakraborti et al. (1999). Os algoritmos para calcular o rank dc uma página web são dados por Page et al. (1999), que descrevem o famoso algoritmo PagcRank, e por Kleinberg (1998), que apresenta o algoritmo HITS. Harth, Hose e Schenkel (2014) apresentam técnicas para consulta e gerenciamento de dados vinculados na web e mostram o potencial dessas técnicas para aplicações de pesquisa e comerciais. A tecnologia de resposta a perguntas é descrita com alguns detalhes por Ferrucci et al. (2010), que desenvolveram o sistema Watson da IBM. Bikel e Zitouni (2012) é um guia abrangente para o desenvolvimento de sistemas NLP (processamento em linguagem natural) multilíngues poderosos e precisos. Blei, Ng e Jordan (2003) oferecem uma visão geral sobre a modelagem dc tópicos e a alocação latente de Dirichlet. Para um guia profundo e prático sobre as tecnologias Lucene e Solr, consulte o livro Enterprise Lucene and Solr, dc Moczar (2015).

963

as últimas décadas, muitas organizações têm gerado uma grande quantidade de dados legíveis à máquina na forma de arquivos e bancos de dados. Para processar esses dados, temos a tecnologia de banco de dados disponível, que dá suporte a linguagens de consulta como a SQL. No entanto, a SQL é uma linguagem estruturada, que supõe que o usuário está ciente do esquema do banco de dados. A SQL dá suporte a operações da álgebra relacionai que permitem que um usuário selecione linhas e colunas de dados das tabelas ou informações relacionadas à junção de tabelas com base em campos comuns. No próximo capítulo, veremos que a tecnologia de data warehouse proporciona vários tipos dc funcionalidade: de consolidação, agregação e resumo dc dados. Os data warehouses (ou armazéns de dados) nos permitem ver a mesma informação por várias dimensões. Neste capítulo, voltaremos nossa atenção para outra área de interesse muito popular, conhecida como mineração de dados (ou data mining). Como o termo indica, mineração de dados refere-se à mineração ou descoberta de novas informações em termos de padrões ou regras com base em grandes quantidades de dados. Para ser útil na prática, a mineração de dados precisa ser executada dc modo eficiente sobre grandes arquivos e bancos dc dados. Embora alguns recursos de mineração de dados estejam sendo fornecidos em SGBDRs, ela não é bem integrada aos sistemas de gerenciamento de banco de dados. O mundo dos negócios atualmente está fascinado pelo potencial da mineração dc dados, e esse campo é chamado popularmente de inteligência dc negócios ou análise de dados. Vamos revisar rapidamente os conceitos e princípios básicos desse vasto campo da mineração de dados, que utiliza técnicas de áreas como aprendizado de máquina, esta­ tística, redes neurais e algoritmos genéticos. Destacaremos a natureza da informação que é descoberta, os tipos de problemas enfrentados quando se tenra minerar bancos de dados e os tipos de aplicações da mineração de dados.Também analisaremos o que há de mais moderno em uma série de ferramentas comerciais disponíveis (ver Seção 28.7) e descreveremos vários avanços de pesquisa necessários para tornar essa área viável.

N

966

Sistemas de banco de dados

28.1 Visão geral da tecnologia de mineração de dados Em relatórios como o popular Gartner Report,1 a mineração de dados tem sido aclamada como uma das principais tecnologias para o futuro próximo. Nesta seção, relacionamos a mineração de dados à área mais ampla, chamada descoberta de conhecimento,, e comparamos as duas utilizando um exemplo ilustrativo.

28.1.1 Mineração de dados versus data warehousing O objetivo de um data warehouse (ver Capítulo 29) é dar suporte à tomada de decisão com dados. A mineração de dados pode ser usada com um data warehouse para ajudar com certos tipos de decisões. A mineração de dados pode ser aplicada a bancos de dados operacionais com transações individuais. Para tomar a mineração de dados mais eficiente, o data warehouse deve ter uma coleção de dados agregada ou resumida. A mineração de dados ajuda na extração de novos padrões significativos que não necessariamente podem ser encontrados apenas ao consultar ou proces­ sar dados ou metadados no data warehouse. Portanto, as aplicações de mineração de dados devem ser forremente consideradas desde cedo, durante o projeto de um dara warehouse. Além disso, ferramentas de mineração de dados devem ser projetadas para facilitar seu uso com data warehouse. De fato, para grandes bancos de dados, que rodam terabytes ou ate petabytes dc dados, o uso bem-sucedido das aplicações de mineração dc dados dependerá, primeiro, da construção de um data warehouse.

28.1.2 Mineração de dados como parte do processo de descoberta de conhecimento A descoberta de conhecimento nos bancos de dados, abreviada como KDD (knowledge discovery in databases), normalmente abrange mais que a mineração de dados. O processo de descoberta de conhecimento compreende seis fases:2 seleção de dados, limpeza de dados, enriquecimento, transformação ou codificação de dados, mineração de dados e o relatório e exibição da informação descoberta. Como exemplo, considere um banco de dados de transação mantido por um revendedor de bens de consumo especializados. Suponha que os dados do cliente incluam um nome de cliente, CEP, número de telefone, dara de compra, código do item, preço, quantidade e valor total. Uma grande quantidade de conhecimento novo pode ser descoberta pelo processamento KDD nesse banco de dados de cliente. Durante a seleção de dados, dados sobre itens específicos ou categorias de itens, ou de lojas em uma região ou área específica do país, podem ser selecionados. O processo de limpeza de dados, então, pode corrigir códigos postais inválidos ou eliminar registros com prefixos de telefone incorretos. O enriquecimento normal­ mente melhora os dados com fontes dc informação adicionais. Por exemplo, dados os nomes do cliente e números de telefone, a loja pode adquirir outros dados sobre idade, renda e avaliação de crédito e anexá-los a cada registro. A transformação de dados e a codificação podem ser feitas para reduzir a quantidade de dados. Por exemplo, os códigos de item podem ser agrupados em relação a categorias de pro­ dutos, em áudio, vídeo, suprimentos, aparelhos eletrônicos, câmera, acessórios, e assim por diante. Os CEPs podem ser agregados em regiões geográficas, as rendas

1 O Gartner Report c um exemplo das muitas publicações dc pesquisa de tecnologia que os gerentes corporativos utilizam para discutir a respeito e selecionar tecnologias de mineração de dados.

- Esta discussão é em grande parte baseada cm Adriaans c Zantinge (19961.

Capitulo 28

Conceitos de mineração de dados

podem ser divididas em faixas, e assim por diante. Na Figura 29.1, mostraremos uma etapa chamada limpeza como um precursor para a criação do data warehouse. Se a mineração de dados for baseada em um data warehouse existente para essa cadeia de varejo, podemos esperar que a limpeza já tenha sido aplicada. E somente depois do pré-processamento que as técnicas de mineração de dados são usadas para extrair diferentes regras e padrões. O resultado da mineração pode ser descobrir o seguinte tipo dc informação nova: ■ Regras de associação — por exemplo, sempre que um cliente compra um equi­ pamento de vídeo, ele também compra outro aparelho eletrônico. ■ Padrões sequenciais — por exemplo, suponha que um cliente compre uma câmera e dentro de três meses ele compre suprimentos fotográficos, depois, dentro de seis meses, ele provavelmente comprará um irem de acessório. Isso define um padrão sequencial de transações. Um cliente que compra mais que o dobro em períodos fracos provavelmente poderá comprar pelo menos uma vez durante o período dc Natal. ■ Arvores dc classificação — por exemplo, os clientes podem scr classificados por frequência dc visitas, tipos dc financiamento utilizado, valor da compra ou afinidade para tipos de itens; algumas estatísticas reveladoras podem ser geradas para essas classes. Conforme mostra esse exemplo de loja de varejo, a mineração de dados precisa scr precedida por uma preparação significativa nos dados, antes dc gerar informações úteis que possam influenciar dirctamente as decisões dc negócios. Os resultados da mineração de dados podem ser informados em diversos forma­ tos, como listagens, saídas gráficas, tabelas de resumo ou visualizações.

28.1.3 Objetivos da mineração de dados e da descoberta de conhecimento A mineração de dados costuma ser executada com alguns objetivos finais ou aplicações. De modo geral, esses objetivos se encontram nas seguintes classes: pre­ visão, identificação, classificação e otimização.

■ Previsão. A mineração de dados pode mostrar como certos atributos dos dados se comportarão no futuro. Alguns exemplos de mineração de dados previsível incluem a análise de transações de compra para prever o que os consumidores comprarão sob certos descontos, quanto volume de vendas uma loja gerará em determinado período e se a exclusão dc uma linha dc produtos gerará mais lucros. Em tais aplicações, a lógica dc negócios é usada com a mineração dc dados. Em um contexto científico, certos padrões de onda sísmica podem prever um terre­ moto com alta probabilidade. ■ Identificação. Os padrões de dados podem ser usados para identificar a existência de um item, um evento ou uma atividade. Por exemplo, intrusos tentando que­ brar um sistema podem ser identificados pelos programas executados, arquivos acessados e tempo de CPU por sessão. Em aplicações biológicas, a existência dc um gene pode scr identificada por certas sequências de símbolos de nucleotídcos na sequência dc DNA. A área conhecida como autenticação é uma forma dc identificação. Ela confirma se um usuário é realmente um usuário específico ou de uma classe autorizada, e envolve uma comparação de parâmetros, imagens ou sinais contra um banco de dados. ■ Classificação. A mineração de dados pode parricionar os dados de modo que dife­ rentes classes ou categorias possam ser identificadas com base em combinações de parâmetros. Por exemplo, clientes cm um supermercado podem scr categorizados

967

968

Sistemas de banco de dados

em compradores que buscam descontos, compradores com pressa, compradores regulares leais, compradores ligados a marcas conhecidas e compradores eventuais. Essa classificação pode ser usada em diferentes análises de transações de compra do cliente como uma atividade pós-mineraçào. Às vezes, a classificação baseada em

conhecimento de domínio comum é utilizada como uma entrada para decompor o problema dc mineração e torná-lo mais simples. Por exemplo, alimentos saudáveis, alimentos para festas ou alimentos para lanche escolar são categorias distintas nos negócios do supermercado. Faz sentido analisar os relacionamentos dentro e entre categorias como problemas separados. Essa categorização pode servir para codificar os dados corretamente antes de submetê-los a mais mineração de dados. ■ Otimização. Um eventual objetivo da mineração de dados pode ser otimizar o uso de recursos limitados, como tempo, espaço, dinheiro ou materiais e maximizar variá­ veis de saída como vendas ou lucros sob determinado conjunto de restrições. Como tal, esse objetivo da mineração dc dados c semelhante à função objetiva, usada em problemas de pesquisa operacional, que lida com otimização sob restrições.

O termo mineração de dados é popularmente usado em um sentido amplo. Em algumas situações, ele inclui análise estatística e otimização restrita, bem como aprendizado dc máquina. Não existe uma linha nítida separando a mineração de dados dessas disciplinas. Portanto, está fora do nosso escopo neste texto discutii; com detalhes, toda a gama dc aplicações que compõem esse vasto corpo de traba­ lho. Para compreender o assunto com detalhes, os leitores poderão consultar livros especializados, dedicados à mineração de dados.

28.1.4 Tipos de conhecimento descoberto durante a mineração de dados O termo conhecimento é interpretado de forma livre como algo que envolve algum grau de inteligência. Há uma progressão de dados brutos da informação ao conhecimento, enquanto passamos pelo processamento adicional. O conhecimento normalmente c classificado como indutivo versus dedutivo. O conhecimento dedu­ tivo deduz novas informações com base na aplicação de regras lógicas previamente especificadas de dedução sobre o dado indicado. A mineração de dados aborda o conhecimento indutivo, que descobre novas regras e padrões com base nos dados fornecidos. O conhecimento pode ser representado de várias maneiras: em um sentido desestruturado, ele pode ser representado por regras ou pela lógica proposicional. Em uma forma estruturada, ele pode ser representado em árvores de decisão, redes semânticas, redes neurais ou hierarquias de classes ou frames. E comum descrever o conhecimento descoberto durante a mineração de dados da seguinte forma: ■ Regras dc associação. Estas regras correlacionam a presença dc um conjunto de itens com outra faixa dc valores para outro conjunto de variáveis. Exemplos: (1) Quando uma compradora adquire uma bolsa, ela provavelmente compra sapatos. (2) Uma imagem de raio X contendo características a e b provavelmente também exibe a característica c. ■ Hierarquias de classificação. O objetivo é trabalhar partindo de um conjunto existente de eventos ou transações para criar uma hierarquia de classes. Exemplos: (1) Uma população pode ser dividida cm cinco faixas de possibilidade dc crédito com base em um histórico dc transações de crédito anteriores. (2) Um modelo pode ser desenvolvido para os fatores que determinam o desejo de obter a locali­ zação de loja em uma escala de 1 a 10. (3) Companhias de investimentos podem ser classificadas com base nos dados de desempenho usando características como crescimento, volume de negócios e estabilidade.

Capitulo 28

Conceitos de mineração de dados

969

■ Padrões sequenciais. Uma sequência de ações ou eventos é buscada. Exemplo: se um paciente passou por uma cirurgia de ponte de safena para artérias bloqueadas e um aneurisma e, depois, apresentou ureia sanguínea alta em até um ano após a cirurgia,ele provavelmente sofrerá de insuficiência renal nos próximos 18 meses. A detecção de padrões sequenciais é equivalente à detecção de associações entre eventos com certos relacionamentos temporais. ■ Padrões dentro de série temporal. As semelhanças podem ser detectadas dentro de posições de uma série temporal de dados, que é uma sequência de dados tomados em intervalos regulares, como vendas diárias ou preços de ações dc fechamento diário. Exemplos: (1) As ações dc uma companhia dc energia, ABC Eólica, c uma companhia financeira, XYZ Criptomocdas, mostraram o mesmo padrão durante 2018 em matéria de preços de fechamento de ações. (2) Dois produtos mostraram o mesmo padrão de vendas no verão, mas um padrão diferente no inverno. (3) Um padrão no vento magnético solar pode scr usado para prever mudanças nas condições atmosféricas da Terra. ■ Agrupamento. Determinada população de eventos ou itens pode ser particionada (segmentada) cm conjuntos dc elementos “semelhantes”. Exemplos: (1) Uma população inteira de dados dc tratamento sobre uma doença pode scr dividida cm grupos com base na semelhança dos efeitos colaterais produzidos. (2) A população adulta no Brasil pode ser categorizada em cinco grupos, desde com maior proba­ bilidade de comprar até com menor probabilidade de comprar um novo produto. (3) Os acessos à web feitos por uma coleção dc usuários contra um conjunto de documentos (digamos, em uma biblioteca digital) podem ser analisados em relação às palavras-chave dos documentos, para revelar grupos ou categorias de usuários. Para a maioria das aplicações, o conhecimento desejado é uma combinação dos tipos citados. Expandimos cada um desses tipos dc conhecimento nas próximas seções.

28.2 Regras de associação 28.2.1 Modelo de cesta de mercado, suporte e confiança Uma das principais tecnologias em mineração dc dados envolve a descoberta dc regras dc associação. O banco dc dados é considerado uma coleção dc transações, cada uma envolvendo um conjunto de itens. Um exemplo comum é o dc dados dc cesta de mercado. Aqui, a cesta de mercado corresponde aos conjuntos de itens que um consumidor compra em um supermercado durante uma visita. Considere quatro dessas transações cm uma amostra aleatória exibida na Eigura 28.1. Uma regra dc associação tem a forma X => Y, em que X = (xp x2,...» xn] c Y = (yp y2, •••» sã° conjuntos de itens, com xt e y; sendo itens distintos para todo i e todo /. Essa associação indica que, se um cliente compra X, ele ou ela provavel­ mente também comprará Y. Em geral, qualquer regra de associação tem a forma LHS (lado esquerdo ou left-hand side) => RHS (lado direito ou right-hand side).

Id transação

ltens comprados

Hora

101

6:35

leite, pão, biscoito, suco

792

7:38

leite, suco

1130

8:05

leite, ovos

1735

8:40

pão, biscoito, café

Figura 28.1 Exemplo de

transações no modelo de cesta

de mercado.

970

Sistemas de banco de dados

cm que LHS c RHS sâo conjuntos dc itens. O conjunto LHS U RHS c chamado dc conjunto dc itens (ou itemset), o conjunto dos itens comprados pelos clientes. Para que uma regra de associação seja de interesse para um minerador de dados, a regra deve satisfazer alguma medida dc interesse. Duas medidas dc interesse comuns sâo suporte e confiança. O suporte para uma regra LHS => RHS é com relação ao conjunto de itens; ele se refere à frequência com que um conjunto de itens específico ocorre no banco de dados. Ou seja, o suporte é o percentual de transações que contêm todos os itens no conjunto de itens LHS U RHS. Se o suporte for baixo, isso implica que não existe evidência forte de que os itens em LHS U RHS ocorrem juntos, pois o conjunto dc itens ocorre cm apenas uma pequena fração das transações. Outro termo para suporte é prevalência da regra. A confiança é com relação à implicação mostrada na regra. A confiança da regra LHS => RHS é calculada como o suporte(LHS U RHS)/suporte(LHS). Podemos pensar nela como a probabilidade dc que os itens no RHS sejam comprados, dado que os itens no LSH são comprados por um cliente. Outro termo para confiança é força da regra. Como um exemplo de suporte e confiança, considere as duas regras a seguir: leite => suco e pão => suco. Examinando nossas quatro transações de exemplo na Figura 28.1, vemos que o suporte de {leite, suco) é 50% e o suporte de |pão, suco) é apenas 25%. A confiança dc leite => suco é de 66,7% (significando que, das três transações em que ocorre leite, duas contêm suco) e a confiança de pão => suco é de 50% (significando que uma de duas transações que contêm pão também contém suco). Como podemos ver, o suporte e a confiança não necessariamente andam lado a lado. O objetivo da mineração de regras de associação, então, é gerar todas as regras possíveis que excedem alguns patamares mínimos dc suporte e confiança especifi­ cados pelo usuário. O problema, portanto, é decomposto cm dois subproblemas:

1. Gerar todos os conjuntos de itens que têm um suporte que excede o patamar. Esses conjuntos de itens são chamados de grandes conjuntos de itens (ou frequentes). Observe que “grande" aqui significa “grande suporte".

2. Para cada conjunto de itens grande, todas as regras que têm uma confiança mínima são geradas da seguinte forma: para um conjunto dc itens grande X e Y C X, considere que Z = X - Y; então, se suporte(X)/suporte(Z) > confiança mínima, a regra Z => Y (ou seja, X - Y => Y) é uma regra válida. A geração de regras usando todos os grandes conjuntos de itens e seus suportes é rclativamente simples. Porém, descobrir todos os conjuntos de itens com o valor para seu suporte é um problema difícil se a cardinalidade do conjunto de itens for muito alta. Um supermercado típico possui milhares de itens. O número de conjuntos de itens distintos é 2W, em queméo número de itens, e contar o suporte para todos os conjuntos de itens possíveis torna-se uma tarefa que exige uma computação intensa. Para reduzir o espaço de pesquisa combinatória, os algoritmos para encontrar regras de associação utilizam as seguintes propriedades: ■ Um subconjunto de um grande conjunto de itens também deve ser grande (ou seja, cada subconjunto de um grande conjunto de itens excede o suporte mínimo exigido). ■ Reciproca men te, um superconjunto de um conjunto de itens pequeno também é pequeno (implicando que ele não tem suporte suficiente).

A primeira propriedade é conhecida como fechamento para baixo. A segunda pro­ priedade, chamada antimonotonicidade, ajuda a reduzir o espaço de busca de possíveis soluções. Ou seja, quando se descobre que um conjunto de itens é pequeno (não um

Capitulo 28

Conceitos de mineração de dados

grande conjunto de itens), qualquer extensão a esse conjunto de itens, formada ao acres­ centar um ou mais itens ao conjunto, também gerará um conjunto de itens pequeno.

28.2.2 Algoritmo Apriori O primeiro algoritmo a usar as propriedades de fechamento para baixo e antimonotonicidade foi o algoritmo Apriori, mostrado como o Algoritmo 28.1. Ilustramos o Algoritmo 28.1 utilizando os dados de transação da Figura 28.1 que usam um suporte mínimo de 0,5. Os conjuntos de itens 1 candidatos são {leite, pão, suco, biscoito, ovos, café} e seus respectivos suportes são 0,75, 0,5, 0,5, 0,5, 0,25 e 0,25. Os quatro primeiros itens se qualificam para L,, pois cada suporte é maior ou igual a 0,5. Na primeira iteração do loop repita, estendemos os conjuntos de itens 1 frequentes para criar os conjuntos dc itens 2 frequentes candidatos, C2. C2 contém {leite, pão}, {leite, suco}, {pão, suco}, {leite, biscoito}, {pão, biscoito} c {suco, biscoito}. Observe, por exemplo, que {leite, ovos} não aparece em C2, pois {ovos} é pequeno (pela propriedade da antimonotonicidade) e não aparece em Lf. O suporte para os seis conjuntos contidos em C2 são 0,25, 0,5, 0,25, 0,25, 0,5 e 0,25 e são calculados com a varredura do conjunto de transações. Somente o segundo conjunto de itens 2 {leite, suco} e o quinto conjunto de itens 2 {pão, biscoito} têm suporte maior ou igual a 0,5. Esses dois conjuntos de itens 2 formam os conjuntos de itens 2 frequentes, L2. Algoritmo 28.1. Algoritmo Apriori para encontrar (grandes) conjuntos de itens frequentes Entrada: Banco dc dados D dc m transações, c um suporte mínimo, min$y repre­ sentado como uma fração de m. Saída: Conjuntos de itens frequentes, Lp L2,..., Lk Início /* passos ou instruções são numeradas para aumentar a legibilidade * /

1. Calcule suporte(z;) = conta(í;)/m para cada item individual, q,í2,..., in fazendo a varredura do banco dc dados uma vez c contando o número dc transações em que o item z; aparece (ou seja, conta(/;)); 2. O conjunto de itens 1 frequente candidato, Cp será o conjunto dc itens q, *2» —» 3. O subconjunto de itens contendo /• de C1 em que suporte(ip >= mins torna-se o conjunto dc itens 1 frequente, L,;

4. k=\; termina = false; repita

1.

= (conjunto vazio);

2. Crie o conjunto de itens (£+1) frequente candidato, CÀ+I, combinando membros dc Lk que tem k-\ itens em comum (isso forma os conjuntos de itens (£+1) frequentes candidatos ao estender scletivamentc os conjuntos de itens k frequentes por um item); 3. Além disso, apenas considere como elementos de Ct+I os k+A itens tais que cada subconjunto de tamanho k apareça cm Lk; 4. Faça a varredura do banco de dados uma vez e calcule o suporte para cada membro dc Cfctl; se o suporte para um membro de Ct>1 >= mins, então acres­ cente o membro cm Lt+1;

5. Se Lkti for vazio, então termina = true, se não, k = k + 1; até que; Fim;

971

972

Sistemas de banco de dados

Na próxima iteração do loop repita, construímos conjuntos de itens 3 frequen­ tes candidatos acrescentando itens adicionais aos conjuntos em L2. Contudo, para nenhuma extensão de conjuntos de itens em L2 todos os subconjuntos de itens 2 estarão contidos em L2. P°r exemplo, considere (leite, suco, pão); o conjunto de itens 2 (leite, pão) não está em L2, logo (leite, suco, pão) não pode ser um conjunto de itens 3 frequente pela propriedade de fechamento para baixo. Nesse ponto, o algoritmo termina com L, igual a {{leite}, {pão}, {suco}, {biscoito}} c L2 igual a {{leite, suco}, {pão, biscoito}}. Vários outros algoritmos foram propostos para minerar regras de associação. Eles variam principalmente em relação a como os conjuntos de itens candidatos são gera­ dos e como os suportes para os conjuntos de itens candidatos são contados. Alguns algoritmos usam essas estruturas dc dados como mapas de bits e árvores de hash para manter informações sobre conjuntos de itens. Vários algoritmos foram propostos para usar múltiplas varreduras do banco de dados, pois o número em potencial de conjuntos de itens, 2W, pode ser muito grande para configurar contadores durante uma única varredura. Examinaremos três algoritmos melhorados (em comparação com o algoritmo Apriori) para mineração da regra de associação: o algoritmo de amostragem, o algoritmo dc árvore dc padrão frequente c o algoritmo dc partição.

28.2.3 Algoritmo de amostragem A ideia principal para o algoritmo de amostragem é selecionar uma amostra pequena, que caiba na memória principal, do banco de dados de transações e deter­ minar os conjuntos dc itens frequentes com base nessa amostra. Se esses conjuntos de itens frequentes formarem um superconjunto dos conjuntos de itens frequentes para o banco de dados inteiro, podemos determinar os conjuntos de itens frequentes reais fazendo a varredura do restante do banco de dados a fim de calcular os valores de suporte exatos para os conjuntos de itens do superconjunto. Um superconjunto dos conjuntos de itens frequentes em geral pode ser encontrado na amostra usando, por exemplo, o algoritmo Apriori, com um suporte mínimo reduzido. Em casos raros, alguns conjuntos de itens frequentes podem ser perdidos e é necessária uma segunda varredura do banco de dados. Para decidir se quaisquer conjuntos de itens frequentes foram perdidos, o conceito de borda negativa é usado. A borda negativa com relação a um conjunto de itens frequente, S, e conjunto de itens, /, sào os conjuntos de itens mínimos contidos em PowerSet(J) e não cm S. A ideia básica c que a borda negativa dc conjunto dc itens frequentes contém os con­ juntos de itens mais próximos que também poderíam ser frequentes. Considere o caso em que um conjunto X não está contido nos conjuntos de itens frequentes. Se todos os subconjuntos de X estiverem contidos no conjunto de conjuntos de itens frequentes, então X estaria na borda negativa. Ilustramos isso com o exemplo a seguir. Considere o conjunto de itens I = {A, B, C, D, Ej e que os conjuntos de itens frequentes combinados de tamanho 1 a 3 sejam S= {(A), (B|, {C}, |D|, |AB|, {AC}, {BC}, (AD), {CD}, {ABC}}. A borda negativa é {{E|, {BD}, {ACD}}. O conjunto {E} éo único conjunto de itens 1 não contido em S, |BDJ é o único conjunto de itens 2 que não está em S, mas cujos subconjuntos do conjunto de itens 1 estão, e {ACD} é o único conjunto de itens 3 cujos subconjuntos do conjunto de itens 2 estão todos em S. A borda negativa é importante, pois é necessária para determinar o suporte para esses conjuntos de itens na borda negativa, garantindo que nenhum grande conjunto de itens se perca da análise dos dados de amostra. O suporte para a borda negativa é determinado quando o restante do banco de dados é varrido. Se descobrirmos que um conjunto de itens X na borda negativa pertence ao conjunto de todos os conjuntos de itens frequentes, então existe um

Capitulo 28

Conceitos de mineração de dados

potencial para um superconjunto de X também ser frequente. Se isso acontecer, uma segunda passada pelo banco de dados é necessária para garantir que todos os conjuntos de itens frequentes sejam localizados.

28.2.4 Algoritmo de árvore de padrão frequente (FP) e de

crescimento FP O algoritmo dc árvore dc padrão frequente (árvore FP) é motivado pelo fato de os algoritmos baseados no algoritmo Apriori poderem gerar e testar um número muito grande de conjuntos de itens candidatos. Por exemplo, com 1.000 conjuntos de itens 1 frequentes, o algoritmo Apriori teria de gerar pooo'i l 2 7 ou 499.500 conjuntos de itens 2 candidatos. O algoritmo dc crescimento FP c uma técnica que elimina a geração de um grande número de conjuntos de itens candidatos. O algoritmo primeiro produz uma versão compactada do banco de dados em rela­ ção a uma árvore FP (árvore de padrão frequente). A árvore FP armazena informações relevantes do conjunto dc itens c permite a descoberta eficiente dc conjuntos dc itens frequentes. O processo real de mineração adota uma estratégia de dividir e conquistag em que o processo de mineração é decomposto em um conjunto de tarefas menores que cada um opera em uma árvore FP condicional, um subconjunto (projeção) da árvore original. Para começar, examinamos como a árvore FP é construída. O banco de dados primeiro é varrido e os conjuntos de itens 1 frequentes com seu suporte são calculados. Com esse algoritmo, o suporte é a contagem dc transações que contem o item cm vez da fração de transações contendo o item. Os conjuntos de itens 1 frequentes são então classificados em ordem decrescente de seu suporte. Em seguida, a raiz da árvore FP é criada com um rótulo NULL. O banco de dados é varrido uma segunda vez e, para cada transação Tno banco dc dados, os conjuntos de itens 1 mais frequentes cm T sào colo­ cados na ordem que foi feita com os conjuntos dc itens 1 frequentes. Podemos designar essa lista ordenada para T como consistindo em um primeiro item, a cabeça, e os itens restantes, a cauda. A informação do conjunto de itens (cabeça, cauda) é inserida na árvore FP recursivamente, começando no nó raiz, da seguinte forma:

1. Se o nó atual, N, da árvore FP tiver um filho com um nome dc item = cabeça, incremente o contador associado ao nó N cm 1, senão, crie outro nó, N, com uma contagem de 1, vincule N a seu pai e vincule N à tabela do cabeçalho do item (usada para travessia eficiente da árvore).

2. Se a cauda não for vazia, repita a etapa (1) usando como lista ordenada somente a cauda, ou seja, a antiga cabeça é removida, a nova cabeça é o primeiro item da cauda e os itens restantes tornam-se a nova cauda. A tabela de cabeçalho do item, criada durante o processo de construção da árvore FP, contém três campos por entrada para cada item frequente: identificador de item, contador de suporte e link de nó. O identificador de item e o contador de suporte são autoexplicativos. O link do nó é um ponteiro para uma ocorrência desse irem na árvore FP. Como várias ocorrências de um único item podem aparecer na árvore FP, esses itens são vinculados como uma lista cm que seu início é apontado pelo link do nó na tabela de cabeçalho do item. Ilustramos a construção da árvore FP com os dados de transação da Figura 28.1. Vamos usar um suporte mínimo de 2. Uma passada pelas quatro transações gera os seguintes conjuntos de itens 1 frequentes com suporte associado: {{(leite, 3)}, {(pâo, 2)), {(biscoito, 2)}, {(suco, 2))). O banco de dados é varrido uma segunda vez c cada transação será processada novamente.

973

974

Sistemas de banco de dados

Para a primeira transação,criamos a lista ordenada, T = (leite, pão, biscoito, suco). Os itens em T são conjuntos de itens 1 frequentes com base na primeira transação. Os itens são ordenados com base na ordem decrescente do contador dos conjuntos de itens 1 encontrados na passada 1 (ou seja, leite primeiro, pão em segundo, e assim por diante). Criamos um nó raiz NULL para a árvore FP e inserimos leite como um filho da raiz, pão como um filho de leite, biscoito como um filho de pào e suco como um filho de biscoito. Ajustamos as entradas para os itens frequentes na tabela de cabeçalho do item. Para a segunda transação, temos a lista ordenada {leite, suco). Começando na raiz, vemos que o nó filho com rótulo leite existe, de modo que movemos para esse nó e atualizamos seu contador (para considerar a segunda transação que contém leite). Vemos que não existe filho do nó atual com rótulo suco, então criamos um nó com o rótulo suco. A tabela de cabeçalho do item é ajustada. terceira transação só tem um item frequente, {leite}. Novamente, começando na raiz, vemos que o nó com o rótulo leite existe, de modo que passamos para esse nó, incrementamos seu contador e ajustamos a tabela de cabeçalho do item. A transação final contém itens frequentes, {pão, biscoito). No nó raiz, vemos que não existe um filho com o rótulo pão. Assim, criamos outro filho da raiz, inicializamos seu contador e depois inserimos biscoito como um filho desse nó, inicializando seu contador. Depois que a tabela de cabeçalho do item é atualizada, acabamos ficando com a árvore FP e a tabela de cabeçalho do item, como mostra a Figura 28.2. Se examinarmos essa árvore FP, vemos que ela realmente representa as transações originais em um formato compactado (ou seja, apenas mostrando os itens de cada transação que são grandes conjuntos de itens 1). O /Ylgoritmo 28.2 é usado para mineração da árvore FP para padrões frequentes. Com a árvore FP, é possível encontrar rodos os padrões frequentes que contêm deter­ minado item frequente, começando da tabela de cabeçalho do item para esse item e atravessando os links do nó na árvore FP. O algoritmo começa com um conjunto de itens 1 frequente (padrão dc sufixo) c constrói sua base dc padrão condicional e depois sua árvore FP condicional. A base de padrão condicional é composta por um conjunto de caminhos de prefixo, ou seja, onde o irem frequente é um sufixo. Por exemplo, se considerarmos o item suco, vemos pela Figura 28.2 que existem dois caminhos na árvore FP que terminam com suco: (leite, pão, biscoito, suco) e (leite, suco). Os dois caminhos de prefixo associados são (leite, pão, biscoito) e (leite). A árvore FP condicional é construída a partir dos padrões na base de padrão condicional. A mineração é realizada recursivamente nessa árvore FP. Os padrões frequentes são formados ao concatenar o padrão de sufixo com os padrões frequentes produzidos de uma árvore FP condicional. Figura 28.2 Árvore FP e tabela

NULL

de cabeçalho do item.

Leite: 3

Item

Suporte

Leite

3

Pão

2

Biscoito

2

Suco

2

Pão: 1

Link Pão: 1

Biscoito: 1

1

Suco:1

Suco: 1 k 1 11 1

1 1 1 1 — 11

Biscoito: 1

|

Capitulo 28

Conceitos de mineração de dados

Algoritmo 28.2. Algoritmo de crescimento FP para localizar conjuntos de itens frequentes

Entrada: Arvore FP e um suporte mínimo, mins Saída: Padrões frequentes (conjuntos de itens) procedimcnto-crescimento-FP (árvore, alfa); Início se árvore contém um único caminho P então para cada combinação, beta, dos nós no caminho gera padrão (beta U alfa) com suporte = suporte mínimo de nós cm beta senão para cada item, i, no cabeçalho da árvore faça início gera padrão beta = (/ U alfa) com suporte = /.suporte; constrói base de padrão condicional de beta; constrói árvore FP condicional de beta, árvore_beta; se árvore_beta não está vazio então crescimento-FP(árvore_beta, beta); fim; Fim;

Ilustramos o algoritmo usando os dados da Figura 28.1 e a árvore da Figura 28.2. O procedimento crescimento-FP é chamado com dois parâmetros: a árvore FP original e NULL para a variável alfa. Como a árvore FP original tem mais que um único caminho, executamos a parte senào da primeira instrução se. Começamos com o item frequente, suco. Examinaremos os itens frequentes em ordem de menor suporte (ou seja, da última entrada na tabela para a primeira). A variável beta c definida como suco com suporte igual a dois. Seguindo o link do nó na tabela de cabeçalho do item, construímos a base de padrão condicional que consiste em dois caminhos (com suco como sufixo). Estes são (leite, pão, biscoito: 1) e (leite: 1). A árvore FP condicional consiste em apenas um único nó, leite: 2. Isso se deve a um suporte dc apenas 1 para o nó pão e biscoito, que está abaixo do suporte mínimo de 2. O algoritmo é chamado recursivamente com uma árvore FP de apenas um único nó (ou seja, leite: 2) e um valor beta de suco. Como essa árvore FP tem apenas um caminho, rodas as combinações de beta e nós no caminho são geradas — ou seja, (leite, suco) — com suporte de 2. Em seguida, o item frequente, biscoito, é utilizado. A variável beta é definida como biscoito com suporte = 2. Seguindo o link do nó na tabela de cabeçalho do irem, construímos a base de padrão condicional que consiste em dois caminhos. Estes são (leite, pão: 1) e (pão: 1). A árvore FP condicional tem apenas um único nó, pão: 2. O algoritmo é chamado recursivamente com uma árvore FP de apenas um único nó (ou seja, pão: 2) e um valor beta dc biscoito. Como essa árvore FP só tem um caminho, todas as combinações de beta e nós no caminho são geradas, ou seja, (pão, biscoito) com suporte de 2. O item frequente, pão, é considerado em seguida. z\ variável beta é definida como pão com suporte = 2. Seguindo o link do nó na tabela de cabeçalho do irem, construímos a base de padrão condicional que consiste em um caminho, que é (leite: 1). A árvore FP condicional é vazia, pois a contagem é menor que o suporte mínimo. Como a árvore FP condicional é vazia, nenhum padrão frequente será gerado. O último irem frequente a considerar é leite. Esse é o item do topo na tabela de cabeçalho do item e, como tal, tem uma base de padrão condicional vazia e árvore FP condicional vazia. Em resultado, nenhum padrão frequente é acrescentado. O resultado

975

976

Sistemas de banco de dados

de execução do algoritmo são os seguintes padrões frequentes (ou conjuntos de itens) com seu suporte: {{leite: 3}, {pão: 2}, {biscoito: 2|, {suco: 2|, {leite, suco: 2}, {pào, biscoito: 2}|.

28.2.5 Algoritmo de partição Outro algoritmo, chamado algoritmo de partição,-' é resumido a seguir. Se recebermos um banco de dados com um pequeno número de grandes conjuntos de itens em potencial, digamos, alguns milhares, o suporte para todos eles pode ser testado em uma só varredura usando uma técnica dc particionamento. O particionamento divide o banco de dados cm subconjuntos não sobrepostos; estes são individualmente considerados como bancos de dados separados e todos os grandes conjuntos de itens para essa partição, chamados conjuntos de itens frequentes locais, são gerados em uma passada. O algoritmo Apriori pode então ser usado dc modo eficiente em cada partição se couber inteiramente na memória principal. As partições são escolhidas de modo que cada uma possa ser acomodada na memória principal. Como tal, uma partição é lida apenas uma vez em cada passada. A única desvantagem com esse método é que o suporte mínimo usado para cada partição tem um significado ligeiramente diferente do valor original. O suporte mínimo é baseado no tamanho da partição, em vez de no tamanho do banco de dados, para determinar os grandes conjuntos de itens frequentes locais. O valor do patamar dc suporte real é o mesmo dado anteriormente, mas o suporte é calculado apenas para uma partição. Ao final da passada um, recuperamos a união de todos os conjuntos de itens frequentes de cada partição. Isso forma os conjuntos de itens frequentes candidatos globais para o banco dc dados inteiro. Quando essas listas são mescladas, elas podem conter alguns falsos positivos. Ou seja, alguns dos grandes conjuntos dc itens que são frequentes em uma partição podem não se qualificar em várias outras partições e, portanto, podem não exceder o suporte mínimo quando o banco de dados original for considerado. Observe que não existem falsos negativos; nenhum grande conjunto de itens será perdido. Os grandes conjuntos de itens candidatos globais identificados na passada 1 são verificados na passada 2; ou seja, seu suporte real é medido para o banco de dados inteiro. Ao final da fase 2, todos os grandes conjuntos de itens globais são identificados. O algoritmo de partição serve naturalmente para uma implementação paralela ou distribuída, para melhorar a eficiência. Foram sugeridas outras melhorias nesse algoritmo.* 4

28.2.6 Outros tipos de regras de associação Regras de associação entre hierarquias. Existem cerros tipos de associações que são particularmente interessantes por um motivo especial. Essas associações ocorrem entre hierarquias de itens. Em geral, é possível dividir os itens entre hierarquias disjuntas com base na natureza do domínio. Por exemplo, alimentos em um supermer­ cado, itens em uma loja de departamentos ou artigos em uma loja de esportes podem ser categorizados em classes e subclasses que fazem surgir hierarquias. Considere a Figura 28.3, que mostra a taxonomia de itens em um supermercado. A figura mos­ tra duas hierarquias — bebidas e sobremesas, respectiva men te. Os grupos inteiros podem não produzir associações da forma bebidas => sobremesas, ou sobremesas => bebidas. Porém, associações do tipo iogurte congelado de marca saudável => água engarrafada, ou sorvete de marca cremosa => cooler de vinho podem produzir confiança e suporte suficientes para serem regras dc associação válidas de interesse. 5 Ver cm Savasere et al. (1995) os detalhes do algoritmo, as estruturas de dados usadas para implemen­ tá-lo e suas comparações de desempenho. 4 Ver Cheung et al. (1996» e Lin e Dunham (1998).

Capitulo 28

Conceitos de mineração de dados

977

Figura 28.3 Taxonomia de

itens em um supermercado.

Laranja

Maçã

Outros

Natural

Mineral

Portanto, se a área de aplicação tiver uma classificação natural dos conjuntos de itens cm hierarquias, descobrir associações dentro das hierarquias não tem qualquer interesse particular. Aquelas de interesse específico são associações entre hierarquias. Elas podem ocorrer entre agrupamentos de item em diferentes níveis.

Associações multidimensionais. A descoberta dc regras de associação envolve a procura por padrões em um arquivo. Na Figura 28.1, temos um exemplo de arquivo de transações de cliente com três dimensões: Id_transação, Hora e Itens_comprados. Porém, nossas tarefas e algoritmos de mineração de dados apresentados até este ponto só envolvem uma dimensão: Itcns_comprados. A regra a seguir é um exemplo de inclusão do rótulo da única dimensão: Itcns_comprados( leite) => Itens_comprados (suco). Pode ser interessante encontrar regras de associação que envolvam múltiplas dimensões, por exemplo, Hora(6:30...8:00) => Itens_comprados( leite). Regras como estas são chamadas de regras de associação multidimensionais. As dimensões repre­ sentam atributos de registros de um arquivo ou, em matéria de relações, colunas de linhas de uma relação, e podem ser categóricas ou quantitativas. Os atributos categóricos têm um conjunto finito dc valores que não exibem qualquer relaciona­ mento dc ordenação. Atributos quantitativos são numéricos c seus valores exibem um relacionamento de ordenação, por exemplo, 75.000). Daqui, o algoritmo do tipo Apriori típico, ou uma de suas variantes, pode ser usado para a mineração de regra, pois os atributos quantitativos agora se parecem com atributos categóricos. Outra técnica para o particionamento é agrupar valores de atributo com base na distribuição de dados (por exemplo, par­ ticionamento de mesma profundidade), e atribuir valores inteiros a cada partição. O particionamento nesse estágio pode ser relativamente bom, ou seja, um número

978

Sistemas de banco de dados

maior de intervalos. Depois, durante o processo de mineração, essas partições podem ser combinadas com outras partições adjacentes se seu suporte for menor que algum valor máximo predefinido. Um algoritmo de tipo /Xpriori pode ser usado aqui, bem como para a mineração de dados. Associações negativas. O problema da descoberta de uma associação negativa é mais difícil que o da descoberta de uma associação positiva. Uma associação negativa tem o seguinte ripo: 60% dos clientes que compram batatas fritas nào compram água engarrafada. (Aqui, os 60% referem-se à confiança para a regra de associação negativa.) Em um banco de dados com 10.000 itens, existem 210.000 combinações possíveis dc itens, c a maioria deles não aparece nem uma vez no banco de dados. Se a ausência de certa combinação de itens significar uma associação negativa, potencialmente temos milhões e milhões de regras de associação negativa com RHSs que não são de nosso interesse. O problema, então, é encontrar apenas regras negativas de interesse. Em geral, estamos interessados cm casos cm que dois conjuntos específicos de itens aparecem muito raramente na mesma transação. Isso impõe dois problemas:

1. Para um estoque total de 10.000 itens, a probabilidade de dois quaisquer serem comprados juntos é (1/10.000) * (1/10.000) = 10"8. Se descobrirmos que o suporte real para esses dois ocorrerem juntos é zero, isso não representa um desvio signi­ ficativo da expectativa e, portanto, não é uma associação (negativa) interessante.

2. O outro problema é mais sério. Estamos procurando combinações de itens com suporte muito baixo, c existem milhões c milhões com suporte baixo ou mesmo zero. Por exemplo, um conjunto de dados de 10 milhões de transações tem a maioria dos 2,5 bilhões de combinações de pares de 10.000 itens faltando. Isso geraria bilhões de regras inúteis. Portanto, para tomar as regras de associação negativas interessantes, temos de usar o conhecimento prévio sobre os conjuntos de itens. Uma das técnicas é empregar hierarquias. Suponha que utilizemos as hierarquias de refrigerantes e batatas fritas mostradas na Figura 28.4. Uma associação positiva forte foi mostrada entre refrigerantes e batatas fritas. Sc encontrarmos um suporte grande para o fato dc que, quando os clientes com­ pram batatas fritas Lisas, eles predominantemente compram Cola e não Soda e não Guaraná, isso seria interessante, pois normalmente esperaríamos que, se houvesse uma associação forte entre Lisas e Cola, também deveria haver uma associação forte entre Lisas e Soda ou Lisas e Guaraná.5 Nos agrupamentos de iogurte congelado e água engarrafada, mostrados na Figura 28.3, suponha que a divisão entre Baixas calorias e Saudável seja 80-20 e a divisão das categorias Natural e Mineral seja 60-40 entre as respectivas categorias. Isso daria uma probabilidade conjunta de um iogurte congelado natural ser com­ prado com água engarrafada natural como 48% entre as transações que contêm um iogurte congelado e água engarrafada. Se esse suporte, porém, for de apenas 20%, isso indicaria uma associação negativa significativa entre o iogurte Baixas calorias e a água engarrafada Natural; mais uma vez, isso seria interessante. Figura 28.4 Hierarquia simples

Batatas fritas

Refrigerantes

de refrigerantes e batatas fritas.

Soda

Guaraná

Cola

Lisa

Ondulada

Palha

5 Para simplificar, estamos considerando uma distribuição uniforme de transações entre os membros de uma hierarquia.

Capitulo 28

Conceitos de mineração de dados

O problema de encontrar associação negativa é importante nas situações ante­ riormente citadas, dado o conhecimento de domínio na forma de hierarquias dc generalização de item (ou seja, as hierarquias dadas de bebida e sobremesa mostradas na Figura 28.3),as associações positivas existentes (como entre os grupos de iogurte congelado e água engarrafada) e a distribuição dos itens (como as marcas dentro de grupos relacionados). O escopo da descoberta de associações negativas é limitado em relação ao conhecimento das hierarquias c distribuições dc itens. O crescimento cxponcncial dc associações negativas continua sendo um desafio.

28.2.7 Considerações adicionais para regras de associação Minerar regras de associação nos bancos de dados da vida real é complicado pelos seguintes fatores: ■ A cardinalidade dos conjuntos de itens na maioria das situações é extremamente grande, e o volume de transações é muito alto também. Alguns bancos de dados operacionais nos setores de varejo e comunicações coletam dezenas de milhões de transações por dia. ■ As transações mostram variabilidade em fatores como localização geográfica e sazonalidade, dificultando a amostragem. ■ As classificações de itens existem ao longo de múltiplas dimensões. Logo, con­ trolar o processo de descoberta com conhecimento de domínio, particularmente para regras negativas, é bastante difícil. ■ A qualidade dos dados é variável; existem problemas significativos com dados faltando, errôneos e em conflito, bem como dados redundantes em muitos setores.

28.3 Classificação Classificação é o processo de aprender um modelo que descreve diferentes classes de dados. As classes são predefinidas. Por exemplo, em uma aplicação bancária, os clientes que solicitam um cartão de crédito podem scr classificados como risco fraco, risco médio ou risco bom. Logo, esse tipo dc atividade também é chamado de aprendizado supervisionado. Quando o modelo é criado, ele pode ser usado para classificar novos dados. O primeiro passo — aprendizado do modelo — é realizado com um conjunto de treinamento de dados que já foram classificados. Cada registro nos dados de treinamento contém um atributo, chamado rótulo de classe, que indica a que classe o registro pertence. O modelo produzido costuma scr na forma dc uma árvore dc decisão ou um conjunto dc regras. Algumas das questões importantes com relação ao modelo e o algoritmo que produz o modelo incluem a capacidade do modelo de prever a classe correta de novos dados, o custo computacional associado ao algoritmo e a escalabilidade do algoritmo. Examinaremos a técnica cm que nosso modelo está na forma dc uma árvore dc decisão. Uma árvore dc decisão é simplesmente uma representação gráfica da descrição de cada classe ou, em outras palavras, uma representação das regras de classificação. Uma árvore de decisão de exemplo é representada na Figura 28.5. Vemos, pela Figura 28.5, que se um cliente for casado e se o salário for £ 50K, ele tem um risco bom para um cartão de crédito bancário. Essa é uma das regras que descrevem a classe risco bom. Atravessar a árvore de decisão saindo da raiz para cada nó folha forma outras regras para essa classe e as duas outras classes. O /Ylgoritmo 28.3 mostra o procedimento para construir uma árvore de decisão com base em um conjunto de dados de treinamento. Inicialmente, todas as amostras de treinamento estão na raiz da árvore. As amostras são particionadas de maneira recursiva com

979

980

Sistemas de banco de dados

Figura 28.5 Árvore de decisão

da amostra para aplicações de cartão de crédito.

base nos atributos selecionados. O atributo usado em um nó para particionar as amostras é aquele com o melhor critério de divisão, por exemplo, o que maximiza a medida de ganho da informação. Algoritmo 28.3. Algoritmo para indução da árvore de decisão Entrada: Conjunto de registros de dados de treinamento: R p R2, •••» e conjunto de atributos: A,, A,,..., An

Saída: Arvore de decisão procedimento Construcao_arvore (registros, atributos); Início crie um nó N; se todos os registros pertencem à mesma classe C, então retorna N como nó folha com rótulo de classe C; se atributos é vazio então retorna N como nó folha com rótulo de classe C, de modo que a maioria dos registros pertença a ele; seleciona atributo At (com o ganho de informação mais alto) dos atributos; rotula nó N com A,; para cada valor conhecido, v-y de A- faça início acrescenta um ramo do nó N para a condição A- = p;; S{ = subconjunto de registros em que A} = se S- é vazio então inclua uma folha, L, com rótulo de classe C, tal que a maioria dos registros pertença a ela e retome L senão inclui o nó retornado por Contrucao_arvore(S;, atributos - AJ; fim; Fim;

Antes de ilustrarmos o Algoritmo 28.3, explicaremos a medida do ganho dc infor­ mação com mais detalhes. O uso de entropia como medida de ganho de informação é motivado pelo objetivo de minimizar a informação necessária para classificar os dados de amostra nas partições resultantes e, assim, minimizar o número esperado

Capitulo 28

Conceitos de mineração de dados

981

de testes condicionais necessários para classificar um novo registro. A informação esperada necessária para classificar dados de treinamento de s amostras, nas quais o atributo Classe tem n valores (t/p ..., vn) e s, é o número de amostras pertencentes ao rótulo de classe é dada por /(^,S2>...,Sr,)=-tpilog;p,

i=l

em que p- é a probabilidade de que uma amostra aleatória pertença à classe com rótulo Uma estimativa para p- é s/s. Considere um atributo A com valores (vp vm] usado como atributo de teste para divisão na árvore de decisão. O atributo A particiona as amostras nos subconjuntos Sp..., Sni nos quais amostras em cada têm um valor de V; para o atributo A. Cada S; pode conter amostras que pertencem a qualquer uma das classes. O número de amostras em S- que pertencem à classe i pode ser indicado como s/;. A entropia associada ao uso do atributo A como atributo de teste é definida como E(A)=É^+s+S* X/fo ...... Sj j=l

d

/(í]-, $-) pode ser definido utilizando a formulação para /(sp ..., sj com p- sendo substituído por p~, em que pz/ = sJSj. Agora, o ganho de informação ao particionar no atributo A, Ganho(A), é definido como /($,, ..., $„) - E(A). Podemos usar os dados de treinamento de amostra da Figura 28.6 para ilustrar o algoritmo. O atributo RID representa o identificador dc registro usado para identificar um registro individual c é um atributo interno. Nós o utilizamos para identificar um regis­ tro em particular em nosso exemplo. Primeiro, calculamos a informação esperada necessária para classificar os dados de treinamento de seis registros como /($p s2), nos quais existem duas classes: o primeiro valor de rótulo de classe corresponde a sim e o segundo, a não. Assim,

2(3,3) = - 0,5log, 0,5 - 0,51og2 0,5 = 1 Agora,calculamos a entropia para cada um dos quatro atributos,como mostrado a seguir. Para Casado = sim, temos sn = 2, s21 = 1 e /(slp s21) = 0,92. Para Casado = não, temos sI2 = 1, s22 = 2 e /($12, $22) = 0,92. Portanto, a informação esperada necessária para classificar uma amostra usando o atributo Casado como atributo de particionamento é

E(Casado) = 3/6 /(slp s21) + 3/6 /(sI2, s22) = 0,92

O ganho na informação, Ganho(Casado), seria 1 - 0,92 = 0,08. Sc seguirmos etapas semelhantes para calcular o ganho com relação aos outros três atributos, acabamos com RID

Casado

Salário

Saldo conta

Idade

Emprestar

não

>=50 K

=25

sim

2

sim

>=50 K

>=5K

>=25

sim

3

sim

20K.. .50K

P = x,

A escolha depende de podermos prever um valor único de P ou um intervalo de valores para P. Se considerarmos P uma função: P = f (teste 1, teste 2,..., teste n)

985

986

Sistemas de banco de dados

a função é denominada função de regressão para prever P. Em geral, se a função aparece como

Y = /'(X„X2, e f é linear nas variáveis de domínio o processo de derivar f de um conjunto dado de tuplas para é denominado regressão linear. A regressão linear é uma técnica estatística comumentc utilizada para ajustar um conjunto dc observações ou pontos em w dimensões com a variável de destino y. A análise de regressão é uma ferramenta muito comum para análise de dados cm diversos domínios de pesquisa. A descoberta da função para prever a variável dc destino c equivalente a uma operação dc mineração dc dados.

28.5.4 Redes neurais Uma rede neural é uma técnica derivada da pesquisa de inteligência artificial que usa a regressão generalizada e oferece um método iterative para executá-la. As redes neurais usam a técnica dc ajuste dc curva para deduzir uma função a partir dc um conjunto dc amostras. Esta técnica oferece um foco de aprendizado; ela é controlada por uma amostra de teste usada para a inferência e o aprendizado iniciais. Com esse tipo de método de aprendizado, as respostas às novas entradas podem ser capazes de ser interpoladas com base nas amostras conhecidas. Essa interpolação, porém, depende do modelo do mundo (representação interna do domínio do problema) desenvolvido pelo método de aprendizado. As redes neurais podem ser classificadas dc modo geral cm duas categorias: redes supervisionadas c não supervisionadas. Métodos adaptativos que tentam reduzir o erro da saída são métodos de aprendizado supervisionado, enquanto os que desen­ volvem representações internas sem saídas de amostra são denominados métodos de aprendizado não supervisionado. As redes neurais se autoadaptam; ou seja, elas aprendem pela informação sobre um problema específico. Elas funcionam bem em tarefas de classificação e, portanto, são úteis na mineração de dados. Xlesmo assim, elas não estão livres de problemas. Embora aprendam, não oferecem uma boa representação do que aprenderam. Suas saídas são altamente quantitativas e difíceis de entender. Como outra limitação, as representações internas desenvolvidas por redes neurais não são únicas. Além disso, em geral, as redes neurais enfrentam problemas na modelagem dos dados de séries temporais. .Apesar desses inconvenientes, elas são populares e constantemente usadas por vários vendedores comerciais.

28.5.5 Algoritmos genéticos Algoritmos genéticos (GAs — genetic algorithms) são uma classe de procedi­ mentos dc pesquisa aleatórios capazes dc realizar pesquisa adaptativa c robusta por uma grande faixa dc topologias dc espaço de pesquisa. Modelados com base no surgimento adaptativo de espécies biológicas de mecanismos evolucionários, e introduzidos por Holland,6 os GAs têm sido aplicados com sucesso em campos tão diversificados quanto análise dc imagens, escalonamento c projeto dc engenharia. Os algoritmos genéticos estendem a ideia da genética humana do alfabeto de quatro letras (com base nos nucleotídeos A, C, T, G) do código de DNA humano. A construção de um algoritmo genético envolve a idealização de um alfabeto que codifica as soluções para o problema de decisão em matéria de sequências desse 6 O trabalho inicial de Holland (1975), intitulado Adaptation in Natural and Artificial Systems, intro­ duziu a ideia de algoritmos genéticos.

Capitulo 28

Conceitos de mineração de dados

alfabeto. As sequências sào equivalentes aos indivíduos. Uma função de ajuste define quais soluções podem sobreviver e quais nào podem. As formas como as soluções podem ser combinadas sào moldadas pela operação cruzada de cortar e combinar sequências de um pai e uma mãe. Uma população inicial bem variada é oferecida, e um jogo de evolução é realizado, no qual mutações ocorrem entre sequências. Elas se combinam para produzir uma nova geração de indivíduos; os mais qualificados sobrevivem e realizam mutação, até que uma família de soluções bem-sucedidas se desenvolva. As soluções produzidas pelos GAs distinguem-se da maioria das outras técnicas de pesquisa pelas seguintes características:

■ Uma pesquisa de GA usa um conjunto de soluções durante cada geração, em vez dc uma única solução. ■ A pesquisa no espaço da sequência representa uma pesquisa paralela muito maior no espaço das soluções codificadas. ■ A memória da pesquisa feita é representada unicamente pelo conjunto de soluções disponíveis para uma geração. ■ Um algoritmo genético é um algoritmo que se torna aleatório, pois os mecanismos dc pesquisa utilizam operadores probabilísticos. ■ Ao prosseguir de uma geração para a seguinte, um GA encontra o equilíbrio quase ideal entre aquisição de conhecimento e exploração ao manipular solu­ ções codificadas. Os algoritmos genéricos são usados para solução e agrupamento de proble­ mas. Sua capacidade de solucionar problemas em paralelo oferece uma ferra­ menta poderosa para a mineração de dados. As desvantagens dos GAs incluem a grande superprodução de soluções individuais, o caráter aleatório do processo dc pesquisa e a alta demanda no processamento do computador. Em geral, um poder de computação substancial é exigido para conseguir algo significativo com algoritmos genéticos.

28.6 Aplicações de mineração de dados Tecnologias de mineração de dados podem ser aplicadas a uma grande variedade de contextos de tomada de decisão nos negócios. Em particular, algumas áreas de ganhos significativos devem incluir as seguintes:

■ Marketing. As aplicações incluem análise de comportamento do consumidor com base nos padrões de compra; a determinação das estratégias de marketing que incluem propaganda, local da loja e correio direcionado; segmentação de clientes, lojas ou produtos; e projeto de catálogos, layouts de loja e campanhas publicitárias. ■ Finanças. As aplicações incluem análise de credibilidade de clientes; segmentação de contas a receber; análise de desempenho de investimentos financeiros, como ações, títulos e fundos de investimentos; avaliação de opções de financiamento; e detecção de fraude. ■ Manufatura. As aplicações envolvem otimização de recursos como máquinas, mão de obra e matéria-prima; e o projeto ideal de processos de manufatura, layout de galpões e projeto de produtos, como automóveis baseados em solici­ tações do cliente. ■ Saúde. Algumas aplicações são descoberta de padrões em imagens radiológicas, análise de dados experimentais de microarray (chip de gene) para agrupar genes

987

988

Sistemas de banco de dados

e relacionar sintomas ou doenças, análise de efeitos colaterais de drogas e eficá­ cia de certos tratamentos, otimização de processos em um hospital e análise do relacionamento entre dados de bem-estar do paciente e qualificações do médico.

28.7 Ferramentas comerciais de mineração de dados Atualmente, as ferramentas comerciais de mineração de dados usam diversas técnicas comuns para extrair conhecimento. Entre elas estão regras de associação, agrupamento, redes neurais, sequenciação e análise estatística. Já discutimos sobre elas. Também são usadas árvores de decisão, que sâo uma representação das regras utilizadas na classificação ou agrupamento, e análises estatísticas, que podem incluir regressão e muitas outras técnicas. Outros produtos comerciais utilizam técnicas avançadas, como algoritmos genéticos, lógica baseada em caso, redes bayesianas, regressão não linear, otimização combinatória,combinação de padrão e lógica fuzzy. Neste capítulo, já discutimos alguns deles. A maioria das ferramentas de mineração de dados utiliza a interface ODBC (open database connectivity). ODBC é um padrão da indústria que funciona com bancos de dados; ele permite acesso aos dados na maioria dos programas de banco de dados populares, como Access, dBASE, Informix, Oracle e SQL Server. Alguns desses paco­ tes de software oferecem interfaces para programas específicos de banco de dados; os mais comuns são Oracle, Access e SQL Server. A maior parte das ferramentas funciona no ambiente Microsoft Windows e algumas, no sistema operacional UNIX. A tendência é que todos os produtos operem no ambiente Microsoft Windows. Uma ferramenta, o Data Surveyor, menciona a compatibilidade com ODMG; ver Capítulo 12, no qual discutimos o padrão orientado a objeto ODMG. Em geral, esses programas realizam processamento sequencial em uma única máquina. Muitos desses produtos atuam no modo cliente-servidor. Alguns deles incorporam o processamento paralelo em arquiteturas de computador paralelas e atuam como uma parte das ferramentas de processamento analítico on-line (OLAP).

28.7.1 Interface com o usuário A maioria das ferramentas é executada em um ambiente de interface gráfica com o usuário (GUI, do \ng\cs graphical user interface). Alguns produtos incluem técni­ cas dc visualização sofisticadas para exibir dados c regras (por exemplo, MincSet da SGI) e são até capazes de manipular dados assim interativamente. As interfaces de texto são raras e mais comuns em ferramentas disponíveis para UNIX, como o Intelligent Miner da IBM.

28.7.2 Interface de programação de aplicações Normalmente, a interface dc programação dc aplicações (API) é uma fer­ ramenta opcional. A maioria dos produtos não permite o uso de suas funções internas. Porém, alguns deles permitem que o programador de aplicação reu­ tilize seu código. As interfaces mais comuns são bibliotecas C e Dynamic Link Libraries (DLLs). Algumas ferramentas incluem linguagens próprias dc comando de banco de dados. Na Tabela 28.1, listamos 11 ferramentas de mineração de dados representativas. Até o momento, existem quase cem produtos de mineração de dados comerciais disponíveis em todo o mundo. Fora dos Estados Unidos, temos o Dara Surveyor, da Holanda, e o PolyAnalyst, da Rússia.

Capitulo 28

Conceitos de mineração de dados

989

Tabela 28.1 Algumas ferramentas de mineração de dados representativas.

Empresa

Técnica

Produto

AcknoSoft

Kate

Angoss

Knowledge SEEKER

Business Objects

Business Miner

CrossZ

QueryObject

Plataforma Windows

seado em caso

UNIX

Árvores de decisão, estatística

Windows

ODBC

Windows

ODBC

Redes neurais, aprendizado de

máquina Análise estatística, algoritmo de

otimização

Data Surveyor

ferentes tipos de mineração de

MVS UNIX

UNIX

dados DBMiner

Technology Inc.

IBM

Megaputer

Intelligence

Análise OLAP, associações,

DBMiner

classificação, algoritmos de

Classificação, regras de associa­

Miner

ção, modelos de previsão Aquisição de conhecimento

PolyAnalyst

simbólico, programação evolucionária

ODBC

ODBC e compatível

com ODMG

Windows

Microsoft 7.0 OLAP

UNIX (AIX)

IBM DB2

Windows

ODBC

OS/2

Oracle DB2

Windows

ODBC

agrupamento

Intelligent

Microsoft Access

Windows

Abrangente; pode misturar di­ Data Distilleries

* Interface

Árvores de decisão, raciocínio ba­

Management

NCR

Discovery Tool

Regras de associação

(MDT)

Árvores de decisão, regras de

Purple Insight

SAS

MineSet

Enterprise Miner

associação

Oracle UNIX (Irix)

Sybase

Informix

Árvores de decisão, regras de as­

UNIX (Solaris)

ODBC

sociação, redes neurais, regressão,

Windows

Oracle

agrupamento

Macintosh

AS/400

* ODBC: open database connectivity ODMG: Object Data Management Group

28.7.3 Direções futuras As ferramentas de mineração de dados estão continuamente evoluindo, com base nas idéias da pesquisa científica mais recente. Muitas dessas ferramentas incorporam os algoritmos mais recentes tomados da inteligência artificial (IA), estatística e otimização. zXtualmente, o processamento rápido é feiro com o uso de técnicas modernas de banco de dados — como o processamento distribuído — em arquiteturas cliente-servidor, em bancos de dados paralelos e em data warehousing. Para o futuro, a tendência é em direção ao desenvolvimento de capacidades dc internet mais completas. Além disso, abordagens híbridas se tornarão comuns, e o processamento será feito usando-se todos os recursos disponíveis. O processamento tirará proveito dos ambientes de computação paralelo e distribuído. Essa mudança é especialmente importante porque os bancos de dados modernos contêm uma quantidade de informação muito grande. A principal direção para a mineração dc dados é na análise de terabytes e peta­ bytes de dados nos chamados sistemas big data que apresentamos no Capítulo 25. Esses sistemas estão sendo equipados com suas próprias ferramentas e bibliotecas para mineração de dados, como Mahout, que roda em cima de Hadoop, que já

990

Sistemas de banco de dados

descrevemos com detalhes. A área de mineração de dados também estará bastante ligada a dados que serão abrigados na nuvem, em data warehouses, e trazidos para serem usados em operações de mineração conforme a necessidade, usando servidores OLAP (on-line analytical processing). Não apenas os bancos de dados de multimídia estão crescendo, mas também o armazenamento e a recuperação de imagens são operações lentas. Além disso, o custo do armazenamento secundário está diminuindo, de modo que o armazenamento maciço dc informações será viável, até mesmo para pequenas empresas. Assim, os programas de mineração dc dados terão dc lidar com conjuntos dc dados maiores de mais empresas. A maioria dos softwares de mineração de dados usará o padrão ODBC para extrair dados de bancos de dados comerciais; formatos de entrada proprietários poderão desaparecer. Existe uma necessidade definitiva de incluir dados fora do padrão, inserindo imagens e outros dados de multimídia, como dados de origem para mineração de dados.

28.8 Resumo Neste capítulo, estudamos a disciplina importante da mineração de dados, que utiliza a tecnologia de banco de dados para descobrir conhecimento e padrões adi­ cionais nos dados. Demos um exemplo ilustrativo da descoberta de conhecimento nos bancos de dados, que tem um escopo maior que a mineração de dados. Para a mineração de dados, entre as diversas técnicas, destacamos os detalhes da mineração da regra de associação, classificação c agrupamento. Apresentamos algoritmos em cada uma dessas áreas e ilustramos com exemplos como eles funcionam. Diversas outras técnicas, incluindo as redes neurais baseadas em IA e algoritmos genéticos, também foram discutidas resumidamente. Existe pesquisa ativa em minera­ ção de dados, e esboçamos algumas de suas direções esperadas. No mercado futuro dc produtos de tecnologia dc banco dc dados, espera-se muita atividade dc mineração de dados. Resumimos 11 das quase cem ferramentas de mineração dc dados disponíveis; pesquisas futuras deverão estender significativamente a quantidade e a funcionalidade.

PERGUNTAS DE REVISÃO -----------------------------------------------------------------------28.1.

28.2. 28.3. 28.4. 28.5.

28.6. 28.7. 28.8. 28.9.

Quais são as diferentes fases da descoberta de conhecimento a partir de bancos de dados? Descreva um cenário de aplicação completo em que o novo conhecimento pode ser minerado com base em um banco de dados de transações existente. Quais são os objetivos ou tarefas que a mineração de dados tenta facilitar? Quais são os cinco tipos dc conhecimento produzidos da mineração dc dados? O que são regras dc associação como um tipo dc conhecimento? Dc uma definição de suporte e confiança e use-as para definir uma regra dc associação. O que é a propriedade de fechamento para baixo? Como ela auxilia no desen­ volvimento de um algoritmo eficiente para encontrar regras de associação, ou seja, com relação à localização dc grandes conjuntos dc itens? Qual foi o fator motivador para o desenvolvimento do algoritmo árvore FP para a mineração da regra de associação? Descreva com um exemplo uma regra de associação entre hierarquias. O que é uma regra de associação negativa no contexto da hierarquia da Figura 28.3? Quais são as dificuldades da mineração dc regras dc associação dc grandes bancos dc dados?

Capitulo 28

Conceitos de mineração de dados

28.10. O que sào regras de classificação e como as árvores de decisão estão rela­ cionadas a elas? 28.11. O que é entropia e como ela é usada na montagem de árvores de decisão? 28.12. Como o agrupamento difere da classificação? 28.13. Descreva as redes neurais e os algoritmos genéricos como técnicas para a mine­ ração de dados. Quais são as principais dificuldades no uso dessas técnicas?

EXERCÍCIOS----------------------------------------------------------------------------------------------28.14. Aplique o algoritmo Apriori ao seguinte conjunto de dados: ltens_comprados

Id_transação

28.15. 28.16.

28.17. 28.18. 28.19.

101

leite, pão, ovos

102

leite, suco

103

suco, manteiga

104

leite, pão, ovos

105

café, ovos

106

café

107

café, suco

108

leite, pão, biscoito, ovos

109

biscoito, manteiga

110

leite, pão

O conjunto de itens é (leite, pão, biscoito, ovos, manteiga, café, suco). Use 0,2 para o valor de suporte mínimo. Mostre duas regras que possuem uma confiança de 0,7 ou mais para um conjunto de itens que contém três itens do Exercício 28.14. Para o algoritmo de partição, prove que qualquer conjunto de itens frequente no banco de dados precisa aparecer como um conjunto de itens frequente local cm pelo menos uma partição. Mostre a árvore FP que seria criada para os dados do Exercício 28.14. Aplique o algoritmo de crescimento FP à árvore FP do Exercício 28.17 e mostre os conjuntos de itens frequentes. /Xplique o algoritmo de classificação ao seguinte conjunto de registros de dados. O atributo de classe é Cliente.assiduo.

RID

Idade

Cidade

Sexo

101

20...30

SP

F

superior incompleto

SIM

102

20...30

BH

M

superior completo

SIM

103

31 .40

SP

F

superior incompleto

SIM

104

51...60

SP

F

superior incompleto

NÂO

105

31...40

RJ

M

nível médio

NÃO

106

41...50

SP

F

superior incompleto

SIM

107

41...50

SP

F

superior completo

SIM

108

20...30

RJ

M

superior incompleto

SIM

109

20...30

SP

F

nível médio

NÃO

110

20...30

SP

F

superior incompleto

SIM

Educacao

Cliente_assiduo

991

992

Sistemas de banco de dados

28.20. Considere o seguinte conjunto de registros bidimensionais: RID

Dimensãol

Dimensão?

1

8

4

2

5

4

3

2

4

4

2

6

5

2

8

6

8

6

Considere também dois esquemas de agrupamento diferentes: (1) no qual Grupo, contém registros {1, 2, 3} e Grupo, contém registros {4, 5, 6} e (2) no qual Grupo, contém registros {1, 6} e Grupo, contém registros {2, 3, 4, 5}. Qual esquema é melhor e por quê? 28.21. Use o algoritmo de &-means para agrupar os dados do Exercício 28.20. Podemos usar um valor de 3 para K e considerar que os registros com RIDs 1, 3 e 5 são utilizados para os centroides (médias) de grupo iniciais. 28.22. O algoritmo de fc-means utiliza uma métrica de semelhança da distância entre um registro e um centroide de cluster. Se os atributos dos registros não forem quantitativos, mas categóricos por natureza, como Nivel_de_renda com valores {baixo, médio, alto} ou Casado com valores {Sim, Não} ou Estado_de_residencia com valores {Acre, Alagoas,..., Tocantins}, então a métrica dc distância não é significativa. Defina uma métrica de semelhança mais adequada, que possa ser usada para agrupamento dos registros de dados que contêm dados categóricos.

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

A literatura sobre mineração de dados vem de vários campos, incluindo estatística, otimização matemática, aprendizado de máquina e inteligência artificial. Chen et al. (1996) dão um bom resumo da perspectiva dc banco dc dados sobre mineração de dados. O livro dc Han c Kambcr (2006) é um texto excelente, que descreve com detalhes os diferentes algoritmos e técnicas usadas na área de mineração de dados. O trabalho na pesquisa Almaden da IBM produziu um grande número de conceitos e algoritmos iniciais, bem como resultados de alguns estudos de desempenho. Agrawal et al. (1993) relatam o primeiro estudo importante sobre regras de associação. Seu algoritmo Apriori para dados de cesta de mercado em Agrawal e Srikant (1994) é melhorado com o uso de particionamento em Savascrc et al. (1995);Toivoncn (1996) propõe a amostragem como um meio dc reduzir o esforço dc processamento. Cheung et al. (1996) estendem o particionamento para ambientes distribuídos; Lin e Dunham (1998) propõem técnicas para contornar problemas com viés dc dados. Agrawal et al. (1993b) discutem a perspectiva dc desempenho sobre regras dc associação. Mannila et al. (1994), Park et al. (1995) e Amir et al. (1997) apresentam outros algoritmos eficientes relacionados a regras de associação. Han et al. (2000) apresentam o algo­ ritmo árvore FP discutido neste capítulo. Srikant e Agrawal (1995) propõem regras generalizadas de mineração. Savasere et al. (1998) apresentam a primeira técnica de mineração de associações negativas. Agrawal et al. (1996) descrevem o sistema Quest na IBM. Sarawagi et al. (1998) descrevem uma implementação em que as regras de associação são integradas a um sistema de gerenciamento de banco de

Capitulo 28

Conceitos de mineração de dados

dados relacionai. Piatesky-Shapiro e Frawley (1992) contribuíram com artigos de diversos tópicos relacionados à descoberta de conhecimento. Zhang et al. (1996) apresentam o algoritmo BIRCH para o agrupamento de grandes bancos de dados. Informações sobre aprendizado de árvore de decisão e o algoritmo de classificação apresentado neste capítulo podem ser encontradas em Mitchell (1997). Adriaans e Zantinge (1996), Fayyad et al. (1997) e Weiss e Indurkhya (1998) são livros dedicados aos diferentes aspectos da mineração de dados e seu uso na previsão. A ideia de algoritmos genéticos foi proposta por Holland (1975); um bom estudo dos algoritmos genéticos aparece em Srinivas e Patnaik (1994). Redes neurais possuem uma vasta literatura; uma introdução abrangente está disponível em Lippman (1987). Tan, Steinbach e Kumar (2006) oferecem uma introdução abrangente à minera­ ção de dados e possuem um conjunto detalhado de referências. Os leitores também são aconselhados a consultar os anais das duas principais conferências anuais em mineração de dados: a Knowledge Discovery and Dara Mining Conference (KDD), que é realizada desde 1995, e a SIAM International Conference on Data Mining (SDM), que acontece desde 2001. Os links para as conferências anteriores podem ser encontrados em .

993

29

Visão geral de data warehousing e OLAP ata warehouses são bancos de dados que armazenam e mantêm dados analíticos separadamente dos bancos de dados orientados a transação, para fins de apoio à decisão. Os bancos de dados normais, orientados a transação, armazenam dados por um período limitado, antes que eles percam sua utilidade imediata e sejam arquivados. Por outro lado, os data warehouses costu­ mam manter dados de vários anos, a fim de permitir a análise de dados históricos. Eles oferecem armazenamento, funcionalidade e responsividade às consultas além das capacidades dos bancos de dados orientados a transação. zVcompanhando esse poder cada vez maior há uma grande demanda para melhorar o desempenho de acesso aos dados dos bancos de dados. Em organizações modernas, os usuários em geral são completamente retirados das fontes de dados. Muitas pessoas só precisam de acesso de leitura aos dados, mas ainda necessitam de acesso rápido a um volume maior de dados do que pode ser convenientemente baixado para o desktop. Com frequência, esses dados vêm de vários bancos. Como muitas das análises realizadas são recorrentes e previsíveis, os vendedores de software e o pessoal de suporte de sistemas projetam sistemas para dar suporte a essas funções. Os data warehouses são modelados e estruturados de forma diferente, utilizam diferentes tipos de tec­ nologias para armazenamento e recuperação, e são usados por tipos de usuários diferentes daqueles dos bancos de dados orientados a transação. Atualmente, existe uma grande necessidade de oferecer aos que tomam decisões, da gerência interme­ diária para cima, informações no nível correto de detalhe para dar apoio à atividade de tomada de decisão. Data warehousing, processamento analítico on-line (OLAP) e mineração de dados oferecem essa funcionalidade. Fizemos uma introdução às técnicas de mineração de dados no Capítulo 28. Neste capítulo, oferecemos uma

D

visão geral mais ampla das tecnologias de data warehousing c OLAP.

996

Sistemas de banco de dados

29.1 Introdução, definições e terminologia No Capítulo 1, definimos banco de dados como uma coleção de dados relacio­ nados e um sistema de banco de dados como um banco de dados e um software de banco de dados juntos. Um data warehouse também é uma coleção de informações, bem como um sistema de suporte. Contudo, existe uma distinção clara. Os bancos de dados tradicionais são transacionais (relacionais, orientados a objeto, em rede ou hierárquicos). Os data warehouses tem a característica distintiva de servir princi­ palmente para aplicações de apoio à decisão. Eles são otimizados para recuperação de dados, e não para processamento de transação de rotina. Como os data warehouses têm sido desenvolvidos em diversas organizações para atender a necessidades particulares, não existe uma única definição canônica desse termo. Artigos de revistas profissionais e livros populares elaboraram o significado de diversas maneiras. Os vendedores aproveitaram a popularidade do termo para ajudar a comercializar uma série de produtos relacionados, e os consultores oferece­ ram uma grande variedade de serviços, todos sob a bandeira do data warehousing. Contudo, os data warehouses são muito distintos dos bancos dc dados tradicionais em sua estrutura, funcionamento, desempenho e finalidade. W. H. Inmon * caracterizou um data warehouse como uma coleção de dados orientada a assunto, integrada, nào volátil, variável no tempo para o apoio às decisões da gerência. Os data warehouses oferecem acesso a dados para análise complexa, descoberta dc conhecimento c tomada de decisão por meio de consultas ocasionais e prontas. Consultas prontas referem-se às consultas definidas a priori, com parâ­ metros que podem ocorrer com alta frequência. Data warehouses dão suporte a demandas de alto desempenho sobre os dados e informações de uma organização. Vários tipos de aplicações — OLAP, SAD e aplicações de mineração de dados — são aceitos. Definimos cada uma delas a seguir. OLAP (processamento analítico on-line, online analytical processing) é um termo usado para descrever a análise de dados complexos do data warehouse. Nas mãos de trabalhadores do conhecimento habilidosos, as ferramentas OLAP permitem a consulta rápida c direta dos dados analíticos armazenados cm data warehouses e data marts (bancos de dados analíticos semelhantes aos data warehouses, mas com um escopo definido de modo mais estreito). SAD (sistemas de apoio à decisão, decision-support systems), também conhe­ cido como EIS — sistemas dc informações executivas (ou sistemas dc informações gerenciais, management information systems), que não devem scr confundidos com sistemas de integração empresarial —, ajudam os principais tomadores de decisões de uma organização com dados de nível mais alto (analíticos) em decisões complexas e importantes. A mineração de dados (que discutimos no Capítulo 28) é usada para descoberta do conhecimento, o processo ocasional de procurar novo conhecimento imprevisto nos dados (como procurar pérolas de sabedoria em um oceano de dados). Os bancos de dados tradicionais têm suporte para o processamento de transação on-line (OLTP, online transaction processing), que inclui inserções, atualizações e cxclusõcs, enquanto também têm suporte para requisitos dc consulta dc informação. Os bancos de dados relacionais tradicionais são otimizados para processar consultas que podem tocar em uma pequena parte do banco de dados e transações que lidam com inserções ou atualizações no processo dc algumas tuplas por relação. Assim, eles não podem ser otimizados para OLAP, SAD ou mineração de dados. Ao contrário, os data warehouses são projetados exatamente para dar suporte à extração, ao pro­ cessamento e à apresentação eficientes para fins analíticos e de tomada de decisão. Em comparação com os bancos de dados tradicionais, os data warehouses em geral 1 Inmon (19921 tem sido reconhecido como o primeiro a usar o termo warehouse. Inmon et al. (2008) é intitulado “DW 2.0: The architecture for the next generation of Data Warehousing”.

Capítulo 29

Visão geral de data warehousing e OLAP

997

contêm quantidades muito grandes de dados de várias fontes, que podem incluir bancos de dados de diferentes modelos de dados e, às vezes, arquivos adquiridos de sistemas e plataformas independentes.

29.2 Características dos data warehouses Para discutir data warehouses e distingui-los dos bancos de dados transacionais, é preciso que haja um modelo dc dados apropriado. O modelo dc dados multidi­ mensional (explicado com mais detalhes na Seção 29.3) é uma boa escolha para OLAP e tecnologias de apoio à decisão. Ao contrário dos multibancos de dados, que oferecem acesso a bancos dc dados disjuntos e normalmentc heterogêneos, um data warehouse geralmenre é um depósito de dados integrados de múltiplas fontes, processados para armazenamento em um modelo multidimensional. Diferentemente da maioria dos bancos de dados transacionais, data warehouses costumam apoiar a análise de série temporal e tendência, ambas exigindo mais dados históricos do que geralmenre é mantido nos bancos de dados transacionais. Em comparação com os bancos dc dados transacionais, os data warehouses são não voláteis. Isso significa que as informações no data warehouse mudam com muito menos frequência c podem ser consideradas como apenas de Icitura/acrcscimo/eliminação. Um data warehouse pode ser considerado não dc tempo real com inserções periódicas. Em sistemas transacionais, as transações são a unidade e o agente de mudança no banco dc dados; ao contrário, a informação do data warehouse c muito menos detalhada e atualizada de acordo com uma escolha cuidadosa de política de atualização, normalmente incremental. As inserções no warehouse são tratadas pelo processo de ETL (extração, transformação e carga, extract, transform, load), que realiza uma grande quantidade de pré-processamento e que pode ser visto na Figura 29.1. Também podemos descrever o data warehousing de forma mais geral como uma coleção de tecnologias de apoio à decisão, visando a habilitar o trabalhador do conhecimento (executivo, gerente, analista) a tomar decisões melhores e mais rápidas.1 A Figura 29.1 oferece uma visão geral da estrutura conceituai de um data warehouse. Ela mostra o processo inteiro de data warehousing, que inclui a possí­ vel limpeza e reformatação dos dados antes que sejam carregados no warehouse. Esse processo é tratado por ferramentas conhecidas como ferramentas de ETL. No backend do processo, OLAP, mineração de dados e SAD podem gerar novas infor­ mações relevantes, como as regras (ou metadados adicionais); essas informações aparecem na figura voltando como entradas de dados adicionais no warehouse. A figura também mostra que as fontes de dados podem incluir arquivos. Figura 29.1 Visão geral da

arquitetura geral de um data warehouse.

2 Chaudhuri e Dayal (1997) oferecem um excelente tutorial sobre o assunto, com esta sendo uma defi­ nição inicial.

998

Sistemas de banco de dados

As características importantes dos data warehouses que acompanharam a defi­ nição do termo OLAP em 1993 incluíram as seguintes, aplicáveis ainda hoje:3 ■ Visão conceituai multidimensional. ■ Dimensões c níveis de agregação ilimitados. ■ Operações irrestritas entre dimensões. ■ Tratamento dinâmico de matriz esparsa. ■ Arquitetura cliente-servidor. ■ Suporte para múltiplos usuários. ■ Acessibilidade. ■ Transparência. ■ Xlanipulação de dados intuitiva. ■ Análise indutiva e dedutiva. ■ Relatório flexível distribuído.

Como abrangem um grande volume de dados, os data warehouses geralmente são uma ordem de grandeza (às vezes, duas ordens de grandeza) maiores que os bancos de dados de origem. O imenso volume de dados (provavelmente na faixa dos terabytes ou mesmo petabytes) é uma questão que tem sido tratada por meio de data warehouses em nível corporativo, data warehouses virtuais, data warehouses lógicos c data marts: ■ Data warehouses em nível corporativo são imensos projetos que exigem investi­ mento maciço de tempo e recursos. ■ Data warehouses virtuais oferecem visões de bancos de dados operacionais que são materializadas para acesso eficiente. ■ Data warehouses lógicos utilizam técnicas de federação, distribuição e virtualização de dados. ■ Data mans em geral são voltados para um subconjunto da organização, como um departamento, e possuem um foco mais estreito.

Outros termos encontrados com frequência no contexto do data warehousing são os seguintes: ■ Data store operacional (ODS): este termo normalmenre é usado para a forma intermediária de bancos de dados, antes que sejam limpos, agregados e transfor­ mados em um data warehouse. ■ Data store analítico (ADS): o banco de dados que é montado para fins de realizar análise de dados. Geralmente, ODSs são recon figura dos e replanejados para ADSs por meio de processos dc limpeza, agregação e transformação.

29.3 Modelagem de dados para data warehouses Modelos multidimcnsionais tiram proveito dos relacionamentos inerentes nos dados para preencher os dados cm matrizes multidimcnsionais, chamadas cubos de dados. (Estes podem ser chamados de hipercubos, se tiverem mais de três dimensões.) Para dados que se prestam à formatação dimensional, o desempenho da consulta nas matrizes multidimcnsionais pode ser muito melhor que no modelo de dados relacionai. Três exemplos de dimensões em um data warehouse corporativo são os períodos fiscais, produtos e regiões da empresa.

’ Codd e Salley (19931 criaram o termo OLAP e mencionaram as características listadas aqui.

Capítulo 29

Visão geral de data warehousing e OLAP

999

Uma planilha-padrão é uma matriz bidimensional. Um exemplo seria uma planilha de vendas regionais por produto para determinado período. Os produtos poderíam ser mostrados como linhas, com as receitas de vendas para cada região compreendendo as colunas. (A Figura 29.2 mostra essa organização bidimensional.) Ao acrescentar uma dimensão de tempo, como os trimestres fiscais de uma organização, seria produzida uma matriz tridimensional, que poderia ser representada usando um cubo de dados. A Figura 29.3 mostra um cubo dc dados tridimensional que organiza os dados de vendas de produtos por trimestres fiscais e regiões de vendas. Cada célula teria dados para um produto específico, trimestre fiscal específico e região específica. Ao incluir outras dimensões, um hipercubo de dados poderia ser produzido, embora mais de três dimensões não possam ser facilmente visualizadas ou apresentadas dc maneira gráfica. Os dados podem ser consultados dirctamcnte cm qualquer combinação dc dimensões, evitando consultas de banco de dados complexas. Existem ferramentas para visualizar dados de acordo com a escolha de dimensões do usuário. Figura 29.2 Um modelo de

Região

matriz bidimensional. Reg 1

Reg 2

Reg 3

o □ ã Q.

Figura 29.3 Um modelo de

cubo de dados tridimensional.

1000

Sistemas de banco de dados

Mudar da hierarquia (orientação) unidimensional para outra é algo feito com facilidade em um cubo de dados com uma técnica chamada de giro (também chamada de rotação). Nessa técnica, o cubo de dados pode ser imaginado girando para mos­ trar uma orientação diferente dos eixos. Por exemplo, você poderia girar o cubo de dados para mostrar as receitas de vendas regionais como linhas, os totais de receita por trimestre fiscal como colunas e os produtos da empresa na terceira dimensão (Figura 29.4). Logo, essa técnica é equivalente a ter uma tabela dc vendas regionais para cada produto separadamente, em que cada tabela mostra vendas trimestrais para esse produto região por região. O termo slice (ou fatia) é usado para se referir a uma visão bidimensional de um cubo tridimensional ou de dimensões maiores. A visão 2-D de Produto versus Região mostrada na Figura 29.2 é uma faria do cubo 3-D mostrado na Figura 29.3.0 termo popular “slice and dice" implica uma redução sistemática de um corpo de dados em trechos ou visões menores, de modo que a informação esteja visível a partir de vários ângulos ou pontos de vista. Os modelos multidimensionais atendem prontamente a visões hierárquicas no que é conhecido como exibição roll-up ou exibição drill-down. Uma exibição roll-up sobe na hierarquia, agrupando em unidades maiores ao longo de uma dimensão (por exemplo, somando dados semanais por trimestre ou por ano). A Figura 29.5 mostra uma exibição roll-up que se move de produtos individuais para uma categorização maior dos produtos. Na Figura 29.6, uma exibição drill-down oferece a capacidade oposta, fornecendo uma visão mais detalhada, talvez desagregando as vendas do país por região c, depois, as vendas regionais por sub-região e também separando produ­ tos por estilos. Gcralmcntc, em um warehouse, a capacidade drill-down é limitada ao menor nível de dados agregados armazenados no warehouse. Por exemplo, em comparação com os dados mostrados na Figura 29.6, os dados de nível mais baixo corresponderão a algo como “o total de vendas para o estilo PI23 subesrilo A cor Preta no CEP 28890-000 da sub-região 1”. Esse nível de agregação pode ter sido mantido no ODS. Alguns SGBDs, como o Oracle, oferecem o conceito de “tabela aninhada”, que permite o acesso a níveis de dados mais baixos e, portanto, o drill-down penetra mais profundamente. Figura 29.4 Versão girada do

cubo de dados da Figura 293.

Capitulo 29

Visão geral de data warehousing e OLAP

Figura 29.5 A operação

Região -----------------------------------------►

Região 2

Região 1

1001

roll-up.

Região 3

Produtos 1XX Produtos 2XX Produtos 3XX Produtos 4XX

Região 1

Região 2

Figura 29.6 A operação drill-down.

Sub_reg 1

Estilos P123

A B C D

Estilos P124

A *

Estilos P125

A B C

Sub.reg 2

Sub_reg 3

Sub_reg 4

Sub.reg 1

D

O modelo multidimensional (também chamado de modelo dimensional) envolve dois tipos dc tabelas: tabelas de dimensão e tabelas dc fatos. Uma tabela dc dimensão consiste cm tuplas dc atributos da dimensão. Uma tabela dc fatos pode scr imagi­ nada como tendo tuplas, uma para cada fato registrado. Esse fato contém alguma(s) variável(is) medida(s) ou observada(s) e a(s) identifica com ponteiros para tabelas de dimensão. A tabela dc fatos contém os dados, c as dimensões identificam cada tupla nesses dados. Outra forma dc examinar uma tabela dc fatos é como uma visão aglomerada dos dados da transação, enquanto cada tabela de dimensão representa os chamados “dados mestres” aos quais essas transações pertencem. Nos sistemas de banco dc dados multidimcnsionais, o modelo multidimensional foi implemen­ tado como um sistema dc software especializado, conhecido como banco de dados multidimensional, que não discutimos aqui. Nosso tratamento do modelo multidi­ mensional é baseado no armazenamento do warehouse como um banco de dados relacionai em um SGBDR. A Figura 29.7 contém um exemplo de tabela de fatos que pode ser vista da pers­ pectiva de múltiplas tabelas de dimensão. Dois esquemas multidimcnsionais comuns são o esquema estrela e o esquema floco de neve. O esquema estrela consiste em uma tabela dc fatos com uma única tabela para cada dimensão (Figura 29.7). O esquema floco de neve é uma variação do esquema estrela em que as tabelas dimensionais de um esquema estrela são organizadas em uma hierarquia ao normalizá-las (Figura 29.8). Uma constelação dc fatos é um conjunto de tabelas de fatos que compartilham

1002

Sistemas de banco de dados

algumas tabelas de dimensão. A Figura 29.9 mostra uma constelação de fatos com duas tabelas de fatos, resultados de negócios e previsão de negócios. Estas compar­ tilham a tabela de dimensão chamada produto. As constelações de fatos limitam as possíveis consultas para o warehouse.

Tabela de dimensão

Tabela de dimensão

Produto

Trimestre fiscal

Tabela de fatos Resultados de negócios

Numero_produto Nome_produto Descricao_produto Estilo_produto Linha_produto

k Numero produto Trimestre Região Receita_vendas

Trimestre Ano Datajnicio Data fim

/

Tabela de dimensão Região Sub-região

Figura 29.7 Um esquema estrela com tabelas de fato e dimensões.

Tabelas de dimensão

Tabelas de dimensão Trimestre fiscal

NomeP

Nome produto Descricao. produto

Tabela de fatos Resultados de negóoos

Produto Numero_produto MQ!D?-Rf9duto_. Estilo > Numero_hnha_p_roduto__

Datas TF

Pata_jnicjq Data_fim

Trimestre Ano Data inicio

Numero_produto / Trimestre Região * Receita vendas \

J

Região vendas

LinhaP

Numero linha produção Nome_linha_producao

Região Sub-região

Figura 29.8 Um esquema floco de neve.

Tabela de fatos I

Tabela de dimensão

Tabela de fatos II

Resultados de negócios

Produto

Previsão de negócios

Produto Trimestre Região Receita

•-



Numero_produto Nome_produto Descri cao_prod uto Estilo_produto Linha_produto

Figura 29.9 Uma constelação de fatos.



Produto Trimestre_futuro Região Receita_p rojetada

Capitulo 29

Visão geral de data warehousing e OLAP

O armazenamento do data warehouse também utiliza técnicas de indexação para dar suporte ao acesso de alto desempenho (ver no Capítulo 17 uma dis­ cussão sobre indexação). Uma técnica chamada indexação bitmap constrói um vetor de bits para cada valor em um domínio (coluna) que está sendo indexado. Ela funciona muito bem para domínios de baixa cardinalidade. Existe um bit 1 colocado na posição ; no vetor se a linha de ordem / tiver o valor sendo indexado. Por exemplo, imagine um estoque de 100.000 carros com um índice bitmap sobre o tamanho do carro. Se houver quatro tamanhos de carro — econômico, compacto, médio e grande —, haverá quatro vetores de bits, cada um contendo 100.000 bits (12,5 KB), com um tamanho total de 50K. A indexação bitmap pode oferecer vantagens consideráveis de entrada/saída e espaço de armazenamento nos domínios de baixa cardinalidade. Com vetores de bits, um índice bitmap pode oferecer grandes melhorias no desempenho de comparação, agregação e junção. Mostramos um exemplo de consulta sobre um esquema estrela na Seção 19.8, e também mostramos a transformação do esquema estrela para a execução eficiente que usa índices de bitmap. Em um esquema estrela, dados dimensionais podem ser indexados para tuplas na tabela de fatos pela indexação dc junção. Os índices dc junção são índices tradicionais para manter relacionamentos entre valores de chave primária e chave estrangeira. Eles relacionam os valores de uma dimensão de um esquema estrela a linhas na tabela de fatos. Por exemplo, considere uma tabela dc fato de vendas que tenha cidade c trimestre fiscal como dimensões. Sc houver um índice de junção sobre cidade, para cada cidade o índice de junção mantém as IDs de tupla das tuplas que contêm essa cidade. Os índices de junção podem envolver várias dimensões. O armazenamento de data warehouse pode facilitar o acesso a dados dc resumo, tirando proveito da não volatilidade dos data warehouses c dc um grau dc previsibi­ lidade das análises que serão realizadas ao utilizá-los. Duas técnicas foram usadas: (1) tabelas menores, incluindo dados de resumo como vendas trimestrais ou receita por linha dc produto; e (2) codificação de nível (por exemplo, semanal, trimestral, anual) em tabelas existentes. Por comparação, o trabalho extra de criação e manu­ tenção de tais agregações provavelmente seria excessivo em um banco de dados volátil, orientado a transação. O objetivo do gerenciamento dc dados mestre (MDM — master data mana­ gement^ um conceito popular dentro das empresas, é definir padrões, processos, políticas e governança relacionados às entidades de dados críticas da organização. As tabelas de dimensão — as quais, em um data warehouse, materializam concei­ tos, como clientes, regiões e categorias de produtos — representam essencialmente os dados mestres. Como as dimensões são compartilhadas entre vários fatos ou relatórios de data marts, os projetistas de data warehouse normalmente gastam uma quantidade considerável de tempo limpando e harmonizando essas dimensões (ou seja, reconciliando as diferenças de definição e notação em vários sistemas de origem provenientes dos dados de dimensão). Dessa forma, as estruturas de tabela que contêm essas dimensões tornam-se boas candidatas para cópias especiais de dados mestres que podem ser usadas em outros ambientes.

29.4 Criando um data warehouse Na construção de um data warehouse, os responsáveis deverão ter uma visão ampla do uso antecipado do warehouse. Não existe um meio de antecipar todas as consultas ou análises possíveis durante a fase de projeto. Porém, o projeto deve

1003

1004

Sistemas de banco de dados

aceitar especifica mente a consulta ocasional, ou seja, acessar dados com qualquer combinação significativa de valores para os atributos nas tabelas de dimensão ou fatos. Por exemplo, uma empresa de bens de consumo com marketing intenso exigiría

diferentes maneiras de organizar o data warehouse do que uma empresa dc caridade sem fins lucrativos, voltada para angariar fundos. Um esquema apropriado seria escolhido para refletir o uso antecipado. A aquisição dc dados para o warehouse envolve as seguintes etapas: 1. Os dados precisam ser extraídos de várias fontes heterogêneas, por exemplo, bancos de dados ou outras entradas de dados, como as que contêm dados do mercado financeiro ou dados ambientais.

2. Os dados precisam scr formatados por coerência dentro do warehouse. Nomes, signi­ ficados e domínios dos dados de fontes não relacionadas precisam ser reconciliados. Por exemplo, empresas subsidiárias de uma grande corporação podem ter diferentes calendários fiscais, com trimestres terminando em datas diferentes, tornando difícil agregar dados financeiros por trimestre. Diversos cartões de crédito podem infor­ mar suas transações de modos diferentes, tomando difícil calcular todas as vendas a crédito. Essas inconsistências de formato devem ser resolvidas. 3. Os dados precisam ser limpos para garantir a validade. A limpeza de dados é um processo complicado e complexo, que tem sido identificado como o componente que mais exige trabalho na construção do data warehouse. Para a entrada de dados, a limpeza precisa ocorrer antes que eles sejam carregados no warehouse. Como os dados de entrada precisam ser examinados e forma­ tados de modo consistente, os criadores de data warehouse devem usar essa oportunidade para verificar a validade e a qualidade. Reconhecer dados errô­ neos e incompletos é difícil de automatizar, e a limpeza que requer correção de erro automática pode ser ainda mais complicada. Alguns aspectos, como a verificação de domínio, são facilmente codificados nas rotinas de limpeza de dados, mas o reconhecimento automático de outros problemas de dados pode ser mais desafiador. (Por exemplo, pode-se exigir que Cidade = “Campinas” com Estado = “RJ” seja reconhecida como uma combinação incorreta.) Depois que tais problemas tiverem sido resolvidos, dados semelhantes de fontes diferentes precisam ser coordenados para carga no warehouse. Quando os gerentes de dados na organização descobrem que seus dados estão sendo limpos para entrada no warehouse, eles provavelmente desejarão uma atualização com os dados limpos. O processo de retornar dados limpos para a origem é chamado de fluxo reverso (ver Figura 29.1).

4. Os dados precisam ser ajustados ao modelo de dados do warehouse. Os dados de várias fontes devem ser representados no modelo de dados do warehouse. Eles podem ter de ser convertidos de bancos de dados relacionais, orientados a objeto ou legados (em rede e/ou hierárquico) para um modelo multidimensional. 5. Os dados precisam ser carregados no warehouse. O grande volume de dados no warehouse torna a carga dos dados uma tarefa significativa. São necessárias ferramentas de monitoramento para cargas, bem como métodos para recupe­ ração de cargas incompletas ou incorretas. Com o imenso volume de dados no warehouse, a atualização incrementai normalmente é a única técnica viável. A política de renovação provavelmente surgirá como um comprometimento que leva em conta as respostas às seguintes perguntas:

■ Até que ponto os dados devem estar atualizados? ■ O warehouse pode ficar off-line, e por quanto tempo?

Capitulo 29

Visão geral de data warehousing e OLAP

■ Quais sào as interdependências dos dados? ■ Qual é a disponibilidade do armazenamento? ■ Quais são os requisitos de distribuição (como para replicação e particionamento)? ■ Qual é o tempo de carga (incluindo limpeza, formatação, cópia, transmissão e overhead, como a recriação de índice)?

Os dados em um warehouse podem vir de várias origens, geografias e/ou fusos horários. As cargas de dados, portanto, precisam ser cuidadosamente planejadas e organizadas. A ordem em que os dados são carregados no warehouse é crítica; a falha no carregamento de dados na ordem correta pode levar a restrições de inte­ gridade ou violações de regras semânticas, que podem causar falhas de carga. Por exemplo, os dados mestres (novos ou alterados), como Cliente e Produto, devem ser carregados antes das transações que os contêm; e os dados da fatura devem ser carregados antes dos dados de faturamento que a referenciam. Como dissemos, os bancos de dados precisam lutar por um equilíbrio entre eficiência no processamento dc transação e suporte dos requisitos da consulta (consultas ocasionais do usuário), mas um dara warehouse normalmente é otimi­ zado para acesso com base nas necessidades de um tomador de decisão. O arma­ zenamento dc dados cm um data warehouse reflete essa especialização c envolve os seguintes processos:

■ Armazenamento dos dados de acordo com o modelo de dados do warehouse. ■ Criação e manutenção das estruturas de dados exigidas. ■ Criação e manutenção dos caminhos de acesso apropriados. ■ Fornecimento dc dados variáveis no tempo à medida que novos dados são incluídos. ■ Suporte à atualização dos dados do warehouse. ■ Atualização dos dados. ■ Eliminação dos dados.

Embora um tempo adequado possa ser inicialmente dedicado à construção do warehouse, seu imenso volume dc dados costuma tomar impossível simplesmente recarregá-lo em sua totalidade mais adiante. As alternativas são a atualização sele­ tiva (parcial) dos dados e versões de warehouse separadas (exigindo capacidade de armazenamento duplo para o warehouse). Quando o warehouse utiliza um meca­ nismo dc atualização de dados incrementai, os dados precisam ser periodicamente eliminados; por exemplo, um warehouse que mantém dados sobre os 12 trimestres comerciais anteriores pode, de maneira periódica, eliminar seus dados a cada ano, ou até mesmo a cada trimestre. Os data warehouses também devem ser projetados com consideração total do ambiente em que residirão. Considerações de projeto importantes incluem as seguintes: ■ Projeções dc uso. ■ O ajuste do modelo de dados. ■ Características das fontes disponíveis. ■ Projeto do componente de metadados. ■ Projeto de componente modular. ■ Projeto de facilidade de gerenciamento e mudança. ■ Considerações dc arquitetura distribuída c paralela.

1005

1006

Sistemas de banco de dados

Discutimos cada um desses itens por vez. O projeto de warehouse é inicialmente controlado por projeções de uso; ou seja, por expectativas sobre quem usará o warehouse e como eles o usarão. A escolha de um modelo de dados para dar suporte a esse uso é uma decisão inicial chave. Projeções de uso e as características das origens de dados do warehouse são levadas em consideração. O projeto modular é uma necessidade prática para permitir que o warehouse evolua com a organização e seu ambiente de informação. Além disso, um data warehouse bem montado deve ser projetado para facilidade de manutenção, permitindo que os gerentes de warehouse planejem c gerenciem a mudança com eficiência, enquanto oferecem suporte ideal para os usuários. Você deve se lembrar do termo metadados do Capítulo 1; metadados foram defi­ nidos como a descrição de um banco de dados que inclui sua definição de esquema. O repositório dc metadados c um componcnte-chavc do data warehouse. O repo­ sitório inclui metadados técnicos e de negócios. Os metadados técnicos abordam detalhes de aquisição, processamento, estruturas de armazenamento, descrições de dados, operações c manutenção do warehouse, c funcionalidade de suponc ao acesso. Os metadados dc negócios incluem as regras de negócios relevantes e os detalhes organizacionais que dão suporte ao warehouse. /\ arquitetura do ambiente de computação distribuída da organização é uma importante característica determinante para o projeto do warehouse. Existem duas arquiteturas distribuídas básicas: o warehouse distribuído e o warehouse federado. Para um warehouse distribuído, todos os aspectos dos bancos de dados distribuídos são relevantes; por exemplo, replicação, particionamento, comunicações e questões dc consistência. Uma arquitetura distribuída pode oferecer benefícios partieularmente importantes ao desempenho do warehouse, como balanceamento de carga melho­ rado, escalabilidade de desempenho e maior disponibilidade. Um único repositório dc metadados replicado residiría em cada site de distribuição. A ideia do warehouse federado é a mesma do banco dc dados federado: uma confederação descentralizada de data warehouses autônomos, cada um com o próprio repositório de metadados. Dada a magnitude do desafio inerente aos data warehouses, é provável que tais federações consistam em componentes de escala menor, como os data marts. As empresas estão ficando insatisfeitas com as técnicas e tecnologias tradicio­ nais de data warehousing. Novos requisitos analíticos estão impulsionando novas aplicações analíticas; alguns exemplos são Netezza da IBM, Greenplum da EMC,

Hana da SAP e ParAccel da Tableau Software. A análise dc big data levou o Hadoop e outros bancos de dados especializados, como armazenamentos de grafos e chave-valor, para a próxima geração do data warehousing (consulte, no Capítulo 25, uma discussão sobre tecnologia big data baseada em Hadoop). As plataformas de virtualização dc dados, como a da Cisco,4 permitirão que esses data warehouses lógicos sejam construídos no futuro.

29.5 Funcionalidade típica de um data warehouse Os data warehouses existem para facilitar as consultas ocasionais complexas, com o uso intenso e frequente de dados. Consequentemente, os data warehouses precisam oferecer suporte à consulta muito maior e mais eficiente do que é exigido dos bancos de dados transacionais. O componente de acesso ao data warehouse tem suporte para funcionalidade dc planilha avançada, processamento de consulta

4 Ver a descrição da Dara Virtualization Platform da Cisco em .

Capitulo 29

Visão geral de data warehousing e OLAP

eficiente, consultas estruturadas, consultas ocasionais, mineração de dados e visões materializadas. Em particular, a funcionalidade de planilha avançada inclui suporte para as mais modernas aplicações de planilha (por exemplo, MS Excel), bem como

para programas dc aplicações OLAP. Estes oferecem funcionalidades pré-programadas, como as seguintes: ■ Roll-up (também drill-up). Os dados sào resumidos com generalização cada vez maior (por exemplo, semanal para trimestral para anual). ■ Drill-down. Níveis cada vez maiores de detalhes sâo revelados (o complemento de roll-up). ■ Giro. A tabulaçào cruzada (também conhecida como rotação} é realizada. ■ Slice and dice. Operações dc projeção são realizadas nas dimensões. ■ Ordenação. Os dados são ordenados por valor ordinal. ■ Seleção. Os dados estão disponíveis por valor ou intervalo. ■ Atributos derivados (calculados). Atributos são calculados por operações sobre valores armazenados e derivados.

Como os data warehouses são livres das restrições do ambiente transacional, existe uma eficiência aumentada no processamento da consulta. Entre as ferramentas c técnicas usadas estão a transformação dc consulta; interseção c união dc índice; funções especiais ROLAP (OLAP relacionai) e MOLAP (OLAP multidimensional); extensões SQL; métodos de junção avançados; e varredura inteligente (como nas consultas múltiplas piggy-backing). Há também uma opção HOLAP (OLAP híbrido), que combina ROLAP e MOLAP. Para as informações do tipo resumo, HOLAP aproveita a tecnologia dc cubo (usando MOLAP) para obter um desempenho mais rápido. Quando são necessárias informa­ ções detalhadas, HOLAP pode “mergulhar” no cubo e chegar até os dados relacionais subjacentes (que estão no componente ROLAP). O melhor desempenho também tem sido obtido com o processamento paralelo. As arquiteturas de servidor paralelas incluem multiprocessador simétrico (SXÍP), cluster e processamento maciçamente paralelo (XÍPP), além de combinações deles. Os trabalhadores do conhecimento e os tomadores dc decisão utilizam ferramen­ tas que variam desde consultas parametrizadas até consultas ocasionais e mineração de dados. Assim, o componente de acesso do data warehouse precisa oferecer suporte para consultas estruturadas (tanto parametrizadas quanto ocasionais). Juntos, eles compõem um ambiente de consulta gerenciado. A própria mineração de dados usa técnicas da análise estatística e inteligência artificial. A análise estatística pode ser realizada por planilhas avançadas, por softwares sofisticados de análise estatística c por programas escritos especialmente para isso. Técnicas como lagging, médias móveis e análise de regressão normalmente também são empregadas. Técnicas de inteligência artificial, que podem incluir algoritmos genéticos e redes neurais, são usadas para classificação e empregadas para descobrir conhecimento do data warehouse, que pode ser inesperado ou difícil de especificar em consultas. (Tratamos a mineração de dados com detalhes no Capítulo 28.)

29.6 Data warehouses versus visões Algumas pessoas têm considerado os data warehouses uma extensão das visões do banco de dados. Já mencionamos as visões materializadas como um modo de atender aos requisitos para acesso melhorado aos dados (veja uma discussão sobre

1007

1008

Sistemas de banco de dados

visões na Seção 7.3). As visões materializadas têm sido exploradas por sua melhoria no desempenho. Na Seção 19.2.4, discutimos como as visões materializadas sào mantidas e usadas como parte da otimização da consulta. No entanto, as visões

oferecem apenas um subconjunto das funções e capacidades dos data warehouses. Visões e data warehouses são semelhantes porque ambos possuem extratos apenas de leitura dos bancos de dados e permitem a orientação por assunto. Contudo, os data warehouses são diferentes das visões das seguintes maneiras: ■ Os data warehouses existem como armazenamento persistente, em vez de serem materializados por demanda. ■ Os data warehouses não são apenas visões relacionais, mas sim visões multidimensionais com níveis dc agregação. ■ Os data warehouses podem scr indexados para otimizar o desempenho. As visões não podem scr indexadas indcpcndcntcmcntc dos bancos dc dados subjacentes. ■ Os data warehouses caractcristicamcntc oferecem suporte específico dc funcio­ nalidade; as visões, não. ■ Os data warehouses oferecem uma grande quantidade de dados integrados e normalmcnte temporais, cm geral mais do que está contido cm um banco dc dados, ao passo que as visões são uma síntese de um banco de dados. ■ Data warehouses trazem dados de várias fontes por meio dc um processo ETL complexo, que envolve limpeza, poda e síntese, ao passo que as visões são uma síntese de um banco de dados por intermédio de uma consulta predefinida.

29.7 Dificuldades de implementação de data warehouses Algumas questões operacionais significativas surgem com o data warehousing: construção, administração e controle de qualidade. O gerenciamento de projeto — projeto, construção c implementação do warehouse — c uma consideração impor­ tante e desafiadora, que não deve ser subestimada. A montagem dc um warehouse em nível corporativo em uma grande organização é uma realização importante, potencialmente exigindo anos da conceitualização para implementação. Em virtude da dificuldade e da quantidade dc tempo inicial exigidas para tal empreendimento, o desenvolvimento e a implantação generalizada dos data marts podem oferecer uma alternativa atraente, especialmente para as organizações com necessidades urgentes para suporte de OLAP, SAD e/ou mineração de dados. A administração de um data warehouse é um empreendimento intenso, pro­ porcional ao tamanho e à complexidade do warehouse. Uma organização que tenta administrar um data warehouse precisa realisticamente entender a natureza complexa de sua administração. Embora projetado para acesso de leitura, um data warehouse não é uma estrutura mais estática do que qualquer uma de suas fontes de informação. Os bancos de dados de origem podem evoluir. O esquema e o componente de aquisição do warehouse devem esperar atualização para lidar com essas evoluções. Uma questão significativa no data warehousing é o controle de qualidade dos dados. Tanto a qualidade quanto a consistência dos dados são questões importan­ tes — especialmcnte em relação aos dados de dimensão, que, por sua vez, afetam o gerenciamento dos dados mestres. Embora os dados passem por uma função de limpeza durante a aquisição, a qualidade e a consistência continuam sendo questões

Capitulo 29

Visão geral de data warehousing e OLAP

significativas para o administrador e o projetista do banco de dados. Juntar dados de fontes heterogêneas e distintas é um desafio sério, dadas as diferenças na nomea­ ção, definições de domínio, números de identificação e coisas do tipo. Toda vez que

um banco de dados de origem muda, o administrador do data warehouse precisa considerar as possíveis interações com outros elementos do warehouse. Projeções de uso devem ser estimadas conservadoramente antes da construção do data warehouse e devem ser revisadas de maneira contínua para refletir os requi­ sitos atuais. A medida que os padrões de utilização se tornam claros c mudam com o tempo, o armazenamento e os caminhos de acesso podem ser ajustados para que permaneçam otimizados para o suporte do uso de seu warehouse pela organização. Essa atividade deve continuar por toda a vida do warehouse para que continue antecipando a demanda. O warehouse também deve ser projetado para acomo­ dar o acréscimo e o desgaste das fontes de dados sem um reprojeto importante. z\s origens e os dados de origem evoluirão, e o warehouse precisa acomodar essa mudança. Ajustar os dados de origem disponíveis ao modelo de dados do warehouse será um desafio contínuo, uma tarefa que é tanto arte quanto ciência. Como existe uma mudança rápida e contínua nas tecnologias, os requisitos e as capacidades do warehouse mudarão consideravelmente com o tempo. Além disso, a própria tecnologia de warehousing continuará a evoluir por algum tempo, dc modo que as estruturas e funcionalidades componentes serão continuamente atualizadas. Essa mudança certa é uma motivação excelente para que haja um projeto totalmente modular dos componentes. A administração dc um data warehouse exigirá habilidades muito mais amplas que as necessárias para a administração do banco de dados tradicional. Geralmente, diferentes partes de uma grande organização enxergam os dados de formas diferen­ tes. Provavelmente, será necessária uma equipe de especialistas técnicos altamente habilitados, com áreas de especialização sobrepostas, cm vez de um único indivíduo. A equipe também deverá possuir um conhecimento profundo dos negócios e, especi­ ficamente, as regras e regulamentações, as restrições e as políticas da empresa. Assim como a administração do banco de dados, a administração do data warehouse é apenas parcialmente técnica; uma grande parte da responsabilidade exige o trabalho eficaz com todos os membros da organização com um interesse no data warehouse. Por mais difícil que às vezes possa ser para os administradores do banco de dados, isso é muito mais desafiador para os administradores do data warehouse, pois o escopo de suas responsabilidades é consideravelmente maior do que o enfrentado pelos administradores de banco de dados. O projeto da função de gerenciamento e a seleção da equipe de gerenciamento para um data warehouse são cruciais. Seu gerenciamento em uma organização grande certamente será uma tarefa importante. Muitas ferramentas comerciais estão disponíveis para dar suporte a funções de gerenciamento. O gerenciamento eficaz do data warehouse com certeza será uma função de equipe, que exige um grande conjunto dc habilidades técnicas, coordenação cuidadosa c liderança eficaz. Assim como precisamos nos preparar para a evolução do warehouse, também temos de reconhecer que as habilidades da equipe da gerência, necessariamente, evoluirão com ela.

29.8 Resumo Neste capítulo, estudamos o campo conhecido como data warehousing. O dara warehousing pode ser visto como um processo que requer uma série de atividades

1009

1010

Sistemas de banco de dados

preliminares. Ao contrário, a mineração de dados (ver Capítulo 28) pode ser imagi­ nada como uma atividade que retira conhecimento de um data warehouse existente ou de outras fontes de dados. Em primeiro lugai; na Seção 29.1, apresentamos os principais conceitos relacionados ao data warehousing e definimos termos como OLAP e SAD, confrontando-os com OLTP. Apresentamos uma arquitetura geral dos sistemas de data warehousing. Na Seção 29.2, discutimos as características fundamentais dos data warehouses e seus diferentes tipos. Depois, na Seção 29.3, discutimos a modelagem dc dados cm warehouses usando o que c popularmcnte conhecido como modelo de dados multidimensional. Foram discutidos diferentes tipos de tabelas e esquemas. Oferecemos um relato elaborado dos processos e con­ siderações dc projeto envolvidos na criação dc um data warehouse na Seção 29.4. Depois, na Seção 29.5, apresentamos a funcionalidade especial típica associada a um data warehouse. O conceito de visão do modelo relacionai foi comparado com a visão multidimensional dos dados nos dara warehouses, na Seção 29.6. Finalmente, na Seção 29.7, discutimos as dificuldades da implementação de data warehouses c os desafios da administração do data warehouse.

PERGUNTAS DE REVISÃO -----------------------------------------------------------------------29.1. 29.2.

O que é um data warehouse? Como ele difere de um banco de dados? Defina os termos: OLAP (processamento analítico on-line), ROLAP (OLAP relacionai), MOLAP (OLAP multidimensional) e SAD (sistemas de apoio à decisão).

29.3.

Descreva as características dc um data warehouse. Divida-as cm funciona­ lidade de um warehouse e vantagens que os usuários riram dele. O que é o modelo de dados multidimensional? Como ele é usado no dara warehousing?

29.4. 29.5. 29.6. 29.7. 29.8. 29.9.

29.10. 29.11. 29.12. 29.13.

Defina os seguintes termos: esquema estrela, esquema floco de neve, conste­ lação de fatos, data marts. Que tipos de índices são criados para um warehouse? Ilustre os usos para cada um com um exemplo. Descreva as etapas para a criação dc um warehouse. Que considerações desempenham um papel importante no projeto de um warehouse? Descreva as funções que um usuário pode realizar em um data warehouse e ilustre os resultados dessas funções em um exemplo de data warehouse multidimensional. Como o conceito de uma visão relacionai está relacionado a um data warehouse c a data marts? Em que eles são diferentes? Liste as dificuldades na implementação dc um data warehouse. Liste as questões abertas e problemas de pesquisa no data warehousing. O que é gerenciamento de dados mestres? Qual é sua relação com o data warehousing?

29.14. O que são data warehouses lógicos? Faça uma pesquisa on-line para a pla­ taforma de virtualização de dados da Cisco e discuta como ela ajudará na criação de um data warehouse lógico.

Capitulo 29

Visão geral de data warehousing e OLAP

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

Inmon (1992, 2005) tem o crédito por dar aceitação geral ao termo data warehouse. Codd e Salley (1993) popularizaram o termo processamento analítico on-line (OL/YP) e definiram um conjunto de características para data warehou­ ses darem suporte a OLAP. Kimball (1996) é conhecido por sua contribuição ao desenvolvimento do campo de data warehousing. Mattison (1996) é um dos vários livros sobre data warehousing que oferecem uma análise abrangente das técnicas disponíveis nos data warehouses e as estratégias que as empresas devem usar em sua implantação. Ponniah (2010) oferece uma visão geral muito prática do processo de criação de data warehouse com base na coleta de requisitos até a implantação e manutenção. Jukic et al. (2013) é uma boa fonte sobre modelagem de um data warehouse. Bischoff e Alexander (1997) é uma compilação de conselhos de especialistas. Chaudhuri e Dayal (1997) oferecem um excelente tutoria! sobre o assunto, enquanto Widom (1995) aponta uma série de problemas pendentes e pesquisa em andamento.

1011

PARTE 12 Tópicos adicionais de banco de dados: segurança

ste capítulo discute técnicas para proteger os bancos de dados contra uma série de ameaças. Ele também apresenta esquemas para fornecer privilégios de acesso a usuários autorizados. Algumas das ameaças de segurança aos bancos de dados — como injeção de SQL — serão apresentadas. Ao final do capí­ tulo, também resumimos como um SGBDR comercial — especificamente, o sistema Oracle — oferece diferentes tipos de segurança. Começamos na Seção 30.1 com uma introdução às questões de segurança e às ameaças aos bancos de dados, e oferecemos uma visão geral das medidas de controle que são abordadas no restante do capítulo. Também comentamos os relacionamentos entre a segurança de dados e a privacidade aplicadas a informações pessoais. A Seção 30.2 discute os mecanismos usados para conceder e revogar privilégios nos sistemas de banco de dados relacionais e em SQL, mecanismos que normalmente são conhecidos como controle de acesso discricio­ nário. Na Seção 30.3, apresentamos uma visão geral dos mecanismos para impor vários níveis de segurança — um problema em particular na segurança do sistema de banco de dados que é conhecido como controle de acesso obrigatório. Essa seção também apresenta as estratégias mais rcccntemente desenvolvidas de controle de acesso baseado em papéis, e a segurança baseada em rótulos e baseada em linha. A Seção 30.3 ainda oferece uma breve discussão sobre controle de acesso por XML. A Seção 30.4 discute uma ameaça importante aos bancos de dados, chamada injeção de SQL, e trata de algumas das medidas preventivas propostas contra ela. A Seção 30.5 discute rapidamente o problema de segurança nos bancos de dados estatísticos. A Seção 30.6 introduz o assunto de controle de fluxo e menciona problemas asso­ ciados aos canais secretos. z\ Seção 30.7 oferece um breve resumo dos esquemas de criptografia e infraesrrutura de chave simétrica e assimétrica (pública). Ela também discute os certificados digitais. A Seção 30.8 introduz técnicas de preservação de privacidade, e a Seção 30.9 apresenta os desafios atuais à segurança do banco de dados. Na Seção 30.10, abordamos a segurança baseada em rótulos do Oracle. Por

E

1016

Sistemas de banco de dados

fim, na Seçào 30.11 apresentamos um resumo do capítulo. Os leitores que estive­ rem interessados apenas nos mecanismos básicos de segurança do banco de dados acharão suficiente abordar o material nas seções 30.1 e 30.2.

30.1 Introdução a questões de segurança de banco de dados1 30.1.1 Tipos de segurança A segurança do banco de dados é uma área extensa, que tenta resolver muitos problemas, incluindo os seguintes: ■ Diversas questões legais e éticas com relação ao direito de acessar certas informa­ ções — por exemplo, algumas informações podem ser consideradas particulares e não podem ser acessadas legalmente por organizações ou pessoas não auto­ rizadas. Nos Estados Unidos, existem várias leis que controlam a privacidade da informação. No Brasil, recentemente foi aprovada a lei geral de proteção de dados pessoais (LGPDP). ■ Questões políticas em nível governamental, institucional ou corporativo quanto aos tipos de informações que não devem se tomar públicas — por exemplo, classificações de crédito e registros médicos pessoais. ■ Questões relacionadas ao sistema, como os níveis de sistema em que várias funções dc segurança devem ser impostas — por exemplo, se uma função dc segurança deve ser tratada no nível dc hardware físico, no nível do sistema ope­ racional ou no nível do SGBD. ■ A necessidade, cm algumas organizações, de identificar vários níveis de segurança e categorizar os dados e usuários com base nessas classificações — por exemplo, altamente secreta, secreta, confidencial e não classificada. A organização deverá impor uma política de segurança com relação a permitir o acesso a várias clas­ sificações dos dados.

Ameaças aos bancos de dados. As ameaças aos bancos de dados podem resultar na perda ou degradação de alguns ou de todos os objetivos de segurança comumente aceitos: integridade, disponibilidade e confidencialidade. ■ Perda de integridade. A integridade do banco de dados refere-se ao requisito de que a informação seja protegida contra modificação imprópria. A modificação de dados inclui criação, inserção, atualização, mudança do status dos dados e exclu­ são. A integridade é perdida se mudanças não autorizadas forem feitas nos dados por atos intencionais ou acidentais. Se a perda da integridade do sistema ou dos dados não for corrigida, o uso continuado do sistema contaminado ou de dados adulterados poderia resultar em decisões imprecisas, fraudulentas ou errôneas. ■ Perda de disponibilidade. A disponibilidade do banco de dados refere-se a tornar os objetos disponíveis a um usuário humano ou a um programa ao qual eles têm um direito legítimo. Perda de disponibilidade ocorre quando o usuário ou o programa não consegue acessar esses objetos. ■ Perda de confidencialidade. A confidencialidade do banco de dados refere-se à proteção dos dados contra exposição não autorizada. O impacto da exposição não autorizada de informações confidenciais pode variar desde a violação da lei geral de proteção de dados pessoais até o comprometimento da segurança nacional. A 1 Agradecemos a contribuição substancial de Fariborz Farahmand. Bharath Rengarajan e Frank- Rietra a esta e às seções seguintes deste capítulo.

Capitulo 30

Segurança de banco de dados

exposição não autorizada, não antecipada ou não intencional podería resultar em perda de confiança pública, constrangimento ou ação legal contra a organização.

Segurança de banco de dados: não é uma preocupação isolada. Ao considerar as ameaças enfrentadas pelos bancos de dados, é importante lembrar que o sistema de geren­ ciamento de banco de dados não pode ser responsável por manter a confidencialidade, a integridade e a disponibilidade dos dados. Em vez disso, o banco dc dados funciona como parte de uma rede de serviços, incluindo aplicativos, servidores web, firewalls, terminadores SSL e sistemas de monitoramento de segurança. Como a segurança de um sistema como um todo é tão forte quanto seu elo mais fraco, um banco de dados pode ser comprometido, mesmo que esteja perfeitamente seguro por seus próprios méritos. Para proteger os bancos de dados contra esses tipos de ameaças, é comum imple­ mentar quatro tipos de medidas de controle: controle dc acesso, controle dc inferência, controle de fluxo e criptografia. Discutiremos cada um desses itens neste capítulo. Em um sistema de banco de dados mulriusuário,o SGBD precisa oferecer técnicas para permitir que certos usuários ou grupos dc usuários acessem partes selecionadas dc um banco de dados sem que obtenham acesso ao restante dele. Isso é particular­ mente importante quando um grande banco dc dados integrado precisa ser usado por diversos usuários diferentes dentro da mesma organização. Por exemplo, informações confidenciais, como salários de funcionários ou análises de desempenho, devem ser mantidas como confidenciais para a maioria dos usuários do sistema de banco de dados. Um SGBD normalmente inclui um subsistema de segurança e autorização do banco dc dados que é responsável por garantir a segurança dc partes dc um banco de dados contra acesso não autorizado. Agora, é comum referir-se a dois tipos de mecanismos de segurança de banco de dados:

■ Mecanismos dc segurança discricionários. Usados para conceder privilégios aos usuá­ rios, incluindo a capacidade dc acessar arquivos dc dados, registros ou campos espe­ cíficos em um modo especificado (como leitura, inserção, exclusão ou atualização). ■ .Mecanismos dc segurança obrigatórios. Usados para impor a segurança multinível pela classificação dc dados e usuários cm várias classes (ou níveis) de segurança e, depois, pela implementação da política de segurança apropriada da organização. Por exemplo, uma política de segurança típica é permitir que os usuários em certo nível de classificação (ou liberação) vejam apenas os itens de dados classificados no próprio nível de classificação do usuário (ou em nível inferior). Uma extensão disso é a segurança baseada em papéis, que impõe políticas e privilégios com base no conceito de papéis organizacionais. (Veja na Seção 30.4.2 o controle de acesso baseado em papéis.) Discutiremos a segurança discricionária na Seção 30.2 c a segurança obrigatória c baseada cm papéis na Seção 30.3.

30.1.2 Medidas de controle Quatro medidas de controle principais são usadas para fornecer segurança em bancos de dados:

■ Controle dc acesso. ■ Controle de inferência. ■ Controle de fluxo. ■ Criptografia de dados.

Um problema de segurança comum aos sistemas de computação é impedir que pessoas não autorizadas acessem o próprio sistema, seja para obter informações, seja para fazer mudanças maliciosas em uma parte do banco de dados. O mecanismo de

1017

1018

Sistemas de banco de dados

segurança de um SGBD precisa incluir provisões para restringir o acesso ao sistema de banco de dados como um todo. Essa função, chamada controle de acesso, é tra­ tada criando-se contas do usuário e senhas para controlar o processo de login pelo SGBD. Discutimos as técnicas de controle de acesso na Seção 30.1.3. Bancos de dados estatísticos são usados para fornecer informações estatísticas ou resumos dos valores com base em diversos critérios. Por exemplo, um banco de dados para estatísticas de população pode oferecer estatísticas com base cm faixas etárias, níveis de renda, tamanho da residência, graus de instrução c outros critérios. Os usuá­ rios de banco de dados estatísticos, como os estatísticos do governo ou de empresas de pesquisa de mercado, têm permissão para acessar o banco de dados e recuperar informações estatísticas sobre uma população, mas não para acessar informações confi­ denciais detalhadas sobre indivíduos específicos. A segurança para os bancos de dados estatísticos deve garantir que informações sobre os indivíduos não possam ser acessadas. Às vezes, é possível deduzir certos fatos com relação aos indivíduos baseando-se em consultas que envolvem apenas estatísticas de resumo sobre grupos; consequentemente, isso também não deve ser permitido. Esse problema, chamado de segurança de banco de dados estatístico, é discutido rapidamente na Seção 30.4. As medidas de controle correspondentes são chamadas de medidas de controle de inferência. Outra questão de segurança é a do controle de fluxo, que impede que informações fluam de modo que cheguem até usuários não autorizados. Isso será discutido na Seção 30.6. Canais secretos são percursos para as informações fluírem implicitamente de maneiras que violam a política de segurança de uma organização. Discutiremos rapidamente algumas questões relacionadas a canais secretos na Seção 30.6.1. Uma medida de controle final é a criptografia de dados, utilizada para proteger dados confidenciais (como números de cartão de crédito) que são transmitidos por meio de algum tipo de rede de comunicação. A criptografia também pode ser usada para oferecer proteção adicional para partes confidenciais de um banco de dados. Os dados são codificados com o uso de algum algoritmo de codificação. Um usuá­ rio não autorizado que acessa dados codificados terá dificuldade para decifrá-los, mas os usuários autorizados recebem algoritmos de codificação ou decodificação (ou chaves) para decifrar os dados. Técnicas de criptografia que são muito difíceis de decodificar sem uma chave foram desenvolvidas para aplicações militares. No entanto, os registros criptografados nos bancos de dados atualmente são usados em aplicações de organizações privadas e também governamentais c militares. Na verdade, leis estaduais e federais prescrevem a criptografia para qualquer sistema que lida com informações pessoais protegidas por lei. Por exemplo, de acordo com a Lei do estado da Geórgia (OCGA 10-1-911):

“Informações pessoais” significa o nome ou a inicial c sobrenome de um indi­ víduo em combinação com qualquer um ou mais dos seguintes elementos de dados, quando o nome ou os elementos de dados não estiverem criptografados ou editados:

■ Número de seguro social. ■ Número da carteira de habilitação ou identificação estadual. ■ Número de conta, cartão de crédito ou débito, se houver circunstâncias nas quais tal número possa ser usado sem informações adicionais de identificação, códigos de acesso ou senhas. ■ Senhas de conta ou números de identificação pessoal ou outros códigos de acesso.

Visto que, nos Estados Unidos, as leis que definem o que constitui informação pes­ soal variam de um estado para outro, os sistemas precisam proteger a privacidade dos indivíduos e impor medidas de privacidade de forma adequada. Usar somente o controle de acesso discricionário (ver Seção 30.2) pode não ser suficiente. A Seção 30.7 aborda de

Capitulo 30

Segurança de banco de dados

maneira breve as técnicas de criptografia, incluindo técnicas populares como a criptogra­ fia de chave pública, bastante usada para dar suporte a transações baseadas na web em relação a bancos de dados, e assinaturas digitais, utilizadas em comunicações pessoais. Uma discussão abrangente da segurança nos sistemas de computação e bancos de dados está fora do escopo deste livro. Oferecemos apenas uma rápida visão geral das técnicas de segurança de banco de dados. A segurança baseada em rede e comunicação também é um tópico muito amplo, que não será tratado aqui. Para ver uma discussão abrangente, o leitor interessado pode consultar várias das referências discutidas na bibliografia selecionada ao final deste capítulo.

30.1.3 Segurança de banco de dados e o DBA Conforme discutimos no Capítulo 1, o administrador do banco de dados (DBA) é a autoridade central para gerenciar um sistema de banco de dados. As responsa­ bilidades do DBA incluem conceder privilégios aos usuários que precisam usar o sistema e classificar os usuários e dados de acordo com a política da organização. O DBA tem uma conta de DBA no SGBD, também conhecida como conta do sistema ou conta de superusuário, que oferece capacidades poderosas que não estão dispo­ níveis às contas e usuários comuns do banco de dados.2 Os comandos privilegiados do DBA incluem aqueles para conceder e revogar privilégios a contas, usuários ou grupos de usuários individuais e para realizar os seguintes tipos de ações: 1. Criação de conta. Esta ação cria uma conta e senha para um usuário ou grupo de usuários para permitir acesso ao SGBD.

2. Concessão de privilégio. Esta ação permite que o DBA conceda certos privilégios a determinadas contas. 3. Revogação de privilégio. Esta ação permite que o DBA revogue (anule) alguns privilégios que foram dados anteriormente a certas contas. 4. Atribuição de nível de segurança. Esta ação consiste em atribuir contas do usuário ao nível de liberação de segurança apropriado. O DBA é responsável pela segurança geral do sistema dc banco de dados. A ação 1 na lista anterior é usada para controlar o acesso ao SGBD como um todo, ao passo que as ações 2 e 3 são utilizadas para controlar a autorização discricionária ao banco de dados, e a ação 4, para controlar a autorização obrigatória.

30.1.4 Controle de acesso, contas de usuário e auditorias de banco de dados Sempre que uma pessoa ou um grupo de pessoas precisa acessar um sistema de banco de dados, o indivíduo ou grupo precisa primeiro solicitar uma conta de usuário. O DBA, então, criará um novo número dc conta c senha para o usuário, se houver uma necessidade legítima para acessar o banco dc dados. O usuário precisa efetuar o login no SGBD ao entrar com o número de conta e senha sempre que o acesso for necessário. O SGBD verifica se os números de conta e senha são válidos; se forem, o usuário tem permissão para usar o SGBD e acessar o banco de dados. Os programas dc aplicação também podem scr considerados usuários e precisam efetuar o login (ver Capítulo 10). E simples registrar os usuários do banco de dados e suas contas e senhas criando uma tabela criptografada ou um arquivo com dois campos: NumeroConta e Senha. Essa tabela pode ser facilmente mantida pelo SGBD. Sempre que uma conta é criada, 2 Esta conta é semelhante às contas root ou superuser dadas aos administradores de sistema de compu­ tação e permitem o acesso a comandos restritos do sistema operacional.

1019

1020

Sistemas de banco de dados

um novo registro é inserido na tabela. Quando uma conta é cancelada, o registro correspondente deve ser excluído. O sistema também precisa registrar todas as operações no banco de dados que sâo aplicadas por cerro usuário em cada sessão de login, que consiste na sequência de interações do banco de dados que o usuário realiza desde o momento do login até o momento do logoff. Quando um usuário efetua o login, o SGBD pode registrar o número dc conta do usuário c associá-lo ao computador ou dispositivo do qual o usuário realizou a conexão. Todas as operações aplicadas desse computador ou dispositivo são atribuídas à conta do usuário até que ele efetue o logoff. E particular­ mente importante registrar as operações de atualização aplicadas ao banco de dados de modo que, se for adulterado, o DBA possa determinar qual usuário mexeu nele. Para manter um registro de todas as atualizações realizadas no banco dc dados e dc usuários em particular que aplicaram cada atualização, podemos modificar o log do sistema. Lembre-se, dos capítulos 20 e 22, que o log do sistema inclui uma entrada para cada operação aplicada ao banco de dados que pode ser exigida para a recupe­ ração de uma falha de transação ou falha do sistema. Podemos expandir as entradas dc log dc modo que também incluam o número de conta do usuário e o computador on-line ou 1D de dispositivo que aplicou cada operação registrada no log. Sc houver suspeita dc qualquer adulteração, é realizada uma auditoria do banco dc dados, que consiste em rever o log para examinar todos os acessos e operações aplicadas durante certo período. Quando uma operação ilegal ou não autorizada é encontrada, o DBA pode determinar o número dc conta usado para realizar a operação. As auditorias são particularmente importantes para bancos dc dados confidenciais, atualizados por muitas transações e usuários, como nos sistemas bancários que os atualizam por meio de seus diversos caixas. Um log de banco de dados, utilizado principal mente para fins de segurança, às vezes é chamado de trilha de auditoria.

30.1.5 Dados sensíveis e tipos de exposição A sensibilidade dc dados é uma medida da importância atribuída aos dados por seu proprietário, com a finalidade de indicar sua necessidade de proteção. Alguns bancos de dados contêm apenas dados confidenciais, enquanto outros podem não conter qualquer dado confidencial. O tratamento dos bancos de dados que caem nesses dois extremos é relativamente fácil, pois podem ser tratados pelo controle de acesso, explicado na próxima seção. A situação torna-se mais complicada quando alguns dos dados são confidenciais, ao passo que outros não o são. Diversos fatores podem fazer que os dados sejam classificados como confidenciais: 1. Inerentemente confidenciais. O valor dos próprios dados pode ser tão revelador ou confidencial que ele se torna sensível — por exemplo, o salário de uma pessoa ou o fato de um paciente ter HIV/Aids.

2. De uma fonte confidencial. A fonte dos dados pode indicar uma necessidade — por exemplo, um informante cuja identidade precisa ser mantida em segredo. 3. Confidenciais declarados. O proprietário dos dados pode tê-los declarado expli­ citamente como confidenciais. 4. Um atributo ou registro confidencial. O atributo ou registro em particular pode ter sido declarado confidencial — por exemplo, o atributo dc salário de um fun­ cionário ou o registro do histórico de salários cm um banco dc dados pessoal. 5. Confidencial em relação a dados previamente expostos. Alguns dados podem não ser confidenciais por si sós, mas assim se tomarão na presença dc algum outro dado — por exemplo, a informação exata dc latitude e longitude para um local onde aconteceu algum evento previamente registrado, que mais tarde foi considerado confidencial.

Capitulo 30

Segurança de banco de dados

É responsabilidade do administrador de banco de dados e do administrador de

segurança impor coletivamente as políticas de segurança de uma organização. Isso indica se o acesso deve ser permitido a certo atributo do banco de dados (também conhecido como coluna da tabela ou um elemento de dados) ou não para usuários individuais ou para categorias de usuários. Vários fatores precisam ser considerados antes de se decidir se é seguro revelar os dados. Os três fatores mais importantes são disponibilidade de dados, aceitabilidade de acesso e garantia de autenticidade.

1. Disponibilidade de dados. Se um usuário estiver atualizando um campo, então esse campo torna-se inacessível e outros usuários não devem visualizar esses dados. Esse bloqueio é temporário e ocorre apenas para garantir que nenhum usuário veja quaisquer dados imprecisos. Isso normalmente é tratado pelo mecanismo de controle de concorrência (ver Capítulo 21).

2. Aceitabilidade de acesso. Os dados só devem ser revelados a usuários autori­ zados. Um administrador de banco de dados também pode negar acesso a uma solicitação do usuário mesmo que esta não acesse diretamente um item de dados confidencial, com base no fato de que os dados solicitados podem revelar infor­ mações sobre os dados confidenciais que o usuário não está autorizado a ter. 3. Garantia de autenticidade. Antes de conceder acesso, certas características exter­ nas sobre o usuário também podem ser consideradas. Por exemplo, um usuário só pode ter acesso permitido durante as horas de trabalho. O sistema pode rastrear consultas anteriores para garantir que uma combinação de consultas não revele dados confidenciais. Este último é particularmente relevante para consultas a banco de dados estatísticos (ver Seção 30.5). O termo precisão, quando usado na área de segurança, refere-se a permitir ao máximo possível que os dados estejam disponíveis, para proteger exatamente o subconjunto de dados confidenciais. As definições de segurança versus precisão são as seguintes: ■ Segurança: meio de garantir que os dados sejam mantidos seguros contra adulte­ ração e que o acesso a eles seja controlado de modo adequado. Prover segurança significa expor apenas dados não confidenciais e rejeitar qualquer consulta que referencie um campo confidencial. ■ Precisão: proteger todos os dados confidenciais enquanto disponibiliza o máximo possível de dados não confidenciais. Observe que essa definição de precisão não está relacionada à precisão da recuperação de informações, definida na Seção 27.6.1. A combinação ideal é manter a segurança perfeita com o máximo de precisão. Se quisermos manter a segurança, algum sacrifício precisa ser feito com a precisão. Logo, em geral existe um dilema entre esses dois conceitos.

30.1.6 Relacionamento entre segurança da informação e privacidade da informação O avanço rápido do uso da tecnologia da informação (TI) na indústria, no governo e no meio acadêmico gera questões e problemas desafiadores com relação à proteção e ao uso de informações pessoais. Questões como quem e quais direitos à informação sobre indivíduos para quais finalidades tornam-se mais importantes à medida que seguimos para um mundo em que é tecnicamente possível conhecer quase tudo sobre qualquer um. Decidir como projetar considerações de privacidade na tecnologia para o futuro inclui dimensões filosóficas, legais e práticas. Existe uma sobreposição considerável entre questões relacionadas ao acesso a recursos (segurança) e questões relacionadas

1021

1022

Sistemas de banco de dados

ao uso apropriado da informação (privacidade). Agora, definimos a diferença entre segurança e privacidade. Segurança na tecnologia da informação diz respeito a muitos aspectos da prote­ ção de um sistema contra uso não autorizado, incluindo autenticação de usuários, criptografia de informação, controle de acesso, políticas de firewall e detecção de intrusão. Para nossos propósitos aqui, limitaremos nosso tratamento da segurança aos conceitos associados a como um sistema pode proteger o acesso às informações nele contidas. O conceito de privacidade vai além da segurança. Privacidade examina como o uso da informação pessoal que um sistema adquire sobre um usuário está de acordo com suposições explícitas ou implícitas relativas a esse uso. Do ponto de vista de um usuário final, a privacidade pode ser considerada sob duas perspectivas diferentes: impedindo o armazenamento de informações pessoais ou garantindo o uso apropriado de informações pessoais. Para os propósitos deste capítulo, uma definição simples, porém útil, de pri­ vacidade é a capacidade de os indivíduos controlarem os termos sob os quais sua informação pessoal é adquirida e usada. Resumindo, segurança envolve a tecnolo­ gia para garantir que a informação está devidamente protegida. A segurança é um bloco de montagem necessário para que exista privacidade. A privacidade envolve mecanismos para dar suporte à conformidade com alguns princípios básicos e outras políticas indicadas explicitamente. Um princípio básico é que as pessoas devem ser informadas sobre a coleta de informações, avisadas com antecedência sobre o que será feito com suas informações e devem receber uma oportunidade razoável dc aprovar tal uso da informação. Um conceito relacionado, confiança, diz respeito à segurança e à privacidade, e é visto como crescente quando percebido que tanto a segurança quanto a privacidade são oferecidas.

30.2 Controle de acesso discricionário baseado na concessão e revogação de privilégios O método típico para impor o controle de acesso discricionário em um sistema de banco de dados é baseado na concessão e revogação de privilégios. Vamos considerar os privilégios no contexto dc um SGBD relacionai. Em particular vamos discutir um sistema de privilégios um tanto semelhante ao desenvolvido originalmente para a linguagem SQL (ver capítulos 6 e 7). Muitos SGBDs relacionais atuais utilizam alguma variação dessa técnica. A ideia principal é incluir declarações na linguagem dc consulta que permitam que o DBA c os usuários selecionados concedam c revo­ guem privilégios.

30.2.1 Tipos de privilégios discricionários Na SQL2 e em versões posteriores,3 o conceito de identificador de autorização é usado para se referir, digamos assim, a uma conta dc usuário (ou grupo dc contas de usuário). Para simplificai; usaremos as palavras usuário ou conta para indicar a mesma coisa, no lugar dc identificador de autorização. O SGBD precisa fornecer acesso seletivo a cada relação no banco de dados com base em contas específicas. As operações também podem ser controladas; assim, ter uma conta não necessaria­ mente capacita seu mantenedor a toda a funcionalidade oferecida pelo SGBD. De maneira informal, existem dois níveis para a atribuição de privilégios na utilização do sistema dc banco de dados:

3 Privilégios discricionários foram incorporados à SQL2 e se aplicam a versões posteriores da SQL.

Capitulo 30

Segurança de banco de dados

■ O nível dc conta. Neste nível, o DBA especifica os privilégios em particular que cada conta mantém independentemente das relações no banco de dados. ■ O nível dc relação (ou tabela). Neste nível, o DBA pode controlar o privilégio para acessar cada relação ou visão individual no banco dc dados. Os privilégios no nível dc conta se aplicam às capacidades fornecidas à própria conta e podem incluir o privilégio CREATE SCHEMA ou CREATE TABLE, para criar um esquema ou relação básica; o privilégio CREATE VIEW; o privilégio ALTER, para apli­ car mudanças dc esquema como a inclusão ou remoção dc atributos das relações; o privilégio DROP, para excluir relações ou visões; o privilégio MODIFY, para inserir, excluir ou atualizar tuplas; e o privilégio SELECT, para recuperar informações do banco de dados usando uma consulta SELECT. Observe que esses privilégios de conta se aplicam à conta em geral. Se determinada conta não tiver o privilégio CREATE TABLE, nenhuma relação pode ser criada com base nessa conta. Os privilégios em nível dc conta wJo sào definidos como parte da SQL2; eles são deixados para os implementadores do SGBD definirem. Nas versões mais antigas da SQL, havia um privilégio CREATETAB para dar a uma conta o privilégio de criar tabelas (relações). O segundo nível de privilégios se aplica ao nível de relação, sejam elas relações básicas ou relações virtuais (visões). Esses privilégios sào definidos para a SQL2. Na discussão a seguir, o termo reiaçào pode se referir a uma relação básica ou a uma visão, a menos que especifiquemos dc maneira explícita uma ou outra. Os privilégios no nível dc relação especificam para cada usuário as relações individuais sobre as quais cada tipo de comando pode ser aplicado. Alguns privilégios também se referem a colunas (atributos) individuais das relações. Comandos SQL2 oferecem privilégios apenas no nível de reiaçào e atributo. Embora isso seja muito geral, torna-se difícil criar contas com privilégios limitados. A concessão e a revogação de privilégios costumam seguir um modelo de autorização para privilégios discricionários conhecido como modelo de matriz de acesso, no qual as linhas de uma matriz M representam sujeitos (usuários, contas, programas) e as colunas representam objetos (relações, registros, colunas, visões, operações). Cada posição M(í, j) na matriz representa os tipos de privilégios (leitura, gravação, atualização) que o sujeito / mantém sobre o objeto /. Para controlar a concessão e revogação dc privilégios de relação, cada relação R em um banco de dados recebe uma conta de proprietário, que normalmente é a conta utilizada quando a relação foi criada em primeiro lugar. O proprietário dc uma relação recebe todos os privilégios sobre essa relação. Em SQL2, o DBA pode atribuir um proprietário a um esquema inteiro ao criar o esquema c associar o identificador de autorização apropriado com esse esquema, usando o comando CREATE SCHEMA (ver Seção 6.1.1). O mantenedor da conta de proprietário pode passar privilégios para qualquer uma das relações possuídas aos outros usuários, concedendo privilégios às suas contas. Em SQL, os seguintes tipos de privilégios podem ser concedidos cm cada relação individual R:

■ Privilégio SELECT (recuperação ou leitura) em R. Dá o privilégio de recuperação da conta. Em SQL, isso dá à conta o privilégio de usar a instrução SELECT para recuperar tuplas de R. ■ Privilégios de modificação em R. Dá à conta a capacidade de modificar as tuplas de R. Em SQL, isso inclui três privilégios: UPDATE, DELETE e INSERT. Estes cor­ respondem aos três comandos SQL (ver Seçào 6.4) para modificar uma tabela R. Além disso, tanto o privilégio INSERT quanto o UPDATE podcin especificar que apenas certos atributos de R podem ser modificados pela conta. ■ Privilégio de referências em R. Dá à conta a capacidade de referenciar (ou refe­ rir-se a) uma relação R ao especificar restrições de integridade. Esse privilégio também pode ser restrito a atributos específicos de R.

1023

1024

Sistemas de banco de dados

Observe que, para criar uma visão, a conta precisa ter o privilégio SELECT em todas as relações envolvidas na definição da visão a fim de especificar a consulta que corresponde à visão.

30.2.2 Especificando privilégios por meio do uso de visões O mecanismo de visões (views) é um importante mecanismo de autorização discricionário por si só. Por exemplo, se o proprietário A de uma relação R quiser que outra conta B seja capaz de recuperar apenas alguns campos de R, então A pode criar uma visão V de R que inclua apenas os atributos e depois conceda SELECT para B sobre V. O mesmo se aplica à limitação de B para recuperar apenas certas tuplas de R; uma visão V pode ser criada ao definir a visão por meio de uma consulta que seleciona apenas as tuplas de R que A deseja permitir que B acesse. Ilustraremos essa discussão com o exemplo dado na Seção 30.2.5.

30.2.3 Revogação de privilégios Em alguns casos, é desejável conceder um privilégio a um usuário temporaria­ mente. Por exemplo, o proprietário de uma relação pode querer conceder o privilégio SELECT a um usuário para uma tarefa específica e, depois, revogar esse privilégio quando a tarefa for concluída. Logo, é preciso que haja um mecanismo para revogar privilégios. Em SQL, um comando REVOKE está incluído com a finalidade de cance­ lar privilégios. Veremos como esse comando é usado no exemplo da Seção 30.2.5.

30.2.4 Propagação de privilégios usando a GRANT OPTION Sempre que o proprietário A de uma relação R concede um privilégio em R para outra conta B, o privilégio pode ser dado a B com ou sem a GRANT OPTION. Se a GRANT OPTION for dada, isso significa que B também pode conceder esse privilégio em R para outras contas. Suponha que B receba a GRANT OPTION de A e que B então conceda o privilégio em R a uma terceira conta C, também com a GRANT OPTION. Desse modo, os privilégios em R podem se propagar para outras contas sem o conhecimento do proprietário de R. Se a conta de proprietário A agora revogar o privilégio concedido a B, todos os privilégios que B propagou com base nesse privilégio deverão ser revogados automaticamente pelo sistema. E possível que um usuário receba certo privilégio de duas ou mais fontes. Por exemplo, A4 pode receber um privilégio UPDATE R tanto de A2 quanto de A3. Nesse caso, se A2 revogar esse privilégio de A4, este ainda continuará a ter o privilégio em virtude de ter sido concedido por A3. Se A3 depois revogar o privilégio de A4, este perde totalmente o privilégio. Logo, o SGBD que permite a propagação de privilégios deve registrar como todos eles foram concedidos, de modo que sua revogação possa ser feira de maneira correra e completa.

30.2.5 Exemplo para ilustrar a concessão e revogação de privilégios Suponha que o DBA crie quatro contas — A1, A2, A3 e A4 — e queira que ape­ nas A1 possa criar relações básicas. Para fazer isso, o DBA precisa emitir o seguinte comando GRANT em SQL:

GRANT CREATETAB TO A1; O privilégio CREATETAB (criar tabela) dá à conta A1 a capacidade de criar novas tabelas de banco de dados (relações básicas) e, portanto, é um privilégio de conta. Esse privilégio fazia parte das versões anteriores da SQL, mas agora fica para cada

Capitulo 30

Segurança de banco de dados

1025

implementação de sistema individual definir. Observe que A1, A2 e assim por diante podem ser indivíduos, como João no departamento de TI ou Maria no Marketing; mas eles também podem ser aplicações ou programas que queiram acessar um banco de dados. Em SQL2, o mesmo efeito pode ser realizado com o DBA emitindo um comando CREATE SCHEMA, da seguinte forma:

CREATE SCHEMA EXEMPLO AUTHORIZATION A1;

A conta de usuário A1 agora pode criar tabelas sob o esquema chamado EXEMPLO. Para continuar nosso exemplo, suponha que A1 crie as duas relações básicas FUNCIONÁRIO e DEPARTAMENTO, mostradas na Figura 30.1; A1 é então o proprietário dessas duas relações e, portanto, tem todos os privilégios de relação em cada uma delas. Em seguida, suponha que a conta A1 queira conceder à conta A2 o privilégio para inserir e excluir tuplas nessas duas relações. Contudo, A1 não quer que A2 possa propagar esses privilégios para outras contas. A1 pode emitir o seguinte comando: GRANT INSERT, DELETE ON FUNCIONÁRIO, DEPARTAMENTO TO A2; Observe que a conta proprietário Al de uma relação automaticamente tem a GRANT OPTION, permitindo que ela conceda privilégios na relação para outras contas. Porém, a conta A2 não pode conceder privilégios INSERT e DELETE nas tabelas FUNCIONÁRIO e DEPARTAMENTO, pois A2 não recebeu a GRANT OPTION no comando anterior. A seguir, suponha que Al queira permitir que a conta A3 recupere informações de qualquer uma das duas tabelas, e que também possa propagar o privilégio SELECT para outras contas. A1 pode emitir o seguinte comando:

GRANT SELECT ON FUNCIONÁRIO, DEPARTAMENTO TO A3 WITH GRANT OPTION; A cláusula WITH GRANT OPTION significa que A3 agora pode propagar o privilé­ gio para outras contas usando GRANT. Por exemplo, A3 pode conceder o privilégio SELECT na relação FUNCIONÁRIO para A4 ao emitir o seguinte comando: GRANT SELECT ON FUNCIONÁRIO TO A4;

Observe que A4 não pode propagar o privilégio SELECT para outras contas, pois a GRANT OPTION não foi dada a A4. Agora, suponha que Al decida revogar o privilégio SELECT na relação FUNCIONÁRIO de A3; A1 pode então emitir este comando: REVOKE SELECT ON FUNCIONÁRIO FROM A3;

O SGBD agora precisa revogar o privilégio SELECT em FUNCIONÁRIO de A3, e também deve revogar automaticamente o privilégio SELECT em FUNCIONÁRIO de A4. Isso porque A3 concedeu esse privilégio a A4, mas A3 não tem mais o privilégio. Em seguida, suponha que Al queira dar de volta a A3 uma capacidade limitada para SELECT da relação FUNCIONÁRIO e queira permitir que A3 possa propagar o privilégio. A limitação é recuperar apenas os atributos Nome, Data_nascimento e

FUNCIONÁRIO

Nome

çeL Data nascimento Endereço Sexo

Salario Numero departamento

DEPARTAMENTO Numero_departamento

Nome_departamento Cpf_gerente

Figura 30.1 Esquemas para as duas relações, FUNCIONÁRIO e DEPARTAMENTO.

1026 Sistemas de banco de dados

Endereço e somente para as tuplas com Numero.departamento = 5. A1, então, cria a seguinte visão: CREATE VIEW A3FUNCIONARIO AS SELECT Nome, Data.nascimento, Endereço FROM FUNCIONÁRIO WHERE Numero.departamento = 5;

Depois que a visão estiver criada, A1 pode conceder SELECT na visão A3FUNCIONARIO para A3 da seguinte forma:

GRANT SELECT ON A3FUNCIONARIO TO A3 WITH GRANT OPTION,

Finalmente, suponha que A1 queira permitir que A4 atualize apenas o atributo Salario de FUNCIONÁRIO; A1 pode então emitir o seguinte comando: GRANT UPDATE ON FUNCIONÁRIO (Salario) TO A4;

Os privilégios UPDATE e INSERT especificam atributos em particular que podem ser atualizados ou inseridos em uma relação. Outros privilégios (SELECT, DELETE) não são específicos do atributo, pois essa especificidade pode facilmente ser contro­ lada ao criar as visões apropriadas que incluam apenas os atributos desejados e ao conceder os privilégios correspondentes nas visões. No entanto, como a atualização de visões nem sempre é possível (ver Capítulo 7), os privilégios UPDATE e INSERT recebem a opção de especificar os atributos em particular de uma relação básica que podem ser atualizados.

30.2.6 Especificando limites na propagação de privilégios Técnicas para limitar a propagação de privilégios foram desenvolvidas, embora ainda não tenham sido implementadas na maioria dos SGBDs e não façam parte da SQL. Limitar a propagação horizontal para um número inteiro i significa que uma conta B que recebe a GRANT OPTION pode conceder o privilégio a, no máximo, i outras contas. A propagação vertical é mais complicada; ela limita a profundidade da concessão de privilégios. A concessão de um privilégio com uma propagação vertical de zero é equi­ valente a conceder o privilégio sem GRANT OPTION. Se a conta A concede um privilégio à conta B com a propagação vertical definida para um número inteiro / > 0, isso significa que a conta B tem a GRANT OPTION sobre esse privilégio, mas B pode conceder o privi­ légio a outras contas somente com uma propagação vertical menor que j. Com efeito, a propagação vertical limita a sequência de GRANT OPTIONS que podem scr dadas de uma conta para a seguinte, com base em uma única concessão original do privilégio. Ilustramos rapidamente os limites de propagação horizontal e vertical — que não estão disponíveis atualmente em SQL ou em outros sistemas relacionais — com um exemplo. Suponha que A1 conceda SELECT a A2 na relação FUNCIONÁRIO com propagação horizontal igual a 1 e propagação vertical igual a 2. A2 pode então conceder SELECT a, no máximo, uma conta, pois a limitação dc propagação hori­ zontal é definida como 1. Além disso, A2 não pode conceder o privilégio para outra conta, exceto com a propagação vertical definida como 0 (sem GRANT OPTION) ou 1; isso porque A2 precisa reduzir a propagação vertical em pelo menos 1 ao passar o privilégio para outros. Além disso, a propagação horizontal precisa scr menor ou igual à concedida originalincntc. Por exemplo, sc a conta A concede um privilégio à conta B com a propagação horizontal definida como um número inteiro / > 0, isso significa que B pode conceder o privilégio para outras contas apenas com uma propagação horizontal menor ou igual a j. Como esse exemplo mostra, as técnicas de propagação horizontal e vertical são projetadas para limitar a profundidade e a largura de propagação de privilégios.

Capitulo 30

Segurança de banco de dados

30.3 Controle de acesso obrigatório e controle de acesso baseado em papel para segurança multinível A técnica de controle de acesso discricionário de conceder e revogar privilégios cm relações tradicionalmente tem sido o principal mecanismo de segurança para os sistemas de banco de dados relacionai. E um método tudo ou nada: um usuário tem ou não tem certo privilégio. Em muitas aplicações, uma política de segurança adicio­ nal é necessária para classificar dados e usuários com base nas classes de segurança. Essa técnica, conhecida como controle de acesso obrigatório (MAC — mandatory access control}, normalmente seria combinada com os mecanismos de controle de acesso discricionários descritos na Seção 30.2. É importante observar que a maioria dos SGBDRs comerciais hoje oferece mecanismos somente para o controle de acesso discricionário. Porém, a necessidade de segurança multinível existe em aplicações do governo, militares e de inteligência, bem como em muitas aplicações industriais e corporativas. Em virtude das preocupações primordiais com a privacidade, em muitos sistemas, os níveis são determinados por quem tem qual acesso a que infor­ mação privada (também chamada de informação pessoalmente identificável). Alguns vendedores de SGBD — por exemplo, Oracle — lançaram versões especiais de seus SGBDRs que incorporam o controle de acesso obrigatório para uso do governo. Classes de segurança típicas são: altamente confidencial (top secret, TS), secreta (secret, S), confidencial (confidential, C) e não classificada (unclassified, U), com TS sendo o nível mais alto e U, o mais baixo. Existem outros esquemas de classificação de segurança mais complexos, em que as classes de segurança são organizadas em um reticulado. Para simplificar, usaremos o sistema com quatro níveis de classificação de segurança, no qual TS S C U, para ilustrar nossa discussão. O modelo normalmente utilizado para segurança multinível, conhecido como modelo de Bell-LaPadula,4 classifica cada sujeito (usuário, conta, programa) e objeto (relação, tupla, coluna, visão, operação) em uma das classificações de segurança TS, S, C ou U. Vamos nos referir à autorização (classificação) de um sujeito S como dasse(S) e à classificação de um objeto O como classe(O). Duas restrições são impostas no acesso aos dados com base nas classificações de sujeito/objeto: 1. Um sujeito S não tem permissão para acesso de leitura a um objeto O a menos que classe(S) classc(O). Isso é conhecido como propriedade de segurança simples.

2. Um sujeito S não tem permissão para gravar um objeto O a menos que classe(S) classe(O). Isso é conhecido como propriedade estrela (ou propriedade * ). A primeira restrição é intuitiva e impõe a regra óbvia de que nenhum sujeito pode ler um objeto cuja classificação de segurança é maior que a autorização de segurança do sujeito. A segunda restrição é menos intuitiva. Ela proíbe um sujeito de gravar um objeto em uma classificação de segurança inferior que a autorização de segurança do sujeito. A violação dessa regra permitiría que a informação fluísse de classificações mais altas para mais baixas, o que viola um princípio básico da segurança multinível. Por exemplo, um usuário (sujeito) com autorização TS pode fazer uma cópia de um objeto com classificação TS e, depois, gravá-lo de volta como um novo objeto com classificação U, tornando-o assim visível por todo o sistema. Para incorporar noções de segurança multinível ao modelo de banco de dados relacionai, é comum considerar valores de atributo e tuplas como objetos de dados. Logo, cada atributo A está associado a um atributo de classificação C no esquema. 4 Bell e La Padulla (1976) foi um relatório técnico do MURE sobre sistemas de computação seguros no Multics.

1027

1028

Sistemas de banco de dados

e cada valor de atributo em uma tupla está associado a uma classificação de segu­ rança correspondente. Além disso, em alguns modelos, um atributo de classificação de tupla TC é acrescentado aos atributos de relação para fornecer uma classificação para cada tupla como um todo. O modelo que descrevemos aqui é conhecido como modelo multinível, pois permite classificações em múltiplos níveis de segurança. Um esquema de relação multinível R com n atributos seria representado como: R(A], Cj, À2, C2,

C„, TC)

em que cada Cf representa o atributo de classificação associado ao atributo A? O valor do atributo de classificação de tupla TC em cada tupla t — que é o mais alto de todos os valores de classificação dc atributo dentro de t — oferece uma classificação geral para a própria tupla. Cada classificação dc atributo C, oferece uma classificação de segurança mais detalhada para cada valor de atributo dentro da tupla. O valor de TC em cada tupla té o mais alto de todos os valores de classi­ ficação de atributo C- dentro de t. A chave aparente de uma relação multinível é o conjunto de atributos que teri a formado a chave primária em uma relação comum (único nível). Uma relação multinível parecerá conter diferentes dados para sujeitos (usuários) com níveis de autorização distintos. Em alguns casos, é possível armazenar uma única tupla na relação em um nível de classificação mais alto e produzir as tuplas correspondentes em uma classificação de nível inferior por meio dc um processo conhecido como filtragem. Em outros casos, é necessário armazenar duas ou mais tuplas cm níveis dc classificação diferentes, com o mesmo valor para a chave aparente. Isso leva ao conceito de poli-instanciação? em que várias tuplas podem ter o mesmo valor de chave aparente, mas com diferentes valores de atributo para usuários em diversos níveis dc autorização. Ilustramos esses conceitos com o exemplo simples dc uma relação multinível mostrada na Figura 30.2(a), em que apresentamos os valores de atributo de clas­ sificação ao lado do valor de cada atributo. Suponha que o atributo Nome seja a chave aparente e considere a consulta SELECT ' FROM FUNCIONÁRIO. Um usuá­ rio com autorização de segurança S veria a mesma relação mostrada na Figura 30.2(a), pois todas as classificações dc tupla são menores ou iguais a S. Contudo, um usuário com autorização de segurança C não poderia ver os valores para Salario dc ‘Borges’ e Desempenho_cargo de ‘Silva’, pois eles tem classificação mais alta. As tuplas seriam filtradas para aparecerem como mostra a Figura 30.2(b), com Salario e Desempenho_cargo aparecendo como nulos. Para um usuário com autorização de segurança U, a filtragem só permite que o atributo Nome dc ‘Silva’ apareça, com todos os outros atributos aparecendo como nulos [Figura 30.2(c)). Assim, a filtragem introduz valores nulos para valores de atributo cuja classificação de segurança é mais alta que a autorização de segurança do usuário. Em geral, a regra de integridade de entidade para relações multinível indica que todos os atributos que são membros da chave aparente não devem ser nulos e pre­ cisam ter a mesma classificação dc segurança dentro dc cada tupla individual. Além disso, todos os outros valores de atributo na tupla precisam ter uma classificação de segurança maior ou igual à da chave aparente. Essa restrição garante que um usuário pode ver a chave se o usuário tiver permissão para ver qualquer parte da tupla. Outras regras de integridade, chamadas integridade nula c integridade entre instâncias, garantem informalmentc que, se um valor dc tupla em algum nível de segurança puder ser filtrado (derivado) dc uma tupla com classificação mais alta, é suficiente armazenar a tupla classificada mais alto na relação multinível. 5 Isso é semelhante à noção de ter múltiplas versões no banco de dados que representam o mesmo ob­ jeto do mundo real.

Capitulo 30

(a)

Segurança de banco de dados

Figura 30.2 Uma relação

FUNCIONÁRIO

Nome

Salario

Desempenho cargo

TC

U

40000

C

Regular

S

S

Borges C

80000

S

Bom

C

S

Silva

1029

multinível para ilustrar a

segurança multinível. (a) As tuplas FUNCIONÁRIO

originais, (b) Aparência de FUNCIONÁRIO depois da

(b)

filtragem para usuários com

FUNCIONÁRIO

Nome Silva

classificação C. (c) Aparência

Desempenho cargo

Salario

U

Borges C

40000 NULL

C C

NULL

Bom

C C

TC

de FUNCIONÁRIO depois

C

da filtragem para usuários

C

com classificação U. (d) Poli-instanciação da tupla de Silva.

(C)

FUNCIONÁRIO

Nome Silva

(d)

Desempenho cargo

Salario U

NULL

U

NULL

U

TC

U

FUNCIONÁRIO

Nome Silva U Silva U Borges C

Desempenho cargo

Salario

40000 40000 80000

C C S

Regular Excelente Bom

S C C

TC

S

C S

Para ilustrar ainda mais a poli-instanciaçào, suponha que um usuário com auto­ rização de segurança C tente atualizar o valor de Desempenho_cargo de ‘Silva' na Figura 30.2 para ‘Excelente’; isso corresponde à seguinte atualização SQL sendo submetida por esse usuário: UPDATE FUNCIONÁRIO SET DesempenhO-Cargo = ‘Excelente’ WHERE Nome =‘Silva’; Como a visão fornecida aos usuários com autorização de segurança C [ver Figura 30.2(b)] permite tal atualização, o sistema não deve rejeitá-la; caso contrário, o usuário poderia deduzir que algum valor não nulo existe para o atributo Desempenho_cargo de ‘Silva’, em vez do valor nulo que aparece. Esse é um exemplo de dedução de infor­ mações conhecido como um canal secreto, que não deve ser permitido em sistemas altamente seguros (ver Seção 30.6.1). Porém, o usuário não deve ter permissão para gravar sobre o valor existente de Desempenho_cargo no nível de classificação mais alto. A solução é criar uma poli-instanciação para a tupla ‘Silva’ no nível de classificação mais baixo C, como mostra a Figura 30.2(d). Isso é necessário porque a nova tupla não pode ser filtrada com base na tupla existente na classificação S. As operações de atualização básicas do modelo relacionai (INSERT, DELETE, UPDATE) devem ser modificadas para lidar com esta e outras situações semelhantes, mas esse aspecto do problema está fora do escopo de nossa apresentação. O leitor interessado deverá consultar a bibliografia selecionada, ao final deste capítulo, para obter mais detalhes.

30.3.1 Comparando os controles de acesso discricionário e obrigatório As políticas do controle de acesso discricionário (DAC) sào caracterizadas por um alto grau de flexibilidade, que as torna adequadas para uma grande varie­ dade de domínios de aplicação. A principal desvantagem dos modelos DAC c sua

1030

Sistemas de banco de dados

vulnerabilidade a ataques maliciosos, como cavalos de Troia embutidos nos progra­ mas de aplicação. O motivo é que os modelos de autorização discricionários não impõem qualquer controle sobre como a informação é propagada e utilizada depois de ter sido acessada pelos usuários autorizados a fazer isso. Ao contrário, as políticas obrigatórias garantem um alto grau de proteção — de certa forma, elas impedem qualquer fluxo de informação ilegal. Portanto, são adequadas para aplicações mili­ tares e outros tipos de alta segurança, que exigem um grau de proteção mais alto. Porem, as políticas obrigatórias têm a desvantagem de serem muito rígidas porque exigem uma classificação estrita de sujeitos e objetos nos níveis de segurança, e, dessa forma, se aplicam a poucos ambientes e impõem um peso adicional da rotulagem de cada objeto com sua classificação de segurança. Em muitas situações práticas, as políticas discricionárias são preferidas às obrigatórias porque oferecem maior facilidade de escolha entre segurança e aplicabilidade.

30.3.2 Controle de acesso baseado em papéis O controle de acesso baseado em papéis (RBAC) surgiu rapidamente na década de 1990 como uma tecnologia comprovada para gerenciar e impor a segurança em sistemas em grande escala por toda a empresa. Sua noção básica é que os privilégios e outras permissões são associados a papéis organizacionais, em vez de a usuários individuais. Tais usuários individuais recebem então os papéis apropriados. Os papéis podem ser criados com o uso dos comandos CREATE ROLE e DESTROY ROLE. Os coman­ dos GRANT e REVOKE, discutidos na Seção 30.2, podem então ser usados para atribuir e revogar privilégios dos papéis, bem como para usuários individuais, quando neces­ sário. Por exemplo, uma empresa pode ter papéis como gerente de conta de vendas, agente de compras, funcionário de entrega, gerente de suporte ao cliente, e assim por diante. Vários indivíduos podem ser designados para cada papel. Os privilégios de segurança comuns a um papel são concedidos ao nome dele, e qualquer indivíduo designado para esse papel automaticamente teria esses privilégios concedidos. O RBAC pode ser usado com os controles de acesso discricionário e obrigatório tradicionais; ele garante que somente usuários autorizados em seus papéis especifi­ cados recebam acesso a certos dados ou recursos. Os usuários criam sessões durante as quais podem ativar um subconjunto de papéis às quais pertencem. Cada sessão pode ser atribuída a vários papéis, mas ela é mapeada para um usuário ou apenas para um único sujeito. Muitos SGBDs têm permitido o conceito de papéis, nos quais os privilégios podem ser atribuídos aos papéis. A separação de tarefas é outro requisito importante em diversos SGBDs con­ vencionais. Isso é necessário para impedir que um usuário realize o trabalho que requer o envolvimento de duas ou mais pessoas, impedindo assim a conivência. Um método cm que a separação de tarefas pode ser implementada com sucesso é a exclusão mútua de papéis. Dois papéis são considerados mutuamente exclusivos se ambos não puderem ser usados simultaneamente pelo usuário. A exclusão mútua de papéis pode ser categorizada em dois tipos, a saber, exclusão em tempo de autoriza­ ção (estática} e exclusão em tempo de execução (dinâmica}. Na exclusão em tempo de autorização, dois papéis especificados como mutuamente exclusivos não podem fazer parte da autorização de um usuário ao mesmo tempo. Na exclusão em tempo de execução, esses dois papéis podem ser autorizados a um usuário, mas não podem ser ativados por ele ao mesmo tempo. Outra variação na exclusão mútua de papéis é aquela da exclusão completa e parcial. A hierarquia de papéis no RBAC é um modo natural de organizar papéis para refletir as linhas de autoridade e responsabilidade da organização. Por convenção, os papéis júnior no fundo da hierarquia estão conectados a papéis progressivamente

Capitulo 30

Segurança de banco de dados

sênior à medida que um deles sobe na hierarquia. Os diagramas hierárquicos sào ordens parciais, de modo que sào reflexivos, transitivos e antissimétricos. Em outras palavras, se um usuário tem um papel, ele automaticamente tem papéis inferiores na hierarquia. A definição de uma hierarquia de papéis envolve escolher o tipo de hierarquia e os papéis, para depois implementar a hierarquia concedendo papéis a outros papéis. Essa hierarquia pode ser implementada da seguinte maneira:

GRANT ROLE tempojntegral TO funcionario_tipo1 GRANT ROLE interno TO funcionario_tipo2 Estes sào exemplos de concessão de papéis tempojntegral e interno para dois tipos dc funcionários. Outra questão relacionada à segurança é o gerenciamento de identidade. Identidade refere-se a um nome único de uma pessoa individual. Como os nomes válidos de pessoas não são necessariamente únicos, a identidade de uma pessoa precisa incluir informações adicionais suficientes para tornar único o nome completo. Autorizar essa identidade e gerenciar o esquema dessas identidades é chamado de gerenciamento de identidade. O gerenciamento de identidade explica como as organizações podem efetivamente autenticar as pessoas e gerenciar seu acesso a informações confidenciais. Isso tem se tomado mais visível como um requisito de negócios por todos os setores que afetam as organizações de rodos os tamanhos. Os administradores de gerencia­ mento de identidade constantemente precisam satisfazer os proprietários da aplicação enquanto mantêm os gastos sob controle e aumentam a eficiência da TI. Outra consideração importante nos sistemas RBAC são as restrições temporais possíveis que podem existir nos papéis, como o horário e a duração das ativações de papéis e o disparo temporizado de um papel por uma ativação de outro papel. O uso dc um modelo RBAC é um objetivo altamcnte desejável para a resolução dos principais requisitos de segurança das aplicações baseadas na web. Os papéis podem ser designados a tarefas de fluxo de trabalho, de modo que um usuário com qualquer um dos papéis relacionados a uma tarefa pode ser autorizado a executá-la e pode desempenhar certo papel somente por determinada duração. Os modelos RBAC têm vários recursos desejáveis, como flexibilidade, neutrali­ dade dc política, melhor suporte para gerenciamento e administração de segurança, e uma imposição natural da estrutura organizacional hierárquica dentro das organi­ zações. Eles também possuem outros aspectos que os tomam candidatos atraentes para desenvolver aplicações seguras baseadas na web. Esses recursos não existem nos modelos DAC e MAC. Modelos RBAC incluem as capacidades disponíveis nas políticas DAC e MAC tradicionais. Além disso, um modelo RBAC oferece meca­ nismos para resolver as questões de segurança relacionadas à execução de tarefas e fluxos de trabalho, e para especificar políticas definidas pelo usuário e específicas da organização. A implantação mais fácil pela internet tem sido outra razão para o sucesso desse tipo de modelos RBrXC.

30.3.3 Segurança baseada em rótulos e controle de acesso em nível de linha Muitos SGBDs convencionais atualmente usam o conceito de controle de acesso em nível de linha, em que regras sofisticadas de controle de acesso podem ser imple­ mentadas ao considerar os dados linha por linha. No controle dc acesso em nível de linha, cada linha dc dados recebe um rótulo, usado para armazenar informações sobre a sensibilidade dos dados. O controle de acesso em nível de linha oferece maior detalhamento de segurança dos dados, deixando que as permissões sejam definidas para cada linha e não apenas para a tabela ou coluna. Inicialmente o usuário recebe

1031

1032

Sistemas de banco de dados

um rótulo de sessão padrão pelo administrador do banco de dados. Os níveis cor­ respondem a uma hierarquia de níveis de sensibilidade de dados para exposição ou adulteração, com o objetivo de manter a privacidade ou a segurança. Os rótulos são usados para impedir que usuários não autorizados vejam ou alterem certos dados. Um usuário com baixo nível de autorização, normalmente representado por um número baixo, tem acesso negado a dados com número de nível mais alto. Se esse rótulo não for dado a uma linha, um rótulo dc linha c automaticamente atribuído a ela, dependendo do rótulo de sessão do usuário. Uma política definida por um administrador é chamada de política de rótulos de segurança. Sempre que os dados afetados pela política são acessados ou consultados por uma aplicação, a política é automaticamente chamada. Quando uma política é implementada, uma nova coluna é acrescentada a cada linha no esquema. A coluna adicionada contém o rótulo para cada linha que reflete a sensibilidade da linha quanto à política. Semelhante ao MAC, em que cada usuário tem uma autorização de segurança, na segurança baseada em rótulo cada usuário tem uma identidade. A identidade desse usuário é comparada com o rótulo atribuído a cada linha para determinar se ele tem acesso para ver o conteúdo dessa linha. Porém, o próprio usuário pode gravar o valor do rótulo, dentro de certas restrições e diretrizes para essa linha específica. Esse rótulo pode ser definido como um valor que está entre o rótulo da sessão atual do usuário e o nível mínimo do usuário. O DBA tem o privilégio para definir um rótulo de linha padrão inicial. Os requisitos da segurança de rótulos são aplicados cm cima dos requisitos do DAC para cada usuário. Logo, o usuário precisa satisfazer os requisitos do DAC e, depois, os requisitos de segurança de rótulo para acessar uma linha. Os requisitos do DAC garantem que o usuário é legalmente autorizado a executar essa operação no esquema. Na maioria das aplicações, somente algumas das tabelas precisam de segurança baseada em rótulo. Para a maioria das tabelas da aplicação, a proteção fornecida pelo DAC é suficiente. As políticas dc segurança gcralmentc são criadas por gerentes c pelo pessoal de recursos humanos. Elas são de alto nível, independentes da tecnologia e relacionadas aos riscos. As políticas são um resultado das instruções da gerência para especificar procedimentos organizacionais, princípios de orientação e cursos de ação conside­ rados ágeis, prudentes ou vantajosos. Tais políticas costumam ser acompanhadas por uma definição dc penalidades e contramedidas se a política for transgredida. Essas políticas são então interpretadas e convertidas para um conjunto de políticas orientadas a rótulos pelo administrador de rótulos de segurança, que define os rótulos de segurança para os dados e autorizações para os usuários; esses rótulos e autorizações controlam o acesso aos objetos protegidos especificados. Suponha que um usuário tenha privilégios SELECT em uma tabela. Quando o usuário executa uma instrução SELECT nessa tabela, a segurança de rótulos automa­ ticamente avaliará cada linha retornada pela consulta para determinar se o usuário tem direitos para ver os dados. Por exemplo, se o usuário tiver uma sensibilidade de 20, então ele pode ver todas as linhas com um nível de segurança menor ou igual a 20. O nível determina a sensibilidade da informação contida em uma linha; quanto mais sensível a linha, maior é seu valor dc rótulo dc segurança. Tal rótulo de segurança também pode ser configurado para realizar verificações de segurança em instruções UPDATE, DELETE e INSERT.

30.3.4 Controle de acesso por XML Com o uso generalizado da XML cm aplicações comerciais c científicas, tem havido esforços para desenvolver padrões dc segurança. Entre esses esforços estão assinaturas

Capitulo 30

Segurança de banco de dados

digitais e padrões de criptografia para XML. A especificação de Processamento e Sintaxe de Assinaturas em XML descreve uma sintaxe em XML para representar as associações entre assinaturas criptográficas e documentos em XML ou outros recursos eletrônicos. A especificação também inclui procedimentos para calcular e verificar assinaturas em XML Uma assinatura digital em XML difere de outros protocolos para assinatura de mensagem, como OpenPGP (pretty good privacy — um serviço de confidencialidade e autenticação que pode ser usado para aplicações de correio eletrônico e armazenamento de arquivo), em seu suporte para assinar apenas partes específicas da árvore em XML (ver Capítulo 13) em vez do documento completo. Além disso, a especificação de assinatura em XML define mecanismos para adicionar uma assinatura e transformações — a chamada canonização — para garantir que duas instâncias de um texto produzam um resumo igual para assinatura, mesmo que suas representações difiram ligeiramente, por exemplo, no espaço em branco tipográfico. A especificação de Processamento e Sintaxe de Criptografia em XML define o vocabulário em XML e as regras de processamento para proteger a confidencialidade de documentos XML no todo ou em parte, além de dados não XML. O conteúdo codificado e as informações de processamento adicionais para o destinatário são representados na XML bem formada, de modo que o resultado pode ser proces­ sado ainda mais usando ferramentas XML. Ao contrário de outras tecnologias normalmente utilizadas para confidencialidade, como a SSL (secure sockets layer — um importante protocolo de segurança da internet) e redes privativas virtuais, a criptografia em XML também se aplica a partes de documentos e a documentos em armazenamento persistente. Sistemas de banco de dados como PostgreSQL ou Oracle têm suporte para objetos JSON {JavaScript object notation) como formato de dados, e possuem facilidades semelhantes para objetos JSON, como as definidas anteriormente para XML.

30.3.5 Políticas de controle de acesso para a web e aplicativos móveis Ambientes de aplicação web acessíveis publicamente apresentam um desafio exclusivo para a segurança do banco de dados. Esses sistemas incluem os responsáveis por lidar com informações confidenciais ou privadas e incluem redes sociais, servido­ res de API de aplicativos móveis e plataformas de transação de comércio eletrônico. Os ambientes de comércio eletrônico (e-commerce) são caracterizados por quaisquer transações que sejam feitas eletronicamente. Eles exigem políticas elabo­ radas de controle de acesso, que vão além dos SGBDs tradicionais. Em ambientes de banco de dados convencionais, o controle de acesso normalmente é realizado usando-se um conjunto de autorizações indicadas pelos agentes de segurança ou usuários de acordo com algumas políticas de segurança. Esse paradigma simples não é muito adequado para um ambiente dinâmico como o e-commerce. Além disso, em um ambiente de e-commerce, os recursos a serem protegidos não são apenas dados tradicionais, mas também conhecimento e experiência. Essas peculiaridades exigem mais flexibilidade na especificação de políticas de controle de acesso. O mecanismo de controle de acesso precisa ser flexível o suficiente para dar suporte a um grande espectro de objetos de proteção heterogêneos. Como muitos sistemas de reservas, emissão de bilhetes, pagamentos e compras on-line processam informações protegidas por lei, para proteger as informações, deve-se implementar uma arquitetura de segurança que vai além do simples controle de acesso ao banco de dados. Quando uma parte não autorizada acessa informações protegidas de forma inadequada, isso equivale a um vazamento de dados, que tem consequências legais e financeiras significativas. Essa parte não autorizada pode ser um adversário que busca ativamente roubar informações protegidas ou pode ser um funcionário que

1033

1034

Sistemas de banco de dados

extrapolou sua função ou distribuiu incorreta mente informações confidenciais para outras pessoas. A manipulação inadequada de dados de cartão de crédito, por exemplo, tem levado a violações de dados significativas nos principais varejistas. Em ambientes de banco de dados convencionais, o controle de acesso geralmente é executado usando-se um conjunto de autorizações declaradas pelos agentes de segurança. Mas, nos aplicativos da web, é muito comum que o próprio aplicativo seja o usuário, e não um indivíduo devidamente autorizado. Isso dá origem a uma situação em que os mecanismos de controle de acesso do DBMS são ignorados e o banco de dados se torna apenas um armazenamento de dados relacionai para o sistema. Em tais ambientes, vulnerabilidades como injeção de SQL (que abordamos em profundidade na Seção 30.4) se tornam significarivamente mais perigosas, já que podem levar a uma violação total dos dados, em vez de se limitarem a dados que uma determinada conta está autorizada a acessar. Para proteger contra violações de dados nesses sistemas, um primeiro requisito é uma política de segurança da informação abrangente, que vá além dos mecanismos técnicos de controle de acesso encontrados nos principais SGBDs. Essa política deve proteger não apenas dados tradicionais, mas também processos, conhecimento e experiência. Um segundo requisito relacionado é o suporte para controle dc acesso baseado em conteúdo. O controle dc acesso baseado cm conteúdo permite que alguém expresse políticas de controle de acesso que levem em consideração o conteúdo do objeto de proteção. Para dar suporte ao controle de acesso baseado em conteúdo, as políticas dc controle precisam permitir a inclusão de condições com base no conteúdo do objeto. Um terceiro requisito está relacionado à hetcrogcncidade dos sujeitos, que requer políticas de controle de acesso baseadas nas características e qualificações do usuário, em vez de nas características específicas e individuais (por exemplo, IDs de usuário). Uma solução possível, para melhor levar em conta os perfis de usuário na formula­ ção das políticas de controle de acesso, é dar suporte à noção de credenciais. Uma credencial é um conjunto de propriedades referentes a um usuário, relevantes para fins de segurança (como idade ou cargo dentro dc uma organização). Por exemplo, ao usar credenciais, pode-se simplesmente formular políticas como: somente o pessoal permanente com cinco ou mais anos de serviço pode acessar documentos relacionados aos detalhes internos do sistema. Acredita-se que a XML deverá desempenhar um papel fundamental no controle dc acesso para aplicações de c-commcrce6 porque ela está se tornando a linguagem dc representação comum para troca de documentos pela web, e também está se tornando a linguagem para e-commerce. /\ssim, por um lado, existe a necessidade de tornar as representações em XML seguras, oferecendo mecanismos de controle de acesso moldados especificamente à proteção de documentos em XML. Por outro lado, a informação de controle de acesso (ou seja, políticas de controle de acesso e credenciais do usuário) pode ser expressa usando-se a própria XML. A Linguagem de Marcação do Serviço de Diretórios (DSML — directory sendees markup language) é uma representação da informação de serviço de diretório na sintaxe XML. Ela oferece um alicerce para um padrão de comunicação com serviços de diretório que serão responsáveis por oferecer e autenticar credenciais do usuário. A apresentação uniforme de objetos de proteção e políticas de controle de acesso pode ser aplicada às próprias políticas e credenciais. Por exemplo, algumas propriedades de credencial (como o nome do usuário) podem ser acessíveis a todos, ao passo que outras pro­ priedades podem ser visíveis apenas para uma classe de usuários restrita. Ademais, o uso de uma linguagem baseada em XML para especificar credenciais e políticas de controle de acesso facilita a submissão segura da credencial e a exportação de políticas de controle de acesso. Ver Thuraisingham ct al. (2001).

Capitulo 30

Segurança de banco de dados

30.4 Injeção de SQL Injeção de SQL é uma das ameaças mais comuns a um sistema de banco de dados. Vamos discuri-la com detalhes mais adiante, nesta seção. Alguns dos outros ataques a bancos de dados, que são muito Frequentes, são:

■ Escalada de privilégios não autorizada. Este ataque é caracterizado por um indi­ víduo que tenta elevar seu privilégio atacando pontos vulneráveis nos sistemas de banco de dados. ■ Abuso de privilégio. Enquanto o ataque anterior é Feito por um usuário não autorizado, este é realizado por um usuário privilegiado. Por exemplo, um admi­ nistrador que tem permissão para alterar a informação do aluno pode usar esse privilégio para atualizar notas dc alunos sem a permissão do proFcssor. ■ Negação de serviço. Um ataque dc negação de serviço (DOS — denial ofsendee) é uma tentativa dc tornar recursos indisponíveis a seus usuários intencionados. Esta é uma categoria dc ataque geral cm que o acesso a aplicações ou dados da rede é negado aos usuários legítimos pelo estouro do buFFcr ou esgotamento de recursos. ■ Autenticação Fraca. Sc o esquema de autenticação do usuário For Fraco, um atacante pode personificar a identidade de um usuário legítimo ao obter suas credenciais de login.

30.4.1 Métodos de injeção de SQL Conforme discutimos no Capítulo 11, programas c aplicações web que acessam um banco dc dados podem enviar comandos c dados a ele, bem como exibir dados recuperados por meio do navegador web. Em um ataque de injeção de SQL, o atacante injeta uma entrada de cadeia de caracteres pela aplicação, que muda ou manipula a instrução SQL para o proveito do atacante. Um ataque de injeção de SQL pode prejudicar o banco de dados de várias maneiras, como na manipulação não autorizada do banco de dados, ou na recuperação de dados confidenciais. Ele também pode ser usado para executar comandos em nível do sistema que podem fazer o sistema negar serviço à aplicação. Esta seção descreve tipos de ataques de injeção. Manipulação de SQL. Um ataque de manipulação, o ripo mais comum de ataque de injeção, muda um comando SQL na aplicação — por exemplo, ao acrescentar condições à cláusula WHERE dc uma consulta, ou ao expandir uma consulta com componentes dc consulta adicionais, usando operações de união como UNION, INTERSECT ou MINUS. Outros tipos de ataques de manipulação também são possíveis. Um ataque de manipulação típico ocorre durante o login do banco de dados. Por exemplo, suponha que um procedimento dc autenticação ingênuo emita a seguinte consulta c verifique se alguma linha foi retornada: SELECT ’ FROM usuários WHERE nomeusuario = 'jaime' and SENHA = 'senhajaime';

O atacante pode tentar alterar (ou manipular) a instrução SQL, alterando-a da seguinte forma: SELECT * FROM usuários WHERE nomeusuario = 'jaime' and (SENHA = 'senhajaime' or 'x' = 'x');

Como resultado, o atacante que sabe que ‘jaime’ é um login válido de algum usuário pode se logar no sistema de banco de dados como ‘jaime’ sem conhecer sua senha e ser capaz de fazer tudo o que ‘jaime’ pode estar autorizado a fazer nesse sistema de banco de dados.

1035

1036

Sistemas de banco de dados

Injeção de código. Este tipo de ataque tenta acrescentar instruções SQL ou coman­ dos adicionais à instrução SQL existente, explorando um bug do computador, causado pelo processamento de dados inválidos. O atacante pode injetar ou introduzir código em um programa de computador para alterar o curso da execução. A injeção de código é uma técnica popular para a invasão ou penetração do sistema para obter informações. Injeção de chamada de função. Neste tipo de ataque, uma função do banco de dados ou uma chamada de função do sistema operacional é inserida em uma ins­ trução SQL vulnerável para manipular os dados ou fazer uma chamada do sistema privilegiada. Por exemplo, é possível explorar uma função que realiza algum aspecto relacionado à comunicação na rede. Além disso, as funções contidas em um pacote de banco de dados personalizado, ou qualquer função de banco de dados personalizada, podem ser executadas como parte de uma consulta SQL. Em particular, consultas SQL criadas dinamicamente (ver Capítulo 10) podem ser exploradas, visto que são construídas em tempo de execução. Por exemplo, a tabela dual é usada na cláusula FROM da SQL no Oracle quando um usuário precisa executar uma SQL que não tenha logicamente um nome de tabela. Para obter a data de hoje, podemos usar: SELECT SYSDATE FROM dual;

O exemplo a seguir demonstra que até mesmo as instruções SQL mais simples podem ser vulneráveis. SELECT TRANSLATE ('user input’, 'from_string', 'to.string') FROM dual;

Aqui, TRANSLATE é usado para substituir uma cadeia de caracteres por outra cadeia de caracteres. A função TRANSLATE citada substituirá os caracteres de ‘from, string’ pelos caracteres de ‘to_string’ um por um. Isso significa que o/será substituído pelo í, o r, pelo o, o o, pelo e assim por diante. Este tipo de instrução SQL pode estar sujeito a um ataque de injeção de função. Considere o exemplo a seguir: SELECT TRANSLATE (“ || UTL_HTTRREQUEST ('httpY/129.107.2.1/') || ", '98765432', '9876') FROM dual;

O usuário pode inserir a string (‘ II UTL_HTTP. REQUEST (‘http://l 29.107.2.1/’) II ’), em que II é o operador de concatenação, solicitando assim uma página de um servidor web. A UTL_HTTP faz chamadas do Hypertext Transfer Protocol (Hl IP) com base na SQL. O objeto REQUEST recupera um URL (‘http^/129.107.2. If neste exemplo) como um parâmetro, entra em contato com esse site e retorna os dados (normalmente HTML) obtidos desse site. O atacante poderia manipular a string que ele insere, bem como o URL, para incluir outras funções e realizar outras operações ilegais, Apenas usamos um exemplo fictício para mostrar a conversão de ‘98765432’ para ‘9876’, mas a intenção do usuário seria acessar o URL e obter informações confidenciais. O atacante pode, então, recuperar informações úteis do servidor de banco de dados — localizado no URL que é passado como parâmetro — e enviá-las ao servidor web (que chama a função TRANSLATE).

30.4.2 Riscos associados à injeção de SQL A injeção de SQL é prejudicial e os riscos associados a ela oferecem motivação para os atacantes. Alguns dos riscos associados a ataques de injeção de SQL são explicados a seguir. ■ Impressão digital do banco de dados. O atacante pode determinar o tipo de banco de dados que está sendo usado no backend de modo que possa utilizar

Capitulo 30

Segurança de banco de dados

ataques específicos ao banco de dados que correspondem a pontos fracos em um SGBD em particular.

■ Negação de serviço. O atacante pode inundar o servidor com solicitações, negando assim o serviço a usuários legítimos, ou pode excluir alguns dados. ■ Contornar a autenticação. Este é um dos riscos mais comuns, em que o atacante pode obter acesso ao banco de dados como um usuário autorizado e realizar todas as tarefas desejadas. ■ Identificar parâmetros injetáveis. Neste tipo de ataque, o atacante reúne informa­ ções importantes sobre o tipo e a estrutura do banco de dados de backend de uma aplicação web. Esse ataque se toma possível pelo fato de a página de erro padrão retornada pelos servidores dc aplicação normalmcntc ser bastante descritiva. ■ Executar comandos remotos. Isso oferece aos atacantes uma ferramenta para executar comandos quaisquer no banco dc dados. Por exemplo, um usuário remoto pode executar procedimentos armazenados e funções do banco de dados a partir de uma interface interativa SQL remota. ■ Realizar escalada dc privilégios. Este tipo de ataque tira proveito das falhas lógicas dentro do banco de dados para aumentar o nível de acesso.

30.4.3 Técnicas de proteção contra injeção de SQL A proteção contra ataques de injeção de SQL pode ser obtida ao se aplicarem certas regras de programação a todos os procedimentos e funções acessíveis pela web. Esta seção descreve algumas dessas técnicas. Variáveis de ligação (usando comandos parametrizados). O uso de variáveis de ligação (também conhecidas como parâmetros^ ver Capítulo 10) protege contra ataques de injeção e também melhora o desempenho. Considere o seguinte exemplo usando Java e JDBC: PreparedStatement stmt = conn.prepareStatement( "SELECT ' FROM FUNCIONÁRIO WHERE FUNCIONARIO_ID=? AND SENHA=?“); stmt.sctString( 1, funcionario_id); stmt.setString(2, senha);

Em vez de embutir a entrada do usuário na instrução, ela deverá ser vinculada a um parâmetro. Neste exemplo, a entrada ‘1’ é atribuída (vinculada) à variável de ligação ‘funcionario_id’ e a entrada ‘2’, à variável de ligação "senha’, em vez de passar parâmetros de cadeia de caracteres diretamente. Filtragem da entrada (validação da entrada). Esta técnica pode ser usada para remover caracteres de escape das cadeias de caracteres de entrada ao utilizar a função Replace da SQL. Por exemplo, o delimitador dc aspa simples (‘) pode ser substituído por duas aspas simples (°). Alguns ataques de manipulação de SQL podem ser impe­ didos com essa técnica, pois os caracteres de escape podem ser usados para injetar ataques de manipulação. Porém, como pode haver um grande número de caracteres dc escape, esta técnica nâo é confiável. Segurança da função. As funções de banco de dados, tanto padrão quanto personalizadas, devem ser restringidas, pois podem ser exploradas nos ataques de injeção de função SQL.

30.5 Introdução à segurança do banco de dados estatístico Bancos de dados estatísticos são usados principalmente para produzir estatísticas sobre várias populações. O banco de dados pode conter dados confidenciais sobre

1037

1038

Sistemas de banco de dados

indivíduos, que devem ser protegidos contra acesso do usuário. Contudo, os usuá­ rios têm permissão para recuperar informações estatísticas sobre populações, como médias, somas, contadores, valores máximo e mínimo e desvios padrões. As técnicas desenvolvidas para proteger a privacidade de informações individuais estão além do escopo deste livro. Vamos ilustrar o problema com um exemplo muito simples, que se refere à relação mostrada na Figura 30.3. Essa é uma relação PESSOA com os atributos Nome, Cpf, Renda, Endereço, Cidade, Estado, Cep, Sexo e Escolaridade. Uma população é um conjunto de tuplas de uma relação (tabela) que satisfazem alguma condição de seleção. Logo, cada condição de seleção na relação PESSOA especificará uma população em particular de tuplas de PESSOA. Por exemplo, a con­ dição Sexo = ‘M’ especifica a população do sexo masculino; a condição ((Sexo = ‘F) AND (Escolaridade = OR Escolaridade = ‘Ph.D.')) especifica a população do sexo feminino que tem um título M.S. ou Ph.D. como seu título mais alto; e a condição Cidade = ‘Curitiba’ especifica a população que mora em Curitiba. z\s consultas estatísticas envolvem a aplicação de funções estatísticas a uma popu­ lação de tuplas. Por exemplo, podemos querer recuperar o número de indivíduos em uma população ou a renda média na população. No entanto, usuários estatísticos não têm permissão para recuperar dados individuais, como a renda de uma pessoa específica. Técnicas de segurança de banco de dados estatístico precisam proibir a recuperação de dados individuais. Isso pode ser obtido proibindo-se consultas que recuperam valores de atributo e permitindo apenas consultas que envolvem funções de agregação estatística, como COUNT, SUM, MIN, MAX, AVERAGE e STANDARD DEVIATION. Estas às vezes são chamadas de consultas estatísticas. E responsabilidade de um sistema de gerenciamento de banco de dados garantir a confidencialidade da informação sobre indivíduos, enquanto ainda oferece resumos estatísticos úteis dc dados sobre esses indivíduos aos usuários. A provisão da proteção da privacidade dos usuários em um banco de dados estatístico é fundamental; sua violação é ilustrada no exemplo a seguir. Em alguns casos, é possível deduzir os valores de tuplas individuais com base em uma sequência de consultas estatísticas. Isso é particularmente verdadeiro quando as condições resultam cm uma população que consiste em um pequeno número de tuplas. Como exemplo, considere as seguintes consultas estatísticas: Cl:

C2:

SELECT COUNT (*) FROM PESSOA WHERE ; SELECT AVG (Renda) FROM PESSOA WHERE ;

Agora suponha que estejamos interessados em descobrir o Salario de Jane Silva, e sabemos que ela tem um título de Ph.D. e mora na cidade de Curitiba, Paraná. Emitimos a consulta estatística C1 com a seguinte condição: (Escolaridade=‘Ph.D.’ AND Sexo=‘F AND Cidade=‘Curitiba’ AND Estado=‘Paraná’)

Se obtivermos um resultado de 1 para essa consulta, podemos emitir C2 com a mesma condição e descobrir o Salario de Jane Silva. Mesmo que o resultado de C1 na condição anterior não seja 1, mas seja um número pequeno — digamos, 2 ou 3 —•, podemos emitir consultas estatísticas usando as funções MAX, MIN e AVERAGE para identificar o possível intervalo de valores para o Salario de Jane Silva. A possibilidade de deduzir informações individuais de consultas estatísticas é reduzida se nenhuma consulta estatística for permitida sempre que o número de Figura 30.3 O esquema de

relação PESSOA para ilustrar a

PESSOA

segurança do banco de dados

Nome

estatístico.

Çpf

Renda

Endereço Cidade] Estado

Cep

Sexo | Escolaridade

Capitulo 30

Segurança de banco de dados

tuplas na população especificada pela condição de seleção estiver abaixo de algum limite. Outra técnica para proibir a recuperação de informações individuais é proibir sequências de consultas que se referem repetidamente à mesma população de tuplas. Também é possível introduzir pequenas imprecisões ou ruído nos resultados das consultas estatísticas de maneira deliberada, para tornar difícil deduzir informações individuais dos resultados. Outra técnica é o particionamento do banco de dados. O particionamento implica que os registros sejam armazenados em grupos de algum tamanho mínimo; as consultas podem se referir a qualquer grupo completo ou conjunto de grupos, mas nunca a subconjuntos de registros dentro de um grupo. O leitor interessado deve consultar a bibliografia ao final deste capítulo para uma discussão a respeito dessas técnicas.

30.6 Introdução ao controle de fluxo O controle de fluxo regula a distribuição ou o fluxo de informações entre objetos acessíveis. Um fluxo entre o objeto X e o objeto Y ocorre quando um programa lê valores de X c grava valores cm Y. Os controles de fluxo verificam que a informação contida em alguns objetos não flui explícita ou implicitamente para objetos menos protegidos. Assim, um usuário não pode obter indiretamente em Y o que ele ou ela não pode obter de maneira direta em X. O controle de fluxo ativo começou no início da década de 1970. A maioria dos controles de fluxo emprega algum conceito de classe de segurança; a transferência de informações de um emissor para um receptor só é permitida se a classe de segurança do receptor for pelo menos tào privilegiada quanto a do emissor. Alguns exemplos de um controle de fluxo incluem impedir que um programa de serviço vaze dados confidenciais de um cliente e bloquear a transmissão de dados militares secretos para um usuário confidencial desconhecido. Uma política de fluxo especifica os canais ao longo dos quais a informação tem permissão para se mover. A política de fluxo mais simples especifica apenas duas classes de informação — confidencial (C) e não confidencial (N) — e permite todos os fluxos, exceto os da classe C para a classe N. Essa política pode solucionar o problema de confinamento que surge quando um programa de serviço trata de dados como infor­ mações do cliente, alguns dos quais podendo ser confidenciais. Por exemplo, um serviço de cálculo de imposto de renda poderia ter permissão para reter o endereço do cliente e apresentar a conta dos serviços, mas não a receita ou as deduções de um cliente. Os mecanismos de controle de acesso são responsáveis por verificar as auto­ rizações dos usuários para acesso ao recurso: somente operações concedidas são executadas. Os controles de fluxo podem ser impostos por um mecanismo estendido de controle de acesso, que envolve atribuir uma classe de segurança (normalmente chamada de autorização) a cada programa cm execução. O programa tem permissão para ler determinado segmento de memória somente se sua classe de segurança for tão alta quanto a do segmento. Ele só tem permissão para gravar em um segmento se sua classe for pelo menos a mesma que a do segmento. Isso automaticamente garante que nenhuma informação transmitida pela pessoa pode passar de uma classe mais alta para uma mais baixa. Por exemplo, um programa militar com autorização secreta só pode ler de objetos públicos e confidenciais, e só pode gravar em objetos secretos ou altamente secretos. Dois tipos de fluxo podem ser distinguidos: fluxos explícitos, que ocorrem como uma consequência das instruções de atribuição, como Y:= fXxXn),e fluxos implíci­ tos, gerados por instruções condicionais, como: se f(Xmtí Xn) então Y:= f (X} Xm). Os mecanismos de controle de fluxo precisam verificar que apenas fluxos auto­ rizados, explícitos e implícitos, sejam executados. Um conjunto de regras precisa ser

1039

1040

Sistemas de banco de dados

satisfeito para garantir fluxos de informação seguros. As regras podem ser expressas com o uso de relações de fluxo entre as classes e atribuídas à informação, indicando os fluxos autorizados dentro de um sistema. (Um fluxo de informação de A para B ocorre quando a informação associada a A afeta o valor da informação associada a B. O fluxo resulta de operações que causam transferência de informações de um objeto para outro.) Essas relações podem definir, para uma classe, o conjunto de classes cm que a informação (confidencial nessa classe) pode fluii; ou podem indi­ car as relações específicas a serem verificadas entre duas classes para permitir que a informação flua de uma para a outra. Em geral, os mecanismos de controle de fluxo implementam os controles ao atribuir um rótulo a cada objeto e ao especificar a classe de segurança do objeto. Os rótulos são, então, utilizados para verificar as relações dc fluxo definidas no modelo.

30.6.1 Canais secretos Um canal secreto permite uma transferência de informação que viola a segurança ou a política. Especificamente, um canal secreto permite que informações passem de um nível de classificação mais alto para um mais baixo por meios impróprios. Os canais secretos podem ser classificados em duas categorias gerais: canais de temporização e armazenamento. O recurso diferenciador entre as duas é que em um canal de temporização a informação é transmitida pela temporização de eventos ou processos, enquanto os canais de armazenamento não exigem qualquer sincronismo temporal, visto que a informação é transmitida ao acessar informações do sistema ou o que, dc outra forma, é inacessível ao usuário. Em um exemplo simples de canal secreto, considere um sistema dc banco dc dados distribuído em que dois nós tenham níveis dc segurança do usuário secreto (S) e não classificado (U). Para que uma transação seja confirmada, os dois nós precisam concordar com isso. Eles só podem realizar operações mutuamente que são consistentes com a propriedade * , que afirma que, em qualquer transação, o nó S não pode gravar ou passar informações para o nó U. Contudo, se esses dois nós combinarem para estabelecer um canal secreto entre eles, uma transação envolvendo dados secretos poderá ser confirmada de maneira incondicional pelo nó U, mas o nó S pode fazer isso de alguma maneira previamente combinada, de modo que cerras informações possam ser passadas do nó S para o nó 17, violando a propriedade ’. Isso pode ser alcançado onde a transação é executada repetidamente, mas as ações tomadas pelo nó S de modo implícito transmitem informações ao nó U. Medidas como bloqueio, que discutimos nos capítulos 21 e 22, impedem a gravação simultâ­ nea das informações pelos usuários com diferentes níveis de segurança nos mesmos objetos, impedindo os canais secretos da categoria de armazenamento. Os sistemas operacionais e os bancos de dados distribuídos oferecem controle sobre a multiprogramação de operações, o que permite um compartilhamento de recursos sem a possibilidade de invasão de um programa ou processo na memória ou em outros recursos do sistema, impedindo assim os canais de temporização secretos. Em geral, os canais secretos não são um grande problema nas implementações de banco de dados robustas e bem implementadas. Contudo,certos esquemas que implicitamente transferem informações podem ser idealizados por usuários inteligentes. Alguns especialistas em segurança acreditam que uma forma de evitar os canais secretos é impedir que os programadores realmente renham acesso aos dados con­ fidenciais que um programa processará depois que tiver entrado em operação. Por exemplo, um programador de um banco não tem necessidade de acessar os nomes ou saldos nas contas dos clientes. Os programadores de empresas de corretagem não precisam saber quais ordens de compra e venda existem para os clientes. Durante o

Capitulo 30

Segurança de banco de dados

teste do programa, o acesso a uma forma de dados reais ou alguns dados de teste de exemplo pode ser justificável, mas nào depois de o programa ser aceito para uso regular.

30.7 Criptografia e infraestruturas de chave pública Os métodos de acesso anteriores e o controle de fluxo, apesar de serem medidas de controle fortes, podem não ser capazes de proteger os bancos de dados contra algumas ameaças. Suponha que comuniquemos dados, mas eles caiam nas mãos de um usuário ilegítimo. Nessa situação, ao usar a criptografia, podemos disfarçar a mensagem de modo que, mesmo que a transmissão seja desviada, a mensagem não será revelada. A criptografia c a conversão de dados para um formato, chamado texto cifrado, que não pode ser facilmente entendido por pessoas não autorizadas. Ela melhora a segurança e a privacidade quando os controles de acesso são evitados, pois, em casos de perda ou roubo, os dados criptografados não podem ser facilmente entendidos por pessoas não autorizadas. Com essa base, aderimos às seguintes definições-padrão:7

■ Texto cifrado: dados criptografados (codificados). ■ Texto limpo (ou texto claro): dados inteligíveis que têm significado e podem ser lidos ou atuados sem a aplicação da descriptografia. ■ Criptografia: o processo de transformar texto limpo em texto cifrado. ■ Descriptografia: o processo de transformar texto cifrado de volta para texto limpo.

A criptografia consiste em aplicar um algoritmo de criptografia aos dados usando alguma chave de criptografia pré-especificada. Os dados resultantes precisam ser descriptografados usando uma chave de descriptografia para recuperar os dados originais.

30.7.1 Os padrões Data Encryption e Advanced Encryption O Data Encryption Standard (DES) é um sistema desenvolvido pelo governo dos Estados Unidos para uso pelo público em geral. Ele foi bastante aceito como padrão criptográfico nos Estados Unidos e no exterior. O DES pode oferecer criptografia de ponta a ponta no canal entre o emissor A e o receptor B. O algoritmo DES é uma combinação cuidadosa e complexa dc dois blocos de montagem fundamentais da criptografia: substituição e permutação (transposição). O algoritmo deriva sua robustez da aplicação repetida dessas duas técnicas para um total de 16 ciclos. O texto limpo (a forma original da mensagem) é criptografado como blocos de 64 bits. Embora a chave tenha 64 bits de extensão, na verdade pode ser qualquer número de 56 bits. Após questionar a adequação do DES, o NIST introduziu o Advanced Encryption Standard (AES). Esse algoritmo tem um tamanho de bloco de 128 bits, comparado com o tamanho de 56 bits do DES, e pode usar chaves de 128,192 ou 256 bits, em comparação com a chave de 56 bits do DES. O AES introduz mais chaves possíveis, em comparação com o DES, e, assim, exige muito mais tempo para quebrar uma chave. Em sistemas atuais, AES é o default, com grandes tamanhos de chave. Ele também é o padrão para produtos de criptografia de unidade inteira, com Apple FileVault e Microsoft BitLocker usando chaves dc 256 ou 128 bits. TripleDES é uma opção de reserva se um sistema legado não puder usar um padrão de criptografia moderno.

Departamento de Comércio dos Estados Unidos.

1041

1042

Sistemas de banco de dados

30.7.2 Algoritmos de chave simétrica Uma chave simétrica é uma chave utilizada para criptografia e descriptografia. Ao usar uma chave simétrica, a criptografia e a descriptografia rápidas sào pos­ síveis para emprego rotineiro com dados confidenciais no banco de dados. Uma mensagem criptografada com uma chave secreta só pode ser descriptograíada com a mesma chave secreta. Os algoritmos usados para a criptografia de chave simétrica sào chamados algoritmos de chave secreta. Como tais algoritmos sào utilizados principalmente para criptografar o conteúdo de uma mensagem, eles também sào chamados dc algoritmos dc criptografia dc conteúdo. A principal desvantagem associada aos algoritmos dc chave secreta é a necessi­ dade dc compartilhar essa chave. Um método possível é derivar a chave secreta de uma cadeia de caracteres de senha fornecida pelo usuário ao aplicar a mesma função à cadeia de caracteres no emissor e no receptor; isso é conhecido como algoritmo de criptografia baseado em senha. A robustez da criptografia de chave simétrica depende do tamanho da chave utilizada. Para o mesmo algoritmo, a criptografia que utiliza uma chave mais longa é mais difícil de ser quebrada que a que usa uma chave mais curta.

30.7.3 Criptografia de chave pública (assimétrica) Em 1976, Diffie e Hellman propuseram um novo tipo de sistema criptográfico, que eles chamaram de criptografia dc chave pública. Os algoritmos de chave pública são baseados em funções matemáticas cm vez dc cm operações cm padrões dc bits. Eles resolvem um problema da criptografia de chave simétrica, a saber, que tanto o emissor quanto o destinatário precisam trocar a chave comum de uma maneira segura. Nos sistemas dc chave pública, duas chaves são utilizadas para criptografia/ descriptografia. A chave pública pode ser transmitida dc uma maneira não segura, enquanto a chave privada não é transmitida. Esses algoritmos — que usam duas chaves relacionadas, uma pública e uma privada, para realizar operações comple­ mentares (criptografia e descriptografia) — são conhecidos como algoritmos de criptografia de chave assimétrica. O emprego de duas chaves pode ter consequências profundas nas áreas de confidencialidade, distribuição de chave e autenticação. As duas chaves usadas para a criptografia de chave pública são conhecidas como chave pública e chave privada. A última é mantida em segredo, mas é referenciada como chave privada em vez de chave secreta (a chave usada na criptografia convencional) para evitar confusão com a criptografia convencional. As duas chaves sào matema­ ticamente relacionadas, pois uma delas serve para realizar a criptografia e a outra, para realizar a descriptografia. Contudo, é muito difícil derivar a chave privada com base na chave pública. Um esquema de criptografia (ou infraestrutura) de chave pública tem seis ingredientes: 1. Texto limpo. Trata-se dos dados ou mensagem legível que é alimentada no algo­ ritmo como entrada.

2. Algoritmo de criptografia. Este algoritmo realiza diversas transformações no texto limpo. 3. e 4. Chaves pública c privada. Trata-se dc um par dc chaves que foram selecio­ nadas dc modo que, se uma for usada para criptografia, a outra é utilizada para descriptografia. As transformações exatas realizadas pelo algoritmo de cripto­ grafia dependem da chave pública ou privada que é fornecida como entrada. Por exemplo, se uma mensagem é criptografada com a chave pública, ela só pode ser descriptografada com a chave privada.

Capitulo 30 Segurança de banco de dados 5. Texto cifrado. Esta é a mensagem misturada produzida como saída. Ela depende do texto limpo e da chave. Para determinada mensagem, duas chaves diferentes produzirão dois textos cifrados diferentes.

6. Algoritmo de descriptografia. Este algoritmo aceita o texto cifrado e a chave correspondente, e produz o texto limpo original. Como o nome sugere, a chave pública do par se torna pública para outros a usarem, enquanto a chave privada é conhecida apenas por seu proprietário. Um algoritmo criptográfico de chave pública para uso geral conta com uma chave para criptografia e uma chave diferente, porém relacionada, para descriptografia. As etapas essenciais são as seguintes: 1. Cada usuário gera um par de chaves a serem usadas para criptografar e descriptografar as mensagens.

2. Cada usuário coloca uma das duas chaves em um registrador público ou outro arquivo acessível. Essa é a chave pública. A chave correspondente é mantida privada. 3. Se um emissor deseja enviar uma mensagem privada a um receptor, o emissor criptografa a mensagem usando a chave pública do receptor. 4. Quando o receptor recebe a mensagem, ele ou ela a descriptografa com a chave privada do receptor. Nenhum outro destinatário pode descriptografar a mensagem porque somente o receptor conhece sua chave privada. 0 algoritmo de criptografia de chave pública RSA. Um dos primeiros esquemas de chave pública foi introduzido em 1978 por Ron Rivest, Adi Shamir e Len Adleman no NÍITS e recebeu o nome de esquema RSA, as iniciais de seus sobrenomes. Desde então, o esquema RSA tem sido afirmado como a técnica mais aceita e implementada para a criptografia de chave pública. O algoritmo de criptografia RSA incorpora resultados da teoria dos números, combinados com a dificuldade de determinar os fatores primos de um alvo. O algoritmo RSA também opera com a aritmética modular — mod n. Duas chaves, d e e, são usadas para criptografia e descriptografia. Uma pro­ priedade importante é que elas podem ser trocadas, w é escolhida como um inteiro grande, que é um produto de dois números primos distintos grandes, a c b,n = a x b. A chave de criptografia e é um número escolhido aleatoriamente entre lew que seja relativamente primo de (a — 1) x (b - 1). O bloco de texto limpo P é criptografado como P1’, em que P * = P mod w. Como a exponenciação é realizada como mod w, a fatoração de Pe para desvendar o texto limpo criptografado é difícil. Porém, a chave de descriptografia d é cuidadosamente escolhida de modo que (Pe) d mod w = P. A chave de descriptografia d pode ser calculada com base na condição de que d x e = 1 mod ((a - 1) x (b - 1)). Assim, o receptor legítimo que conhece d simplesmente calcula (Pe) d mod w = P e recupera P sem ter de fatorar Pe.

30.7.4 Assinaturas digitais Uma assinatura digital é um exemplo de uso de técnicas de criptografia para fornecer serviços de autenticação cm aplicações de comércio eletrônico. Assim como uma assinatura manual, uma assinatura digital é um meio de associar uma marca única a um indivíduo com um corpo de texto. A marca deve ser inesquecível, significando que outros devem poder verificar se a assinatura vem do remetente. Uma assinatura digital consiste cm uma string de símbolos. Se a assinatura digital de uma pessoa sempre fosse a mesma para cada mensagem, alguém poderia 8 Rivest et al. (1978).

1043

1044

Sistemas de banco de dados

facilmente falsificá-la apenas copiando a string de símbolos. Assim, as assinaturas devem ser diferentes para cada uso. Isso pode ser obtido tornando cada assinatura digital uma função da mensagem que ela está assinando, com um rótulo de tempo. Para ser única a cada assinante e à prova de falsificação, cada assinatura digital também precisa depender de algum número secreto que seja exclusivo ao assinante. Dessa forma, em geral, uma assinatura digital à prova de falsificação deve depender da mensagem c de um número secreto único do assinante. O verificador da assina­ tura, porém, não deve precisar saber qualquer número secreto. As técnicas dc chave pública são a melhor maneira de criar assinaturas digitais com essas propriedades.

30.7.5 Certificados digitais Um certificado digital é utilizado para combinar o valor de uma chave pública com a identidade da pessoa ou do serviço que mantém a chave privada corres­ pondente em uma declaração assinada digitalmente. Os certificados são emitidos e assinados por uma autoridade certificadora (CA — certification authority}. A entidade que recebe esse certificado de uma CA é o sujeito desse certificado. Em vez de exigir que cada participante em uma aplicação autentique cada usuário, uma autenticação de terceiros conta com o uso de certificados digitais. O próprio certificado digital contém vários tipos de informação. Por exemplo, estão incluídas informações tanto da autoridade certificadora quanto do proprietário do certificado. A lista a seguir descreve todas as informações incluídas no certificado: 1. A informação do proprietário do certificado, que é representado por um identi­ ficador único, conhecido como nome distinto (DN) do proprietário. Isso inclui o nome do proprietário, bem como sua organização e outras informações sobre ele.

2. O certificado também inclui a chave pública do proprietário. 3. A data de emissão do certificado também é incluída. 4. O período de validade é especificado por datas ‘Válido de' e ‘Válido até’, que estão incluídas em cada certificado. 5. A informação do identificador do emissor é incluída no certificado.

6. Finalmente, a assinatura digital da CA emissora para o certificado é incluída. Todas as informações listadas são codificadas por meio de uma função message-digest, que cria a assinatura digital. A assinatura digital basicamente certifica que a associação entre o proprietário do certificado e a chave pública é válida.

30.8 Questões de privacidade e preservação A preservação da privacidade dos dados é um desafio cada vez maior para os espe­ cialistas em segurança e privacidade do banco de dados. Em algumas perspectivas, para preservar a privacidade dos dados, devemos até mesmo limitar a realização da mineração e análise de dados em grande escala. Uma das técnicas mais comuns para resolver esse problema é evitar a criação de warehouses centrais imensos como um único repositório de informações vitais. Esse é um dos principais obstáculos para a criação de registros nacionais de pacientes para muitas doenças importantes. Outra medida possível é modificar ou perturbar dados intencionalmente. Se todos os dados estivessem disponíveis em um único warehouse, a violação da segurança dc um único repositório poderia expor todos os dados. Evitar warehou­ ses centrais e usar algoritmos de mineração de dados distribuídos minimiza a troca de dados necessária para desenvolver modelos globalmenre válidos. Ao modificar, atrapalhar e tornar os dados anônimos, também podemos aliviar os riscos de priva­ cidade associados à mineração dc dados. Isso pode scr feito ao remover informações

Capitulo 30

Segurança de banco de dados

de identidade dos dados liberados e injetar ruído aos dados. Porém, ao usar essas técnicas, devemos prestar atenção à qualidade dos dados resultantes no banco dc dados, que podem sofrer muitas modificações. Também devemos poder estimar os erros passíveis de serem introduzidos por essas modificações. A privacidade é uma área importante de pesquisa contínua no gerenciamento de banco de dados. Isso é complicado em razão de sua natureza multidisciplinar e suas questões relacionadas à subjetividade na interpretação da privacidade, confiança, c assim por diante. Como exemplo, considere registros e transações médicos c legais, que devem manter certos requisitos de privacidade. Oferecer controle de acesso e privacidade para dispositivos móveis também está recebendo cada vez mais aten­ ção. Os SGBDs precisam de técnicas robustas para o armazenamento eficiente de informações relevantes à segurança cm pequenos dispositivos, bem como técnicas de negociação de confiança. Onde manter informações relacionadas a identidades, perfis, credenciais e permissões e como usá-las para a identificação confiável do usuário ainda é um problema importante. Como fluxos de dados de grande tamanho são gerados em tais ambientes, é preciso elaborar técnicas eficientes para controle de acesso, integrando-as com técnicas de processamento para consultas contínuas. Por fim, é preciso que se garanta a privacidade dos dados dc localização do usuário, adquiridos de sensores e redes de comunicação.

30.9 Desafios da segurança do banco de dados Considerando o grande crescimento cm volume e velocidade das ameaças aos bancos de dados e informações, é preciso dedicar esforços de pesquisa às seguintes questões: qualidade dos dados, direitos de propriedade intelectual e sobrevivência do banco de dados, para citar apenas algumas. Vamos resumir o trabalho exigido em algumas áreas importantes que os pesquisadores em segurança de banco dc dados estão tentando resolver.

30.9.1 Qualidade dos dados A comunidade de banco de dados precisa de técnicas e soluções organizacionais para avaliar e atestar a qualidade dos dados. Essas técnicas podem incluir mecanis­ mos simples, como rótulos dc qualidade que são postados em sites web. Também precisamos dc técnicas que ofereçam verificação eficaz da semântica dc integridade e ferramentas para a avaliação da qualidade dos dados, com base em técnicas como a ligação de registros. Técnicas de recuperação em nível de aplicação também são necessárias para reparar automaticamente os dados incorretos. As ferramentas de ETL (extract, transform, load — extração, transformação, carga), bastante usadas para carregar dados em data warehouses (ver Seção 29.4), atualmente estão ata­ cando essas questões.

30.9.2 Direitos de propriedade intelectual Com o uso generalizado da internet e de intranets, aspectos legais e informati­ vos dos dados estão se tornando preocupações importantes das organizações. Para enfrentar esses problemas, têm sido propostas técnicas dc marca d’água para dados relacionais. A finalidade principal da marca d'água digital é proteger o conteúdo contra duplicação e distribuição não autorizadas, habilitando a propriedade prová­ vel do conteúdo. Isso tradicionalmente tem ficado por conta da disponibilidade de um grande domínio de ruído, dentro do qual o objeto pode ser alterado enquanto retém suas propriedades essenciais. Porém, é preciso que haja pesquisa para avaliar

1045

1046

Sistemas de banco de dados

a robustez dessas técnicas e investigar diferentes técnicas visando à prevenção de violações dos direitos de propriedade intelectual.

30.9.3 Sobrevivência do banco de dados Os sistemas de banco de dados precisam operar e continuar suas funções, mesmo com capacidades reduzidas, apesar de eventos destruidores, como ataques de busca de vantagem competitiva. Um SGBD, além de realizar todos os esforços para impedir um ataque e detectar um, caso ocorra, deve ser capaz de fazer o seguinte: ■ Confinamento. Tomar ação imediata para eliminar o acesso do atacante ao sis­ tema e isolar ou conter o problema para impedir que se espalhe mais. ■ Avaliação de danos. Determinar a extensão do problema, incluindo funções que falharam e dados adulterados. ■ Reconfiguração. Reconfigurar para permitir que a operação continue em um modo reduzido enquanto a recuperação prossegue. ■ Reparo. Recuperar dados adulterados ou perdidos e reparar ou reinstalar funções do sistema que falharam, para restabelecer um nível de operação normal. ■ Tratamento de falha. Ao máximo possível, identificar os pontos fracos explorados no ataque e tomar medidas para impedir uma nova ocorrência.

O objetivo do atacante em busca de vantagem competitiva é prejudicar a operação da organização e a realização de sua missão, por meio de danos a seus sistemas dc informação. O alvo específico de um ataque pode scr o próprio sistema ou seus dados. Embora os ataques que paralisam totalmente o sistema sejam graves e dramáticos, eles também devem ser bem temporizados para alcançar o objetivo do atacante, pois receberão atenção imediata e concentrada, a fim de retornar o sistema à condição operacional, diagnosticar como ocorreu o ataque e instalar medidas preventivas. Até o momento, questões relacionadas à sobrevivência do banco de dados ainda não foram suficientemente investigadas. E preciso que se dedique muito mais pesquisa às técnicas e metodologias que garantam a sobrevivência do sistema de banco de dados.

30.10 Segurança baseada em rótulo no Oracle Restringir o acesso a tabelas inteiras ou isolar dados confidenciais em bancos de dados separados é uma operação dispendiosa para administrar. A Oracle Label Security evita a necessidade dessas medidas ao habilitar o controle de acesso em nível de linha. No momento em que este livro foi escrito, ela estava disponível no Oracle Database llg Release 1 (11.1) Enterprise Edition. Cada tabela ou visão do banco de dados tem uma política dc segurança associada a ela. Essa política é executada toda vez que a tabela ou visão é consultada ou alterada. Os desenvolvedores podem prontamente acrescentar o controle de acesso baseado em rótulo às suas aplicações em Oracle Database. A segurança baseada em rótulo oferece uma forma adaptável de controlar o acesso a dados confidenciais.Tanto usuários quanto dados possuem rótulos associados a eles. A Oracle Label Security usa esses rótulos para oferecer segurança.

30.10.1 Tecnologia Virtual Private Database (VPD) Virtual Private Databases (VPDs) são um recurso do Oracle Enterprise Edition que acrescenta predicados aos comandos do usuário para limitar seu acesso de uma maneira transparente ao usuário e à aplicação. O conceito de VPD permite o controle de acesso imposto pelo servidor, detalhado, para uma aplicação segura.

Capitulo 30

Segurança de banco de dados

1047

O VPD oferece controle de acesso baseado em políticas. Essas políticas de VPD impõem controle de acesso em nível de objeto ou segurança em nível de linha. Isso fornece uma interface de programação de aplicação (API) que permite que as polí­ ticas de segurança sejam ligadas às tabelas ou visões do banco de dados. Ao utilizar PL/SQL, uma linguagem de programação hospedeira usada em aplicações Oracle, os desenvolvedores e administradores de segurança podem implementar políticas de segurança com a ajuda de procedimentos armazenados.9 As políticas VPD per­ mitem que os desenvolvedores removam os mecanismos de segurança de acesso das aplicações e os centralizem no Oracle Database. O VPD é habilitado ao associar-se uma “política” de segurança a uma tabela, visão ou sinônimo. Um administrador usa o pacote PL/SQL fornecido, SGBD_RLS, para vincular uma função da política a um objeto do banco de dados. Quando um objeto que tem uma política de segurança associada a ela é acessado, a função que implementa essa política é consultada. A função da política retorna um predicado (uma cláusula WHERE) que é então anexado ao comando SQL do usuário, modifi­ cando assim, de forma transparente e dinâmica, o acesso aos dados pelo usuário. A Oracle Label Security é uma técnica de imposição da segurança em nível de linha na forma de uma política de segurança.

30.10.2 Arquitetura Label Security A Oracle Label Security está embutida na tecnologia VPD entregue no Oracle Database 11.1 Enterprise Edition. A Figura 30.4 ilustra como os dados são acessa­ dos sob a Oracle Label Security, mostrando a sequência de verificações do DAC e da segurança de rótulo. A Figura 30.4 mostra a sequência de verificações do controle de acesso discri­ cionário (DAC) e da segurança de rótulo. A parte da esquerda da figura mostra um usuário de aplicação em uma sessão do Oracle Database 1 lg Release 1 (11.1) enviando uma requisição SQL. O SGBD Oracle verifica os privilégios do DAC do usuário, garantindo que ele ou ela tenha privilégios SELECT na tabela. Depois, Usuário do Orade

Figura 30.4 Arquitetura Oracle

Label Security.

Procedimentos armazenados (ou stored procedures} foram discutidos na Seção 7.2.2.

1048

Sistemas de banco de dados

ele verifica se a tabela tem uma política de Virtual Private Database (VPD) associada para determinar se ela está protegida ao usar a Oracle Label Security. Se estiver, a modificação SQL da política VPD (cláusula WHERE) é acrescentada à instrução SQL original para encontrar o conjunto de linhas acessíveis que o usuário pode ver. Depois, a Oracle Label Security verifica os rótulos em cada linha, para determinar o subconjunto de linhas às quais o usuário tem acesso (conforme explicaremos na próxima seção). Essa consulta modificada é proces­ sada, otimizada e executada.

30.10.3 Como rótulos de dados e rótulos de usuário trabalham juntos O rótulo de um usuário indica a informação de que ele tem permissão para aces­ sar. Ele também determina o tipo de acesso (leitura ou gravação) que o usuário tem sobre essa informação. O rótulo dc uma linha mostra a sensibilidade da informação que a linha contém, bem como a propriedade da informação. Quando uma tabela no banco de dados tem um acesso baseado em rótulo associado a ela, uma linha só pode ser acessada se o rótulo do usuário atender a certos critérios definidos nas definições da política. O acesso é concedido ou negado com base no resultado da comparação do rótulo de dados e do rótulo de sessão do usuário. Os compartimentos permitem uma classificação mais detalhada da sensibilidade dos dados rotulados. Todos os dados relacionados ao mesmo projeto podem ser rotulados com o mesmo compartimento. Os compartimentos são opcionais; um rótulo pode conter zero ou mais compartimentos. Os grupos são usados para identificar organizações como proprietárias dos dados com rótulos dc grupo correspondentes. Os grupos são hierárquicos; por exemplo, um grupo pode ser associado a um grupo pai. Se um usuário tiver um nível máximo de SECRETO, então ele potencialmente tem acesso a todos os dados com níveis SECRETO, CONFIDENCIAL e PUBLICO. Esse usuário não tem acesso a dados ALTAMENTE_SECRETO. A Figura 30.5 mostra como os rótulos de dados e de usuário trabalham juntos para oferecer controle de acesso na Oracle Label Security. Figura 30.5 Rótulos de dados

e rótulos de usuário no Oracle.

r | iI

Rótulo de usuário

Nível de acesso máximo

Rótulo de dados

Nível de acesso ■ mínimo exigido:

Todos os compartimentos aos quais o usuário tem acesso

Todos os compartimentos aos quais o usuário deve ter acesso

L

Rótulos de usuário AS i FIN:CO

S

íFIN:CO VEN

Legenda dos rótulos AS = Altamente Secreto S = Secreto C = Confidencial P = Público

FonteOracle (2007)

Linhas na tabela

Rótulos de dados

i QUIM, FIN:CO

Linha 1

s

Linha 2

AS :i FIN:CO VEN

-► Linha 3

P

► Linha 4

c

FIN

i FIN:CO VEN

Capitulo 30

Segurança de banco de dados

Como vemos na Figura 30.5, o Usuário 1 pode ter acesso às linhas 2, 3 e 4, pois seu nível máximo é AS (A)tamente_Secreto). Ele tem acesso ao compartimento FIN (Finanças), e seu acesso ao grupo CO (Centro_Oeste) hierarquicamente inclui o grupo CO_VEN (Vendas CO). Ele nào pode acessar a linha 1 porque nào tem o compartimento QUI.M (Química). É importante que um usuário tenha autorização

para todos os compartimentos no rótulo de dados de uma linha para poder acessá-la. Com base nesse exemplo, o usuário 2 pode acessar as linhas 3 e 4, e tem um nível máximo dc S, que c menor que o AS na linha 2. Portanto, embora o usuário 2 tenha acesso ao compartimento FIN, ele pode acessar apenas o grupo CO_VEN, e, dessa forma, não pode acessar a linha 1.

30.11 Resumo Neste capítulo, discutimos várias técnicas para impor a segurança do sistema de banco de dados. Seção 30.1 é uma introdução à segurança do banco de dados. Na Seção 30.1.1, apresentamos diferentes ameaças aos bancos de dados cm relação à perda dc integridade, disponibilidade c confidencialidade. Discutimos, na Seção 30.1.2, os tipos de medidas de controle para lidar com esses problemas: controle de acesso, controle de inferência, controle de fluxo e criptografia. No restante da Seção 30.1, abordamos diversas questões relacionadas à segurança, incluindo sensibilidade de dados e tipos de exposições, segurança versus precisão no resultado quando um usuário solicita informações, e o relacionamento entre segurança c privacidade das informações. A imposição da segurança lida com o controle do acesso ao sistema dc banco de dados como um todo e com o controle da autorização para acessar partes espe­ cíficas de um banco de dados. O primeiro normalmente é feito ao atribuir contas com senhas aos usuários. O segundo pode ser realizado com o uso dc um sistema dc concessão c revogação dc privilégios a contas individuais para acessar partes específicas do banco de dados. Essa técnica, apresentada na Seção 30.2, gcralmentc é conhecida como controle de acesso discricionário (DAC). /Ypresentamos alguns comandos SQL para conceder e revogar privilégios, e ilustramos seu uso com exem­ plos. Depois, na Seçào 30.3, oferecemos uma visão geral dos mecanismos de controle de acesso obrigatório (MAC) que impõem a segurança multinível. Estes exigem as classificações de usuários e valores de dados em classes de segurança e impõem as regras que proíbem o fluxo de informações dos níveis de segurança mais altos para os mais baixos. Foram apresentados alguns dos principais conceitos nos quais o modelo relacionai multinível se baseia, incluindo filtragem e poli-instanciação. O controle de acesso baseado em papéis (RBAC) foi introduzido na Seção 30.3.2, e atribui privilégios com base nos papéis que os usuários desempenham. Abordamos a noção de hierarquias de papéis, exclusão mútua de papéis e segurança baseada em linha e rótulo. Explicamos as principais idéias por trás da ameaça da injeção de SQL na Seção 30.4, os métodos nos quais ela pode ser induzida e os vários tipos de riscos associados a ela. Depois, demos uma ideia das diversas formas como a injeção de SQL pode ser impedida. Discutimos rapidamente na Seção 30.5 o problema de controle de acesso a ban­ cos de dados estatísticos para proteger a privacidade de informações individuais e, ao mesmo tempo, oferecer acesso estatístico a populações de registros. As questões relacionadas a controle de fluxo e os problemas associados a canais secretos foram discutidos em seguida, na Seção 30.6, bem como a criptografia e as infraestruturas baseadas em chave pública/privada na Seção 30.7. A ideia de algoritmos de chave simétrica e o uso do popular esquema de infraestrutura de chave pública (PKI)

1049

1050

Sistemas de banco de dados

baseada em chave assimétrica foram explicados na Seção 30.7.3. Também aborda­ mos, nas seções 30.7.4 e 30.7.5, os conceitos de assinaturas digitais e certificados digitais. Destacamos a importância de questões de privacidade na Seção 30.8, e sugerimos algumas técnicas de preservação da privacidade. Na Seção 30.9, discu­ timos uma série de desafios à segurança, incluindo qualidade de dados, direitos de propriedade intelectual e sobrevivência do banco de dados. Terminamos o capítulo na Seção 30.10, introduzindo a implementação de políticas de segurança ao usar uma combinação da segurança baseada em rótulo e os bancos de dados privados virtuais no Oracle llg.

PERGUNTAS DE REVISÃO -----------------------------------------------------------------------30.1.

30.2. 30.3. 30.4. 30.5. 30.6. 30.7. 30.8. 30.9.

30.10. 30.11. 30.12. 30.13. 30.14. 30.15. 30.16. 30.17. 30.18. 30.19. 30.20.

30.21. 30.22. 30.23.

Discuta o significado de cada um dos seguintes termos: autorização de banco de dados, controle de acesso, criptografia de dados, conta privilegiada (sis­ tema), auditoria de banco de dados, trilha de auditoria. Que conta é designada como proprietária de uma relação? Que privilégios o proprietário de uma relação possui? Como o mecanismo de visão é usado como um mecanismo de autorização? Discuta os tipos de privilégios no nível de conta e aqueles no nível de relação. O que significa a concessão de um privilégio? O que significa a revogação de um privilégio? Discuta o sistema de propagação de privilégios e as restrições impostas pelos limites de propagação horizontais e verticais. Liste os tipos de privilégios disponíveis em SQL. Qual é a diferença entre controle de acesso discricionário (DAC) e obrigatório (MAC)? Quais são as classificações de segurança típicas? Discuta a propriedade de segurança simples e a propriedade * , e explique a justificativa por trás dessas regras para impor a segurança multinível. Descreva o modelo de dados relacionai multinível. Defina os seguintes termos: chave aparente, poli-instanciaçào, filtragem. Quais são os méritos relativos do uso do DAC ou do MAC? O que é controle de acesso baseado em papel? De que maneiras ele é superior ao DAC e ao MAC? Quais são os dois tipos de exclusão mútua no controle de acesso baseado em papel? O que significa controle de acesso em nível de linha? O que é a segurança de rótulo? Como um administrador a impõe? Quais são os diferentes tipos de ataques de injeção de SQL? Que riscos estão associados aos ataques de injeção de SQL? Que medidas preventivas são possíveis contra os ataques de injeção de SQL? O que é um banco de dados estatístico? Discuta o problema da segurança do banco de dados estatístico. Como a privacidade está relacionada à segurança do banco de dados esta­ tístico? Que medidas podem ser tomadas para garantir algum grau de pri­ vacidade nos bancos de dados estatísticos? O que é controle de fluxo como uma medida de segurança? Que tipos de controle de fluxo existem? O que são canais secretos? Dê um exemplo de canal secreto. Qual é o objetivo da criptografia? Que processo está envolvido na criptografia de dados e sua recuperação na outra ponta?

Capitulo 30

Segurança de banco de dados

Dê um exemplo de algoritmo de criptografia e explique como ele funciona. Repita a pergunta anterior para o algoritmo popular RSA. O que é algoritmo de chave simétrica para a segurança baseada em chave? O que é esquema de infraestrutura de chave pública? Como ele oferece segurança? 30.28. O que são assinaturas digitais? Como elas funcionam? 30.29. Que tipo de informação um certificado digital inclui?

30.24. 30.25. 30.26. 30.27.

EXERCÍCIOS----------------------------------------------------------------------------------------------30.30. Como a privacidade dos dados pode ser preservada cm um banco de dados? 30.31. Cite alguns dos maiores desafios atuais para a segurança do banco de dados. 30.32. Considere o esquema de banco de dados relacionai da Figura 5.5. Suponha que todas as relações tenham sido criadas pelo (e, portanto, pertencem ao) usuário X, que deseja conceder os seguintes privilégios às contas de usuário A, B, C, D e E: a. A conta A pode recuperar ou modificar qualquer relação, exceto DEPENDENTE, e pode conceder qualquer um desses privilégios a outros usuários. b. A conta B pode recuperar todos os atributos de FUNCIONÁRIO e DEPARTAMENTO, exceto Salario, Cpf.gerente e Data_inicio_gerente. c. A conta C pode recuperar ou modificar TRABALHA_EM, mas só pode recuperar os atributos Primeiro_nome, Nome_meio, Ultimo_nome e Cpf de FUNCIONÁRIO e os atributos Nome_projeto e Numero_projeto de PROJETO. d. conta D pode recuperar qualquer atributo de FUNCIONÁRIO ou DEPENDENTE e pode modificar DEPENDENTE. e. A conta E pode recuperar qualquer atributo de FUNCIONÁRIO, mas somente para tuplas de FUNCIONÁRIO que têm Numero_departamento = 3. f. Escreva instruções SQL para conceder esses privilégios. Use visões onde for apropriado. 30.33. Suponha que o privilégio (a) do Exercício 30.32 deva ser dado com GRANT OPTION, mas somente para que a conta A possa concedê-lo a no máximo cinco contas, e cada uma dessas contas possa propagar o privilégio a outras contas, mas sem o privilégio GRANT OPTION. Quais seriam os limites de propagação horizontal e vertical neste caso? 30.34. Considere a relação mostrada na Figura 30.2(d). Como ela apareceria para um usuário com classificação U? Suponha que um usuário com classificação U tente atualizar o salário de‘Silva’ para RS50.000; qual seria o resultado dessa ação?

BIBLIOGRAFIA SELECIONADA------------------------------------------------------------------

A autorização baseada na concessão e revogação de privilégios foi proposta para o SGBD experimental SYSTEM R e é apresentada em Griffiths e Wadc (1976). Vários livros discutem a segurança nos bancos de dados e sistemas de computação em geral, incluindo os livros de Leiss (1982a), Fernandez et al. (1981) e Fugini et al. (1995). Natan (2005) é um livro prático sobre questões de segurança e auditoria em todos os principais SGBDRs.

1051

1052

Sistemas de banco de dados

Muitos artigos discutem as diferentes técnicas para o projeto e proteção de bancos de dados estatísticos. Entre eles estão McLeish (1989), Chin e Ozsoyoglu (1981), Leiss (1982), Wong (1984) e Denning (1980). Ghosh (1984) discute o uso de bancos de dados estatísticos para o controle da qualidade. Também há muitos artigos que discutem a criptografia e a criptografia de dados, incluindo Diffie e Hellman (1979), Rivest et al. (1978), Akl (1983), Pfleeger e Pfleeger (2007), Omura ct al. (1990), Stallings (2000) e Iyer et al. (2004). Halfond et al. (2006) ajudam a entender os conceitos de ataques de injeção de SQL e as várias ameaças impostas por eles. O documento oficial Oracle (2007a) explica como o Oracle é menos passível a um ataque de injeção de SQL em compa­ ração com o SQL Server. Ele também oferece uma rápida explicação de como esses ataques podem ser impedidos. Outras estruturas propostas são discutidas em Boyd e Keromytis (2004), Halfond e Orso (2005) e McClure e Krüger (2005). segurança multinível é discutida em Jajodia e Sandhu (1991), Denning et al. (1987), Smith e Winslett (1992), Stachour e Thuraisingham (1990), Lunt et al. (1990) e Bertino et al. (2001). Visões gerais de questões de pesquisa em segurança de banco de dados são dadas por Lunt e Fernandez (1990), Jajodia e Sandhu (1991), Bertino (1998), Castano ct al. (1995) e Thuraisingham ct al. (2001). Os efeitos da segurança multinível no controle de concorrência são discutidos em Atluri et al. (1997). A segu­ rança nos bancos de dados da próxima geração, semânticos e orientados a objeto, é discutida cm Rabbiti et al. (1991), Jajodia e Kogan (1990) e Smith (1990). Oh (1999) apresenta um modelo para a segurança com controle de acesso discricionário e obrigatório. Os modelos de segurança para aplicações baseadas na web e o controle de acesso baseado em papel são discutidos em Joshi et al. (2001). As questões de segurança para gerentes no contexto das aplicações de e-commerce e a necessidade de modelos de avaliação de risco para a seleção de medidas apropriadas de controle de segurança são discutidas em Farahmand et al. (2005). O controle de acesso em nível de linha é explicado com detalhes em Oracle (2007b) e Sybase (2005). O último também oferece detalhes sobre hierarquia dc papel e exclusão mútua. Oracle (2009) explica como o Oracle usa o conceito de gerenciamento de identidade. Avanços recentes, bem como desafios futuros para a segurança e privacidade de bancos de dados, são discutidos em Bertino e Sandhu (2005). U.S. Govt. (1978), OECD (1980) c NRC (2003) são boas referencias sobre a visão da privacidade por importantes agencias do governo. Karat ct al. (2009) discutem uma estrutura política para segurança e privacidade. XML e controle de acesso são discutidos em Naedele (2003). Mais detalhes sobre as técnicas de preservação da privacidade podem ser encontrados em Vaidya e Clifton (2004), direitos de propriedade intelectual em Sion et al. (2004) e sobrevivência de banco de dados em Jajodia et al. (1999). A tecnologia de VPD e a segurança baseada em rótulo do Oracle são discutidas com mais detalhes em Oracle (2007b). Agrawal et al. (2002) definiram o conceito de bancos de dados hipocráticos para a preservação da privacidade nas informações da área de saúde. K-anonimato como uma técnica de preservação da privacidade é discutido em Bayardo e Agrawal (2005) e em Ciriani et al. (2007). Técnicas dc mineração dc dados para a preservação dc privacidade com base em k-anonimato são analisadas por Ciriani ct al. (2008). Vimercati et al. (2014) discutem a criptografia e a fragmentação como técnicas de proteção em potencial para a confidencialidade de dados na nuvem.

Apêndice A Notações diagramáticas alternativas para modelos ER Figura A.l mostra uma série de notações diagramáticas diferentes para repre­ sentar conceitos de modelo ER e EER. Infelizmente, não existe uma notação-padrão: diferentes profissionais de projeto de banco de dados preferem notações distintas. De modo semelhante, diversas ferramentas CASE (computer-aided software engineering — engenharia de software auxiliada por computador) e meto­ dologias de OOA (object-oriented analysis — análise orientada a objeto) utilizam várias notações. Algumas notações são associadas a modelos que possuem conceitos e restrições adicionais, além daqueles dos modelos ER e EER descritos nos capítulos 3,4 e 9, enquanto outros modelos têm menos conceitos e restrições. A notação que usamos no Capítulo 3 é muito próxima da notação original para diagramas ER, que ainda é bastante utilizada. Discutimos aqui algumas notações alternativas. A Figura A. 1 (a) mostra diferentes notações para exibir tipos/classes de entidade, atributos e relacionamentos. Nos capítulos 3, 4 e 9, usamos os símbolos marcados com (i) na Figura A. 1(a) — a saber, retângulo, oval e losango. Observe que o símbolo (ii) para tipos/classes de entidade, o símbolo (ii) para atributos e o símbolo (ii) para relacionamentos são semelhantes, mas usados por diferentes metodologias para representar três conceitos distintos. O símbolo de linha reta (iii) para representar relacionamentos é utilizado por várias ferramentas e metodologias. A Figura A.l(b) mostra algumas notações para conectar atributos a tipos de entidade. Usamos a notação (i). A notação (ii) utiliza a terceira notação (iii) para atributos da Figura A.l(a). As duas últimas notações na Figura A.l(b) — (iii) e (iv) — são populares em metodologias OOA e em algumas ferramentas CASE. Em par­ ticular; a última notação mostra os atributos e os métodos de uma classe, separados por uma linha horizontal. A Figura A.l (c) mostra várias notações para representar a razão de cardinalidade dos relacionamentos binários. Usamos a notação (i) nos capítulos 3,4 e 9. A notação (ii) — conhecida como notação pé de galinha — é muito popular. A notação (iv)

A

1054

(a)

Sistemas de banco de dados

Símbolos de tipo/dasse de entidade Símbolos de atributo

(iii) ------------ O A

Símbolos de relacionamento

(iii) —5------

(b)

(c)

(e)

Figura A.1 Notações alternativas, (a) Símbolos para tipo/dasse, atributo e relacionamento de entidade, (b) Exibindo atributos, (c) Exibindo razões de cardinalidade. (d) Diversas notações (min, max), (e) Notações para exibir

especialização/generalização.

utiliza a seta como uma referência funcional (do N para o lado 1) e é semelhante à nossa notação para chaves estrangeiras no modelo relacionai (ver Figura 9.2); a notação (v) — usada nos diagramas de Bachman e no modelo de dados de rede — usa a seta na direçào inversa (do 1 para o lado N). Para um relacionamento 1:1, (ii) utiliza uma linha reta sem qualquer pé dc galinha; (iii) torna as duas metades do losango brancas; e (iv) coloca pontas de seta nos dois lados. Para um relacionamento M:N, (ii) usa pés de galinha nas duas pontas da linha; (iii) torna as duas metades do losango escuras; e (iv) não exibe qualquer ponta de seta. A Figura A.1(d) traz diversas variações para exibição (min, max) de restrições, utilizadas para mostrar a razão de cardinalidade e a participação total/parcial.

Apêndice A

Notações diagramáticas alternativas para modelos ER

Usamos principalmente a notação (i). A notação (ii) é a notação alternativa que empregamos na Figura 3.15 e discutimos na Seção 3.7.4. Lembre-se de que nossa notação especifica a restrição de que cada entidade precisa participar em pelo menos min e no máximo max instâncias de relacionamento. Logo, para um relacionamento 1:1, os dois valores max são 1; para M:N, os dois valores max são n. Um valor min maior que 0 (zero) especifica participação total (dependência de existência). Em metodologias que utilizam a linha reta para exibir relacionamentos, é comum inverter o posicionamento das restrições (min, max), como mostramos em (iii); uma variação comum em algumas ferramentas (e na notação UML) aparece em (v). Outra técnica popular — que segue o mesmo posicionamento de (iii) — é exibir o min como o (a letra ou um círculo, que representa zero) ou como I (barra vertical, que representa 1), e exibir o max como I (barra vertical, que representa 1) ou como pés de galinha (que representam n), como mostramos em (iv). A Figura A. 1(e) mostra algumas notações para exibir especialização/generalização. Usamos a notação (i) no Capítulo 4, em que um d no círculo especifica que as subclasses (S1, S2 e S3) são disjuntas e um o no círculo especifica subclasses sobrepostas. A notação (ii) usa G (de generalização) para especificar disjunção, e Gs para especificar sobreposição; algumas notações utilizam a seta sólida, enquanto outras usam a seta vazia (mostrada na figura). A notação (iii) utiliza um triângulo que aponta para a superclasse, e a notação (v), um triângulo que aponta para as subclasses; também é possível usar as duas notações na mesma metodologia, com (iii) indicando generalização e (v) indicando especialização. A notação (iv) coloca as caixas que representam subclasses dentro da caixa que representa a superclasse. Das notações baseadas em (vi), algumas usam uma seta de única linha, enquanto outras utilizam uma seta de linha dupla (mostrada na Figura A. 1(e)]. As notações mostradas na Figura A.l trazem apenas alguns dos símbolos diagramáticos que têm sido usados ou sugeridos para exibir esquemas conceituais de banco de dados. Outras notações, bem como diversas combinações das anteriores, também têm sido empregadas. Seria útil estabelecer um padrão a que todos pudessem aderir, a fim de evitar mal-entendidos e reduzir a confusão.

1055

parâmetro de disco mais importante é o tempo exigido para localizar um bloco de disco qualquer, dado seu endereço, e depois transferir o bloco entre o disco e o buffer da memória principal. Esse é o tempo de acesso aleatório para acessar um bloco dc disco. Existem três componentes dc tempo a considerar:

O

1. Tempo de busca (s). E o tempo necessário para posicionar mecanicamente a cabeça de leitura/gravaçâo na trilha correta para os discos de cabeça móvel. (Para os discos de cabeça fixa, é o tempo necessário para alternar eletronicamente para a cabeça de leitura/gravaçâo apropriada.) Para discos de cabeça móvel, esse tempo varia, dependendo da distância entre a trilha atual sob a cabeça c a trilha especificada no endereço do bloco. Em geral, o fabricante do disco oferece um tempo de busca médio em milissegundos. A faixa típica do tempo de busca médio é de 4 a 10 ms. Esse é o principal culpado pelo atraso envolvido na transferência de blocos entre o disco e a memória.

2. Atraso de rotação (ar). Quando a cabeça de leitura/gravaçâo está na trilha cor­ reta, o usuário precisa esperar que o início do bloco solicitado gire até a posição sob a cabeça de leitura/gravaçâo. Na média, isso leva cerca de meia rotação do disco, mas na realidade varia do acesso imediato (se o início do bloco solicitado estiver na posição sob a cabeça de leitura/gravaçâo logo após a busca) até uma rotação de disco inteira (se o início do bloco solicitado tiver acabado de passar pela cabeça de leitura/gravaçâo após a busca). Se a velocidade da rotação do disco for p rotações por minuto (rpm), o atraso dc rotação médio ar é dado por ar = (1/2) x (1/p) min = (60 x 1.000)/(2 x p) ms = 30.000/p ms

Um valor típico para p é 10.000 rpm, que gera um arraso de rotação de ar = 3 ms. Para discos de cabeça fixa, nos quais o tempo de busca é desprezível, esse componente causa o maior atraso na transferência de um bloco dc disco.

1058

Sistemas de banco de dados

3. Tempo de transferência de bloco {ttb). Quando a cabeça de leitura/gravação estiver no início do bloco solicitado, algum tempo é necessário para transferir os dados no bloco. Esse tempo de transferência do bloco depende do tamanho do bloco, do tamanho da trilha e da velocidade de rotação. Se a taxa de transferência para o disco for tt bytes/ms e o tamanho do bloco for B bytes, então ttb = B/tt ms

Se tivermos um tamanho de trilha de 50 Kbytes e p for 3.600 rpm, então a taxa de transferência em bytes/ms é tt = (50 x 1.000)/(60 * 1.000/3.600) = 3.000 bytes/ms Neste caso, ttb = B/3.000 ms, em que B é o tamanho do bloco em bytes.

O tempo médio (s) necessário para encontrar e transferir um bloco, dado seu endereço de bloco, é estimado por (s + ar + ttb} ms

Isso se mantém para a leitura ou a gravação de um bloco. O método principal para reduzir esse tempo é transferir vários blocos que estão armazenados em uma ou mais trilhas do mesmo cilindro; depois, o tempo de busca é exigido apenas para o primeiro bloco. Para transferir consecutivamente & blocos não contíguos que estão no mesmo cilindro, precisamos de aproximadamente s + {k x {ar + ttb}} ms

Nesse caso, precisamos de dois ou mais buffers no armazenamento principal, pois estamos conrinuamente lendo ou gravando os k blocos, conforme discutimos no Capítulo 17. O tempo de transferência por bloco é reduzido ainda mais quando blocos consecutivos na mesma trilha ou cilindro são transferidos. Isso elimina o atraso rotacional para todos menos o primeiro bloco, dc modo que a estimativa da transferência dc k blocos consecutivos é $ + ar + {k x ttb) ms Uma estimativa mais precisa para transferir blocos consecutivos leva cm conta a lacuna entre blocos (ver Seção 16.2.1), que inclui a informação que permite que a cabeça de leitura/gravação determine qual bloco está para ser lido. Normalmente, o fabricante de disco oferece uma taxa de transferência bruta {ttbr} que leva em conta o tamanho da lacuna ao ler blocos armazenados consecutiva mente. Sc o tamanho da lacuna for dc G bytes, então

ttbr = (B/(B + O) x tt bytes/ms

A taxa de transferência bruta é a taxa da transferência de bytes úteis nos blocos de dados. A cabeça dc leitura/gravação do disco precisa passar por todos os bytes em uma trilha enquanto o disco gira, incluindo os bytes nas lacunas entre blocos, que armazenam informações de controle, mas não dados reais. Quando a taxa de transferência bruta é usada, o tempo necessário para transferir os dados úteis em um bloco para fora dos vários blocos consecutivos é B/ttbr. Logo, o tempo estimado para ler k blocos armazenados consecutiva mente no mesmo cilindro toma-se s + tfr + (À x {B/ttbr}) ms

Outro parâmetro dos discos é o tempo dc regravação. Este é útil nos casos em que lemos um bloco do disco para o buffer da memória principal, atualizamos o buffer e depois gravamos o buffer de volta no mesmo bloco de disco em que ele estava armazenado. Em muitos casos, o tempo exigido para atualizar o buffer na

Apêndice B

Parâmetros de discos

memória principal é menor que o tempo exigido para uma rotação do disco. Se soubermos que o buffer está pronto para regravaçào, o sistema pode manter as cabeças do disco na mesma trilha e, durante a rotação seguinte do disco, o buffer atualizado é regravado de volta para o bloco do disco. Logo, o tempo de regravaçào Tr normalmente é estimado como o tempo necessário para uma rotação do disco:

Tr = 2 xarms = 60.000/p ms Resumindo, a lista a seguir mostra os parâmetros que discutimos e os símbolos que usamos para eles: Tempo de busca: s ms Atraso de rotação: ar ms ttb ms Tempo de transferência de bloco: Tempo de regravaçào: Tr ms Tempo de transferência: tt bytes/ms Taxa de transferência bruta: ttbr bytes/ms Tamanho do bloco: B bytes Tamanho da lacuna entre blocos: G bytes • Velocidade do disco: p rpm (rotações por minuto)

1059

Apêndice

C

Visão geral da linguagem QBE linguagem Query-By-Example (QBE) é importante porque é uma das pri­ meiras linguagens de consulta gráficas com sintaxe mínima desenvolvida para sistemas de banco de dados. Ela foi desenvolvida na IBM Research e está disponível como um produto comercial IBM como parte da opção de interface QMF (Query Management Facility) para DB2. A linguagem também foi implemen­ tada no SGBD Paradox e está relacionada a uma interface tipo apontar e clicar no SGBD Microsoft Access. Ela difere da SQL porque o usuário não precisa especificar explicitamente uma consulta usando uma sintaxe fixa. Em vez disso, a consulta é formulada ao preencher modelos dc relações que sâo exibidos na tela. A Figura C.l mostra como podem ser esses modelos para o banco de dados da Figura 5.5. O usuário não precisa se lembrar dos nomes dos atributos ou das relações, pois eles são exibidos como parte desses modelos. Além disso, o usuário não precisa seguir regras de sintaxe rígidas para especificação de consulta; em lugar disso, constantes e variáveis são inseridas nas colunas dos modelos para construir um exemplo rela­ cionado à solicitação de recuperação ou atualização. A QBE está relacionada ao cálculo relacionai do domínio, conforme veremos, c sua especificação original tem sido mostrada como completa do ponto de vista relacionai.

A

C.1 Recuperações básicas em QBE Em QBE, as consultas dc recuperação são especificadas ao preencher uma ou mais linhas nos modelos das tabelas. Para uma consulta de única relação, inserimos constantes ou elementos de exemplo (um termo da QBE) nas colunas do modelo dessa relação. Um elemento de exemplo representa uma variável de domínio e é especificado como um valor de exemplo precedido pelo caractere dc sublinhado (_). Além disso, um prefixo R (chamado operador P ponto) é inserido em certas colunas para indicar que gostaríamos

Sistemas de banco de dados

1062

FUNCIONÁRIO Nome meio Ultimo nome

Primeiro.nome

Cpf

Data.nascimento Endereço Sexo Salario

Cpf.supervisor Numero.departamento

DEPARTAMENTO Nome departamento Numero departamento Cpf gerente Data inicio gerente

LOCAUZACOES_DEPARTAMENTO Numero_departamento Local

I

I

PROJETO Nome projeto

Numero_projeto

I

I

Local projeto Numero departamento

TRABALHA EM Cpf funcionário

Numero_projeto

Horas

DEPENDENTE Cpf funcionário

Nome dependente

Sexo Data nascimento Parentesco

Figura C.1 O esquema relacionai da Figura 5.5 conforme exibido pela QBE.

de imprimir (ou exibir) valores nessas colunas para o resultado. As constantes especificam valores que devem ser combinados dc maneira exata nessas colunas. Por exemplo, considere a consulta CO: recuperar a data de nascimento e o ende­ reço de João B. Silva. Nas figuras C.2(a) a C.2(d), mostramos como essa consulta pode ser especificada em uma forma progressivamente mais concisa em QBE. Na Figura C.2(a), um exemplo de funcionário é apresentado como o ripo de linha em que estamos interessados. Ao deixar Joào B. Silva como constantes nas colunas Primei ro.nome, Nome.meio e Ultimo_nome, estamos especificando uma combina­ ção exata nessas colunas. O restante das colunas é precedido por um sublinhado indicando que elas são variáveis dc domínio (elementos de exemplo). O prefixo P. c colocado nas colunas Data_nascimento e Endereço para indicar que gostaríamos de recuperar o(s) valor(es) conrido(s) nessas colunas.

(a) FUNCIONÁRIO

Primeiro,nome

João

Nome.meio

B.

Ultimo.nome

Silva

Cpf J2345678966

Endereço

Data.nascimento

P..9/1/60

Salario

Cpf.supervisor

.25000

.12345678966

Sexo

Salario

Cpf.supervisor

Numero.depa'tamento

Sexo

Salario

Cpf.supervisor

Numero.depa'tamento

Sexo

Salario

Cpf.supervisor

Numero.depa'tamento

Sexo

P._ Rua das Flores, 751.

Numero.depa'tamento

-3

São Paulo. SP

(b) FUNCIONÁRIO Primeiro,nome

João

Nome.meio

B.

Ultimo.nome

Cpf

Silva

Endereço

Data.nascimento

P..9/1/60

P._ Rua das Flores, 751, São Paulo, SP

(c) FUNCIONÁRIO

Primeiro,nome

João

Nome.meio

B.

Ultimo.nome

Cpf

Silva

Data nascimento

P..X

Endereço

P..Y

(d) FUNCIONÁRIO Primeiro.nome

João

Nome meic

B.

Ultimo.nome

Silva

Cpf

Data.nascimento

P.

Figura C.2 Quatro maneiras de especificar a consulta CO em QBE.

Endereço

P.

Apêndice C

Visão geral da linguagem QBE

1063

CO pode ser abreviada como mostra a Figura C.2(b). Não é preciso especificar valores de exemplo para colunas em que nào estamos interessados. Além disso, como valores de exemplo sào completamente arbitrários, podemos simplesmente especi­ ficar nomes de variável para eles, como mostra a Figura C.2(c). Por fim, também podemos omitir os valores de exemplo inteiramente, como mostra a Figura C.2(d), e apenas especificar um R sob as colunas a serem recuperadas. Para ver como as consultas dc recuperação cm QBE são semelhantes ao cálculo relacionai do domínio, compare a Figura C.2(d) com CO (simplificada) no cálculo dc domínio da seguinte forma:

CO : ( uv I FUNCIONARIO(qrstuvwxyz) and