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

Citation preview

SISTEMAS DE BANCO DE DADOS

ELMASRI • NAVATHE

'P Pearson

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

SISTEMAS DE BANCO DE DADOS 7s 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

e 2016. 20] 1.2007 In Ramez Elmasri and Shamkant B. Navalhe

£2019 by Pcjbími Education do Brasil lida. Iodos os direitos rescnados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer iimxJooci por qualquer outro meio, eletrônico ou mecânico. íik IiiíikIo fbtocõpra. gravação ou qualquer outro tipo de sistema de armazenamento e transmissão de informação, sem présii .mtorizaçáo por escrito da Pearson Education do Brasil

VlCE-PRESlDE.X'TE DL EDUCAÇÃO

Juliano Costa

GlREME DL PROD11OS Alexandre Mattioli SuPERMSOfLA DE PRODUÇÃO EDITORIAL

COORDENADOR DE PRODUÇÃO EDITORIAL

Editora de texto E1MIOR.AS ASSISTEX I ES EsiAGlÁRK)

Preparação

Revisão Capa DlACRAMAÇÃO E PROJETO CRÃFICO

Silvana Afonso Jean Xavier Sabrina Levensteinas

Karina Ono e Mariana Rodrigues Rodrigo Orsi

Rcnala Siqueira Campos

Maria Aiko Natália Gaio «sobre o projeto original de Micha Pawlitzki/lcna.Corbis)

Casa de Idéias

Dados Internacionais de Catalogação na Publicação (CIP)

(Câmara Brasileira do Livro. SP. Brasil) Elmasri. Ramez S ste~as de oanco de dados • Ramez Elmasri. Snamleant B Navatne; tradução Daniel Vieira; revisão técn

Figura 3.8 Projeto preliminar de tipos

de entidade para o banco de dados

EMPRESA. Alguns dos

atributos mostrados serão refinados nos

relacionamentos.

66

Sistemas de banco de dados

2. Um tipo de entidade PROJETO com atributos Nome, Numero, Localizacao e Departamento_gerenciador. Tanto Nome quanto Numero são atributos-chave (separados).

3. Um tipo de entidade FUNCIONÁRIO com atributos Nome, Cpf, Sexo, Endereço, Salario, Data_nascimento, Departamento e Supervisor. Tanto Nome quanto Endereço podem ser atributos compostos; no entanto, isso não foi especificado nos requisi­ tos. Temos de voltar aos usuários para ver se algum deles irá se referir aos com­ ponentes individuais de Nome — Primeiro.nome, Nome.meio, Ultimo_nome — ou de Endereço. Em nosso exemplo. Nome é modelado como um atributo composto, enquanto Endereço não, talvez depois de uma consulta com os usuários. 4. Um tipo de entidade DEPENDENTE com atributos Funcionário, Nome.dependente. Sexo, Data_nascimento e Parentesco (com o funcionário). Outro requisito é que um funcionário pode trabalhar em vários projetos, e o banco de dados precisa armazenar o número de horas por semana que um fun­ cionário trabalha em cada projeto. Esse requisito c listado como parte do terceiro requisito na Seção 3.2, e pode ser representado por um atributo composto multi valo­ rado de FUNCIONÁRIO, chamado Trabalha.em, com os componentes simples (Projeto, Horas). Como alternativa, ele pode ser representado como um atributo composto multivalorado de PROJETO, chamado Trabalhadores, com os componentes simples (Funcionário, Horas). Escolhemos a primeira alternativa na Eigura 3.8; veremos, na próxima seção, que isso será refinado em um relacionamento muitos para muitos, quando introduzirmos os conceitos de relacionamentos.

3.4 Tipos e conjuntos de relacionamentos, papéis e restrições estruturais Na Figura 3.8 existem vários relacionamentos implícitos entre os diversos tipos de entidade. De fato, sempre que um atributo de um tipo de entidade se refere a outro tipo dc entidade, existe algum relacionamento. Por exemplo, o atributo Gerente dc DEPARTAMENTO refcrc-sc a um funcionário que gerencia o departamento; o atributo Departamento.gerenciador de PROJETO refere-se ao departamento que controla o projeto; o atributo Supervisor de FUNCIONÁRIO refere-se a outro funcionário (aquele que supervisiona esse funcionário); o atributo Departamento de FUNCIONÁRIO refere-se ao departamento para o qual o funcionário trabalha, e assim por diante. No modelo ER, essas referências não devem ser representadas como atributos, mas como relacionamentos. O esquema do banco dc dados inicial EMPRESA da Figura 3.8 será refinado na Seção 3.6 para representar relacionamentos de maneira explícita. No projeto inicial dos tipos de entidade, os relacionamentos normalmente são captura­ dos na forma de atributos. A medida que o projeto é refinado, esses atributos são

convertidos cm relacionamentos entre os tipos dc entidade. Esta seção é organizada da seguinte forma: a Seção 3.4.1 apresenta os conceitos dos tipos, conjuntos e instâncias de relacionamento. Definimos os conceitos de grau de relacionamento, nomes de função e relacionamentos recursivos na Seção 3.4.2, e depois discutimos as restrições estruturais sobre os relacionamentos — como as razões de cardinalidade e dependências de existência — na Seção 3.4.3. A Seção 3.4.4 mostra como os tipos de relacionamento também podem ter atributos.

3.4.1 Tipos, conjuntos e instâncias de relacionamento Um tipo de relacionamento R entre n tipos de entidade £p £,,..., £„ define um conjunto de associações — ou um conjunto de relacionamentos — entre as entidades

Capitulo 3

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

67

desses tipos de entidade. Assim como no caso dos tipos de entidades e conjuntos de entidades, um tipo de relacionamento e seu conjunto de relacionamentos cor­ respondente em geral sào referenciados pelo mesmo nome, R. Matematicamente, o conjunto de relacionamentos R é um conjunto de instâncias de relacionamento rp onde cada r, associa-se a n entidades individuais (ep e2,...» en), e cada entidade em r, é um membro do conjunto de entidades E,, 1 < j < n. Logo, um conjunto de relacionamentos é uma relação matemática sobre Ep E„ ..., En. Como alternativa, ele pode ser definido como um subconjunto do produto cartesiano dos conjuntos de entidades Et x E2 x ... x En. Cada um dos tipos de entidades £p E2,..., En é dito participar no tipo de relacionamento R; de modo semelhante, cada uma das entidades individuais ep e2,..., en é dito participar na instância de relacionamento r, = (e„ e,,.... e„). Informalmente, cada instância de relacionamento r- em R é uma associação de entidades, em que a associação inclui exatamente uma entidade de cada tipo de entidade participante. Cada instância de relacionamento r- desse ripo representa o fato de que as entidades participantes em rÉ estão relacionadas de alguma maneira na situação do minimundo correspondente. Por exemplo, considere um tipo de relacionamento TRABALHA_PARA entre os dois tipos de entidade FUNCIONÁRIO e DEPARTAMENTO, que associa cada funcionário ao departamento para o qual o funcionário trabalha no conjunto de entidades correspondente. Cada instância de relacionamento no conjunto de relacionamentos TRABALHA_PARA associa uma entidade FUNCIONÁRIO a uma entidade DEPARTAMENTO. A Figura 3.9 ilustra esse exemplo, em que cada instância de relacionamento ri aparece conectada às entidades FUNCIONÁRIO e DEPARTAMENTO que participam de r-. No minimundo representado pela Figura 3.9, os funcionários fx,f3 e f6 trabalham para o departamento dp os funcionários f2e f4 trabalham para o departamento d2; e os funcionários f5 e f7 trabalham para o departamento Nos diagramas ER, os tipos de relacionamento são exibidos como caixas em forma dc losango, que são conectadas por linhas retas às caixas retangulares que representam os ripos de entidade participantes. O nome do relacionamento é exibido na caixa em forma de losango (ver Figura 3.2). FUNCIONÁRIO

TRABALHA PARA

DEPARTAMENTO

Figura 3.9 Algumas

instâncias no conjunto

de relacionamentos TRABALHA-PARA, que

representa um tipo

de relacionamento TRABALHA, PARA entre FUNCIONÁRIO e DEPARTAMENTO.

68 Sistemas de banco de dados

3.4.2 Grau de relacionamento, nomes de papéis e relacionamentos

recursivos (autorrelacionamento) Grau de um tipo de relacionamento. O grau de um ripo de relacionamento é o número dos tipos de entidade participantes. Logo, o relacionamento TRABALHA_PARA tem grau dois. Um tipo de relacionamento de grau dois é chamado dc binário, c um tipo de grau três é chamado de ternário. Um exemplo de relacionamento ternário é FORNECE, mostrado na Figura 3.10, em que cada instância de relacionamento rt associa três entidades — um fornecedor f uma peça p e um projeto / — sempre que f fornece a peça p ao projeto/. Os relacionamentos geralmente podem ser dc qualquer grau, mas os mais comuns são os relacionamentos binários. Relacionamentos dc grau mais alto geralmente são mais complexos que os binários; nós os caracterizaremos mais adiante, na Seção 3.9. Relacionamentos como atributos. Às vezes, c conveniente pensar em um tipo de relacionamento binário em termos dc atributos, conforme discutimos na Seção 3.3.3. Considere o ripo de relacionamento TRABALHA.PARA da Figura 3.9. Pode-se pensar em um atributo chamado Departamento do ripo de entidade FUNCIONÁRIO, cm que o valor do Departamento para cada entidade FUNCIONÁRIO c a (uma refe­ rência à) entidade DEPARTAMENTO para a qual esse funcionário trabalha. Logo, o conjunto de valores para esse atributo Departamento é o conjunto de todas as entidades DEPARTAMENTO, em que está o conjunto de entidades DEPARTAMENTO. Foi isso que fizemos na Figura 3.8, quando especificamos o projeto inicial do tipo de entidade FUNCIONÁRIO para o banco de dados EMPRESA. Porém, quando pensamos em um relacionamento binário como um atributo, sempre temos duas opções ou dois pontos dc vista. Neste exemplo, o ponto dc vista alternativo c pensar em um atributo mukivalorado Funcionários do tipo de entidade DEPARTAMENTO, cujos valores para cada entidade DEPARTAMENTO são o conjunto de entidades de FUNCIONÁRIO que trabalham para esse departamento. O conjunto de valores desse atributo Funcionários é o conjunto dc potência do conjunto dc entidades FUNCIONÁRIO. Qualquer um desses dois atributos — Departamento dc FUNCIONÁRIO ou Funcionários de DEPARTAMENTO — pode representar o tipo de relacionamento FORNECEDOR

Figura 3.10 Algumas instâncias de relacionamento no conjunto de relacionamento ternário FORNECE.

FORNECE

PROJETO

Capitulo 3

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

69

TRABALHA_PARA. Se os dois forem representados, eles são restringidos a serem o inverso um do outro.8

Nomes de papéis e relacionamentos recursivos. Cada tipo de entidade que participa de um tipo de relacionamento desempenha nele um papel em particular. O nome do papel significa o papel que uma entidade participante do ripo de entidade desempenha em cada instância de relacionamento, e ajuda a explicar o que o relacionamento significa. Por exemplo, no tipo de relacionamento TRABALHA_PARA, FUNCIONÁRIO desempenha o papel de funcionário ou trabalhador, e DEPARTAMENTO desempenha o papel de departamento ou empregador. Os nomes dos papéis não são tecnicamente necessários nos tipos de relaciona­ mento em que todos os tipos de entidade participantes são distintos, pois o nome de cada tipo de entidade participante pode ser usado como o nome do papel. Contudo, em algumas ocasiões, o mesmo tipo de entidade participa mais de uma vez em um tipo de relacionamento em papéis diferentes. Nesses casos, o nome do papel torna-se essencial para distinguir o significado do papel que cada entidade participante desem­ penha. Esses tipos de relacionamento são chamados de relacionamentos recursivos ou autorrelacionados. A Figura 3.11 mostra um exemplo. O tipo de relacionamento SUPERVISIONA relaciona um funcionário a um supervisor, no qual as entidades fun­ cionário e supervisor são membros do mesmo conjunto de entidades FUNCIONÁRIO. Logo, o tipo de entidade FUNCIONÁRIO participa duas vezes em SUPERVISIONA: uma vez no papel de supervisor (ou chefe) e outra no papel dc supervisionado (ou subordinado). Cada instância de relacionamento r, em SUPERVISIONA associa duas entidades de funcionário f- e fk> uma das quais desempenha o papel de supervisor e a outra, o papel de supervisionado. Na Figura 3.11, as linhas marcadas com ‘1’ representam o papel de supervisor, e aquelas marcadas com ‘2’ representam o papel de supervisionado; assim, fx supervisiona e /3, fA supervisiona e f7, c fs supervisiona fx e fA. Neste exemplo, cada instância de relacionamento precisa ser conectada com duas linhas, uma marcada com ‘1’ (supervisor) e a outra com ‘2’ (supervisionado). FUNCIONÁRIO

SUPERVISIONA

Figura 3.11 Um

relacionamento recursive SUPERVISIONA entre

FUNCIONÁRIO no papel

de supervisor (1) e FUNCIONÁRIO no papel

de subordinado (2).

8 Esse conceito dc representar os tipos dc relacionamento como atributos c usado cm uma classe dc modelos de dados chamada modelos de dados funcionais. Nos bancos de dados de objeto (ver Capítulo

12), os relacionamentos podem ser representados por atributos de referência, seja em uma direção, seja nas duas direções como inversos. Em bancos dc dados relacionais (ver Capítulo 5), as chaves estrangei­

ras são um ripo de atributo de referência usado para representar relacionamentos.

70

Sistemas de banco de dados

3.4.3 Restrições sobre tipos de relacionamento binários Os tipos de relacionamento costumam ter certas restrições que limitam as combinações de entidades que podem participar no conjunto de relacionamen­ tos correspondente. Essas restrições sào determinadas com base na situação do minimundo que os relacionamentos representam. Por exemplo, na Figura 3.9, se a empresa tem uma regra de que cada funcionário precisa trabalhar para exatamente um departamento, gostaríamos de descrever essa restrição no esquema. Podemos distinguir dois tipos principais de restrições de relacionamento binário: razão de cardinalidade e participação. Razões de cardinalidade para relacionamentos binários. A razão de cardinali­ dade para um relacionamento binário especifica o número máximo de instâncias de relacionamento em que uma entidade pode participar. Por exemplo, no tipo dc relacionamento binário TRABALHA.PARA, DEPARTAMENTOTUNCIONARIO tem razão de cardinalidade 1:N, significando que cada departamento pode estar relacionado a (ou seja, emprega) qualquer número de funcionários (N),9 mas um funcionário só pode estar relacionado a (trabalha para) um departamento. Isso significa que, para esse relacionamento TRABALHA_PARA cm particular uma entidade de departamento específica pode estar relacionada a qualquer número dc funcionários (N indica que não existe um número máximo). Por sua vez, um funcionário pode estar relacionado no máximo a um único departamento. As razões de cardinalidade possíveis para tipos de relacionamento binários são 1:1, 1:N, N:1 e M:N. Um exemplo de relacionamento binário 1:1 é GERENCIA (Figura 3.12), o qual rela­ ciona uma entidade dc departamento ao funcionário que gerencia esse departamento. Isso representa as restrições do minimundo que — em qualquer ponto no tempo — um funcionário pode gerenciar apenas um departamento e um departamento pode ter apenas um gerente. O tipo de relacionamento TRABALHA_EM (Figura 3.13) é de razão dc cardinalidade M:N, porque a regra do minimundo é que um funcionário pode trabalhar cm vários projetos c um projeto pode ter vários funcionários. FUNCIONÁRIO

GERENCIA

DEPARTAMENTO

Figura 3.12 Um relacionamento 1:1. GERENCIA.

9 N significa qualquer número de entidades relacionadas (zero ou mais). Em algumas relações, o sím­

bolo do asterisco (*) é usado no lugar de N.

Capitulo 3

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

As razões de cardinalidade para relacionamentos binários são representadas nos diagramas ER exibindo 1, M e N nos losangos, como mostra a Figura 3.2. Observe que, nessa notação, podemos especificar nenhum máximo (N) ou um máximo de um (1) na participação. Uma notação alternativa (ver Seção 3.7.4) permite que o projetista especifique um número máximo na participação, como 4 ou 5.

Restrições de participação e dependências de existência. A restrição dc partici­ pação especifica se a existência de uma entidade depende de ela estar relacionada a outra entidade por meio do tipo de relacionamento. Essa restrição especifica o número mínimo de instâncias de relacionamento em que cada entidade pode parti­ cipar, e às vezes é chamada de restrição de cardinalidade mínima. Existem dois tipos de restrições de participação — total e parcial — que vamos ilustrar. Se a política dc uma empresa afirma que todo funcionário precisa trabalhar para um departamento, uma entidade dc funcionário só pode existir se participar cm, pelo menos, uma instância de relacionamento TRABALHA_PARA (Figura 3.9). Assim, a participação dc FUNCIONÁRIO em TRABALHA_PARA é chamada de participação total, significando que cada entidade no conjunto total dc entidades de funcionário deve estar relacionada a uma entidade de departamento por meio de TRABALHA_PARA. A participação total também é conhecida como dependência de existência. Na Figura 3.12, não esperamos que cada funcionário gerencie um departamento, de modo que a participação de FUNCIONÁRIO no tipo de relacionamento GERENCIA é parcial, significando que uma parte do conjunto de entidades de funcionário está relacionada a alguma entidade de departamento por meio dc GERENCIA, mas não necessariamente todas. Vamos nos referir à razão de cardinalidade e restrições dc participação, juntas, como as restrições estruturais de um tipo de relacionamento. Em diagramas ER, a participação total (ou dependência de existência) é exibida como uma linha dupla que conecta o tipo dc entidade participante ao relacionamento, enquanto a participação parcial c representada por uma linha simples (ver Figura 3.2). Observe que, nessa notação, podemos especificar nenhum mínimo (participação parcial) ou um mínimo de um (participação total). Uma notação alternativa (ver Seção 3.7.4) permite que o projetista indique um número mínimo específico da participação no relacionamento, como 4 ou 5.

71

72

Sistemas de banco de dados

Discutiremos as restrições sobre os relacionamentos de grau mais alto na Seção 3.9.

3.4.4 Atributos dos tipos de relacionamento Os tipos de relacionamento também podem ter atributos, semelhantes àqueles dos tipos de entidade. Por exemplo, para registrar o número de horas por semana que um funcionário trabalha em um determinado projeto, podemos incluir um atributo Horas para o ripo de relacionamento TRABALHA_EM na Figura 3.13. Outro exemplo é incluir a data em que um gerente começou a chefiar um departamento por meio dc um atributo Datajnicio para o tipo dc relacionamento GERENCIA na Figura 3.12. Observe que os atributos dos tipos de relacionamento 1:1 ou 1:N podem ser migrados para um dos tipos de entidade participantes. Por exemplo, o atributo Datajnicio para o relacionamento GERENCIA pode ser um atributo de FUNCIONÁRIO (gerente) ou de DEPARTAMENTO, embora conccitualmcnte ele pertença a GERENCIA. Isso porque GERENCIA c um relacionamento 1:1, de modo que cada entidade de departamento ou funcionário participa de no máximo uma instância de relaciona­ mento. Logo, o valor do atributo Datajnicio pode ser determinado separadamente, pela entidade do departamento participante ou pela entidade do funcionário par­ ticipante (gerente). Para um tipo de relacionamento 1:N, um atributo de relacionamento pode ser migrado somente para o tipo de entidade no lado N do relacionamento. Por exemplo, na Figura 3.9, se o relacionamento TRABALHA_PARA também tiver um atributo Datajnicioque indica quando um funcionário começou a trabalhar para um departamento, esse atributo pode ser incluído como um atributo de FUNCIONÁRIO. Isso porque cada funcionário trabalha para somente um departamento c por isso participa de, no máximo, uma instância de relacionamento em TRABALHA_PARA, mas um departamento pode ter muitos funcionários, cada um com uma data de início diferente. Nos tipos de relacionamento 1:1 e 1:N, a decisão de onde colocar um atributo de relacionamento — como um atributo do tipo de relacionamento ou como um atributo dc um tipo de entidade participante — é determinada dc maneira subjetiva pelo projetista do esquema. Para tipos de relacionamento M:N (muitos para muitos), alguns atributos podem ser determinados pela combinação de entidades participantes em uma instância de relacionamento, e não por qualquer entidade isolada. Esses atributos precisam ser especificados como atributos de relacionamento. Um exemplo é o atributo Horas do relacionamento M:N de TRABALHA_EM (Figura 3.13). O número dc horas por semana que um funcionário trabalha atualmente em um projeto é determinado por uma com­ binação FUNCIONARIO-PROJETO, e não de maneira separada por qualquer entidade.

3.5 Tipos de entidade fraca Tipos dc entidade que não possuem atributos-chave próprios são chamados tipos de entidade fraca. Ao contrário, os tipos de entidade regulares que possuem um atributo-chave — o que inclui todos os exemplos discutidos até aqui — são chamados de tipos de entidade fortes. As entidades pertencentes a um ripo de entidade fraca são identificadas por estarem relacionadas a entidades específicas de outro ripo em combinação com um de seus valores de atributo. Chamamos esse outro tipo de entidade de tipo dc entidade dc identificação ou proprietário,10 e chamamos o tipo de relacionamento que relaciona um tipo de entidade fraca a seu proprietário de

10 O tipo dc entidade dc identificação c também chamado dc tipo dc entidade pai, ou tipo dc entidade dominante.

Capitulo 3

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

relacionamento de identificação do ripo de entidade fraca.11 Um ripo de enridade fraca sempre tem uma restrição de participação total (dependência de existência) com relação a seu relacionamento de identificação, porque a entidade fraca não pode ser identificada sem uma entidade proprietária. Porém, nem roda dependên­ cia de existência resulta em um ripo de entidade fraca. Por exemplo, uma enridade CARTEIRA_MOTORISTA não pode existir, a menos que esteja relacionada a uma enti­ dade PESSOA, embora tenha a própria chave (Numero_habilitacao) e, portanto, não seja uma entidade fraca. Considere o tipo de entidade DEPENDENTE, relacionado a FUNCIONÁRIO, que é usado para registrar os dependentes de cada funcionário por meio de um relaciona­ mento 1:N (Figura 3.2). Em nosso exemplo, os atributos de DEPENDENTE são Nome (o primeiro nome do dependente), Data_nascimento, Sexo e Parentesco (com o fun­ cionário). Dois dependentes de dois funcionários distintos podem, por coincidência, ter os mesmos valores para Nome, Data_nascimento. Sexo e Parentesco, mas ainda assim eles são entidades distintas. Eles são identificados como entidades distintas apenas depois de determinar a entidade de funcionário em particular à qual cada dependente está relacionado. Considera-se que cada entidade de funcionário possui as entidades dependentes que estão relacionadas a ele. Um tipo de entidade fraca normalmente tem uma chave parcial, que é o atributo que pode identificar exclusivamente as entidades fracas que estão relacionadas à mesma entidade proprietária.Em nosso exemplo, se considerarmos que dois depen­ dentes do mesmo funcionário não poderão ter o mesmo primeiro nome, o atributo Nome dc DEPENDENTE é a chave parcial. No pior dos casos, um atributo composto de todos os atributos da entidade fraca será a chave parcial. Em diagramas ER, tanto um tipo de entidade fraca quanto seu relacionamento de identificação são disringuidos ao delimitar suas caixas e losangos com linhas duplas (ver Figura 3.2). O atributo de chave parcial é sublinhado com uma linha tracejada ou pontilhada. Os tipos de entidade fraca às vezes podem ser representados como atributos complexos (compostos, multivalorados). No exemplo anterior, poderiamos especi­ ficar um atributo multivalorado Dependentes para FUNCIONÁRIO, que é um atributo composto com os atributos componentes Nome, Data.nasdmento. Sexo e Parentesco. A escolha de qual representação usar é feita pelo projetista de banco de dados. Um critério que pode ser usado é escolher a representação do tipo de entidade fraca se ela participar independentemente nos tipos de relacionamento além de seu tipo de relacionamento de identificação. Em geral, podemos definir qualquer quantidade de níveis de tipos de entidade fraca; um tipo de entidade proprietário pode ele mesmo ser um tipo de entidade fraca. Além disso, um tipo de entidade fraca pode ter mais de um tipo de entidade de identificação e um tipo de relacionamento de identificação de grau maior que dois, conforme ilustraremos na Seção 3.9.

3.6 Refinando o projeto ER para o banco de dados EMPRESA Agora, podemos refinar o projeto de banco de dados da Figura 3.8 alterando os atributos que representam relacionamentos para tipos dc relacionamento. A razão de cardinalidade c a restrição de participação dc cada tipo dc relacionamento são

1 1 O tipo de enridade fraca também é chamado de tipo de enridade filho, ou ripo de entidade subordinado.

*- A chave parcial às vezes é chamada de discríminadora.

73

74

Sistemas de banco de dados

determinadas com base nos requisitos listados na Seçào 3.2. Se alguma razão de cardinalidade ou dependência nào puder ser especificada dessa maneira, os usuários terão de ser questionados ainda mais para determinar essas restrições estruturais. Em nosso exemplo, especificamos os seguintes tipos de relacionamento: ■ GERENCIA, um tipo de relacionamento 1:1 (um para um) entre FUNCIONÁRIO c DEPARTAMENTO. A participação de FUNCIONÁRIO é parcial. A participação de DEPARTAMENTO não é clara pelos requisitos. Questionamos os usuários, que dizem que um departamento precisa ter um gerente o tempo todo, o que implica parti­ cipação total.15 O atributo Datajnicio é atribuído a esse tipo de relacionamento. ■ TRABALHA_PARA, um tipo de relacionamento 1:N (um para muitos) entre DEPARTAMENTO e FUNCIONÁRIO. As duas participações são totais. ■ CONTROLA, um tipo de relacionamento 1:N entre DEPARTAMENTO e PROJETO. A participação de PROJETO é total, enquanto a de DEPARTAMENTO é determinada para ser parcial, depois que os usuários indicaram que alguns departamentos podem não controlar projeto algum. ■ SUPERVISIONA, um ripo de relacionamento 1 :N entre FUNCIONÁRIO (no papel de supervisor) e FUNCIONÁRIO (no papel de supervisionado). As duas participações são determinadas como parciais, depois que os usuários indicaram que nem todo funcionário é um supervisor e nem todo funcionário tem um supervisor. ■ TRABALHA_EM, determinado como um tipo de relacionamento M:N (muitos para muitos) com atributo Horas, depois que os usuários indicaram que um projeto pode ter vários funcionários trabalhando nele. As duas participações são deter­ minadas como totais. ■ DEPENDEM_DE, um tipo de relacionamento 1 :N entre FUNCIONÁRIO e DEPENDENTE, que também é o relacionamento de identificação para o tipo de entidade fraca DEPENDENTE. A participação de FUNCIONÁRIO é parcial, enquanto a de DEPENDENTE é total.

Depois de especificar os seis tipos de relacionamento citados, removemos dos tipos de entidade da Figura 3.8 todos os atributos que foram refinados para relacionamen­ tos. Estes incluem Gerente e Data_inicio_qerente de DEPARTAMENTO; Departamento, gerenciador de PROJETO; Departamento, Supervisor e Trabalha_em de FUNCIONÁRIO; e Funcionário de DEPENDENTE. É importante ter o mínimo possível de redundância

quando projetamos o esquema conceituai de um banco dc dados. Sc alguma redun­ dância for desejada no nível dc armazenamento ou no nível de visão do usuário, ela pode ser introduzida mais tarde, conforme discutimos na Seção 1.6.1.

3.7 Diagramas ER, convenções de nomes e questões de projeto 3.7.1 Resumo da notação para diagramas ER As figuras 3.9 a 3.13 ilustram exemplos da participação dos tipos de entidade nos tipos de relacionamento ao exibir seus conjuntos de entidade e relacionamento (ou extensões) — as instâncias dc entidade individuais cm um conjunto dc entidades c as instâncias de relacionamento individuais em um conjunto de relacionamentos. Nos diagramas ER, a ênfase está em representar os esquemas em vez das instâncias. Isso é mais útil no projeto porque um esquema de banco de dados muda raramente.

13 As regras no minimundo que determinam as restrições também são chamadas de regras de negócio,

pois elas são determinadas pelo negócio ou pela organização que utilizará o banco de dados.

Capitulo 3

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

enquanto o conteúdo dos conjuntos de entidades muda com frequência. Além disso, o esquema é obviamente mais fácil de exibir, pois é muito menor. A Figura 3.2 exibe o esquema de banco de dados EMPRESA como um diagrama ER. Agora, revisamos a notação completa do diagrama ER. Tipos de entidade regulares (fortes) como FUNCIONÁRIO, DEPARTAMENTO e PROJETO são mostrados nas caixas retangulares.Tipos de relacionamento como TRABALHA_PARA, GERENCIA, CONTROLA e TRABALHA_EM são mostrados em caixas em forma dc losango, conectadas aos tipos de entidade participantes com linhas retas. Os atributos são mostrados cm ovais, e cada atributo é conectado por uma linha reta a seu tipo de entidade ou tipo de relacionamento. Os atributos componentes de um atributo composto são conectados à oval que representa o atributo composto, conforme ilustrado pelo atributo Nome dc FUNCIONÁRIO. Os atributos mukivalorados aparecem cm ovais duplas, conforme ilustrado pelo atributo Localizacoes de DEPARTAMENTO. Os atributos-chave têm seus nomes sublinhados. Os atributos derivados aparecem em ovais tracejadas, conforme ilustrado pelo atributo Numero_de_funcionarios de DEPARTAMENTO. Os tipos de entidade fraca são distinguidos ao serem colocados em retângulos duplos e terem seu relacionamento dc identificação colocado cm losangos duplos, conforme ilustrado pelo tipo dc entidade DEPENDENTE e o tipo dc relacionamento de identificação DEPENDEM_DE. A chave parcial do tipo de entidade fraca é sublinhada com uma linha tracejada. Na Figura 3.2, a razão dc cardinalidadc dc cada tipo de relacionamento binário é especificada pela conexão de um 1, M ou N cm cada aresta participante. A razão de cardinalidadc de DEPARTAMENTO:FUNCIONARIO cm GERENCIA é 1:1, enquanto é 1:N para DEPARTAMENTOTUNCIONARIO em TRABALHA_PARA, e M:N para TRABALHA.EM. A restrição de participação é especificada por uma linha simples para participação parcial e por linhas duplas para a participação total (dependência de existência). Na Figura 3.2, mostramos os nomes de papel para o tipo de relacionamento SUPERVISIONA, pois o mesmo tipo dc entidade FUNCIONÁRIO desempenha dois papéis distintos nesse relacionamento. Observe que a razão dc cardinalidadc é 1:N dc supervisor para supervisionado porque cada funcionário no papel de supervisionado tem, no máximo, um supervisor direto, ao passo que um funcionário no papel de supervisor pode controlar zero ou mais funcionários. A Figura 3.14 resume as convenções para diagramas ER. É importante observar

que existem muitas outras notações diagramáticas alternativas (ver Seção 3.7.4 e Apêndice A).

3.7.2 Nomeação apropriada de construções de esquema Ao projetar um esquema dc banco de dados, a escolha dc nomes para tipos dc entidade, atributos, tipos dc relacionamento e (particularmentc) papéis nem sempre é simples. E preciso escolher nomes que transmitam, tanto quanto possível, os sig­ nificados associados às diferentes construções no esquema. Escolhemos usar nomes no singular para os tipos de entidade, em vez de nomes no plural, porque o nome se aplica a cada entidade individual pertencente a esse ripo de entidade. Em nossos diagramas ER, usaremos a convenção de que os nomes do tipo de entidade e tipo dc relacionamento são escritos cm letras maiusculas, os nomes dc atributo têm apenas a letra inicial cm maiuscula c os nomes do papel são escritos cm letras minúsculas. Usamos essa convenção na Figura 3.2. Como uma prática geral, dada uma descrição narrativa dos requisitos do banco de dados, os substantivos que aparecem na narrativa tendem a gerar nomes de tipo de entidade, c os verbos tendem a indicar nomes dc tipos dc relacionamento. Os

75

76

Sistemas de banco de dados

Símbolo

Significado

Entidade

Entidade fraca

Relacionamento

Relacionamento de identificação

Atributo

Atributo-chave

Atributo multivalorado

Atributo composto

Atributo derivado

Participação total de

E2 em R

Razão de cardinalidade 1: N para

Ey: E2 em R

Restrição estrutural (min, max) na participação de

E em R

nomes de atributo costumam surgir de substantivos adicionais que descrevem os nomes correspondentes a tipos de entidade. Outra consideração de nomeação envolve a escolha de nomes de relacionamento binário para tornar o diagrama ER do esquema legível da esquerda para a direita e de cima para baixo. Seguimos essa orientação de modo geral na Figura 3.2. Para explicar melhor essa convenção de nomeação, temos uma exceção para a Figura 3.2 — o ripo de relacionamento DEPENDEM.DE, lido de baixo para cima. Quando descrevemos esse relacionamento, podemos dizer que as entidades DEPENDENTE (tipo dc entidade inferior) DEPENDEM_DE (nome dc relacionamento) um FUNCIONÁRIO (tipo de entidade superior). Para mudar isso e ler de cima para baixo, poderiamos

Capitulo 3

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

renomear o ripo de relacionamento para POSSUI_DEPENDENTES, que então seria lido da seguinte forma: uma entidade FUNCIONÁRIO (tipo de entidade superior) POSSUI_DEPENDENTES (nome de relacionamento) do tipo DEPENDENTE (tipo de entidade inferior). Observe que esse problema surge porque cada relacionamento binário pode ser descrito começando de qualquer um dos dois tipos de entidades participantes, conforme discutido no início da Seção 3.4.

3.7.3 Escolhas de projeto para o projeto conceituai ER Às vezes c difícil decidir se um conceito cm particular no minimundo deve ser modelado como um tipo de entidade, um atributo ou um tipo de relacionamento. Nesta seção, oferecemos algumas orientações rápidas sobre qual construção deve ser escolhida em situações específicas. Em geral, o processo de projeto dc esquema deve ser considerado um processo de refinamento iterativo, no qual um projeto inicial é criado e depois refinado iterativamente até que o mais adequado seja alcançado. Alguns dos refinamentos frequentemente utilizados incluem o seguinte: ■ Um conceito pode ser modelado como um atributo e depois refinado para um rela­ cionamento, pois c determinado que o atributo c uma referencia para outro tipo dc entidade. Com frequência acontece de um par desses atributos, que são inversos um do outro, ser refinado em um relacionamento binário. Discutimos esse tipo de refi­ namento com detalhes na Seção 3.6. É importante observar que, em nossa notação, quando um atributo é substituído por um relacionamento, o próprio atributo deve ser removido do tipo de entidade para evitar duplicação e redundância. ■ Dc modo semelhante, um atributo que existe em vários tipos de entidade pode ser elevado ou promovido para um tipo dc entidade independente. Por exemplo, suponha que cada tipo de entidade em um banco de dados UNIVERSIDADE, como ALUNO, PROFESSOR e DISCIPLINA, tenha um atributo Departamento no projeto ini­ cial. O projetista pode escolher criar um ripo de entidade DEPARTAMENTO com um único atributo Nome_departamento e relacioná-lo aos três tipos de entidade (ALUNO, PROFESSOR e DISCIPLINA) por meio de relacionamentos apropriados. Outros atributos/relacionamentos de DEPARTAMENTO podem ser descobertos mais tarde. ■ Um refinamento inverso para o caso anterior pode ser aplicado — por exemplo, se um tipo dc entidade DEPARTAMENTO existir no projeto inicial com um atri­ buto isolado Nome_departamento e estiver relacionado a somente outro tipo de entidade, ALUNO. Nesse caso, DEPARTAMENTO pode ser reduzido ou rebaixado para um atributo de ALUNO. ■ A Seção 3.9 vai discutir as escolhas referentes ao grau de um relacionamento. No Capítulo 4, discutiremos outros refinamentos referentes à especialização/ generalização.

3.7.4 Notações alternativas para diagramas ER Existem muitas notações diagramáticas alternativas para exibir diagramas ER. O Apêndice A mostra algumas das mais populares. Na Seção 3.8, vamos introduzir a notação Linguagem de Modelagem Unificada (UML) para diagramas de classe, que foi proposta como um padrão para a modelagem conceituai de objeto. Nesta seção, descrevemos uma notação ER alternativa para especificar restrições estruturais sobre os relacionamentos, que substitui a razão de cardinalidade (1:1, 1:N, M:N) e a notação de linha simples/dupla para as restrições de participação. Essa notação envolve associar um par de números inteiros (min, max) a cada participação

77

78

Sistemas de banco de dados

de um tipo de entidade E em um tipo de relacionamento R, onde 0 < min < max e max > 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. 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 de 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, e assim por diante). Um complexo tem um local, organizador-chcfe, área total ocupada, e 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 c, 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 de 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 (sc 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-Relaoonamento 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],c dc um tipo de 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 dc serviço [SERVIÇO]. Cada aeronave passa por serviço de manuten­ ção muitas vezes; logo, ela é relacionada por |PASSA_POR) a uma serie dc 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 dc 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

uma

Sa ano TRABALHA EM>^

---XPeso

FUNCIONÁRIO |N

M

-A7

MANUTFNC AC

MODELO- AERONAVE

umero licenca

estncoes

1

M

VOA ATRIBUÍDO

PILOTO

ÇCodigo_tra ba I ho

N

ata/codigo trabalh

Horas

SERVIÇO

Cod registro

N

PASSA POR

AERONAVE N

(^Data compra^)

GUARDADO FM

proprietário]

PFRTFNC

nn

r HANGAR

Numero

CORPORACAO

Localizacao

Capacidade

Telefone Endereço

(g)—I

PESSOA

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 rumo 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

(d) É uma

Conjunto de

especialização

generalização

entidades ou

de

de

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 claramcntc 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.

b.

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

NOTEBOOK

DESKTOP

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 e 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 e 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-Relacionamento 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 de 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 (Verhcijen e VanBekkum, 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 de generalização c agregação. O modelo dc dados semântico de Hammer c McLeod (1981) introduziu os conceitos dc rcticulados dc classc/subclasse, 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). howler 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 c 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 de 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 e de 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 de 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 Figura 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 normalmente 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 de 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 de 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 c relação — de maneira formal. 1

CASE

significa computer-aided software engineering {engenharia

computador).

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 de 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 ..., An. Cada atributo Ai é o nome dc um papel desempenhado por algum domínio D no esquema de relação R. D é chamado dc domínio dc Ai c indicado por dom(A;). Um esquema de 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) - 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 tuplas r = {ípí2,..., tOT|. Cada n tuplas t é uma lista ordenada de n valores t = , em que cada valor 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 rupia í, que corresponde ao atributo Aj, é referenciado como í[AJ ou t-At (ou 4fl, se 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 doiníAj), dom(Â2),..., 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

Atributos

Nome de relação ALUNO

Tuplas

Nome

Cpf

Telefone residencial Endereço

Telefone comercial Idade

Bruno Braga

305.610.243-51

(17) 3783-1616

NULL

19

3,21

Carlos Kim

361.620.124-45 (17)3785-4409

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

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

28

3,93

Barbara Benson

533.690.123-80 (17) 3239-8461

Rua Jardim, 7384

19

3,25

Rua das Paineiras, 2918

NULL

Media

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_telefones_local, 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 ldom(An)l Esse produto de cardinalidades de todos os domínios representa o número total de possíveis instâncias ou tuplas que poderão existir em qualquer estado de relação r(R). De todas as combinações possíveis, um estado de relação em 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 R é 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 originalmente armazenadas na relação. E possível que vários atributos tenham o mesmo domínio. Os nomes de 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 de 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 em 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 = {Ap 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 í2, —» em que cada tupla ti é 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, í|AJ deve estar em dom(AJ para 1 < / < w para cada mapeamento t em r. Cada mapeamento ti é 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 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 dc 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

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)>

ordem dos atributos e

valores não faz parte da definição da relação.

t = 5 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-relacional (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 de 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 de dois valores NULL leva a ambiguidades — se os Clientes A e B têm 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 de um esquema de relação é como um predicado; neste caso, os valores em 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 de 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 de grau n é indicado por R(Aj, 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 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 geralmentc 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 de 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 de dependências de dados, que incluem dependências funcionais e dependências multivaloradas. Elas são usadas principalmente para testar a “virtude” do projeto de um banco de 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 Seção 5.1.1. Os tipos de 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 de 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 de 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 r1 e t, em um estado de relação r de R, temos a restrição de que: í,[SCh]

r2[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 de SCh. Cada relação tem pelo menos uma superchave padrão — o conjunto de todos os seus atributos. Contudo, uma superchave pode ter atributos redundantes, de modo que um conceito mais útil é o de 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 A 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 Numero chassi

Marca

Itatiaia ABC-7039

A6935207586

Volkswagen

Gol

02

ltuTVP-3470

B4369668697

Chevrolet

Corsa

05

Santos MPO-2902

X8355447376

Rat

Uno

01

Itanhaem TFY-6858

C4374268458

Chevrolet

Celta

99

Itatiba RSK-6279

Y8293586758

Renault

Clio

04

Atibaia RSK-6298

U0283657858

Volkswagen

Parati

04

Placa

Figura 5.4 A relação

CARRO, com duas chaves candidatas:

Placa e Numero.chassi.

Modelo

Ano

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 de dados relacionai e um esquema de banco de dados relacionai. Um esquema de banco dc dados relacionai 5 é um conjunto de esquemas de relação 5 = |Rj, R2, ..., Rm| 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» •••» rml, tal que cada r, é 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 de exemplo em diferentes linguagens relacionais.

Primeiro_

Nome_

Ultimo_

nome

meio

nome

IS

FUNCIONÁRIO Data_ nascimento

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 Cpffuncionario

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 estado 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 Primei ro_ Nome_ Ultimo_ nome meio nome

Çfif

Data_ nasd mento

Numero Sexo Salario Cpf_supervisor departa­

Endereço

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 fóulo, SP

F

25.000

33344555587

5

André

V

Pereira

98798798733 29-03-1969

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

RuaTimbira, 35, São Paulo, SP

LOCALIZACOES.DEPARTAMENTO

DEPARTAMENTO Nome_

Numero,

departamento

departamento

Cpfgerente

Numero_departamento

Datajnido,

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, projeto

Numero, departamento

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

Novosbenefkios

30

Mauá

4

Sexo

Data.nasdmento

Parentesco

33344555587

2

10,0

33344555587

3

10,0

33344555587

10

10.0

33344555587

20

10,0

99988777767

30

30,0

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

Local projeto

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

Michael

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 cut/j 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. Informalmcntc, 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 dc FUNCIONÁRIO fornece o número dc 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 f, 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 t2. 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 t] da relação FUNCIONÁRIO precisa combinar com um valor da chave primária de DEPARTAMENTO — o atributo Numero.departamento — em alguma tupla t2 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

meio

nome

Data

nascimento

Endereço

Sexo

Salario

Cpf

supervisor

Numero_ departa­

mento

DEPARTAMENTO Nome departamento

Numero departamento

Cpf gerente

Data Jnicio. gerente

LOCALIZACOES DEPARTAMENTO Numero_departamento

Local

L PROJETO Nome_ projeto

Numero projeto | Local projeto

Numero departamento

TRABALHA_EM Cpf_funcionario

Numero_projeto

Horas

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 dc dados, ou utilizando uma linguagem dc especificação dc restrição dc 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.” 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 de 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 dc 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, de 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 restrições estáticas, e as restrições de transi­

ção também sào chamadas de restrições dinâmicas.

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 t 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 e 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

Estado

VOO Numero_voo

Dias_da_semana

Companhia_aerea

TRECHO Numero voo

Numero trecho

Codigo_aeroporto_

inicia

Codigo_aeroporto_

Horario_inicia

finaliza

Horário termino

TRECHO-SOBREVOADO Numero_ Numero_voo

Numerotrecho

Data

assentos_

disponíveis

Codigo_ aeronave

Codigo_ aeroporto_

Codigo_ Horariojnicia

inicia

aeroporto_

finaliza

Horario_ termino

TARIFA Numero voo | Codigo tarifa

Quantidade |

Restrições

MODELO-AERONAVE Nome modelo

Maximo assentos

Empresa

PODE_POUSAR Nome_modelo

Codiqo_aeroporto

AERONAVE Codigo_aeronave

Numero_total_assentos

Modelo_aeronave

RESERVA,ASSENTO Numero voo

Numero trecho

Data

Numero assentos

Nome_cliente

Telefone_diente

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 de 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(ÇpL 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 de automóveis em um revendedor de 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 uiola as restrições de integridade referencial e de 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 é ú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 de cidade e estado diferentes do telefone local. Uma tupla possível da relação é mostrada a seguir: Nome Jorge Pereira William Ribeiro

Cpf

Telefonejocal

123-459-678-97

5555-1234

Endereço Rua Cambará,

33, Bauru, SP

Telefone_celular

Idade

Media

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 de 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 de conjunto para modelar bancos dc 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 dc 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 Elmasri (1979) introduzem diversos tipos dc 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 c 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 c 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 scr especificadas em um banco dc dados relacionai. Elas também são importantes para processamento c 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 de 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 de 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 de 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

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 de 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 de transação no Capítulo 20, bancos dc 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, rcspcctivamcnte. Usaremos os termos correspon­ dentes para indicar a mesma coisa. O principal comando SQL para a definição dc 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 c 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 dc 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 dc um esquema dc 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 dc banco dc dados (cm alguns sistemas, um esquema é chamado dc 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 — dc 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 cm 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 c elementos do esquema. O privilégio para criar esquemas, tabelas c outras construções deve ser concedido explicitamente às contas de usuário relevantes pelo administrador do sistema ou DBA.

SQL básica

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 diretamenre à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 CREA TE 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

(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,

NOT NULL,

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

FOREIGN KEY (CpLgerente) REFERENCES FUNCIONARIO(Cpf));

CREATE TABLE LOCALIZACOES.DEPARTAMENTO

(Numero-departamento

INT

NOT NULL,

Local

VARCHAR(15)

NOT NULL,

PRIMARY KEY (Numero.departamento. Local), FOREIGN KEY (Numero_departamento) REFERENCES D E PARTAMENTO(N u mero_departamento));

CREATE TABLE PROJETO

(Nome_projeto

VARCHARQ5)

NOT NULL,

Numero-projeto

INT

NOT NULL

LocaLprojeto

VARCHAR(15),

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 cm 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.

SQL básica

163

164

Sistemas de banco de dados

As relações declaradas por meio das instruções CREATE TABLE sào chamadas de tabelas de 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 cm 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(í,/) — em que f, 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 de 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 de dado de cadeia de caracteres de

3 Isso nào acontece com palavras-chave da SQL. como CREATE ou CHAR. Com as palavras-chave, a SQL c 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

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(n) — ou de tamanho variável — BIT VARYING(m), em que n é o número máximo de bits. O valor padrão para h, 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, B‘10101’.5 Outro tipo de dados de sequência dc bits de tamanho variável, cha­ 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 ser especificado em 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, em razão da presença dc valores NULL (nulos), uma lógica de 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 dc 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, e 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 caractere 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 c 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.

SQL básica

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 tipo 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 de dados para atributos quanto como a base para a criação de tabelas. Explicaremos esse comando em detalhes no Capítulo 12, pois normalmente é 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 de atributo e NULLs e 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 UPDATE CASCADE,

ON DELETE SET NULL

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 ripo 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 de 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 ser 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 ser 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.

s 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

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

171

b)

a)

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 f)

c)

Numero_projeto

DEPARTAMENTO. Numero_departamento

10

4

Cpf

Ultimo nome

Endereço

Nome departamento

Data nascimento

12345678966

Pesquisa

33344555587

F^squisa

99988777767

Pesquisa

98765432168

Pesquisa

6668S444476

Pesquisa

45345345376

Pesquisa

98798798733

Pesquisa

88866555576

Ftesquisa

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

12345678966

Matriz

33344555587

33344555587

Matriz

99988777767

99988777767

Matriz

98765432168

98765432168

Matriz

66688444476

66688444476

Matriz

45345345376

45345345376

Matriz

98798798733

98798798733

Matriz

88866555576

88866555576

Matriz

30

4

Souza

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

20-06-1941

Souza

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

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

e)

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

Wong

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) CIO. (g)C1C.

(continuação)

Cpf

Endereço

Sexo

Sal^rip

Cpf_supervisor

Numero departamento

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

30000

33344555587

5

40000

88866555576

5

38000

33344555587

5

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

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’.

C1: 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

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).

CT: 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;

SQL básica

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 referências à 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 de 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

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 normalmcnte 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 é 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.

SQL básica

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 em valores de 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 de 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)” e interseção de conjunto (INTERSECT). As relações resultantes dessas operações de conjunto são conjuntos de 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 Em alguns sistemas, a palavra chave MINUS é usada para a operação de diferença de conjunto, em vez de EXCEPT.

Capitulo 6

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

a1

a2

a2

a2

a1

a3

a2

a4

a2

a3

a5

a2

(b)

a2

(c)

(d)

T

a3

A

a4

ai

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

SQL básica

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 4______ ______ 5 com cada sublinhado servindo como um marcador de 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\%EF’ 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 (‘ ’) 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 projeto4 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 P.Nome.projeto = 'ProdutoX';

Para os tipos de dados dc cadeia, o operador dc concatcnação II pode ser usado em uma consulta para anexar dois valores de cadeia. Para tipos de dados date, rime, timestamp e interval, os operadores incluem incremento (+) ou decremento (-) 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 e hora. Outro

Capitulo 6

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 c 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. A 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

SQL básica

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, ires comandos podem ser 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 cm 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 de 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

VALUES

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

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

Os atributos não especificados cm 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 dc 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 Nu mero_departa mento = 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

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

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.) U2A:

INSERT INTO

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 em um projeto, podemos escrever as instruções cm U3A e U3B: U3A:

CREATE TABLE

(Nome.fundonario Nome_projeto Horas.semanal U3B:

INSERT INTO

SELECT FROM WHERE

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

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;

SQL básica

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

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-departa mento = 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 (/om), junções externas {outer joins)., instruções case e con­ sultas recursivas; visões (views)., 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 dc 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 c 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 de banco dc dados ativo, pois especificam

SQL básica

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 Server 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 de recuperação complexas; views; triggers e assertions; e comandos de modificação de esquema.

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

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 em 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?

6.1.

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

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 rodos os funcionários que são supervisionados direta­ mente por‘Fernando Wong’.

SQL básica

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

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.

SQL básica

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 também 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 rupia). 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 é 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. A Tabela 7.1 mostra os valores resultantes. Tabela 7.1 Conectivos

a)

lógicos na lógica de

AND

TRUE

FALSE

UNKNOWN

três valores.

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. 018: 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 convenientemente 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 cm 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 TRABALHAJM, FUNCIONÁRIO WHERE CpfJuncionario = 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

DISTINCT CpfJuncionario

FROM

TRABALHA.EM

WHERE

(Numero-projeto, Horas) IN

( SELECT FROM WHERE

Numero_projeto, Horas TRABALHA.EM CpfJuncionario = 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 TRABALHAJM 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 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 referência 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 rupia) 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.UItimo_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 teríamos 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, de 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 em 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:

FROM

F.Primeiro_nome, F.UItimo_nome FUNCIONÁRIO AS F

WHERE

EXISTS ( SELECT

SELECT

FROM

WHERE

DEPENDENTE AS D F.Cpf = D.CpfJuncionark) 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_funcionario. 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:

FROM

Primeiro_nome, Ultimo_nome FUNCIONÁRIO

WHERE

NOT EXISTS ( SELECT

SELECT

FROM

DEPENDENTE

WHERE

Cpf = C pf_fundone rio);

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_fundonerio 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.

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

Capítulo 7

C7:

SELECT Primeiro.nome, Ultimo.nome

FROM

FUNCIONÁRIO

WHERE EXISTS ( SELECT

FROM WHERE

DEPENDENTE Cpf = CpfJuncionario)

AND EXISTS ( SELECT FROM WHERE

DEPARTAMENTO 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.

Primeiro_nome, Ultimo_nome FROM FUNCIONÁRIO WHERE NOT EXISTS (( SELECT Numero_projeto

C3A: SELECT

FROM

PROJETO

WHERE Numero.departamento = 5)

Numero_projeto FROM TRABALHA.EM WHERE Cpf = Cpf.fundonario));

EXCEPT (SELECT

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 *

TRABALHA.EM AS B WHERE( B.NumerO-projeto IN (SELECT Numero_projeto FROM

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

TRABALHA_EM AS C

WHERE

CCpf_funcionario = Cpf

AND

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 em 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

DISTINCT Cpf.funcionário

FROM

TRABALHA-EM

WHERE

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

F.UItimo_nome AS Nome.funcionario, S.UItimo_nome AS Nome, supervisor

FROM

FUNCIONÁRIO AS F, FUNCIONÁRIO AS S

WHERE

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 de R eS. Cada par dc atributos desse tipo é incluído apenas uma vez na relação resultante (ver seções 8.3.2 e 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 cm C1 B,em que a relação DEPARTAMENTO é renomeada como DEP c 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 lnicio_gerente_dep. O significado da condição de 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, lnicio_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 dc 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_nasci mento ((PROJETO JOIN DEPARTAMENTO ON PROJETO.Numero_ departamento = DEPARTAMENTO.Numero_departamento) JOIN FUNCIONÁRIO ON Cpf.gerente = Cpf) LocaLprojeto = '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

F.UItimo_nome, S.UItimo_nome FUNCIONÁRIO F, FUNCIONÁRIO S ECpf.supervisor += 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 de dados, e apresentaremos seu uso na SQL por meio de exemplos. Existem diversas funções de agregação embutidas: COUNT, SUM. MAX. MIN e 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, respectivamente, 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 em uma cláusula HAVING (que apresentaremos mais adiante). As funções MAX e 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 wmj 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:

FROM

Ultimo_nome, Primeiro_nome FUNCIONÁRIO

WHERE

(SELECT

SELECT

FROM

WHERE

COUNT (* )

DEPENDENTE Cpf = Cpf.funcionário ) >= 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 uma 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 dc 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

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

Primeiro, nome

Nome, meio

Ultimo, nome

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

Salario

Cpf

Numero, departa­ mento

Cpf.supervisor

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

201

Numero de­ partamento

Count

5

4

33250

4

3

31000

1

1

55000

(*)

Avg (Salario)

Resultado de C24

Agrupamento de tuplas FUNCIONÁRIO pelo valor de Numero_departamento Nome_projeto

Numero, projeto

(b)

ProdutoX

Cpf_funcionario

Numero projeto

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

Horas

1

12345678966

1

32,5

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

ProdutoZ

3

33344555587

3

10,0

Informatização

10

33344555587

10

10,0

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

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

Nome_projeto

Numero_projeto

Cpf_funcionario

Numero projeto

Horas

ProdutoY

2

12345678966

2

7,5

ProdutoY

2

45345345376

2

ProdutoY

2

33344555587

Informatização

10

Informatização 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

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

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

FROM WHERE

GROUP BY

PROJETO.Numero_projeto, Nome_projeto, COUNT (*) PROJETO, TRABALHA.EM PROJETO.Numero_projeto = TRABALHA.EM. Numero.projeto 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:

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

FROM

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 e 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-.

GROUP BY

Numero_departamento, COUNT (*) FUNCIONÁRIO Salario>40000 Numero_departamento

HAVING

COUNTS) >5;

SELECT

FROM WHERE

Ela está incorreta porque selecionará somente departamentos que tenham mais de 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 (*)

FUNCIONÁRIO WHERE Salario>40000 AND Numero_departamento IN (SELECT Numero_departamento FROM FUNCIONÁRIO GROUP BY NumerO-departamento FROM

HAVING GROUP BY

)>5) * COUNT(

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': C28‘:

WITH

DEPARTAMENTO-GRANDE (Numero_departamento) AS (SELECT Numero.departamento FROM FUNCIONÁRIO GROUP BY Numero_departamento HAVING

)>5) * COUNT(

Numero_departamento, COUNT (*) FROM FUNCIONÁRIO WHERE Salario>40000 AND Numero_departamento IN DEPARTAMENTO.GRANDE GROUP BY Numero_departamento; SELECT

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 de 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 de funcionário (no papel de supervisionado) com outra tupla de 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

SUPERVISIONA_SUPERVISIONADO (Cpf_ supervisiona, Cpf_supervisionado) AS Cpf.supervisor, Cpf FUNCIONÁRIO

UNION SELECT

FROM WHERE

F.Cpf, S.Cpf.supervisiona FUNCIONÁRIO AS F, SUPERVISIONA, SUPERVISIONADO AS S F.Cpf_su pervisor = S. Cpf_su pervisionado)

* SELECT

FROM

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 econdição de grupo> 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 ser 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 dedarativas, usando o comando CREATE ASSERTION. Cada asserção recebe um nome dc restrição c é 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

WHERE

*

FUNCIONÁRIO F, FUNCIONÁRIO G, DEPARTAMENTO D F.Salario>G.Salario AND ENumerO-departa mento = D.Numero.de parlamento 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 dc seu supervisor direto no banco dc dados EMPRESA (ver figuras 5.5 c 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 é 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 é 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 dc 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 podem 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

V2:

CREATE VIEW AS SELECT

FROM WHERE GROUP BY

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; INFORMACAO_DEP(Nome_departamento, Quant_func, Total, sal) Nome.departamento, COUNT (*), SUM (Salario) DEPARTAMENTO, FUNCIONÁRIO DEPARTAMENTO.Numero.departamento = FUNCIONARIO.NumerO-departamento Nome.departamento;

6 Conforme usado em SQL, o termo 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

Total_sal

Figura 7.2 Duas visõ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 expliciramente novos nomes de atributo para a visão INFORMACAO-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 de 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) em 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 = CpfJuncionario AND TRABALHA_EM.Numero_projeto = PROJETO.Numero_projeto AND Nome_projeto = 'ProdutoX';

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 de 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 geralmente é 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_EM1 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 =

(SELECT

FROM WHERE WHERE

Cpf.funcionario IN

( SELECT

FROM WHERE

Numero-projeto PROJETO Nome.projeto = 'ProdutoY') Cpf FUNCIONÁRIO Ultimo_nome = 'Silva' AND Primeiro.nome = 'João')

AND

Numero_projeto =

WHERE

Numero_projeto PROJETO Nome.projeto = 'ProdutoX');

SET

Nome.projeto = 'ProdutoY'

( SELECT

FROM

(b)

UPDATE PROJETO

WHERE

Nome_projeto = ProdutoX';

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 dc 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 geralmenre 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 todos 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 fina) 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

FUNCDEP5

AS

SELECT FROM

WHERE

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 recoinpilaçã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 de 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 ser 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 atrioutos>

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; c. 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 dc visão c 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 c SQL 2008 — são descritos cm diversos rela­ tórios técnicos, mas não existem rcferências-padrão.

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 declaratiia 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 c 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 dc tuplas — aquelas que satisfazem a condição c 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: ^^.oepana^oJFUNCIONARIO)

a^^FUNCIONARIO) Em geral, a operação SELEÇÃO é indicada por ^concição de se eçá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> «cnome atributo> cm que é o nome de um atributo de R, em geral é um dos operadores (=, , >, * ) e «cvalor constanto é 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_0epaftaniena>=4 AND Saiana>2500Q OR iNumero-OepartafnentosS 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 ífAJ. 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 condi) é 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

Fernando

T

Wong

33344555587

08-12-1955

Jennifer

S

Souza

98765432168

20-06-1941

Ronaldo

K

Lima

66688444476

15-09-1962

nome

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

c)

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) c uma lista dc pares ( ). Em cada par desse tipo, é uma das funções permitidas — como SUM, AVG, MAX, MIN, COUNT— e é um atributo da relação especificada por R. relação resultante tem os atributos de agrupamento mais um atributo para cada elemento na lista de funções. Por exemplo, para recuperar cada número de departamento, o número de funcionários no departamento e seu salário medio, enquanto renomeia os atributos resultantes como indicado a seguir, escrevemos: P ^:Dnumero. Total.funoonanos, Mecia.sai: ^Numero.departamentoCOUNT Cpf. AVG Salano (FUNCIONÁRIO))

O resultado dessa operação sobre a relação FUNCIONÁRIO da Figura 5.6 é exibido na Figura 8.10(a). No exemplo anterior, especificamos uma lista de nomes dc atributo — entre parênteses na operação RENOMEAR — para a relação resultante R. Se não houver renomeação, os atributos da relação resultante que correspondem à lista de funções serão a concatcnação do nome da função com o nome do atributo, na forma _.s Por exemplo, a Figura 8.10(b) mostra o resultado da seguinte operação: Numero-departarrentoCOUNTCpf. AVGSaiano^UNCIONARIO)

Se nenhum atributo de agrupamento for especificado, as funções são aplicadas a todas as tuplas na relação, de modo que a relação resultante tenha apenas unia única tupla. Por exemplo, a Figura 8.10(c) mostra o resultado da seguinte operação: count cpf. avg JUNCIONARIO)

b)

(a) Total funcioná­

Media

Numero.departa­

rios

sal

mento

5

4

33250

4

3

1

1

Dnumero

COUNT.Cpf

AVG.Salario

5

4

33250

31000

4

3

31000

55000

1

1

55000

Figura 8.10 A operação de função agregada.

(C) COUNT.Cpf

AVG.Salario

8

35125

P^(Dnumefo. Totaljunocnaoos. Media_sai; Numero.depanamerto

COUNT

Cpf.AVGSalano(FUNCIONARIO)). b- Numera_depdrtdrnento

COUNT Cpf. AVG Salanc^UNClONARIO).

c- * countcpf.AVG JUNCIONARIO).

7 Não existe uma única notação combinada para especificar funções de agregação. Em alguns casos é usado um ‘script A’.

8 Observe que esta é uma notação arbitrária, consistente com o que a SQL faria.

239

240

Sistemas de banco de dados

É importante observar que, em geral, as duplicatas nào são eliminadas quando uma função de agregação é aplicada; desse modo, a interpretação normal de funções como SUM e AVG é calculada.9 No entanto, valores NULL não são considerados na agregação, conforme discutimos na Seção 7.1.7. Vale a pena enfatizar que o resul­ tado de aplicar uma função de agregação é uma relação, e não um número escalar — mesmo que ele tenha um único valor. Isso torna a álgebra relacionai um sistema matemático fechado.

8.4.3 Operações de fechamento recursive Outro tipo de operação que, em geral, não pode ser especificado na álgebra relacionai original básica é o fechamento recursivo. Essa operação é aplicada a um relacionamento recursivo entre tuplas do mesmo tipo, como o relacionamento entre um funcionário e um supervisor. Esse relacionamento é descrito pela chave estrangeira Cpf_supervisor da relação FUNCIONÁRIO nas figuras 5.5 e 5.6, e relaciona cada tupla de funcionário (no papel de supervisionado) a outra tupla de funcionário (no papel de supervisor). Um exemplo de operação recursiva é recuperar todos os supervisionados de um funcionário /em todos os níveis — ou seja, todos os funcionários f supervi­ sionados diretamente por /, todos os funcionários f" supervisionados diretamente por cada funcionário /', todos os funcionários /'"supervisionados diretamente por cada funcionário /", e assim por diante. Na álgebra relacionai, é relarivamente simples especificar rodos os funcionários supervisionados por fem um nível específico juntando uma ou mais vezes a própria tabela. Porém, é difícil especificar todos os supervisionados em todos os níveis. Por exemplo, para especificar os Cpfs de todos os funcionários /’ supervisionados diretamente — no nível um — pelo funcionário /cujo nome é ‘Jorge Brito’ (ver Figura 5.6), podemos aplicar a seguinte operação:

CPF-BRITO w andUiúno nomeio- (FUNCIONÁRIO)) SUPERVISAO(Cpf1, Cpf2) ()

); 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) e para instruções dc looping. Estas darão uma ideia do tipo dc 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 ã SQI7PSM 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 TotaLdeJuncs é 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 DO clista de instruções> 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.deJunes > 100 THEN RETURN " ENORME"

6)

ELSEIF TotaLdeJuncs > 25 THEN RETURN “GRANDE “

7)

ELSEIF TotaLdeJuncs > 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 dc 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 de 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 de 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 dc 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 de banco de dados relacionai de biblioteca da Figura 6.6. Escreva um segmento dc programa que rccupcrc a lista dc livros que ficaram cm atraso ontem e que imprima o título do livro e o nome de 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 dc 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 intcrprctadorcs 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 c 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 Xlac OS, o interpretador PHP pode ser baixado em



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 poderia 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 X.ML 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), permite o processamento dc documentos XML no ato ao notificar o programa dc 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 c permite o processamento dos chamados documentos XML de streaming, em que o programa dc processamento pode processar as tags à medida que forem encontradas. Isso também é conhecido como processamento baseado cm evento. Também existem outros processadores especializados que trabalham com diversas linguagens de programação e scripring para analisar documentos XML. Um documento X.ML 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 dc elemento usados nos pares de tag dc início c dc fim devem seguir a estru­ tura especificada em 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) cIDOCTYPE Projetos l

Figura 13.4 (a) Um

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) cIDOCTYPE Empresai clELEMENT Empresa((Departamento|Funcionario|Projeto) *)> clELEMENT Departamento (Nome_dep, Localizacao+)>

clATTUST Departamento Code.dep ID #REQUIRED> clELEMENT Funcionário (Nomejunc, Cargo, Salario)>

clATTUST Funcionário CodeJune ID «REQUIRED Code.dep IDREF #REQUIRED> clELEMENT Projeto (Nome_proj, Localizacao)

clATTUST Projeto Code_proj ID «REQUIRED Trabalhadores IDREFS #IMPLIED>

clELEMENT Nome.de p (#PCDATA)> clELEMENT Nomejunc (#PCDATA)> clELEMENT Nome_proj (#PCDATA)> clELEMENT Cargo (#PCDATA) clELEMENT Localizacao (#PCDATA)> clELEMENT Salario (#PCDATA)>

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ó folha. 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 (ej I e-,) 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 cm 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, Codejunc 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 dc 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 DI D 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 de 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.

Figura 13.5 Um arquivo

em XML schema chamado

Esquema Empresa (Definição Elemento) -

Criado por Babak

Hojabri





























Y, entre dois conjun­ tos dc atributos X e Y que são subconjuntos dc R, especifica uma restrição sobre possíveis tuplas que podem formar um estado de relação r dc R. A restrição c que, para quaisquer duas tuplas e í2 em r que tenham íJX] = f,[X], elas também devem teríl[Y] = í2[Y]. Isso significa que os valores do componente Y de uma tupla em r dependem dos (ou são determinados pelos) valores do componente X; como alternativa, os valores do componente X dc uma tupla determinam exclusivamente (ou funcionalmentc) os valores do componente Y. Também dizemos que existe uma dependência funcio­ nal de X para Y, ou que Y é funcionalmente dependente de X. A abreviação para dependência funcional é DF ou d.f. O conjunto de atributos X é chamado de lado esquerdo da DF, e Y é chamado dc lado direito. Assim, a funcionalidade X determina Y cm um esquema dc relação R se, c somente se, sempre que duas tuplas dc r(R) combinarem sobre seu valor X, elas devem neces­ sariamente combinar sobre seu valor Y. Observe o seguinte: ■ Se uma restrição sobre R declarar que não pode haver mais de uma tupla com determinado valor X em qualquer instância de relação r(R) — ou seja, X é uma chave candidata dc R —, isso implica que X > Y para qualquer subconjunto de atributos Y de R (porque a restrição de chave implica que duas tuplas em qualquer estado válido r(R) não terão o mesmo valor de X). Se X for uma chave candidata de R, então X * - R. ■ Se X —* Y em R, isso não quer dizer que Y —* X em R.

Uma dependência funcional c uma propriedade da semântica ou significado dos atributos. Os projetistas dc banco dc dados usarão seu conhecimento da semântica dos atributos de R — ou seja, como eles se relacionam entre si — para especificar as dependências funcionais que devem ser mantidas em todos os estados de relação (extensões) r de R. As extensões de relação r(R) que satisfazem as restrições de dependência funcional são chamadas de estados de relação válidos (ou extensões válidas) de R. Logo, o uso principal das dependências funcionais é para descrever melhor um esquema de relação R ao especificar restrições sobre seus atributos que devem ser mantidas o tempo todo. Certas DFs podem ser especificadas sem que se refiram a uma relação específica, mas como uma propriedade desses atributos, dado

~ Esse conceito de uma relação universal será importante quando discutirmos os algoritmos para o

projeto de banco de dados relacionai no Capítulo 15.

s Esta suposição implica que cada atributo no banco dc dados tenha um nome distinto. No Capítulo 5, finalizamos os nomes de atributo com nomes de relação, para obter exxlusividade sempre que os atri­ butos em relações distintas tinham o mesmo nome.

427

428

Sistemas de banco de dados

seu significado comumenre entendido. Por exemplo, (Estado, Num_habilitacao) —> Cpf deve ser mantido para qualquer adulto no Brasil e, por isso, mantido sempre que esses atributos aparecerem em uma relação.9 Também é possível que cerras dependências funcionais possam deixar de existir no mundo real se o relacionamento mudar. Por exemplo, a DF Cep —* Codigo.area costumava existir como um relacionamento entre os códigos postais e os códigos de área telefônicos no Brasil, mas, com a proliferação dos códigos de área telefônicos, isso não é mais verdadeiro. Considere o esquema de relação FUNCIONARIO.PROJETO da Figura 14.3(b). Pela semântica dos atributos e da relação, sabemos que as seguintes dependências fun­ cionais devem ser mantidas: a. Cpf > Nome.funcionario

b. Numero.projeto —* {Nome.projeto, LocaLprojeto) c. {Cpf, Numero-projeto) —* Horas Essas dependências funcionais especificam que (a) o valor do número do Cadastro de Pessoa Física (Cpf) de um funcionário determina exclusivamente o nome do fun­ cionário (Nome.funcionario), (b) o valor do número de um projeto (Numero_projeto) determina exclusivamente o nome do projeto (Nome_projeto) e seu local (LocaLpro­ jeto) e (c) uma combinação de valores de Cpf e Numero.projeto determina exclusi­ vamente o número de horas que o funcionário trabalha atualmente no projeto por semana (Horas). Como alternativa, dizemos que Nome.funcionario é determinado de maneira funcional por (ou dependente funcionalmente de) Cpf, ou dado uni valor de Cpf, sabemos o valor de Nome.funcionário, e assim por diante. Uma dependência funcional é uma propriedade do esquema de relação R, e não um estado de relação válido e específico r de R. Portanto, uma DF não pode ser deduzida automaticamente por determinada extensão de relação r, mas deve ser defi­ nida de maneira explícita por alguém que conhece a semântica dos atributos de R. Por exemplo, a Figura 14.7 mostra um estado em particular do esquema de relação ENSINA. Embora à primeira vista possamos pensar que Livro.texto —* Disciplina, não podemos confirmar isso, a menos que saibamos que é verdadeiro para todos os estados válidos possíveis de ENSINA. No entanto, é suficiente demonstrar um único contraexemplo para refutar uma dependência funcional. Por exemplo, como ‘Silva’ leciona tanto ‘Estruturas de Dados' quanto ‘Gerenciamento de Dados', podemos concluir que o Professor não determina funcionalmente a Disciplina. Dada uma relação preenchida, não se podem determinar quais DFs são mantidas e quais não são, a menos que o significado e os relacionamentos entre os atribu­ tos sejam conhecidos. Tudo o que se pode dizer é que certa DF pode existir se for mantida nessa extensão em particular. Não se pode garantir sua existência até que Figura 14.7 Um estado de

ENSINA

relação de ENSINA com uma Professor

possível dependência funcional

Disciplina

Livro.texto

LIVRO.TEXTO — DISCIPLINA.

Silva

Estruturas de Dados

Bartram

Porém, PROFESSOR ->

Silva

Gerenciamento de Dados

Martin

Neto

Compiladores

Hoffman

Braga

Estruturas de Dados

Horowitz

DISCIPLINA, LIVRO.TEXTO -> PROFESSOR e DISCIPLINA

»

LIVRO.TEXTO estão excluídos.

9 Observe que existem bancos de dados, como os de companhias de cartão de crédito ou departa­

mentos dc policia, cm que essa dependência funcional pode não scr mantida, cm virtude dc registros fraudulentos resultantes do mesmo número de carteira de habilitação sendo usado por dois ou mais indivíduos diferentes.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

429

o significado dos atributos correspondentes seja claramente compreendido. Porém, pode-se afirmar de modo enfático que certa DF nào se mantém se houver tuplas que mostrem a violação de tal DE Veja a relação de exemplo ilustrativa na Figura 14.8. Nela, as DFs a seguir podem ser mantidas porque as quatro tuplas na extensão atual não têm violação dessas restrições: R —♦ C; C —♦ R; (A, B) —> C; {4, B) —* D; e (C, D) —> B. No entanto, as seguintes nào se mantêm porque já temos violações delas na extensão dada: A —» B (as tuplas 1 e 2 violam essa restrição); B —> A (as tuplas 2 e 3 violam essa restrição); D —* C (as tuplas 3 e 4 a violam). A Figura 14.3 apresenta uma notação diagramática para exibir DFs: cada DF aparece como uma linha horizontal. Os atributos do lado esquerdo da DF são conectados por linhas verticais à linha que representa a DF, enquanto os atributos do lado direito são conectados pelas linhas com setas que apontam para os atributos. 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 semanticamente óbvias. Porém, diversas outras dependências funcionais se mantêm em todas as instâncias de relação válidas entre conjuntos de atributos que podem ser derivados das (e satisfazem as) dependências em F. Essas outras dependências podem ser deduzidas das DFs em F. Deixaremos os detalhes das regras dc inferência e propriedades das dependências funcionais para o Capítulo 15. A

B

C

D

Figura 14.8 Uma relação /?(A, B, C, D) com sua extensão.

a1

bl

C1

d1

a1

b2

c2

d2

a2

b2

c2

d3

a3

b3

c4

d4

14.3 Formas normais baseadas em chaves primárias Após introduzir as dependências funcionais, agora estamos prontos para a espe­ cificação dc como desenvolver uma metodologia formal para teste c melhoria dos esquemas dc relação. Consideramos que um conjunto de dependências funcionais é dado para cada relação e que cada relação tem uma chave primária designada. Essa informação, combinada com os restes (condições) para formas normais, controla o processo de normalização para o projeto do esquema relacionai. A maioria dos projetos relacionais práticos assume uma das duas técnicas a seguir: ■ Realiza um projeto dc esquema conceituai usando um modelo conceituai como ER ou EER e mapeia o projeto conceituai para um conjunto de relações. ■ Projeta as relações com base no conhecimento externo derivado dc uma imple­ mentação existente dc arquivos, formulários ou relatórios.

Ao seguir uma dessas técnicas, é útil avaliar a virtude das relações e decompô-las ainda mais, conforme a necessidade, para obter formas normais mais altas, usando a teoria dc normalização apresentada neste capítulo e no seguinte. Nesta seção, foca­ lizamos as três primeiras formas normais para esquemas de relação e a intuição por trás delas, e discutimos como elas foram desenvolvidas historicamente. Definições mais gerais dessas formas normais, que levam em conta todas as chaves candidatas de uma relação em vez de apenas a chave primária, sào adiadas para a Seção 14.4. Começamos discutindo informalmente as formas normais c a motivação por trás dc seu desenvolvimento, bem como revisando algumas definições do Capítulo 5, que

430

Sistemas de banco de dados

são necessárias aqui. Depois, discutimos a primeira forma normal (1FN) na Seção 14.3.4, e apresentamos as definições da segunda forma normal (2FN) e da terceira forma normal (3FN), que são baseadas em chaves primárias, nas seções 14.3.5 e 14.3.6, respecrivamente.

14.3.1 Normalização de relações O processo de normalização, proposto inicialmente por Codd (1972a), leva um esquema de relação por uma série de testes para certificar se ele satisfaz certa forma normal. O processo, que prossegue em um padrão de cima para baixo, avaliando cada relação em comparação com os critérios para as formas normais e decompondo as relações conforme a necessidade, pode assim ser considerado projeto relacionai por análise. Inicialmente, Codd propôs três formas normais, que ele chamou dc primeira, segunda e terceira forma normal. Uma definição mais forte da 3FN — chamada Forma Normal de Boyce-Codd (FNBC) — foi proposta posteriormente por Boyce e Codd. Todas essas formas normais estão fundamen­ tadas em uma única ferramenta analítica: as dependências funcionais entre os atributos de uma relação. Depois, uma quarta forma normal (4FN) e uma quinta forma normal (5FN) foram propostas, com base nos conceitos de dependências multivaloradas e dependências dc junção, rcspcctivamcntc: estas serão discutidas rapidamente nas seções 14.6 e 14.7. A normalização de dados pode ser considerada um processo de analisar os esque­ mas de relação dados com base em suas DFs e chaves primárias para conseguir as propriedades desejadas de (1) minimização da redundância c (2) minimização das anomalias dc inserção, exclusão c atualização discutidas na Seção 14.1.2. Esse pode ser considerado um processo de “filtragem" ou “purificação”, para fazer com que o projeto tenha uma qualidade cada vez melhor. Esquemas de relação insatisfatórios, que não atendem a certas condições para uma forma normal — os testes de forma normal —, são decompostos em esquemas de relação menores, que contêm um subconjunto dos atributos e que atendem ao teste que, dc outra maneira, não era atendido pela relação original. Assim, o procedimento de normalização oferece aos projetistas de banco de dados o seguinte: ■ Uma estrutura formal para analisar esquemas de relação com base em suas chaves e nas dependências funcionais entre seus atributos. ■ Uma série de testes de forma normal que podem ser executados em esquemas de relação individuais, dc modo que o banco dc dados relacionai possa ser norma­ lizado para qualquer grau desejado.

Definição. A forma normal de uma relação rcferc-sc à condição dc forma normal mais alta a que ela atende e, portanto, indica o grau ao qual ela foi normalizada. As formas normais, quando consideradas isoladamente de outros fatores, não garantem um bom projeto de banco de dados. Em geral, não é suficiente verificar em separado se cada esquema de relação no banco de dados está, digamos, na FNBC ou na 3FN. Em vez disso, o processo de normalização pela decomposição também precisa confirmar a existência de propriedades adicionais que os esquemas relacio­ nais, tomados juntos, devem possuir. Estas incluiriam duas propriedades: ■ A propriedade de junção não aditiva ou junção sem perdas, que garante que o problema dc geração dc tuplas falsas, discutido na Seção 14.1.4, não ocorra com relação aos esquemas de relação criados após a decomposição. ■ A propriedade dc preservação dc dependência, que garante que cada dependên­ cia funcional seja representada cm alguma relação individual resultante após a decomposição.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

A propriedade de junção não aditiva é extremamente crítica e deve ser alcançada a todo custo, ao passo que a propriedade de preservação de dependência, embora desejável, às vezes é sacrificada, conforme discutiremos na Seção 15.2.2. Adiaremos para o Capítulo 15 a apresentação de conceitos e técnicas formais que garantem as duas propriedades citadas.

14.3.2 Uso prático das formas normais A maioria dos projetos práticos nos ambientes comercial e governamental adquire projetos existentes dc bancos de dados anteriores, projetos cm modelos legados ou de arquivos existentes. Eles certamente estão interessados em garantir que os projetos tenham boa qualidade e sejam sustentáveis por longos períodos. Os projetos exis­ tentes são avaliados aplicando-se os testes para formas normais, e a normalização é executada na prática, dc modo que os projetos resultantes sejam de alta qualidade c atendam às propriedades desejáveis indicadas anteriormente. Embora várias formas normais mais altas tenham sido definidas, como a 4FN e a 5FN, que discutiremos nas seções 14.6 e 14.7, a utilidade prática dessas formas normais torna-se questionável quando as restrições sobre as quais elas estão baseadas são raras e difíceis de entender ou detectar pelos projetistas e usuários de banco de dados. Projetistas e usuários precisam já conhecê-las ou descobrir a respeito delas como parte de negócio. Assim, o projeto de banco de dados praticado na indústria hoje presta atenção particular à normalização apenas até a 3FN, FNBC ou, no máximo, 4FN. Outro ponto que merece ser observado é que os projetistas de banco de dados nào precisam normalizar para a forma normal mais alta possível. As relações podem ser deixadas cm um estado dc normalização inferior como 2FN, por questões de desempenho, como as discutidas ao final da Seção 14.1.2. Fazer isso gera as pena­ lidades correspondentes de lidar com as anomalias. Definição. Dcsnormalização é o processo de armazenar a junção dc relações na forma normal mais alta como uma relação básica, que está em uma forma normal mais baixa.

14.3.3 Definições de chaves e atributos participantes em chaves Antes dc prosseguirmos, vejamos novamente as definições de chaves dc um esquema de relação do Capítulo 5. Definição. Uma superchave de um esquema de relação R = {Aj, A2,..., An) é um conjunto dc atributos 5 Ç R com a propriedade dc que duas tuplas e t2 cm qual­ quer estado dc relação válido r dc R não terão ZjS] = í,[S). Uma chave Ch é uma superchave com a propriedade adicional de que a remoção de qualquer atributo de Ch fará com que Ch não seja mais uma superchave. A diferença entre uma chave c uma superchave é que a primeira precisa ser mínima-, ou seja, se tivermos uma chave Ch = {Aj, A2, ..., Ak} de R, então Ch - {AJ não é uma chave de R para qualquer A:, 1 < i < k. Na Figura 14.1, {Cpf) é uma chave para FUNCIONÁRIO,enquanto (Cpf), {Cpf, Nomejundonario), {Cpf, Nomejundonario, Data. nascimento) e qualquer conjunto de atributos que inclua Cpf são todos superchaves. Se um esquema de relação tiver mais de uma chave, cada uma é chamada de chave candidata. Uma das chaves candidatas é arbitrariamente designada para ser a chave primária, e as outras são chamadas de chaves secundárias. Na prática, em um banco de dados relacionai, cada esquema de relação precisa ter uma chave primária. Se nenhuma chave candidata for conhecida para uma relação, a relação inteira pode ser tratada como uma superchave padrão. Na Figura 14.1, {Cpf) é a única chave candidata para FUNCIONÁRIO, de modo que também é a chave primária.

431

432

Sistemas de banco de dados

Definição. Um atributo do esquema de relação R é chamado de atributo principal de R se ele for um membro de alguma chave candidata de R. Um atributo é chamado nào principal se não for um atributo principal — ou seja, se não for um membro de qualquer chave candidata. Na Figura 14.1, tanto Cpf quanto Numero_projeto sào atributos principais de TRABALHAJEM, ao passo que outros atributos de TRABALHA_EM sào não principais. Agora, vamos apresentar as três primeiras formas normais: 1FN, 2FN e 3FN. Elas foram propostas por Codd (1972a) como uma sequência para conseguir o estado desejável de relações 3FN ao prosseguir pelos estados intermediários de 1FN e 2FN, se necessário. Conforme veremos, 2FN e 3FN atacam diferentes tipos de problemas que aparecem por dependências funcionais problemáticas entre os atri­ butos. Contudo, por motivos históricos, é comum segui-los nessa sequência. Logo, por definição, uma relação 3FN já satisfaz 2FN.

14.3.4 Primeira forma normal A primeira forma normal (1FN) agora é considerada parte da definição formal de uma relação no modelo relacionai básico (plano). Historicamente, ela foi definida para reprovar atributos mui rival orados, atributos compostos e suas combinações. Ela afirma que o domínio de um atributo deve incluir apenas valores atômicos (simples, indivisíveis) e que o valor de qualquer atributo em uma tupla deve ser um único valor do domínio desse atributo. Logo, 1FN reprova ter um conjunto de valores, uma tupla de valores ou uma combinação de ambos como um valor de atributo para uma única tupla. Em outras palavras, a 1FN reprova relações dentro de relações ou relações como valores de atributo dentro de tuplas. Os únicos valores de atributo permitidos pela 1FN são os valores atômicos (ou indivisíveis). Considere o esquema de relação DEPARTAMENTO da Figura 14.1, cuja chave primária é Numero_departamento,e suponha que a estendamos ao incluir o atributo Localizacoes_departamento, conforme mostra a Figura 14.9(a). Supomos que cada departamento pode ter certo número de locais. O esquema DEPARTAMENTO e um exemplo de estado de relação são mostrados na Figura 14.9. Como podemos vei; este não está em 1FN porque Localizacoes_departamento não é um atributo atômico, conforme ilustrado pela primeira tupla na Figura 14.9(b). Existem duas maneiras possíveis para examinar o atributo Localizacoes.departa mento:

■ O domínio de Localizacoes_departamento contém valores atômicos, mas algumas tuplas podem ter um conjunto desses valores. Nesse caso, Localizacoes_departamento não é funcionalmente dependente da chave primária Numero_departamento. ■ O domínio de Localizacoes_departamento contém conjuntos de valores e, portanto, é não atômico. Nesse caso, Numero_departamento —*■ Localizacoes.departamento, pois cada conjunto é considerado um único membro do domínio de atributo.10

De qualquer forma, a relação DEPARTAMENTO da Figura 14.9 não está na 1FN; de fato, ela nem sequer se qualifica como uma relação, de acordo com nossa defini­ ção na Seção 5.1. Existem três técnicas principais para conseguir a primeira forma normal para tal relação: 1. Remover o atributo Localizacoes_departamento que viola a 1FN e colocá-lo em uma relação separada LOCALIZACOES_DEPARTAMENTO, com a chave primá­ ria Numero_departamento de DEPARTAMENTO. A chave primária dessa relação

10 Neste caso, podemos considerar o domínio dc Localizacoes_departarnento como o conjunto dc po­ tência do conjunto de locais isolados; ou seja, o domínio é composto por todos os subconjuntos possí­

veis do conjunto de locais isolados.

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

433

(a)

Figura 14.9 Normalização

DEPARTAMENTO

na 1FN. (a) Um esquema de

Nome departamento | Numero.departa mento | Cpf qerente

Localizacoes departamento

I—_1_____ *

t_________________

relação que não está em 1FN. (b) Exemplo de estado da

relação DEPARTAMENTO, (c)

Versão 1FN da mesma relação

(b)

com redundância.

DEPARTAMENTO Numero departamento

Cpf gerente

Localizacoes-departamento

Pesquisa

5

33344555587

{Santo André, Itu, São Paulo}

Administração

4

98765432168

{Mauá}

Matriz

1

88866555576

{São Paulo}

Nome departamento

(c)

DEPARTAMENTO Nome departamento Numero departamento

Cpf ge rente

Loca l.departamento

Pesquisa

5

33344555587

Santo André

Pesquisa

5

33344555587

Itu

Pesquisa

5

33344555587

São Paulo

Administração

4

98765432168

Mauá

Matriz

1

88866555576

São Paulo

recém-form ada é a combinação {Numero_departamento, Local_departamento|, como mostra a Figura 14.2. Existe uma tupla distinta em LOCALIZACOES_ DEPARTAMENTO para cada local de um departamento. Isso decompõe a relação não 1FN em duas relações 1FN.

2. Expandir a chave dc modo que haverá uma tupla separada na relação original DEPARTAMENTO para cada local de um DEPARTAMENTO, como mostra a Figura 14.9(c). Neste caso, a chave primária torna-se a combinação |Numero_departamento, Local_departamento|. Essa solução tem a desvantagem de introduzir a redundância na relação e, portanto, raramente é adotada. 3. Se o número máximo de valores for conhecido para o atributo — por exemplo, se for conhecido que poderão existir no máximo três locais para um departamento —, substituir o atributo Localizacoes.departamento pelos três atributos atômicos: Local 1, Local2 e Local3. Esta solução tem a desvantagem de introduzir valores NULL se a maioria dos departamentos tiver menos de três locais. Ela ainda introduz uma falsa semântica sobre a ordenação entre os valores de local, o que não era intencionado originalmente. A consulta sobre esse atributo torna-se mais difícil. Por exemplo, considere como você escrevería a consulta: Listar os departamentos que têm 'Santo André' como um de seus locais nesse projeto. Por todos esses motivos, é melhor evitar esta alternativa. Das três soluções anteriores, a primeira geralmente é considerada a melhor, pois não sofre de redundância e é completamente genérica, não tendo limite imposto sobre o número máximo de valores. De fato, se escolhermos a segunda solução, ela será decomposta ainda mais durante as etapas de normalização subsequentes, para voltar à primeira solução. A primeira forma normal também desaprova atributos multivalorados que por si só sejam compostos. Estes são chamados de relações aninhadas, pois cada tupla pode ter uma relação dentro dela. A Figura 14.10 mostra como a relação FUNCIONARIO_ PROJETO poderia aparecer se o aninhamento fosse permitido. Cada tupla representa uma entidade de funcionário, e a relação PROJETOS(Numero_projeto, Horas) dentro de cada tupla representa os projetos do funcionário e o número de horas por semana

434

Sistemas de banco de dados

Figura 14.10 Normalizando

relações aninhadas para a

(a) FUNCIONARIO.PROJETO

Projetos

1FN. (a) Esquema da relação

FUNCIONARIO.PROJETO com um atributo de relação

aninhada PROJETOS, (b) Exemplo de extensão da relação FUNCIONÁRIO.

PROJETO mostrando relações

Cpf

Nome.funcionario

Numero-projeto

Horas

(b) FUNCIONARIO.PROJETO Nome.funcionario

Cpf

12345678966

Numero.projeto

Horas

1

32,5

2

7,5

Silva, João B.

aninhadas dentro de cada tupla. (c) Decomposição de

FUNCIONARIO.PROJETO

66688444476

Uma, Ronaldo K.

3

40,0

nas relações FUNCIONÁRIO.

45345345376

Leite, Joice A.

1

20,0

2

20,0

2

10,0

3

10,0

10

10,0

20

10,0

30

30,0

10

10,0

10

35,0

30

5,0

30

20,0

20

15,0

20

NULL

PROJET01 e FUNCIONÁRIO. PR0JET02 pela propagação da

chave primária.

33344555587

99988777767

98798798733

98765432168

88866555576

Wong, Fernando T.

Zelaya, Alice J.

Pereira, André V.

Souza, Jennifer S.

Brito, Jorge E.

(c)

FUNCIONÁRIO PROJET01 Cpf

Nome.funcionario

FUNCIONÁRIO PR0JET02

Cpf

Numero projeto

Horas

que ele trabalha em cada projeto. O esquema dessa relação FUNCIONARIO.PROJETO pode ser representado da seguinte forma: FUNCIONARIO_PROJETO(Cpf, Nome.funcionario, {PROJETOSfNumero.projeto, Horas)))

O conjunto de chaves { ) identifica o atributo PROJETOS como multivalorado, e listamos os atributos componentes que formam o PROJETOS entre parênteses ( ). O interessante é que as tendências recentes para dar suporte a objetos complexos (ver Capítulo 12) e dados XML (ver Capítulo 13) tentam permitir e formalizar as rela­ ções aninhadas nos sistemas de bancos de dados relacionais, que eram inicialmente reprovadas pela 1FN. Observe que Cpf é a chave primária da relação FUNCIONARIO.PROJETO nas figuras 14.10(a) e (b), enquanto Numero.projeto é a chave parcial da relação aninhada; ou seja, dentro de cada tupla, a relação aninhada precisa ter valores únicos de Numero_projeto. Para normalizar isso para a 1FN, removemos os atributos da relação aninhada para uma nova relação c propagamos a chave primária para ela. A chave primária da nova relação combinará a chave parcial com a chave primária da relação ori­ ginal. A decomposição e a propagação da chave primária resultam nos esquemas FUNCIONARIO.PROJETOl e FUNCI0NARI0_PR0JET02,como mostra a Figura 14.10(c).

Capitulo 14

Fundamentos de dependências funcionais e normalização para bancos de dados relacionais

Esse procedimento pode ser aplicado recursivamente a uma relação com aninhamento em nível múltiplo para desaninhar a relação para um conjunto de relações 1FN. Isso é útil na conversão de um esquema de relação não normalizado com muitos níveis de aninhamento em relações 1FN. Como um exemplo, considere o seguinte: CANDIDATO (Cpf, Nome, {HISTORICO.EMPREGO (Empresa, Maior.cargo, {HISTORICO_SALARIO (Ano, Salario_maximo)})}) Este exemplo descreve dados sobre candidatos a emprego com seus históricos de emprego sendo uma relação aninhada dentro da qual o histórico de salários está armazenado como uma relação aninhada mais profundamente. A primeira norma­ lização usando chaves parciais internas Empresa e Ano, respectivamente, resulta nas seguintes relações 1FN:

CANDIDATO-1 (Cpf, Nome) CANDIDATO_HISTORICO_EMPREGO (Cof, Empresa, Maior.cargo) CANDIDATO_HISTORICO_SALARIO (Cpf, Empresa, Ano, Salario.maximo) A existência de mais de um atributo multivalorado em uma relação deve ser tratada com cuidado. Como um exemplo, considere a seguinte relação não 1FN:

PESSOA (Cpf, {Placa), {Telefone))

Essa relação representa o fato de uma pessoa ter vários carros e vários telefones. Sc a estratégia 2 acima for seguida, ela resulta cm uma relação com todas as chaves:

PESSOA_NA_1FN (Cpf, Placa, Telefone) Para evitar a introdução de qualquer relacionamento estranho entre Placa e Telefone, todas as combinações dc valores possíveis são representadas para cada Cpf, fazendo surgir a redundância. Isso leva aos problemas que normalmentc são descobertos em um estágio posterior da normalização, e que são tratados pelas dependências multivaloradas e 4FN, explicadas na Seção 14.6. O modo certo de lidar com os dois atributos multivalorados cm PESSOA mostrados anteriormente é decompô-los cm duas relações separadas, usando a estratégia 1 já discutida: P1 (Cpf. Placa) e P2(Çpf. Telefone). Vejamos agora um detalhe sobre as relações que envolvem atributos que vão além de apenas dados numéricos e de cadeia de caracteres. Nos bancos de dados atuais, está se tornando comum incorporar imagens, documentos, clipes de vídeo, clipes de áudio e outros elementos de multimídia. Quando estes são armazenados em uma relação, o objeto ou arquivo inteiro é tratado como um valor indivisível, que é armazenado como um tipo de dado BLOB (objeto binário grande) ou CLOB (objeto de caracteres grande) usando SQL. Para rodos os fins práticos, o objeto é tratado como um atributo atômico, de único valor, e, portanto, mantém o status de 1FN da relação.

14.3.5 Segunda forma normal A segunda forma normal (2FN) é fundamentada no conceito de dependência funcional total. Uma dependência funcional X —> 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 funcionalmente. 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 em 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 teste 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 LocaLprojeto, 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 LocaLprojeto podem ser funcional mente determinados somente por Numero_projeto. Os atributos Cpf e Numero_projeto fazem parte da chave primária {Cpf, Numero_projeto} dc FUNCIONAR1O_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)

FUNCIONARIO PROJETO ÇBÍ Numero projeto Horas Nome fundonario Nome projeto Local projeto

DF1

DF2 DF3

Normalizacao 2FN

rr3

FP1 Cpf |Numero projeto DF1

Horas

____ ♦

Çfií DF2

Nome funcionario

___ 1

Numero projeto|Nome projelo Local projeto

DF3I_______ 1_____ 1

(b)

FUNCIONÁRIO DEPARTAMENTO Nome funcionario J

Data nasci mento

Endereço Numero departamento Nome departamento CpLgerente

t_________ 41 Normalizacao 3FN DF1

’

4

♦

DF2

Nome_funcionario Cpf Datanascimento| Endereço| Numero departamento

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 FUNCIONÁRIOJ3EPARTAMENTO 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 é testada 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 de 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 de 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 em 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 Identificador_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 e funcionalmente dependente de cdda 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

LOTES__________ I

I

1

_______

para 2FN e 3FN. (a) A relação

ldentificador_propriedade | Nome_cidade | Numerojote | Area | Preco | Imposto |

LOTES com suas dependências funcionais de DF1 a DF4. (b)

1 I__ I I___________ ___ I I__ I

OH

I_________________ __________ ______

DF2 DF3

439

Decompondo para as relações

2FN LOTES1 e LOTES2. (c)

__________________________________ |

Decompondo LOTES 1 para as relações 3FN LOTES 1A e LOTES1B. (d) Normalização

progressiva de LOTES para um

(b)

LOTES1

LOTES2

Identificador_propnedade | Nome_cidade| Numero_k)te Area Preco

1

DF1

1 LI ___ LI

DF2

Nome cidade

DF3

projeto 3FN.

Imposto

|__________ |

DF4

(c)

LOTES1B_______

LOTES1A ldentificador propriedade Nome cidade Numero lote |Area

|

Area

Preco

DF4 |_______ |

DF1 DF2

(d) LOTES

LOTES1

LOTES1A

LOTES1B

1FN

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 dc LOTES 1 e colocando-o com Area (o lado esquerdo de DF4 que causa a dependência transitiva) cm 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 —• Y.-A 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 R.

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. (a)

Figura 14.13 Forma normal de

LOTES1A Nome ddade Numero lote Area

FNBC de LOTES 1A com

♦

DF1

Boyce-Codd. (a) Normalização

a dependência funcional

DF2

DF2 sendo perdida na DF5

decomposição, (b) Uma relação

esquemática com DFs; ela está Normalização FNBC LOTES 1AX

na 3FN, mas não na FNBC, em LOTES1AY

ldentificador_propriedade

Area Numero_lote

Area

Nome_cidade

R

(b)

A

c

B

DF1 DF2 t

4

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

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

ENSINA que está na 3FN, mas

não na FNBC.

Aluno

Disciplina

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 B e Professor como C. Logo, essa relação está na 3FN, mas não na FNBC. A decomposição desse esquema de relação cm dois esquemas não é direta, pois ele pode ser decomposto cm um dos três pares possíveis a seguir: 1. Ri (Aluno, Professor) e R2(.Aiun.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 = |R,, R,J de R tem a propriedade de junção sem perda (não aditiva) cm relação a um conjunto de 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 R2 para o teste acima é Professor e R, - R2 é 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 em R, 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 exatainente 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 e 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 é uma relação dc todas as chaves (sua chave são todos os seus atributos juntos) c, 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 ser especificadas como dependências funcionais c, portanto, não estão violando a FNBC. Para resolver essa situação, foi proposto o conceito de 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 dc 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_fundonario

Nome projeto

projeto e Nome_funcionario

Silva

X

João

—*♦ Nome.dependente.

Silva

Y

Ana

(b) Decompondo a relação

Silva

X

Ana

Silva

Y

João

Nome_funconano —Nome_

FUNCIONÁRIO em duas relações

4FN FUNCIONARIO-PROJETOS e 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.funcionario

Nome, projeto

Nome.funcionario

Silva

X

Silva

João

Silva

Y

Silva

Ana

RJ. (d) Decompondo a relação FORNECE nas relações 5FN Rv r2.r3.

Nome.dependente

(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

Rsrafuso

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] = fJX],então duas tuplas í3 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 ■ Z3[X)=Í4[X] = /1[XJ = Z2[X| ■ G[V] = í1[Y|er4[Yl =í2[Y] ■ í3[Z] = í2[Z]et4[Z] = tI[Z]

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 Nomejuncionario -* ♦ Nome_projeto e a relação FUNCIONARIO-DEPENDENTES tem a DMV trivial Nomejuncionario —«■ 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 tlt t;, t- e t4 não são necessariamente distintas.

2,1 Z é uma forma abreviada para os atributos em R após os atributos em (X U Y) serem removidos de R. 21 P refere-se à cobertura das dependências funcionais F,ou rodas as dependências que sào implicadas por E 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 * (KK1(r), xR,(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 O R7) -» (Rj - R») (ou, por simetria, (R, O R,) —(R, - RJ). Uma dependência dc 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,..., RJ 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 Figura 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 /também 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„ R3) 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 RpR2eR3 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 de 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 de 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 e a falta de redundância evitarão as anomalias de inserção/exclusão/atualização, além da geração de dados falsos. Recomendamos limitar os valores NULL, que causam problemas durante operações SELECT, JOIN e de 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 de dependências — Novamenre, P refere-se à coberrura 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 de 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 de 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 em 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 e 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 Boyee-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 normalmentc 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. c. Um registro dc nota refere-se a um aluno (Cpf), uma turma em particular e uma nota (Nota). Crie um esquema de banco de dados relacionai para essa aplicação. Primeiro, mostre todas 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 dc 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, C, H, /,/) e o conjunto de dependências funcionais F = ( (A, B}—>{C), (A)-»{D, £|, {B|—>{F), {F)-»{G, F/|, {D| ->{/,/} }. Qual é a chave para R? Decomponha R em relações na 2FN c depois na 3FN. Repita o Exercício 14.24 para o seguinte conjunto dc dependências funcionais G = f(A, B)-(C), (B, D}-(£, F), {A, DUG, H), (A|-{/), |. Considere a seguinte relação:

a.

A

B

C

NUM TUPLA

10

bl

C1

1

10

b2

c2

2

11

b4

C1

3

12

b3

c4

4

13

b1

d

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.disciplina, 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.disciplina} —► {Numero.departamento, Horas.creditos, NiveLdisciplina} {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) UEM-PEDIDO (Numero-pedido, Numero_item, Quantidade_pedida, Preco_ total, Porcentagem_desconto)

Suponha que cada item tenha um desconto diferente. Preco_total 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? Mostre 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, Preco_livro, 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’, ‘WesternDigital’, ‘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 c 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 cerro 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 Datajnicio, 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= [IfeLl/]], lí/Lfe, F]], [MLlA/lll Como o DBD é implementado em Prolog, o uso de termos em maiusculas c reservado para variáveis na linguagem e, portanto, constantes em 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 originalmente 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 dc atualização. A Forma Normal dc Boycc-Codd foi definida cm Codd (1974). A definição alternativa da terceira forma normal c dada em 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. Conceirualmente, 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 e 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 mulrivalorada (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 de 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 akas, como 2FN, 3FN e FNBC. As relações resultantes precisam satisfazer colerivamente 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 dc 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 dc dependência multivalorada (DMV) ainda mais, aplicando as noções de inferência c 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. z\ 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 restes 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 de 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.

15.1.1 Regras de inferência para dependências funcionais Indicamos com F o conjunto dc 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 —♦ ¥ se mantiver em cada estado dc relação válido r de R; ou seja, sempre que r satisfizer todas as dependências em F, X —* ¥ 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.departamento > 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.departamento}, 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 —> ¥ para indicar que a dependência funcional X —♦ ¥é 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 de fechamento de F, pode ser determinado a partir de 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 de 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 e 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 e que duas tuplas Z] e t2 existam em alguma instância de relação r de R, tal que ty [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 eZ2 em r, tais que (1) t, [X] = t2 [X], (2) [Y] = t2 [Y], (3) íj [XZ] = Z, [XZ] e (4) t] [YZ] x t2 [YZ]. Isso não é possível porque, com base em (1) e (3), deduzimos (5) Z, |Z| = Z2 [Z],ede (2) e (5) deduzimos (6) [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 tx e t2 em r tais que Z, [X] = t2 [X], devemos ter (3) Zj [Y| = Z2 [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. 5 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 -> Y, 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|, A2,...»A J 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 VV (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 RH 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 ser 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 funcionalmente determinados por X com base em F; X * é chamado de fechamento dc 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 dc DFs em um esquema dc 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 cm 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 de fechamento é útil para compreender o significado e as implicações dos atributos ou conjuntos dc atributos cm uma relação. Por exemplo, considere o esquema de 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 cm 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.disciplina, 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 dc 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 podería 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 E *. Portanto, a equivalência significa que cada DF em E pode ser deduzida de F, e cada DF em F pode ser deduzida de E; ou seja, E é equivalente a F se as duas condições — E cobre F e F cobre E — se mantiverem. Podemos determinar se F cobre E 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 E, então F cobre E. Determinamos se E e F são equivalentes verificando se E cobre Fe se Fcobre E. 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 E é um conjunto de dependências funcionais F que satisfaz a propriedade dc que cada dependência em E está no fechamento F~ de 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) {(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 E Ao usar a regra de inferência RI4, 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 —* {A,, A,,AJ em F pelas n depen­ dências funcionais X —♦A], X —*A 2, X —* An. * (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) l 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 E': {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 de 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 Cb 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 Cb {calcule (Cb - A) * em relação a F; se (Cb - A) * contiver todos os atributos em R, defina Cb := Cb — {A} }; No Algoritmo 15.2(a), começamos pela definição de Cb 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 tinta 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 c 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,,..., A J, 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 ser 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]y que se tornará o esquema do banco de 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 de condição dc preservação dc atributo dc 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, LocaLprojeto) 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, LocaLprojeto), 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 LOCAUZACOES.FUNCIONARIO com PROJETO(Nome_projeto, Numero_projeto, LocaLprojeto, Numero_departamento) na Figura 14.2 — que está na FNBC —, usando LocaLprojeto 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 rodo.

15.2.2 Propriedade de preservação de dependência de uma decomposição Seria útil se cada dependência funcional X—>¥ 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 Informalinente, 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 R( é um subconjunto dc R, c o conjunto das dependências X —* Y em F+ tal que os atributos em X U Y estejam todos contidos em R-. Logo, a projeção de F sobre cada esquema de relação R- 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, Rot} 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 cm {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 cm relação a F, dc 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) de 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, e não à perda de 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 NJB 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 RpRw) 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 5 com uma linha i para cada relação R; em D, e uma coluna / para cada atributo A em R.

2. Defina $(/,/):= 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 ti (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 dc 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 dc 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 dc relação FUNCIONARIO_PROJETO1 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. l ogo, 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 dc junção nâo aditiva. A Figura 15.1(b) mostra outra decomposição dc 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 n 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 é 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 = (Rj, R2, •••» Rm} de R tem a propriedade de 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( = {Qj, Q2,..., QJ de R, tem a propriedade de junção não aditiva em relação à projeção de F em Rp então a decomposição D» = (R(, R2,..., R^, Q,, Q2,..., Qh R^t,..., Rm] de R tem a propriedade de junção não aditiva em relação a F.

467

468 (a)

Sistemas de banco de dados

R = {Cpf, Nomejuncionario, Numero_projeto, Nome_projeto, LocaLprojeto, Horas} D = {R,.R2} R} = LOCALIZACOESJUNCIONARIO {Nomejuncionario, LocaLprojeto} R2 = FUNCIONARIO_PROJETO1{Cpf, Numero.projeto, Horas, Nome_projeto, LocaLprojeto}

F= {Cpf —♦ Nomejuncionario; Numero_projeto —> {Nome_projeto, LocaLprojeto}; {Cpf, Numero_projeto) —> Horas} Nome_

Numero,

Nome,

Local.

funcionário

projeto

projeto

projeto

*11

â2

*13

*14

â5

*>16

a1

bl2

a3

a4

*5

*6

Cpf

«2

Horas

(Nenhuma mudança na matriz após aplicar as dependências funcionais) (b)

Cpf

(c)

TRABALHA EM

PROJETO

FUNCIONÁRIO Nome_

Numero,

Nome,

Local,

funcionário

projeto

projeto

projeto

Cpf

R = {Cpf, Nomejuncionario, Numero_projeto, Nome.projeto, LocaLprojeto, Horas}

Numero, projeto

Horas

D = {R1,R?,R3)

R, = FUNCIONÁRIO = {Cpf, Nomejuncionario}

R2 = PROJETO = {Numero_projeto, Nome_projeto, LocaLprojeto} R3 = TRABALHAJM = {Cpf, Numero_projeto, Horas} F = {Cpf —> Nomejuncionario; Numero.projeto —* {Nome.projeto, LocaLprojeto}; {Cpf, Numero_projeto} —* Horas}

Cpf

Nome,

Numero,

Nome,

Local,

funcionário

projeto

projeto

projeto

Horas

a1

az

*>13

*>u

*>15

*>16

«2

*>21

*22

*3

a4

as

*26

«3

a.

*32

â3

*34

*35

â6

(Matriz original S no início do algoritmo)

Cpf

Nome

Numero _

Nome .

Local _

funcionário

projeto

projeto

projeto

Horas

a.

a2

*13

b»

*15

*16

«2

b2i

*>22

*3

*4

as

*>26

«3

ai

X Salario.fun­ cionario, Telefone.fundonario, Numero.departamento. Além disso, Cpf.funcionario é externo em Cpf.funcionario, Numero_projeto —» Nome.projeto, LocaLprojeto. 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.fundonario -> Salario_funcionario,Telefone_funcionario, Numero.departamento; Numero.projeto —* Nome.projeto, LocaLprojeto) A segunda etapa do Algoritmo 15.4 produz as relações Rt e R2 como:

Rj (Cpf-fundonario, Salario.fundonario, Telefone.fundonario, Numero.departamento)

R2 (Numero_projeto, 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 (Cof.funcionário, 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 (casoX). Considere o esquema de relação LOTES1A 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: R, (E 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: S| (£ 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 5] 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 Sj 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 = (A,, A2, ...»AJ em uma decomposição D = (R,, R2,..., Rm), tal que cada R-está na FNBC ca 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 em decomposições sucessivas) para criar uma decomposição de junção não aditiva D = (Rf, R2,...»Rm} de uma relação universal R baseada em um conjunto de dependências funcionais F, tal que cada R- 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 e um conjunto de dependências funcionais F nos atributos de R. 1. Defina D := |R|;

2. Enquanto existe um esquema de relação Q em D que não esteja na FNBC, faça

I 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 em 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 todos 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 e aplicarmos uma NATURAL JOIN cm FUNCIONARIO_1 c FUNCIONARIO_3, as tuplas para Borges c 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 de dados grande, com centenas dc atributos. Deixar de 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 deterministicos. Por exemplo, os algoritmos de síntese (algoritmos 15.4 c 15.6) exigem a especificação dc uma cobertura mínima G

473

474

Sistemas de banco de dados

(a) FUNCIONÁRIO

Q2Í

Data, nascimento

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

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

Berges, 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

Silva. João B.

Numero, departamento

Endereço

5

DEPARTAMENTO Nome.departamento

(b)

CBÍ

Data. nascimento

Silva. João B.

12345678966

09-01-1965

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

5

Pesquisa

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 $.

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

RuaTinbira, 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

Numero, departamento

Nome, departamento

Gerente, departamento

33344555587

(c)

Nome funcionário

Nome departamento

Gerente departamento

5

Pesquisa

33344555587

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

5

Pesquisa

33344555587

19-07-1968

Rua Souza Uma, 35, Curitiba, PR

4

Administração

98765432168

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

NULL

NULL

NULL

NULL

NULL

NULL

ÇBÍ

Data nascimento

Silva. João B.

12345678966

09-01-1965

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

Wong, Fernando T.

33344555587

08-12-1955

Zelaya, Aíce J.

99988777767

Souza, Jennifer S.

Endereço

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

Numero 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)

FUNCIONÁRIO 1

Nome funcionário

(b)

Algoritmos de projeto de banco de dados relacionai e demais dependências

£pf

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

FUNCIONÁRIO _2

Cpf

(c)

FUNCIONÁRIO 3

Numero_

Cpf

departamento

Numero_ 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, é 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 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 dc 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

Propriedades/Finalidade

conjunto de dependên­

cias funcionais F

Um conjunto de relações

na3FN

Determinar a cobertura mínima

de um conjunto de dependên­ cias F

Encontrar uma chave

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

Ch (que

seja um subconjunto de R)

Testar para a decomposição da

junção não aditiva

A relação R inteira é sempre uma superchave padrão

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

dependência

priedades desejáveis e a 3FN

todas as pro­

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

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 e 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 = (Â,, Â2,..., 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 complementação para DMVs): (X —** Y) l= (X —►* (R - (X U Y))|. RI5 (regra de aumento para DMVs): se X —>-> Ye W3 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 W com 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

(‘Jim’, ‘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 cm um novo projeto adicional ‘P’, temos dc inserir três tuplas cm 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 podcin 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)

Nome 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

Nome_dependente

Silva

X

Silva

Ana

Silva

Y

Silva

João

Braga

W

Braga

Jim

Braga

X

Braga

Joana

Braga

Y

Braga

Roberto

Braga

Z

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 —>♦ ¥ 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, AR.)-(R,-R,) ou, por simetria, se, e somente se,

(R, A R,) —»* (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 de S, devemos ter nx(r(R)) Ç n^s{S))

O relacionamento Ç (subconjunto) não necessariamente precisa ser um sub­ conjunto próprio. Obviamente, os conjuntos de atributos em que a dependência de inclusão é especificada — X de R e ¥ de 5 — devem ter o mesmo número de atri­ butos. Além disso, os domínios para cada par de atributos correspondentes devem ser compatíveis. Por exemplo, se X = (Ap A2, ..., AJ e ¥ = {Bp B2,..., BJ, uma correspondência possível é ter dom(A;) compatível com dom(B:) para 1 Totaljtem pela fórmula Total_item = Preco_unitario * Quantidade.

Logo, existe um valor exclusivo para Totaljtem para cada par (Quantidade, Preco_unitario) e, portanto, está de acordo com a definição de dependência funcional. Além disso, pode haver um procedimento que leve em consideração os descontos por quantidade, o tipo de item, e assim por diante, e calcule um preço com desconto para a quantidade total pedida para esse item. Portanto, podemos dizer (Numero_item, Quantidade, Preco.unitario) —* Preco.desconto, ou (NumerO-item, Quantidade, Totaljtem) —* Preco.desconto

Para verificar as DFs acima, um procedimento mais complexo CALCULAR_PRECO_ TOTAL pode ser colocado em ação. Embora os tipos mostrados de DFs estejam tecni­ camente presentes na maioria das relações, eles não recebem atenção em particular durante a normalização. Eles podem ser relevantes durante a carga das relações e o processamento da consulta, pois o preenchimento ou a recuperação do atributo no lado direito da dependência exige a execução de um procedimento como o mencionado.

15.6.4 Forma normal de domínio-chave Não existe uma regra estrita sobre a definição de formas normais apenas até a 5FN. Historicamente, os processos de normalização e de descoberta de dependências indesejáveis eram executados até a 5FN, mas tem sido possível definir formas nor­ mais mais rigorosas que levam em conta outros tipos de dependências e restrições. A ideia por trás da forma normal de domínio-chave (FNDC) é especificar (pelo menos, de maneira teórica) a forma normal definitiva que considera todos os tipos possíveis de dependências e restrições. Um esquema de relação é considerado na FNDC se todas as restrições e dependências que devem ser mantidas nos estados válidos da relação puderem ser impostas simplesmente ao impor as restrições de domínio e restrições de chave sobre a relação. Para uma relação na FNDC, torna-se muito simples impor todas as restrições do banco de dados simplesmente verificando se cada valor de atri­ buto em uma tupla tem o domínio apropriado e se cada restrição de chave é imposta.

481

482

Sistemas de banco de dados

Contudo, pela dificuldade de incluir restrições complexas em uma relação FNDC, sua utilidade prática é limitada, pois pode ser muito difícil especificar restrições de integridade gerais. Por exemplo, considere uma relação C ARRO(Marca, ldentificador_ carro) (em que ldentificador_carro é o número de identificação do veículo) e outra relação FABRICANTE(ldentificador_carro, Pais) (em que Pais é o país de fabricação). Uma restrição geral pode ter a seguinte forma: se a marca for 'Toyota' ou 'Lexus', o primeiro caractere de Identificador_carro é'J' se o país de fabricação for 'Japão'; se a marca for 'Honda' ou 'Acura', o segundo caractere de Identificador_carro é um se o país de fabricação for 'Japão'. Não existe um modo simplificado de representar essas restrições além de escrever um procedimento (ou asserções gerais) para testá-las. O procedimento CALCULAR_PRECO_TOTAL é um exemplo desses procedimentos necessários para impor uma restrição de integridade apropriada. Por esses motivos, embora o conceito da FNDC seja atraente e pareça simples, ele não pode ser testado ou implementado diretamente com quaisquer garantias de con­ sistência ou não redundância de projeto. Logo, ele não é muito utilizado na prática.

15.7 Resumo Neste capítulo, apresentamos outro conjunto de tópicos relacionados a depen­ dências, uma discussão da decomposição e diversos algoritmos relacionados a eles e também ao projeto de relações 3FN, FNBC e 4FN a partir de um conjunto dado de dependências funcionais e multivaloradas. Na Seção 15.1, apresentamos regras de inferência para dependências funcionais (DFs), a noção de fechamento dc um atributo, fechamento dc um conjunto dc dependências funcionais, equivalência entre conjuntos de dependências funcionais e algoritmos para encontrar o fechamento de um atributo (Algoritmo 15.1) e a cobertura mínima de um conjunto de DFs (Algoritmo 15.2). Depois, discutimos duas propriedades importantes das decom­ posições: a propriedade dc junção não aditiva e a propriedade dc preservação dc dependência. Foi apresentado um algoritmo de n vias para testar a decomposição não aditiva de uma relação (Algoritmo 15.3), e um teste mais simples para verificar a propriedade das decomposições binárias não aditivas (propriedade NJB) já foi descrito na Seção 14.5.1. Depois, abordamos o projeto relacionai pela síntese, com base em um conjunto de dependências funcionais dadas. O algoritmo de síntese rela­ cionai (Algoritmo 15.4) cria relações 3FN de um esquema de relação universal com base em determinado conjunto de dependências funcionais que foram especificadas pelo projetista do banco de dados. Os algoritmos de decomposição relacionai (como os algoritmos 15.5 e 15.6) criam relações FNBC (ou 4FN) pela decomposição não aditiva sucessiva dc relações não normalizadas para duas relações componentes de cada vez. Vimos que é possível sintetizar esquemas de relação 3FN que atendem a ambas as propriedades; porém, no caso das FNBC, é possível visar apenas à não aditividade das junções — a preservação da dependência não pode ser garantida. Se o projetista tiver de visar a uma dessas duas, a condição de junção não aditiva é uma necessidade absoluta. Na Seção 15.4, mostramos como certas necessidades surgem em uma coleção de relações em virtude de valores nulos que podem existir em relações, apesar de estas estarem individualmente na 3FN ou na FNBC. As vezes, quando a decomposição é indevidamente levada muito adiante, certas “tuplas suspensas” podem acontecer, as quais não participam dos resultados das junções e, portanto, podem se tornar invisíveis. Também mostramos como os algoritmos como o 15.4 para a síntese 3FN poderíam levar a projetos alternativos com base na escolha da cobertura mínima. Depois, revisamos as dependências multivaloradas (DMVs) na Seção 15.5, as quais surgem de uma combinação imprópria de dois ou

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

mais atributos multivalorados independentes na mesma relação e que resultam em uma expansão combinatória das tuplas usadas para definir a quarta forma normal (4FN). Discutimos as regras de inferência aplicáveis às DMVs e abordamos a impor­ tância da 4FN. Finalmente, na Seção 15.6, discutimos as dependências de inclusão, utilizadas para especificar a integridade referencial e as restrições de classe/subclasse, e indicamos a necessidade de funções aritméticas ou procedimentos mais complexos para impor certas restrições dc dependência funcional. Concluímos com uma breve discussão da forma normal dc domínio-chave (FNDC).

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

15.1. 15.2. 15.3. 15.4.

15.5. 15.6. 15.7.

15.8. 15.9.

15.10. 15.11. 15.12. 15.13.

15.14. 15.15. 15.16.

Qual c o papel das regras dc inferência de Armstrong (regras dc inferência dc R11 a RI3) no desenvolvimento da teoria do projeto relacionai? O que significa a completude e legitimidade das regras de inferência de Armstrong? O que significa o fechamento de um conjunto de dependências funcionais? Ilustre com um exemplo. Quando dois conjuntos de dependências funcionais são equivalentes? Como podemos determinar sua equivalência? O que é um conjunto mínimo dc dependências funcionais? Cada conjunto de dependências tem um conjunto equivalente mínimo? Ele é sempre exclusivo? O que significa a condição de preservação dc atributo em uma decomposição? Por que as formas normais isoladas são insuficientes como uma condição para um bom projeto dc esquema? O que é a propriedade de preservação de dependência para uma decompo­ sição? Por que ela é importante? Por que não garantimos que os esquemas de relação FNBC serão produzidos pelas decomposições de preservação de dependência dos esquemas de relação não FNBC? Dê um contraexemplo para ilustrar esse ponto. O que é a propriedade de junção sem perdas (ou não aditiva) de uma decom­ posição? Por que ela é importante? Entre as propriedades da preservação de dependência e “sem perdas”, qual deve ser definitivamente satisfeita? Por quê? Discuta os problemas do valor NULL c da tupla suspensa. Ilustre como o processo dc criação dc relações na primeira forma normal pode levar a dependências multivaloradas. Como a primeira normalização deve ser feita corretamente de modo que as DMVs sejam evitadas? Que tipos de restrições as dependências de inclusão pretendem representar? Como as dependências de modelo diferem dos outros tipos de dependências que discutimos? Por que a forma normal de domínio-chave (FNDC) é conhecida como a forma normal definitiva?

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

15.17. Mostre que os esquemas de relação produzidos pelo Algoritmo 15.4 estão na 3FN. 15.18. Mostre que, se a matriz 5 resultante do Algoritmo 15.3 não tiver uma linha contendo todos os símbolos d, projetar 5 na decomposição e juntá-la nova­ mente sempre produzirá pelo menos uma tupla falsa.

483

484

Sistemas de banco de dados

15.19. Mostre que os esquemas de relação produzidos pelo Algoritmo 15.5 estão na FNBC. 15.20. Escreva programas que implementem os algoritmos 15.4 e 15.5. 15.21. Considere a relação GELADEIRA(Numero_modelo, Ano, Preco, Fabrica, Cor), que é abreviada como GELADEIRA(M, A, P, F, C), e o seguinte conjunto F de dependências funcionais: F = |M —♦ F, {M, A) —♦ P, F —♦ C) a. Avalie cada um dos seguintes como uma chave candidata para GELADEIRA, dando motivos pelos quais ela pode ou não ser uma chave {M|, (M, A), {M,C(. b. Com base na determinação de chave acima, indique se a relação GELADEIRA está na 3FN e na FNBC, dando motivos apropriados. c. Considere a decomposição de GELADEIRA em D = {RJM, A, P), R2(M, F, C)). Essa decomposição é sem perdas? Mostre por quê. (Você pode consultar o teste sob a Propriedade NJB na Seção 14.5.1.) 15.22. Especifique todas as dependências dc inclusão para o esquema relacionai da Figura 5.5. 15.23. Prove que uma dependência funcional satisfaz a definição formal da depen­ dência multi valorada. 15.24. Considere o exemplo de normalização da relação LOTES nas seções 14.4 e 14.5. Determine se a decomposição de LOTES em {LOTES 1AX, LOTES 1 AY, LOTES 1B, L0TES2) tem uma propriedade de junção sem perdas, aplicando o /Ylgoritmo 15.3 e também usando o teste sob a Propriedade NJB da Seção 14.5.1. 15.25. Mostre como as DMVs Nome_funcionario —*♦ Nome_projeto e Nomejuncionario —** Nome.dependente da Figura 14.15(a) podem surgir durante a normalização para a 1FN de uma relação, na qual os atributos Nome_projeto e Nome_dependente são multivalorados. 15.26. Aplique o Algoritmo 15.2(a) à relação do Exercício 14.24 para determinar uma chave para R. Crie um conjunto mínimo de dependências G que seja equivalente a F c aplique o algoritmo dc síntese (Algoritmo 15.4) para decompor R em relações 3FN. 15.27. Repita o Exercício 15.26 para as dependências funcionais do Exercício 14.25. 15.28. Aplique o algoritmo de decomposição (Algoritmo 15.5) à relação R e o con­ junto de dependências F no Exercício 15.24. Repita para as dependências G no Exercício 15.25. 15.29. Aplique o Algoritmo 15.2(a) às relações nos exercícios 14.27 e 14.28 para determinar uma chave para R. Aplique o algoritmo de síntese (Algoritmo 15.4) para decompor R em relações 3FN e o algoritmo de decomposição (Algoritmo 15.5) para decompor R em relações FNBC. 15.30. Considere as seguintes decomposições para o esquema de relação R do Exercício 14.24. Determine se cada decomposição tem (1) a propriedade de preservação de dependência e (2) a propriedade de junção sem perdas, com relação a F. Determine também cm qual forma normal cada relação na decomposição se encontra. a. D, = {Rj, R„ Rj, R4, R5í; R, = {A, B, Q, R, = {A, D, £|, R. = {B, F), R4 = (F, G, H|,R5 = (D, I,J] b. D2 = {R„ R,, R3); R, = (A, B, C, D, E\, R2 = (B, F, G, H}, R? = |D, I,J] c. D3 = (R„ R2, R3, R4, R5|; R, = (A, B, C, D|, R, = |D, E), R3 = (B, F), R4 = {F, G, H},R5 = {D, I,J]

EXERCÍCIO DE LABORATÓRIO-----------------------------------------------------------------Nota: estes exercícios usam o sistema DBD {data base designer) que é descrito no manual do laboratório (disponível em inglês, na Sala Virtual do livro). O esquema

Capítulo 15

Algoritmos de projeto de banco de dados relacionai e demais dependências

relacionai R e o conjunto de dependências funcionais F precisam ser codificados como listas. Como um exemplo, R e F para o Problema 14.24 são codificados como: R = [a, b, c, d, e, f, g, b, i, /]

f= ll/l,te,F|],

Como o DBD é implementado em Prolog, o uso de termos em maiúsculas é reser­ vado para variáveis na linguagem e, portanto, constantes minúsculas são utilizadas para codificar os atributos. Para obter mais detalhes sobre o uso do sistema DBD, consulte o manual do laboratório. 15.31. Usando o sistema DBD, verifique suas respostas para os seguintes exercícios: a. 15.24 b. 15.26 c. 15.27 d. 15.28 c. 15.29 f. 15.30 (a) e(b)

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

Os livros de Maier (1983) e Atzcni c De Antonellis (1993) incluem uma discussão abrangente sobre a teoria da dependência relacionai. O Algoritmo 15.4 é baseado no algoritmo de normalização apresentado em Biskup et al. (1979). O algoritmo de decomposição (Algoritmo 15.5) é atribuído a Bernstein (1976). Tsou e Fischer (1982) dão um algoritmo de tempo polinomial para a decomposição da FNBC. A teoria da preservação de dependência e junções sem perdas é explicada em Ullman (1988), onde aparecem provas de alguns dos algoritmos discutidos aqui. A propriedade de junção sem perda é analisada em Aho et al. (1979). Os algoritmos para determinar as chaves de uma relação com base em dependências funcionais são dados em Osborn (1977); o teste para a FNBC é discutido em Osborn (1979). O teste para a 3FN é discutido cm Tsou c Fischer (1982). Os algoritmos para projetar relações FNBC são dados em Wang (1990) e em Hernandez e Chan (1991). As dependências multi valoradas e a quarta forma normal são definidas em Zaniolo (1976) e em Nicolas (1978). Muitas das formas normais avançadas são atribuídas a Fagin: a quarta forma normal em Fagin (1977), FNPJ em Fagin (1979) e FNDC em Fagin (1981). O conjunto dc regras legítimas c completas para depen­ dências funcionais e multivaloradas foi dado por Beeri et al. (1977). As dependências de junção são discutidas por Rissanen (1977) e por Aho et al. (1979). As regras de inferência para dependências de junção são dadas por Sciore (1982). As dependências de inclusão são discutidas por Casanova et al. (1981) e analisadas ainda mais em Cosmadakis et al. (1990). Seu uso na otimização de esquemas relacionais é discutido em Casanova et al. (1989). As dependências dc modelo, que são uma forma geral de dependências baseadas em hipóteses e tuplas de conclusão, são discutidas por Sadri e Ullman (1982). Outras dependências são discutidas cm Nicolas (1978), em Furtado (1978) e em Mendelzon e Maier (1979). Abiteboul et al. (1995) oferecem um tratamento teórico de muitas das idéias apresentadas neste capítulo e no Capítulo 14.

485

PARTE 7 Estruturas de arquivo, hashing, indexação e projeto físico de banco j de dados J

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing e arquiteturas de armazenamento modernas s bancos de dados sào armazenados fisicamente como arquivos de registros, que em geral ficam em discos magnéticos. Este capítulo e o seguinte tratam da organização dos bancos de dados em locais de armazenamento e as téc­ nicas para acessá-los dc modo eficiente usando diversos algoritmos, alguns dos quais exigindo estruturas dc dados auxiliares, chamadas índices. Essas estruturas costumam ser conhecidas como estruturas físicas de arquivo de banco de dados c estão no nível físico da arquitetura de três esquemas descrita no Capítulo 2. Começamos a Seção 16.1 introduzindo os conceitos de hierarquias de armazenamento de computador e como elas são usadas nos sistemas de banco de dados. A Seção 16.2 é dedicada a uma descrição dos dispositivos de armazenamento de disco magnético e suas características, memória flash e unidades em estado sólido e unidades ópticas, além dos dispositivos de armazenamento de fita magnética usados para fins de arquivamento. Também discutiremos técnicas mais eficientes para ter acesso aos discos. Depois de discutir dife­ rentes tecnologias de armazenamento, voltamos nossa atenção para os métodos para organizar fisicamente os dados nos discos. A Seção 16.3 aborda a técnica de buffering duplo, usada para agilizar a recuperação dc múltiplos blocos dc disco. Também discu­ timos o gerenciamento de buffer e as estratégias de substituição de buffer. Na Seção 16.4, discutimos diversas maneiras de formatar e armazenar registros de arquivo no disco. A Seção 16.5 discute os diversos tipos de operações normalmentc aplicadas aos registros do arquivo. Apresentamos três métodos principais para organizar registros de arquivo no disco: registros desordenados, na Seção 16.6; registros ordenados, na Seção 16.7; e registros com hashing, na Seção 16.8. A Seção 16.9 apresenta rapidamente os arquivos de registros mistos e outros métodos principais para organizar registros, como as B-trees. Estas são parti­ cularmente relevantes para o armazenamento de bancos de dados orientados a objeto, que discutimos no Capítulo 12. A Seção 16.10 descreve o RAID (redundant arrays of inexpensive — ou independent — disks), uma arquitetura de sistema de

O

490

Sistemas de banco de dados

armazenamento de dados que normalmente é usada em grandes organizações para obter melhor confiabilidade e desempenho. Por fim, na Seção 16.11, descrevemos três desenvolvimentos modernos que são importantes para o armazenamento de dados corporativos: área de armazenamento em rede (SAN, do inglês storage area networks), armazenamento conectado à rede (NAS, do inglês network-attached storage) e iSCSI (internet SCSI — small computer system interface), além de outros protocolos de armazenamento baseados em rede, que tornam as redes de área de armazenamento mais acessíveis sem o uso da infraestrutura canais de fibra e, por­ tanto, está obtendo grande aceitação na indústria. Também discutimos as camadas de armazenamento e o armazenamento baseado em objeto. A Seção 16.12 resume o capítulo. No Capítulo 17, discutimos as técnicas para criar estruturas de dados auxiliares, chamadas dc índices, que agilizam a busca e a recuperação de registros. Essas técnicas envolvem o armazenamento de dados auxiliares, chamados arquivos de índice, além dos próprios registros do arquivo. Os capítulos 16 e 17 podem ser folheados ou mesmo omitidos pelos leitores que já estudaram organizações e indexação de arquivos em outro curso. O material abordado aqui, em particular as seções 16.1 a 16.8, é necessário para se entender os capítulos 18 e 19, que tratam do processamento e otimização de consulta c do ajuste do banco de dados para melhorar o desempenho das consultas.

16.1 Introdução A coleção dc dados que compõem um banco dc dados computadorizado deve ser armazenada fisicamente cm algum meio dc armazenamento no computadon O software de SGBD pode recuperar, atualizar e processar esses dados conforme a necessidade. A mídia de armazenamento de computador forma uma hierarquia de armazenamento que inclui três categorias principais:

■ Armazenamento primário. Esta categoria inclui a mídia de armazenamento que pode ser operada diretamente pela unidade central de processamento (CPU) do computador, como a memória principal do computador e memórias cache meno­ res, porém mais rápidas. O armazenamento primário normalmente oferece acesso rápido aos dados, mas tem capacidade dc armazenamento limitada. Embora as capacidades da memória principal estejam crescendo rapidamente nos últimos anos, elas ainda são mais caras e têm menos capacidade de armazenamento que o exigido pelos bancos de dados típicos, em nível corporativo. O conteúdo da memória principal é perdido quando há falta de energia ou uma falha no sistema. ■ Armazenamento secundário. A escolha principal de meio de armazenamento para os bancos de dados corporativos tem sido os discos magnéticos. Porém, as memórias flash estão se tornando um meio comum para o armazenamento dc quantidades moderadas dc dados permanentes. Quando usada como um substi­ tuto para um disco rígido, essa memória é denominada unidade cm estado sólido (ou SSD, do inglês solid-state drivel. ■ Armazenamento terciário. Os discos ópticos (CD-ROMs, DVDs e outros meios de armazenamento semelhantes) e fitas são meios removíveis usados nos sistemas atuais como armazenamento off-line para o arquivamento de bancos de dados e, portanto, estão incluídos na categoria denominada armazenamento terciário. Estes dispositivos costumam ter uma capacidade maior, menor custo c oferecem acesso mais lento aos dados que os dispositivos de armazenamento primários. Os dados no armazenamento secundário ou terciário não podem ser processados diretamente pela CPU; primeiro, eles precisam ser copiados para o armazena­ mento primário e, depois, processados pela CPU.

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

Primeiro, damos uma visão geral dos diversos dispositivos de armazenamento usados para armazenamento primário, secundário e terciário na Seção 16.1.1, e depois, na Seção 16.1.2, discutimos como os bancos de dados normalmente são tratados na hierarquia de armazenamento.

16.1.1 Hierarquias de memória e dispositivos de armazenamento' Em um sistema de computador moderno, os dados residem e são transportados por uma hierarquia de meios de armazenamento. A memória dc velocidade mais alta c a mais cara e, portanto, está disponível com a menor capacidade. A memória de velocidade mais lenta é o armazenamento em fita off-line, que basicamente está disponível em capacidade de armazenamento indefinida. No nível de armazenamento primário, a hierarquia dc memória inclui, no extremo mais caro, a memória cache, que c uma RAM {random access memory) estática. A memória cache normalmente é usada pela CPU para agilizar a execução de instru­ ções de programa usando técnicas como pré-busca e pipelining. O próximo nível de armazenamento primário é a DRAM {dynamic RAM), que oferece a área de trabalho principal para a CPU, para manter instruções de programa e dados. Ela é popularmente chamada dc memória principal. A vantagem da DRAM é seu baixo custo, que continua a diminuir; a desvantagem é sua volatilidade1 2 c menor velocidade em comparação com a RAM estática. No ninei de armazenamento secundário e terciário, a hierarquia inclui discos magnéticos, bem como armazenamento em massa na forma de dispositivos dc CD-ROM {compact disk-read-only memory) c DVD {digital video disk ou digital versatile disk) c, por fim, fitas no extremo mais barato da hierarquia. A capacidade dc armazenamento é medida em kilobytes (Kbyte ou 1.000 bytes), megabytes (MB ou 1 milhão de bytes), gigabytes (GB ou 1 bilhão de bytes) e até mesmo terabytes (1.000 GB). A palavra petabyte (1.000 terabytes ou 1015 bytes) agora está se tornando relevante no contexto de repositórios muito grandes de dados na física, astronomia, ciências terrestres e outras aplicações científicas. Os programas residem e são executados na DRAM. Em geral, grandes bancos de dados permanentes residem no armazenamento secundário (discos magnéticos) e partes do banco são lidas e escritas de buffers na memória principal conforme a necessidade. Atualmente, os computadores pessoais e as estações de trabalho pos­ suem grandes memórias principais dc centenas dc megabytes dc RAM ou DRAM, dc modo que está se tornando possível carregar uma grande parte do banco de dados na memória principal. Oito a 16 GB de memória principal cm um único servidor está se tornando algo comum em notebooks, e servidores com 256 GB de capacidade não são raros. Em alguns casos, bancos dc dados inteiros podem ser mantidos na memória principal (com uma cópia de backup no disco magnético), levando a ban­ cos dc dados dc memória principal. Estes são particularmente úteis em aplicações de tempo real, que exigem tempos de resposta extremamente rápidos. Um exemplo são as aplicações de comutação de telefone, que armazenam bancos de dados que contêm informações de roteamento e linha na memória principal.

Memória flash. Entre a DRAM e o armazenamento em disco magnético, outra forma de memória, a memória flash, está se tornando comum, principal mente porque ela é não volátil. As memórias flash são de alta densidade e alto desempenho e usam

1 Os autores gostariam dc agradecer a valiosa ajuda de Dan Forsyth com relação ao estado atual dos

sistemas de armazenamento nas empresas. Os autores também desejam agradecer a Satish Damle por

suas sugestões. 2 A memória volátil normalmente perde seu conteúdo em caso de falta de energia, mas com a memória não volátil isso não acontece.

491

492

Sistemas de banco de dados

a tecnologia EEPROM (electrically erasable programmable read-only memory}. A vantagem da memória flash é a velocidade de acesso rápida; a desvantagem é que um bloco inteiro precisa ser apagado e gravado simultaneamente. As memórias flash podem ser de dois tipos, denominados NAND e NOR, com base no ripo de circuito lógico utilizado. Os dispositivos flash NAND possuem capacidade de armazenamento maior para determinado custo e sào usados como meio de armazenamento de dados em aplicações com capacidades variando dc 8 GB a 64 GB para as placas populares, que custam menos dc um dólar por GB. Os dispositivos flash são usados cm câmeras, MP3/MP4 players, telefones celulares, PDAs (personal digital assistants}, e assim por diante. Unidades flash USB (universal serial bus) tornaram-se o meio mais portátil para transportar dados entre computadores pessoais; elas têm um dispositivo de armazenamento de memória flash integrado a uma interface USB. Unidades ópticas. A forma mais popular de armazenamento óptico removível sào os CDs (compact disks} c os DVDs. Os CDs possuem capacidade de 700 MB, enquanto os DVDs têm capacidades que variam dc 4,5 a 15 GB. Os CD-ROMs (compact disk — read only memory) armazenam dados opticamente e são lidos por um dispositivo a laser. Os CD-ROMs contêm dados pré-gravados que não podem ser modificados. A versão dos discos compactos e de vídeo digital, chamada CD-R (compact disk recordable) e DVD-R ou DVD+R, que também são conhecidos como WORM (unite-once-read-many), é uma forma dc armazenamento óptico usado para arquivar dados; eles permitem que os dados sejam gravados uma vez e lidos qualquer número de vezes sem a possibilidade de apagamento. Eles mantêm cerca de meio gigabyte de dados por disco e duram muito mais que os discos magnéticos.3 Um formato de maior capacidade para os DVDs, chamado DVD Blu-ray, pode armazenar 27 GB por camada, ou 54 GB cm um disco de duas camadas. Memórias de jukebox óptico utilizam um conjunto de placas de CD-ROM, que são carregadas cm unida­ des por demanda. Embora os jukeboxes ópticos tenham capacidades na ordem de centenas de gigabytes, seus tempos de recuperação estão na ordem de centenas de milissegundos, muito mais lento que os discos magnéticos. Esse ripo de armazena­ mento terciário continua a diminuir cm decorrência da rápida diminuição no custo e do aumento nas capacidades dos discos magnéticos. A maioria das unidades de disco de computador pessoal agora lê discos de CD-ROM e DVD. Normalmente, as unidades são CD-R (compact disk recordable) que podem criar CD-ROMs e CDs de áudio (compact disks), bem como gravar DVDs.

Fitas magnéticas. Finalmente, as fitas magnéticas são usadas para arquivamento e armazenamento de backup dos dados. Os jukeboxes de fita — que contêm um banco de fitas que são catalogadas e podem ser carregadas automaticamente nas unidades dc fita — estão se tornando populares como armazenamento terciário, para manter terabytes dc dados. Por exemplo, o sistema satélite dc observação da Terra (EOS — Earth Observation Satellite) da NASA armazena bancos de dados arquivados dessa forma. Muitas organizações grandes já possuem bancos de dados com tamanhos na ordem dos terabytes. O termo banco dc dados muito grande não pode mais ser definido com exatidão, pois as capacidades dc armazenamento cm disco estão aumentando, e os custos, diminuindo. Logo, o termo banco de dados muito grande pode ser reservado para bancos de dados com centenas de terabytes ou petabytes. Para resumir, uma hierarquia de dispositivos e sistemas de armazenamento está disponível hoje para o armazenamento de dados. Dependendo do uso pretendido ’ Suas velocidades de rotação são mais baixas (em tomo de 400 rpm), gerando maiores atrasos de latcncia c baixas taxas dc transferencia (cm tomo dc 100 a 200 KB/scgundo) para driver IX. Drivers nX (por exemplo: 16X, em que w=16) devem atingir uma taxa de transferência superior multiplicando rpm

n vezes. A taxa de transferência de DVD

IX é mais ou menos 1,385 MB/s.

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

e dos requisitos da aplicação, os dados sào mantidos em um ou mais níveis dessa hierarquia. A Tabela 16.1 resume o estado atual desses dispositivos e sistemas, mostrando a variedade de capacidades, os tempos médios de acesso, as larguras de banda (velocidades de transferência) e os custos no mercado aberto de commodities. O custo do armazenamento geralmente diminui em todos os níveis dessa hierarquia. Tabela 16.1 Tipos de armazenamento com capacidade, tempo de acesso, largura de banda (velocidade de transferência) máxima e custo da commodity.

Tipo

* Capacidade

Tempo de

Largura de

acesso

banda máxima

Preços de

commodity (2014) **

Memória principal - RAM

4 GB-1TB

30 ns

35 GB/s

USS100-USS 20K

Memória flash - SSD

64 GB-1TB

50 ps

750 MB/s

USS 50-USS 600

Memória flash - pen drive

4GB-512GB

100 ps

50 MB/s

USS 2-USS 200

Disco magnético

400GB-8TB

10 ms

200 MB/s

US$ 70-USS 500

Armazenamento óptico

50 GB-100 GB

180 ms

72 MB/s

US$100

Fita magnética

2.5TB-8.5TB

10s-80s

40-250 MB/s

USS 2.5K-USS 30K

Jukebox de fita

25 TB-2.100.000 TB

10s-80s

250 MB/s-1,2 PB/s

US$ 3K-USS1M+

’ As capacidades são baseadas em unidades populares disponíveis comercial mente em 2014. Os custos são baseados cm mercados de commodity on-line.

16.1.2 Organização do armazenamento de bancos de dados Os bancos de dados costumam armazenar grande quantidade de dados que preci­ sam persistir por longos períodos de tempo e, portanto, costumam ser considerados dados persistentes. Partes desses dados sào acessadas e processadas repetidamente durante esse período de armazenamento. Isso é contrário à noção de dados transientes, que persistem apenas por um tempo limitado durante a execução do programa. A maioria dos bancos de dados é armazenada de maneira permanente (ou persistente­ mente} no armazenamento secundário do disco magnético, pelos seguintes motivos: ■ Em geral, os bancos de dados são muito grandes para caber inteiramente na memória principal.4 ■ As circunstâncias que causam perda permanente de dados armazenados surgem com menos frequência para o armazenamento de disco secundário que para o armazenamento primário. Logo, referimo-nos ao disco — e a outros dispositivos de armazenamento secundário — como armazenamento não volátil, ao passo que a memória principal normalmente é chamada de armazenamento volátil. ■ O custo de armazenamento por unidade de dados está na ordem de grandeza menor para o armazenamento dc disco secundário que para o armazenamento primário.

Algumas das tecnologias mais novas, como discos em unidade de estado sólido (SSD), provavelmente oferecem alternativas viáveis ao uso de discos magnéticos. No futuro, portanto, os bancos de dados poderão residir em diferentes níveis de hierarquia dc memória, com base nas descritas na Seção 16.1.1. Os níveis podem variar do armazenamento cm nível dc memória principal dc velocidade mais alta até o jukebox de fita, com velocidade mais baixa de armazenamento off-line. Contudo, já se sabe que os discos magnéticos continuarão a ser o meio de escolha principal

4 Essa afirmação está sendo desafiada pelos recentes desenvolvimentos nos sistemas dc banco dc dados

da memória principal. Exemplos de sistemas comerciais proeminentes sào HANA, da SAP, e T1MESTEN, da Oracle.

493

494

Sistemas de banco de dados

para bancos de dados grandes por muitos anos. Logo, é importante estudar e enten­ der as propriedades e as características dos discos magnéticos e o modo como os arquivos podem ser organizados neles a fim de projetar bancos de dados eficazes, com desempenho aceitável. As fitas magnéticas são frequentemente usadas como meio de armazenamento para o backup de bancos de dados, pois o armazenamento em fita custa ainda menos que o armazenamento em disco. Alguma intervenção por um operador — ou um dispositivo de carga automática — para carregar uma fita é necessária antes que os dados se tomem dispo níveis para processamento. Ao contrário, os discos são dispositivos on-line, que podem ser acessados diretamente a qualquer momento. As técnicas utilizadas para armazenar grande quantidade de dados estruturados em disco são importantes para os projetistas de banco de dados, para o DBA e para implementadores de um SGBD. Os projetistas de banco de dados e o DBA precisam conhecer as vantagens e as desvantagens de cada técnica de armazenamento quando projetam, implementam e operam um banco de dados em um SGBD específico. Em geral, o SGBD tem várias opções disponíveis para organizar os dados. O processo de projeto físico dc banco dc dados envolve a escolha das técnicas de organização de dados cm particular que mais se ajustam a determinados requisitos da aplicação entre as opções. Os implementadores dc sistema dc SGBD devem estudar as técnicas de organização de dados de modo que possam implementá-las de modo eficaz e, portanto, oferecer opções suficientes ao DBA e aos usuários do SGBD. As aplicações dc banco dc dados típicas só precisam dc uma pequena parte do banco de dados de cada vez para processamento. Sempre que certa parte dos dados é necessária, ela precisa ser localizada no disco, copiada para a memória principal para processamento e, depois, reescrita para o disco se os dados forem alterados. Os dados armazenados no disco são organizados como arquivos de registros. Cada registro é uma coleção de valores de dados que podem ser interpretados como fatos sobre entidades, seus atributos e relacionamentos. Os registros devem ser armaze­ nados cm disco de uma maneira que torne possível localizá-los de modo eficiente quando necessário. Discutiremos na Seção 17.2.2 algumas das técnicas para tornar o acesso ao disco mais eficiente. Existem várias organizações dc arquivo primário que determinam como os regis­ tros de arquivo são colocados fisicamente no disco e, daí, como os registros podem ser acessados. Um arquivo de heap (ou arquivo desordenado) coloca os registros no disco sem qualquer ordem em particular, acrescentando novos registros ao final do arquivo, ao passo que um arquivo classificado (ou arquivo sequencial) mantém os registros ordenados pelo valor de um campo em particular (chamado campo de classificação). Um arquivo em bashing usa uma função de hash aplicada a um campo em particular (chamado chave hash) para determinar o posicionamento de um registro no disco. Outras organizações de arquivo primárias, como B-trees, usam estruturas em árvore. Discutimos as principais organizações de arquivo nas seções 16.6 a 16.9. Uma organização secundária ou estrutura de acesso auxiliar permite acesso eficiente aos registros do arquivo com base em campos alternativos, além dos que foram usados para a organização dc arquivo primário. A maioria destes existe como índices e será discutida no Capítulo 17.

16.2 Dispositivos de armazenamento secundários Nesta seção, descrevemos algumas características dos dispositivos de armaze­ namento cm disco magnético e fita magnética. Os leitores que já estudaram esses dispositivos podem simplesmente folhear esta seção.

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

495

16.2.1 Descrição de hardware dos dispositivos de disco Os discos magnéticos são usados para armazenar grande quantidade de dados. O dispositivo que mantém os discos é chamado de unidade de disco rígido, ou HDD (do inglês bard disk drive). A unidade de dados mais básica no disco é um único bit de informação. Ao magnetizar uma área do disco dc certas maneiras, podc-sc fazer que ele represente um valor de bit de 0 (zero) ou 1 (um). Para codificar a informação, os bits são agrupados em bytes (ou caracteres). Os tamanhos de byte normalmenre variam de 4 a 8 bits, dependendo do computador e do dispositivo; 8 bits é a quantidade mais comum. Consideramos que um caractere é armazenado cm um único byte, e usamos os termos byte c caractere para indicar a mesma coisa. A capacidade de um disco é o número de bytes que ele pode armazenai; que em geral é muito grande. Pequenos disquetes foram usados com microcomputadores e notebooks durante muitos anos — eles costumavam manter de 400 KB a 1,5 MB; hoje, estão quase totalmente fora de circulação. Os discos rígidos para computadores pessoais normalmenre mantém de várias centenas de gigabytes (GB) até alguns terabytes (TB); c grandes volumes dc disco usados com servidores e mainframes têm capacidades de centenas de gigabytes. As capacidades de disco continuam a crescer à medida que a tecnologia se aperfeiçoa. Independentemente de sua capacidade, rodos os discos são feitos de um material magnético na forma de um disco circular fino, como mostra a Figura 16.1(a), e pro­ tegidos por uma camada dc plástico ou acrílico. Um disco é dc face simples se arma­ zenar informações apenas cm uma dc suas superfícies, c dc face dupla se as duas superfícies forem usadas. Para aumentar a capacidade de armazenamento, os discos são montados em um volume de discos, como mostra a Figura 16.1(b), que pode incluir muitos discos e, portanto, muitas superfícies. As informações são armazenadas em uma superfície do disco cm círculos concêntricos dc pequena largura,5 cada um com um diâmetro distinto. Cada círculo é chamado dc trilha. Em volumes de discos, Trilha

Acionador

Braço

Cabeça de leitura/ gravação

Eixo

Rotação do disco

(b)

Cilindro — de trilhas (imaginário) Figura 16.1 (a) Um disco de 7

face simples com hardware de

leitura/gravação. (b) Um volume

de discos com hardware de

Movimento do acionador

5 Em alguns discos, os círculos agora são conectados em um ripo de espiral contínua.

leitura/gravação.

496

Sistemas de banco de dados

as trilhas com o mesmo diâmetro nas diversas superfícies formam um cilindro, pela forma que elas teriam se fossem conectadas no espaço. O conceito de cilindro é impor­ tante porque os dados armazenados em um cilindro podem ser recuperados muito mais rapidamente do que se fossem distribuídos entre diferentes cilindros. O número de trilhas em um disco varia de alguns milhares até 152.000 nas unidades de disco mostradas na Tabela 16.2, e a capacidade de cada trilha normal­ mente varia de dezenas de KB até 150 KB. Como uma trilha cm geral contém uma grande quantidade de informações, ela é dividida em blocos menores, ou setores. A divisão de uma trilha em setores é marcada na superfície do disco e não pode ser alterada. Um tipo de organização de setor, como mostra a Figura 16.2(a), chama uma parte da trilha que se estende por um ângulo fixo no centro de um setor. Várias outras organizações dc setor são possíveis, e uma delas é fazer que os setores se estendam por ângulos menores no centro à medida que se move para fora, mantendo assim uma densidade de gravação uniforme, como mostra a Figura 16.2(b). Uma técnica chamada ZBR {zone bit recording) permite que um intervalo de cilindros tenha o mesmo número de setores por arco. Por exemplo, os cilindros 0-99 podem ter um setor por trilha, 100-199 podem ter dois por trilha, e assim por diante. O tamanho padrão de setor é de 512 bytes. Nem todos os discos tem suas trilhas divididas cm setores. Tabela 16.2 Especificações de discos típicos de alto nível da Seagate, (a) Seagate Enterprise Performance 10K HDD - 1200 GB.

Especificações

1.200 GB

Número do modelo SED

ST1200MM0017

Número do modelo SED FIPS 140-2

ST1200MM0027

Nome do modelo

Enterprise Performance 10K HDD v7

Interface

6 Gb/s SAS

Capacidade Formatada com 512 bytes/setor (GB)

1.200

Taxa de transferência externa (MB/s)

600

Desempenho

Velocidade do eixo (RPM)

10K

Latência média (ms)

2,9

Taxa de transferência sustentada do diâmetro externo ao interno (MB/s)

204 a 125

Cache multissegmentado (MB)

64

Configuração/confiabilidade Discos

4

Cabeças

8

Erro de leitura não recuperável por bits lidos

1 por 10E16

Taxa de falha anual (AFR)

0,44% Físico

Altura (pol./mm. máxima)

0,591/15,00

Largura (poL/mm, máxima)

2,760/70,10

Profundidade (poL/mm, máxima)

3,955/100,45

Peso (Ib/kg)

0,450/0,204

Fonte: cortesia da Seagate Technology

(contínua)

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

Tabela 16.2 (b) Características internas da unidade de discos Seagate de 300 GB a 900 GB.

497

(Continuação)

ST900MM0006

ST600MM0006

ST450MM0006

ST300MM0006

ST900MM0026

ST600MM0026

ST450MM0026

ST300MM0026

ST900MM0046

ST600MM0046

ST450MM0046

ST300MM0046

ST900MM0036 Capacidade da

GB (formatados, 900

600

450

300

6

4

3

2

Bytes por trilha

997,9

997,9

997,9

997,9

Bytes por superfície

151.674

151.674

151.674

151.674

152

152

152

152

279

279

279

279

KTPI (média)

1.925

1.925

1.925

1.925

KBPI

538

538

533

533

Gb/pol.2

10K

10K

10K

10K

rpm

2,9

2,9

2,9

2.9

ms

unidade Cabeças de leitura/ gravação de dados

Trilhas por superfície

(total) Trilhas por polegada

Pico de bits por polegada

Densidade de área Velocidade de rotação

do disco Latência de rotação média

(a)

arredondado)

KBytes (média, valo­

res arredondados) MB (não formatados, arredondado)

KTrilhas (acessíveis ao usuário)

Setor (arco de trilha)

(b)

Figura 16.2 Diferentes

organizações de setor no disco, (a) Setores se estendendo por um ângulo fixo, (b) Setores

mantendo uma densidade de

gravação uniforme.

A divisão dc uma trilha cm blocos dc disco (ou páginas) dc mesmo tamanho é definida pelo sistema operacional durante a formatação (ou inicializaçãoI do disco. O tamanho do bloco é fixado no decorrer da inicialização e não pode ser trocado dinamicamente. Os tamanhos de bloco de disco típicos variam de 512 a 8.192 bytes. Um disco com setores fixos costuma ter os setores subdivididos em blocos durante a inicialização. Os blocos são separados por lacunas entre blocos dc tamanho fixo, que incluem informações de controle especialmente codificadas, gravadas durante a inicialização do disco. Essa informação é usada para determinar qual bloco da trilha segue cada lacuna entre blocos. A Tabela 16.2 ilustra as especificações dos discos típicos usados em grandes servidores na indústria. O prefixo 10K nos nomes de disco refere-se às velocidades de rotação em rpm (rotações por minuto).

498

Sistemas de banco de dados

Há uma melhora contínua na capacidade de armazenamento e nas taxas de trans­ ferência associadas aos discos. Eles também estão ficando cada vez mais baratos — hoje, custam apenas uma fração de um dólar por megabyte de armazenamento em disco. Os custos estão se reduzindo tão rapidamente que já chegaram a USS 100/TB. Um disco é um dispositivo endereçável por acesso aleatório. A transferência de dados entre a memória principal e o disco ocorre em unidades de blocos de disco. O endereço dc hardware dc um bloco — uma combinação dc número dc cilindro, número de trilha (número dc superfície no cilindro cm que a trilha está localizada) e número de bloco (dentro da trilha) —é fornecido ao hardware de E/S (entrada/saída) do disco. Em muitas unidades de disco modernas, um único número, chamado LBA (logical block address), que é um número entre 0 e n (considerando que a capacidade total do disco cn + 1 blocos), c mapeado automaticamente para o bloco correto pelo controlador da unidade de disco. O endereço de um buffer — uma área reservada contígua no armazenamento principal, que mantém um bloco de disco — também é fornecido. Para um comando de leitura, o bloco de disco é copiado para o buffer, ao passo que, para um comando de gravação, o conteúdo do buffer é copiado para o bloco dc disco. Às vezes, vários blocos contíguos podem ser transferidos como

uma unidade, denominada cluster. Nesse caso, o tamanho do buffer é ajustado para corresponder ao número de bytes no cluster. O mecanismo de hardware real que lê ou grava um bloco é a cabeça de leitura/ gravação do disco, que faz parte dc um sistema chamado unidade dc disco. Um disco ou volume de discos é montado na unidade, que inclui um motor que gira os discos. Uma cabeça dc leitura/gravação inclui um componente eletrônico conectado a um braço mecânico. Os volumes de discos com superfícies múltiplas são controlados por várias cabeças de leitura/gravação — uma para cada superfície, como mostra a Figura 16.1(b). Todos os braços são conectados a um acionador ligado a outro motor elétrico, que move as cabeças de leitura/gravação em harmonia e as posiciona exatamente sobre o cilindro dc trilhas especificado em um endereço dc bloco. As unidades de disco rígido giram o volume continuamente a uma velocidade constante (em geral, variando entre 5.400 e 15.000 rpm). Quando a cabeça de leitura/ gravação está posicionada na trilha correra e o bloco especificado no endereço de bloco move-se sob a cabeça de leitura/gravação, o componente eletrônico da cabeça de lei­ tura/gravação é ativado para transferir os dados. Algumas unidades de disco possuem cabeças dc leitura/gravação fixas, com o número dc cabeças correspondente ao de trilhas. Estes são chamados discos de cabeça fixa, ao passo que as unidades de disco com um acionador são chamadas de discos de cabeça móvel. Para os discos de cabeça fixa, uma trilha ou cilindro é selecionado eletronicamente, passando para a cabeça de leitura/gravação apropriada, em vez de por um movimento mecânico; em consequência, isso é muito mais rápido. Porém, o custo das cabeças de leitura/gravação adicionais é muito alto, de modo que os discos com cabeça fixa não são muito utilizados. Interface de unidades de disco com sistemas de computação. Um controlador dc disco, normalmente embutido na unidade de disco, controla a unidade de disco e a interliga ao sistema de computação. Uma das interfaces-padrão usadas para unidades de disco nos PCs e estações de trabalho se chamava SCSI (small computer system inter­ face). Hoje, para conectar unidades de disco rígido, CDs e DVDs a um computador, a interface escolhida é a SATA. SATA significa Serial ATA, e ATA representa attachment (ligação); assim, SATA torna-se ligação serial. Ela tem sua origem na ligação do PC/ AT, que se referia à ligação direta ao barramento de 16 bits introduzido pela IBM. O AT era uma referência a tecnologia avançada, mas não é usado na expansão do SATA por questões de marca registrada. Outra interface popular usada atualmente é chamada dc SAS (Serial Attached SCSI). A SATA foi introduzida cm 2002 c permite que o controlador dc disco esteja na unidade dc disco; a placa-mãc só precisa ter um

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

circuito simples. As velocidades de transferência SATA passaram por uma evolução de 2002 a 2008, indo de 1,5 Gbps (gigabits por segundo) para 6 Gbps. A SATA agora é chamada de NL-SAS, significando nearline SAS (S/\S perto da linha). As maiores unidades SATA e SAS de 3,5 polegadas são de 8 TB, ao passo que as unidades SAS de 2,5 polegadas são menores e vão até 1,2 TB. As unidades de 3,5 polegadas utilizam velocidades de 7.200 ou 10.000 rpm, ao passo que as unidades de 2,5 polegadas alcançam 15.000 rpm. Em termos de lOPs (operações dc entrada/saída) por segundo como um fator custo/dcsempenho, a SAS é considerada superior à SATA. O controlador aceita comandos de E/S de alto nível e age de maneira apropriada para posicionar o braço e fazer que aconteça a ação de leitura/gravação. Para transferir um bloco de disco, dado seu endereço, o controlador de disco primeiro deve posicionar mecanicamente a cabeça dc leitura/gravação na trilha correta. O tempo exigido para fazer isso é chamado tempo de busca. Os tempos de busca típicos são de 5 a 10 ms em desktops e de 3 a 8 ms em servidores. Depois disso, existe outro atraso — cha­ mado de atraso rotacional ou latência — enquanto o início do bloco desejado gira até a posição sob a cabeça de leitura/gravação. Isso depende das rpm do disco. Por exemplo, a 15.000 rpm, o tempo por rotação é de 4 ms e o atraso rotacional medio é o tempo por meia rotação, ou 2 ms. A 10.000 rpm, o atraso rotacional medio aumenta para 3 ms. Finalmente, algum tempo adicional é necessário para transferir os dados; este é chamado tempo de transferência de bloco. Logo, o tempo total necessário para localizar e transferir um bloco qualquer, dado seu endereço, é a soma do tempo de busca, do atraso rotacional c do tempo dc transferência dc bloco. O tempo dc busca c o atraso rotacional costumam ser muito maiores que o tempo dc transferência dc bloco. Para tomar a transferência de múltiplos blocos mais eficiente, é comum trans­ ferir vários blocos consecutivos na mesma trilha ou cilindro. Isso elimina o tempo de busca e o arraso rotacional para todos, menos o primeiro bloco, e pode resultar em uma economia de tempo substancial quando vários blocos contíguos são transferidos. Normalmente, o fabricante do disco oferece uma taxa dc transferência cm massa a fim de calcular o tempo exigido para transferir blocos consecutivos. O Apêndice B contém uma discussão sobre esses e outros parâmetros de disco. O tempo necessário para localizar e transferir um bloco de disco está na ordem de milissegundos, em geral variando de 9 a 60 ms. Para blocos contíguos, localizar o primeiro bloco leva dc 9 a 60 ms, mas transferir os blocos subsequentes pode levar apenas 0,4 a 2 ms cada. Xluitas técnicas de busca tiram proveito da recuperação consecutiva de blocos ao procurar dados no disco. De qualquer forma, um tempo de transferência na ordem de milissegundos é considerado bastante alto em com­ paração com o tempo exigido para processar os dados na memória principal pelas CPUs atuais. Logo, a localização dos dados no disco é um gargalo principal nas aplicações de banco de dados. As estruturas de arquivo que discutimos aqui e no Capítulo 17 tentam minimizar o número de transferências de bloco necessárias para localizar e transferir os dados exigidos do disco para a memória principal. Colocar “informações relacionadas” em blocos contíguos é o objetivo básico de qualquer organização de armazenamento no disco.

16.2.2 Tornando o acesso aos dados mais eficiente no disco Nesta subseção, listamos algumas das técnicas comumente usadas para tornar o acesso aos dados mais eficiente nas unidades de disco rígido.

1. Buffering de dados: para lidar com a incompatibilidade de velocidades entre uma CPU e o dispositivo eletromecânico, como uma unidade de disco, que é inerentemente mais lenta, o buffering de dados é feiro na memória, para que novos dados possam ser mantidos em um buffer enquanto os dados antigos

499

500

Sistemas de banco de dados

são processados por uma aplicação. Discutimos a estratégia de buffering duplo seguida de problemas gerais de gerenciamento de buffer e estratégias de substi­ tuição de buffer na Seção 16.3.

2. Organização adequada dos dados no disco: dadas a estrutura e a organização dos dados no disco, é vantajoso manter dados relacionados em blocos contíguos; quando são necessários múltiplos cilindros por uma relação, cilindros contíguos devem ser usados. Isso evita o movimento desnecessário do braço de leitura/ gravação e os tempos de busca relacionados. 3. Leitura de dados antes de serem solicitados: para minimizar os tempos de busca, sempre que um bloco é lido para o buffer, os blocos do restante da trilha também podem ser lidos, mesmo que ainda não tenham sido solicitados. Isso funciona bem para aplicações que provavelmente precisarão dc blocos consecutivos; para leituras de blocos aleatórios, esta estratégia é contraproducente. 4. Escalonamento adequado de solicitações dc E/S: se for necessário ler vários blo­ cos do disco, o tempo total de acesso pode ser minimizado escalonando-os para que o braço se mova somente em uma direção e capture os blocos ao longo de seu movimento. Um algoritmo popular é chamado de algoritmo do elevador; ele imita o comportamento de um elevador, que programa as solicitações de vários andares em uma sequência apropriada. Dessa forma, o braço pode atender pedi­ dos ao longo de seus movimentos para fora e para dentro sem muita interrupção. 5. Uso de discos de registro para manter as escritas temporariamente: um único disco pode ser atribuído a apenas uma função chamada registro (log) de escritas. Todos os blocos a serem escritos podem ir para esse disco sequencialmente, eliminando assim qualquer tempo de busca. Isso funciona muito mais rápido que fazer as escritas em um arquivo em locais aleatórios, o que requer uma busca para cada escrita. O disco de log pode ordenar essas escritas em ordem (cilindro, trilha) para minimizar o movimento do braço ao escrever. Na verdade, o disco dc registro pode ser apenas uma área (extensão) de um disco. Ter o arquivo de dados e o arquivo de registro no mesmo disco é uma solução mais barata, mas compromete o desempenho. Embora a ideia de um disco de registro possa melhorar o desempenho da escrita, ela não é viável para a maioria dos dados de aplicações da vida real.

6. Uso de SSDs ou de memória flash para fins de recuperação: em aplicações nas quais as atualizações ocorrem com alta frequência, as atualizações podem ser perdidas da memória principal se o sistema falhar. Uma medida preventiva seria aumentar a velocidade das atualizações/escritas no disco. Uma técnica possível envolve a escrita das atualizações para um buffer SSD não volátil, que pode ser uma memória flash ou DRAM alimentada por bateria, ambas operando em velocidades muito mais rápidas (ver Tabela 16.1). O controlador de disco, então, atualiza o arquivo de dados durante seu tempo de inatividade e também quando o buffer se enche. Durante a recuperação de uma falha, os buffers SSD não gravados devem ser registrados no arquivo de dados na unidade de disco. Para obter mais detalhes sobre recuperação e logs, consulte o Capítulo 22.

16.2.3 Armazenamento em dispositivo no estado sólido (SSD) Este tipo de armazenamento às vezes é conhecido como armazenamento flash, porque é baseado na tecnologia da memória flash, que discutimos na Seção 16.1.1. A tendência recente é usar memórias flash como uma camada intermediária entre a memória principal e o armazenamento rotativo secundário na forma de discos magnéticos (HDDs). Como eles se assemelham a discos em termos de capacidade de armazenar dados em armazenamento secundário sem a necessidade de alimentação contínua, são chamados dc discos dc estado sólido ou unidades dc estado sólido

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

(SSDs, do inglês solid-state drives). Primeiro, discutiremos SSDs em termos gerais, e depois comentaremos seu uso no nível corporativo, no qual às vezes sào chama­ dos de drives flash corporativos (EFDs, do inglês enterprise flash drives), um termo introduzido pela EMC Corporation. O componente principal de um SSD é um controlador e um conjunto de cartões de memória flash interconectados. O uso da memória flash NAND é mais comum. O uso de formatos compatíveis com HDDs de 3,5 polegadas ou 2,5 polegadas torna os SSDs conectávcis em slots já disponíveis para a montagem de HDDs em notebooks e servidores. Para ultrabooks, tablets e similares, estão sendo padronizados formatos baseados em cartões, como mSATA e M.2. Interfaces como SATA express foram criadas para acompanhar os avanços nas SSDs. Como nào há partes móveis, a unidade é mais robusta, roda silenciosamente, é mais rápida em termos de tempo de acesso e fornece taxas de transferência maiores que uma HDD. Ao contrário das HDDs, em que os dados relacionados da mesma relação devem ser colocados em blocos contíguos, de preferência em cilindros contíguos, nào há restrição na colocação de dados em uma SSD, pois qualquer endereço é diretamente endereçável. Como resultado, há menos chance de os dados serem fragmentados; portanto, nenhuma reorganização é neces­ sária. Normalmenre, quando uma gravação em disco ocorre em uma HDD, o mesmo bloco é substituído por novos dados. Em SSDs, os dados são gravados cm diferentes células NAND para atingir o nivelamento de desgaste, o que prolonga a vida útil da SSD. O principal problema que impede uma adoção em larga escala de SSDs hoje é seu custo proibitivo (ver Tabela 16.1), que costuma ser de cerca de 70 a 80 centavos dc dólar por GB, ao contrário dos 15 a 20 centavos por GB para HDDs. Além da memória flash, também estão disponíveis SSDs baseadas em DRAM. Elas são mais caras que a memória flash, mas oferecem tempos de acesso mais rápidos, de cerca de 10 ps (microssegundos), comparados com os 100 ps para a memória flash. A principal desvantagem é que eles precisam de uma batería interna ou de um adaptador para fornecer energia. Como exemplo dc SSD em nível corporativo, podemos considerar as SSDs da série Invicta UCS (Unified Computing System0) da CISCO. Eles permitiram a implantação de SSDs no nível do datacenter para unificar as cargas de trabalho de todos os tipos, incluindo bancos de dados e infraestrutura dc desktop virtual (VDI, do inglês virtual desktop infrastructure), c para permitir uma solução econômica, eficiente cm termos dc energia e com economia de espaço. A CISCO afirma que as SSDs Invicta oferecem melhor relação preço-desempenho para as aplicações em uma arquitetura de múltiplas locações e redes, pelas vantagens das SSDs anteriormente indicadas. /\ CISCO afirma que, normalmente, quatro vezes mais unidades HDD poderíam ser necessárias para igualar o desempenho de uma arquitetura RAID baseada em SSD.67A configuração SSD pode ter uma capacidade de 6 a 144 TB, com até 1,2 milhão de operações de E/S por segundo e uma largura de banda de até 7,2 GB/s, com uma latência média de 200 ps. Os centros de dados modernos estão passando por uma rápida transformação e devem fornecer resposta em tempo real usando arquiteturas baseadas em nuvem. Nesse ambiente, as SSDs provavelmente desempenharão um papel importante.

16.2.4 Dispositivos de armazenamento de fita magnética Discos sào dispositivos dc armazenamento secundário de acesso aleatório, pois um bloco de disco qualquer pode ser acessado aleatoriamente depois que especifi­ camos seu endereço. As fitas magnéticas são dispositivos de acesso sequencial; para

6 Baseado no CISCO White Paper (CISCO, 2014). 7 Data sheet para o UCS Invicta Scaling System da CISCO.

501

502

Sistemas de banco de dados

acessar o enésimo bloco na fita, primeiro temos de varrer os n - 1 blocos anterio­ res. Os dados sào armazenados em bobinas de fita magnética de alta capacidade, semelhantes às fitas de áudio ou vídeo. Uma unidade de fita precisa ler os dados ou gravá-los em uma bobina de fita. Em geral, cada grupo de bits que forma um byte é armazenado na fita, e os próprios bytes sào armazenados consecutivamente nela. Uma cabeça de leitura/gravaçào é usada para ler ou gravar dados na fita. Os regis­ tros dc dados na fita também sào armazenados cm blocos — embora os blocos possam ser substancialmentc maiores que os dos discos, e as lacunas entre blocos também sejam muito grandes. Com densidades de fita típicas de 1.600 a 6.250 bytes por polegada, uma lacuna entre blocos típica8 de 0,6 polegada corresponde a 960 até 3.750 bytes de espaço de armazenamento desperdiçado. É comum agrupar muitos

registros cm um bloco para melhorar a utilização do espaço. A principal característica de uma fita é seu requisito de que acessemos os blocos de dados em ordem sequencial. Para chegar até um bloco no meio da bobina de fira, esta é montada e depois varrida até que o bloco solicitado passe sob a cabeça de leitura/gravaçào. Por esse motivo, o acesso da fita pode ser lento e elas nào são usadas para armazenar dados on-line, exceto para algumas aplicações especializadas. Porém, as fitas têm uma funçào muito importante — backup do banco dc dados. Uma razão para haver backup é manter cópias de arquivos dc disco no caso dc perda de dados por uma falha no disco, que pode acontecer se a sua cabeça de leitura/ gravação tocar na superfície por um defeito mecânico. Por esse motivo, os arquivos dc disco sào copiados periodicamente para a fita. Para muitas aplicações críticas on-line, como sistemas dc reserva aérea, para evitar qualquer tempo dc paralisação, são usados sistemas espelhados para manter três conjuntos de discos idênticos — dois em operação on-line e um como backup. Aqui, os discos off-line tornam-se um dispositivo de backup. Os três são usados de modo que possam ser trocados caso haja uma falha em uma das unidades de disco ativas. As fitas também podem ser utilizadas para armazenar arquivos dc banco de dados excessivamente grandes. Os arquivos do banco dc dados que raramente sào usados ou cstào desatualizados, mas sào necessários para manutenção de registro histórico, podem ser arquivados em fita. Originalmente, as unidades de fita com bobina de meia polegada eram usadas para o armazenamento de dados, empregando as chamadas fitas de nove trilhas. Mais tarde, fitas magnéticas menores, dc 8 mm (semelhantes às usadas em filmadoras portáteis), que podem armazenar até 50 GB, bem como os cartuchos de dados de varredura helicoidal de 4 mm e CDs e DVDs graváveis, tornaram-se mídia popular para o backup de arquivos de dados de PCs e estações de trabalho. Eles também são usados para armazenar imagens e bibliotecas de sistemas. O backup de bancos de dados corporativos, de modo que nenhuma informação de transação seja perdida, é uma tarefa importante. As bibliotecas de fitas eram bastante comuns, com slots para várias centenas de cartuchos; essas bibliotecas eram usadas com Digital e Superdigital Linear Tapes (DLTs e SDLTs), com capacidades na ordem de centenas de gigabytes, que registram dados em trilhas lineares. Atualmente, essas bibliotecas de fitas não estão mais sendo desenvolvidas. O consórcio LTO (Linear Tape Open), formado por IBM, HP e Seagate, lançou o último padrão LTO-6 em 2012 para fitas. Ele usa fitas magnéticas de meia polegada, como as usadas nas unidades de fita mais antigas, mas em um cartucho menor; em uma bobina única. A geração atual de bibliotecas utiliza unidades LTO-6, em cartucho de 2,5 TB, com uma taxa de transferência de 160 MB/s. O tempo dc busca médio está em torno dc 80 segundos. A unidade T10000D da Oracle/StorageTck lida com 8,5 TB em um único cartucho, com uma taxa de transferência de até 252 MB/s.

s Chamadas dc lacunas entre registros cm terminologia dc fita.

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

503

Braços robóticos são usados para gravar em vários cartuchos em paralelo, utili­ zando várias unidades de fita com software de rotulagem automático para identificar os cartuchos de backup. Um exemplo de biblioteca gigante é o modelo SL8500 da Sun Storage Technology. A SL8500 varia de 1.450 a mais de 10.000 slots e de 1 a 64 unidades de fita dentro de cada biblioteca. Ela aceita fitas DLT/SDLT e LTO. Até 10 SL8500s podem ser conectadas dentro de um único complexo de bibliotecas para mais de 100.000 slots e até 640 unidades. Com 100.000 slots, a SL8500 pode arma­ zenar 2,1 exabytes (1 exabyte = 1.000 petabytes, ou 1 milhão de TB = IO18 bytes). Vamos adiar a discussão sobre a tecnologia de armazenamento de disco chamada RAID, e sobre as áreas de armazenamento em rede, armazenamento conectado à rede e sistemas de armazenamento iSCSI para o final do capítulo.

16.3 Buffering de blocos Quando vários blocos precisam ser transferidos do disco para a memória principal e todos os endereços de bloco são conhecidos, vários buffers podem ser reservados na memória principal para agilizar a transferência. Enquanto um buffer está sendo lido ou gravado, a CPU pode processar dados em outro, pois existe um processador (controlador) de E/S de disco separado que, uma vez iniciado, pode prosseguir para transferir um bloco de dados entre a memória e o disco independente e em paralelo com o processamento da CPU. A Eigura 16.3 ilustra como dois processos podem prosseguir em paralelo. Os processos A e B estão rodando simultaneamente em um padrão intervalado, cm que os processos C c D estão rodando simultaneamente em um padrão paralelo. Quando uma única CPU controla vários processos, a execução paralela não é possível. Contudo, os processos ainda podem ser executados de maneira simultânea de uma forma intervalada. O buffering é mais útil quando os processos podem ser executados simultaneamente em um padrão paralelo, seja porque existe um processador dc E/S de disco separado ou porque há vários processadores (CPUs). A Figura 16.4 ilustra como a leitura e o processamento podem prosseguir em para­ lelo quando o tempo exigido para processar um bloco de disco na memória é menor que o tempo exigido para ler o bloco seguinte e preencher um buffer. A CPU pode começar a processar um bloco quando sua transferência para a memória principal termina; ao mesmo tempo, o processador de E/S de disco pode estar lendo e transfe­ rindo o bloco seguinte para um buffer diferente. Essa técnica é chamada de buffering duplo e também pode ser usada para ler um fluxo contínuo de blocos do disco para a memória. O buffering duplo permite a leitura ou a gravação contínua de dados em blocos de disco consecutivos, o que elimina o tempo de busca e o atraso rotacional Concorrência intervalada das operações A e B

Execução paralela das operações C e D

Figura 16.3 Concorrência

Tempo

intervalada paralela.

versus execução

504

Sistemas de banco de dados

Bloco de disco: E/S:

i

j

i +1

[

Preenche A i Preenche B i

Bloco de disco: PROCESSAMENTO:

I / I 1 Processa A 1 i i — i i i i

i

+2

í

Preenche A

'+3

i Preenche A ___________ i i i /+1 i í+2 Processa B 1 Processa A i i i

i i • Preenche A i H rj i i i i i i I /+4 i í+3 1 Processa B 1 Processa A i i , i i i i

!

»+4

Tempo

Figura 16.4 Uso de dois buffers, A e B, para a leitura do disco.

para todas as transferências dc bloco, com exceção da primeira. Além disso, os dados ficam prontos para processamento, reduzindo assim o tempo de espera nos programas.

16.3.1 Gerenciamento de buffer Gerenciamento de buffer e estratégias de substituição. Para a maioria dos grandes arquivos de banco de dados, contendo milhões de páginas, não é possível trazer todos os dados para a memória principal de uma só vez. Mencionamos o duplo buffering como uma técnica pela qual podemos obter eficiência em termos de executar a operação de E/S entre o disco e a memória principal cm uma área de buffer simultaneamente com o processamento dos dados dc outro buffer. O gerenciamento real de buffers c a deci­ são sobre quais buffers usar para colocar uma página recém-lida é um processo mais complexo. Usamos o termo buffer para nos referir a uma parte da memória principal que está disponível para receber blocos ou páginas dc dados do disco.9 O gerenciador de buffer é um componente dc software dc um SGBD que responde aos pedidos de dados e decide qual buffer será usado e quais páginas serão substituídas no butter para acomodar os blocos recém-solicitados. O gerenciador de buffer vê o armazenamento disponível na memória principal como um pool de buffers, que possui uma coleção de páginas. O tamanho do pool de buffers compartilhado geralmente é um parâmetro do SGBD controlado pelos DBAs. Nesta seção, discutimos brevemente o funcionamento do gerenciador de buffer c algumas estratégias dc substituição. Existem dois tipos dc gerenciadores de buffer; o primeiro controla a memória principal diretamente, como na maioria dos SGBDRs. O segundo aloca buffers na memória virtual, o que permite que o controle seja transferido para o sistema operacional (SO). O SO, por sua vez, controla quais buffers estão realmcnte na memória principal c quais estão no disco, sob o controle do SO. Esse segundo tipo de gerenciador de buffer é comum em sistemas de banco de dados na memória principal e em alguns SGBDs orientados a objeto. São dois os objetivos gerais do gerenciador de buffer: (1) maximizar a probabilidade de que a página solicitada seja encontrada na memória principal; e (2) caso seja necessário ler um novo bloco do disco, encontrar uma página a ser substituída que cause o menor dano no sentido de que não será exigida novamente em breve. Para habilitar sua operação, o gerenciador de buffer mantém dois tipos de infor­ mações disponíveis sobre cada página no pool de buffers:

1. Um contador dc visitas: o número de vezes que a página foi solicitada, ou o número de usuários atuais dessa página. Se esse contador cair para zero, a página é considerada não visitada. Inicialmente, o contador de visitas de cada página é definido em zero. O incremento do contador é chamado de pinning. Em geral, um bloco visitado não deverá ser gravado em disco. Usamos os termos página e bloco para nos referir à mesma coisa no contexto atual.

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

2. Um bit dc modificação, que inicialmente é definido em zero para todas as pági­ nas, mas passa para 1 sempre que a página é atualizada por qualquer programa de aplicação. Em termos de gerenciamento de armazenamento, o gerenciador de buffer tem a seguinte responsabilidade: deve certificar-se dc que o número de buffers se encaixa na memória principal. Se a quantidade dc dados solicitada exceder o espaço de buf­ fer disponível, o gerenciador deverá selecionar quais buffers devem ser esvaziados, conforme regido pela política de substituição do buffer em vigor. Se o gerenciador reservar espaço na memória virtual e todos os buffers em uso excederem a memória principal real, então ocorre o problema comum de ‘'thrashing” do sistema opera­ cional, quando as páginas são movidas continuamente para o espaço de “swap” no disco, sem realizar qualquer trabalho útil. Quando uma determinada página é solicitada, o gerenciador de buffer realiza as seguintes ações: verifica se a página solicitada já está em um buffer no pool de buffers; se assim for, ele incrementa sua contagem de visitas e libera a página. Se a página não estiver no pool de buffers, o gerenciador faz o seguinte: a. Escolhe uma página para substituir; usando a política de substituição, e incre­ menta seu contador de visitas.

b. Se o bit de modificação da página substituta estiver marcado, o gerenciador de buffer grava essa página no disco, substituindo sua cópia antiga no disco. Se o bit não estiver marcado, a página não foi modificada e o gerenciador não precisa gravá-la no disco. c. Ele lê a página solicitada para o espaço que acabou de ser liberado. d. O endereço da nova página na memória principal é passado para a aplicação solicitante.

Se não houver página não visitada à disposição no pool de buffers e a página solicitada não estiver disponível no pool, o gerenciador pode ter de esperar até que uma página seja liberada. Uma transação solicitando essa página pode entrar em um estado de espera ou até mesmo ser abortada.

16.3.2 Estratégias de substituição de buffer A seguir, vemos algumas das estratégias de substituição populares, semelhantes às utilizadas em outras partes do sistema, como nos sistemas operacionais:

1. Usado menos recentemente (LRU): a estratégia aqui é remover a página que não foi usada (lida ou escrita) há mais tempo. Isso exige que o gerenciador de buffer mantenha uma tabela na qual registrará a hora toda vez que uma página de um buffer for acessada. Embora isso constitua um esforço extra, a estratégia funciona bem porque, para um buffer que não foi usado há muito tempo, sua chance de ser acessado novamente é pequena. 2. Política de relógio: esta é uma variante de rodízio da política LRU. Imagine que os buffers estejam organizados como um círculo, semelhante a um relógio de ponteiros. Cada buffer tem um sinalizador com um valor 0 ou 1. Os buffers com 0 são vulneráveis e podem ser usados para substituição, com seu conteúdo levado de volta para o disco. Os buffers com 1 não são vulneráveis. Quando um bloco é lido para um buffer, o sinalizador é definido como 1. Quando o buffer é acessado, o sinalizador também é definido como 1. O “ponteiro do relógio” é posicionado em um “buffer atual”. Quando o gerenciador precisa de um buffer para um novo bloco, ele gira o ponteiro até encontrar um buffer com 0 e o utiliza para ler e inserir o novo bloco. (Se o bit de modificação estiver marcado para

505

506

Sistemas de banco de dados

a página que está sendo substituída, essa página será gravada em disco, subs­ tituindo assim a página antiga em seu local no disco.) Se o ponteiro do relógio passar por buffers com 1, ele os define para zero. Assim, um bloco é substituído de seu buffer somente se não for acessado até que o ponteiro complete uma volta e retorne a ele, encontrando o bloco com o 0 que ele definiu na última passada.

3. Primeiro a entrar, primeiro a sair (FIFO): com essa política, quando um buffer é solicitado, o que foi ocupado há mais tempo por uma página é usado para a substituição. Neste caso, o gerenciador anota a hora em que cada página foi car­ regada em um buffer, mas ele não precisa registrar a hora em que as páginas são acessadas. Embora a técnica FIFO precise dc menos manutenção que a LRU, ela pode ter um comportamento contrário ao desejado. Um bloco que permanece no buffer por muito tempo porque é necessário continuamente,como um bloco raiz de um índice, pode ser descartado e precisar ser trazido de volta imediatamente. As políticas LRU e de relógio nào são as melhores políticas para aplicações de banco de dados se elas exigirem varreduras sequenciais dos dados e o arquivo não couber no buffer de uma só vez. Também há situações em que cerras páginas nos buffers não podem ser retiradas e gravadas no disco porque certas outras páginas visitadas apontam para essas páginas. Além disso, políticas como FIFO podem ser modifica­ das para garantir que os blocos visitados, como o bloco raiz dc um índice, possam permanecer no buffer Também é possível modificar a política dc relógio para que buffers importantes tenham valores mais altos que 1 e, portanto, não estejam sujeitos a substituição por várias rodadas do ponteiro. Há também situações em que o SGBD tem a capacidade de gravar certos blocos no disco mesmo que o espaço ocupado por esses blocos não seja necessário. Isso é chamado dc forçar a escrita, c geralmente ocorre quando registros de log precisam ser gravados em disco antes das páginas modifica­ das em uma transação, para fins de recuperação (ver Capítulo 22). Existem algumas outras estratégias de substituição, como MRU (usado mais recentemente, do inglês most recently used}, que funcionam bem para certos tipos de transações de banco de dados, por exemplo, quando um bloco usado mais recentemente não é mais necessário até que sejam processados todos os blocos restantes na relação.

16.4 Gravando registros de arquivo no disco Os dados em um banco são considerados como um conjunto de registros organi­ zados cm um conjunto dc arquivos. Nesta seção, definimos os conceitos de registros, tipos dc registro e arquivos. Depois, discutimos sobre as técnicas para gravar registros de arquivo no disco. Note que, daqui por diante neste capítulo, vamos nos referir ao armazenamento secundário persistente de acesso aleatório como “unidade de disco”, ou simplesmente “disco”. O disco pode estar cm diferentes formatos; por exemplo, discos magnéticos com memória rotacional ou discos dc estado sólido, com acesso eletrônico e nenhuma espera mecânica.

16.4.1 Registros e tipos de registro Os dados costumam ser armazenados na forma de registros. Cada registro contém uma coleção dc valores ou itens de dados relacionados, em que cada valor é formado por um ou mais bytes e corresponde a um campo cm particular do registro. Os regis­ tros normalmente descrevem entidades e seus atributos. Por exemplo, um registro de FUNCIONÁRIO representa uma entidade de funcionário e o valor de cada campo no registro especifica algum atributo desse funcionário,como Nome, Data_nascimento, Salario ou Supervisor. Uma coleção de nomes de campo e seus tipos de dados correspondentes

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

constituem uma definição de tipo de registro ou formato de registro. Um tipo de dado, associado a cada campo, especifica os tipos de valores que um campo pode assumir. O tipo de dado de um campo normalmente é um dos tipos de dado padrão usados na programação. Estes incluem os tipos de dados numéricos (inteiro, inteiro longo ou ponto flutuante), cadeia de caracteres (tamanho fixo ou variável), booleanos (tendo apenas valores 0 e 1, ou TRUE e FALSE) e, às vezes, tipos data e hora especialmente codificados. O número de bytes exigidos para cada tipo dc dado c fixo para determinado sistema dc computação. Um inteiro pode exigir 4 bytes; um inteiro longo, 8 bytes; um número real, 4 bytes; um booleano, 1 byte; uma data, 10 bytes (considerando um formato DD-MM-AAAA), e uma cadeia de tamanho fixo de k caracteres, k bytes. As cadeias (ou strings) de tamanho variável podem exibir tantos bytes quantos caracteres existirem no valor dc cada campo. Por exemplo, um tipo de registro FUNCIONÁRIO pode ser definido — usando a notação da linguagem de programação C — com a seguinte estrutura: struct funcionario{ char nome[30];

char cpf[11 ]; int

salario;

int

codigo_cargo;

char departamento(20]; );

Em algumas aplicações de banco dc dados, pode haver necessidade dc armazenar itens de dados que consistem em grandes objetos não estruturados, que representam imagens, vídeo digitalizado ou streams de áudio, ou então texto livre. Estes são conhe­ cidos como BLOBs (objetos binários grandes). Um item dc dados BLOB costuma ser armazenado separadamente de seu registro, em um conjunto de blocos de disco, e um ponteiro para o BLOB é incluído no registro. Para armazenar texto livre, alguns SGBDs (por exemplo, Oracle, DB2 etc.) oferecem um tipo de dado chamado CLOB (objeto grande de caracteres); alguns SGBDs chamam esse tipo de dado de texto.

16.4.2 Arquivos, registros de tamanho fixo e registros de tamanho variável Um arquivo é uma sequência de registros. Em muitos casos, todos os registros cm um arquivo são do mesmo tipo de registro. Se cada registro no arquivo tem exata­ mente o mesmo tamanho (em bytes), o arquivo é considerado composto de registros de tamanho fixo. Se diferentes registros no arquivo possuem diversos tamanhos, o arquivo é considerado composto de registros de tamanho variável. Um arquivo pode ter registros dc tamanho variável por vários motivos: ■ Os registros do arquivo são do mesmo tipo de registro, mas um ou mais dos campos são de tamanho variável (campos de tamanho variável). Por exemplo, o campo Nome de FUNCIONÁRIO pode ser um campo de tamanho variável. ■ Os registros do arquivo são do mesmo tipo de registro, mas um ou mais dos campos podem ter múltiplos valores para registros individuais; esse campo é chamado de campo repetitivo, e um grupo de valores para o campo normalmente é chamado de grupo repetitivo. ■ Os registros do arquivo são do mesmo tipo de registro, mas um ou mais dos campos são opcionais, ou seja, podem ter valores para alguns, mas não para todos os registros do arquivo (campos opcionais). ■ O arquivo contém registros dc tipos de registro diferentes c, portanto, dc tamanho variável (arquivo misto). Isso ocorrería se registros relacionados dc diferentes tipos fossem agrupados (colocados juntos) em blocos de disco; por exemplo, os

507

508

Sistemas de banco de dados

registros de HISTORICO.ESCOLAR de determinado aluno podem ser colocados após o registro desse ALUNO.

Os registros de FUNCIONÁRIO de tamanho fixo na Figura 16.5(a) têm um tamanho de registro de 71 bytes. Cada registro tem os mesmos campos, e os tamanhos de campo sâo fixos, dc modo que o sistema pode identificar a posição dc byte inicial dc cada campo cm relação à posição inicial do registro. Isso facilita a localização de valores de campo pelos programas que acessam tais arquivos. Observe que é possível repre­ sentar um arquivo que logicamente deveria ter registros de tamanho variável como um arquivo de registros de tamanho fixo. Por exemplo, no caso dos campos opcionais, poderiamos ter cada campo incluído em cada registro de arquivo, mas armazenar um valor especial NULL se não houver valor para esse campo. Para um campo repetitivo, poderiamos alocar tantos espaços cm cada registro quanto o número máximo possível de ocorrências do campo. De qualquer forma, o espaço é desperdiçado quando certos registros não têm valores para todos os espaços físicos fornecidos em cada registro. Agora, vamos considerar outras opções para formatar registros de um arquivo dc registros dc tamanho variável. Para campos de tamanho variável, cada registro tem um valor para cada campo, mas não sabemos o tamanho exato de alguns valores de campo. Em um registro em particular, para determinar os bytes que representam cada campo, podemos usar caracteres separadores especiais (como ? ou % ou S) — que não aparecem em qualquer valor do campo — para terminar os campos de tamanho variável, como mostra a Figura 16.5(b), ou podemos armazenar o tamanho do campo em bytes no próprio registro, antes do valor do campo. Um arquivo de registros com campos opcionais pode ser formatado de várias maneiras. Se o número total de campos para o ripo de registro for grande, mas o número de campos que realmente aparecem em um registro típico for pequeno, pode­ mos incluir cm cada registro uma sequência de pares .

(a)

Salario

Cpf

Nome

Codigo_cargo

Departamento

Data contratacao

llllllllllllllllllllllllllIlMlIlllllflIlIlIlIllllllllllllllirTTTtTTTTTl

1

Nome | Silva, João

Cpf Salario 112345678966 ~ XXXX

1

12

21

25

31

40

44

Codigo_ cargo XXXX

Departamento Computação

68

48

|

| Caracteres separadores

29

(0

Nome = Silva, João | Cpf = 12345678966 | DEPARTAMENTO = Computação

Caracteres separadores = Separa nome de campo do valor do campo

Figura 16.5 Três formatos de armazenamento de registro, (a) Um registro

| Separa campos

de tamanho fixo com seis campos e tamanho de 71 bytes, (b) Um registro

com dois campos de tamanho variável e três campos de tamanho fixo, (c) Um registro de campo variável com três tipos de caracteres separadores.

M Termina registro

Capítulo 16

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

em vez de apenas os valores de campo. Três tipos de caracteres separadores sào usados na Figura 16.5(c), embora pudéssemos usar o mesmo caractere separador para as duas primeiras finalidades — separar o nome do valor do campo e separar um campo do campo seguinte. Uma opção mais prática é atribuir um código curto de tipo de campo — digamos, um número inteiro — a cada campo e incluir em cada registro uma sequência de pares , em vez de pares . Um campo repetitivo precisa dc um caractere separador para afastar os valores repetitivos do campo e outro caractere separador para indicar o término do campo. Finalmente, para um arquivo que inclui registros de diferentes tipos, cada registro é precedido por um indicador de tipo de registro. É compreensível que os programas

que processam arquivos de registros com tamanho variável — que cm geral fazem parte do sistema de arquivos e, portanto, ficam ocultos da maioria dos programa­ dores — tenham de ser mais complexos que aqueles para registros de tamanho fixo, nos quais a posição inicial e o tamanho de cada campo são conhecidos e fixos.10

16.4.3 Blocagem de registros e registros espalhados versus não

espalhados Os registros de um arquivo precisam ser alocados a blocos de disco, porque um bloco é a unidade de transferência de dados entre o disco e a memória. Quando o tamanho do bloco é maior que o tamanho do registro, cada bloco terá diversos registros, embora alguns arquivos possam ter registros excepcionalmente grandes que não cabem em um bloco. Suponha que o tamanho do bloco seja B bytes. Para um arquivo dc registros de tamanho fixo, com tamanho de R bytes, sendo B è R, podemos estabelecer bfr = LB/RJ registros por bloco, em que _(x)J (função floor) arredonda para baixo o número x para um inteiro. O valor bfr é chamado de fator dc blocagem para o arquivo. Fm geral, R pode não dividir B exatamente, de modo que temos algum espaço não usado em cada bloco, igual a B - (bfr * R) bytes Para aproveitar esse espaço não usado, podemos armazenar parte de um registro em um bloco e o restante em outro. Um ponteiro no final do primeiro bloco aponta para o bloco que contém o restante do registro, caso não seja o próximo bloco consecutivo no disco. Essa organização é chamada de espalhada porque os registros podem se espalhar por mais de um bloco. Sempre que um registro é maior que um bloco, temos de usar uma organização espalhada. Se os registros não puderem atravessar os limites de bloco, a organização é chamada de não espalhada. Isso é usado com registros de tamanho fixo tendo B > 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

Registro 1

(a)

Registro 2

Registro 3 |

organização de registro, (a) Não espalhada, (b) Espalhada.

Bloco i + 1 |

(b)

Registro 4 Registro 1

Registro 5

Registro 6

| Registro 2 | Registro 3

Registro 4

P

Bloco 7 + 1 | Registro 4 (restante) | Registro 51 Registro 6 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 dc 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 dc 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 ser 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 de 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. ■ FindNcxt. 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 c 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 de 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 anteriormente — 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 predominantemente 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 dc 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 rodas 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 geralmenre 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 c indexação, são usadas para criar métodos de 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 em que são inseridos, de 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 de um novo registro é muito eficiente. O último bloco de disco do arquivo é copiado para um buffer, o novo registro é acrescentado e 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. Se 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 butter. 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 de 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 /-ésimo registro do arquivo está localizado no bloco [_(i/bfr)i

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 ripo echave = valor>, ou uma condição de intervalo como . Segundo, encontrar o próximo registro com base no atual na ordem da chave de ordenação em geral não requer acessos de bloco adicionais porque o próximo registro está no mesmo bloco do atual (a menos que o registro atual seja o último no bloco). Terceiro, o uso de uma condição de pesquisa baseada no valor de um campo-chave de ordenação resulta em acesso mais rápido quando a técnica de pesquisa binária é usada, o que constitui uma melhoria em relação às pesquisas lineares, embora isso normalmente não seja utilizado para arquivos de disco. Os arquivos ordenados estão em blocos e armazenados em cilindros contíguos para minimizar o tempo dc busca.

12 O termo arquivo sequencial também tem sido usado para se referir aos arquivos desordenados, em

bora seja mais apropriado para arquivos ordenados.

Capítulo 16

Nome Bloco 1

Armazenamento de disco, fundamentos de estruturas de arquivo, hashing (...)

Cpf

Data nascimento

Cargo

Salario

Aaron, Eduardo Abílio, Diana

Acosta, Marcos Bloco 2

Adams, João Adams, Roberto

Akers, Janete

Bloco 3

Alexandre,

Eduardo Alfredo, Roberto

Allen, Samuel Bloco 4

Allen, Tiago

Anderson, Kely

Anderson, Joel Bloco 5

Anderson, Isaac Angeli, José

Anita, Sueli Bloco 6

Arnold, Marcelo Arnold, Estêvão

Atkins, Timóteo

Bloco n-1

Wong, Jaime Wood, Ronaldo

Woods, Manuel

Bloco n

Wright, Pâmela Wyatt, Charles

Zimmer, André

Figura 16.7 Alguns blocos de um arquivo ordenado (sequencial) de registros de

FUNCIONÁRIO com Nome como campo-chave de ordenação.

Sexo

515

516

Sistemas de banco de dados

Uma pesquisa binária por arquivos de disco pode ser feita nos blocos, em vez de nos registros. Suponha que o arquivo tenha b blocos numerados com 1,2,..., b; os registros sào ordenados por valor crescente de seu campo-chave de ordenação; e estamos procurando um registro cujo valor do campo-chave de ordenação seja K. Supondo que os endereços de disco dos blocos de arquivo estejam disponíveis no cabeçalho de arquivo, a pesquisa binária pode ser descrita pelo Algoritmo 16.1. Uma pesquisa binária normalmente acessa log,(b) blocos, não importando se o registro foi localizado ou não — uma melhora em relação às pesquisas lineares, em que, na média, (b/2) blocos são acessados quando o registro é encontrado e b blocos são acessados quando o registro não é encontrado.

Algoritmo 16.1. Pesquisa binária em uma chave de ordenação de um arquivo de disco /«— 1; bé o número de blocos de arquivo (* ) * enquanto (u > /)faça início / (valor do campo-chave de ordenação do último registro no bloco /), então /* —/+! senão, se o registro com valor do campo-chave de ordenação = K está no buffer, então vá para achou senão, vá para nãoachou; fim; vá para nãoachou; Um critério dc pesquisa envolvendo as condições >, e < no campo dc 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 dc 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-chavc 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

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

um registro específico

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 de arquivo de 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. A 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 é 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 normalmente é 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 Aí - 1, como mostra a Figura 16.8(a). Então, temos Aí 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 Al, que retorna o resto de um valor de campo de hash inteiro K após a divisão por Al; esse valor é então usado para o endereço do registro.

Nome

(a)

Cpf

Cargo

Salario

0 1 2 3 M-2

M-1

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.

• 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 dc um caractcrc 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 / 40 refere-se aos dados no bucket do topo mostrado na Figura 17.14. O conceito de arquivo dc grade pode scr aplicado a qualquer quantidade dc chaves dc pesquisa. Por exemplo, para n chaves dc pesquisa, o vetor dc grade teria n dimensões. O vetor de grade, assim, permite um particionamcnto do arquivo ao longo das dimensões

571

572

Sistemas de banco de dados

N umero.departa mento 0

1.2

1

3,4

2

5

3

6,7

4

8

5

9, 10

Escala linear para Numero.departamento

Escala linear para Idade

0 50

Figura 17.14 Exemplo de um vetor de grade nos atributos Numero.departamento e Idade.

dos atributos de chave e oferece um acesso por combinações de valores ao longo dessas dimensões. Os arquivos de grade funcionam bem em relação à redução no tempo para o acesso com múltiplas chaves. Contudo, eles representam um overhead dc espaço em matéria de estrutura dc vetor dc grade. Além disso, com arquivos dinâmicos, uma reor­ ganização frequente do arquivo aumenta o custo de manutenção.14

17.5 Outros tipos de índices 17.5.1 índices de hash Também é possível criar estruturas de acesso semelhantes aos índices baseados no hashing. O índice de hash é uma estrutura secundária para acessar o arquivo usando hashing cm uma chave dc pesquisa diferente da usada para a organização do arquivo de dados primário. As entradas de índice são do tipo ou , em que Pr é um ponteiro para o registro que contém a chave, ou P é um ponteiro para o bloco que contém o registro para essa chave. O arquivo de índice com essas entradas pode ser organizado como um arquivo de hash dinamicamente cxpansívcl, usando uma das técnicas descritas na Seção 16.8.3; a pesquisa por uma entrada usa o algoritmo de pesquisa de hash em K. Quando uma entrada é localizada, o ponteiro Pr (ou P) é utilizado para localizar o registro correspondente no arquivo de dados. A Figura 17.15 ilustra um índice de hash no campo Codigo.funcionario para um arquivo armazenado como um arquivo sequencial, ordenado por Nome. O Codigo_funcionario passa pelo hashing para obter um número de bucket usando a função de hashing: a soma dos dígitos dc Codigo_fundonario módulo 10. Por exemplo, para encontrar o Codigo_funcionario 51024, a função de hash resulta no número de bucket 2; esse bucket é acessado primeiro. Fie contém a entrada de índice < 51024, Pr >; o ponteiro Pr nos leva ao registro real no arquivo. Em uma aplicação prática, pode haver milhares de buckets; o número do bucket, que pode ter vários bits de extensão, estaria sujeito aos esquemas de diretório discutidos no contexto do hashing dinâmico, na Seção 16.8.3. Outras estruturas de pesquisa também podem ser usadas como índices.

14 Algoritmos de inserção/exclusão para arquivos de grade podem ser encontrados em Nievergelr et al. (1984).

Capitulo 17

13646 21124

•—

Estruturas de indexação para arquivos e projeto físico de banco de dados

Codigojuncionario Uhimo nome Sexo ■■ ■■■ 12676 M Marcus

.....

.....

23402

13646

Hamilton

M

21124

M

23402

Donato .......... Pires

34723

Fernandes

F

.......... 41301

.......... Zara

F

51024

Braga

M

62104

Brito

M

71221

Antunes .......... Gouveia

F

.....

81165

51024

F

12676

..

62104

71221

•

..... 81165

F

Bucket 9 34723

41301

Figura 17.15 Indexação baseada em hash.

17.5.2 índices bitmap O índice bitmap é outra estrutura de dados popular que facilita a consulta sobre múltiplas chaves. A indexação bitmap é usada para relações que contêm um grande número de linhas. Ela cria um índice para uma ou mais colunas, e cada valor ou intervalo de valores nessas colunas é indexado. Normalmente, um índice bitmap é criado para as colunas que contêm um número muito pequeno de valores únicos. Para criar um índice bitmap sobre um conjunto de registros em uma relação, os registros precisam ser numerados de 0 a n com um id (um id de registro ou um id de linha) que pode ser mapeado para um endereço físico composto de um número de bloco e um deslocamento de registro dentro desse bloco. Um índice bitmap c criado sobre um valor específico de um campo cm particular (a coluna em uma relação) e é apenas um vetor de bits. Assim, para determinado campo, existe um índice bitmap (ou vetor) separado e mantido, correspondente a cada valor único no banco de dados. Considere um índice bitmap para a coluna C c um valor V para essa coluna. Para uma relação com n linhas, ele contém n bits. O z-ésimo bit é definido como 1 se a linha i tiver o valor V para a coluna C; caso contrário, ele é definido como 0. Se C contiver o conjunto de valores 15000;

Exemplo 3. Este é um exemplo mais avançado do uso da indexação baseada em função para definir a exclusividade condicional. A instrução a seguir cria um índice único com base em função na tabela PEDIDOS, que impede que um cliente tire proveito de um código de promoção mais de uma vez. Ele cria um índice composto nos campos Codiqo_cliente e Codigo_promocao juntos, e só permite uma entrada no índice para determinado Codigo_diente com Codigo_promocao de ‘2’, declarando-o como um índice único. CREATE UNIQUE INDEX idx_promocao ON Pedidos (CASE WHEN Codigo. promoção = 2 THEN Codigo_cliente ELSE NULL END, CASE WHEN Codigo_promocao = 2 THEN Codigo_promocao ELSE NULL END);

Observe que, usando a instrução CASE, o objetivo é remover do índice quaisquer linhas em que Codigo.promocao não seja igual a 2.0 Oracle Database nào armazena no índice da B"-tree quaisquer linhas em que todas as chaves são NULL. Portanto, neste exemplo, mapeamos tanto Codigo_diente quanto Codigo_promocao para NULL, a menos que Codigo_promocao seja igual a 2.0 resultado é que a restrição de índice é violada somente se Codigo_promocao for igual a 2, para duas (tentativas de inserção dc) linhas com o mesmo valor de Codigo_cliente.

17.6 Algumas questões gerais referentes à indexação 17.6.1 índices lógicos versus físicos Na discussão anterior, consideramos que as entradas de índice (ou ) sempre incluem um ponteiro físico Pr (ou P) que especifica o endereço do

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

registro físico no disco como um número de bloco e deslocamento. Este, às vezes, é chamado de índice físico, e tem a desvantagem dc o ponteiro precisar ser mudado se o registro for movimentado para outro local no disco. Por exemplo, suponha que uma organização de arquivo primária seja fundamentada no hashing linear ou no hashing extensível. Então, toda vez que um bucket for dividido, alguns registros serão alocados para novos buckets e, portanto, terão novos endereços físicos. Se houvesse um índice secundário no arquivo, os ponteiros para esses registros teriam de ser localizados e atualizados, o que é uma tarefa difícil. Para solucionar essa situação, podemos usar uma estrutura chamada índice lógico, cujas entradas de índice têm a forma . Cada entrada tem um valor K para algum campo de índice secundário combinado com o valor Kp do campo usado para a organização do arquivo primário. Ao pesquisar o índice secundário sobre o valor de K, um programa pode localizar o valor correspondente de Kp e usá-lo para acessar o registro pela organização do arquivo primário, usando um índice primário, se houver. Os índices lógicos, assim, introduzem um nível adicional de indireção entre a estrutura de acesso e os dados. Eles são usados quando se espera que os endereços de registro físicos mudem com frequência. O custo dessa indireção é a pesquisa extra fundamentada na organização do arquivo primário.

17.6.2 Criação de índice Muitos SGBDs possuem um ripo de comando semelhante para a criação de um índice, embora não faça parte do padrão SQL. O formato geral desse comando é: CREATE [ UNIQUE ] INDEX ON ( [ ] {, [ ]}) [CLUSTER);

As palavras-chave UNIQUE e CLUSTER são opcionais. A palavra-chave CLUSTER é usada quando o índice a ser criado também deve ordenar os registros do arquivo de dados sobre o atributo de indexação. Assim, a especificação de CLUSTER em um atributo de chave (única) criaria alguma variação de um índice primário, ao passo que a especificação de CLUSTER em um atributo não chave (não único) criaria alguma variação dc um índice dc agrupamento. O valor para pode ser ASC (cres­ cente) ou DESC (decrescente), e especifica se o arquivo de dados deverá ser classificado em ordem crescente ou decrescente de valores do atributo de indexação. O default é ASC. Por exemplo, o comando a seguir criaria um índice dc agrupamento (crescente) sobre o atributo não chave Numero_departamento do arquivo FUNCIONÁRIO:

CREATE INDEX idx_NumDepartamento ON FUNCIONÁRIO (Numero.departamento) CLUSTER ;

Processo de criação de índice: em muitos sistemas, um índice não faz parte integral do arquivo dc dados, mas pode ser criado e descartado dinamicamente. É por isso

que, em geral, é chamado dc uma estrutura de acesso. Sempre que esperamos aces­ sar um arquivo com frequência com base cm alguma condição dc pesquisa envolvendo um campo em particular, podemos solicitar que o SGBD crie um índice sobre esse campo, como vimos no exemplo para o idx_NumDepartamento. Normalmente, um índice secundário é criado para evitar a ordenação física dos registros no arquivo dc dados cm disco. A principal vantagem dos índices secundários é que — pelo menos teoricamente — eles podem ser criados com praticamente qualquer organização de registro primária. Logo, um índice secundário poderia ser usado para complementar outros métodos de acesso primários, como a ordenação ou o hashing, ou poderia ainda ser utilizado

577

578

Sistemas de banco de dados

com arquivos mistos. Para criar um índice secundário de B’-tree sobre algum campo de um arquivo, se o arquivo for grande e tiver milhões de registros, nem o arquivo nem o índice caberíam na memória principal. A inserção de um grande número de entradas no índice é feita por um processo chamado carga em massa (bulk loading) do índice. Temos de percorrer todos os registros no arquivo para criar as entradas no nível de folha da árvore. Essas entradas sào então classificadas e preenchidas de acordo com o fator dc preenchimento especificado; dc maneira simultânea, os outros níveis dc índice são criados. E mais dispendioso e muito mais difícil criar índices primários e índices de agrupamento dinamicamente, pois os registros do arquivo de dados precisam ser fisicamente classificados no disco na ordem do campo de indexação. Porém, alguns sistemas permitem que os usuários criem esses índices dinamicamente em seus arquivos classificando o arquivo durante a criação do índice. Indexação de strings: existem algumas questões que se referem particularmente à indexação de strings (ou cadeias de caracteres). Strings podem ter tamanho variável (por exemplo, o tipo de dado VARCHAR na SQL; ver Capítulo 6) e podem ser muito longas, limitando o fan-out. Se um índice B -tree tiver de serenado com uma string * sendo a chave de pesquisa, pode haver uma quantidade desigual de chaves por nó de índice, e o fan-out pode variar. Alguns nós podem ser forçados a se dividir quando estiverem cheios, independentemente do número de chaves contidas. A técnica de compactação de prefixo alivia essa situação. Em vez de armazenar a string inteira nos nós intermediários, ela armazena apenas o prefixo da chave de pesquisa ade­ quado para distinguir as chaves que estão sendo separadas e direcionadas para a subárvore. Por exemplo, se Ultimo_nome fosse uma chave dc pesquisa e estivéssemos procurando por “Navathe”, o nó não folha podería conter “Nac" para Nachamkin e “Nay” para Nayuddin como as duas chaves em ambos os lados do ponteiro da subárvore que precisamos seguir.

17.6.3 Ajuste de índices A escolha inicial de índices pode precisar ser revisada pelos seguintes motivos: ■ Certas consultas podem levar muito tempo para serem executadas, por falta de um índice. ■ Certos índices podem nem chegar a ser utilizados. ■ Certos índices podem sofrer muita atualização, pois o índice é sobre um atributo que sofre mudanças frequentes.

A maioria dos SGBDs possui um comando ou facilidade de trace, que pode ser usado pelo DBA para pedir que o sistema mostre como uma consulta foi executada — que operações foram realizadas cm que ordem c quais estruturas dc acesso secun­ dárias (índices) foram usadas. Analisando esses planos de execução (discutiremos esse termo com mais detalhes no Capítulo 18), é possível diagnosticar as causas desses problemas. Alguns índices podem ser removidos e alguns índices novos podem ser criados com base na análise de ajuste. O objetivo do ajuste é avaliar dinamicamente os requisitos, que às vezes flutuam sazonalmente ou durante diferentes dias do mês ou da semana, e reorganizar os índices e organizações de arquivo para gerar o melhor desempenho geral. z\ remo­ ção e a criação de novos índices é um trabalho adicional que pode ser justificado em termos de melhoras de desempenho. A atualização de uma tabela geralmente é suspensa enquanto um índice é removido ou criado; essa perda temporária de serviço deverá ser considerada. Além de remover ou criar índices e passar dc um índice não agrupado para um índice agrupado, e vice-versa, a recriação do índice pode melhorar o desempenho.

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

A maioria dos SGBDRs utiliza B -rrees para um índice. Se houver muitas exclusões * sobre a chave de índice, as páginas de índice podem conter espaço desperdiçado, que podem ser reobtidas durante a operação de recriação. De modo semelhante, muitas inserções podem causar overflows em um índice agrupado, o que afeta o desempenho. A criação de um índice agrupado significa reorganizar a tabela inteira ordenada sobre essa chave. As opções disponíveis para indexação e o modo como são definidas, criadas e reorganizadas variam de um sistema para outro. Como ilustração, considere os índices esparso e denso que discutimos na Seção 17.1. Um índice esparso, como um índice primário, terá um ponteiro de índice para cada página (bloco de disco) no arquivo de dados; um índice denso, como um índice secundário único, terá um ponteiro de índice para cada registro. O Sybase oferece índices de agrupamento como índices esparsos, na forma de B -trees, * enquanto o INGRES oferece índices de agrupamento esparsos, como arquivos ISAM, e índices de agrupamento densos, como B -trees. * Em algumas versões do Oracle e do DB2, a opção de configurar um índice de agrupamento é limitada a um índice denso, e o DBA precisa trabalhar com essa limitação.

17.6.4 Questões adicionais relacionadas ao armazenamento de relações e índices Usando um índice para gerenciar restrições e duplicatas: é comum usar um índice para impor uma restrição de chave sobre um atributo. Enquanto se pesquisa o índice para inserir um novo registro, é fácil verificar ao mesmo tempo se outro registro no arquivo — e, portanto, na árvore de índice — tem o mesmo valor de atributo de chave que o novo registro. Nesse caso, a inserção pode ser rejeitada. Se um índice for criado em um campo não chave, ocorrem duplicatas. O tra­ tamento dessas duplicatas é uma questão com que os vendedores de produtos de SGBD precisam lidar e afeta o armazenamento de dados, bem como a criação e o gerenciamento de índice. Os registros de dados para a chave duplicada podem estar contidos no mesmo bloco ou podem se espalhar por vários blocos, nos quais muitas duplicatas são possíveis. Alguns sistemas acrescentam uma identificação de linha para o registro, de modo que os registros com chaves duplicadas tenham os próprios identificadores exclusivos. Nesses casos, o índice da B+-tree pode consi­ derar uma combinação de como a chave de fato para o índice, transformando-o em um índice exclusivo sem duplicatas. A exclusão de uma chave K de tal índice envolvería a exclusão de todas as ocorrências dessa chave K — daí o algoritmo de exclusão ter de considerar isso. Nos produtos de SGBD reais, a exclusão de índices da B -tree * também é tratada de diversas maneiras para melhorar o desempenho e os tempos de resposta. Os registros excluídos podem ser marcados como excluídos e as entradas de índice correspondentes também não podem ser removidas até que o processo de coleta de lixo retome o espaço no arquivo de dados; o índice é reconstruído on-line após a coleta de lixo. Arquivos invertidos e outros métodos de acesso: um arquivo que tem um índice secundário em cada um de seus campos costuma ser chamado dc arquivo totalmente invertido. Como todos os índices são secundários, novos registros são inseridos ao final do arquivo. Portanto, o próprio arquivo dc dados é um arquivo desordenado (heap). Os índices normalmente são implementados como B’-trecs, de modo que são atualizados dc maneira dinâmica para refletir a inserção ou a exclusão de registros. Alguns SGBDs comerciais, como o Adabas da Software AG, utilizam esse método de modo extensivo.

579

580

Sistemas de banco de dados

Citamos a popular organização de arquivos da IBM, chamada ISAM, na Seção 17.2. Outro método da IBM, o método de acesso dc armazenamento virtual (VSAM — virtual storage access method), é semelhante à estrutura de acesso da B -tree * e ainda está sendo usado em muitos sistemas comerciais. Usando dicas de indexação em consultas: SGBDs como Oracle possuem uma provisão para permitir sugestões nas consultas, que são alternativas ou indicadores sugeridos para o processador e otimizador de consulta, para agilizar a execução da consulta. Uma forma de dica é chamada dica de indexação; esta sugere o uso de um índice para melhorar a execução de uma consulta. As dicas aparecem como um comentário especial (que é precedido por +) e redefinem todas as decisões do oti­ mizador, mas podem ser ignoradas pelo otimizador se forem inválidas, irrelevantes ou formuladas indevidamente. Não entraremos cm uma discussão detalhada sobre dicas de indexação, mas vamos ilustrar isso com um exemplo de consulta. Por exemplo, para recuperar Cpf, salário e número de departamento para os funcionários que trabalham em departamentos com Numero.departamento menor que 10: SELECT /* +

INDEX (FUNCIONÁRIO idx_numDepartamento_func) */Cpf_funciona-

rio, Salario, Numero.departamento FROM FUNCIONÁRIO

WHERE Numero.departamento < 10;

Essa consulta inclui uma dica para usar um índice válido chamado idx.numDepartamento.func (que é um índice sobre Numero.departamento na relação FUNCIONÁRIO). Armazenamento de relações baseado em coluna: há uma tendência recente em considerar um armazenamento de relações baseado em coluna como uma alternativa ao modo tradicional de armazenar relações linha por linha. Os SGBDs relacionais comerciais têm oferecido a indexação da B+-tree em chaves primárias e secundárias como um mecanismo eficiente para admitir o acesso aos dados por diversos crité­ rios de pesquisa e a capacidade de gravar uma linha ou um conjunto de linhas em disco dc uma só vez, para produzir sistemas otimizados para gravação. Para data warehouses (que serão discutidos no Capítulo 29), bancos dc dados somente de leitura, o armazenamento baseado em coluna oferece vantagens em particular para as consultas somente de leitura. Em geral, os SGBDs com armazenamento de coluna consideram o armazenamento de cada coluna de dados individualmente e permitem vantagens dc desempenho nas seguintes áreas: ■ Particionamcnto vertical da tabela coluna por coluna, dc modo que uma tabela de duas colunas pode ser construída para cada atributo e, portanto, somente as colunas necessárias possam ser acessadas. ■ Uso de índices por colunas (semelhante aos índices bitmap discutidos na Seção 17.5.2) e índices de junção em várias tabelas para responder às consultas sem ter de acessar as tabelas de dados. ■ Uso de visões materializadas (ver Capítulo 7) para dar suporte a consultas em múltiplas colunas.

O armazenamento dc dados por coluna permite a liberdade adicional na criação de índices, como os índices bitmap discutidos anteriormente. A mesma coluna pode estar presente em várias projeções de uma tabela e os índices podem ser criados sobre cada projeção. Para armazenar os valores na mesma coluna, estratégias para compactação de dados, supressão de valor nulo, técnicas de codificação de dicio­ nário (em que valores distintos na coluna recebem códigos mais curtos) e técnicas de codificação run-length têm sido idealizadas. NlonetDB/XlOO, C-Store e Verrica são exemplos desses sistemas. Alguns sistemas populares (como Cassandra, Hbase

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

e Hypertable) usaram o armazenamento com base em coluna de modo eficaz, com o conceito de armazenamento cm nível dc coluna. O armazenamento de dados nesses sistemas será explicado no contexto de sistemas NOSQL, que discutiremos no Capítulo 24.

17.7 Projeto físico em bancos de dados relacionais Nesta seção, discutimos os fatores de projeto físicos que afetam o desempenho de aplicações e transações, e depois comentamos as orientações específicas para SGBDRs no contexto daquilo que discutimos no Capítulo 16 e até este ponto do capítulo.

17.7.1 Fatores que influenciam o projeto físico do banco de dados O projeto físico é uma atividade em que o objetivo é nào apenas criar a estru­ turação apropriada dc dados no armazenamento, mas também fazer isso dc modo que garanta um bom desempenho. Para determinado esquema conceituai, existem muitas alternativas de projeto físico em determinado SGBD. Não é possível tomar decisões significativas dc projeto físico e análise dc desempenho até que o projetista conheça a combinação dc consultas, transações c aplicações que deverão usar o banco de dados. Isso é chamado dc combinação dc tarefas para determinado conjunto dc aplicações de sistema de banco de dados. Os administradores/projetistas precisam analisar essas aplicações, suas frequências de chamada esperadas, quaisquer restrições de temporização em sua velocidade de execução, a frequência esperada de operações de atualização e quaisquer restrições exclusivas nos atributos. Discutimos cada um desses fatores a seguir A. Analisando as consultas e as transações de banco de dados. Antes dc realizar o projeto físico dc banco dc dados, devemos ter uma boa ideia do uso intencionado deste último, definindo em uma forma de alto nível as consultas e as transações que deverão usar o banco de dados. Para cada consulta de recuperação, as seguintes informações seriam necessárias:

1. Os arquivos (relações) que serão acessados pela consulta. 2. Os atributos sobre os quais quaisquer condições de seleção para a consulta são especificadas. 3. Se a condição de seleção é uma condição de igualdade, desigualdade ou intervalo. 4. Os atributos sobre os quais são especificadas quaisquer condições de junção ou condições para ligar múltiplas tabelas ou objetos para a consulta.

5. Os atributos cujos valores serão recuperados pela consulta. Os atributos listados nos itens 2 e 4 são candidatos para a definição de estruturas de acesso, como índices, chaves de hash ou ordenação do arquivo. Para cada operação dc atualização ou transação dc atualização, a informação a seguir seria necessária:

1. Os arquivos que serão atualizados. 2. O tipo de operação em cada arquivo (inserção, atualização ou exclusão). 3. Os atributos sobre os quais as condições de seleção para uma exclusão ou atua­ lização são especificadas. 4. Os atributos cujos valores serão alterados por uma operação de atualização. Novamente, os atributos listados no irem 3 são candidatos para estruturas de acesso nos arquivos, pois eles seriam usados para localizar os registros que serão atualizados ou excluídos. Por sua vez, os atributos listados no item 4 são candidatos

581

582

Sistemas de banco de dados

para evitar unia estrutura de acesso, pois modificá-los exigirá atualização das estru­ turas de acesso. B. Analisando a frequência de chamada de consultas e transações esperada. Além de identificar as características das consultas de recuperação e transações de atua­ lização esperadas, temos de considerar suas taxas de chamada esperadas. Essa informação de frequência, com a informação de atributo coletada em cada con­ sulta e transação, é usada para compilar uma lista cumulativa da frequência de uso esperada para todas as consultas e transações. Isso é expresso como a frequência de uso esperada de cada atributo em cada arquivo como um atributo de seleção ou um atributo de junção, sobre todas as consultas c transações. Geralmcnte, para um grande volume de processamento, a regra dos 80-20 informal pode ser usada: aproximadamente 80% do processamento é atribuído a apenas 20% das consultas e transações. Portanto, em situações práticas, raramente é necessário coletar estatísticas completas c taxas de chamada em todas as consultas e transações; basta determinar 20% ou mais das mais importantes. C. Analisando as restrições de tempo de consultas e transações. Algumas consul­ tas e transações podem ter rigorosas restrições dc desempenho. Por exemplo, uma transação pode ter a restrição de que deve terminar dentro de 5 segundos em 95% das ocasiões em que é chamada, e que ela nunca deve levar mais que 20 segundos. Essas restrições de tempo colocam ainda mais prioridades nos atributos candidatos para caminhos de acesso. Os atributos de seleção usados por consultas e transações com restrições de tempo tornam-se candidatos de maior prioridade para estruturas de acesso primárias para os arquivos, visto que as estruturas de acesso primárias geralmente são as mais eficientes para localizar registros em um arquivo.

D. Analisando as frequências esperadas de operações de atualização. Um número mínimo de caminhos de acesso deve ser especificado para um arquivo que é fre­ quentemente atualizado, pois a atualização dos próprios caminhos de acesso atrasa esse tipo de operação. Por exemplo, se um arquivo que tem inserções de registro frequentes possui dez índices sobre dez atributos diferentes, cada um desses índices deve ser atualizado sempre que um novo registro é inserido. O overhead para atua­ lizar dez índices pode atrasar as operações de inserção. E. Analisando as restrições de exclusividade sobre atributos. Os caminhos de acesso devem ser especificados em todos os atributos — ou conjuntos de atributos — de chave candidata que são a chave primária de um arquivo ou atributos únicos. A existência de um índice (ou outro caminho de acesso) toma suficiente apenas procurar o índice ao verificar essa restrição de exclusividade, pois todos os valores do atributo existirão nos nós folha do índice. Por exemplo, ao inserir um novo registro, se um valor de atributo-chave do novo registro já existir no índice, a inserção do novo registro deve ser rejeitada, pois ela violaria a restrição de exclusividade sobre o atributo. Quando a informação anterior é compilada, é possível resolver as decisões de projeto físico do banco de dados, que consistem principalmente em decidir sobre as estruturas dc armazenamento e caminhos dc acesso para os arquivos de banco dc dados.

17.7.2 Decisões do projeto físico do banco de dados A maioria dos sistemas relacionais representa cada relação básica como um arquivo de banco de dados físico. As opções do caminho de acesso incluem a espe­ cificação do ripo de organização de arquivo primário para cada relação e os atribu­ tos dos quais os índices devem ser definidos. No máximo, um dos índices em cada arquivo pode ser um índice primário ou de agrupamento. Qualquer quantidade de índices secundários adicionais pode ser criada.

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

Decisões de projeto sobre indexação. Os atributos cujos valores sào exigidos nas condições de igualdade ou intervalo (operação de seleção) são os de chave ou que participam nas condições de junção (operação de junção) exigindo caminhos de acesso, como índices. O desempenho das consultas depende em grande parte de quais índices ou esque­ mas de hashing existem para agilizar o processamento de seleções e junções. Por outro lado, durante as operações de inserção, exclusão ou atualização, a existência de índices aumenta o overhead. Esse overhead precisa ser justificado em relação ao ganho em eficiência ao agilizar consultas e transações. As decisões de projeto físico para indexação ficam nas seguintes categorias:

1. Se um atributo deve ser indexado. As regras para a criação de um índice sobre um atributo são que o atributo deve scr uma chave (única) ou deve haver alguma consulta que use esse atributo em uma condição de seleção (igualdade ou intervalo de valores) ou em uma condição de junção. Um motivo para a criação de múl­ tiplos índices é que algumas operações podem ser processadas apenas varrendo os índices, sem ter dc acessar o arquivo dc dados real. 2. Que atributo ou atributos indexar. Um índice pode ser construído sobre um único atributo, ou sobre mais de um atributo, se for um índice composto. Se vários atributos de uma relação estiverem envolvidos juntos em várias consultas (por exemplo, (Codigo_estilo_roupa, Cor) em um banco dc dados de estoque de roupas), um índice multiatributos (composto) é garantido. A ordenação dos atributos em um índice multiatributos deve corresponder às consultas. Por exemplo, o índice acima considera que as consultas seriam baseadas em uma ordenação de cores em um Codigo_estilo_roupa, em vez do contrário. 3. Se um índice agrupado deve ser montado. No máximo, um índice por tabela pode ser um índice primário ou de agrupamento, pois isso implica que o arquivo seja fisicamente ordenado nesse atributo. Na maioria dos SGBDRs, isso c espe­ cificado pela palavra chave CLUSTER. (Se o atributo for uma chave, uni índice primário é criado, enquanto um índice de agrupamento é criado se o atributo nào for unia chave.} Se uma tabela exigir vários índices, a decisão sobre qual deve ser o índice primário ou de agrupamento depende da necessidade de manter a tabela ordenada nesse atributo. As consultas de intervalo se beneficiam muito do agrupamento. Se vários atributos exigem consultas de intervalo, benefícios relativos devem ser avaliados antes de se decidir sobre qual atributo agrupar. Se uma consulta tiver de ser respondida com a realização de apenas uma consulta de índice (sem recuperar registros de dados), o índice correspondente não deverá ser agrupado, pois o principal benefício do agrupamento é alcançado ao se recuperar os próprios registros. Um índice de agrupamento pode scr configurado como um índice multiatributos se a recuperação de intervalo por essa chave composta for útil na criação de relatório (por exemplo, um índice em Cep, Idjoja e ld_produto pode ser um índice de agrupamento para dados de venda). 4. Se um índice de hash deve ser usado em um índice de árvore. Em geral, os SGBDRs usam * -trees B para indexação. Contudo, o ISAM e índices de hash também são fornecidos cm alguns sistemas. As B’-trees admitem consultas dc igualdade e de intervalo no atributo usado como chave de pesquisa. Os índices de hash fun­ cionam bem com condições de igualdade, particularmente durante junções para encontrar registros correspondentes, mas eles não admitem consultas de intervalo.

5. Sc o hashing dinâmico deve scr usado para o arquivo. Para arquivos muito voláteis — ou seja, aqueles que aumentam e diminuem de maneira contínua —, um dos esquemas de hashing dinâmico discutidos na Seção 16.8 seria adequado. Atualmente, eles não são oferecidos por muitos SGBDRs comerciais.

583

584

Sistemas de banco de dados

17.8 Resumo Neste capítulo, apresentamos organizações de arquivo que envolvem estruturas de acesso adicionais, chamadas de índices, para melhorar a eficiência da recu­ peração de registros de um arquivo de dados. Essas estruturas de acesso podem ser usadas com as organizações de arquivo primárias, discutidas no Capítulo 16, utilizadas para organizar os próprios registros de arquivo no disco. Três tipos de índices de único nível ordenados foram apresentados: primá­ rio, de agrupamento e secundário. Cada índice é especificado em um campo do arquivo. índices primários e de agrupamento sào construídos sobre o campo de ordenação física de um arquivo, ao passo que os índices secundários são espe­ cificados em campos não ordenados como estruturas de acesso adicionais para melhorar o desempenho de consultas e transações. O campo para um índice primário também precisa ser uma chave do arquivo, enquanto é um campo não chave para um índice de agrupamento. Um índice de único nível é um arquivo ordenado e é pesquisado por meio de uma pesquisa binária. Mostramos como os índices multiníveis podem ser construídos para melhorar a eficiência da pes­ quisa sobre um índice. Um exemplo é o popular método de acesso sequencial indexado (ISAM) da IBM, que é um índice multinível baseado na configuração de cilindro/trilha no disco. Em seguida, mostramos como os índices multiníveis podem ser implementados como B-trees e B -trces, estruturas dinâmicas que permitem que um índice se expanda * e encolha dinamicamente. Os nós (blocos) dessas estruturas de índice são mantidos entre metade e completamente cheios por algoritmos de inserção e exclusão. Os nós, por fim, se estabilizam em uma ocupação média de 69%, permitindo espaço para inserções sem exigir reorganização do índice para a maioria das inserções. As B * -trees em geral podem manter mais entradas em seus nós internos que as B-trees, de modo que podem ter menos níveis ou manter mais entradas que uma B-tree correspondente. Demos uma visão geral dos diversos métodos de acesso de chave e mostramos como um índice pode ser construído com base nas estruturas de dados de hash. Apresentamos o conceito de hashing particionado, que é uma extensão do hashing externo para lidar com múltiplas chaves. Apresentamos também os arquivos dc grade, que organizam dados cm buckets ao longo dc várias dimensões. Discutimos o índice de hash com alguns detalhes — essa é uma estrutura secundária para acessar o arquivo, usando o hashing em uma chave de pesquisa diferente da usada para a organização primária. A indexação bitmap é outro tipo importante dc indexação utilizado para consulta por várias chaves, sendo partieularmente aplicável a campos com um pequeno número de valores únicos. Os bitmaps também podcin ser usados nos nós folha dos índices da B -tree. Também abordamos a indexação baseada em * função, que está sendo fornecida por vendedores relacionais para permitir índices especiais em uma função de um ou mais atributos. Apresentamos o conceito de um índice lógico e o comparamos aos índices físicos descritos anteriormente. Eles permitem um nível de indireção adicional na indexação, a fim de permitir maior liberdade para a movimentação dos locais de registro reais no disco. Discutimos a criação de índice em SQL, o processo de carga em massa de arquivos de índice e a indexação de strings. Discutimos as circunstâncias que justi­ ficam o ajuste de índices. Também revisamos algumas questões gerais relacionadas à indexação, incluindo gerenciamento dc restrições, uso de índices invertidos c uso dc dicas dc indexação nas consultas; comentamos o armazenamento dc relações com base em colunas, que está se tornando uma alternativa viável para o armazenamento e o acesso de grandes bancos de dados. Por fim, discutimos o projeto físico de banco de dados relacionais, que envolve decisões relacionadas ao armazenamento e o acesso

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

aos dados, assuntos que discutimos neste e no capítulo anterior. Essa discussão foi dividida em fatores que influenciam o projeto e os tipos de decisões referentes à indexação ou não de um atributo, quais atributos incluir em um índice, índices agrupados ou não agrupados, índices com hashing e hashing dinâmico.

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

17.1.

17.2.

17.3. 17.4.

17.5. 17.6. 17.7.

17.8. 17.9. 17.10. 17.11.

17.12. 17.13. 17.14. 17.15. 17.16. 17.17.

Defina os seguintes termos: campo de índice, campo de chave primária, campo de agrupamento, campo de chave secundária, âncora de bloco, índice denso e índice não denso (esparso). Quais são as diferenças entre índices primário, secundário e de agrupamento? Como essas diferenças afetam as maneiras como esses índices sâo implemen­ tados? Quais dos índices são densos e quais não são? Por que podemos ter no máximo um índice primário ou de agrupamento em um arquivo, mas vários índices secundários? Como a indexação multinível melhora a eficiência da pesquisa em um arquivo de índice? O que é a ordem p de uma B-tree? Descreva a estrutura dos nós da B-tree. O que é a ordem p dc uma * -trce? B Descreva a estrutura dos nós internos c de folha dc uma * -trce. B Como uma B-tree difere de uma * -tree? B Por que uma * -tree B normalmente é preferida como uma estrutura de acesso para um arquivo de dados? Explique que escolhas alternativas existem para acessar um arquivo com base cm múltiplas chaves dc pesquisa. O que é hashing particionado? Como ele funciona? Quais são suas limitações? O que é um arquivo de grade? Quais são suas vantagens e desvantagens? Mostre um exemplo de construção de um vetor de grade sobre dois atributos em algum arquivo. O que é um arquivo totalmente invertido? O que é um arquivo sequencial indexado? Como o hashing pode ser usado para construir um índice? O que é indexação bitmap? Crie uma relação com duas colunas e 16 tuplas, e mostre um exemplo de um índice bitmap sobre uma ou ambas as colunas. O que é o conceito dc indexação com base cm função? Para que finalidade adicional ele serve? Qual é a diferença entre um índice lógico e um índice físico? O que é armazenamento com base em coluna de um banco de dados relacionai?

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

17.18. Considere um disco com tamanho de bloco B = 512 bytes. Um ponteiro de bloco tem P = 6 bytes de extensão, e um ponteiro de registro tem PR = 7 bytes de extensão. Um arquivo tem r = 30.000 registros de FUNCIONÁRIO dc tamanho fixo. Cada registro tem os seguintes campos: Nome (30 bytes), Cpf (11 bytes), Codigo_departamento (9 bytes). Endereço (40 bytes). Telefone (10 bytes), Data_nascimento (8 bytes). Sexo (1 byte), Codigo_cargo (4 bytes) e Salario (4 bytes, número real). Um byte adicional é usado como um marcador de exclusão. a. Calcule o tamanho do registro R cm bytes.

585

586

Sistemas de banco de dados

b. Calcule o fator de bloco bfr e o número de blocos de arquivo 6, consi­ derando uma organização não estendida. c. Suponha que o arquivo seja ordenado pelo campo de chave Cpf e queira­ mos construir um índice primário sobre Cpf. Calcule (i) o fator de bloco de índice bfrt (que também é o fan-out do índice /o); (ii) o número de entradas de índice de primeiro nível e o número de blocos de índice de primeiro nível; (iii) o número dc níveis necessários se o transformarmos cm um índice multinível; (iv) o número total de blocos exigidos pelo índice multinível; e (v) o número de acessos de bloco necessários para pesquisar e recuperar um registro do arquivo — dado seu valor de Cpf — usando o índice primário. d. Suponha que o arquivo não esteja ordenado pelo campo de chave Cpf e queiramos construir um índice secundário sobre Cpf. Repita o exercí­ cio anterior (parte c) para o índice secundário e compare com o índice primário. e. Suponha que o arquivo não esteja ordenado pelo campo não chave Codigo_departamento e queiramos construir um índice secundário sobre Codigo_departamento, usando a opção 3 da Seção 17.1.3, com um nível extra dc indireção que armazena ponteiros de registro. Suponha que existam 1.000 valores distintos de Codigo_departamento e que os registros de FUNCIONÁRIO estejam distribuídos uniformemente entre esses valores. Calcule (i) o fator de bloco dc índice bfr: (que também é o fan-out dc índice /o); (ii) o número dc blocos necessários pelo nível dc indireção que armazena ponteiros de registro; (iii) o número de entradas de índice de primeiro nível e o número de blocos de índice de primeiro nível; (iv) o número de níveis necessários se o transformarmos em um índice multinível; (v) o número total de blocos exigidos pelo índice multinível e os blocos usados no nível de indireção extra; e (vi) o número aproximado dc acessos dc bloco necessários para pesquisar c recuperar todos os regis­ tros no arquivo que têm um valor específico de Codigo_departamento, usando o índice. f. Suponha que o arquivo esteja ordenado pelo campo não chave Codigo_ departamento e que queiramos construir um índice de agrupamento sobre Codigo_departamento que use âncoras dc bloco (cada novo valor de Codigo_departamento começa no início de um novo bloco). Suponha que existam 1.000 valores distintos de Codigo.departamento e que os registros de FUNCIONÁRIO sejam distribuídos uniformemente entre esses valores. Calcule (i) o fator de bloco de índice bfrê (que também é o fan-out do índice fo); (ii) o número de entradas de índice de primeiro nível e o número de blocos de índice de primeiro nível; (iii) o número de níveis necessários se o transformarmos em um índice multinível; (iv) o número total de blocos exigidos pelo índice multinível; e (v) o número de aces­ sos dc bloco necessários para pesquisar e recuperar todos os registros no arquivo que tenham um valor específico dc Codigo_departamento, usando o índice dc agrupamento (suponha que vários blocos em um cluster sejam contínuos). g. Suponha que o arquivo não esteja ordenado pelo campo de chave Cpf c que queremos construir uma estrutura de acesso (índice) * -tree B sobre Cpf. Calcule (i) as ordens p c pfo|ha da * -tree; B (ii) o número dc blocos cm nível de folha necessários se os blocos estiverem aproxima­ damente 69% cheios (arredondado por conveniência); (iii) o número de níveis necessários se os nós internos também estiverem 69% cheios

Capitulo 17

17.19.

17.20.

17.21.

17.22. 17.23.

17.24.

17.25. 17.26.

17.27. 17.28.

Estruturas de indexação para arquivos e projeto físico de banco de dados

(arredondado por conveniência); (iv) o número total de blocos exigi­ dos pela B -tree; * e (v) o número de acessos de bloco necessários para procurar e recuperar um registro do arquivo — dado seu valor de Cpf — usando a B"-tree. h. Repita a parte g, mas para uma B-tree em vez de uma * -tree. Compare B seus resultados para a B-tree e para a B’-tree. Um arquivo PECAS com Numero_peca como campo de chave inclui registros com os seguintes valores de Numero.peca: 23,65, 37,60,46, 92,48, 71, 56, 59,18, 21,10, 74, 78,15,16, 20, 24,28, 39, 43,47, 50, 69, 75, 8, 49, 33, 38. Suponha que os valores do campo de pesquisa sejam inseridos na ordem dada em uma B‘-tree de ordem p = 4 e pfüUia = 3; mostre como a árvore será expandida e como será sua aparência final. Repita o Exercício 17.19, mas use uma B-tree de ordem p = 4 no lugar de uma B"-tree. Suponha que os valores de campo de pesquisa a seguir sejam excluídos, na ordem indicada, da * -tree B do Exercício 17.19. Mostre como a árvore será encolhida e sua forma final. Os valores excluídos sào 65, 75,43,18,20, 92, 59, 37. Repita o Exercício 17.21, mas para a B-tree do Exercício 17.20. O Algoritmo 17.1 esboça o procedimento de pesquisa sobre um índice pri­ mário mulrinível não denso para recuperar um registro do arquivo. Adapte o algoritmo para cada um dos seguintes casos: a. Um índice secundário mulrinível cm um campo não ordenado não chave de um arquivo. Suponha que a opção 3 da Seção 17.1.3 seja usada, em que um nível de indireção extra armazena ponteiros para os registros individuais com o valor correspondente de campo de índice. b. Um índice secundário mulrinível em um campo de chave não ordenado de um arquivo. c. Um índice dc agrupamento mulrinível cm um campo de ordenação não chave de um arquivo. Suponha que existam vários índices secundários em campos não chave de um arquivo, implementados usando a opção 3 da Seção 17.1.3. Por exem­ plo, poderiamos ter índices secundários nos campos Codigo_departa mento, Codigo_cargo e Salario do arquivo FUNCIONÁRIO do Exercício 17.18. Descreva um modo eficiente de pesquisar e recuperar registros que satisfaçam uma condição de seleção complexa sobre esses campos, como (Codigo_departamento = 5 AND Codigo_cargo = 12 AND Salario = 50000), usando ponteiros de registro no nível de indireção. Adapte os algoritmos 17.2 e 17.3, que esboçam procedimentos de pesquisa e inserção de uma * -tree B para uma B-tree. É possível modificar o algoritmo de inserção da * -tree B para adiar o caso em que um novo nível é produzido ao verificar uma redistribuição possível de valores entre os nós folha. A Figura 17.17 ilustra como isso poderia ser feito para o exemplo da Figura 17.12; cm vez de dividir o nó folha mais à esquerda quando 12 c inserido, realizamos uma redistribidção à esquerda movendo 7 para o nó folha à sua esquerda (se houver espaço nesse nó). A Figura 17.17 mostra como a árvore ficaria quando a redistribuição é considerada. Também é possível considerar a redistribuição ã direita. Tente modificar o algoritmo de inserção da B'-tree para levar em conta a redistribuição. Esboce um algoritmo para exclusão com base em uma * -tree. B Repita o Exercício 17.27 para uma B-tree.

587

588

Sistemas de banco de dados

Inserção 12: overflow (redrst riboição â esquerda)

Figura 17.17 Inserção de B’-tree com redistribuição à esquerda.

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

Indexação: Bayer e McCreight (1972) introduziram B-trees e algoritmos associa­ dos. Comer (1979) oferece um excelente estudo das B-trees e sua história, além de suas variações. Knuth (1998) faz uma análise detalhada de muitas técnicas de pes­ quisa, incluindo B-trees e algumas de suas variações. Nievergelt (1974) discute o uso das árvores de pesquisa binária para organização de arquivo. Os livros-texto sobre estruturas de arquivo, incluindo Claybrook (1992), Smith c Barnes (1987) e Salzberg (1988), os livros-texto sobre algoritmos e estruturas de dados de Wirth (1985), bem como o livro-texto de banco de dados de Ramakrishnan e Gehrke (2003) discutem a indexação com detalhes, e podem ser consultados para algoritmos de pesquisa, inserção e exclusão para B-trees e B -trees. Larson (1981) analisa arquivos sequenciais * indexados, e Held e Stonebraker (1978) comparam os índices multiníveis estáticos com índices dinâmicos de B-tree. Lehman e Yao (1981) e Srinivasan e Carey (1991) realizaram mais análise do acesso concorrente a B-trees. Os livros de Wiederhold (1987), Smith e Barnes (1987) e Salzberg (1988), entre outros, discutem muitas das técnicas de pesquisa descritas neste capítulo. Arquivos de grade são apresentados em Nievergelt et al. (1984). A recuperação de combinação parcial, que usa o hashing particionado, é discutida em Burkhard (1976, 1979).

Capitulo 17

Estruturas de indexação para arquivos e projeto físico de banco de dados

Novas técnicas e aplicações de índices e B’-trees sào discutidas em Lanka e Mays (1991), Zobel et al. (1992) e Faloutsos e Jagadish (1992). Mohan e Narang (1992) discutem a criação de índice. O desempenho de diversos algoritmos de B-tree e -tree * B é avaliado em Baeza-Yates e Larson (1989) e Johnson e Shasha (1993). O gerenciamento de buffer para índices é discutido em Chan et al. (1992). O armaze­ namento de bancos de dados com base em colunas foi proposto por Stonebraker et al. (2005) no sistema dc banco dc dados C-Storc; MonctDB/XlOO, de Boncz ct al. (2008), é outra implementação da ideia. Abadi et al. (2008) discutem as vantagens dos bancos de dados armazenados por colunas em relação aos armazenados por linhas para aplicações de banco de dados somente de leitura. Projeto físico de banco de dados: Wiederhold (1987) aborda questões relacio­ nadas ao projeto físico. O'Neil e O’Neil (2001) tem uma discussão detalhada do projeto físico e questões de transação em referência a SGBDRs comerciais. Navalhe e Kerschberg (1986) discutem todas as fases do projeto de banco de dados e apontam o papel dos dicionários de dados. Rozen e Shasha (1991) e Carlis e March (1984) apresentam diferentes modelos para o problema do projeto físico do banco de dados. Shasha e Bonnet (2002) têm uma discussão elaborada das orientações para ajuste dc banco dc dados. Niemiec (2008) c um entre vários livros disponíveis para administração c ajuste dc banco dc dados Oracle. Schneider (2006) é voltado para o projeto e o ajuste de bancos de dados MySQL.

589

PARTE 8 Processamento e otimização de consulta

18

Estratégias para processamento de consulta1 este capítulo, discutimos as técnicas usadas internamente por um SGBD para processar, otimizar e executar consultas de alto nível. Uma consulta expressa em uma linguagem de consulta de alto nível, como SQL, primeiro precisa ser lida, analisada e validada.2 A varredura {scanner) identifica os tokens de con­ sulta — como as palavras-chave SQL, nomes dc atributo c nomes dc relação — que aparecem no texto da consulta, enquanto o analisador sintático {parser) verifica a sintaxe da consulta para determinar se ela está formulada de acordo com as regras de sintaxe (regras de gramática) da linguagem de consulta. A consulta também pre­ cisa ser validada verificando se todos os nomes dc atributo e relação são válidos e semanticamcnte significativos no esquema do banco dc dados em particular sendo consultado. Uma representação interna da consulta é então criada, normalmente como uma estrutura de dados de árvore chamada árvore de consulta. Também é possível representar a consulta usando uma estrutura de dados de grafo, chamada grafo de consulta, que é geralmente um grafo acídico direcionado. O SGBD precisa então idealizar uma estratégia dc execução ou plano dc consulta para recuperar os resultados da consulta com base nos arquivos dc banco dc dados. Uma consulta costuma ter muitas estratégias de execução possíveis, e o processo de escolha de uma estratégia adequada para processá-la é conhecido como otimização de consulta. Deixamos uma discussão detalhada da otimização de consulta para o próximo capítulo. Neste, vamos focar principalmente em como as consultas são processa­ das c quais algoritmos são usados para realizar as operações individuais dentro da consulta. A Figura 18.1 mostra as diferentes etapas do processamento de uma consulta de alto nível. O módulo otimizador de consulta tem a tarefa de produzir

N

1 Agradecemos a contribuição de Rafi Ahmcd na atualização deste capítulo.

2 Não discutiremos aqui a fase de análise e verificação de sintaxe do processamento da consulta; esse

material é discutido nos livros-texto sobre compilador.

594

Sistemas de banco de dados

Figura 18.1 Etapas típicas ao processar uma consulta de alto nível.

Consulta em uma linguagem de alto nível

____ 1____

Varredura, análise e validação

Forma imediata de consulta

Código pode ser:

Executado diretamente (modo interpretado) Armazenado e executado mais tarde,

sempre que possível (modo compilado)

Resultado da consulta

um bom plano de execução, e o gerador de código dá origem ao código para executar esse plano. O processador cm tempo de execução do banco de dados tem a tareia dc rodar (executar) o código da consulta, seja no modo compilado, seja interpretado, para produzir o resultado da consulta. Se houver um erro em tempo de execução, uma mensagem de erro é gerada pelo processador em tempo de execução do banco de dados. O termo otimização é, na realidade, um nome errado, pois em alguns casos o plano de execução escolhido não é a estratégia ótima (ou a melhor absoluta) — trata-se apenas de uma estratégia razoavelmente eficiente ou a melhor estratégia avaliada para executar a consulta. Encontrar a estratégia ideal em geral é muito demorado — exceto para a mais simples das consultas. Além disso, tentar encontrar a estratégia de execução de consulta ideal pode exigir informações detalhadas e precisas sobre o tamanho das tabelas e as distribuições de coisas como valores de coluna, que podem não estar totalmentc disponíveis no catálogo do SGBD. Além disso, informações detalhadas como o tamanho do resultado esperado deverão ser derivadas com base nos predicados da consulta. Logo, o planejamento de uma boa estratégia de execução pode ser uma descrição mais precisa que a otimização de consulta. Para as linguagens dc banco dc dados navcgacionais dc nível mais baixo nos sistemas legados — como a DML dc rede ou a DL/1 hierárquica —, o programador deve escolher a estratégia de execução de consulta enquanto escreve o programa de banco de dados. Se um SGBD oferece apenas uma linguagem navegacional, existe uma necessidade ou oportunidade limitada para otimização de consulta extensiva pelo SGBD; em vez disso, o programador recebe a capacidade de escolher a estratégia dc execução de consulta. Por sua vez, uma linguagem de consulta de alto nível — como SQL para SGBDs relacionais (SGBDRs) ou OQL (ver Capítulo 12) para SGBDs de objeto (SGBDOs) — é mais dcclarativa por natureza, pois especifica quais são os resultados intencionados da consulta, em vez de identificar os detalhes de como o resultado deve ser obtido. A otimização de consulta é, portanto, necessária para consultas especificadas cm uma linguagem dc consulta dc alto nível.

Capitulo 18

Estratégias para processamento de consulta

Vamos nos concentrar na descrição da otimização de consulta no contexto de uni SGBDR, pois muitas das técnicas que descrevemos também foram adaptadas para outros tipos de sistemas de gerenciamento de banco de dados, como os SGBDOs.3 Um SGBD relacionai deve avaliar sistematicamente estratégias alternativas de exe­ cução de consulta e escolher uma estratégia razoavelmente eficiente ou quase ideal. A maioria dos SGBDs normalmente tem uma série de algoritmos gerais de acesso dc banco dc dados que implementam operações da álgebra relacionai, como SELECT ou JOIN (ver Capítulo 8) ou combinações dessas operações. Somente estratégias dc execução que podem ser implementadas pelos algoritmos de acesso do SGBD e que se aplicam à consulta em particular, bem como ao projeto de banco de dados físico em particular, podem ser consideradas pelo módulo de otimização de consulta. Este capítulo está organizado da seguinte forma: a Seção 18.1 começa com uma discussão geral de como as consultas SQL costumam ser traduzidas para consultas da álgebra relacionai e operações adicionais, para depois serem otimizadas. Depois, discutimos algoritmos para implementar operações da álgebra relacionai nas seções 18.2 a 18.6. Na Seção 18.7, discutimos a estratégia para execução chamada de pipelining. A Seção 18.8 oferece uma breve visão geral da estratégia para execução paralela dos operadores. A Seção 18.9 resume o capítulo. No próximo capítulo, daremos uma visão geral das estratégias de otimização de consulta. Existem duas técnicas principais empregadas durante a otimização da con­ sulta. A primeira é baseada em regras heurísticas para ordenar as operações em uma estratégia de execução de consulta, que funciona bem na maioria dos casos, mas não garante funcionar bem em todos eles. As regras costumam reordenar as operações em uma árvore de consulta. A segunda técnica envolve estimar sistematicamente o custo de diferentes estratégias de execução e escolher o plano de execução com a estimativa de custo mais baixa. Os tópicos abordados neste capítulo exigem que o leitor esteja acostumado com o material apresentado em vários capítulos anteriores. Em particular, os capítulos sobre SQL (capítulos 6 e 7), álgebra relacionai (Capítulo 8) e estruturas e indexação de arquivo (capítulos 16 e 17) são um pré-requisito para este capítulo. Além disso, é importante observar que o tópico de processamento e otimização de consulta é vasto, e só podemos oferecer uma introdução aos princípios e técnicas básicas neste e no próximo capítulo. Diversos trabalhos importantes são mencionados na Bibliografia selecionada deste e do próximo capítulo.

18.1 Traduzindo consultas SQL para álgebra relacionai e outros operadores Na prática, a SQL é a linguagem de consulta usada na maioria dos SGBDRs comerciais. Uma consulta SQL é primeiro traduzida para uma expressão equivalente da álgebra relacionai estendida — representada como uma estrutura de dados de árvore de consulta — que é, então, otimizada. Normalmente, as consultas SQL são decompostas em blocos de consulta, que formam as unidades básicas que podem ser traduzidas em operadores algébricos e otimizadas. Um bloco de consulta contém uma única expressão SELECT-FROM-WHERE, bem como cláusulas GROUP BY e HAVING, se estas fizerem parte do bloco. Logo, as consultas aninhadas em uma consulta são identificadas como blocos de consulta separados. Como a SQL inclui operadores de agregação — como MAX, MIN, SUM e COUNT — esses operadores também precisam ser incluídos na álgebra estendida, conforme discutimos na Seção 8.4. ’ Existem alguns problemas c técnicas dc otimização dc consulta que são pertinentes apenas aos SGBDOs. Contudo, nào os discutimos aqui porque oferecemos apenas uma introdução ao processa mento de consulta, e não discutimos a otimização da consulta antes do Capítulo 19.

595

596

Sistemas de banco de dados

Considere a seguinte consulta SQL na relação FUNCIONÁRIO na Figura 5.5: SELECT Ultimo_nome, Primeiro_nome FROM FUNCIONÁRIO WHERE Salario >( 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 de 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 em 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

F.NumerO-departamento

FROM

FUNCIONÁRIO F

WHERE

F.Salario > 200000)

Aqui, remos uma consulta aninhada que é unida pelo conector IN. Remover a consulta aninhada: (

SELECT

F.Numero_departamento

FROM

FUNCIONÁRIO F

WHERE

F.Salario > 200000)

é 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

COUNT»

FROM

FUNCIONÁRIO F, DEPARTAMENTO D

WHERE

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):

SELECT COUNT»

FROM

FUNCIONÁRIO

WHERE

FUNCIONÁRIO.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 de 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) c 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-inerge) usados para JOIN e outras operações (como UNION c INTERSECTION), e em algoritmos dc eliminação de 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 exatainente 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 de cada pedaço e o número dc pedaços iniciais (wR) 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 dc intercalação. Cada passo de intercalação pode ter uma ou mais etapas dc intercalação. O grau dc intercalação ( 30000 AND Sexo = F (FUNCIONÁRIO)

OP^ c’Cpf_funciorere='12345678966 AND Numero_prajeto =i0(TRABALHA_EM)

0P6: Uma consulta SQL: SELECT

*

FROM

FUNCIONÁRIO

WHERE

Numero-departamento IN (3, 27, 49)

Capitulo 18

Estratégias para processamento de consulta

OP7: Uma consulta SQL (da Seção 17.5.3) SELECT Primei ro.nome, Ultimo.nome FROM FUNCIONÁRIO WHERE ((Salario’porc.Comissao) + Salario) > 15000; Métodos de pesquisa para seleção simples. Diversos algoritmos de pesquisa são possíveis para selecionar registros de um arquivo. Estes são conhecidos como var­ reduras de arquivo porque varrem os registros de um arquivo para procurar e recu­ perar registros que satisfazem uma condição de seleção." Se o algoritmo de pesquisa envolve o uso de um índice, a pesquisa do índice é denominada varredura de índice. Os métodos de pesquisa a seguir (SI a S6) são exemplos de alguns dos algoritmos de pesquisa que podem ser usados para implementar uma operação de seleção: ■ SI — Pesquisa linear (algoritmo dc força brutal. Recupera cada registro no arquivo c testa se seus valores dc atributo satisfazem a condição de seleção. Como os registros são agrupados em blocos de disco, cada um desses blocos é lido para um buffer da memória principal, e depois uma pesquisa pelos registros no bloco de disco é realizada na memória principal. ■ S2 — Pesquisa binária. Se a condição de seleção envolver uma comparação dc igualdade sobre um atributo-chave no qual o arquivo é ordenado, a pesquisa binária — que é mais eficiente que a pesquisa linear — pode ser utilizada. Um exemplo é OP1 se Cpf for o atributo de ordenação para o arquivo FUNCIONÁRIO.78 ■ S3a — Usando um índice primário. Se a condição de seleção envolver uma com­ paração dc igualdade sobre um atributo-chavc com um índice primário — por exemplo, Cpf = ‘12345678966’ cm OP1 —, use o índice primário para recuperar o registro. Observe que essa condição recupera um único registro (no máximo). ■ S3b — Usando uma chave hash. Se a condição dc seleção envolver uma compara­ ção dc igualdade sobre um atributo-chavc com uma chave hash — por exemplo, Cpf = ‘12345678966’ em 0P1 —, use a chave hash para recuperar o registro. Observe que essa condição recupera um único registro (no máximo). ■ S4 — Usando um índice primário para recuperar vários registros. Se a condição de comparação for >, >=, < 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 também pode ser usado para comparações envolvendo >, >=, < ou '31-12-1957'

PROJETO P

F.UItimo nome

(e)

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 por operações JUNÇÃO. (e) Movendo operações PROJEÇÃO mais para baixo na árvore de consulta. (continuação)

T.Cpf_funcionario=F.Cpf

7 T.Cpf_funcionario M I P.Numero projeto= T.Numero_projeto

* P.Numero_projeto

F.Cpf, F.Ultimo_nome

°F.Data nascimento>'31-12-1957'

'^T.Cpf-funcionario, T. N u mero_projeto

°P.Nome projeto ='Aquarius' TRABALHA EM T

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 de seleção conjuntiva pode ser desmembrada em uma cascata (ou seja, uma sequência) dc operações o individuais: (...(O^JR))...))

Qq AND = 1000. Para 0P2, podemos usar ou o método Sl (com custo estimado Csu = 2000) ou o método S6b (com custo estimado C^ = xNuner0 depanamefT0 + (b/INun>!ro_3epartanerto/2) + (rF /2) = 2 + (4/2) + (10000/2) = 5004), de modo que escolhemos a técnica de pesquisa linear para OP2. Para OP3, podemos utilizar o método Sl (com custo esti­ mado CSIj = 2000) ou o método S6j (com custo estimado = ^Nimero.depenamerxo + ^Numero departamento = 2 + 80 = 82), de modo que escolhemos o método S6j. Finalmente, considere OP4, que tem uma condição de seleção conjuntiva. Precisamos estimar o custo de usar qualquer um dos três componentes da condição dc seleção para recuperar os registros, mais a técnica de pesquisa linear. A última gera a estimativa dc custo CSld = 2000. O uso da condição (Numero_departamento = 5) primeiro gera a estimativa dc custo = 82. O uso da condição (Salario > 30000) primeiro gera a estimativa de custo CS4 = x^^ + (bFH) = 3 + (2000/2) = 1003. O uso da condição (Sexo = T’) primeiro gera a estimativa de custo C^ = Xsexo + sSexo = 1 + 5000 = 5001.0 otimizador, então, escolheria o método S6a sobre o índice secundário em Numero.departamento, pois ele tem a menor estimativa de custo. A condição (Numero.departamento = 5) serve para recuperar os registros, e a parte restante da condição conjuntiva (Salario > 30000 AND Sexo = ‘F) é verifi­ cada para cada registro selecionado depois que ele for recuperado para a memória. Apenas os registros que satisfazem essas condições adicionais são incluídos no resultado da operação. Considere a condição Numero.departamento = 5 em OP3, mostrada; Numero.departamento tem 125 valores c, portanto, um índice de B’-trcc seria apropriado. Em vez disso, se tivéssemos um atributo Cep em FUNCIONÁRIO e se a condição fosse Cep = 30332000, e tivéssemos apenas cinco códigos postais, a indexação bitmap podería ser usada para descobrir quais registros se qualificam. Considerando uma distribuição uniforme, = 2000. Isso resultaria em um custo dc 2000 para a indexação bitmap.

19.5 Funções de custo para a operação JUNÇÃO Para desenvolver funções dc custo razoavelmente precisas para operações JUNÇÃO, precisamos ter uma estimativa do tamanho (número de tuplas) do arquivo resultante após as operações JUNÇÃO. Isso costuma ser mantido como uma razão

Capitulo 19

Otimização de consulta

entre o tamanho (número de tuplas) do arquivo de junção resultante e o tamanho do arquivo de produto cartesiano (PRODUTO CARTESIANO), se ambos forem aplica­ dos aos mesmos arquivos de entrada, e é chamado de seletividade de junção (;s). Se indicarmos o número de tuplas de uma relação R como IRI, temos:

js = l(R

S)l / l(R x S)l = l(R m S)l / (IRI * ISI)

Se não houver condição de junção c, então /$ = 1 e a junção é igual ao produto cartesiano. Se nenhuma tupla das relações satisfizer a condição de junção, então /$ = 0. Em geral, 0 < js < 1. Para uma junção em que a condição c é uma comparação de igualdade R.A = S.B, chegamos aos dois casos especiais a seguir:

1. Se A é uma chave de R, então I(R *t. S)l < ISI, de modo que /s < (1/IRI). Isso por­ que cada registro no arquivo S será juntado com no máximo um registro no arquivo R, pois A é uma chave dc R. Um caso especial dessa condição c quando o atributo B c uma chave estrangeira de S que referencia a chave primária A dc R. Além disso, se a chave estrangeira B tiver a restrição NOT NULL, então js = (1/IRI), e o arquivo de resultado da junção terá ISI registros. 2. Se B é uma chave dc S, então I(R

S)l < IRI, de modo que js < (1/ISI).

Daí uma fórmula simples para usar para a seletividade dc junção é:

js = 1/max (NVD(A, R), NVD (B,S) )

Ter uma estimativa da seletividade de junção para condições de junção que ocorrem normalmcntc permite que o otimizador dc consulta estime o tamanho do arquivo resultante após a operação dc junção, que chamamos de cardinalidade dc junção ijc). jc = \(RCS)\ = js * \R\ * \S\ Agora, podemos dar alguns exemplos de funções de custo aproximado para esti­ mar o custo de alguns dos algoritmos de junção dados na Seção 18.4. As operações de junção têm a forma:

em que A e B são atributos compatíveis em domínio dc R e S, respectivamente. Suponha que R tenha blocos e que S tenha bs blocos: ■ J1 —Junção de loop aninhado. Suponha que usemos R para o loop externo; depois obtemos a seguinte função dc custo para estimar o número dc blocos para este método, considerando três buffers de memória. Consideramos que o fator de bloco para o arquivo resultante seja bfrRS e que a seletividade de junção seja conhecida:

Cji = hR + (hR * hs) + ((js *

IRI * ISb/bfr^)

A última parte da fórmula é o custo de gravar o arquivo resultante em disco. Esta fórmula de custo pode ser modificada para levar cm conta diferentes números de buffers de memória, conforme apresentado na Seção 19.4. Sc nfí blocos dc buffers da memória principal estiverem disponíveis para realizar a junção, a fórmula de custo torna-se:

Cji =

+
1 *

+ «A * IRI * ISIVbfrd

■ J2 — Junção de loop aninhado baseada em índice [usando uma estrutura de acesso para recuperar o(s) registro(s) que combina(m)]. Se existir um índice para o atributo de junção B de S com níveis de índice xB, podemos recuperar cada registro s cm R c depois usar o índice para recuperar todos os registros / dc S que combinam e que satisfaçam Z[B] = s[A]. O custo depende do tipo de índice. Para

649

650

Sistemas de banco de dados

um índice secundário em que sB é a cardinalidade de seleção para o atributo de junção B de S,9 obtemos: CJ2j = bR + (IRI * (x8 + 1 + sfl)) + ((is * IRI * ISIWnJ Para um índice de agrupamento em que sB é a cardinalidade de seleção de B, obtemos

CJ2b = bR +

+ «/5 * IR| * I51)/^Rs)

Para um índice primário, obtemos CJ2e = bR + (IRI * (xB + 1)) + ((js * IRI * ISWrRs) Se houver uma chave hash para um dos dois atributos de junção — digamos, B de S —, obtemos

CJ2j=bR + (|R| * ^) + «A * IRI * ISI)/fc/rRS) em que h £ 1 é o número médio de acessos de bloco para recuperar um registro, dado seu valor de chave hash. Normalmente, h é estimado como 1 para o hashing estático e linear e 2 para o hashing extensível. Essa é uma estrutura otimista e em geral h varia de 1,2 a 1,5 em situações práticas. ■ J 3 — Junção merge-sort. Se os arquivos já estiverem ordenados sobre os atributos dc junção, a função dc custo para esse método é

= bR + bs +

* IRI * ISI)/^/rR5)

Se tivermos dc ordenar os arquivos, o custo dc ordenação precisa ser acrescentado. Podemos usar as fórmulas da Seção 18.2 para estimar esse custo.

■ J4 — Junção de partição-hash (ou simplesmente junção de hash). Os registros dos arquivos ReS são particionados em arquivos menores. O particionamento de cada arquivo é feiro usando-se a mesma função de hashing h sobre o atributo de junção Ade R (para o arquivo de particionamento R) e B de S (para o arquivo dc particionamento S). Conforme mostramos na Seção 18.4, o custo dessa junção pode ser aproximado para:

CJ4 = 3 * (bR + bs) + (( is * IRI * \S\)/bfrRS)

19.5.1 Seletividade e cardinalidade de junção para semijunçào e antijunção Consideramos estas duas operações importantes, usadas para o desaninhamenro dc cenas consultas. Na Seção 18.1, mostramos exemplos de subconsultas que são transformadas nessas operações. O objetivo dessas operações é evitar o esforço desnecessário de realizar uma correspondência cm pares exaustiva de duas tabelas com base na condição de junção. Vamos considerar a seletividade e a cardinalidade desses dois tipos de junções.

Semijunção SELECT COUNT( ) * FROM TI WHERE Tl.X IN (SELECT T2.Y FROM T2); ’ A cardinalidade de seleção foi definida como o número medio dc registros que satisfazem uma condi­

ção de igualdade sobre um atributo, que é o número médio de registros que têm o mesmo valor para o atributo e, portanto, serão juntados a um único registro no outro arquivo.

Capitulo 19

Otimização de consulta

O desaninhamento da consulta anterior leva à semijunção. (Na consulta a seguir, a notação “S=” para a semijunção não faz parte do padrão.) SELECT COUNT( ) * FROMT1,T2 WHERE T1.XS= T2.Y;

A seletividade de junção da semijunção anterior é dada por: is = MIN(1,NVD(Y,T2)/NVD(X,T1))

A cardinalidade de junção da semijunção é dada por: jc = IT1I * js

Antijunção Considere a seguinte consulta:

SELECT COUNT(’) FROM TI WHERE TLX NOT IN ( SELECT T2.Y FROM T2);

O desaninhamento da consulta anterior leva à antijunção.10 (Na consulta a seguir; a notação “A=” para a antijunção não faz parte do padrão.) SELECT COUNT(’) FROMT1,T2 WHERE TLX A= T2.Y;

A seletividade de junção da antijunção anterior é dada por: is = 1 - MIN(l,NVD(T2.y)/NVD(Tl.x)) A cardinalidade de junção da antijunção é dada por: jc = ITl I * is

19.5.2 Exemplo de otimização de junção baseada em fórmulas de custo Suponha que tenhamos o arquivo FUNCIONÁRIO descrito no exemplo da seção anterior, e que o arquivo DEPARTAMENTO da Figura 5.5 consista em rD = 125 registros armazenados em = 13 blocos de disco. Considere as duas operações de junção: 0P6: FUNCIONÁRIO ^^o_^^^NuTCro_^TCnto DEPARTAMENTO 0P7: DEPARTAMENTO

FUNCIONÁRIO

Suponha que tenhamos um índice primário sobre Numero.departamento de DEPARTAMENTO com xNlMnero aeça^merto = 1 nível e um índice secundário sobre Cpf_ gerente de DEPARTAMENTO com cardinalidade de seleção = 1c níveis * qí_geferte = 2. Suponha que a seletividade de junção para 0P6 seja /sOP6 = (1/lDEPARTAMENTOl) = 1/125,11 pois Numero.departamento é uma chave de DEPARTAMENTO. Suponha também que o fator de bloco para o arquivo dc junção resultante seja bfrrD= 4 registros por

10 Observe que, para que a antijunção seja usada na subconsulta de NOT IN, os dois atributos da junção, T1.X e T2.Y, precisam ter valores não nulos. Para obter uma discussão detalhada, consulte Bellamkonda et al. (2009). 11 Observe que isso coincide com nossas outras fórmulas: = 1/max(NVD(Numero_depanamento,

FUNCIONÁRIO), NVD(Numero_departamento, DEPARTAMENTO) = 1/max (125,125) = 1/125.

651

652

Sistemas de banco de dados

bloco. Podemos estimar os custos no pior caso para a operação JUNÇÃO 0P6 usando os métodos aplicáveis JI e J2, da seguinte forma: 1. Usando o método J1 com FUNCIONÁRIO como loop externo:

Cj, = bF + (bF * bD) + ((/SQP6 * rF * rD)lbfrFD} = 2000 + (2000 * 13) + ((1/125) * 10000 * 125)/4) = 30500

2. Usando o método J1 com DEPARTAMENTO como loop externo: Cji = bD + (bF * bD} + (( /sore * rF * rD)/bfrFD) = 13 + (13 * 2000) + ((1/125) * * 10000 125/4) = 28513

3. Usando o método J2 com FUNCIONÁRIO como loop externo: Çj2t = + (rF * (A'Nurnero departamento +!)) + ((/SQpg * rF * rD)lbfrFD = 2000 + (10000 * 2) + ((1/125) * 10000 * 125/4) = 24500

4. Usando o método J2 com DEPARTAMENTO como loop externo: Çj2a= + ^rD ('VNumero_departamento + 5Numero_óepartamerto^ + K /SOP6 bfrFD) = 13 + (125 * (2 + 80)) + ((1/125) * 10000 * 125/4) = 12763

rF

rD^

5. Usando o método J4, obtemos:

CJ4 = 3 * (bD + bh) + ((/Sopé * rh * rD)lbfrFD) = 3 * (13 + 2000) + 2500 = 8539

O caso 5 tem a menor estimativa de custo e será escolhido. Observe que, no caso 2, se 15 buffers de memória (ou mais) estivessem disponíveis para executar a junção em vez de apenas três, 13 deles poderiam ser usados para manter a relação DEPARTAMENTO inteira (relação de loop externo) na memória, um poderia ser usado como buffer para o resultado e um seria usado para manter um bloco de cada vez do arquivo FUNCIONÁRIO (arquivo de loop interno), e o custo para o caso 2 seria drasticamente reduzido para apenas bF + bD + ((;$op6 * * rDVbfrFD)9 ou 4513, conforme discutimos na Seção 18.4. Se algum outro número de buffers da memória principal estivesse disponível, digamos, nR = 10, então o custo para o caso 2 seria calculado da seguinte forma, que também daria um desempenho melhor que o caso 4:

cJI= bD+(rv (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 dc 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, FUNCION/XRIO 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 dc 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 rcfcrindo-sc às variáveis dc consulta. A consulta 2 tem três variáveis (f,tep)c retorna os projetos e horas por semana cm 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.projcto = 2. A consulta 4 ilustra a cláusula ORDER BY c retorna todos os funcionários e os projetos nos quais eles trabalham, classificados por Primciro_nomc. 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 dc visualização de grafos, para que um subconjunto dc nós e bordas em um de 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 de 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 é geralmente 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 dc 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 de 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 e sharding. Como a consistência e 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 al. (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 arrigos 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 e 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 dc 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 e 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 US$ 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 data 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 c 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. 1 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, c 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 MapReduce/Hadoop. Primeiro, discu­ timos essa tecnologia cm comparação à tecnologia de 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 de 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 dc energia, monitoramento ambiental, monitoramento c regulação dc 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 de dados de texto. Assim, os dados dc multimídia que estão sendo carregados no YouTube c em plataformas de 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 Nco4j, 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 dc programação MapReduce e o HDFS, o Hadoop Distributed File System. Vamos explicar brevemente o histórico por trás do Hadoop c, cm seguida, o MapReduce. Depois, faremos algumas breves observações sobre o ecossistema Hadoop c 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 de 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 em 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 Cloudera em 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 em 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 Ghemawar, Gbiofí 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.). Conceirualmente, 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 de programação MapReduce e o ambiente de runtime foram projetados para lidar com a complexidade anteriormente citada. A abstração é 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 de interesse na forma de uma chave única que tenha conteúdo ou valor associados. Este e o par chave-valor. Surpreendentemente, muitos cálculos podem ser expressos como a aplicação de uma operação map a cada44registro" 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 idéia de fornecer um modelo de programação restrito para que o runtime possa executar cálculos em 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 de 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 K1 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 dc 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:

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 (2004).

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.our) 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 e 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 dc 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 URl-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 dc 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 empacotadas 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 cm uma configuração. Existem centenas dc 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: geralmente especificada como caminhof s) 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 é executado cm 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 Write-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 dc 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 NameXodes 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 de 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 em 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 de gravação e 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 de 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 estã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 perto 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 seguia 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 i-node. Cem milhões de 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 de uma capacidade de 6 TB. Isso pode ser obtido com oito drives de 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 em 60K blocos por relatório foram recebidos pelo NameNode. ■ A carga externa no NameNode consistia cm conexões externas e tarefas de jobs do MapReduce. Isso resultou em dezenas de milhares de conexões simultâneas. ■ A leitura do cliente consistia em realizar uma pesquisa de blocos para obter localizações de blocos do NameNode, seguido do acesso à replica mais próxima do bloco. Um cliente típico (o job Xlap dc uma tarefa X1R) 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 podería lidar com 126 mil solicitações por segundo. ■ A carga de trabalho dc gravação: considerando uma taxa dc transferência de gravação de 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/Dcsscrialização), que define um modo dc modelar a estrutura dc registros em conjuntos dc dados no HDFS além dc 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 cm 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. z\gora, 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 TaskTracker em execução nesses nós se registram no JobTracker

835

836

Sistemas de banco de dados

na inicialização. Eles executam tarefas que o JobTracker 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 dc tarefas dc redução c criado com base na configuração do job. Atribuição dc tarefa: O escalonador do JobTracker atribui a tarefa ao TaskTracker a partir de um dos jobs em 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 escalonador 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 também 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 dc 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 dc mapeamento ou tarefa dc redução em andamento cm um TaskTracker com falha também é rcescalonada.

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 reinicia lizaçã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 dcterminí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á todas, 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 de 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 em buffer com base no número de 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 dc mapeamento, várias iterações dc particionamcnto, 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 excederiam os tempos de execução, e a taxa de transferência no cluster sofreria. Além disso, o cluster também permane­ cería 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 em 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 e 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 de 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 e S sobre o valor da coluna B. A saída dc 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 cm 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 z-é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 /-ésima partição da tabela maior leia a /-é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 dc 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 dc 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)eT(C,F) pode scr obtida cm um job MR, desde que as linhas dc 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 dc mapeamento possui memória suficiente para manter o mapeamento hash dc várias tabelas dimensionais pequenas. Como as linhas da tabela dc Fato estão sendo lidas na tarefa dc mapeamento, elas podem scr 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).1415 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 particionamcnto 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 c do sistema Hive.

Apache Pig. Pig13 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 ti 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 et 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

Serviço de Metadados

Armazenamento 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, SequenceFile); formatos colunares (por exemplo, RCFilc, 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 de 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 cm 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 consrantemente. (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 de 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 de 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 de 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. À 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 dc um cluster era estática. Isso significava que grandes partes dc 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 dc 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 de nós disponíveis. Os usuários começaram a estender a vida útil dos clusters e 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 de tarefas por job, limitação do número de jobs submetidos por usuário e 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 de 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 dc 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 dc programação MapReduce. O runtime do MR não se encaixava bem no processamento iterativo; 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 c 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 deveríam ser modelados como slots estáticos de mapeamento e redução. ■ Para ser compatível com versões anteriores, os jobs existentes deveríam scr 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 esquemático de alto nível do Hadoop vl e do Hadoop v2 lado a lado. O Gerenciador de Recursos (ResourceManager) e o nó por trabalhador NodeManager, juntos, formam a plataforma na qual qualquer aplicação pode ser hospedada no YARN. O Gerenciador dc Recursos gerencia o cluster, distribuindo recursos com base em uma política de 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 ResourceManager 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 referência. 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 Pig

Hive

Map Reduce Application Master

Tez Application Master

I

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 Node 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 AppIicationMaster é 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 AppIicationMaster e o inicia nesse contêiner. No caso do MR, o AppIicationMaster 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 ApplicationMasters 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 AppIicationMaster 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 escalonador 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 de 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 m 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 em 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 e 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 em 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) dc 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 8 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 c 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 HBase pode ser configurada individualmente. O Hoya AppIicationMaster inicia o HBase Master localmente. O Hoya AM também solicita ao RM do YARN um conjunto dc contêineres para iniciar o HBasc RegionServcrs no cluster. Os RegionServcrs do HBasc são os processos dc 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, MapR), 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 dc otimização inerentes às nuvens dc armazenamento c às de computação. Também discutimos o YARN como uma plataforma de serviços dc dados c 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 dirctamente; e (iv) técnicas dc 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 e sistemas baseados cm 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 cm 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 dc 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 semiestruturados 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 cm 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áveis com uma qualidade que, dc 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 de streaming dc vídeo para milhões dc clientes, graças a um sistema dc 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 scr tratados csscncialmcnte como sendo completamente 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 rodas 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 propuseram2425 uma estrutura de gerenciamento de dados e dc máquinas virtuais autocon figuravel, 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.2' 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 cm 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 infraestrutura 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 de nuvem é 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 cm 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 duster. Como discutimos na Seção 25.5, isso abriu a porra para muitos serviços (com seus próprios modelos de 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 dc aprendizado de máquina c assim por diante. As mesmas máquinas usadas para o cluster do Hadoop estavam sendo usadas para aplicativos toralmcnre diferentes, como o processamento

26 Veja Palantsamy 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 cluster YARN. O Apache Storm c um mecanismo de streaming cscalávcl distribuído que permite aos usuários processar feeds de 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 de máquina espera que os dados sejam alimentados cm uma estrutura uniforme. A provcniência dc dados (que se refere às informações sobre a origem e a propriedade dos dados) normalmcnte 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

ama)

w-325p230-azubirigrayarv4>. 50 Veja Jagadish et al. (2014).

está

disponível

cm

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 [Tj, TJ. 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| INCLUDES |TP T,|

Equivalente a T, 2 T.Tiv AND T, £ T.Tfv

[T.Tiv, T.Tfv] INCLUDED IN [fp TJ [T.Tiv, TTfv| OVERLAPS |TP T,|

Equivalente a Tt £ TTiv AND T, £ T.Tfv Equivalente a (T, S TTfv AND f, £ T.Tiv)22

[T.Tiv, TTfv] BEFORE [Tp TJ

Equivalente a Tj £ TTfv

[T.Tiv, TTfv] AFTER |T,,T2|

Equivalente a T, S TTiv

[T.Tiv, T.Tfv] MEETS_BEFÓRE [Tp TJ

Equivalente a T, = T.Tfv + 123

[T.Tiv, TTfv| MEETS AFTER |TP TJ

Equivalente a T, + 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 de tempo cm um elemento temporal não sejam dirctamcntc adjacentes. Ou seja, para dois períodos quaisquer |Tp TJ e [Tj, TJ em um elemento temporal, as três condições a seguir devem ser mantidas: ■ A interseção de (Tp TJ com [T3, TJ é vazia. ■ T? não é o ponto no tempo após T, na granularidade indicada. ■ Tj 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 TJ e [T3, TJ são adjacentes, eles são combinados em um único período dc tempo [Tp TJ. 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. 22 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 de 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 é aplicada à dimensão de tempo válida. Para um banco de dados bitemporal, em geral se aplicam as condições às tuplas atualmente correras com uc como seus tempos finais de transação. Contudo, se a consulta precisa ser aplicada a um estado de 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 de 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 de 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, em vez dc 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 de

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 de 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 — dc países c 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 de 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 -4 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 rodos 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 c cada cliente cm um mapa 2-D com base cm seu endereço. Efetivamente, cada cliente estará associado a uma posição de clatitude, longitudo. Um índice B -tree * tradicional, baseado nos CEPs dos clientes ou em outros atributos não espaciais, não pode ser usado para processar essa consulta, visto que os índices tradicionais não são capazes de ordenar dados dc coordenadas multidimensionais. Portanto, existe uma necessidade especial para bancos de dados ajustados para tratar de dados e consultas espaciais. A Tabela 26.1 mostra as operações analíticas comuns envolvidas no processa­ mento de dados geográficos ou espaciais.25 Operações de medição são usadas para medir algumas propriedades globais de objetos isolados (como a área, o tamanho relativo das partes dc um objeto, compactação ou simetria) e a posição relativa de diferentes objetos cm relação a distância c direção. Operações dc análise espacial, que normalmcnte usam técnicas estatísticas, são utilizadas para desvendar relacio­ namentos espaciais dentro e entre camadas de dados mapeadas. Um exemplo seria criar um mapa — conhecido como mapa de previsão — que identifica os locais de prováveis clientes para produtos cm particular com base nas informações dc vendas históricas e demográficas. Operações de análise dc fluxo ajudam a determinar o caminho mais curto entre dois pontos e também a conectividade entre nós ou regiões em um grafo. A análise de local visa a descobrir se o conjunto dado de pontos e linhas se encontra em um determinado polígono (local). O processo consiste em gerar um buffer em torno dos recursos geográficos existentes e, depois, identificar ou selecionar características tendo como base se eles estão dentro ou fora do limite do buffer. A análise digital de terreno é utilizada para montar modelos tridimen­ sionais, nos quais a topografia de um local geográfico pode ser representada com um modelo de dados x, y, z conhecido como Digital Terrain (ou Elevation) Model (DTM/DEM). As dimensões x e y de um DTM representam o plano horizontal e z representa alturas pontuais para as respectivas coordenadas x, y. Esses modelos podem ser usados para análise de dados ambientais ou durante o desenho de pro­ jetos de engenharia que exijam informações de terreno. A busca espacial permite que um usuário procure objetos em determinada região espacial. Por exemplo, a busca temática nos permite procurar objetos relacionados a determinado tema ou classe, como “Encontre todas as fontes de água localizadas até 25 quilômetros de Uberlândia", onde a classe é água. Tabela 26.1 Tipos comuns de análise para dados espaciais.

Tipo de análise

Medições

Tipo de operações e medidas Distância, perímetro, forma, adjacência e direção

Análise/estatística

Padrão, autocorrelação e índices de similaridade e topolo­

espacial

gia usando dados espaciais e não espaciais

Análise de fluxo

Conectividade e caminho mais curto

Análise de local

Análise de pontos e linhas dentro de um polígono

Análise de terreno

Inclinação/aspecto, área de captação, rede de drenagem

Pesquisa

Busca temática, busca por região

25 Lista dc operações dc análise dc GIS proposta em Albrecht (1996).

891

892

Sistemas de banco de dados

Também há relacionamentos topológicos entre objetos espaciais. Esses normal­ mente sào usados em predicados booleanos para selecionar objetos com base em seus relacionamentos espaciais. Por exemplo, se um limite de cidade for representado como um polígono e as rodovias forem representadas como mulrilinhas, uma condi­ ção como “Encontrar todas as rodovias que passam por Campinas, SP” envolvería uma operação de interseção, para determinar quais rodovias (linhas) cruzam o limite da cidade (polígono).

26.3.2 Tipos de dados e modelos espaciais Esta seção descreve resumidamente os modelos e tipos de dados comuns para armazenamento de dados espaciais. Os dados espaciais vêm em três formas básicas. Essas formas se tomaram um padrão de fato por seu uso generalizado em sistemas comerciais. ■ Dados de mapa26 incluem diversos recursos geográficos ou espadais de objetos em um mapa, como a forma de um objeto e seu local no mapa. Os três tipos básicos de recursos são pontos, linhas e polígonos (ou áreas). Pontos são usados para representar características espaciais dos objetos cujos locais correspondem a uma única coordenada 2-D (x, y ou longitudc/latitude) na escala de uma aplicação em particular. Dependendo da escala, alguns exemplos de objetos de ponto poderíam ser prédios, torres de celular ou veículos estacionários. Veículos em movimento e outros objetos em movimento podem ser representados por uma sequência de locais de ponto que mudam com o tempo. As linhas representam objetos que têm comprimento, como estradas e rios, cujas características espaciais podem ser aproximadas por uma sequência de linhas conectadas. Polígonos são usados para representar características espaciais de objetos que têm um limite, como países, estados, lagos ou cidades. Observe que alguns objetos, como prédios ou cidades, podem ser representados como pontos ou polígonos, dependendo da escala de detalhe. ■ Dados de atributo são os dados descritivos que os sistemas de GIS associam a recursos de mapa. Por exemplo, suponha que um mapa contenha recursos que representam municípios em um estado do Brasil (como São Paulo ou Minas Gerais). Os atributos para cada recurso de município (objeto) poderíam incluir população, maior cidade, área em quilômetros quadrados, e assim por diante. Outros dados de atributo poderíam ser incluídos para outros recursos no mapa, como estados, cidades, distritos, partido político dominante etc. ■ Dados de imagem incluem dados como imagens de satélite e fotografias aéreas, que são tipicamente criadas por câmeras. Objetos de interesse, como prédios e estradas, podem ser identificados e sobrepostos nessas imagens. As imagens tam­ bém podem ser atributos de recursos de mapa. Podem-se acrescentar imagens a outros recursos de mapa, de modo que o clique no recurso exibiría a imagem. Imagens aéreas e de satélite são exemplos típicos de dados de rastreio.

Modelos de informações espaciais às vezes são agrupados em duas categorias gerais: campo e objeto. Uma aplicação espacial (como sensoriamento remoto ou controle de tráfego de rodovia) é modelada usando um modelo baseado em campo ou objeto, dependendo dos requisitos e da escolha tradicional do modelo para a apli­ cação. Modelos de campo normalmente são utilizados para modelar dados espaciais que são contínuos em natureza, como elevação de terreno, dados de temperatura e características de variação de solo, enquanto modelos dc objeto tradicionalmentc 26 Esses tipos de dados geográficos são baseados no guia de ESRI para o GIS. Disponível em: .

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

têm sido usados para aplicações como redes de transporte, lotes de terra, prédios e outros objetos que possuem atributos espaciais e nào espaciais.

26.3.3 Operadores espaciais e consultas espaciais Operadores espaciais são usados para capturar todas as propriedades geométricas relevantes dos objetos embutidos no espaço físico e as relações entre elas, bem como realizar análise espacial. Os operadores são classificados em três categorias gerais. ■ Operadores topo lógicos. Propriedades topológicas são invariáveis quando trans­ formações topológicas são aplicadas. Essas propriedades não mudam após transformações como rotação, translação ou escala. Operadores topológicos são hierarquicamente estruturados em diversos níveis, e o nível básico oferece aos operadores a capacidade de verificar relações topológicas detalhadas entre regiões com um limite amplo, e os níveis mais altos oferecem operadores mais abstratos, que permitem que os usuários consultem dados espaciais incertos independentemente do modelo de dados geométricos básico. Alguns exemplos incluem aberto (região), fechado (região) e interno (ponto, loop). ■ Operadores projetivos. Operadores projetivos, como corpo convexo, são usados para expressar predicados sobre a concavidade/convexidade de objetos, bem como outras relações espaciais (por exemplo, estar dentro da concavidade de determinado objeto). ■ Operadores métricos. Operadores métricos oferecem uma descrição mais espe­ cífica da geometria do objeto. Eles são usados para medir algumas propriedades globais de objetos isolados (como a área, o tamanho relativo das partes de um objeto, a compactação e a simetria) e para medir a posição relativa de diferentes objetos em relação a distância e direção. Alguns exemplos incluem comprimento (arco) e distância (ponto, ponto).

Operadores espaciais dinâmicos. As operações realizadas pelos operadores men­ cionados são estáticas, no sentido dc que os operandos não são afetados pela apli­ cação da operação. Por exemplo, calcular o comprimento da curva não tem efeito sobre a própria curva. Operações dinâmicas alteram os objetos sobre os quais as operações atuam. As três operações dinâmicas fundamentais são criar, destruir e atualizar. Um exemplo representativo das operações dinâmicas seria atualizar um objeto espacial que pode ser subdividido em traduzir (deslocar posição), girar (mudar orientação), escalar para cima ou para baixo, refletir (produzir uma imagem de espelho) e cortar (deformar).

Consultas espaciais. As consultas espaciais são solicitações para dados espaciais que exigem o uso de operações espaciais. As categorias a seguir ilustram três tipos típicos de consultas espaciais: ■ Consulta de intervalo (range). Encontra todos os objetos de determinado tipo que estào dentro de determinada área espacial; por exemplo, encontre todos os hospitais dentro da área da cidade metropolitana de São Paulo. Uma variação dessa consulta é encontrar todos os objetos dentro de determinada distância de um local indicado; por exemplo, encontre todas as ambulâncias no raio de cinco quilômetros do local de um acidente. ■ Consulta do vizinho mais próximo. Encontra um objeto de determinado tipo que esteja mais próximo de determinado local; por exemplo, encontre o carro dc polícia que esteja mais próximo do local dc um crime. Isso pode ser generali­ zado para encontrar os k vizinhos mais próximos, como as 5 ambulâncias mais próximas do local de um acidente.

893

894

Sistemas de banco de dados

■ Junções ou sobreposições espaciais. Normalmente, a junção dos objetos de dois tipos com base em alguma condição espacial, como os objetos que se cruzam ou se sobrepõem espacialmente ou que estão dentro de certa distância um do outro. Por exemplo, encontre rodas as cidades localizadas em uma rodovia importante entre duas cidades ou encontre todas as casas que estejam a menos de três quilômetros de um lago. O primeiro exemplo junta espacialmente objetos cidade e um objeto rodovia, c o segundo exemplo junta espacialmente objetos lago e objetos casa.

26.3.4 Indexação de dados espaciais Um índice espacial é usado para organizar objetos em um conjunto de buckets (que correspondem a páginas de memória secundária), de modo que os objetos em determinada região espacial possam ser facilmente localizados. Cada bucket tem uma região, uma parte do espaço que contém todos os objetos armazenados nele. As regiões do bucket normalmcnte são retângulos; para estruturas de dados pontuais, essas regiões são disjuntas e dividem o espaço de modo que cada ponto pertença a exatamente um bucket. Existem basicamente duas maneiras de oferecer um índice espacial: 1. Estruturas de indexação especializadas, que permitem a busca eficiente por obje­ tos de dados com base nas operações de busca espacial, são incluídas no sistema de banco de dados. Essas estruturas de indexação desempenhariam um papel semelhante ao realizado pelos índices da * -tree nos sistemas de banco de dados B tradicionais. Alguns exemplos dessas estruturas de indexação são arquivos de grade e R-trees. Tipos especiais de índices espaciais, conhecidos como índices de junção espacial, podem ser usados para agilizar operações de junção espacial.

2. Em vez de criar estruturas de indexação totalmcnte novas, os dados espaciais bidimensionais (2-D) são convertidos em dados unidimensionais (1-D), para que possam ser usadas técnicas de indexação tradicionais * -tree). (B Os algoritmos para converter 2-D para 1-D são conhecidos como curvas de preenchimento de espaço. Não discutiremos esses métodos com detalhes (veja outras referências na bibliografia selecionada ao final deste capítulo). A seguir, oferecemos uma visão geral de algumas das técnicas de indexação espacial. Arquivos de grade. Apresentamos os arquivos de grade para indexação dc dados em múltiplos atributos no Capítulo 17. Eles também podem ser usados para indexa­ ção de dados espaciais bidimensionais e de dimensão n mais alta. O método de grade fixa divide um hiperespaço «-dimensional em buckets de mesmo tamanho. A estrutura de dados que implementa a grade fixa é um vetor «-dimensional. Os objetos cujos locais espaciais se encontram em uma célula (total ou parcialmente) podem ser armazenados em uma estrutura dinâmica para lidar com overflows. Essa estrutura é útil para dados uniformemente distribuídos, como imagens de satélite. Porém, a estrutura de grade fixa é rígida, e seu diretório pode ser esparso e grande.

R-trees. A R-tree é uma árvore com altura balanceada, que é uma extensão da B‘-tree para k dimensões, em que k > 1. Para duas dimensões (2-D), os objetos espaciais são aproximados na R-trcc por seu retângulo delimitador mínimo (MBR — minimum bounding rectangle), que é o menor retângulo, com lados paralelos ao eixo do sistema de coordenadas (x e y), que contém o objeto. As R-trees são caracterizadas pelas propriedades a seguir, que são semelhantes às propriedades das B'-trees (ver Seção 17.3), mas são adaptadas para objetos espaciais 2-D. Como na Seção 17.3, usamos M para indicar o número máximo de entradas que podem caber cm um nó da R-tree.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

1. A estrutura de cada entrada de índice (ou registro de índice) em um nó folha é (I, identificador-objeto), em que I é o MBR para o objeto espacial cujo identificador é identificador-objeto. 2. Cada nó, exceto o nó raiz, deve estar cheio pelo menos até a metade. Assim, um nó folha que não é a raiz deve conter w entradas (I, identificador-objeto), em que AÍ/2 < m < Al. De modo semelhante, um nó não folha que não é a raiz deve conter m entradas (I, ponteiro-filho), em que Af/2 < m < Aí, e I é o MBR que contém a união de todos os retângulos no nó apontado pelo ponteiro-filho. 3. Todos os nós folha estão no mesmo nível, e o nó raiz deve ter pelo menos dois ponteiros, a menos que seja um nó folha.

4. Todos os MBRs têm seus lados paralelos aos eixos do sistema de coordenada global. Outras estruturas de armazenamento espaciais incluem quadtrees e suas variações. Quadtrees costumam dividir cada espaço ou subespaço em áreas de mesmo tamanho, e prosseguem com as subdivisões dc cada subespaço para identificar as posições de vários objetos. Recentemente, muitas estruturas de acesso espaciais mais novas têm sido propostas, e essa continua sendo uma área de pesquisa ativa. índice de junção espacial. Um índice de junção espacial pré-calcula uma opera­ ção de junção espacial e armazena os ponteiros para o objeto relacionado em uma estrutura de índice. Os índices de junção melhoram o desempenho das consultas de junção recorrentes em tabelas que possuem baixas taxas de atualização. As condições dc junção espaciais são usadas para responder a desafios como “Crie uma lista dc combinações de rodovia c estrada que se cruzam”. A junção espacial é usada para identificar e recuperar esses pares de objetos que satisfazem o relacionamento espacial cruzado. Como o cálculo dos resultados dos relacionamentos espaciais geralmente é demorado, o resultado pode ser calculado uma vez c armazenado em uma tabela que tem os pares dc identificadores de objetos (ou ids dc tupla) que satisfazem o relacionamento espacial, o qual basicamente é o índice de junção. Um índice de junção pode ser descrito por um grafo bipartite G = (V,, V2, E), em que V] contém as ids de tupla da relação R, e V2 contém as ids de tupla da relação 5. O conjunto de arestas contém uma aresta vj para vT em R e vs em S, se existir uma tupla correspondente a (t/^ ps) no índice de junção. O grafo bipartite modela todas as tuplas relacionadas como vértices conectados nos gráficos. Os índices de junção espacial são usados nas operações (ver Seção 26.3.3) que envolvem o cálculo de relacionamentos entre objetos espaciais.

26.3.5 Mineração de dados espaciais Dados espaciais tendem a ser altamente correlacionados. Por exemplo, as pes­ soas com características, ocupações e bases semelhantes tendem a se agrupar nas mesmas vizinhanças. As três técnicas principais de mineração de dados espaciais são classificação espacial, associação espacial e agrupamento espacial. ■ Classificação espacial. O objetivo da classificação é estimar o valor de um atributo de uma relação com base no valor dos outros atributos da relação. Um exemplo do problema de classificação espacial é determinar os locais dos ninhos em um pântano com base no valor de outros atributos (por exemplo, durabilidade da vegetação e profundidade da água); isso também é chamado de problema da previsão de local. De modo semelhante, onde esperar os principais pontos de atividade criminosa também é um problema dc previsão dc local. ■ Associação espacial. As regras de associação espacial são definidas em termos de predicados espaciais, em vez de itens. Uma regra de associação espacial tem a forma

P/P2A...APfl=>Q1AQ2 A

A Q„,

895

896

Sistemas de banco de dados

em que pelo menos um dos P; ou Q; é um predicado espacial. Por exemplo, a regra is_a(x, país) A touchcs(x, Mediterrâneo) => is_a (x, exportador-vinho)

(ou seja, um país que é adjacente ao Nlar Mediterrâneo normalmente é um exportador de vinho) é um exemplo de uma regra de associação, que terá certo suporte s e confiança c.27 Regras dc colocação espacial tentam generalizar as regras de associação para que apontem para conjuntos de dados de coleta que são indexados por espaço. Existem várias diferenças cruciais entre associações espaciais e não espaciais, incluindo: 1. A noção de uma transação é ausente em situações espaciais, pois os dados são embutidos no espaço contínuo. O particionamento do espaço em transações levaria a uma superestimativa ou a uma subestimariva de medidas de interesse, por exemplo, suporte ou confiança.

2. O tamanho dos conjuntos de itens nos bancos de dados espaciais é pequeno, ou seja, existem muito menos itens no conjunto de itens em uma situação espacial que em uma situação não espacial. Na maioria dos casos, os itens espaciais são uma versão discreta das variáveis contínuas. Por exemplo, no Brasil, as regiões de receita podem ser definidas como regiões onde a receita anual média está dentro de certos intervalos, como abaixo de R$ 10.000, de R$ 10.000 a R$ 25.000, e acima de RS 25.000.

■ O agrupamento (clustering) espadai tenta agrupar objetos do banco de dados de modo que os objetos mais semelhantesestejam no mesmo cluster e objetos cm clusters diferen­ tes sejam os mais divergentes possíveis. Uma aplicação do agrupamento espadai é agru­ par eventos sísmicos a fim de determinar falhas de terremoto. Um exemplo de algoritmo de agrupamento espadai é o agrupamento baseado cm densidade, que tenta encontrar clusters com base na densidade dos pontos de dados cm uma região. Esses algoritmos tratam dos clusters como regiões densas de objetos no espaço de dados. Duas variações desses algoritmos são o agrupamento espadai baseado em densidade das aplicações com ruído (DBSCAN)28 e o agrupamento baseado em densidade (DENCLUE).29 O DBSCAN é um algoritmo de agrupamento baseado em densidade porque encontra uma série de clusters que começam a partir da distribuição de densidade estimada dos nós correspondentes.

26.3.6 Aplicações de dados espaciais O gerenciamento de dados espaciais é útil em muitas disciplinas, incluindo geogra­ fia, sensores remotos, planejamento urbano e gerenciamento de recursos naturais. O gerenciamento de banco de dados espacial está desempenhando um papel importante na solução dc problemas científicos desafiadores, como mudanças globais no clima e no genoma. Em decorrência da natureza espacial dos dados dc genoma, o G1S c sistemas de gerenciamento de banco de dados espacial têm um papel importante a desempenhar na área de bioinformática. Algumas das aplicações típicas incluem reconhecimento de padrão (por exemplo, para verificar se a topologia dc determinado gene no genoma é encontrada cm qualquer outro mapa dc característica de sequência no banco de dados), desenvolvimento de navegador de genoma e mapas de visualização. Outra área de aplicação importante da mineração de dados espaciais é a detecção de outlier (caso

27 Os conceitos de suporte e confiança para regras de associação serão discutidos como parte da mine­

ração de dados na Seção 28.2. 28 O DBSCAN foi proposto por Martin Ester, Hans-Peter Kriegel, Jõrg Sander e Xiaowei Xu (1996). 29 O DENCLUE foi proposto por Hinncnbcrg e Gabriel (2007).

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

isolado) espacial. Um caso isolado (outlier) espacial é um objeto referenciado espacial­ mente cujos valores de atributo não espaciais sào significativamente diferentes dos de outros objetos referenciados espacialmente em sua vizinhança espacial. Por exemplo, se uma vizinhança de casas mais antigas tiver apenas uma casa nova, essa casa seria um caso isolado (outlier), com base no atributo nào espacial “casa_antiga”. A detecção de outliers espaciais é útil em muitas aplicações de sistemas de informações geográficas e bancos de dados espaciais. Esses domínios dc aplicação incluem transporte, ecologia, segurança pública, saúde pública, climatologia e serviços baseados em local.

26.4 Conceitos de banco de dados multimídia Os bancos dc dados multimídia oferecem recursos que permitem que os usuários armazenem e consultem diferentes tipos de informações de multimídia, que incluem imagens (como fotos ou desenhos), clipes de vídeo (como filmes, noticiários ou vídeos caseiros), clipes de áudio (como canções, mensagens telefônicas ou discursos) e docu­ mentos (como livros ou artigos). Os principais tipos de consultas de banco de dados necessários envolvem localização de fontes de multimídia que contêm certos objetos de interesse. Por exemplo, alguém pode querer localizar todos os clipes dc vídeo cm um banco de dados de video que incluam certa pessoa, digamos, Michael Jackson. Também se pode querer recuperar clipes de vídeo com base em certas atividades incluídas neles, como clipes de vídeo nos quais um gol no futebol é marcado por certo jogador ou time. Esses tipos de consultas são conhecidos como recuperação baseada em conteúdo, pois a fonte de multimídia está sendo recuperada se contiver certos objetos ou ativida­ des. Logo, um banco de dados multimídia precisa usar algum modelo para organizar e indexar as fontes de multimídia com base em seus conteúdos. A identificação do conteúdo das fontes de multimídia é uma tarefa difícil e demorada. Existem duas téc­ nicas principais. A primeira se baseia na análise automática das fontes de multimídia para identificar certas características matemáticas de seu conteúdo. Essa abordagem usa diferentes técnicas, dependendo do tipo de fonte de multimídia (imagem, vídeo, áudio ou texto). A segunda abordagem depende da identificação manual dos objetos e atividades de interesse em cada fonte de multimídia e do uso dessa informação para indexar as fontes. Essa técnica pode ser aplicada a todas as fontes de multimídia, mas requer uma fase de pré-processamento manual, em que uma pessoa precisa analisar cada fonte de multimídia para identificar e catalogar os objetos e atividades que ela contém, de modo que possam ser usados para indexar as fontes. Na primeira parte desta seção, discutiremos rapidamente algumas das carac­ terísticas dc cada tipo dc fonte dc multimídia — imagens, vídeo, áudio c texto/ documentos. Depois, abordaremos técnicas para a análise automática de imagens, seguidas pelo problema de reconhecimento de objeto nelas. Terminamos esta seção com alguns comentários sobre a análise de fontes de áudio. Uma imagem costuma ser armazenada em forma bruta, como um conjunto de valores de pixel ou célula, ou em forma compactada, para economizar espaço. O descritor de forma da imagem descreve a forma geométrica da imagem bruta, que normalmente é um retângulo de células de certa largura e altura. Logo, cada imagem pode ser representada por uma grade de células de m por n. Cada célula contém um valor dc pixel que descreve seu conteúdo. Nas imagens em preto c branco, os pixels podem ter um bit. Em imagens com escala de cinza ou coloridas, um pixel tem múltiplos bits. Como as imagens podem exigir grande quantidade de espaço, elas normalmente são armazenadas em forma compactada. Os padrões de compactação, como GIF, JPEG ou MPEG, utilizam diversas transformações matemáticas para reduzir o número de células armazenadas, mas ainda mantêm as principais caracte­ rísticas da imagem. Transformações matemáticas aplicáveis incluem discrete Fourier transform (DFT), discrete cosine transform (DCT) e transformações de wavelet.

897

898

Sistemas de banco de dados

Para identificar objetos de interesse em uma imagem, esta normalmente é divi­ dida em segmentos homogêneos que usam um predicado de homogeneidade. Por exemplo, em uma imagem colorida, células adjacentes que possuem valores de pixel semelhantes são agrupadas em um segmento. O predicado de homogeneidade define condições para agrupar essas células automaticamente. A segmentação e a compactação podem, então, identificar as principais características de uma imagem. Uma consulta típica a um banco dc dados dc imagem seria encontrar imagens no banco dc dados que são similares a determinada imagem. A imagem dada poderia scr um segmento isolado que contém, digamos, um padrão de interesse, e a consulta deve localizar outras imagens que contenham esse mesmo padrão. Existem duas técnicas principais para esse ripo de consulta. A primeira utiliza uma função de distância para comparar a imagem dada com as imagens armazenadas e seus segmentos. Sc o valor de distância retornado for pequeno, a probabilidade de uma combinação é alta. Podem ser criados índices para agrupar imagens armazenadas que são próximas na métrica da distância para limitar o espaço de pesquisa. A segunda, chamada de técnica da transformação, mede a semelhança da imagem tendo um pequeno número dc transformações que podem mudar as células de uma imagem para combinar com a outra imagem. As transformações incluem rotações, translaçõcs c escala. Embora a abordagem da transformação seja mais geral, ela também é mais demorada e difícil. Uma fonte de vídeo em geral é representada como uma sequência de quadros, na qual cada quadro ainda é uma imagem. Porém, em vez de identificar os objetos e as atividades cm cada quadro individual, o vídeo é dividido em segmentos dc vídeo, cm que cada segmento compreende uma sequência dc quadros contíguos que inclui os mesmos objetos/atividades. Cada segmento é identificado por seus quadros inicial e final. Os objetos e atividades identificados em cada segmento de vídeo podem ser usados para indexar os segmentos. Uma técnica de indexação chamada árvores de segmento de quadro foi proposta para a indexação do vídeo. O índice inclui tanto objetos, como pessoas, casas e carros, quanto atividades, como uma pessoa reali­ zando uma fala ou duas pessoas conversando. Os vídeos também costumam scr compactados usando padrões como MPEG. Fontes de áudio incluem mensagens gravadas armazenadas, como discursos, apresentações em sala dc aula ou mesmo gravações de vigilância de mensagens ou conversas telefônicas por imposição da lei. Aqui, transformações discretas podem scr usadas para identificar as principais características da voz de uma pessoa a fim de ter indexação e recuperação baseada em semelhança. Comentaremos rapidamente sobre sua análise na Seção 26.4.4. Uma fonte de texto/documento é basicamente o texto completo de algum artigo, livro ou revista. Essas fontes normalmente são indexadas ao identificar as palavras-chave que aparecem no texto e suas frequências relativas. Contudo, palavras de preenchimento ou palavras comuns, chamadas stopwords, são eliminadas do processo. Como pode haver muitas palavras-chave ao tentar indexar uma coleção de documen­ tos, foram desenvolvidas técnicas para reduzir o número de palavras-chave às que são mais relevantes para a coleção. Uma técnica de redução de dimensionalidade, chamada decomposição de valor singular (SVD), baseada cm transformações dc matriz, pode scr utilizada para essa finalidade. Uma técnica dc indexação, chamada árvores de vetor telescópico (árvores TV), pode então ser usada para agrupar documentos semelhantes. O Capítulo 27 discutirá o processamento de documentos em detalhes.

26.4.1 Análise automática de imagens A análise dc fontes dc multimídia é crítica para o suporte dc qualquer tipo dc con­ sulta ou interface dc pesquisa. Precisamos representar dados de fonte de multimídia.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

como imagens, em relação aos recursos que nos permitiríam definir similaridade. O trabalho feito até aqui nessa área usa recursos visuais de baixo nível, como cor, textura e forma, que estão diretamente relacionados aos aspectos perceptivos do conteúdo da imagem. Esses recursos são fáceis de extrair e representar, e é conve­ niente projetar medidas de similaridade com base em suas propriedades estatísticas. A cor é um dos recursos visuais mais usados na recuperação de imagens com base em conteúdo, pois não depende do tamanho ou da orientação da imagem. A recupera­ ção com base em semelhança de cor é feita principalmcntc ao calcular um histograma de cor para cada imagem, que identifica a proporção de pixels dentro de uma imagem para os três canais de cor (vermelho, verde, azul — RGB, red, green, blue). Porém, a representação RGB é afetada pela orientação do objeto com relação à iluminação e direção da câmera. Portanto, as técnicas atuais de recuperação de imagens calculam histogramas de cores que usam representações invariáveis concorrentes, como HSV (matiz, saturação, valor — hue, saturation, value). O HSV descreve cores como pontos em um cilindro cujo eixo central varia de preto, no fundo, até branco, no topo, com cores neutras entre os dois extremos. O ângulo em tomo do eixo corresponde ao matiz; a distância do eixo, à saturação; e a distância ao longo do eixo, ao valor (brilho). A textura refere-se aos padrões em uma imagem que apresentam as propriedades de homogeneidade que não resultam da presença de um único valor de cor ou de intensidade. Alguns exemplos de classes de textura são a bruta e a lustrosa. Alguns exemplos de texturas que podem ser identificadas incluem couro de bezerro pren­ sado, esteira de palha, tela de algodão, e assim por diante. Assim como as figuras são representadas por vetores dc pixels (elementos dc imagem), as texturas são represen­ tadas por vetores de texels (elementos de textura). Essas texturas são então colocadas em uma série de conjuntos, dependendo de quantas texturas são identificadas na imagem. Tais conjuntos não apenas contêm a definição de textura, mas também indicam onde a textura está localizada na imagem. A identificação de textura é feita principalmente ao modelá-la como uma variação bidimensional, de nível dc cinza. O brilho relativo dos pares dc pixels é calculado para estimar o grau de contraste, regularidade, rispidez e direcionalidade. A forma refere-se ao formato de uma região em uma imagem. Ela geralmente é determinada ao aplicar segmentação ou detecção de borda a uma imagem. A seg­ mentação é uma técnica baseada cm região que usa uma região inteira (conjuntos de pixels), enquanto a detecção dc borda c uma técnica baseada em limites, que utiliza apenas as características de contorno externo das entidades. A representação da forma em geral precisa ser invariável a translação, rotação e escala. Alguns métodos bem conhecidos para a representação de forma incluem descritores de Fourier e invariáveis de movimento.

26.4.2 Reconhecimento de objeto em imagens O reconhecimento de objeto é a tarefa de identificar objetos do mundo real em uma imagem ou sequência de vídeo. O sistema precisa ser capaz de identificar o objeto mesmo quando suas imagens variam em pontos de vista, tamanho, escala ou mesmo quando elas são giradas ou passam por translação. Algumas técnicas foram desenvolvidas para dividir a imagem original em regiões com base na semelhança dos pixels contíguos. Assim, cm determinada imagem que mostra um tigre na selva, uma subimagem do tigre pode ser detectada contra o fundo da selva e, quando comparada com um conjunto de imagens em treinamento, ela pode ser marcada como um tigre. A representação do objeto de multimídia cm um modelo de objeto é extremamente importante. Uma técnica consiste cm dividir a imagem em segmentos homogêneos usando um predicado homogêneo. Por exemplo, em uma imagem colorida, células

899

900

Sistemas de banco de dados

adjacentes que possuem valores de pixel semelhantes sào agrupadas em um segmento. O predicado de homogeneidade define condições para agrupar automaticamente essas células. A segmentação e a compactação, portanto, podem identificar as prin­ cipais características de uma imagem. Outra técnica encontra medições do objeto que são invariáveis às transformações. E impossível manter um banco de dados de exemplos de todas as diferentes transformações de uma imagem. Para lidar com isso, as técnicas de reconhecimento de objeto encontram pontos (ou características) interessantes em uma imagem, que não variam com as transformações. Uma contribuição importante para esse campo foi feita por Lowe,30 que usou características invariáveis na escala com base nas imagens para realizar um reconheci­ mento de objeto confiável. Essa técnica é chamada de transformação de característica invariável cm escala (scale-invariant feature transform — SIFT). As características SIFT são invariáveis ao redimensionamento e na rotação da imagem, e parcialmente invariáveis à mudança na iluminação e no ponto de vista da câmera 3-D. Eles são bem localizados nos domínios espacial e de frequência, reduzindo a probabilidade de interrupção por oclusão, aglomeração ou ruído. Além disso, as características são altamente distintivas, o que permite que uma única característica seja corretamente combinada com alta probabilidade contra um grande banco dc dados dc caracte­ rísticas, oferecendo uma base para o reconhecimento de objeto e cena. Para combinação c reconhecimento dc imagem, as características do SIFT (tam­ bém conhecidas como características de ponto-chave) primeiro são extraídas de um conjunto de imagens de referência e armazenadas em um banco de dados. O reconhecimento de objeto é então realizado ao comparar cada característica da nova imagem com aquelas armazenadas no banco de dados e ao encontrar prováveis características correspondentes com base na distância euclidiana de seus vetores de característica. Como as características de ponto-chave são altamente distintas, uma única característica pode ser combinada corretamente com boa probabilidade em um grande banco de dados de características. Além do SIFT, existem diversos métodos concorrentes disponíveis para reconhe­ cimento de objeto sob aglomeração ou oclusão parcial. Por exemplo, o RIFT, uma generalização invariável à rotação do SIFT, identifica grupos de regiões afins locais (características de imagem com uma aparência característica e forma elíptica) que permanecem aproximadamente afins por uma gama de visões de um objeto, e por múltiplas instâncias da mesma classe de objeto.

26.4.3 Marcação semântica de imagens A noção de marcação implícita é importante para reconhecimento e comparação de imagem. Múltiplas tags podem se conectar a uma imagem ou uma subimagem: por exemplo, no caso que referenciamos anteriormente, tags como “tigre", “selva", “verde" e “listras” podem ser associadas a essa imagem. A maioria das técnicas de pesquisa de imagem recupera imagens com base em tags fornecidas pelo usuário, que normalmente não são muito precisas ou abrangentes. Para melhorar a qualidade da pesquisa, diver­ sos sistemas recentes visam à geração automatizada dessas tags de imagem. Xo caso de dados de multimídia, a maioria de sua semântica está presente em seu conteúdo. Esses sistemas utilizam técnicas de processamento de imagem e modelagem estatística para analisar o conteúdo da imagem e gerar tags de anotação precisas, que podem então ser usadas para recuperar imagens por conteúdo. Como diferentes esquemas de anotação empregarão vocabulários distintos para anotar imagens, a qualidade da recuperação da imagem será fraca. Para resolver esse problema, técnicas de pesquisa recentes propuseram o uso de hierarquias de conceito, taxonomias ou ontologias usando OWL (Web Ontology Language), em que termos e seus relacionamentos são

Ver Lowe (20041, “Distinctive image features from scale-invariant keypoints”.

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

claramente definidos. Estes podem ser usados para deduzir conceitos de nível mais alto com base nas tags. Conceitos como “céu" e “grama" podem ser divididos ainda em “céu claro" e “céu nublado" ou “grama seca" e “grama verde" nessa taxonomia. Essas técnicas costumam vir sob a marcação semântica e podem scr usadas em conjunto com as estratégias citadas de análise de recursos e identificação de objetos.

26.4.4 Análise de fontes de dados de áudio As fontes dc áudio em geral são classificadas em dados de voz, música e outros dados dc áudio. Cada uma delas é significativamente diferente da outra; portanto, diversos tipos de dados de áudio sào tratados de formas diferentes. Os dados de áudio precisam scr digitalizados antes que possam scr processados c armazenados. A indexação e recuperação de dados de áudio é comprovadamente a mais difícil entre todos os ripos de mídia, pois, assim como o vídeo, ela é contínua no tempo e não tem características facilmente mensuráveis, como texto. A clareza das gravações de som é fácil de perceber humanamente, mas difícil de ser quantificada para aprendizado da máquina. E interessante que os dados de voz com frequência usam técnicas de reconhecimento de voz para auxiliar o conteúdo de áudio real, e isso pode tornar a indexação desses dados muito mais facil c precisa. Isso às vezes é chamado dc indexação de dados de áudio baseada em texto. Os metadados de voz costumam depender do conteúdo, na medida cm que eles são gerados a partir do conteúdo dc áudio, como o comprimento da fala, o número de pessoas falando, e assim por diante. Porém, alguns dos metadados poderíam ser independentes do conteúdo real, como o comprimento da fala c o formato em que os dados são armazenados. A indexação da música, por sua vez, é feira com base na análise estatística do sinal de áudio, também conhecida como indexação baseada em conteúdo. Tal tipo de indexação normalmente utiliza os principais recursos do som: intensidade, tom, timbre e ritmo. É possível comparar diferentes trechos de dados de áudio e recuperar informações deles com base no cálculo de certas características, bem como a aplicação de certas transformações.

26.5 Introdução aos bancos de dados dedutivos 26.5.1 Visão geral dos bancos de dados dedutivos Em um sistema dc banco de dados dedutivo, é comum especificarmos regras por meio de uma linguagem dedarativa — uma linguagem em que especificamos o que conseguir em vez de como consegui-lo. Um mecanismo de inferência (ou mecanismo dc dedução) dentro do sistema pode deduzir novos fatos a partir do banco dc dados ao interpretar essas regras. O modelo usado para bancos de dados dedutivos está bastante relacionado ao modelo de dados relacionai, e particularmente ao forma­ lismo do cálculo relacionai do domínio (ver Seção 8.6). Ele também está relacionado ao campo da programação lógica e à linguagem Prolog. O trabalho com banco de dados dedutivo baseado na lógica tem usado Prolog como ponto de partida. Uma variação da Prolog, chamada Datalog. é utilizada para definir regras em forma dc declaração, com um conjunto de relações existentes, que por si sós são tratadas como literais na linguagem. Embora a estrutura da linguagem da Datalog seja semelhante à da Prolog, sua semântica operacional — ou seja, como um programa em Datalog é executado — ainda é diferente. Um banco dc dados dedutivo usa dois tipos principais dc especificações: fatos e regras. Fatos são especificados de uma maneira semelhante ao modo como as relações são especificadas, exceto que não é necessário incluir nomes de atributo. Lembre-se de que uma tupla em uma relação descreve algum fato do mundo real, cujo significado é parcialmente determinado pelos nomes de atributo. Em um banco de

901

902

Sistemas de banco de dados

dados dedutivo, o significado de um valor de atributo em uma tupla é determinado unicamente por sua posição na tupla. Regras sâo semelhantes a visões relacionais. Elas especificam relações virtuais que não estão realmente armazenadas, mas podem ser formadas com base nos fatos, ao aplicar mecanismos de inferência baseados nas especificações da regra. A principal diferença entre regras e visões é que as regras podem envolver recursão e, portanto, gerar relações virtuais que não podem ser definidas em relação a visões relacionais básicas. A avaliação de programas Prolog se baseia em uma técnica chamada backward chaining, que envolve uma avaliação top-down (de cima para baixo) dos objetivos. Em bancos de dados dedutivos que usam Datalog, a atenção deve ser dedicada ao tratamento de grande volume de dados armazenados em um banco de dados rela­ cionai. Logo, técnicas de avaliação foram criadas, semelhantes àquelas para uma avaliação bottom-up (de baixo para cima). O Prolog sofre da limitação de que a ordem da especificação dos fatos e regras é significativa na avaliação; além disso, a ordem de literais (definidas na Seção 26.5.3) em uma regra é significativa. As técnicas de execução para programas Datalog tentam contornar esses problemas.

26.5.2 Notação Prolog/Datalog A notação usada em Prolog/Datalog é baseada em fornecimento dc predicados com nomes únicos. Um predicado tem um significado implícito, que é sugerido pelo nome do predicado, e um número fixo de argumentos. Se os argumentos forem todos valores constantes, o predicado simplesmente indica que certo fato é verdadeiro. Se, caso contrário, o predicado tiver variáveis como argumentos, ele é considerado uma consulta ou parte dc uma regra ou restrição. Em nossa discussão, adotamos a convenção Prolog de que todos os valores constantes em um predicado são strings numéricas ou de caractere-, eles são representados como identificadores (ou nomes) que começam com uma letra minúscula, ao passo que nomes dc variáveis sempre começam com uma letra maiuscula. Considere o exemplo mostrado na Figura 26.11, que é baseado no banco de dados relacionai da Figura 5.6, mas cm uma forma bastante simplificada. Existem três nomes de predicado: supervisiona, superior e subordinado. O predicado SUPERVISIONA é definido por meio de um conjunto de fatos, cada um com dois argumentos: um nome dc supervisor, seguido pelo nome dc um supervisionado direto (subordinado) desse supervisor. Esses fatos correspondem aos dados reais armazenados no banco dc dados, e podem scr considerados constituintes dc um conjunto dc tuplas em uma relação SUPERVISIONA com dois atributos, cujo esquema é SUPERVISIONA(Supervisor, Supervisionado)

Figura 26.11 (a) Notação Prolog.

(b) A árvore de supervisão.

(a) Fatos SUPERVISIONA (fernando, joao). SUPERVISIONA (fernando, ronaldo) SUPERVISIONA (fernando, joke). SUPERVISIONA (Jennifer, alice). SUPERVISIONA (Jennifer, andre). SUPERVISIONA (jorge, fernando). SUPERVISIONA (jorge, Jennifer).

Regras SUPERIORR Y)SUPERVISIONAR Y). SUPERIORR Y)SUPERVISIONAR 2), SUPERIORS, Y). SUBORDINADOR Y)SUPERIORR X).

Consultas SUPERIOR(jorge, Y)? SUPERIORíjorge, joice)?

joao

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

Assim, SUPERV1SIONA(X, Y) declara o fato de que X supervisiona Y. Observe a omissão dos nomes de atributo na notação Prolog. Os nomes de atributo só são representados em virtude da posição de cada argumento em um predicado: o pri­ meiro argumento representa o supervisor, e o segundo argumento representa um subordinado direto. Os outros dois nomes de predicado são definidos por regras. As principais contri­ buições dos bancos de dados dedutivos são a capacidade de especificar regras recursivas e oferecer uma estrutura ou framework para deduzir novas informações com base nas regras específicas. Uma regra tem a forma cabeça corpo, em que é lido como se e somente se. Uma regra normal mente tem um único predicado à esquerda do símbolo :----- chamado de cabeça ou left-hand side (LHS) ou conclusão da regra — e um ou mais predicados à direita do símbolo :------chamado de corpo ou right-hand side (RHS) ou premissa(s) da regra. Um predicado com constantes como argumentos é considerado base; também nos referimos a ele como um predicado instanciado. Os argumentos dos predicados que aparecem em uma regra costumam incluir uma série de símbolos variáveis, embora os predicados também possam conter constantes como argumentos. Uma regra especifica que, se determinada atribuição ou vínculo dos valores constantes às variáveis no corpo (predicados RHS) tomar todos os predicados RHS verdadeiros, cia também toma a cabeça (predicado LHS) verdadeira ao usar a mesma atribuição de valores constantes às variáveis. Logo, uma regra nos oferece um modo de gerar novos fatos que são instanciações da cabeça da regra. Esses novos fatos sâo baseados cm fatos que já existem, correspondentes às instanciações (ou vínculos) dc predicados no corpo da regra. Observe que, ao listar vários predicados no corpo de uma regra, aplicamos implicitamente o operador lógico AND a esses predicados. Assim, as vírgulas entre os predicados RHS podem ser lidas como significando and. Considere a definição do predicado SUPERIOR da Figura 26.11, cujo primeiro argumento é um nome de funcionário e cujo segundo argumento é um funcionário subordinado direto ou indireto do primeiro funcionário. Com subordinado indireto, queremos dizer o subordinado dc algum subordinado abaixo até qualquer número de níveis. Assim, SUPERIOR(X, Y) indica o fato de que X é um superior de Y por meio de supervisão direta ou indireta. Podemos escrever duas regras que, juntas, especificam o significado do novo predicado. A primeira regra sob Regras na figura indica que, para cada valor de X e Y, se SUPERVISIONA(X,Y) — o corpo da regra — for verda­ deiro, então SUPERIOR(X,Y) — a cabeça da regra — também é verdadeiro, pois Y seria um subordinado direto de X (um nível abaixo). Essa regra pode ser usada para gerar todos os relacionamentos diretos de superior/subordinado com base nos fatos que definem o predicado SUPERVISIONA. A segunda regra recursiva indica que, se SUPERVISIONA(X,Z) e SUPERIOR(Z, Y) são ambos verdadeiros, então SUPERIORLY) também é verdadeiro. Esse é um exemplo de uma regra recursiva, em que um dos predicados do corpo da regra no RHS é o mesmo que o predicado de cabeça da regra no LHS. Em geral, o corpo da regra define uma série de premissas, de modo que, se rodas elas são verdadeiras, podemos deduzir que a conclusão na cabeça da regra também é verdadeira. Observe que, se tivermos duas (ou mais) regras com a mesma cabeça (predicado LHS), isso é equivalente a dizer que o predicado é ver­ dadeiro (ou seja, que pode ser instanciado) se um dos corpos for verdadeiro; logo, isso é equivalente a uma operação lógica OR. Por exemplo, se tivermos duas regras X Y e X Z, elas são equivalentes a uma regra X Y OR Z. Porém, a última forma não é usada nos sistemas dedutivos, pois não está na forma padrão da regra, chamada cláusula de Horn, como discutiremos na Seção 26.5.4. Um sistema Prolog contém uma série de predicados embutidos que o sistema pode interpretar diretamente. Eles costumam incluir o operador de comparação de igualdade = (X, Y), que retorna verdadeiro se X e Y forem idênticos e também pode

903

904

Sistemas de banco de dados

ser escrito como X = ¥ ao utilizar a notação de infixo padrão.31 Outros operadores de comparação para números, como =, podem ser tratados como pre­ dicados binários. ;\s funções aritméticas como * e / podem ser usadas como argumentos em predicados Prolog. Por sua vez, Datalog (em sua forma básica) não permite, como argumentos, funções do tipo das operações aritméticas; na realidade, essa é uma das principais diferenças entre Prolog e Datalog. Contudo, foram pro­ postas extensões à Datalog, que incluem funções. Uma consulta normalmente envolve um símbolo de predicado com alguns argumentos variáveis, e seu significado (ou resposta) é deduzir todas as diferentes combinações de constantes que, quando vinculadas (atribuídas) às variáveis, podem tornar o predicado verdadeiro. Por exemplo, a primeira consulta na Figura 26.11 solicita os nomes de todos os subordinados de jorge em qualquer nível. Um tipo diferente de consulta, que tem apenas símbolos constantes como argumentos, retoma um resultado verdadeiro ou falso, dependendo de os argumentos fornecidos poderem ser deduzidos dos fatos e regras. Por exemplo, a segunda consulta na Figura 26.11 retorna verdadeiro, pois SUPERIOR(jorge, joice) pode ser deduzido.

26.5.3 Notação Datalog Em Datalog, como em outras linguagens baseadas na lógica, um programa é criado a partir de objetos básicos, chamados fórmulas atômicas. É comum definir a sintaxe de linguagens baseadas em lógica ao descrever a sintaxe de fórmulas atômicas e identificar como elas podem ser combinadas para formar um programa. Em Datalog, as fórmulas atômicas são literais na forma p(at, a2,... an), em que p é o nome do predicado e n é o número de argumentos para o predicado p. Diferentes símbolos de predicado podem ter distintos números de argumentos, e o número de argumentos n do predicado p às vezes é chamado de aridez ou grau de p. Os argumentos podem ser valores constantes ou nomes variáveis. Como já dissemos, usamos a convenção de que valores constantes ou são numé­ ricos ou começam com um caractere minúsculo, ao passo que nomes de variável sempre começam com um caractere maiusculo. Uma série de predicados embutidos está incluída em Datalog, que também pode ser usada para construir fórmulas atômicas. Os predicados embutidos são de dois tipos principais: os predicados de comparação binária < (less), (greater) e >= (greater_or_equal) em domínios ordenados; e os predicados de comparação = (equal) e /= (not_equal) em domínios ordenados ou não ordenados. Estes podem ser utilizados como predicados binários com a mesma sintaxe funcional dc outros predicados — por exemplo, ao escrever less(X,3) — ou eles podem ser especificados ao usar a notação infíxa comum X Q, OR Q, OR ... OR Qm

(2)

cm que => é o símbolo implica. As fórmulas (1) e (2) são equivalentes, significando que seus valores verdade são sempre os mesmos. Isso acontece porque, se todas as literais Pf (/ = 1, 2,..., w) forem verdadeiras, a fórmula (2) só é verdadeira se pelo menos um dos Qi for verdadeiro, que é o significado do símbolo => (implica). Para a fórmula (1), se todas as literais Pi (i= 1,2,..., n) forem verdadeiras, suas negações são todas falsas; assim, nesse caso, a fórmula (1) só é verdadeira se pelo menos um dos Q. for verdadeiro. Em Datalog, as regras são expressas como uma forma restrita de cláusulas, chamadas cláusulas de Horn, em que uma cláusula pode conter no máximo uma literal positiva. Logo, uma cláusula de Horn pode ter a forma

NOT(Pj) OR NOT(P2) OR ... OR NOT(P„) OR Q

(3)

ou a forma

NOT(P,) OR NOT(P2) OR ... OR NOT(Pn)

(4)

A cláusula de Horn em (3) pode ser transformada na cláusula P, AND P2 AND ... AND P„=>Q

(5)

que é escrita em Datalog como a seguinte regra: Q > Pr Pi...... P„

(6)

A cláusula de Horn em (4) pode ser transformada para PI AND P2 AND ... AND Pn =>

(7)

que é escrita em Datalog da seguinte forma: Pv Pl...... P.

(8)

905

906

Sistemas de banco de dados

Uma regra Datalog, como em (6), é, portanto, uma cláusula de Horn, e seu sig­ nificado, baseado na fórmula (5), é que, se os predicados Pt AND P2 AND ... AND Ptl forem todos verdadeiros para um vínculo em particular com seus argumentos variáveis, então Q também é verdadeiro e, portanto, pode ser deduzido. A expressão Datalog (8) pode ser considerada uma restrição de integridade, em que todos os predicados devem ser verdadeiros para satisfazer a consulta. Em geral, uma consulta cm Datalog consiste cm dois componentes: ■ Um programa Datalog, que é um conjunto finito de regras. ■ Uma literal P(X,, X2,..., Xrt), em que cada Xt é uma variável ou uma constante.

Um sistema em Prolog ou Datalog tem um mecanismo de inferência interno que pode ser usado para processar e calcular os resultados de tais consultas. Os mecanismos de inferência em Prolog normalmcnte retornam um resultado para a consulta (ou seja, um conjunto de valores para as variáveis na consulta) de cada vez e devem ser solicitados a retornar resultados adicionais. Ao contrário, Datalog retorna resultados um conjunto de cada vez.

26.5.5 Interpretações de regras Existem duas alternativas principais para interpretar o significado teórico das regras: teórico de prova c teórico de modelo. Em sistemas práticos, o mecanismo dc inferência em um sistema define a interpretação exata, que pode não coincidir com nenhuma das interpretações teóricas. O mecanismo de inferência é um procedimento computacional e, portanto, oferece uma interpretação computacional do significado das regras. Nesta seção, primeiro discutimos as duas interpretações teóricas. Depois, discutimos rapida­ mente os mecanismos de inferência como um modo de definir o significado das regras. Na interpretação teórica de prova das regras, consideramos os fatos e as regras como afirmações verdadeiras, ou axiomas. Axiomas de base não possuem variáveis. Os fatos são axiomas de base dados como verdadeiros. Regras são chamadas de axio­ mas dedutivos, pois podem ser usadas para deduzir novos fatos. Os axiomas dedu­ tivos podem ser utilizados para construir provas que derivam novos fatos de fatos existentes. Por exemplo, a Figura 26.12 mostra como provar o fato SUPERIOR(jorge, andre) com base nas regras e fatos dados na Figura 26.11. A interpretação teórica de prova nos dá uma técnica procedimental e computacional para calcular uma resposta à consulta Datalog. O processo de provar se certo fato (teorema) é mantido é conhecido como prova do teorema. O segundo tipo de interpretação é chamado de interpretação teórica de modelo. Aqui, dado um domínio finito ou infinito de valores constantes,1’ atribuímos a um predicado cada combinação possível de valores como argumentos. Devemos, então, determinar se o predicado é verdadeiro ou falso. Em geral, é suficiente espe­ cificar as combinações de argumentos que tornam o predicado verdadeiro e indicar que todas as outras combinações tomam o predicado falso. Se for feito para cada

1. SUPERIORR, V)SUPERVISIONAR,

2. SUPERIORR, Y)

Y).

SUPERVISIONAR, 2), SUPERIORR, 3. SUPERVISIONAÍjennifer, andre). 4. SUPERVISIONA(jorge, Jennifer).

5. SUPERIOR(jennifer, andre). 6. SUPERIORfjorge, andre).

(regra 1)

Y-

(regra 2)

(axioma de base, dado) (axioma de base, dado) (aplicar regra 1 sobre 3) (aplicar regra 2 sobre 4 e 5)

Figura 26.12 Provando um novo fato.

33 O domínio escolhido mais comum é finito e se chama Universo de Herbrand.

Capítulo 26 Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos 907

predicado, isso é chamado de uma interpretação do conjunto de predicados. Por exemplo, considere a interpretação mostrada na Figura 26.13 para os predicados SUPERVISIONA e SUPERIOR. Essa interpretação atribui um valor verdade (verdadeiro ou falso) para cada combinação possível de valores de argumento (de um domínio finito) para os dois predicados. Uma interpretação é chamada de modelo para um conjunto específico de regras se essas regras forem sempre verdadeiras sob essa interpretação; ou seja, para quaisquer valores atribuídos às variáveis nas regras, a cabeça das regras é verdadeira quando substituímos os valores verdade atribuídos aos predicados no corpo da regra por essa interpretação. Logo, sempre que determinada substituição (vínculo) para as variáveis nas regras é aplicada, se rodos os predicados no corpo de uma regra forem verdadeiros sob a interpretação, o predicado na cabeça da regra também precisa ser verdadeiro. A interpretação da Figura 26.13 é um modelo para as duas regras mostradas, pois nunca pode fazer que as regras sejam violadas. Observe que uma regra é violada se determinado vínculo de constantes para variáveis tornar rodos os predicados no corpo da regra verdadeiros, mas tomar o predicado na cabeça da regra falso. Por exemplo, se SUPERVISIONAR, b) e SUPERIORS, c) forem ambos verdadeiros sob alguma interpretação, mas SUPERIORR, c) não for verdadeiro, a interpretação não pode ser um modelo para a regra recursiva: SUPERIOR(X, Y)SUPERVISIONS, Z), SUPERIORS, Y)

Na técnica teórica de modelo, o significado das regras é estabelecido ao ofe­ recer um modelo para essas regras. Um modelo é chamado dc modelo mínimo

Regras SUPERIORS, Y)SUPERVISIONA(X, Y). SUPERIORS, Y)SUPERVISIONA(X, Z), SUPERIOR^, Y).

Interpretação Fatos conhecidos: SUPERVISIONA(fernando, joao) é verdadeiro. SUPERVISIONA(fernando, ronaldo) e verdadeiro. SUPERVISIONA(fernando, joice) é verdadeiro. SUPERVISIONA(jennifer, alice) é verdadeiro. SUPERVISIONA(jennifer, andre) é verdadeiro. SUPERVISIONA(jorge, fernando) é verdadeiro. SUPERVISIONAÍjorge, Jennifer) é verdadeiro. SUPERVISIONA(X, Y) é falso para todas as outras combinações possíveis de (X, Y) Fatos derivados: SUPERIOR(fernando, joao) é verdadeiro. SUPERIOR(fernando, ronaldo) é verdadeiro. SUPERIOR(fernando, joice) é verdadeiro SUPERIOR(jennifer, alice) é verdadeiro SUPERIOR(jennifer, andre) é verdadeiro SUPERIOR(jorge, fernando) é verdadeiro SUPERIOR(jorge, Jennifer) é verdadeiro SUPERIOR(jorge, joao) é verdadeiro. SUPERIOR(jorge, ronaldo) é verdadeiro SUPERIOR(jorge, joice) é verdadeiro. SUPERIOR(jorge, alice) é verdadeiro SUPERIOR(jorge, andré) é verdadeiro SUPERIORÍX, Y) é falso para todas as outras combinações possíveis de (X, Y)

Figura 26.13 Uma interpretação que é um modelo mínimo.

908

Sistemas de banco de dados

para um conjunto de regras se nào pudermos mudar nenhum faro de verdadeiro para falso e ainda obter um modelo para essas regras. Por exemplo, considere a interpretação na Figura 26.13, e suponha que o predicado SUPERVISIONA seja definido por um conjunto de fatos conhecidos, ao passo que o predicado SUPERIOR é definido como uma interpretação (modelo) para as regras. Suponha que acrescentemos o predicado SUPERIOR(jorge, roberto) aos predicados verdadei­ ros. Este permanece um modelo para as regras mostradas, mas não é um modelo mínimo, pois mudar o valor verdade de SUPERIOR(jorge, roberto) de verdadeiro para falso ainda nos oferece um modelo para as regras. O modelo mostrado na Figura 26.13 é o modelo mínimo para o conjunto de fatos definidos pelo predicado SUPERVISIONA. Em geral, o modelo mínimo que corresponde a determinado conjunto dc fatos na interpretação teórica de modelo deve ser o mesmo que os fatos gerados pela interpretação teórica de prova para o mesmo conjunto original de axiomas de base e dedutivos. Porém, isso geralmente é verdadeiro apenas para regras com uma estrutura simples. Quando permitimos a negação na especificação das regras, a correspondência entre as interpretações nào se mantém. De fato, com a negação, diversos modelos mínimos são possíveis para um determinado conjunto dc fatos. Uma terceira técnica para interpretar o significado das regras envolve a definição de um mecanismo de inferência usado pelo sistema para deduzir fatos das regras. Esse mecanismo de inferência definiria uma interpretação computacional para o signifi­ cado das regras. A linguagem de programação lógica Prolog utiliza seu mecanismo de interface para definir o significado das regras c fatos cm um programa Prolog. Nem todos os programas Prolog correspondem às interpretações teóricas de prova ou teóricas de modelo; isso depende do tipo de regras no programa. Porém, para muitos programas Prolog simples, o mecanismo de inferência Prolog deduz os fatos que correspondem ou à interpretação teórica de prova ou a um modelo mínimo sob a interpretação teórica de modelo.

26.5.6 Programas Datalog e sua segurança Existem dois métodos principais para definir os valores verdade de predi­ cados em programas Datalog reais. Predicados definidos por fato (ou relações) são definidos ao listar todas as combinações de valores (as tuplas) que tornam o predicado verdadeiro. Estas correspondem às relações de base cujo conjunto é armazenado cm um sistema de banco dc dados. A Figura 26.14 mostra os predi­ cados definidos por fato FUNCIONÁRIO, MASCULINO, FEMININO, DEPARTAMENTO, SUPERVISIONA, PROJETO e TRABALHA_EM, que correspondem à parte do banco de dados relacionai mostrado na Figura 5.6. Predicados definidos por regra (ou visões) são definidos por serem a cabeça (LHS) de uma ou mais regras Datalog; eles correspondem a relações virtuais cujo conteúdo pode ser deduzido pelo mecanismo de inferência. A Figura 26.15 mostra uma série de predicados defi­ nidos por regra. Um programa ou uma regra é considerado seguro se gerar um conjunto finito de fatos. O problema teórico geral de determinar se um conjunto de regras é seguro é indecidível. Contudo, pode-se determinar a segurança de formas restritas de regras. Por exemplo, as regras mostradas na Figura 26.16 são seguras. Uma situação cm que obremos regras inseguras que podem gerar um número infinito de fatos surge quando uma das variáveis na regra pode variar por um domínio infinito de valores, e essa variável não é limitada a variar por uma relação finita. Por exemplo, considere a regra a seguir:

ALTO-SALARIO(Y)V>60000

Capítulo 26

Modelos de dados avançados: ntrodução a bancos de dados ativos, têmporas, espaces, multimídia e dedutivos

FUNCIONARIO(joao). FUNCIONARlO(fernando). FUNCIONARlO(alice). FUNCIONARIOfjennifer). FUNCIONARIO(ronaldo). FUNCIONARIO(joice). FUNCIONARlO(andre). FUNCIONARIO(jorge).

SALARIO(joao, 30000). SALARIO(fernando, 40000). SALARIOfalice, 25000). SALARIOfjennifer, 43000). SALARIO(ronaldo, 38000). SALARIOfjoice, 25000). SALARIO(andre, 25000). SALARIO(jorge, 55000).

HOMEM(joao). HOMEM(fernando). HOMEM(ronaldo). HOMEM(andre). HOMEM(jorge). MULHER(alice). MULHERfjennifer). MULHER(joice). PROJ ETCXprod utox). PROJ ETO(prod utoy). PROJ ETO(prod utoz). PROJ ETO(inf ormatizacao). PROJ ETO(reorgan izacao). PROJ ETO(novosbenef idos).

TRABALHA_EM(joao, produtox, 32). DEPARTAMENTO(joao, pesquisa). TRABALHA_EM(joao, produtoy, 8). DEPARTAMENTO(fernando, pesquisa). TRABALHA_EM(ronaldo, produtoz, 40). DEPARTAMENTO(alice, administracao). TRABALHA_EM(joice, produtox, 20). DEPARTAME NTOfjenn ifer, ad ministracao). TRABALHA_EM(joice, produtoy, 20). DEPARTAMENTO(ronaldo, pesquisa). TRABALHA_EM(fernando, produtoy, 10). TRABALHA_EM(fernando, produtoz, 10). DEPARTAMENTOfjoice, pesquisa). DEPARTAM ENTO(andre, administracao). TRABALHA_EM(fernando, informatizacao, 10). TRABALHA_EM(fernando, reorganizacao, 10). DEPARTAMENTO(jorge, matriz). TRABALHA_EM(alice, novosbenefidos, 30). SUPERVISIONA(fernando, joao). TRABALHA_EM(alice, informatizacao, 10). SUPERVISIONA(fernando, ronaldo). TRABALHA_EM(andre, informatizacao, 35). SUPERVISIONA(fernando, joice). TRABALHA_EM(andre, novosbenefidos, 5). SUPERVISIONA(jennifer, alice). TRABALHA_EM(jennifer, novosbenefidos, 20). SUPERVISIONA(jennifer, andre). TRABALHA_EM(jennifer, reorganizacao, 15). SUPERVISIONA(jorge, fernando). TRABALHA_EM(jorge, reorganizacao, 10). SUPERVISIONA(jorge, Jennifer). Figura 26.14 Predicados definidos por fato para parte do banco de dados da Figura 5.6.

SUPERIORS, Y)SUPERVISIONAR, Y). SUPERIORR, Y)SUPERVISIONAR, 2), SUPERIORR, Y).

SUBORDINADOR, Y)SUPERIORR, X). SUPERVISORS FUNCIONÁRIOS, SUPERVISIONAR, Y). FUNCIONARIO_ACIMA_40KR) FUNCIONÁRIOS, SALARIOR, Y), Y>= 40000. SUPERVISOR_ABAlXO_40KR) > SUPERVISORS, NOT(FUNCIONARIO_ACIMA_40KS). FUNCIONARIO_PRINC_PRODUTOR) FUNCIONÁRIOS, TRABALHA_EM(X, produtox, Y),

Y >=20. PRESIDENTES

FUNCIONÁRIOS. NOT(SUPERVISIONA(Y, X)).

Figura 26.15 Predicados definidos por regra.

Aqui, podemos obter um resultado infinito se Y variar por todos os inteiros possíveis. Mas suponha que mudemos a regra da seguinte forma: ALTO_SALARIO(Y)FUNCIONARIO(X), Salario(X, Y), Y>60000

Na segunda regra, o resultado não é infinito, pois os valores aos quais Y pode estar vinculado agora são restringidos a valores que são o salário de algum funcioná­ rio no banco de dados — presumidamente, um conjunto de valores finito. Também podemos reescrever a regra da seguinte forma: ALTO_SALARIO(Y)Y>60000, FUNCIONARIO(X), Salario(X, Y)

909

910

Sistemas de banco de dados

REL_ONE(A B, O. REL_TWCXDZ E F). REL_THREE(G, Ht I, f).

SELECT_ONE_A_EQ_C(XZ Yf Z)REL_ONE(C, Y, Z). SELECT_ONE_B_LESS_5(XZ Y, Z)REL_ONE(XZ Y, Z), Y

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á inrimamente 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, probabilistico 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 scr 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 Microsoft. 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 transformativa? 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 revoorçã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 cm 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 de busca? Como ela é 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 RI 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 RI é Modern Information Retrieval, de Ricardo Baeza-Yates e Berthier Ribeiro-Neto (1999), que oferece uma cobertura detalhada dos diversos aspectos da tecnologia de RI. Os livros clássicos de Gerald Salton (1968) e Van Rijsbergen (1979) sobre recuperação dc 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 c pré-processamento dc 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. Brodcr (2002) classifica consultas da web cm três classes distintas — navcgacional, informativa e transacional — c 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 c 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 de 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 de 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 de 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 em 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 PageRank, 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 de funcionalidade: de consolidação, agregação e resumo de 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 de modo eficiente sobre grandes arquivos e bancos de 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 de dados, e esse campo é chamado popularmente de inteligência de 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 fortemente 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 até 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 dc 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 de 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 em Adriaans e 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. É 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 ser 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 dc 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 particionar 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 de 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 de dados é semelhante à função objetiva, usada em problemas de pesquisa operacional, que lida com otimização sob restrições.

O termo mineração de dados é popularmenre usado em um sentido amplo. Em algumas situações, ele inclui análise estatística e otimização restrita, bem como aprendizado de 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 de 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 é 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 de associação. Estas regras correlacionam a presença de um conjunto de itens com outra faixa de 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 de crédito com base em um histórico de 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 de 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 ser 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 ser 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 dc 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 Figura 28.1. Uma regra de associação tem a forma X => Y, em que X = (x1? x2,...» xn] c Y = (yp y2, —» >’wl sã° conjuntos de itens, com x- 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

Figura 28.1 Exemplo de

transações no modelo de cesta 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é

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 de 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 dc 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 de 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 em 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 de 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 é 2OT, em que m é 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 Lp 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 de itens 2 frequentes candidatos, C2. C2 contém (leite, pão}, {leite, suco}, {pão, suco}, {leite, biscoito}, {pão, biscoito} e {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 L}. 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 de dados D de m transações, e um suporte mínimo, mins., 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(z;)/m para cada item individual, q, i2,..., z„ fazendo a varredura do banco de dados uma vez e contando o número de transações em que o item z; aparece (ou seja, conta(z;)); 2. O conjunto de itens 1 frequente candidato, C,, será o conjunto de itens zp *2’ •••’ 3. O subconjunto de itens contendo z- de C1 em que suporte(zp >= mins torna-se o conjunto de itens 1 frequente, Lx\

4. k=l; termina = false; repita

1.

= (conjunto vazio);

2. Crie o conjunto de itens (fc+1) frequente candidato, Cfc+I, combinando membros de Lk que têm k-\ itens em comum (isso forma os conjuntos de itens (k+1) frequentes candidatos ao estender seletivamente 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 em Lk; 4. Faça a varredura do banco de dados uma vez e calcule o suporte para cada membro de Cfc4l; se o suporte para um membro de >= mins, então acres­ cente o membro em Lt+J;

5. Se I.kti 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 Z_, 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 dc bits e árvores dc hash para manter informações sobre conjuntos dc 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 dc 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 dc itens mínimos contidos em PovvcrSet(f) e não em 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 dc itens frequentes, então X estaria na borda negativa. Ilustramos isso com o exemplo a seguir. Considere o conjunto dc itens I = {A, B, C, D, E) 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 dc itens 3 cujos subconjuntos do conjunto de itens 2 estão todos cm 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 dc dados é varrido. Sc descobrirmos que um conjunto de itens X na borda negativa pertence ao conjunto dc 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) c 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 dc itens 1 frequentes, o algoritmo Apriori teria de gerar

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 dc 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. Sc 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 irem e o contador de suporte são auroexplicativos. 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 e 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 todos 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 de sufixo) e constrói sua base de 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.

Pão: 1

Leite: 3 Item

Suporte

Leite

3

Pão

2

Biscoito

2

Suco

2

Link

Pão: 1

Suco: 1 À

Biscoito: 1

Suco:1

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) procedimento-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, /, 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 item 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 particionamcnto. 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 rodos os conjuntos de itens frequentes de cada partição. Isso forma os conjuntos de itens frequentes candidatos globais para o banco de 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 dc interesse. 5 Ver em 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

calorias

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 de 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: Itens_comprados. A regra a seguir é um exemplo de inclusão do rótulo da única dimensão: Itens_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 de valores que não exibem qualquer relaciona­ mento de ordenação. Atributos quantitativos são numéricos e 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 dc 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 cem 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 dc dados. Se a ausência dc 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 dc nosso interesse. O problema, então, é encontrar apenas regras negativas de interesse. Em geral, estamos interessados cm casos cm que dois conjuntos específicos dc 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 dc 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 c 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 c Soda ou Lisas c 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

de refrigerantes e batatas fritas.

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 de 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 e distribuições de itens. O crescimento exponencial 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 ser classificados como risco fraco, risco médio ou risco bom. Logo, esse tipo de 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 ser na forma de uma árvore de 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 de decisão. Uma árvore dc decisão c 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: Rp •••» e conjunto de atributos: A,, A2,..., 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- = 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(Sz, atributos - A,); fim; Fim;

Antes de ilustrarmos o Algoritmo 28.3, explicaremos a medida do ganho de 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 ..., 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 Py. Uma estimativa para p- é s/s. Considere um atributo A com valores (t/p z'OT| 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 Sf 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)=fS|'+-s'+S"'x/(^,...,S„) j=l

d

/(íj-, s •) pode ser definido utilizando a formulação para /(sp ..., sn) com p, sendo substituído por p-, em que pf/ = si/s/. Agora, o ganho de informação ao particionar no atributo A, Ganho(A), é definido como /(sp ..., sn) - 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 I(st, s2), nos quais existem duas classes: o primeiro valor de rótulo de classe corresponde a sim e o segundo, a não. Assim,

1(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 /(sn, s2I) = 0,92. Para Casado = não, temos sI2 = 1, s22 = 2 e /(s12, $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 /(sn, 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

T-rb,|

Quanto menor a distância entre dois pontos, maior é a semelhança conforme pensamos nelas. Um algoritmo de agrupamento clássico é o algoritmo de &-means, o Algoritmo 28.4. Algoritmo 28.4. Algoritmo de agrupamento de £-means Entrada: Um banco de dados D, de m registros, r,,..., rm e um número desejado de clusters k Saída: Conjunto de k clusters que minimiza o critério de erro ao quadrado Início escolha aleatoriamente k registros como os centroides para os k clusters; repita atribua cada registro, a um cluster tal que a distância entre reo centroide do cluster (médio) é a menor entre os k clusters; recalcule o centroide (médio) para cada cluster com base nos registros atri­ buídos ao cluster; até que não haja mudança; Fim;

O algoritmo começa escolhendo aleatoriamente k registros para representar os centroides (médias), Wj,..., dos clusters, Cp ..., Ct. Todos os registros sào colocados em determinado cluster com base na distância entre o registro e a média do cluster. Se a distância entre w, e o registro r- é a menor entre todas as médias de cluster; então o registro r- é colocado no cluster C;. Quando todos os registros tiverem sido colocados inicialmente em um cluster, a média para cada cluster é recalculada. Depois o processo se repete, examinando cada registro novamente e colocando-o no cluster cuja média é a mais próxima. Várias iterações podem ser necessárias, mas o algoritmo convergirá, embora possa terminar em um ponto ideal local. A condição de término normalmente é o critério de erro ao quadrado. Para os clusters Cp ..., Ck com médias ..., mk, o erro é definido como: t Erro =

y, Distância(r-,wf)2 í=i VfjeÇ

Examinaremos como o Algoritmo 28.4 funciona com os registros (bidimensio­ nais) na Figura 28.8. Suponha que o número de clusters k desejados seja 2. Considere que o algoritmo escolha registros com RID 3 para o cluster Cj e RID 6 para o cluster C2 como centroides de cluster iniciais. Os registros restantes serão atribuídos a um desses clusters durante a primeira iteração do loop repita. O registro com RID 1 tem uma distância de Cj igual a 22,4 e uma distância de C2 de 32,0, de modo que se junta ao cluster Cr O registro com RID 2 tem uma distância de Cj igual a 10,0 e uma distância de C2 igual a 5,0, de modo que se junta ao cluster C2. O registro com RID 4 tem uma distância de Cj igual a 25,5 e uma distância de C, igual a 36,6, de modo que se junta ao cluster Cj. O registro com RID 5 tem uma distância de Cj igual a 20,6 e uma distância de C2 igual a 29,2, de modo que se junta ao cluster Cj. Agora, a nova média (centroide) para os dois clusters é calculada. A média para um cluster, Cy, com w registros de w dimensões é o vetor:

983

984

Sistemas de banco de dados

Figura 28.8 Registros de duas

dimensões de amostra para o exemplo de agrupamento (a

RID

Idade

Anos_de_servico

1

30

5

2

50

25

3

50

15

4

25

5

5

30

10

6

55

25

coluna RID não é considerada).

A nova média para C, é (33,75; 8,75) e a nova média para C, é (52,5; 25). Uma segunda iteração é realizada c os seis registros sào colocados nos dois clusters da seguinte forma: os registros com RIDs 1, 4, 5 são colocados em Cj e os registros com RIDs 2, 3, 6 são colocados em C2. A média para C] e C2 é recalculada como (28,3; 6,7) e (51,7; 21,7), respectiva mente. Na próxima iteração, rodos os registros permanecem em seus clusters anteriores e o algoritmo termina. Tradicionalmente, os algoritmos de agrupamento consideram que o conjunto de dados inteiro cabe na memória principal. Mais recentemente, os pesquisadores desen­ volveram algoritmos eficientes e escaláveis para bancos de dados muito grandes. Um desses algoritmos é chamado de BIRCH. BIRCH é uma abordagem híbrida, que usa agrupamento hierárquico e monta uma representação de árvore dos dados, bem como métodos de agrupamento adicionais, aplicados aos nós folha da árvore. Dois parâme­ tros dc entrada são utilizados pelo algoritmo BIRCH. Um especifica a quantidade de memória principal disponível e o outro é um threshold inicial para o raio de qualquer cluster. A memória principal serve para armazenar informações de cluster descritivas, como o centro (média) de um cluster e o raio do cluster (clusters são considerados esféricos em forma). O threshold do raio afeta o número de clusters produzidos. Por exemplo, se o valor de threshold do raio for grande, menos clusters de muitos registros serão formados. O algoritmo tenta manter o número de clusters de modo que seu raio esteja abaixo do threshold do raio. Se a memória disponível for insuficiente, o threshold do raio é aumentado. O algoritmo BIRCH lê os registros de dados sequencialmente e os insere em uma estrutura de árvore na memória, que tenta preservar a estrutura dc agrupa­ mento dos dados. Os registros são inseridos em nós folha apropriados (clusters em potencial), com base na distância entre o registro e o centro do cluster. O nó folha onde a inserção acontece pode ter de ser dividido, dependendo do centro atualizado, do raio do cluster e do parâmetro de threshold do raio. Além disso, ao dividir, informações extras do cluster são armazenadas, e se a memória se tornar insuficiente, o threshold do raio será aumentado. Aumentar o threshold do raio pode realmente produzir um efeito colateral de reduzir o número de clusters, pois alguns nós podem ser mesclados. Em geral, o BIRCH é um método de agrupamento eficiente, com uma com­ plexidade computacional linear em relação ao número de registros a serem agrupados.

28.5 Abordagens para outros problemas de mineração de dados 28.5.1 Descoberta de padrões sequenciais A descoberta de padrões sequenciais é baseada no conceito de uma sequência de conjuntos de itens. Consideramos que transações como as de cesta de mercado.

Capitulo 28

Conceitos de mineração de dados

que discutimos anteriormente, sào ordenadas por momento da compra. Essa ordenação gera uma sequência de conjuntos de itens. Por exemplo, {leite, pão, suco), {pão, ovos), {biscoito, leite, café) podem ser tal sequência de conjuntos de

itens com base em três visitas pelo mesmo cliente ao mercado. O suporte para uma sequência S de conjuntos de itens é a porcentagem do conjunto indicado U de sequências das quais S é uma subsequência. Neste exemplo, {leite, pão, suco) {pão, ovos) e {pão, ovos) {biscoito, leite, café) são consideradas subsequências. O problema dc identificar padrões sequenciais, então, é encontrar todas as sub­ sequências para os conjuntos de sequências indicados que possuem um suporte mínimo definido pelo usuário. A sequência S2, S3,... é um indicador do fato dc que um clicntc que compra o conjunto dc itens S, provavelmente comprará o conjunto de itens S, e depois S3, c assim por diante. Essa previsão c baseada na frequência (suporte) dessa sequência no passado. Diversos algoritmos foram investigados para a detecção de sequência.

28.5.2 Descoberta de padrões na série temporal Séries temporais são sequências de eventos; cada evento pode ser um certo tipo fixo dc uma transação. Por exemplo, o preço dc fechamento dc uma ação ou de um fundo c um evento que ocorre a cada dia da semana para cada ação c fundo. A sequência desses valores por ação ou fundo constitui uma série temporal. Para uma série temporal, pode-se procurar uma série de padrões ao analisar sequências e sub­ sequências, como fizemos antes. Por exemplo, poderiamos achar o período durante o qual o preço da ação subiu ou se manteve constante por w dias, ou poderiamos achar o período mais longo sobre o qual o preço da ação teve uma flutuação de não mais que 1 % em relação ao preço de fechamento anterior, ou poderiamos achar o trimestre durante o qual o preço da ação teve o maior ganho percentual ou perda percentual. A série temporal pode ser comparada estabeleeendo-se medidas dc semelhança para identificar empresas cujas ações se comportam de um modo semelhante. A análise e mineração de séries temporais é uma funcionalidade estendida do gerenciamento de dados temporais (ver Capítulo 26).

28.5.3 Regressão A regressão é uma aplicação especial da regra de classificação. Se uma regra de classificação é considerada uma função sobre as variáveis, que mapeia essas variáveis em uma variável de classe de destino, a regra é denominada regra de regressão. Uma aplicação geral da regressão ocorre quando, em vez de mapear uma tupla de dados dc uma relação para uma classe específica, o valor dc uma variável é previsto com base nessa tupla. Por exemplo, considere uma relação TESTES_LAB (ID paciente, teste 1, teste 2,..., teste n)

que contém valores que são resultados dc uma série dc n testes para um paciente. A variável de destino que queremos prever é P, a probabilidade de sobrevivência do paciente. Então a regra para regressão toma a forma: (teste 1 no intervalo,) e (teste 2 no intervalo2) e ... (teste n no intervaloj => P = x, ou x < P < y 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=/-(xpx2, 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 comumente utilizada para ajustar um conjunto de 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 de destino é equivalente a uma operação de mineração de 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 de ajuste de curva para deduzir uma função a partir de um conjunto de 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 de modo geral em duas categorias: redes supervisionadas e 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. z\pesar 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 de pesquisa aleatórios capazes de realizar pesquisa adaptativa e robusta por uma grande faixa de topologias de 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 de imagens, escalonamento e projeto de 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éticos 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 de 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 inglês graphical user interface). Alguns produtos incluem técni­ cas de visualização sofisticadas para exibir dados e 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 de 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 Data 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.

Produto

Empresa

AcknoSoft

Angoss

Kate

Knowledge

Técnica

Business Miner

CrossZ

QueryObject

Windows

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

Technology Inc.

UNIX

IBM

Megaputer Intelligence

Análise OLAP, associações,

DBMiner

classificação, algoritmos de

Windows

agrupamento Intelligent

Classificação, regras de associa­

Miner

ção, modelos de previsão Aquisição de conhecimento

PolyAnalyst

simbólico, programação

evolucionária

ODBC

UNIX

dados

DBMiner

Microsoft Access

Windows

Abrangente; pode misturar di­

Data Distilleries

* Interface

seado em caso

SEEKER

Business Objects

Plataforma

Árvores de decisão, raciocínio ba­

ODBC e compatível

com ODMG

Microsoft 7.0

OLAP

UNIX (AIX)

IBM DB2

Windows

ODBC

OS/2

Oracle DB2

Windows

ODBC

Management NCR

Discovery Tool

Regras de associação

(MDT)

Oracle

Árvores de decisão, regras de

Purple Insight

SAS

MineSet

Enterprise Miner

associação

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. Atualmente, 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 de 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 de 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 de informações será viável, até mesmo para pequenas empresas. Assim, os programas de mineração de dados terão de lidar com conjuntos de 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 cm 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 de produtos de tecnologia dc banco dc dados, espera-se muita atividade de mineração de dados. Resumimos 11 das quase cem ferramentas de mineração de 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 de conhecimento produzidos da mineração de dados? O que são regras de 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 em 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

superior incompleto

NÂO

nível médio

NÃO

Educacao

Cliente_assiduo

104

51...60

SP

F

105

31...40

RJ

M

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

991

992

Sistemas de banco de dados

28.20. Considere o seguinte conjunto de registros bidimensionais: RID

Dimensão1

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 centro ides (médias) de grupo iniciais. 28.22. O algoritmo de &-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 de Han e 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 de dados. Agrawal et al. (1993b) discutem a perspectiva dc desempenho sobre regras de 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 dc 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. zXcompanhando 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 e 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 de 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 de conhecimento e 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 e direta dos dados analíticos armazenados em 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 de informações executivas (ou sistemas de informações gerenciais, management information systems), que não devem ser 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 exclusões, enquanto também têm suporte para requisitos de consulta de 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 de 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 de 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 de dados disjuntos e normalmente 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 geralmente é 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 e podem scr consideradas como apenas dc leitura/acréscimo/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 dc 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 dc 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 dc 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. ■ Manipulaçã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 marts 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 de limpeza, agregação e transformação.

29.3 Modelagem de dados para data warehouses Modelos multidimensionais tiram proveito dos relacionamentos inerentes nos dados para preencher os dados cm matrizes multidimensionais, 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 multidimensionais 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.

3 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 de 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 de maneira gráfica. Os dados podem ser consultados dirctamente em qualquer combinação de 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. Região

Figura 29.2 Um modelo de

matriz bidimensional.

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 de 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 dice9* 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 e, depois, as vendas regionais por sub-região e também separando produ­ tos por estilos. Geralmente, 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

*

Estilos P125

A B C D

Sub.reg 2

Sub_reg 3

Sub_reg 4

Sub.reg 1

q

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 de 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 dc 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

Numero_produto

Trimestre

Nome_produto Descricao_produto

Estilo_produto

Ano Datajnicio Data fim

Numero produto Trimestre

Linha_produto

Região Receita vendas 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

Datas TF

Trimestre fiscal

NomeP Nome produto Descricao produto

Tabela de fatos Resultados de negóoos

Produto

Da_ta_mido Data_fim

Trimestre Ano Data inicio

Numero_produto

N9_T?-P_r9duto_ Estilo • NjimeroJjnha_prgduto__

** 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 de 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. Se houver um índice de junção sobre cidade, para cada cidade o índice de junção mantém as IDs de rupia 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 dc 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 management}y 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 dc 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 cm 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 dc 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 de 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 credito 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 dc 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 de 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 scr 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 dc 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 de metadados replicado residiría em cada site de distribuição. A ideia do warehouse federado é a mesma do banco de 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 de big data levou o Hadoop e outros bancos de dados especializados, como armazenamentos de grafos e cha­ ve-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 de 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 de 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 de 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 de 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 e técnicas usadas estão a transformação dc consulta; interseção e união de í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 de 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 de 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 e 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 multidi­ mensionais com níveis dc agregação. ■ Os data warehouses podem ser indexados para otimizar o desempenho. As visões não podem ser indexadas independentemente 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 de 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 de 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 — especialmente 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, de 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 de 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, em 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 de 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 data 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 e 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 tiram 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------------------------------------------------------------------

Ininon (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 dc dados que é conhecido como controle dc acesso obrigatório. Essa seção também apresenta as estratégias mais rcccntemente desenvolvidas de controle dc acesso baseado cm 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, c trata dc algumas das medidas preventivas propostas contra ela. A Seção 30.5 discute rapidamente o problema de segurança nos bancos dc 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 infraestrutura 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 dc 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 de segurança devem ser impostas — por exemplo, se uma função de segurança deve ser tratada no nível de 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- Rietta

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 de 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 forre 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 de acesso, controle de 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 de usuários acessem partes selecionadas de um banco de dados sem que obtenham acesso ao restante dele. Isso c particularinente importante quando um grande banco de 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 de dados que é responsável por garantir a segurança de partes de 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 de segurança discricionários. Usados para conceder privilégios aos usuá­ rios, incluindo a capacidade de acessar arquivos de dados, registros ou campos espe­ cíficos em um modo especificado (como leitura, inserção, exclusão ou atualização). ■ .Mecanismos de segurança obrigatórios. Usados para impor a segurança multinível pela classificação de dados e usuários em 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 e a segurança obrigatória e 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 de 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 dc população pode oferecer estatísticas com base cm faixas etárias, níveis dc 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 dc 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 dc dados estatístico, é discutido rapidamente na Seção 30.4. As medidas dc controle correspondentes são chamadas dc medidas de controle dc inferência. Outra questão dc segurança é a do controle dc 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 dc maneiras que violam a política dc segurança dc 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 ripo 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 dc dados atualmente são usados em aplicações dc organizações privadas e também governamentais e 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 dc um indi­ víduo cm 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 dc 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 dc identificação, códigos de acesso ou senhas. ■ Senhas de conta ou números de identificação pessoal ou outros códigos dc 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

Capítulo 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 de 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 permirem 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 de conta do usuário e 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 de dados e de 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 de log de 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 de qualquer adulteração, é realizada uma auditoria do banco de 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 de conta usado para realizar a operação. As auditorias são particularmente importantes para bancos de 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 de 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 de salário de um fun­ cionário ou o registro do histórico de salários cm um banco de 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 de algum outro dado — por exemplo, a informação exata de latitude e longitude para um local onde aconteceu algum evento previamente registrado, que mais tarde foi considerado confidencial.

Capítulo 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 dc 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 dc controle dc 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 dc 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 de 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 de usuário (ou grupo dc contas dc 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 de banco dc dados:

3 Privilégios discricionários foram incorporados à SQL2 c se aplicam a versões posteriores da SQL.

Capítulo 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 de 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 de 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 não 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 dc 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 relaçã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 de 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 relaçã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 i mantém sobre o objeto j. Para controlar a concessão e revogação de 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 em 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 podem 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 dc recuperar apenas alguns campos dc R, então A pode criar uma visão V dc R que inclua apenas os atributos c depois conceda SELECT para B sobre V. O mesmo se aplica à limitação de B para recuperar apenas certas tuplas dc R; uma visão V pode ser criada ao definir a visão por meio de uma consulta que seleciona apenas as tuplas dc 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 feita 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

Capítulo 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 SQI.2, 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

DEPARTAMENTO Numero.departamento

Nome.departamento

Cpf.gerente

Numero.departamento

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 dc 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 dc privilégios. A concessão dc um privilégio com uma propagação vertical dc zero é equi­ valente a conceder o privilégio sem GRANT OPTION. Sc 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 ser 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 ser menor ou igual à concedida originalmente. Por exemplo, se a conta A concede um privilégio à conta B com a propagação horizontal definida como um número inteiro j > 0, isso significa que B pode conceder o privilégio para outras contas apenas com uma propagação horizontal menor ou igual a /'. 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.

Capítulo 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 dc segurança multinível existe cm 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 dc informação pcssoalmcnte 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-LaPadida,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 classe(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 classc(S) classe(O). Isso é conhecido como propriedade dc 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 dc segurança é maior que a autorização dc segurança do sujeito. A segunda restrição é menos intuitiva. Ela proíbe um sujeito dc gravar um objeto em uma classificação de segurança inferior que a autorização dc 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 dc segurança multinível ao modelo dc banco dc 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 I.a 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, A2, 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 dc todos os valores de classificação dc atributo dentro dc t — ofcrccc uma classificação geral para a própria tupla. Cada classificação dc atributo C, ofcrccc 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 Ci 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 cm uma classificação de nível inferior por meio de 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 dc segurança C não poderia ver os valores para Salario de ‘Borges’ e Desempenho_cargo dc ‘Silva’, pois eles têm 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.

Capítulo 30

(a)

Segurança de banco de dados

Figura 30.2 Uma relação

FUNCIONÁRIO Salario

Nome

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 Desempenho cargo

Salario

Nome

U

Silva

classificação C. (c) Aparência

Borges C

TC

de FUNCIONÁRIO depois

40000

C

NULL

C

C

da filtragem para usuários

NULL

C

Bom

C

C

com classificação U. (d) Poli-

-instanciação da tupla de Silva. (C)

FUNCIONÁRIO

U

Silva

(d)

Desempenho cargo

Salario

Nome

NULL

U

NULL

U

TC

U

FUNCIONÁRIO Desempenho cargo

Salario

Nome

TC

Silva

U

40000

C

Regular

S

S

Silva

U

40000

C

Excelente

C

C

Borges C

80000

S

Bom

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 podería 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 dc 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 dc conta dc 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 em 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 dc 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

Capítulo 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 ripo 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 fundonario_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 rodos 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 remporizado de um papel por uma ativação de outro papel. O uso dc um modelo RBAC é um objetivo altamente desejável para a resolução dos principais requisitos dc 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 c 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 de acesso cm nível dc linha, cada linha dc dados rcccbc 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 rcccbc

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 cerros 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 de linha é 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 em 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 de segurança geralmente são criadas por gerentes e 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 de 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 de rótulo de 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 de segurança. Entre esses esforços estão assinaturas

Capítulo 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 dc correio eletrônico c 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 dc 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 dc processamento adicionais para o destinatário são representados na XML bem formada, dc modo que o resultado pode ser proces­ sado ainda mais usando ferramentas XML. Ao contrário dc 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 cm armazenamento persistente. Sistemas de banco dc 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 dc controle dc acesso, que vão além dos SGBDs tradicionais. Em ambientes dc 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 c-commcrcc. Além disso, cm 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 dc 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 dc forma inadequada, isso equivale a um vazamento dc dados, que tem consequências legais c 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 de controle precisam permitir a inclusão de condições com base no conteúdo do objeto. Um terceiro requisito está relacionado à heterogeneidade 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 de 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 de acesso para aplicações de c-commerce6 porque ela está se tornando a linguagem de 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. /\ 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 dc uma linguagem baseada em XML para especificar credenciais c políticas de controle de acesso facilita a submissão segura da credencial e a exportação de políticas de controle de acesso. 6 Ver Thuraisingham ct al. (2001).

Capítulo 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 em que o acesso a aplicações ou dados da rede é negado aos usuários legítimos pelo estouro do buFFcr ou esgotamento dc 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 dc 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 dc banco dc 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 dc execução. Por exemplo, a tabela ditai é 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 dc 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 (fchttp://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 dc 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

Capítulo 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 normalmcnte 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 remora. ■ 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:

PreparedSratemenr srmt = conn.prepareStatemenrf "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 de 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 dc 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. /\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 cm 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 segurança do banco de dados

estatístico.

PESSOA Nome

Çpf

Renda

Endereço Cidade] Estado

Cep

Sexo | Escolaridade

Capítulo 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 dc fluxo verificam que a informação contida cm 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 dc segurança; a transferência de informações de um emissor para um receptor só é permitida se a classe dc segurança do receptor for pelo menos tào privilegiada quanto a do emissor. Alguns exemplos dc um controle dc 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 dc fluxo especifica os canais ao longo dos quais a informação tem permissão para se mover. A política dc fluxo mais simples especifica apenas duas classes dc 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 dc 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 dc acesso, que envolve atribuir uma classe dc segurança (normalmcnte chamada dc 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 dc 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(Xmti Xn) então Y:= f(X} Xm). Os mecanismos dc 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 de 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, de outra forma, é inacessível ao usuário. Em um exemplo simples de canal secreto, considere um sistema de banco de dados distribuído em que dois nós tenham níveis de 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ó U, 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 é a conversão de dados para um formato, chamado texto cifrado, que não pode scr 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 de 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 descriptografada 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.

Capítulo 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 M1TS 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 dc 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 dc 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 Pl\ 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 em 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 em uma string de símbolos. Se a assinatura digital de uma pessoa sempre fosse a mesma para cada mensagem, alguém poderia s 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 globalmente 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

Capítulo 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 de 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, e assim por diante. Como exemplo, considere registros e transações médicos e 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 cm segurança dc banco de 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 cm 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 de 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 dc 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 ser 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 de 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.

Capítulo 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 dc 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 dc 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ótulo

de usuário

Nível de acesso

máximo

I | i I

Todos os compartimentos aos

quais o usuário tem acesso

Rótulo

Nível de acesso ■

Todos os compartimentos aos

de dados

mínimo exigido: i

quais o usuário deve ter acesso

FonteOracle (2007)

Capítulo 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 de 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 rodo 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, geralmente é conhecida como controle de acesso discricionário (DAC). /Xpresentamos 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 dc políticas dc segurança ao usar uma combinação da segurança baseada cm 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 dc 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 dc visão é usado como um mecanismo de autorização? Discuta os tipos dc privilégios no nível dc conta c aqueles no nível dc relação. O que significa a concessão dc 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 dc 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 c ao MAC? Quais são os dois tipos dc exclusão mútua no controle dc 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 dc ataques dc 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 dc pri­ vacidade nos bancos dc 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? Dc um exemplo dc canal secreto. Qual é o objetivo da criptografia? Que processo está envolvido na criptografia de dados e sua recuperação na outra ponta?

Capítulo 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 dc 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 dc dados? 30.31. Cite alguns dos maiores desafios atuais para a segurança do banco dc 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. A 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 dc 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 et 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 et al. (1995) e Thuraisingham et 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 em 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 ofcrccc detalhes sobre hierarquia de 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 ct 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 r\ 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.l(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. 1(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 decardinalidade 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. notação (iv)

A

1054

(a)

Sistemas de banco de dados

Símbolos de tipo/dasse de entidade

o Q

(ii)

E

(iii) ------------- O A

Símbolos de atributo

Símbolos de relacionamento

(ü) ( R

)

(iii) —5------

(b)

(c)

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.l (d) traz diversas variações para exibição (min, max) de restrições, utilizadas para mostrar a razão de cardinalidade c 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 de 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 e 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 k 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 de k blocos consecutivos é

s + 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 dc transferência bruta (ttbr) que leva em conta o tamanho da lacuna ao ler blocos armazenados consecutiva mente. Se 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 + ar + {k x {B/ttbr}) ms Outro parâmetro dos discos é o tempo de 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 dc volta no mesmo bloco dc disco cm 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 x ar ms = 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

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 P (chamado operador P ponto) é inserido em certas colunas para indicar que gostaríamos

Sistemas de banco de dados

1062

FUNCIONÁRIO

I

Primeiro.nome

Nome.meio | Ultimo.nome | Cpf | Data nascimento

Endereço

Sexo| Salario Cpf supervisor | Numero departamento |

DEPARTAMENTO Nome departa mento

Numero departamento |cpf gerente|Data inicio gerente |

LOCAUZACOES_DEPARTAMENTO | Numero departamento| Local

PROJETO Nome projeto

Numero_projeto

I

I

Local projeto

Numero departamento |

TRABALHA EM Cpf funcionário

Numero_projeto

I

Horas

DEPENDENTE Cpf funcionário

Nome dependente

Sexo Dat

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 de 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 Primeiro_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 de domínio (elementos de exemplo). O prefixo P. é 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 Nome.meio Ultimo.nome João

B.

Silva

Cpf .12345678966

Data.nascimento

Endereço

P..9/1/60

P._ Rua das Flores. 751. São Paulo. SP

Sexo

Salario

Cpf.supervisor Numero.departamento

.25000 .12345678966

-3

(b) FUNCIONÁRIO Primeiro.nome Nome.meio Ultimo.nome João

B.

Cpf

Silva

Data.nascimento

Endereço

P..9/1/60

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

Data .nascimento

Endereço

Sexo Salario

Cpf.supervisor Numero.departamento

Sexo

Salario

Cpf.supervisor Numero.depa'tamento

Sexo Salario

Cpf.supervisor Numero-departamemo

(c) FUNCIONÁRIO

Primeiro,nome Nome.meio Ultimo.nome João

B.

Cpf

Stfva

P..X

P..Y

(d) FUNCIONÁRIO Pnmeiro.nome Nome.meio Ultimo.nome João

B.

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 . Acesso em: maio 2008.

______ .; GEHANI, N. ODE: The language and rhe data model. ______ SR1KANT, R. Fast algorithms for mining association rules VLDB,

1994.

______ ; GEHANI, N.; SRINIVASAN, J. OdeView: The graphical SIGMOD,

1990.

______ ________.;______ . Database mining: A performance pers­

v. 5, n. 6, dez. 1993. KDD,

1996.

AHAD, R.; BASU, A. ESQL: A query language for rhe relational model supporting image domains. In:

ICDE,

1991.

2006.

for association generation.

v. 22, n. 6,

Information Systems,

set. 1997.

Memory Caching for Parallel Jobs. In: USENIX Symp. on Networked Systems Design and Implementation (NSDI), 2012. ANDERSON, S. et al. Sequence and organization of the human mitochondrial genome.

Nature,

v. 290, p. 457-465, 1981.

advances in an object-oriented development environment. OOPSLA,

1987.

Data Base Management Systems: Interim Report.

FDT,

v. 7,

n.2,ACM, 1975.

ANSI. American National Standards Institute.

The database lan­

Documento ANSI X3.135, 1986.

ANSI. American National Standards Institute. Inguage NDL.

The database

Documento ANSI X3.133, 1986a.

ANSI. American National Standards Institute. resource dictionary systems.

to the technology.

Information

Documento ANSI X3.138,1989.

Geographic information systems: A guide

Chapman e I lall, maio 1998.

ANWAR, T; BECK, H.; NAVATHE, S. Knowledge mining by

imprecise querying: A classification based approach. In:

ICDE,

APERS, P.; HEVNER, A.; YAO, S. Optimization algorithms for

distributed queries.

TSE,

v. 9, n. 1, jan. 1983.

proteomics.

Pharmacogenomics,

v. 4, n. 3, p. 343-350, maio

2003.

______ . et al. Of Snowstorms and Bushy Trees. In:

VLDB,

2014.

AHO, A.; ULLMAN, J. Universality’ of data retrieval languages. Proc. POPE Conference.

San Antonio, TX, ACM, 1979.

______ .; BEERI, C.; ULLMAN, J. The theory of joins in relational TODS,

AMIR, A.; FELDMAN, R.; KASI IL R. A new and versatile method

APWE1LER, R. et al. Managing core resources for genomics and

AHMED R. et al. Cost-Based Query Transformation in Oracle".

databases.

ALONSO, G. et al. Functionalities and limitations of current workflow management systems. 1F.F.F. Expert, 1997.

1992.

______ . et al. The quest data mining system. In:

VLDB,

v. 14, n.

26, n. 11, p. 832-843, nov. 1983.

ANTENUCCI, J. et al.

______ .; IMIEL1NSKI, T.; SWAMI, A. Mining association rules between sets of items in databases. In: SIGMOD, 1993.

TKDE,

CACM, v.

guage SQL.

In: SIGMOD, 1989.

interface to ode. In:

Computing Surveys,

ANSI. American National Standards Institute Study Group on

Disponível em: