Sistemas de Banco de Dados navathe 6 Edicao - Outros (2025)

Prévia do material em texto

ISBN 978-85-7936-085-5sv.pearson.com.brA Sala Virtual oferece: para professores, apresentações em PowerPoint, banco de imagens, manual de soluções (em inglês); para estudantes, apêndices D e E (em inglês), manual de laboratório (em inglês).Computaçãow w w . p e a r s o n . c o m . b rSistemas debanco de dadosElmasri • Navathe6a ediçãoSistemas debanco de dadosElmasriNavathe6a ediçãoSistemas debanco de dadosElmasri • Navathe6a ediçãoReferência acadêmica tanto teórica como prática, Sistemas de banco de dados apresenta os aspectos mais importantes não apenas dos sistemas, mas também das aplicações de banco de dados, além de diversas tecnologias relacionadas ao assunto. Atualizada, a obra aborda: • Conceitos fundamentais para projetar e usar os sistemas de banco de dados.• Fundamentos de modelagem e de projeto de banco de dados.• Linguagens e modelos fornecidos pelos sistemas de gerenciamento de banco de dados.• Técnicas de implementação do sistema de banco de dados, com exemplos práticos.Indicado para os cursos de ciência e engenharia da computação, desenvolvimento de sistemas e sistemas de informação, este livro é também bibliogra� a básica para cursos de análise de redes, análise de sistemas e processamento de dados.CVR_ELMA0855_6_CVR.indd 1 23/07/2014 09:41:2600 elmas0810_iniciais BR.indd 1 11/30/10 5:27 PM6a edição00 elmas0810_iniciais BR.indd 2 11/30/10 5:27 PMRamez ElmasriDepartamento de Ciência da Computação e EngenhariaUniversidade do Texas em ArlingtonShamkant B. NavatheFaculdade de Computação Georgia Institute of TechnologyTradução: Daniel VieiraRevisão técnica: Enzo SeraphimThatyana de Faria Piola SeraphimProfessores Doutores do Instituto de Engenharia de Sistemas e Tecnologias da Informação — Universidade Federal de ItajubáSão PauloBrasil Argentina Colômbia Costa Rica Chile Espanha Guatemala México Peru Porto Rico Venezuela00 elmas0810_iniciais BR.indd 3 11/30/10 5:27 PM6a ediçãoSão PauloBrasil Argentina Colômbia Costa Rica Chile EspanhaGuatemala México Peru Porto Rico Venezuela© 2011 by Pearson Education do Brasil. © 2011, 2007, 2004, 2000, 1994 e 1989 Pearson Education, Inc. Tradução autorizada a partir da edição original, em inglês, Fundamentals of Database Systems, 6th edition, publicada pela Pearson Education, Inc., sob o selo Addison-Wesley. Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de siste-ma de armazenamento e transmissão de informação, sem prévia autorização, por escrito, da Pearson Education do Brasil.Diretor editorial: Roger TrimerGerente editorial: Sabrina CairoSupervisor de produção editorial: Marcelo FrançozoEditora plena: Thelma BabaokaEditora de texto: Sabrina LevensteinasPreparação: Paula Brandão Perez MendesRevisão: Elisa Andrade BuzzoCapa: Thyago Santos sobre o projeto original de Lou Gibbs/Getty ImagesProjeto gráfico e diagramação: Globaltec Artes Gráficas Ltda.Dados Internacionais de Catalogação na Publicação (CIP)(Câmara Brasileira do Livro, SP, Brasil)Elmasri, RamezSistemas de banco de dados / Ramez Elmasri e Shamkant B. Navathe ; tradução Daniel Vieira ; revisão técnica Enzo Seraphim e Thatyana de Faria Piola Seraphim. -- 6. ed. -- São Paulo : Pearson Addison Wesley, 2011.Título original: Fundamentals of database systems.ISBN 978-85-4301-381-71. Banco de dados I. Navathe, Shamkant B..II. Título.10-11462 CDD-005.75Índices para catálogo sistemático:1. Banco de dados : Sistemas : Processamento de dados 005.752. Banco de dados : Fundamentos : Processamento de dados 005.751a reimpressão – setembro 2011Direitos exclusivos para a língua portuguesa cedidos àPearson Education do Brasil,uma empresa do grupo Pearson EducationRua Nelson Francisco, 26 – LimãoCep: 02712-100 São Paulo – SPTel: (11) 2178-8686 – Fax: (11) 2178-8688e-mail: vendas@pearson.com00 elmas0810_iniciais BR.indd 4 9/27/11 2:49 PM2a reimpressão – agosto 2012Direitos exclusivos para a língua portuguesa cedidos àPearson Education do Brasil Ltda.,uma empresa do grupo Pearson EducationRua Nelson Francisco, 26CEP 02712-100 – São Paulo – SP – BrasilFone: 11 2178-8686 – Fax: 11 2178-8688vendas@pearson.com2a reimpressão – junho 2013Direitos exclusivos para a língua portuguesa cedidos àPearson Education do Brasil Ltda.,uma empresa do grupo Pearson EducationRua Nelson Francisco, 26CEP 02712-100 – São Paulo – SP – BrasilFone: (11) 2178-8686 – Fax: (11) 2178-8688vendas@pearson.com3a reimpressão – Julho 2014Direitos exclusivos para a língua portuguesa cedidos àPearson Education do Brasil Ltda.,uma empresa do grupo Pearson EducationRua Nelson Francisco, 26CEP 02712-100 – São Paulo – SP – BrasilFone: (11) 2178-8686 – Fax: (11) 2178-8688vendas@pearson.comPara Katrina, Thomas e Dora (e também para Vicky)R.E.Para minha esposa Aruna, mãe Vijaya e para minha família inteira, por seu amor e apoioS.B.N.00 elmas0810_iniciais BR.indd 5 11/30/10 5:27 PM00 elmas0810_iniciais BR.indd 6 11/30/10 5:27 PMParte 1: Introdução aos bancos de dados ......1Capítulo 1 Bancos de dados e usuários de banco de dados .............................21.1 Introdução ................................................. 21.2 Um exemplo .............................................. 41.3 Características da abordagem de banco de dados ......................................................... 61.4 Atores em cena .......................................... 91.5 Trabalhadores dos bastidores .................. 101.6 Vantagens de usar a abordagem de SGBD 111.7 Uma breve história das aplicações de banco de dados .................................................. 151.8 Quando não usar um SGBD .................... 17Resumo ............................................................ 18Perguntas de revisão ......................................... 18Exercícios ......................................................... 18Bibliografia selecionada .................................... 18Capítulo 2 Conceitos e arquitetura do sistema de banco de dados .....................192.1 Modelos de dados, esquemas e instâncias 192.2 Arquitetura de três esquemas e independência de dados ........................... 222.3 Linguagens e interfaces do banco de dados ... 242.4 O ambiente do sistema de banco de dados .. 262.5 Arquiteturas centralizadas e cliente/servidor para SGBDs ............................................. 292.6 Classificação dos sistemas gerenciadores de banco de dados ........................................ 32Resumo ............................................................ 35Perguntas de revisão ......................................... 36Exercícios ......................................................... 36Bibliografia selecionada .................................... 36Parte 2: Modelo de dados relacional e SQL ..37Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais ................................ 383.1 Conceitos do modelo relacional ............... 393.2 Restrições em modelo relacional e esquemas de bancos de dados relacionais ................ 443.3 Operações de atualização, transações e tratamento de violações de restrição ........ 50Resumo ............................................................ 52Perguntas de revisão ......................................... 53Exercícios ......................................................... 53Bibliografia selecionada .................................... 56Capítulo 4 SQL básica .................................574.1 Definições e tipos de dados em SQL ........ 584.2 Especificando restrições em SQL ............. 614.3 Consultas de recuperação básicas em SQLCCMatemática discretaMAT2410 3 MATBanco de dados CC3380 3 CCTURMAIdentificacao_turmaNumero_disciplinaSemestre Ano Professor85 MAT2410 Segundo 07 Kleber92 CC1310 Segundo 07 Anderson102 CC3320 Primeiro 08 Carlos112 MAT2410 Segundo 08 Chang119 CC1310 Segundo 08 Anderson135 CC3380 Segundo 08 SantosHISTORICO_ESCOLARNumero_aluno Identificacao_turma Nota17 112 B17 119 C8 85 A8 92 A8 102 B8 135 APRE_REQUISITONumero_disciplina Numero_pre_requisitoCC3380 CC3320CC3380 MAT2410CC3320 CC1310Figura 1.2Exemplo de banco de dados que armazena informações de aluno e disciplina.tam o Nome, Numero_aluno, Tipo_aluno (como novato igual a ‘1’, segundo ano igual a ‘2’, e assim por diante) e Curso (como matemática igual a ‘MAT’ e ciência da computação igual a ‘CC’); cada registro de DISCIPLINA Capítulo 1 Bancos de dados e usuários de banco de dados 501 elmas0810_cap01 BR.indd 5 11/30/10 5:24 PMO departamento de Tecnologia da Informação (TI) de uma empresa projeta e mantém um sistema de infor-mações que consiste em vários computadores, siste-mas de armazenamento, software de aplicação e ban-cos de dados. O projeto de uma nova aplicação para um banco de dados existente ou de um novo banco de dados começa com uma fase chamada especificação e análise de requisitos. Esses requisitos são documen-tados com detalhes e transformados em um projeto conceitual, que pode ser representado e manipulado usando algumas ferramentas computadorizadas para que possa ser facilmente mantido, modificado e trans-formado em uma implementação de banco de dados. (Apresentaremos um modelo denominado Entidade--Relacionamento, no Capítulo 7, que é usado para essa finalidade.) O projeto é então traduzido para um projeto lógico, que pode ser expresso em um mode-lo de dados implementado em um SGBD comercial. (Neste livro, vamos enfatizar um modelo de dados conhecido como Modelo de Dados Relacional a par-tir do Capítulo 3. Essa é atualmente a técnica mais popular para projetar e implementar bancos de dados usando SGBDs relacionais.) O estágio final é o projeto físico, durante o qual outras especificações são forne-cidas para armazenar e acessar o banco de dados. O projeto de banco de dados é implementado, alimen-tado com dados reais e mantido continuamente para refletir o estado do minimundo.1.3 Características da abordagem de banco de dadosDiversas características distinguem a abordagem de banco de dados da abordagem muito mais antiga de programação com arquivos. No processamento de arquivo tradicional, cada usuário define e implementa os arquivos necessários para uma aplicação de softwa-re específica como parte da programação da aplicação. Por exemplo, um usuário, o departamento de registro acadêmico, pode manter arquivos sobre os alunos e suas notas. Os programas para imprimir o histórico escolar de um aluno e inserir novas notas são implementados como parte da aplicação. Um segundo usuário, o depar-tamento de finanças, pode registrar as mensalidades dos alunos e seus pagamentos. Embora ambos os usuários estejam interessados em dados sobre alunos, cada um mantém arquivos separados — e programas para mani-pular esses arquivos —, pois cada usuário requer dados não disponíveis nos arquivos do outro. Essa redundância na definição e no armazenamento de dados resulta em desperdício no espaço de armazenamento e em esforços redundantes para manter os dados comuns atualizados.Na abordagem de banco de dados, um único repositório mantém dados que são definidos uma vez e depois acessados por vários usuários. Nos sis-temas de arquivo, cada aplicação é livre para no-mear os elementos de dados independentemente. Ao contrário, em um banco de dados, os nomes ou rótulos de dados são definidos uma vez, e usados re-petidamente por consultas, transações e aplicações. As principais características da abordagem de ban-co de dados versus a abordagem de processamento de arquivo são as seguintes: � Natureza de autodescrição de um sistema de banco de dados. � Isolamento entre programas e dados, e abs-tração de dados. � Suporte de múltiplas visões dos dados. � Compartilhamento de dados e processamen-to de transação multiusuário.Descrevemos cada uma dessas características em uma seção distinta. Discutiremos características adi-cionais dos sistemas de banco de dados nas seções 1.6 a 1.8.1.3.1 Natureza de autodescrição de um sistema de banco de dadosUma característica fundamental da abordagem de banco de dados é que seu sistema contém não apenas o próprio banco de dados, mas também uma definição ou descrição completa de sua estrutura e restrições. Essa definição é armazenada no catálogo do SGBD, que possui informações como a estrutura de cada arquivo, o tipo e o formato de armazena-mento de cada item de dados e diversas restrições so-bre os dados. A informação armazenada no catálogo é chamada de metadados, e descreve a estrutura do banco de dados principal (Figura 1.1).O catálogo é usado pelo software de SGBD e tam-bém pelos usuários do banco de dados que precisam de informações sobre a estrutura do banco de dados. Um pacote de software de SGBD de uso geral não é escrito para uma aplicação de banco de dados específica. Por-tanto, ele precisa consultar o catálogo para conhecer a estrutura dos arquivos em um banco de dados especí-fico, como o tipo e o formato dos dados que ele aces-sará. O software de SGBD precisa trabalhar de forma satisfatória com qualquer quantidade de aplicações de banco de dados — por exemplo, um banco de dados de universidade, de banco ou de uma empresa —, des-de que sua definição esteja armazenada no catálogo.No processamento de arquivos tradicional, a de-finição de dados normalmente faz parte dos próprios programas de aplicação. Logo, esses programas são forçados a trabalhar com apenas um banco de dados específico, cuja estrutura é declarada nos programas de aplicação. Por exemplo, um programa de aplicação 6 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 6 11/30/10 5:24 PMescrito em C++ pode ter declarações de estrutura ou classe, e um programa em COBOL tem instruções da divisão de dados para definir seus arquivos. Enquanto o software de processamento de arquivos pode aces-sar apenas bancos de dados específicos, o software de SGBD pode acessar diversos bancos de dados extraindo e usando as definições do catálogo de banco de dados.Para o exemplo mostrado na Figura 1.2, o catálo-go do SGBD armazenará as definições de todos os ar-quivos mostrados. A Figura 1.3 mostra alguns exem-plos de entradas em um catálogo de banco de dados. Essas definições são especificadas pelo projetista an-tes da criação do banco de dados real e armazenadas no catálogo. Sempre que é feita uma solicitação para acessar, digamos, o Nome de um registro de ALUNO, o software de SGBD consulta o catálogo para deter-minar a estrutura do arquivo ALUNO e a posição e o tamanho do item de dado Nome dentro do registro de ALUNO. Ao contrário, em uma aplicação típica de pro-cessamento de arquivo, a estrutura do arquivo e, no caso extremo, a localização exata do Nome dentro de um registro de ALUNO já estão codificadas dentro de cada programa que acessa esse item de dados.RELACOESNome_relacao Numero_de_colunasALUNO 4DISCIPLINA 4TURMA 5HISTORICO_ESCOLAR 3PRE_REQUISITO 2COLUNASNome_coluna Tipo_de_dado Pertence_a_relacaoNome Caractere (30) ALUNONumero_aluno Caractere (4) ALUNOTipo_aluno Inteiro (1) ALUNOCurso Tipo_curso ALUNONome_disciplina Caractere (10) DISCIPLINANumero_disciplina XXXXNNNN DISCIPLINA.... .... ........ .... ........ .... ....Numero_pre_requisito XXXXNNNN PRE-REQUISITOFigura 1.3Exemplo de um catálogo para o banco de dados na Figura 1.2.Nota: Tipo_curso é definido como um tipo enumerado com todas as matérias conhecidas. XXXXNNNN é usado para definir um tipo com quatro características alfanuméricas seguidas por quatrodígitos.1.3.2 Isolamento entre programas e dados, e abstração de dadosNo processamento de arquivos tradicional, a es-trutura dos arquivos de dados está embutida nos pro-gramas de aplicação, de modo que quaisquer mudan-ças em sua estrutura podem exigir alteração em todos os programas que acessam esse arquivo. Ao contrário, os programas que acessam o SGBD não exigem tais mu-danças na maioria dos casos. A estrutura dos arquivos de dados é armazenada no catálogo do SGBD sepa-radamente dos programas de acesso. Chamamos essa propriedade de independência de dados do programa.Por exemplo, um programa de acesso a arqui-vo pode ser escrito para acessar apenas registros de ALUNO da estrutura mostrada na Figura 1.4. Se quisermos acrescentar outro dado a cada registro de ALUNO, digamos Data_nascimento, esse programa não funcionará mais, e precisará ser alterado. Ao contrário, em um ambiente de SGBD, só precisamos mudar a descrição dos registros de ALUNO no ca-tálogo (Figura 1.3) para refletir a inclusão do novo item de dado Data_nascimento; nenhum programa é alterado. Da próxima vez que o programa de SGBD consultar o catálogo, a nova estrutura dos registros de ALUNO será acessada e usada.Em alguns tipos de sistemas de banco de dados, como os orientados a objeto e objeto-relacional (ver Capítulo 11), os usuários podem definir operações sobre dados como parte das definições do banco de dados. Uma operação (também chamada de função ou método) é especificada em duas partes. A interface (ou assinatura) de uma operação inclui o nome da operação e os tipos de dados de seus argumentos (ou parâmetros). A implementação (ou método) da ope-ração é especificada separadamente e pode ser altera-da sem afetar a interface. Os programas de aplicação do usuário podem operar sobre os dados invocando essas operações por meio de seus nomes e argumen-tos, independentemente de como as operações são implementadas. Isso pode ser chamado de indepen-dência da operação do programa.Nome do item de dadosPosicionamento inicial no registroTamanho em caracteres (bytes)Nome 1 30Numero_aluno 31 4Tipo_aluno 35 1Curso 36 4Figura 1.4Formato de armazenamento interno para um registro de ALUNO, baseado no catálogo do banco de dados da Figura 1.3.Capítulo 1 Bancos de dados e usuários de banco de dados 701 elmas0810_cap01 BR.indd 7 11/30/10 5:24 PMA característica que permite a independência de dados do programa e a independência da operação do programa é chamada de abstração de dados. Um SGBD oferece aos usuários uma representação con-ceitual de dados que não inclui muitos dos detalhes de como os dados são armazenados ou como as ope-rações são implementadas. De maneira informal, um modelo de dados é um tipo de abstração de dados usado para oferecer essa representação conceitual. O modelo de dados usa conceitos lógicos, como obje-tos, suas propriedades e seus inter-relacionamentos, que podem ser mais fáceis para os usuários entende-rem do que os conceitos de armazenamento de com-putador. Logo, o modelo de dados oculta os detalhes de armazenamento e implementação que não são do interesse da maioria dos usuários de banco de dados.Por exemplo, reconsidere as figuras 1.2 e 1.3. A implementação interna de um arquivo pode ser definida por seu tamanho de registro — o número de caracteres (bytes) em cada registro — e cada item de dados pode ser especificado pelo byte inicial dentro de um registro e seu tamanho em bytes. O registro de ALUNO, assim, seria representado como mostra a Figura 1.4. Mas um típico usuário de banco de dados não está preocupado com a localização de cada item de dados dentro de um registro ou em seu tamanho; em vez disso, o usuário se preocupa se o valor é retor-nado corretamente, quando for feita uma referência ao Nome do ALUNO. Uma representação conceitual dos registros de ALUNO aparece na Figura 1.2. Muitos outros detalhes da organização do armazenamento do arquivo — como os caminhos de acesso especificados em um arquivo — podem ser ocultados dos usuários do banco de dados pelo SGBD. Discutiremos detalhes de armazenamento nos capítulos 17 e 18.Na abordagem de banco de dados, a estrutura detalhada e a organização de cada arquivo são arma-zenadas no catálogo. Os usuários do banco de dados e os programas de aplicação se referem à represen-tação conceitual dos arquivos, e o SGBD extrai os detalhes do armazenamento do arquivo do catálogo quando estes são necessários para os módulos de acesso a arquivo do SGBD. Muitos modelos de dados podem ser usados para oferecer essa abstração aos usuários do banco de dados. A primeira parte deste livro é dedicada à apresentação dos vários modelos de dados e dos conceitos que eles utilizam para abs-trair a representação dos dados.Nos bancos de dados orientados a objeto e ob-jeto-relacional, o processo de abstração inclui não apenas a estrutura dos dados, mas também as opera-ções sobre os dados. Essas operações oferecem uma abstração das atividades do minimundo comumente entendidas pelos usuários. Por exemplo, uma ope-ração CALCULA_MEDIA pode ser aplicada ao objeto ALUNO para calcular a média das notas. Essas opera-ções podem ser solicitadas pelas consultas do usuário ou por programas de aplicação sem ter que saber os detalhes de como as operações são implementadas. Nesse sentido, uma abstração da atividade do mi-nimundo se torna disponível ao usuário como uma operação abstrata.1.3.3 Suporte para múltiplas visões dos dadosUm banco de dados em geral tem muitos usuá-rios, cada um podendo exigir um ponto de vista ou visão diferente do banco de dados. Uma visão (ou view) pode ser um subconjunto do banco de dados ou conter dado virtual que é derivado dos arquivos do banco de dados, mas não estão armazenados ex-plicitamente. Alguns usuários não precisam saber se os dados a que se referem estão armazenados ou se são derivados. Um SGBD multiusuário, cujos usuá-rios têm uma série de aplicações distintas, precisa oferecer facilidades para definir múltiplas visões. Por exemplo, um usuário do banco de dados da Figura 1.2 pode estar interessado apenas em acessar e imprimir o histórico escolar de cada aluno; a visão para esse usuário é mostrada na Figura 1.5(a). Um segundo usuário, que está interessado apenas em verificar se os alunos possuem todos os pré-requisitos de cada disciplina para a qual se inscreveram, pode requerer a visão apresentada na Figura 1.5(b).1.3.4 Compartilhamento de dados e processamento de transação multiusuárioUm SGBD multiusuário, como o nome suge-re, precisa permitir que múltiplos usuários acessem o banco de dados ao mesmo tempo. Isso é essencial se o dado para múltiplas aplicações está sendo inte-grado e mantido em um único banco de dados. O SGBD precisa incluir um software de controle de con-corrência para garantir que vários usuários tentan-do atualizar o mesmo dado faça isso de uma maneira controlada, de modo que o resultado dessas atualizações seja correto. Por exemplo, quando vários agentes de via-gem tentam reservar um assento em um voo de uma com-panhia aérea, o SGBD precisa garantir que cada assento só possa ser acessado por um agente de cada vez para que seja atribuído a um único passageiro. Esses tipos de aplicações geralmente são chamados de aplicações de processamen-to de transação on-line (OLPT — On-Line Transaction Processing). Um papel fundamental do software SGBD multiusuário é garantir que as transações concorrentes operem de maneira correta e eficiente.8 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 8 11/30/10 5:24 PMO conceito de transação tem se tornado funda-mental para muitas aplicações de banco de dados. Uma transação é um programa em execução ou processo que inclui um ou mais acessos ao banco de dados, como a leitura ou atualização de seus registros. Uma transação executa um acesso logicamente correto a um banco de dados quando ela é executadade for-ma completa e sem interferência de outras transações. O SGBD precisa impor várias propriedades da tran-sação. A propriedade de isolamento garante que cada transação pareça executar isoladamente das demais, embora centenas de transações possam estar execu-tando concorrentemente. A propriedade de atomicida-de garante que todas as operações em uma transação sejam executadas ou que nenhuma seja. Discutiremos sobre transações em detalhes na Parte 9.As características anteriores são importantes para distinguir um SGBD de um software tradicio-nal de processamento de arquivo. Na Seção 1.6, dis-cutiremos recursos adicionais que caracterizam um SGBD. Primeiro, porém, vamos categorizar os dife-rentes tipos de pessoas que trabalham em um am-biente de sistema de banco de dados.1.4 Atores em cenaPara um pequeno banco de dados pessoal, como a lista de endereços discutida na Seção 1.1, uma pessoa normalmente define, constrói e manipula o banco de dados, sem compartilhamento. Porém, em grandes organizações, muitas pessoas estão en-volvidas no projeto, no uso e na manutenção de um grande banco de dados, com centenas de usuários. Nesta seção, identificamos as pessoas cujas funções envolvem o uso diário de um grande banco de dados; nós os chamamos de atores em cena. Na Seção 1.5, consideraremos as pessoas que podem ser chamadas de trabalhadores dos bastidores — aqueles que tra-balham para manter o ambiente do sistema de banco de dados, mas que não estão ativamente interessados em seu conteúdo como parte de sua função diária.1.4.1 Administradores de banco de dadosEm qualquer organização onde muitas pessoas utilizam os mesmos recursos, há uma necessidade de um administrador principal para supervisionar e ge-renciar tais recursos. Em um ambiente de banco de dados, o recurso principal é o próprio banco de da-dos, e o recurso secundário é o SGBD e os softwares relacionados. A administração desses recursos é de responsabilidade do administrador de banco de da-dos (DBA — database administrator). O DBA é res-ponsável por autorizar o acesso ao banco de dados, coordenar e monitorar seu uso e adquirir recursos de software e hardware conforme a necessidade. Tam-bém é responsável por problemas como falhas na se-gurança e demora no tempo de resposta do sistema. Em grandes organizações, ele é auxiliado por uma equipe que executa essas funções.1.4.2 Projetistas de banco de dadosOs projetistas de banco de dados são responsá-veis por identificar os dados a serem armazenados e escolher estruturas apropriadas para representar e ar-mazenar esses dados. Essas tarefas são realizadas prin-cipalmente antes que o banco de dados esteja real mente implementado e populado com dados. É responsabili-dade dos projetistas de banco de dados se comunicar com todos os potenciais usuários a fim de entender suas necessidades e criar um projeto que as atenda. Em muitos casos, os projetistas estão na equipe de DBAs e podem receber outras responsabilidades após o proje-to do banco de dados estar concluído. Os projetistas de banco de dados normalmente interagem com cada potencial grupo de usuários e desenvolvem visões do banco de dados que cumprem os requisitos de dados e processamento desses grupos. Cada visão é então anali-sada e integrada às visões de outros grupos de usuários. DADO_ESCOLARNome_alunoHistorico_escolar_alunoNumero_disciplinaNota Semestre AnoIdentificacao_turmaSilvah CC1310 C Segundo 08 119MAT2410 B Segundo 08 112Braga MAT2410 A Segundo 07 85CC1310 A Segundo 07 92CC3320 B Primeiro 08 102CC3380 A Segundo 08 135PRE_REQUISITO_DISCIPLINANome_disciplina Numero_disciplina Pre_requisitosBanco de dados CC3380 CC3320MAT2410Estrutura de dados CC3320 CC1310Figura 1.5Duas visões derivadas do banco de dados da Figura 1.2. (a) A visão do HISTORICO_ESCOLAR. (b) A visão do PRE_REQUISITO_DISCIPLINA.(a)(b)Capítulo 1 Bancos de dados e usuários de banco de dados 901 elmas0810_cap01 BR.indd 9 11/30/10 5:24 PMO projeto final do banco de dados precisa ser capaz de atender às necessidades de todos os grupos de usuários.1.4.3 Usuários finaisOs usuários finais são pessoas cujas funções exi-gem acesso ao banco de dados para consultas, atua-lizações e geração de relatórios. O banco de dados existe primariamente para atender os usuários finais. Existem várias categorias de usuários finais: � Usuários finais casuais ocasionalmente aces-sam o banco de dados, mas podem precisar de diferentes informações a cada vez. Utili-zam uma linguagem sofisticada de consulta ao banco de dados para especificar suas ne-cessidades e normalmente são gerentes de nível intermediário ou alto, ou outros usuá-rios ocasionais. � Usuários finais iniciantes ou paramétricos compõem uma grande parte dos usuários finais do banco de dados. Sua função principal gira em torno de consultar e atualizar o banco de dados constantemente, usando tipos padrão de consultas e atualizações — denominadas tran-sações programadas — que foram cuidadosa-mente programadas e testadas. As tarefas que esses usuários realizam são variadas:�� Caixas de banco verificam saldos de conta e realizam saques, depósitos, pagamentos etc.�� Agentes de companhias aéreas, hotéis e locadoras de automóveis verificam a dis-ponibilidade de determinada solicitação e fazem reservas.�� Funcionários nas estações de recebimento de transportadoras inserem identificações de pacotes por códigos de barra e infor-mações descritivas por meio de etiquetas para atualizar um banco de dados central de pacotes recebidos e em trânsito. � Usuários finais sofisticados incluem enge-nheiros, cientistas, analistas de negócios e outros que estão profundamente familiariza-dos com as facilidades do SGBD a ponto de implementar as próprias aplicações para que atendam a suas necessidades complexas. � Usuários isolados mantêm bancos de dados pessoais usando pacotes de programas pron-tos, que oferecem interfaces de fácil utiliza-ção, baseadas em menus ou gráficos. Um exemplo é o usuário de um pacote de cálcu-los de impostos, que armazena uma série de dados financeiros pessoais para fins de decla-ração de imposto.Um SGBD típico oferece múltiplas facilidades para acessar um banco de dados. Usuários iniciantes precisam aprender muito pouco sobre as facilidades oferecidas pelo SGBD; eles simplesmente têm de en-tender as interfaces de usuário das transações padrão projetadas e implementadas para seu uso. Os usu-ários casuais aprendem apenas algumas facilidades que podem usar repetidamente. Usuários sofisticados tentam aprender a maioria das facilidades do SGBD para satisfazer suas necessidades complexas. Usuá-rios isolados costumam se tornar especialistas no uso de um pacote de software específico.1.4.4 Analistas de sistemas e programadores de aplicações (engenheiros de software)Analistas de sistemas identificam as necessidades dos usuários finais, especialmente os iniciantes e pa-ramétricos, e definem as especificações das transações padrão que atendam a elas. Os programadores de aplicações implementam essas especificações como programas; depois, eles testam, depuram, documen-tam e mantêm essas transações programadas. Esses analistas e programadores — também conhecidos como engenheiros de software e desenvolvedores de sistemas de software — devem estar familiarizados com todo o conjunto de capacidades fornecido pelo SGBD para realizarem suas tarefas.1.5 Trabalhadores dos bastidoresAlém daqueles que projetam, usam e adminis-tram um banco de dados, há outros associados ao projeto, desenvolvimento e operação do software e ambiente de sistema do SGBD. Essas pessoas nor-malmente não estão interessadas no conteúdo do banco de dados em si. Vamos chamá-las de traba-lhadores dos bastidores, e elas estão incluídas nas seguintes categorias: � Projetistas e implementadores de sistema de SGBD projetam e implementam os módulos e as interfacesdo SGBD como um pacote de software. Um SGBD é um sistema muito com-plexo, que consiste em muitos componentes, ou módulos, incluindo módulos para imple-mentação do catálogo, processamento de linguagem de consulta, processamento de in-terface, acesso e buffering de dados, controle de concorrência e tratamento de recuperação e segurança de dados. O SGBD precisa reali-zar a interface com outros sistemas de softwa-re, como o sistema operacional, e compilado-res para diversas linguagens de programação.10 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 10 11/30/10 5:24 PM � Desenvolvedores de ferramentas projetam e im-plantam ferramentas — os pacotes de software que facilitam a modelagem e o projeto do ban-co de dados, o projeto do sistema de banco de dados e a melhoria no desempenho. Ferramen-tas são pacotes opcionais que, em geral, são ad-quiridos separadamente. Elas incluem pacotes para projeto de banco de dados, monitoramen-to de desempenho, linguagem natural ou inter-faces gráficas, protótipo, simulação e geração de dados de teste. Em muitos casos, fornecedo-res de software independentes desenvolvem e comercializam essas ferramentas. � Operadores e pessoal de manutenção (pessoal de administração de sistemas) são responsáveis pela execução e manutenção do ambiente de hardwa-re e software para o sistema de banco de dados.Embora essas categorias de trabalhadores dos bastidores sejam instrumento para tornar o sistema de banco de dados disponível aos usuários finais, eles não costumam utilizar o conteúdo do banco de da-dos para fins pessoais.1.6 Vantagens de usar a abordagem de SGBDNesta seção, discutiremos algumas das vanta-gens de usar um bom SGBD e as capacidades que ele deve possuir. Essas capacidades estão além das qua-tro principais características discutidas na Seção 1.3. O DBA deve utilizá-las para cumprir uma série de objetivos relacionados ao projeto, à administração e ao uso de um grande banco de dados multiusuário.1.6.1 Controlando a redundânciaNo desenvolvimento de software tradicional, utilizando processamento de arquivo, cada grupo de usuários mantém os próprios arquivos para trata-mento de suas aplicações de processamento de dados. Por exemplo, considere o exemplo do banco de dados UNIVERSIDADE da Seção 1.2; aqui, dois grupos de usu-ários podem ser o pessoal do departamento de registro acadêmico e departamento de finanças. Na técnica tra-dicional, cada grupo mantém de maneira independente os arquivos sobre os alunos. O departamento finan-ceiro mantém dados sobre o registro e informações relacionadas a faturas, enquanto o departamento de registro acadêmico acompanha as disciplinas e as notas dos alunos. Outros grupos podem duplicar ainda mais alguns ou todos os dados nos próprios arquivos.Essa redundância causada ao armazenar os mesmos dados várias vezes gera diversos problemas. Primeiro, é preciso realizar uma única atualização lógica — como a entrada de dados sobre um novo aluno — várias vezes: uma para cada arquivo onde o dado do aluno é registra-do. Isso ocasiona uma duplicação de esforço. Segundo, o espaço de armazenamento é desperdiçado quando o mes-mo dado é armazenado repetidamente, e esse problema pode ser sério para grandes bancos de dados. Terceiro, os arquivos que representam os mesmos dados podem tornar-se inconsistentes. Isso porque uma atualização é aplicada a alguns dos arquivos, mas não a outros. Mes-mo que uma atualização — como a inclusão de um novo aluno — seja aplicada a todos os arquivos apropriados, os dados referentes ao aluno ainda podem ser inconsis-tentes porque as atualizações são aplicadas de maneira independente pelos grupos de usuários. Por exemplo, um grupo de usuários pode entrar com a data de nascimen-to de um aluno incorretamente como ‘19/01/1988’, en-quanto outros grupos de usuários podem inserir o valor correto ‘29/01/1988’.Na abordagem de banco de dados, as visões de dife-rentes grupos de usuários são integradas durante o pro-jeto. O ideal é que tenhamos um projeto que armazena cada item de dados lógico — como o nome ou a data de nascimento de um aluno — em apenas um lugar no banco de dados. Isso é conhecido como normalização de dados, e garante consistência e economia de espaço de armazenamento (a normalização de dados é descrita na Parte 6 do livro). Porém, na prática, às vezes é ne-cessário usar a redundância controlada para melhorar o desempenho das consultas. Por exemplo, podemos armazenar Nome_aluno e Numero_disciplina redundan-temente em um arquivo HISTORICO_ESCOLAR [Figura 1.6(a)] porque, sempre que recuperamos um registro de HISTORICO_ESCOLAR, queremos recuperar o nome do aluno e o número da disciplina juntamente com a nota, o número do aluno e o identificador de turma. Colocando todos os dados juntos, não precisamos pesquisar vários arquivos para coletar esses dados. Isso é conhecido como desnormalização. Nesses casos, o SGBD deve ter a ca-pacidade de controlar essa redundância a fim de proibir inconsistências entre os arquivos. Isso pode ser feito ve-rificando automaticamente se os valores de Nome_aluno--Numero_aluno em qualquer registro de HISTORICO_ES-COLAR na Figura 1.6(a) combinam com um dos valores de Nome-Numero_aluno de um registro de ALUNO (Fi-gura 1.2). De modo semelhante, os valores de Identifica-cao_turma-Numero_disciplina de HISTORICO_ESCOLAR podem ser verificados em registros de TURMA. Essas ve-rificações podem ser especificadas no SGBD durante o projeto do banco de dados e impostas automaticamente pelo SGBD sempre que o arquivo HISTORICO_ESCO-LAR for atualizado. A Figura 1.6(b) mostra um registro de HISTORICO_ESCOLAR incoerente com o arquivo ALUNO na Figura 1.2; esse tipo de erro pode ser inseri-do se a redundância não for controlada. Você consegue identificar a parte inconsistente?Capítulo 1 Bancos de dados e usuários de banco de dados 1101 elmas0810_cap01 BR.indd 11 11/30/10 5:24 PM1.6.2 Restringindo o acesso não autorizadoQuando vários usuários compartilham um gran-de banco de dados, é provável que a maioria deles não esteja autorizada a acessar todas as informações nele contidas. Por exemplo, dados financeiros normalmen-te são considerados confidenciais, e somente pesso-as autorizadas têm permissão para acessá-los. Além disso, alguns usuários só podem ter permissão para recuperar dados, enquanto outros podem recuperar e atualizar. Logo, o tipo de operação de acesso — re-cuperação ou atualização — também deve ser con-trolado. Em geral, os usuários ou grupos de usuários recebem números de conta protegidos por senhas, que podem usar para acessar o banco de dados. Um SGBD deve oferecer um subsistema de segurança e autoriza-ção, que o DBA utiliza para criar contas e especificar suas restrições. Então, o SGBD deve impor essas res-trições automaticamente. Observe que podemos apli-car controles semelhantes ao software de SGBD. Por exemplo, somente o DBA está autorizado a usar cer-to software privilegiado, como o software para criar contas. De modo semelhante, usuários paramétricos podem ter permissão para acessar o banco de dados apenas por meio de transações programadas predefi-nidas, desenvolvidas para seu uso.1.6.3 Oferecendo armazenamento persistente para objetos do programaOs bancos de dados podem ser usados para ofere-cer armazenamento persistente para objetos e estruturas HISTORICO_ESCOLARNumero_alunoNome_alunoIdentificacao_turmaNumero_disciplinaNota17 Silva 112 MAT2410 B17 Silva 119 CC1310 C8 Braga 85 MAT2410 A8 Braga 92 CC1310 A8 Braga 102 CC3320 B8 Braga 135 CC3380 AHISTORICO_ESCOLARNumero_alunoNome_alunoIdentificacao_turmaNumero_disciplinaNota17 Braga 112 MAT2410 BFigura 1.6Armazenamento redundante de Nome_aluno e Nome_disciplina em HISTORICO_ESCOLAR. (a) Dados consistentes. (b) Registro inconsistente.(a)(b)de dados do programa. Esse é um dos principais motivos para aexistência de sistemas de banco de dados orienta-dos a objeto. Linguagens de programação normalmente possuem estruturas de dados complexas, como tipos de registro em Pascal ou definições de classe em C++ ou Java. Os valores das variáveis de programa ou estrutu-ras dos objetos são descartados quando um programa termina, a menos que o programador os armazene ex-plicitamente em arquivos permanentes, o que, em geral, envolve converter essas estruturas complexas em um formato adequado para armazenamento de arquivo. Quando surge a necessidade de ler esses dados mais uma vez, o programador precisa converter do formato de arquivo para a variável de programa ou estrutura de objeto. Os sistemas de banco de dados orientados a ob-jeto são compatíveis com linguagens de programação, como C++ e Java, e o software de SGBD realiza auto-maticamente quaisquer conversões necessárias. Assim, um objeto complexo em C++ pode ser armazenado de forma permanente em um SGBD orientado a objeto. Esse objeto é considerado persistente, pois sobrevive ao término da execução e pode ser recuperado mais tarde diretamente por outro programa C++.O armazenamento persistente de objetos de pro-grama e estruturas de dados é uma função impor-tante dos sistemas de banco de dados. Os sistemas tradicionais sofrem com frequência do chamado problema de divergência de impedância, pois as es-truturas de dados fornecidas pelo SGBD são incom-patíveis com as estruturas de dados da linguagem de programação. Os sistemas de banco de dados orien-tados a objeto em geral oferecem compatibilidade da estrutura de dados com uma ou mais linguagens de programação orientadas a objeto.1.6.4 Oferecendo estruturas de armazenamento e técnicas de pesquisa para o processamento eficiente de consultaOs sistemas de banco de dados precisam oferecer capacidades para executar consultas e atualizações de modo eficiente. Como o banco de dados costuma ser armazenado em disco, o SGBD precisa oferecer estruturas de dados e técnicas de pesquisa especiali-zadas para agilizar a busca dos registros desejados no disco. Arquivos auxiliares, denominados índices, são usados para essa finalidade. Os índices normalmen-te são baseados em estruturas de dados em árvore ou estrutura de dados em hash, que são modificadas de maneira adequada para a pesquisa no disco. Para processar os registros de banco de dados necessários por uma consulta em particular, eles precisam ser co-piados do disco para a memória principal. Portanto, 12 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 12 11/30/10 5:24 PMo SGBD frequentemente tem um módulo de buffe-ring ou caching que mantém partes do banco de da-dos nos buffers de memória principais. Em geral, o sistema operacional é responsável pelo buffering do disco para a memória. Contudo, como o buffering de dados é essencial para o desempenho do SGBD, a maioria desses sistemas realiza o próprio buffering de dados.O módulo de processamento e otimização de consulta do SGBD é responsável por escolher um plano de execução eficiente para cada consulta, com base nas estruturas de armazenamento existentes. A escolha de quais índices criar e manter faz parte do projeto e ajuste de banco de dados físico, que é uma das responsabilidades da equipe de DBAs. Discutire-mos sobre processamento de consulta, otimização e ajuste na Parte 8 do livro.1.6.5 Oferecendo backup e recuperaçãoUm SGBD precisa oferecer recursos para recupe-rar-se de falhas de hardware ou software. Seu subsis-tema de backup e recuperação é responsável por isso. Por exemplo, se o sistema do computador falhar no meio de uma transação de atualização complexa, o subsistema de recuperação é responsável por garantir que o banco de dados seja restaurado ao estado em que estava antes da transação ser executada. Como alternativa, o subsistema de recuperação poderia ga-rantir que a transação seja reiniciada no ponto em que foi interrompida, de modo que seu efeito com-pleto seja registrado no banco de dados. O backup de disco também é necessário no caso de uma falha de disco catastrófica. Discutiremos a respeito do backup e recuperação no Capítulo 23.1.6.6 Oferecendo múltiplas interfaces do usuárioUma vez que muitos tipos de usuários, com diver-sos níveis de conhecimento técnico, utilizam um banco de dados, um SGBD deve oferecer uma variedade de interfaces de usuário. Essas incluem linguagens de con-sulta para usuários casuais, interfaces de linguagem de programação para programadores de aplicação, formu-lários e códigos de comando para usuários paramétricos e interfaces controladas por menu e de linguagem natu-ral para usuários isolados. As interfaces no estilo de for-mulários e de menus normalmente são conhecidas como interfaces gráficas do usuário (GUIs — Graphical User Interfaces). Existem muitas linguagens e ambientes espe-cializados para especificar GUIs. Recursos para oferecer interfaces GUI para um banco de dados na Web — ou habilitar um banco de dados para a Web — também são muito comuns.1.6.7 Representando relacionamentos complexos entre dadosUm banco de dados pode incluir muitas variedades de dados que estão inter-relacionados de diversas ma-neiras. Considere o exemplo mostrado na Figura 1.2. O registro de ‘Braga’ no arquivo ALUNO está relacio-nado a quatro registros no arquivo HISTORICO_ES-COLAR. De modo semelhante, cada registro de tur-ma está relacionado a um registro de disciplina e a uma série de registros de HISTORICO_ESCOLAR — um para cada aluno que concluiu a turma. Um SGBD pre-cisa ter a capacidade de representar uma série de rela-cionamentos complexos entre os dados, definir novos relacionamentos à medida que eles surgem e recuperar e atualizar dados relacionados de modo fácil e eficaz.1.6.8 Impondo restrições de integridadeA maioria das aplicações de banco de dados possui certas restrições de integridade que devem ser manti-das para os dados. Um SGBD deve oferecer capacida-des para definir e impor tais restrições. O tipo mais sim-ples de restrição de integridade envolve especificar um tipo de dado para cada item de dado. Por exemplo, na Figura 1.3, especificamos que o valor do item de dados Tipo_aluno em cada registro de ALUNO deve ser um in-teiro de um dígito e que o valor de Nome precisa ser um alfanumérico de até 30 caracteres. Para restringir o va-lor de Tipo_aluno entre 1 e 5, seria preciso uma restrição adicional, que não aparece no catálogo atual. Um tipo de restrição mais complexo, que ocorre com frequência, envolve especificar que um registro em um arquivo deve estar relacionado a registros em outros arquivos. Por exemplo, na Figura 1.2, podemos especificar que cada registro de turma deve estar relacionado a um registro de disciplina. Isso é conhecido como restrição de integri-dade referencial. Outro tipo de restrição especifica a ex-clusividade sobre valores de item de dados, como cada registro de disciplina deverá ter um valor exclusivo para Numero_disciplina. Isso é conhecido como uma restri-ção de chave ou singularidade. Tais restrições são derivadas do significado ou da semântica dos dados e do minimundo que eles representam. É responsabilidade dos projetistas do banco de dados identificar restri-ções de integridade durante o projeto. Algumas restrições podem ser especificadas ao SGBD e impostas automa-ticamente. Outras podem ter que ser verificadas por programas de atualização ou no momento da entrada de dados. Em geral, para grandes aplicações, é comum chamar essas restrições de regras de negócio.Um item de dados pode ser inserido erroneamen-te e ainda satisfazer as restrições de integridade espe-cificadas. Por exemplo, se um aluno recebe uma nota ‘A’, mas uma nota ‘C’ é inserida no banco de dados, o SGBD não pode descobrir esse erro automaticamente, Capítulo 1 Bancos de dados e usuários de banco de dados 1301 elmas0810_cap01 BR.indd 13 11/30/10 5:24 PMpois ‘C’ é um valor válidopara o tipo de dados Nota. Es-ses erros de entrada de dados só podem ser descobertos manualmente (quando o aluno recebe a nota e reclama) e corrigidos posteriormente, atualizando o banco de dados. Porém, uma nota ‘Z’ seria rejeitada automati-camente pelo SGBD, pois ‘Z’ não é um valor válido para o tipo de dado Nota. Quando discutirmos cada modelo de dados nos próximos capítulos, vamos apre-sentar regras que pertencem a esse modelo de maneira implícita. Por exemplo, no modelo Entidade-Relaciona-mento, no Capítulo 7, um relacionamento deve envol-ver pelo menos duas entidades. Essas regras são regras inerentes do modelo de dados e assumidas de maneira automática, para garantir a validade do modelo.1.6.9 Permitindo dedução e ações usando regrasAlguns sistemas oferecem capacidades para defi-nir regras de dedução (ou inferência) para deduzir no-vas informações com base nos fatos armazenados no banco de dados. Esses sistemas são chamados de siste-mas de banco de dados dedutivos. Por exemplo, pode haver regras complexas na aplicação do minimundo para determinar quando um aluno está em época de prova. Estas podem ser especificadas declarativamente como regras que, quando compiladas e mantidas pelo SGBD, podem determinar todos os alunos em época de prova. Em um SGBD tradicional, um código de pro-grama de procedimento explícito teria de ser escrito para dar suporte a tais aplicações. Mas, se as regras do minimundo mudarem, geralmente é mais conveniente mudar as regras de dedução declaradas do que reco-dificar programas de procedimento. Nos sistemas de banco de dados relacionais de hoje é possível associar gatilhos (ou triggers) a tabelas. Um gatilho é uma for-ma de regra ativada por atualizações na tabela, que re-sulta na realização de algumas operações adicionais em algumas outras tabelas, envio de mensagens, e assim por diante. Procedimentos mais elaborados para impor regras são popularmente chamados de procedimentos armazenados (ou stored procedures); eles se tornam parte da definição geral de banco de dados e são cha-mados de forma apropriada quando certas condições são atendidas. A funcionalidade mais poderosa é fornecida por sistemas de banco de dados ativos, que oferecem regras ativas que podem automaticamente ini-ciar ações quando ocorrem certos eventos e condições.1.6.10 Implicações adicionais do uso da abordagem de banco de dadosEsta seção discute algumas implicações adicio-nais do uso da abordagem de banco de dados que pode beneficiar a maioria das organizações.Potencial para garantir padrões. A técnica de banco de dados permite que o DBA defina e impo-nha o uso de padrões entre os usuários de banco de dados em uma grande organização. Isso facilita a comunicação e a cooperação entre seus vários depar-tamentos, projetos e usuários dentro da organização. Podem ser definidos padrões para nomes e formatos dos elementos de dados, formatos de exibição, estru-turas de relatório, terminologia, e assim por diante. O DBA pode impor padrões em um ambiente de ban-co de dados centralizado mais facilmente do que em um ambiente onde cada grupo de usuários tem con-trole sobre os próprios arquivos de dados e software.Tempo reduzido para desenvolvimento de aplica-ção Um importante recurso de venda da aborda-gem de banco de dados é que o desenvolvimento de uma nova aplicação — como a recuperação de certos dados para impressão de um novo relatório — leva muito pouco tempo. Projetar e implementar um gran-de banco de dados multiusuário do zero pode levar mais tempo do que escrever uma única aplicação de arquivo especializada. Porém, quando um banco de dados está pronto e funcionando, geralmente é preciso muito menos tempo para criar outras apli-cações usando as facilidades do SGBD. O tempo de desenvolvimento usando um SGBD é estimado como sendo um sexto a um quarto daquele para um siste-ma de arquivo tradicional.Flexibilidade. Pode ser necessário mudar a estrutu-ra de um banco de dados à medida que as necessida-des mudam. Por exemplo, pode aparecer um novo grupo de usuários precisando de informações atual-mente não incluídas no banco de dados. Em resposta, pode ser preciso acrescentar um arquivo ao banco de dados ou estender os elementos de dados em um arquivo existente. Os SGBDs modernos permitem certos tipos de mudanças evolucionárias na estrutura do banco de dados sem afetar os dados armazenados e os programas de aplicação existentes.Disponibilidade de informações atualizadas. Um SGBD torna o banco de dados disponível a todos os usuários. Assim que a atualização de um usuário é aplicada ao banco de dados, todos os outros usuários podem vê-la imediatamente. Essa disponibilidade de informações atualizadas é essencial para muitas apli-cações de processamento de transação, como siste-mas de reserva ou bancos de dados bancários, e ela é possibilitada pelos subsistemas de controle de con-corrência e recuperação de um SGBD.Economias de escala. A técnica de SGBD permite a consolidação de dados e aplicações, reduzindo assim a quantidade de sobreposição desperdiçada entre as ativi-dades do pessoal de processamento de dados em diferen-14 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 14 11/30/10 5:24 PMtes projetos ou departamentos, bem como as redundân-cias entre as aplicações. Isso permite que a organização inteira invista em processadores, dispositivos de arma-zenamento ou mecanismos de comunicação mais pode-rosos, em vez de cada departamento ter de comprar o próprio equipamento (menor desempenho), o que reduz os custos gerais de operação e gerenciamento.1.7 Uma breve história das aplicações de banco de dadosAgora, vamos apresentar uma breve visão his-tórica das aplicações que usam SGBDs e como elas motivaram o desenvolvimento de novos tipos de sis-temas de banco de dados.1.7.1 Antigas aplicações de banco de dados usando sistemas hierárquicos e de redeMuitas aplicações de banco de dados antigas mantinham os registros em grandes organizações, como corporações, universidades, hospitais e bancos. Em muitas delas, existia grande quantidade de regis-tros com estrutura semelhante. Por exemplo, em uma aplicação de universidade, informações semelhantes seriam mantidas para cada aluno, cada disciplina, cada histórico escolar, e assim por diante. Também existiam muitos tipos de registros e muitos inter-rela-cionamentos entre eles.Um dos principais problemas com os sistemas de banco de dados antigos era a mistura de relacio-namentos conceituais com o armazenamento e posi-cionamento físico dos registros no disco. Logo, esses sistemas não ofereciam capacidades suficientes para abstração de dados e independência entre dados e programas. Por exemplo, as notas de determinado aluno poderiam ser armazenadas fisicamente próxi-mas do registro do aluno. Embora isso fornecesse um acesso muito eficiente para as consultas e transações originais com as quais o banco de dados foi proje-tado para lidar, não oferecia flexibilidade suficiente para acessar registros de modo eficiente quando no-vas consultas e transações fossem identificadas. Em particular, novas consultas que exigiam uma organi-zação de armazenamento diferente para o processa-mento eficiente eram muito difíceis de implementar de modo eficaz. Também era muito trabalhoso re-organizar o banco de dados quando eram feitas mu-danças nos requisitos da aplicação.Outra deficiência dos sistemas antigos era que eles ofereciam apenas interfaces da linguagem de progra-mação. Isso tornava demorada e cara a implementação de novas consultas e transações, pois novos programas tinham de ser escritos, testados e depurados. A maioria desses sistemas de banco de dados era implantada em computadores mainframes grandes e caros, começan-do em meados da década de 1960 e continuando nos anos 1970 e 1980. Os principais tipos dos primeiros sistemas eram baseados em três paradigmas princi-pais: sistemas hierárquicos,sistemas baseados em mo-delo de rede e sistemas de arquivo invertidos.1.7.2 Oferecendo abstração de dados e flexibilidade de aplicação com bancos de dados relacionaisOs bancos de dados relacionais foram propostos originalmente para separar o armazenamento físi-co dos dados de sua representação conceitual e para fornecer uma base matemática para a representação e a consulta dos dados. O modelo de dados relacio-nal também introduziu linguagens de consulta de alto nível, que ofereciam uma alternativa às interfaces de linguagem de programação, tornando muito mais rápida a escrita de novas consultas. A representação relacional dos dados é semelhante ao exemplo que apresentamos na Figura 1.2. Os sistemas relacionais visavam inicialmente atender às mesmas aplicações dos sistemas mais antigos, e forneciam flexibilidade para desenvolver rapidamente novas consultas e reor-ganizar o banco de dados à medida que os requisitos mudavam. Logo, a abstração de dados e a independên-cia entre dados e programas eram mais desenvolvidas em comparação com os sistemas anteriores.Os sistemas relacionais experimentais, desen-volvidos no final da década de 1970, e os sistemas de gerenciamento de bancos de dados relacionais (SGBDR), introduzidos na década de 1980, eram muito lentos, pois não usavam ponteiros de armaze-namento físico ou posicionamento de registro para acessar registros de dados relacionados. Com o de-senvolvimento de novas técnicas de armazenamento houve uma melhora no desempenho do processamen-to e otimização de consulta. Por fim, os bancos de da-dos relacionais se tornaram o tipo de sistema de ban-co de dados dominante para aplicações tradicionais. Eles agora existem em quase todos os tipos de com-putadores, desde os menores modelos pessoais até grandes servidores.1.7.3 Aplicações orientadas a objeto e a necessidade de bancos de dados mais complexosO surgimento de linguagens de programação orientadas a objeto no final da década de 1980 e a necessidade de armazenar e compartilhar objetos complexos e estruturados levou ao desenvolvimento Capítulo 1 Bancos de dados e usuários de banco de dados 1501 elmas0810_cap01 BR.indd 15 11/30/10 5:24 PMde Bancos de Dados Orientados a Objeto (BDOOs). Inicialmente, os BDOOs eram considerados um con-corrente dos bancos de dados relacionais, pois forne-ciam estruturas de dados mais gerais. Eles também incorporavam muitos dos paradigmas úteis orien-tados a objeto, como tipos de dados abstratos, en-capsulamento de operações, herança e identidade de objeto. Porém, a complexidade do modelo e a fal-ta de um padrão inicial contribuíram para seu uso limitado. Eles agora são usados principalmente em aplicações especializadas, como projeto de engenha-ria, publicação de multimídia e sistemas de manufa-tura. Apesar das expectativas de que eles causarão um grande impacto, atualmente sua penetração geral no mercado de produtos de banco de dados perma-nece abaixo dos cinco por cento. Além disso, muitos conceitos orientados a objeto foram incorporados nas versões mais recentes dos SGBDs relacionados, levando a sistemas de gerenciamento de banco de da-dos objeto-relacional, conhecidos como SGBDORs.1.7.4 Intercâmbio de dados na Web para comércio eletrônico usando XMLA World Wide Web oferece uma grande rede de computadores interconectados. Os usuários podem criar documentos usando uma linguagem de publi-cação na Web, como HyperText Markup Language (HTML ou, em português, linguagem de marcação de hipertexto), e armazenar esses documentos em ser-vidores Web, onde outros usuários (clientes) podem acessá-los. Os documentos podem ser vinculados por meio de hyperlinks, que são indicadores para outros documentos. Na década de 1990, o comércio eletrô-nico (e-commerce) surgiu como uma importante apli-cação da Web. Rapidamente ficou visível que partes da informação nas páginas Web de e-commerce eram, com frequência, dados extraídos dinamicamente de SGBDs. Diversas técnicas foram desenvolvidas para permitir o intercâmbio de dados na Web. Atualmente, a eXtended Markup Language (XML, em português, linguagem de marcadores extensível) é considerada o principal padrão para intercâmbio entre diversos tipos de bancos de dados e páginas Web. A XML combina conceitos dos modelos usa-dos nos sistemas de documentos com os conceitos de modelagem de banco de dados. O Capítulo 12 é de-dicado à discussão sobre a XML.1.7.5 Estendendo as capacidades do banco de dados para novas aplicaçõesO sucesso dos sistemas de banco de dados nas aplicações tradicionais encorajou os desenvolvedores de outros tipos de aplicações a tentarem utilizá-los. Essas aplicações tradicionalmente usavam suas pró-prias estruturas especializadas de arquivo e dados. Os sistemas de banco de dados agora oferecem ex-tensões para dar melhor suporte às necessidades es-pecializadas para algumas dessas aplicações. A seguir estão alguns exemplos dessas aplicações: � Aplicações científicas que armazenam grande quantidade de dados resultantes de experi-mentos científicos em áreas como a física de alta energia, o mapeamento do genoma huma-no e a descoberta de estruturas de proteínas. � Armazenamento e recuperação de imagens, in-cluindo notícias escaneadas e fotografias pes-soais, imagens fotográficas de satélite e ima-gens de procedimentos médicos, como raios X e IRMs (imagens por ressonância magnética). � Armazenamento e recuperação de vídeos, como filmes, e clipes de vídeo de notícias ou de câmeras digitais pessoais. � Aplicações de mineração de dados (ou data mining), que analisam grande quantidade de dados procurando as ocorrências de padrões ou relacionamentos específicos, e identifica-ção de padrões incomuns em áreas como uso de cartão de crédito. � Aplicações espaciais, que armazenam a loca-lização espacial de dados, como informações de clima, mapas usados em sistemas de infor-mações geográficas e em sistemas de navega-ção de automóveis. � Aplicações de série temporais, que armaze-nam informações como dados econômicos em pontos regulares no tempo, como vendas diárias e valores mensais do Produto Interno Bruto (PIB).Logo ficou aparente que os sistemas relacionais básicos não eram muito adequados para muitas des-sas aplicações, em geral por um ou mais dos seguin-tes motivos: � Estruturas de dados mais complexas eram ne-cessárias para modelar a aplicação do que a representação relacional simples. � Novos tipos de dados eram necessários além dos tipos básicos numéricos e alfanuméricos. � Novas operações e construtores de linguagem de consulta eram necessários para manipular os novos tipos de dados. � Novas estruturas de armazenamento e inde-xação eram necessárias para a pesquisa efi-ciente sobre os novos tipos de dados.16 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 16 11/30/10 5:24 PMIsso levou os desenvolvedores de SGBD a acres-centarem funcionalidade a seus sistemas. Alguma funcionalidade era de uso geral, como a incorporação de conceitos dos bancos de dados orientados a objeto aos sistemas relacionais. Outras eram de uso espe-cial, na forma de módulos opcionais que poderiam ser usados para aplicações específicas. Por exemplo, os usuários poderiam comprar um módulo de séries temporal para usar com seu SGBD relacional para aplicações de séries temporais.Muitas organizações de grande porte utilizam vários pacotes de aplicação de software que trabalham intimamente com o banco de dados de back-ends. O banco de dados do back-end. representa um ou mais bancos de dados, possivelmente de diferentes forne-cedores e usando diferentes modelos de dados, que mantêm dados manipulados por esses pacotes para dar suporte a transações, gerar relatórios e responder a consultas ocasionais. Um dos sistemas mais utili-zados inclui o ERP (Enterprise Resource Planning, planejamento de recursos empresariais), que serve para consolidar diversas áreas funcionaisdentro de uma organização, incluindo produção, vendas, dis-tribuição, marketing, finanças, recursos humanos, e assim por diante. Outro tipo de sistema popular é o CRM (Customer Relationship Management, gerenciamento do relacionamento com o cliente), que compreende funções de processamento de pe-dido, bem como marketing e suporte ao cliente. Essas aplicações são habilitadas para Web porque usuários internos e externos recebem uma série de interfaces de portal Web para interagir com os ban-cos de dados de back-end.1.7.6 Bancos de dados versus recuperação de informaçõesTradicionalmente, a tecnologia de banco de dados se aplica a dados estruturados e formatados, que surgem em aplicações de rotina no governo, no comércio e na indústria. Ela é bastante utilizada nos setores de manufatura, varejo, bancos, seguros, finanças e saúde, onde dados estruturados são co-letados por meio de formulários, como faturas ou documentos de registro de paciente. Uma área rela-cionada à tecnologia de banco de dados é a Recupe-ração de Informação (RI), que lida com livros, ma-nuscritos e diversas formas de artigos baseados em biblioteca. O dado é indexado, catalogado e anotado usando palavras-chave. A RI está relacionada à bus-ca por conteú do com base nessas palavras-chave e a muitos problemas que lidam com processamento de documento e processamento de texto em forma livre. Muito trabalho tem sido feito sobre busca em texto baseada em palavras-chave, localização de do-cumentos e sua classificação conforme a relevância, categorização automática de texto, classificação de documentos de texto por tópicos, e assim por diante. Com o advento da Web e a proliferação de páginas HTML na faixa dos bilhões, é preciso aplicar muitas técnicas de RI para processar os dados na Web. Os dados dessas páginas normalmente contêm imagens, texto e objetos que são ativos e mudam de maneira dinâmica. A recuperação de informações na Web é um problema novo que exige que técnicas de bancos de dados e RI sejam aplicadas a uma série de combi-nações novas. Discutiremos os conceitos relaciona-dos à recuperação de informações e páginas Web no Capítulo 27.1.8 Quando não usar um SGBDApesar das vantagens de usar um SGBD, existem algumas situações em que esse sistema pode envolver custos adicionais desnecessários, que não acontece-riam no processamento de arquivos tradicional. Os custos adicionais do uso de um SGBD devem-se aos seguintes fatores: � Alto investimento inicial em hardware, software e treinamento. � A generalidade que um SGBD oferece para a definição e o processamento de dados. � Esforço adicional para oferecer funções de segurança, controle de concorrência, recupe-ração e integridade.Portanto, pode ser mais desejável usar arquivos comuns sob as seguintes circunstâncias: � Aplicações de banco de dados simples e bem definidas, para as quais não se espera muitas mudanças. � Requisitos rigorosos, de tempo real, para al-guns programas de aplicação, que podem não ser atendidos devido as operações extras exe-cutadas pelo SGBD. � Sistemas embarcados com capacidade de ar-mazenamento limitada, onde um SGBD de uso geral não seria apropriado. � Nenhum acesso de múltiplos usuários aos dados.Certos setores e aplicações decidiram não utili-zar SGBDs de uso geral. Por exemplo, muitas ferra-mentas de projeto auxiliado por computador (CAD) usadas por engenheiros civis e mecânicos possuem software proprietário para gerenciamento de arqui-vos e dados, preparado para as manipulações inter-nas dos desenhos e objetos 3D. De modo semelhante, sistemas de comunicação e comutação projetados por empresas como a AT&T foram manifestações Capítulo 1 Bancos de dados e usuários de banco de dados 1701 elmas0810_cap01 BR.indd 17 11/30/10 5:24 PMiniciais do software de banco de dados preparado para executar de forma muito rápida com dados or-ganizados hierarquicamente, para agilizar o acesso e o roteamento das chamadas. De modo semelhante, implementações dos sistemas de informações geo-gráficas (SIG) normalmente usam os próprios esque-mas de organização de dados, a fim de implantar, de modo eficiente, funções relacionadas a processamen-to de mapas, contornos físicos, linhas, polígonos, e assim por diante. Os SGBDs de uso geral são inade-quados para essa finalidade.ResumoNeste capítulo, definimos um banco de dados como uma coleção de dados relacionados, onde dados signifi-cam fatos gravados. Um banco de dados típico represen-ta algum aspecto do mundo real e é usado para fins es-pecíficos por um ou mais grupos de usuários. Um SGBD é um pacote de software generalizado para implementar e manter um banco de dados computadorizado. Juntos, o banco de dados e o software formam um sistema de banco de dados. Identificamos várias características que distinguem a técnica de banco de dados das aplicações tradicionais de processamento de arquivo, e discutimos as principais categorias de usuários de banco de dados, ou os atores em cena. Observamos que, além dos usuá-rios em ambiente de banco de dados, existem várias ca-tegorias de pessoal de suporte, ou trabalhadores de bas-tidores, em um ambiente de banco de dados.Apresentamos uma lista de capacidades que devem ser fornecidas pelo software de SGBD ao DBA, aos pro-jetistas de banco de dados e aos usuários finais para aju-dá-los a projetar, administrar e usar um banco de dados. Depois, mostramos uma rápida perspectiva histórica da evolução das aplicações de banco de dados. Indicamos o casamento da tecnologia de banco de dados com a tecno-logia da recuperação de informações, que desempenhará um papel importante devido à popularidade da Web. Fi-nalmente, discutimos os custos adicionais do uso de um SGBD e algumas situações em que sua utilização pode não ser vantajosa.Perguntas de revisão 1.1. Defina os seguintes termos: dados, banco de da-dos, SGBD, sistema de banco de dados, catálogo de banco de dados, independência entre dados e programas, visão do usuário, DBA, usuário fi-nal, transação programada, sistema de banco de dados dedutivo, objeto persistente, metadados e aplicação para processamento de transação. 1.2. Quais os quatro tipos principais de ações que envolvem bancos de dados? Discuta cada tipo rapidamente. 1.3. Discuta as principais características da aborda-gem de banco de dados e como ela difere dos sistemas de arquivo tradicionais. 1.4. Quais são as responsabilidades do DBA e dos projetistas de banco de dados? 1.5. Quais são os diferentes tipos de usuários finais de banco de dados? Discuta as principais ativi-dades de cada um. 1.6. Discuta as capacidades que devem ser fornecidas por um SGBD. 1.7. Discuta as diferenças entre sistemas de banco de dados e sistemas de recuperação de informações.Exercícios 1.8. Identifique algumas operações informais de con-sulta e atualização que você esperaria aplicar ao banco de dados mostrado na Figura 1.2. 1.9. Qual é a diferença entre redundância controlada e não controlada? Dê exemplos. 1.10. Especifique todos os relacionamentos entre os re-gistros do banco de dados mostrado na Figura 1.2. 1.11. Mostre algumas visões adicionais que podem ser necessárias a outros grupos de usuários do ban-co de dados mostrado na Figura 1.2. 1.12. Cite alguns exemplos de restrições de integrida-de que você acredita que possam se aplicar ao banco de dados mostrado na Figura 1.2. 1.13. Dê exemplos de sistemas em que pode fazer sen-tido usar o processamento de arquivos tradicio-nal em vez da técnica de banco de dados. 1.14. Considere a Figura 1.2.a. Se o nome do departamento ‘CC’ (Ciência da computação) mudar para ‘CCES’ (Ciência da computação e engenharia de software) e o prefixo correspondente para o número da disciplina também mudar, identifique as co-lunas no banco de dados que precisariam ser atualizadas.b. Você consegue reestruturar as colunas nas ta-belas DISCIPLINA, TURMA e PRE_REQUISI-TO demodo que somente uma delas precise de atualização?Bibliografia selecionadaA edição de outubro de 1991 de Communications of the ACM e Kim (1995) incluem vários artigos que des-crevem SGBDs da próxima geração. Muitos dos recursos de banco de dados discutidos no início agora estão dis-poníveis comercialmente. A edição de março de 1976 de ACM Computing Surveys oferece uma introdução aos sistemas de banco de dados, e pode fornecer uma pers-pectiva histórica para o leitor interessado.18 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 18 11/30/10 5:24 PMA arquitetura dos SGBDs tem evoluído desde os primeiros sistemas monolíticos, nos quais todo o software SGBD era um sistema altamente integrado, até os mais modernos, que têm um projeto modu-lar, com arquitetura de sistema cliente/servidor. Essa evolução espelha as tendências na computação, em que grandes computadores mainframes centralizados estão sendo substituídos por centenas de estações de trabalho distribuídas e computadores pessoais, co-nectados por redes de comunicações a vários tipos de máquinas servidoras — servidores Web, servido-res de banco de dados, servidores de arquivos, servi-dores de aplicações, e assim por diante.Em uma arquitetura básica de SGBD cliente/servidor a funcionalidade do sistema é distribuída entre dois tipos de módulos.1 O módulo cliente nor-malmente é projetado para executar em uma esta-ção de trabalho ou computador pessoal. Em geral, os programas de aplicação e interfaces com o usuário que acessam o banco de dados executam no módulo cliente. Logo, esse módulo se encarrega da intera-ção do usuário e oferece interfaces amigáveis, como formulários ou GUIs (interfaces gráficas do usuário) baseadas em menu. O outro tipo de módulo, cha-mado módulo servidor, é normalmente responsável pelo armazenamento de dados, acesso, pesquisa e ou-tras funções. Discutiremos sobre arquiteturas cliente/servidor com mais detalhes na Seção 2.5. Primeiro, temos de estudar mais os conceitos básicos, que nos darão um melhor conhecimento das arquiteturas de banco de dados modernas.Neste capítulo, apresentamos a terminologia e os conceitos básicos que serão usados no decorrer do livro. A Seção 2.1 discute os modelos de dados e de-fine os conceitos de esquemas e instâncias, que são fundamentais para o estudo dos sistemas de banco de dados. Depois, discutimos a arquitetura do SGBD de três esquemas e a independência de dados na Se-ção 2.2; isso oferece um ponto de vista do usuário sobre o que um SGBD deve realizar. Na Seção 2.3, descrevemos os tipos de interfaces e linguagens que, normalmente, são fornecidas por um SGBD. A Seção 2.4 discute o ambiente do software de um sistema de banco de dados. A Seção 2.5 oferece uma visão geral de vários tipos de arquiteturas cliente/servidor. Finalmente, a Seção 2.6 apresenta uma classificação dos tipos de pacotes de SGBD. No final do capítulo é apresentado um resumo.O material nas seções 2.4 a 2.6 oferece conceitos mais detalhados, que podem ser considerados suple-mentares ao material introdutório básico.2.1 Modelos de dados, esquemas e instânciasUma característica fundamental da abordagem de banco de dados é que ela oferece algum nível de abstração de dados. A abstração de dados, geral-mente, se refere à supressão de detalhes da organiza-ção e armazenamento dos dados, destacando recur-sos essenciais para um melhor conhecimento desses dados. Uma das principais características da abor-dagem de banco de dados é possibilitar a abstração de dados, de modo que diferentes usuários possam percebê-los em seu nível de detalhe preferido. Um modelo de dados — uma coleção de conceitos que podem ser usados para descrever a estrutura de um banco de dados — oferece os meios necessários para 1 Conforme veremos na Seção 2.5, existem variações sobre essa simples arquitetura cliente/servidor em duas camadas.capítulo 2Conceitos e arquitetura do sistema de banco de dados02 elmas0810_cap02 BR.indd 19 11/30/10 5:23 PMde dados representativos (ou de implementação),4 que oferece conceitos que podem ser facilmente entendidos pelos usuários finais, mas que não está muito longe do modo como os dados são organizados e armazenados no computador. Modelos de dados representativos ocultam muitos detalhes do armazenamento de dados em disco, mas podem ser implementados diretamente em um sistema de computador.Os modelos de dados conceituais utilizam con-ceitos como entidades, atributos e relacionamentos. Uma entidade representa um objeto ou conceito do mundo real, como um funcionário ou um projeto do minimundo que é descrito no banco de dados. Um atributo representa alguma propriedade de interesse que descreve melhor uma entidade, como o nome ou o salário do funcionário. Um relacionamento entre duas ou mais entidades representa uma associação entre elas — por exemplo, um relacionamento traba-lha-em entre um funcionário e um projeto. O Capítu-lo 7 apresentará o modelo Entidade-Relacionamen-to — um modelo de dados conceitual popular de alto nível. O Capítulo 8 descreverá abstrações adicionais usadas para a modelagem avançada, como generali-zação, especialização e categorias (tipos de união).Os modelos de dados representativos ou de im-plementação são os usados com mais frequência nos SGBDs comerciais tradicionais. Estes incluem o am-plamente utilizado modelo de dados relacional, bem como os chamados modelos de dados legados — os modelos de rede e hierárquicos — que foram bastante usados no passado. A Parte 2 é dedicada ao modelo de dados relacional e suas restrições, operações e lingua-gens.5 O padrão SQL para bancos de dados relacionais será descrito nos capítulos 4 e 5. Os modelos de dados representativos mostram os dados usando estruturas de registro e, portanto, às vezes são denominados mo-delos de dados baseados em registro.Podemos considerar o modelo de dados de objeto como um exemplo de uma nova família de modelos de dados de implementação de nível mais alto e que são mais próximos dos modelos de dados conceituais. Um padrão para bancos de dados de objeto, cha-mado modelo de objeto ODMG, foi proposto pelo grupo de gerenciamento de dados objeto (ODMG — Object Data Management Group). O Capítulo 11 descreve as características gerais dos bancos de da-dos de objeto e o padrão proposto do modelo de alcançar essa abstração.2 Com estrutura de um ban-co de dados, queremos dizer os tipos, relacionamen-tos e restrições que se aplicam aos dados. A maioria dos modelos de dados também inclui um conjunto de operações básicas para especificar recuperações e atualizações no banco de dados.Além das operações básicas fornecidas pelo modelo de dados, está se tornando mais comum incluir conceitos no modelo de dados para espe-cificar o aspecto dinâmico ou comportamento de uma aplicação de banco de dados. Isso permite ao projetista do banco de dados especificar um con-junto de operações válidas, definidas pelo usuário, sobre os objetos do banco de dados.3 Um exemplo de uma operação definida pelo usuário poderia ser CALCULA_MEDIA, que pode ser aplicada a um objeto ALUNO. Por sua vez, operações genéricas para inse-rir, excluir, modificar ou recuperar qualquer tipo de objeto normalmente estão incluídas nas operações básicas do modelo de dados. Conceitos para espe-cificar o comportamento são fundamentais para os modelos de dados orientados a objeto (ver Capítu-lo 11), mas também estão sendo incorporados em modelos de dados mais tradicionais. Por exemplo, mo-delos objeto-relacional (ver Capítulo 11) estendem o modelo relacional básico para incluir tais conceitos, entre outros. No modelo de dados relacional básico, existe um recurso para conectar um comportamento às relações, na forma de módulos de armazenamen-to persistente, popularmente conhecidos como pro-cedimentos armazenados ou stored procedures (ver Capítulo 13).2.1.1 Categorias de modelos de dadosMuitos modelosde dados foram propostos, e po-demos classificá-los de acordo com os tipos de conceitos que eles utilizam para descrever a estrutura do banco de dados. Modelos de dados de alto nível ou concei-tuais oferecem conceitos que são próximos ao modo como muitos usuários percebem os dados, enquanto os modelos de dados de baixo nível ou físicos oferecem conceitos que descrevem os detalhes de como os dados são armazenados no computador, em geral, em discos magnéticos. Os conceitos oferecidos pelos modelos de dados de baixo nível costumam ser voltados para es-pecialistas de computadores, não para usuários finais. Entre esses dois extremos está uma classe de modelos 2 Às vezes, a palavra modelo é usada para indicar uma descrição de banco de dados específica, ou esquema — por exemplo, o modelo de dados de marketing. Não usaremos essa interpretação.3 A inclusão de conceitos para descrever um comportamento reflete uma tendência por meio da qual as atividades do projeto do banco de dados e do projeto de software estão, cada vez mais, sendo combinadas em uma única atividade. Tradicionalmente, especificar um comportamento é algo associado ao projeto de software.4 O termo modelo de dados de implementação não é um termo padrão; ele foi apresentado para nos referirmos aos modelos de dados disponíveis nos sistemas de banco de dados comerciais.5 Um resumo dos modelos de dados hierárquico e de rede consta dos apêndices D e E (em inglês). Eles podem ser acessados no site de apoio do livro.20 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 20 11/30/10 5:23 PMobjeto. Os modelos de dados de objeto também são frequentemente utilizados como modelos conceitu-ais de alto nível, em particular no domínio da enge-nharia de software.Os modelos de dados físicos descrevem o arma-zenamento dos dados como arquivos no computa-dor, com informações como formatos de registro, ordenações de registro e caminhos de acesso. Um caminho de acesso é uma estrutura que torna efi-ciente a busca por registros de um banco de dados em particular. Discutiremos as técnicas de armaze-namento físico e as estruturas de acesso nos capítu-los 17 e 18. Um índice é um exemplo de um cami-nho que permite o acesso direto aos dados usando um termo de índice ou uma palavra-chave. Ele é semelhante ao índice no final deste livro, com a ex-ceção de que pode ser organizado de forma linear, hierárquica (estruturada em árvore) ou de alguma outra maneira.2.1.2 Esquemas, instâncias e estado do banco de dadosEm qualquer modelo de dados, é importante distinguir entre a descrição do banco de dados e o próprio banco de dados. Tal descrição é chamada de esquema do banco de dados, que é especificado durante o projeto do banco de dados e não se espera que mude com frequência.6 A maioria dos modelos de dados tem certas convenções para representar es-quemas como diagramas.7 A representação de um esquema é chamada de diagrama de esquema. A Fi-gura 2.1 mostra um diagrama de esquema para o banco de dados da Figura 1.2; o diagrama apresenta a estrutura de cada tipo de registro, mas não as ins-tâncias reais dos registros. Chamamos cada objeto no esquema — por exemplo, ALUNO ou DISCIPLINA — de construtor do esquema.Um diagrama de esquema representa apenas al-guns aspectos de um esquema, como os nomes de ti-pos de registro e itens de dados, e alguns tipos de res-trições. Outros aspectos não são especificados nele; por exemplo, a Figura 2.1 não mostra nem o tipo de dado de cada item de dados nem os relacionamentos entre os diversos arquivos. Muitos tipos de restrições não são apresentados nos diagramas de esquema. Uma restrição do tipo alunos prestes a se formarem em ciência da computação precisam realizar o curso CC1310 antes do final de seu segundo ano é muito difícil de representar em forma de diagrama.Os dados reais armazenados em um banco de dados podem mudar com muita frequência. Por exemplo, o banco de dados mostrado na Figura 1.2 muda toda vez que acrescentamos um novo aluno ou inserimos uma nova nota. Os dados no banco de da-dos em determinado momento no tempo são chama-dos de estado ou instante do banco de dados. Tam-bém são chamados de conjunto atual de ocorrências ou instâncias no banco de dados. Em determinado estado do banco de dados, cada construtor de es-quema tem o próprio conjunto de instâncias atuais; por exemplo, o construtor ALUNO terá o conjunto de entidades de cada aluno (registros) como suas ins-tâncias. Muitos estados de banco de dados podem ser construídos para corresponder a um esquema de banco de dados em particular. Toda vez que inseri-mos ou excluímos um registro ou alteramos o valor de um item de dados em um registro, mudamos de um estado do banco de dados para outro.A distinção entre esquema e estado de banco de dados é muito importante. Quando definimos um novo banco de dados, especificamos seu esquema ape-nas para o SGBD. Nesse ponto, o estado do banco de dados correspondente é o estado vazio, sem dados. Obtemos o estado inicial do banco de dados quando ele é populado ou carregado com os dados iniciais. Daí em diante, toda vez que uma operação de atualização 6 Mudanças no esquema normalmente são necessárias à medida que os requisitos das aplicações do banco de dados mudam. Sistemas de banco de dados mais novos incluem operações para permitir mudanças de esquema, embora esse processo seja mais complicado do que as simples atualizações no banco de dados.7 Em terminologia de banco de dados, em inglês, é comum usar schemas como plural para schema, embora schemata seja a forma no plural apropriada. A palavra scheme também é usada para se referir a um esquema.ALUNONome Numero_aluno Tipo_aluno CursoDISCIPLINANome_disciplinaNumero_disciplinaCreditos DepartamentoPRE_REQUISITONumero_disciplina Numero_pre_requisitoTURMAIdentificacao_turmaNumero_disciplinaSemestre Ano ProfessorHISTORICO_ESCOLARNumero_aluno Identificacao_turma NotaFigura 2.1Diagrama de esquema para o banco de dados da Figura 1.2.Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 2102 elmas0810_cap02 BR.indd 21 11/30/10 5:23 PMé aplicada, obtemos outro estado do banco de dados. Em qualquer ponto no tempo, o banco de dados tem um estado atual.8 O SGBD é parcialmente responsável por garantir que todo estado do banco de dados seja um estado válido — ou seja, um estado que satisfaça a estrutura e as restrições especificadas no esquema. Logo, especificar um esquema correto para o SGBD é extremamente importante, e o esquema deve ser pro-jetado com extremo cuidado. O SGBD armazena as descrições das construções e restrições do esquema — também denominadas metadados — no catálogo do SGBD, de modo que o software do SGBD possa re-correr ao esquema sempre que precisar. O esquema às vezes é chamado de intenção, e um estado do banco de dados é chamado de extensão do esquema.Embora, como já mencionamos, o esquema não deva mudar com frequência, não é raro que as mu-danças, ocasionalmente, precisem ser aplicadas ao esquema, à medida que os requisitos da aplicação mudam. Por exemplo, podemos decidir que outro item de dados precisa ser armazenado para cada registro em um arquivo, como a inclusão de Data_nascimento ao esquema ALUNO da Figura 2.1. Isso é conhecido como evolução do esquema. A maioria dos SGBDs modernos possui algumas operações para evolução de esquema que podem ser aplicadas en-quanto o banco de dados está em funcionamento.2.2 Arquitetura de três esquemas e independência de dadosTrês das quatro características importantes da abordagem de banco de dados, listadas na Seção 1.3, são (1) uso de um catálogo para armazenar a descri-ção (esquema) do banco de dados de modo a torná-lo autodescritivo, (2) isolamento de programas e dados (independência entre dados do programa e operação do programa) e (3) suporte para múltiplas visões do usuário. Nesta seção, especificamos uma arquitetura para sistemas..634.4 Instruções INSERT, DELETE e UPDATE em SQL ................................................... 704.5 Recursos adicionais da SQL .................... 72Resumo ............................................................ 73Perguntas de revisão ......................................... 73Exercícios ......................................................... 74Bibliografia selecionada .................................... 75Capítulo 5 Mais SQL: Consultas complexas, triggers, views e modificação de esquema ................................... 765.1 Consultas de recuperação SQL mais complexas ............................................... 76Sumário00 elmas0810_iniciais BR.indd 7 11/30/10 5:27 PM5.2 Especificando restrições como asserções e ações como triggers ................................. 875.3 Visões (views) — Tabelas virtuais em SQL ..885.4 Instruções de alteração de esquema em SQL ..91Resumo ............................................................ 92Perguntas de revisão ......................................... 93Exercícios ......................................................... 94Bibliografia selecionada .................................... 94Capítulo 6 Álgebra e cálculo relacional ....... 966.1 Operações relacionais unárias: SELEÇÃO e PROJEÇÃO ............................................. 976.2 Operações de álgebra relacional com base na teoria dos conjuntos .............................. 1016.3 Operações relacionais binárias: JUNÇÃO e DIVISÃO ................................................ 1056.4 Outras operações relacionais ................. 1106.5 Exemplos de consultas na álgebra relacional ............................................... 1156.6 O cálculo relacional de tupla ................. 1166.7 O cálculo relacional de domínio ............ 123Resumo .......................................................... 124Perguntas de revisão ....................................... 125Exercícios ....................................................... 125Exercícios de laboratório ............................... 128Bibliografia selecionada .................................. 129Parte 3: Modelagem conceitual e projeto de banco de dados ...........................130Capítulo 7 Modelagem de dados usando o modelo Entidade-Relacionamento (ER) .......................................... 1317.1 Usando modelos de dados conceituais de alto nível para o projeto do banco de dados ... 1327.2 Exemplo de aplicação de banco de dados ..1337.3 Tipos de entidade, conjuntos de entidades, atributos e chaves .................................. 1347.4 Tipos e conjuntos de relacionamentos, papéis e restrições estruturais ................ 1407.5 Tipos de entidade fraca .......................... 1447.6 Refinando o projeto de ER para o banco de dados EMPRESA ................................... 1457.7 Diagramas ER, convenções de nomes e questões de projeto ................................ 1467.8 Exemplo de outra notação: diagramas de classes UML .......................................... 1487.9 Tipos de relacionamento de grau maior que dois ....................................................... 151Resumo .......................................................... 154Perguntas de revisão ....................................... 154Exercícios ....................................................... 155Exercícios de laboratório ............................... 159Bibliografia selecionada .................................. 160Capítulo 8 O modelo Entidade-Relacionamento Estendido (EER) ..........................1618.1 Subclasses, superclasses e herança ......... 1628.2 Especialização e generalização ............... 1638.3 Restrições e características das hierarquias de especialização e generalização ........... 1658.4 Modelagem dos tipos UNIAO usando categorias .............................................. 1708.5 Um exemplo de esquema UNIVERSIDADE de EER, opções de projeto e definições formais .................................................. 1728.6 Exemplo de outra notação: representando especialização e generalização em diagramas de classes em UML ................................ 1758.7 Conceitos de abstração de dados, representação do conhecimento e ontologia...................... 176Resumo .......................................................... 181Perguntas de revisão ....................................... 181Exercícios ....................................................... 181Exercícios de laboratório ............................... 186Bibliografia selecionada .................................. 188Capítulo 9 Projeto de banco de dados relacional por mapeamento ER e EER para relacional ..................1899.1 Projeto de banco de dados relacional usando o mapeamento ER para relacional ......... 1899.2 Mapeando construções do modelo EER para relações ................................................. 195Resumo .......................................................... 198Perguntas de revisão ....................................... 199Exercícios ....................................................... 199Exercícios de laboratório ............................... 200Bibliografia selecionada .................................. 200Capítulo 10 Metodologia prática de projeto de banco de dados e uso de diagramas UML ......................20110.1 O papel dos sistemas de informação nas organizações ........................................ 20210.2 O projeto de banco de dados e o processo de implementação ................................ 205viii Sistemas de banco de dados00 elmas0810_iniciais BR.indd 8 11/30/10 5:27 PM10.3 Uso de diagramas UML como recurso para especificação de projeto de banco de dados ................................................... 21910.4 Rational Rose: uma ferramenta de projeto baseada em UML ................................ 22510.5 Ferramentas de projeto automatizado de banco de dados .................................... 229Resumo .......................................................... 231Perguntas de revisão ....................................... 232Bibliografia selecionada .................................. 233Parte 4: Objeto, objeto-relacional e XML: conceitos, modelos, linguagens e padrões .......................................235Capítulo 11 Bancos de dados de objeto e objeto-relacional .................... 23611.1 Visão geral dos conceitos de banco de dados de objeto ................................... 23711.2 Recursos objeto-relacional: extensões do banco de dados de objeto para SQL .... 24711.3 O modelo de objeto ODMG e a Object Definition Language (ODL) ................. 25211.4 Projeto conceitual de banco de dados de objeto .................................................. 26711.5 A linguagem de consulta de objeto (OQL — Object Query Language) ................. 26911.6 Visão geral de binding da linguagem C++ no padrão ODMG ............................... 275Resumo .......................................................... 276Perguntas de revisão ....................................... 277Exercícios ....................................................... 277Bibliografia selecionada .................................. 278Capítulo 12 XML: Extensible Markup Language ...............................27912.1 Dados estruturados, semiestruturados e não estruturados .................................. 28012.2 Modelo de dados hierárquico (em árvore) da XML .............................................. 28312.3 Documentos XML, DTD e esquema XML ................................................... 28412.4 Armazenando e extraindo documentos XML de bancos de dados .................... 29112.5 Linguagens XML ................................. 29212.6 Extraindo documentos XML de bancos de dados relacionais .................................de banco de dados, chamada arquite-tura de três esquemas,9 que foi proposta para ajudar a alcançar e visualizar essas características. Depois, vamos discutir melhor o conceito de independência de dados.2.2.1 A arquitetura de três esquemasO objetivo da arquitetura de três esquemas, ilustrada na Figura 2.2, é separar as aplicações do usuário do banco de dados físico. Nessa arquitetu-ra, os esquemas podem ser definidos nos três níveis a seguir: 1. O nível interno tem um esquema interno, que descreve a estrutura do armazenamento físico do banco de dados. O esquema interno usa um modelo de dados físico e descreve os deta-lhes completos do armazenamento de dados e caminhos de acesso para o banco de dados. 2. O nível conceitual tem um esquema concei-tual, que descreve a estrutura do banco de dados inteiro para uma comunidade de usuá-rios. O esquema conceitual oculta os detalhes das estruturas de armazenamento físico e se concentra na descrição de entidades, tipos de dados, relacionamentos, operações do usuá-rio e restrições. Normalmente, um modelo de dados representativo é usado para descrever o esquema conceitual quando um sistema de banco de dados é implementado. Esse esque-ma conceitual de implementação costuma es-tar baseado em um projeto de esquema con-ceitual em um modelo de dados de alto nível. 3. O nível externo ou de visão inclui uma série de esquemas externos ou visões do usuário. Cada esquema externo descreve a parte do banco de dados em que um grupo de usuários em par-ticular está interessado e oculta o restante do banco de dados do grupo de usuários. Como no nível anterior, cada esquema externo é co-mumente implementado usando um modelo de dados representativo, possivelmente basea-do em um projeto de esquema externo em um modelo de dados de alto nível.8 O estado atual também é chamado de instante atual do banco de dados e de instância do banco de dados, mas preferimos usar o termo instância para nos referir a registros individuais.9 Isso também é conhecido como arquitetura ANSI/SPARC, mesmo nome do comitê que a propôs (Tsichritzis e Klug, 1978).VisãoexternaEsquema conceitualEsquema internoBanco de dados armazenadoVisãoexternaNível internoMapeamento conceitual/internoNível conceitualMapeamento externo/conceitualNível externoUsuários finais. . .Figura 2.2A arquitetura de três esquemas.22 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 22 11/30/10 5:23 PMA arquitetura de três esquemas é uma ferramen-ta com a qual o usuário pode visualizar os níveis de esquema em um sistema de banco de dados. A maio-ria dos SGBDs não separa os três níveis completa e explicitamente, mas dá suporte a eles de alguma forma. Alguns sistemas mais antigos podem incluir detalhes de nível físico no esquema conceitual. A ar-quitetura ANSI de três níveis tem um lugar impor-tante no desenvolvimento da tecnologia de banco de dados, pois separa, claramente, o nível externo dos usuários, o nível conceitual do banco de dados e o nível de armazenamento interno no projeto de um banco de dados. Ainda hoje ela é bastante aplicável no projeto de SGBDs. Na maioria dos SGBDs que têm suporte a visões do usuário, os esquemas exter-nos são especificados no mesmo modelo de dados que descreve a informação no nível conceitual (por exemplo, um SGBD relacional como o Oracle utili-za SQL para isso). Alguns SGBDs permitem que di-ferentes modelos de dados sejam usados nos níveis conceitual e externo. Um exemplo é a Base de Dados Universal (Universal Data Base — UDB), um SGBD da IBM que utiliza o modelo relacional para descre-ver o esquema conceitual, mas que pode usar um mo-delo orientado a objeto para descrever um esquema externo.Observe que os três esquemas são apenas descri-ções dos dados; os dados armazenados que realmente existem estão apenas no nível físico. Em um SGBD baseado na arquitetura de três esquemas, cada grupo de usuários recorre ao seu próprio esquema exter-no. Assim, o SGBD precisa transformar uma solici-tação especificada em um esquema externo em uma solicitação no esquema conceitual, e depois em uma solicitação no esquema interno para o processamen-to no banco de dados armazenado. Se a solicitação for uma recuperação, os dados extraídos do banco de dados armazenado devem ser reformatados para corresponder à visão externa do usuário. Os proces-sos de transformação de requisições e os resultados entre os níveis são chamados de mapeamentos. Esses mapeamentos podem ser demorados, de modo que alguns SGBDs — especialmente aqueles que servem para dar suporte a pequenos bancos de dados — não suportam visões externas. Porém, mesmo em tais sis-temas, uma certa quantidade de mapeamento é ne-cessária para transformar solicitações entre os níveis conceitual e interno.2.2.2 Independência de dadosA arquitetura de três esquemas pode ser usada para explicar melhor o conceito de independência de dados, que pode ser definida como a capacidade de alterar o esquema em um nível do sistema de banco de dados sem ter de alterar o esquema no nível mais alto. Podemos definir dois tipos de independência de dados: 1. Independência lógica de dados é a capacida-de de alterar o esquema conceitual sem ter de alterar os esquemas externos ou os progra-mas de aplicação. Podemos alterar o esquema conceitual para expandir o banco de dados (acrescentando um tipo de registro ou item de dado), para alterar restrições ou para reduzir o banco de dados (removendo um tipo de regis-tro ou item de dado). No último caso, esque-mas externos que se referem apenas aos dados restantes não seriam afetados. Por exemplo, o esquema externo da Figura 1.5(a) não deverá ser afetado pela alteração do arquivo HISTO-RICO_ESCOLAR (ou tipo de registro), mostra-do na Figura 1.2, para aquele mostrado na Figura 1.6(a). Somente a definição da visão e os mapeamentos precisam ser alterados em um SGBD que suporta a independência lógica de dados. Depois que o esquema conceitual passa por uma reorganização lógica, os pro-gramas de aplicação que referenciam as cons-truções do esquema externo devem trabalhar da mesma forma que antes. As mudanças nas restrições podem ser aplicadas ao esquema conceitual sem afetar os esquemas externos ou os programas de aplicação. 2. Independência física de dados é a capacidade de alterar o esquema interno sem ter de alte-rar o esquema conceitual. Logo, os esquemas externos também não precisam ser alterados. Mudanças no esquema interno podem ser ne-cessárias porque alguns arquivos físicos foram reorganizados — por exemplo, ao criar estru-turas de acesso adicionais — para melhorar o desempenho da recuperação ou atualização. Se os mesmos dados de antes permanecerem no banco de dados, provavelmente não te-remos de alterar o esquema conceitual. Por exemplo, oferecer um caminho de acesso para melhorar a velocidade de recuperação dos re-gistros de turma (Figura 1.2) por semestre e ano não deverá exigir que uma consulta como listar todas as turmas oferecidas no segundo semestre de 2008 seja alterada, embora a con-sulta seja executada com mais eficiência pelo SGBD ao utilizar o novo caminho de acesso.Em geral, a independência física de dados existe na maioria dos bancos de dados e ambientes de ar-quivo, nos quais detalhes físicos, como a localização exata dos dados no disco, e detalhes de hardware sobre codificação do armazenamento, posicionamen-to, compactação, divisão, mesclagem de registros, e Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 2302 elmas0810_cap02 BR.indd 23 11/30/10 5:23 PMassim por diante, são ocultados do usuário. As de-mais aplicações ignoram esses detalhes. Por sua vez, a independência lógica de dados é mais difícil de ser alcançada porque permite alterações estruturais e de restrição sem afetar os programas de aplicação — um requisito muito mais estrito.Sempre que temos um SGBD de múltiplos níveis, seu catálogodeve ser expandido para incluir informa-ções sobre como mapear solicitações e dados entre os diversos níveis. O SGBD usa software adicional para realizar esses mapeamentos, recorrendo à informa-ção de mapeamento no catálogo. A independência de dados ocorre porque, quando o esquema é alterado em algum nível, o esquema no próximo nível mais alto permanece inalterado; somente o mapeamento entre os dois níveis é alterado. Logo, os programas de aplicação que fazem referência ao esquema de nível mais alto não precisam ser alterados.A arquitetura de três esquemas pode tornar mais fácil obter a verdadeira independência de dados, tanto física quanto lógica. Porém, os dois níveis de mapeamentos criam uma sobrecarga durante a com-pilação ou execução de uma consulta ou programa, levando a baixa eficiência do SGBD. Por causa disso, poucos SGBDs implementaram a arquitetura com-pleta de três esquemas.2.3 Linguagens e interfaces do banco de dadosNa Seção 1.4, discutimos a variedade de usu-ários atendidos por um SGBD. O sistema precisa oferecer linguagens e interfaces apropriadas para cada categoria de usuário. Nesta seção, discutimos os tipos de linguagens e interfaces oferecidas por um SGBD e as categorias de usuário alvo de cada interface.2.3.1 Linguagens do SGBDQuando o projeto de um banco de dados é fina-lizado e um SGBD é escolhido para implementá-lo, o primeiro passo é especificar esquemas conceituais e internos para o banco de dados e quaisquer ma-peamentos entre os dois. Em muitos SGBDs, onde não é mantida nenhuma separação estrita de níveis, uma linguagem, chamada linguagem de definição de dados (DDL — Data Definition Language), é usada pelo DBA e pelos projetistas de banco de dados para definir os dois esquemas. O SGBD terá um compi-lador da DDL cuja função é processar instruções da DDL a fim de identificar as descrições dos construto-res de esquema e armazenar a descrição de esquema no catálogo do SGBD.Nos SGBDs que mantêm uma separação clara entre os níveis conceitual e interno, a DDL é usada para especificar apenas o esquema conceitual. Ou-tra linguagem, a linguagem de definição de arma-zenamento (SDL — Storage Definition Language), é utilizada para especificar o esquema interno. Os mapeamentos entre os dois esquemas podem ser es-pecificados em qualquer uma dessas linguagens. Na maioria dos SGBDs relacionais, não existe uma lin-guagem específica que realiza o papel de SDL. Em vez disso, o esquema interno é especificado por uma combinação de funções, parâmetros e especificações relacionadas ao armazenamento, que permitem aos DBAs controlar opções de indexação e mapeamentos dos dados que serão armazenados. Para uma verda-deira arquitetura de três esquemas, precisaríamos de uma terceira linguagem, a linguagem de definição de visão (VDL — View Definition Language), para es-pecificar visões do usuário e seus mapeamentos ao esquema conceitual, mas na maioria dos SGBDs a DDL é usada para definir tanto o esquema conceitu-al como o externo. Nos SGBDs relacionais, a SQL é usada pela VDL para definir visões do usuário ou da aplicação como resultados de consultas predefinidas (ver capítulos 4 e 5).Quando os esquemas são compilados e o ban-co de dados é populado, os usuários precisam de alguma forma de manipulá-lo. As manipulações tí-picas incluem recuperação, inserção, exclusão e mo-dificação dos dados. O SGBD oferece um conjunto de operações ou uma linguagem chamada linguagem de manipulação de dados (DML — Data Manipulation Language) para essas finalidades.Nos SGBDs atuais, esses tipos de linguagens nor-malmente não são considerados linguagens distintas; ao contrário, uma linguagem integrada e abrangente é usada na definição do esquema conceitual, defini-ção de visão e manipulação de dados. A definição do armazenamento, em geral, é mantida em separado, pois serve para definir estruturas de armazenamento físicas, para ajustar o desempenho do sistema de ban-co de dados, o que é normalmente feito pelos DBAs. Um exemplo típico de linguagem de banco de dados abrangente é a linguagem de banco de dados rela-cional SQL (ver capítulos 4 e 5), que representa uma combinação de DDL, VDL e DML, bem como as instruções para especificação de restrição, evolução de esquema e outros recursos. A SDL era um compo-nente nas primeiras versões da SQL, mas foi remo-vida da linguagem para mantê-la apenas nos níveis conceitual e externo.Existem dois tipos de DMLs. Uma DML de alto nível ou não procedural pode ser utilizada para espe-24 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 24 11/30/10 5:23 PMcificar operações de banco de dados complexas de for-ma concisa. Muitos SGBDs permitem que instruções DML de alto nível sejam inseridas interativamente em um monitor ou terminal ou sejam embutidas em uma linguagem de programação de uso geral. Nesse último caso, as instruções DML precisam ser identifi-cadas dentro do programa, de modo que possam ser extraídas por um pré-compilador e processadas por um SGBD. Uma DML de baixo nível ou procedural deve ser embutida em uma linguagem de programa-ção de uso geral. Esse tipo de DML, em geral, recupe-ra registros individuais ou objetos do banco de dados e processa cada um deles separadamente. Portanto, precisa de construções de linguagem de programa-ção, como o looping, para recuperar e processar cada registro de um conjunto de registros. DMLs de bai-xo nível também são chamadas de DMLs que tratam um registro de cada vez, devido a essa propriedade. A DL/1, uma DML projetada para o modelo hierárquico, é uma DML de baixo nível que emprega comandos como GET UNIQUE, GET NEXT ou GET NEXT WITHIN PARENT para navegar de um registro para outro em uma hierarquia de registros no banco de dados. As DMLs de alto nível, como a SQL, podem especificar e recuperar muitos registros em uma única instrução DML; portanto, elas são chamadas de DMLs de um conjunto de cada vez ou orientadas a conjunto. Uma consulta em uma DML de alto nível normalmente especifica quais dados recuperar, em vez de como recuperá-los; portanto, essas linguagens também são chamadas declarativas.Sempre que comandos DML, sejam eles de alto ou de baixo nível, são incorporados em uma lingua-gem de programação de uso geral, ela é chamada de linguagem hospedeira e a DML é chamada de sublin-guagem de dados.10 Por sua vez, uma DML de alto nível usada em uma maneira interativa é chamada linguagem de consulta. Em geral, comandos de re-cuperação e atualização de uma DML de alto nível podem ser usados de maneira interativa e, portanto, são considerados parte da linguagem de consulta.11Usuários finais casuais costumam usar uma lin-guagem de consulta de alto nível para especificar suas solicitações, enquanto os programadores usam a DML em sua forma embutida. Para usuários co-muns e paramétricos, normalmente existem interfa-ces amigáveis ao usuário para interagir com o banco de dados; estas também podem ser usadas por usu-ários casuais ou outros que não querem aprender os detalhes de uma linguagem de consulta de alto nível. Discutiremos esses tipos de interfaces a seguir.2.3.2 Interfaces de SGBDAs interfaces amigáveis ao usuário oferecidas por um SGBD podem incluir:Interfaces baseadas em menu para clientes Web ou de navegação. Essas interfaces apresentam ao usuário uma lista de opções (chamadas menus) que acompanham o usuário na formulação de uma solicitação. Os menus acabam com a necessidade de memorizar os comandos específicos e a sintaxe de uma linguagem de consulta; em vez disso, a consulta é composta passo a passo ao escolher opções de um menu que é exibido pelo sistema. Os menus pull--down são uma técnica muito popular nas interfa-ces de usuário baseadas na Web. Eles também são usados com frequência em interfaces de navegação, que permitem a um usuário examinar o conteúdo de um banco de dados de uma maneira exploratória e desestruturada.Interfaces baseadasem formulário. Uma inter-face baseada em formulário apresenta um formulário para cada usuário. Os usuários podem preencher todas as entradas do formulário para inserir novos dados ou preencher apenas certas entradas, neste caso o SGBD recuperará os dados correspondentes para as entradas restantes. Os formulários, normalmente, são projeta-dos e programados para usuários finais como interfa-ces para transações já programadas. Muitos SGBDs possuem linguagens de especificação de formulários, que são linguagens especiais que ajudam os progra-madores a especificar tais formulários. A SQL*Forms é uma linguagem baseada em formulário que espe-cifica consultas usando um formulário projetado em conjunto com o esquema de banco de dados relacio-nal. O Oracle Forms é um componente do pacote de produtos da Oracle que oferece um extenso conjunto de recursos para projetar e montar aplicações usando formulários. Alguns sistemas possuem utilitários para definir um formulário, permitindo que o usuário final construa interativamente um formulário de amostra na tela.Interfaces gráficas com o usuário. Uma GUI normalmente apresenta um esquema para o usuário em formato de diagrama. O usuário pode então es-pecificar uma consulta manipulando o diagrama. Em 10 Em bancos de dados de objeto, as sublinguagens hospedeiras e de dados formam uma linguagem integrada — por exemplo, C++ com algumas extensões, para dar suporte à funcionalidade de banco de dados. Alguns sistemas relacionais também oferecem linguagens integradas — por exemplo, a PL/SQL do Oracle.11 De acordo com seu significado em inglês, a palavra consulta (query), na realidade, deveria ser usada para descrever apenas leituras, e não atualizações.Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 2502 elmas0810_cap02 BR.indd 25 11/30/10 5:23 PMmuitos casos, as GUIs utilizam menus e formulários. A maioria delas utiliza um dispositivo de apontamen-to, como um mouse, para selecionar certas partes do diagrama de esquema apresentado.Interfaces de linguagem natural. Essas interfaces aceitam solicitações escritas em inglês, ou em outro idio-ma, e tentam entendê-las. Uma interface de linguagem natural costuma ter o próprio esquema, que é semelhan-te ao esquema conceitual do banco de dados, bem como um dicionário de palavras importantes. Essa interface recorre às palavras em seu esquema, bem como ao con-junto de palavras-padrão em seu dicionário, para inter-pretar a solicitação. Se a interpretação for bem-sucedida, a interface gera uma consulta de alto nível correspon-dente à solicitação de linguagem natural e a submete ao SGBD para processamento; caso contrário, um diálogo é iniciado com o usuário para esclarecer a solicitação. As funcionalidades das interfaces de linguagem natural não têm avançado rapidamente. Hoje, vemos mecanismos de busca que aceitam sequências de palavras de linguagem natural (como inglês) e as combinam com documentos em sites específicos (para mecanismos de busca locais) ou páginas na Web em geral (para mecanismos como Goo-gle ou Ask). Eles utilizam índices pré-definidos sobre pa-lavras e funções de pontuação (ranking) para recuperar e apresentar documentos resultantes em um grau decres-cente de combinação. Essas interfaces de consulta textual ‘em forma livre’ ainda não são comuns nos bancos de dados de modelo relacional estruturado ou legado, em-bora uma área de pesquisa chamada consulta baseada em palavra-chave tenha surgido recentemente para os bancos de dados relacionais.Entrada e saída de voz. O uso limitado da voz como entrada para uma consulta e como resposta para uma pergunta ou resultado de uma solicitação está se tornando comum. Aplicações com vocabulá-rios limitados, como consultas do catálogo telefôni-co, chegada/saída de voo e informações de conta de cartão de crédito, estão permitindo que a voz, para entrada e saída, facilite o acesso a essas informações pelos clientes. A entrada de voz é detectada usando uma biblioteca de palavras predefinidas e usadas para configurar os parâmetros fornecidos para as consultas. Para a saída, acontece uma conversão se-melhante de texto ou de números para voz.Interfaces para usuários paramétricos. Os usuários paramétricos, como caixas de banco, em ge-ral possuem um pequeno conjunto de operações que precisam realizar repetidamente. Por exemplo, um caixa pode usar teclas de função isoladas para fazer transações de rotina e repetitivas, como depósitos em conta ou saques, ou consultas de saldo. Os analistas de sistemas e programadores projetam e implemen-tam uma interface especial para cada classe conhe-cida de usuários finais. Normalmente, um pequeno conjunto de comandos abreviados é incluído, com o objetivo de minimizar o número de toques de te-clas exigidos para cada solicitação. Por exemplo, as teclas de função em um terminal podem ser progra-madas para iniciar diversos comandos. Isso permite que o usuário paramétrico prossiga com um número mínimo de toques de teclas.Interfaces para o DBA. A maioria dos sistemas de banco de dados contém comandos privilegiados que podem ser usados apenas pelos DBAs. Estes incluem comandos para criar contas, definir parâ-metros do sistema, conceder autorização de conta, alterar um esquema e reorganizar as estruturas de armazenamento de um banco de dados.2.4 O ambiente do sistema de banco de dadosUm SGBD é um sistema de software complexo. Nesta seção, vamos discutir os tipos de componentes de software que constituem um SGBD e os tipos de software de sistemas de computação com os quais ele interage.2.4.1 Módulos componentes do SGBDA Figura 2.3 ilustra, de uma forma simplifica-da, os componentes típicos do SGBD. A figura está dividida em duas partes. A parte superior refere-se aos vários usuários do ambiente de banco de dados e suas interfaces. A parte inferior mostra os detalhes internos do SGBD, responsáveis pelo armazenamen-to de dados e processamento de transações.O banco de dados e o catálogo do SGBD, habi-tualmente, são armazenados em disco. O acesso ao disco é controlado, em especial, pelo sistema opera-cional (SO), que escalona a leitura/escrita em disco. Muitos SGBDs possuem o próprio módulo de geren-ciamento de buffer para planejar a leitura/escrita em disco, pois isso tem um efeito considerável sobre o desempenho. A redução da leitura/escrita em disco melhora o desempenho de maneira considerável. Um módulo gerenciador de dados armazenados controla o acesso às informações do SGBD que são armazena-das em disco, não importando se elas fazem parte do banco de dados ou do catálogo.Primeiramente, vamos considerar a parte su-perior da Figura 2.3. Ela mostra as interfaces para DBAs, usuários casuais que trabalham com interfaces interativas para formular consultas, programadores de aplicação que criam programas usando algumas linguagens de programação hospedeira, e usuários 26 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 26 11/30/10 5:23 PMparamétricos que realizam a entrada dos dados for-necendo parâmetros para transações predefinidas. Os DBAs definem o banco de dados e realizam ajus-tes, alterando sua definição por meio da DDL e de outros comandos privilegiados.O compilador da DDL processa as definições de esquema especificadas e armazena as descrições dos es-quemas (metadados) no catálogo do SGBD. O catálo-go inclui informações como os nomes e os tamanhos dos arquivos, nomes e tipos de dados dos itens de dados, detalhes de armazenamento de cada arquivo, informações de mapeamento entre esquemas e restri-ções. Além disso, o catálogo armazena muitos outros tipos de informações essenciais para os módulos do SGBD, que podem, então, utilizar as informações do catálogo, conforme a necessidade.Usuários casuais do banco de dados interagem usando alguma forma de interface, que chamamos Processador debanco de dados em tempo de execução Pré-compiladorCatálogodo sistema/Dicionáriode dadosOtimizadorde consultaCompiladorDMLCompiladorde linguagemhospedeiraSubsistemas de controlede concorrência/backup/recuperaçãoTransaçõescompiladasBanco de dadosarmazenadoComandos, consultas etransações do DBA Entrada/saídado banco de dadosExecução deconsulta e transação:CompiladorDDLInstruçõesDDLComandosprivilegiadosConsultainterativaProgramas de aplicaçãoDBAs Usuários casuais Programadoresde aplicaçãoUsuários paramétricosUsuários:Compiladorde consultaGerenciadorde dadosarmazenadosFigura 2.3Módulos componentes de um SGBD e suas interações.de interface de consulta interativa, na Figura 2.3. Não mostramos explicitamente qualquer interação basea-da em menu ou baseada em formulário que possa ser usada para gerar a consulta interativa de maneira au-tomática. Essas consultas são analisadas e validadas pela exatidão da sintaxe da consulta, os nomes de ar-quivos e elementos de dados, e assim por diante, por um compilador de consulta, que as compila para um formato interno. Essa consulta interna está sujeita à otimização de consultas (discutida nos capítulos 19 e 20). Entre outras coisas, o otimizador de consulta preocupa-se com o rearranjo e a possível reordena-ção de operações, com a eliminação de redundâncias e uso dos algoritmos e índices corretos durante a exe-cução. Ele consulta o catálogo do sistema em busca de informações estatísticas e outras informações físi-cas sobre os dados armazenados, gerando um código executável que realiza as operações necessárias para Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 2702 elmas0810_cap02 BR.indd 27 11/30/10 5:23 PMa consulta e faz chamadas ao processador em tempo de execução.Os programadores de aplicação escrevem pro-gramas em linguagens hospedeiras, como Java, C ou C++, que são submetidas a um pré-compilador. O pré--compilador extrai comandos DML do programa de aplicação escrito em uma linguagem de programação hospedeira. Esses comandos são enviados ao compi-lador DML para serem compilados em código objeto para o acesso ao banco de dados. O restante do pro-grama é enviado ao compilador da linguagem hospe-deira. Os códigos objeto para os comandos DML e o restante do programa são ligados (‘linkados’), for-mando uma transação programada, cujo código exe-cutável inclui chamadas para o processador de banco de dados em tempo de execução. As transações pro-gramadas são executadas repetidamente pelos usuá-rios paramétricos, que apenas fornecem os parâmetros para as transações. Cada execução é considerada uma transação separada. Um exemplo é uma transação de saque bancário, no qual o número da conta e o valor podem ser fornecidos como parâmetros.Na parte inferior da Figura 2.3, o processador de banco de dados em tempo de execução execu-ta (1) os comandos privilegiados, (2) os planos de consulta executáveis e (3) as transações programa-das com parâmetros em tempo de execução. Ele trabalha com o catálogo do sistema e pode atua-lizá-lo com estatísticas. Também trabalha com o gerenciador de dados armazenados, que, por sua vez, utiliza os serviços básicos do sistema opera-cional para executar operações de entrada/saída (leitura/escrita) de baixo nível entre o disco e a me-mória principal. O processador de banco de dados em tempo de execução cuida de outros aspectos da transferência de dados, como o gerenciamento de buffers na memória principal. Alguns SGBDs têm o próprio módulo de gerenciamento de buffer, en-quanto outros dependem do SO para fazê-lo. Mos-tramos os sistemas de controle de concorrência e backup e recuperação separadamente como um módulo nessa figura. Eles são integrados ao pro-cessador de banco de dados em tempo de execução para fins de gerenciamento de transação.Agora, é comum que o programa cliente acesse o SGBD executando em um computador separado do computador em que o banco de dados reside. O pri-meiro é chamado computador cliente, que executa um software cliente do SGBD, e o segundo é chama-do servidor de banco de dados. Em alguns casos, o cliente acessa um computador intermediário, conhe-cido como servidor de aplicações, que, por sua vez, acessa o servidor de banco de dados. Abordaremos melhor esse assunto na Seção 2.5.A Figura 2.3 não pretende descrever um SGBD específico; ao contrário, ela ilustra os módulos bási-cos de SGBD. O SGBD interage com o sistema ope-racional quando os acessos ao disco — ao banco de dados ou ao catálogo — são necessários. Se o com-putador for compartilhado por muitos usuários, o SO escalonará as solicitações de acesso ao disco do SGBD e o processamento do SGBD juntamente com outros processos. Além disso, se o computador estiver, prin-cipalmente, dedicado a executar o servidor de banco de dados, o SGBD controlará a memória principal buferizando das páginas do disco. O sistema também realiza a interface com compiladores das linguagens de programação hospedeiras de uso geral, e com os servidores de aplicação e programas cliente rodando em máquinas separadas, por meio da interface de rede do sistema.2.4.2 Utilitários do sistema de banco de dadosAlém dos componentes de software que descre-vemos, a maioria dos SGBDs possui utilitários de banco de dados que ajudam o DBA a gerenciar o sis-tema. Os utilitários têm, basicamente, os seguintes tipos de funções: � Carga. Um utilitário de carga é usado para car-regar os arquivos de dados existentes — como arquivos de texto ou arquivos sequenciais — no banco de dados. Normalmente o formato atual do arquivo de dado (origem) e a estrutura do arquivo do banco de dados desejado (desti-no) são especificados pelo utilitário que refor-mata automaticamente os dados e os armaze-na no banco de dados. Com a proliferação de SGBDs, a transferência de dados de um SGBD para outro está se tornando comum em muitas organizações. Alguns fornecedores de SGBDs estão oferecendo produtos que geram os pro-gramas de carga apropriados, tendo como base descrições de armazenamento de banco de da-dos de origem e destino (esquemas internos). Essas ferramentas também são chamadas de ferramentas de conversão. Para o SGBD hie-rárquico chamado IMS (da IBM) e para muitos SGBDs de rede, incluindo o IDMS (da Com-puter Associates), SUPRA (da Cincom) e Ima-ge (da HP), os fornecedores ou empresas de terceiros estão disponibilizando uma série de ferramentas de conversão (por exemplo, o SU-PRA Server SQL da Cincom) para transformar os dados para o modelo relacional. � Backup. Um utilitário de backup cria uma cópia de segurança do banco de dados, nor-28 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 28 11/30/10 5:23 PMmalmente copiando o banco de dados inteiro para fita ou outro meio de armazenamento em massa. A cópia backup pode ser usada para restaurar o banco de dados no caso de uma falha catastrófica no disco. Os backups incrementais também costumam ser utiliza-dos, e registram apenas as mudanças ocor-ridas após o backup anterior. O backup in-cremental é mais complexo, mas economiza espaço de armazenamento. � Reorganização do armazenamento do banco de dados. Esse utilitário pode ser usado para reorganizar um conjunto de arquivos do ban-co de dados em diferentes organizações de ar-quivo, e cria novos caminhos de acesso para melhorar o desempenho. � Monitoração de desempenho. Esse utilitário monitora o uso do banco de dados e oferece estatísticas ao DBA. O DBA usa as estatísti-cas para tomar decisões se deve ou não reor-ganizar arquivos ou se deve incluir ou remo-ver índices para melhorar o desempenho.Podem estar disponíveis outros utilitários para classificar arquivos, tratar da compactação de dados, monitorar o acesso pelos usuários, realizar a interfa-ce com a rede e desempenhar outras funções.2.4.3 Ferramentas, ambientes de aplicação e facilidades de comunicaçõesOutras ferramentas estão frequentemente dispo-níveis aos projetistas debancos de dados, usuários e ao SGBD. Ferramentas CASE12 são usadas na fase de projeto dos sistemas de banco de dados. Outra ferramenta que pode ser muito útil em grandes orga-nizações é um sistema de dicionário de dados (ou de repositório de dados) expandido. Além de armazenar informações de catálogo sobre esquemas e restrições, o dicionário de dados armazena decisões do projeto, padrões de uso, descrições de programa de aplica-ção e informações do usuário. Esse sistema também é chamado de repositório de informação. Essa infor-mação pode ser acessada diretamente pelos usuários ou pelo DBA, quando necessário. Um utilitário de dicionário de dados é semelhante ao catálogo do SGBD, mas inclui uma variedade maior de informa-ções e é acessado principalmente pelos usuários, em vez de ser acessada pelo software de SGBD.Ambientes de desenvolvimento de aplicação, como o PowerBuilder (Sybase) ou o JBuilder (Bor-land), são muito populares. Esses sistemas oferecem um ambiente para desenvolver aplicações de banco de dados e incluem facilidades que ajudam em muitas facetas dos sistemas, incluindo projeto de banco de dados, desenvolvimento GUI, consulta e atualização, e desenvolvimento de programas de aplicação.O SGBD também precisa realizar a interface com o software de comunicações, cuja função é per-mitir que os usuários em locais remotos do sistema de banco de dados acessem o banco de dados por meio de terminais de computador, estações de traba-lho ou computadores pessoais. Estes são conectados ao local do banco de dados por meio de hardware de comunicações de dados, como roteadores da Inter-net, linhas telefônicas, redes de longa distância, redes locais ou dispositivos de comunicação por satélite. Muitos sistemas de banco de dados do mercado pos-suem pacotes de comunicação que trabalham com o SGBD. O sistema integrado de SGBD e comunica-ções de dados é chamado de sistema DB/DC. Além disso, alguns SGBDs estão fisicamente distribuídos em várias máquinas. Nesse caso, redes de comuni-cações são necessárias para conectar as máquinas. Estas, com frequência, são redes locais (LANs — Lo-cal Area Networks), mas também podem ser outros tipos de redes.2.5 Arquiteturas centralizadas e cliente/servidor para SGBDs2.5.1 Arquitetura de SGBDs centralizadaAs arquiteturas para SGBDs têm seguido tendên-cias semelhantes àquelas dos sistemas de computação em geral. As arquiteturas anteriores usavam compu-tadores mainframe para oferecer o processamento principal para todas as funções do sistema, incluindo programas de aplicação do usuário e programas de interface com o usuário, bem como toda a funcio-nalidade do SGBD. O motivo é que a maioria dos usuários acessava tais sistemas por terminais de com-putador, que não tinham poder de processamento e apenas ofereciam capacidades de exibição. Portanto, todo o processamento era realizado remotamente no computador central, e somente informações de exibi-ção e controles eram enviados do computador para os terminais de vídeo, que eram conectados ao com-putador central por meio de vários tipos de redes de comunicações.À medida que os preços do hardware caíram, a maioria dos usuários substituiu seus terminais com PCs e estações de trabalho. No início, os sistemas 12 Embora CASE signifique engenharia de software auxiliada por computador, muitas de suas ferramentas são usadas, principalmente, para o projeto de banco de dados.Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 2902 elmas0810_cap02 BR.indd 29 11/30/10 5:23 PMde banco de dados usavam esses computadores de modo semelhante à forma que usavam terminais de vídeo, de maneira que o SGBD em si ainda era um SGBD centralizado, em que toda sua funcionalidade, execução de programas de aplicação e processamen-to de interface do usuário eram executados em uma máquina. A Figura 2.4 ilustra os componentes físicos em uma arquitetura centralizada. Gradualmente, os sistemas de SGBD começaram a explorar o poder de processamento disponível no lado do usuário, o que levou às arquiteturas de SGBD cliente/servidor.2.5.2 Arquiteturas cliente/servidor básicasPrimeiro, vamos discutir a arquitetura clien-te/servidor em geral, e depois veremos como ela se aplica aos SGBDs. A arquitetura cliente/servi-dor foi desenvolvida para lidar com ambientes de computação em que um grande número de PCs, estações de trabalho, servidores de arquivos, im-pressoras, servidores de banco de dados, servido-res Web, servidores de correio (e-mail) e outros softwares e equipamentos são conectados por uma rede. A ideia é definir servidores especializados com funcionalidades específicas. Por exemplo, é possível conectar uma série de PCs ou pequenas estações de trabalho como clientes a um servidor de arquivos que mantém os arquivos das máquinas clientes. Outra máquina pode ser designada como servidor de impressão, sendo conectada a várias impressoras; todas as solicitações de impressão pe-los clientes são encaminhadas a essa máquina. Os servidores Web ou servidores de correio também se encontram na categoria de servidor especializado. Os recursos fornecidos pelos servidores especiali-zados podem ser acessados por muitas máquinas cliente. As máquinas cliente oferecem ao usuário as interfaces apropriadas para utilizar esses ser-vidores, bem como poder de processamento local para executar aplicações locais. Esse conceito pode ser transportado para outros pacotes de software, com programas especializados — como o CAD (Computer-Aided Design) — sendo armazenados em máquinas servidoras específicas e acessíveis a múltiplos clientes. A Figura 2.5 ilustra a arquite-tura cliente/servidor no nível lógico; a Figura 2.6 é um diagrama simplificado que mostra a arquitetu-ra física. Algumas máquinas seriam apenas locais do cliente (por exemplo, estações de trabalho sem disco ou estações de trabalho/PCs com discos, que têm apenas software cliente instalado). Outras má-quinas seriam servidores dedicados, e outras ainda teriam funcionalidade de cliente e servidor.Sistema operacionalSoftwareProgramasde aplicaçãoSGBD. . .. . .CompiladoresEditoresde textoControle de exibição do terminalMonitorde vídeoMonitorde vídeoRedeMonitorde vídeoTerminais . . .Hardware/FirmwareControladorCPUControlador. . .ControladorMemória DiscoDispositivos deE/S (impressoras,unidades de fita...)Barramento do sistema. . .Figura 2.4Uma arquitetura física centralizada.Cliente CLIENTLocal 2Clientecom discoClienteLocal 1Clientesem discoServidorLocal 3ServidorRede decomunicaçãoLocal nServidore cliente. . .ClienteServidorFigura 2.6Arquitetura cliente/servidor física em duas camadas.Cliente Cliente ClienteServidor deimpressãoServidor deSGBDServidor dearquivos. . .. . .RedeFigura 2.5Arquitetura cliente/servidor lógica em duas camadas.30 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 30 11/30/10 5:23 PMO conceito de arquitetura cliente/servidor assu-me uma estrutura básica composta por muitos PCs e estações de trabalho, além de um número menor de máquinas de grande porte (mainframes), conec-tados por LANs e outros tipos de redes de compu-tadores. Um cliente nessa estrutura normalmente é uma máquina que oferece capacidades de interface com o usuário e processamento local. Quando um cliente requer acesso a alguma funcionalidade adi-cional — como acesso ao banco de dados — que não existe nessa máquina, ele se conecta a um ser-vidor que oferece a funcionalidade necessária. Um servidor é um sistema com hardware e software que pode oferecer serviços às máquinas cliente, como acesso a arquivo, impressão, arquivamento ou aces-so a banco de dados. Em geral, algumas máquinas têm instalados apenas softwares cliente, outras, apenas software servidor, e ainda outras podem in-cluir software cliente e servidor, conforme ilustrado na Figura 2.6. Porém,é mais comum que o software cliente e servidor seja executado em máquinas se-paradas. Dois tipos principais de arquiteturas de SGBD foram criados nessa estrutura cliente/servi-dor básica: duas camadas e três camadas.13 Vamos explicar esses dois tipos a seguir.2.5.3 Arquiteturas cliente/servidor de duas camadas para SGBDsEm sistemas de gerenciamento de banco de da-dos relacional (SGBDRs), muitos dos quais começa-ram como sistemas centralizados, os componentes do sistema movidos inicialmente para o lado do cliente foram a interface com o usuário e os programas de aplicação. Como a SQL (ver capítulos 4 e 5) fornecia uma linguagem-padrão para os SGBDRs, isso criou um ponto de divisão lógico entre cliente e servidor. Assim, as funcionalidades de consulta e de transação relacionadas ao processamento da SQL permanece-ram no lado do servidor. Em tal arquitetura, o servi-dor frequentemente é chamado servidor de consulta ou servidor de transação, pois oferece essas duas fun-cionalidades. Em um SGBDR, o servidor também é chamado de servidor SQL.Os programas da interface com o usuário e os programas de aplicação podem ser executados no lado do cliente. Quando é necessário acessar o SGBD, o programa estabelece uma conexão com o SGBD (que está no lado do servidor); quando a conexão é criada, o programa cliente pode se comu-nicar com o SGBD. Um padrão denominado Co-nectividade de Banco de Dados Aberta (ODBC — Open Database Connectivity) oferece uma interface de programação de aplicações (API — Application Programming Interface), que permite que os progra-mas do cliente chamem o SGBD, desde que as má-quinas cliente e servidor tenham o software neces-sário instalado. A maioria dos vendedores de SGBD oferece drivers ODBC para seus sistemas. Um pro-grama cliente pode se conectar a vários SGBDRs e enviar solicitações de consulta e transação usando a API da ODBC, que são processadas nos servido-res. Quaisquer resultados de consulta são enviados de volta ao programa cliente, que pode processar e exibir os resultados conforme a necessidade. Foi definido também um padrão para a linguagem de programação Java, chamado JDBC. Isso permite que programas cliente em Java acessem um ou mais SGBDs por meio de uma interface-padrão.A abordagem diferente para a arquitetura clien-te/servidor em duas camadas foi seguida por alguns SGBDs orientados a objeto, em que os módulos de software do sistema foram divididos entre clien-te e servidor de uma maneira mais integrada. Por exemplo, o nível do servidor pode incluir a parte do software do SGBD responsável por tratar do arma-zenamento de dados nas páginas do disco, contro-le de concorrência local e recuperação, buffering e caching de páginas do disco, e outras funções se-melhantes. Enquanto isso, o nível do cliente pode tratar da interface com o usuário; funções de dicio-nário de dados; interações do SGBD com os compi-ladores da linguagem de programação; otimização global da consulta, controle de concorrência e re-cuperação entre vários servidores; estruturação de objetos complexos com base nos dados dos buffers; e outras funções semelhantes. Nessa abordagem, a interação cliente/servidor é mais acoplada e é feita internamente pelos módulos de SGBD — alguns dos quais residem no cliente e alguns no servidor —, e não pelos usuários/programadores. A divisão exata da funcionalidade pode variar de um sistema para outro. Em tal arquitetura cliente/servidor, o servi-dor é chamado de servidor de dados, pois oferece dados organizados em páginas de disco ao cliente. Esses dados podem então ser estruturados pelos pro-gramas clientes pelo software cliente do SGBD em objetos.As arquiteturas descritas aqui são chamadas arqui-teturas de duas camadas porque os componentes de sof-tware são distribuídos por dois sistemas: cliente e servi-dor. As vantagens dessa arquitetura são sua simplicidade e compatibilidade transparente com os sistemas existen-tes. O surgimento da Web mudou os papéis de clientes e servidores, levando à arquitetura de três camadas.13 Existem muitas outras variações de arquiteturas cliente/servidor. Discutiremos aqui as duas mais básicas.Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 3102 elmas0810_cap02 BR.indd 31 11/30/10 5:23 PM2.5.4 Arquiteturas de três camadas e n camadas para aplicações WebMuitas aplicações Web utilizam uma arquitetura chamada arquitetura de três camadas, que acrescenta uma camada intermediária entre o cliente e o servi-dor de banco de dados, conforme ilustrado na Figura 2.7(a).Essa camada intermediária é chamada de servi-dor de aplicação ou servidor Web, dependendo da aplicação. Esse servidor desempenha um papel inter-mediário pela execução de programas de aplicação e armazenamento de regras de negócios (procedimen-tos ou restrições), que são usados para acessar os da-dos do servidor de banco de dados. Ela também pode melhorar a segurança do banco de dados, verifican-do as credenciais de um cliente antes de encaminhar uma solicitação ao servidor de banco de dados. Os clientes têm interfaces GUI e algumas regras de negó-cios adicionais, específicas da aplicação. O servidor intermediário aceita e processa solicitações do clien-te, e envia consultas e comandos do banco de dados ao servidor de banco de dados, e depois atua como um canal para passar (parcialmente) dados processa-dos do servidor de banco de dados aos clientes, onde podem ainda ser processados e filtrados para serem apresentados aos usuários no formato da GUI. As-sim, a interface com o usuário, as regras da aplicação e o acesso aos dados atuam como três camadas. A Figura 2.7(b) mostra outra arquitetura usada pelos fornecedores de bancos de dados e de outras aplica-ções. A camada de apresentação exibe informações ao usuário e permite a entrada de dados. A camada de lógica de negócios cuida das regras e restrições intermediárias antes dos dados serem passados para o usuário ou devolvidos ao SGBD. A camada inferior inclui todos os serviços de gerenciamento de dados. A camada do meio também pode atuar como um ser-vidor Web, que recupera resultados das consultas do servidor de banco de dados e os formata para as pá-ginas Web dinâmicas, que são vistas pelo navegador Web no lado do cliente.Outras arquiteturas também foram propostas. É possível dividir as camadas entre o usuário e os dados armazenados em outros componentes mais detalha-dos, resultando, assim, em arquiteturas de n camadas, onde n pode ser quatro ou cinco camadas. Em geral, a camada da lógica de negócios é dividida em várias ca-madas. Além de distribuir a programação e os dados pela rede, as aplicações de n camadas têm a vantagem de que qualquer camada poder ser executada em um processador ou plataforma de sistema operacional adequado e ser tratada independentemente. Os forne-cedores de pacotes de ERP (Enterprise Resource Plan-ning) e CRM (Customer Relationship Management) costumam utilizar uma camada de middleware, que é responsável pelos módulos de front-end (clientes) que se comunicam com uma série de bancos de dados de back-end (servidores).Os avanços na tecnologia de criptografia tornam mais seguro transferir dados confidenciais em forma-to codificado do servidor ao cliente, onde será deco-dificado. Isso pode ser feito pelo hardware ou por um software avançado. Essa tecnologia oferece níveis mais altos de segurança de dados, mas as questões de segurança da rede continuam sendo uma preocupa-ção constante. Diversas tecnologias de compactação de dados também ajudam a transferir grande quan-tidade de dados dos servidores aos clientes por redes com e sem fio.2.6 Classificação dos sistemas gerenciadores de banco de dadosVários critérios são normalmente utilizados para classificar os SGBDs. O primeiro é o modelo de da-dos no qual o SGBD é baseado. O principal modelo de dados usado atualmente em muitos SGBDs co-mercial é o modelo de dados relacional.O modelo de dados de objeto foi implementado em alguns sis-temas comerciais, mas não tem seu uso generalizado. Muitas aplicações legadas ainda rodam em sistemas de banco de dados baseados nos modelos de dados hierárquico e de rede. Alguns exemplos de SGBDs hierárquicos são o IMS (da IBM) e alguns outros sis-temas, como o System 2K (da SAS Inc.) e o TDMS. GUI,Interface WebClienteServidor de aplicaçãoouServidor WebServidor de banco de dadosProgramas deaplicação,páginas WebSistemagerenciador de banco de dadosCamada deapresentaçãoCamada lógicade negóciosCamada deserviços debanco de dados(a) (b)Figura 2.7Arquitetura cliente/servidor lógica de três camadas, com algumas nomenclaturas comumente utilizadas.32 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 32 11/30/10 5:23 PMO IMS ainda é usado em instalações do governo e in-dustriais, incluindo hospitais e bancos, embora mui-tos de seus usuários tenham passado para sistemas relacionais. O modelo de dados de rede foi usado por muitos fornecedores, e os produtos resultantes, como IDMs (da Cullinet — atualmente, Computer Associates), DMS 1100 (da Univac — atualmente, Unisys), IMAGE (da Hewlett-Packard), VAX-SGBD (da Digital — depois Compaq e atualmente HP) e SUPRA (da Cincom), ainda têm seguidores e seus grupos de usuários estão ativamente organizados. Se acrescentarmos a eles o popular sistema de arquivos VSAM da IBM, podemos facilmente dizer que uma porcentagem razoável dos dados computadorizados do mundo inteiro ainda estão nesses chamados siste-mas de banco de dados legados.Os SGBDs relacionais estão evoluindo continua-mente e, em particular, têm incorporado muitos dos conceitos que foram desenvolvidos nos bancos de da-dos de objeto. Isso tem levado a uma nova classe de SGBDs, chamada SGBDs objeto-relacionais. Assim, podemos categorizar os SGBDs com base no modelo de dados: relacionais, objeto, objeto-relacional, hie-rárquico, rede, entre outros.Mais recentemente, alguns SGBDs experimen-tais se baseiam no modelo XML (eXtended Markup Language), que é um modelo de dados estruturado em árvore (hierárquico). Estes têm sido chamados de SGBDs XML nativos. Vários SGBDs relacionais co-merciais acrescentaram interfaces e armazenamento XML a seus produtos.O segundo critério usado para classificar SGBDs é o número de usuários suportados pelo sistema. Sis-temas monousuário admitem apenas um usuário de cada vez, e são usados principalmente com PCs. Sis-temas multiusuário, que incluem a maioria dos SGBDs, admitem múltiplos usuários simultaneamente.O terceiro critério é o número de locais sobre os quais o banco de dados está distribuído. Um SGBD é centralizado se os dados estiverem armazenados em um único computador. Um SGBD centralizado pode atender a vários usuários, mas o SGBD e o banco de dados residem integralmente em um único computa-dor. Um SGBD distribuído (SGBDD) pode ter o ban-co de dados real e o software de SGBD distribuídos por vários locais, conectados por uma rede de com-putadores. Os SGBDDs homogêneos usam o mesmo software de SGBD em todos os locais, ao passo que SGBDDs heterogêneos podem usar um software de SGBD diferente em cada local. Também é possível desenvolver software de middleware para acessar vá-rios bancos de dados autônomos pré-existentes, ar-mazenados sob SGBDs heterogêneos. Isso leva a um SGBD federado (ou sistema multibanco de dados), em que os sistemas participantes são fracamente aco-plados e possuem um certo grau de autonomia local. Muitos SGBDDs utilizam arquitetura cliente/servi-dor, conforme descrito na Seção 2.5.O quarto critério é o custo. É difícil propor uma classificação dos SGBDs com base no custo. Hoje, temos SGBDs de código aberto (gratuito), como MySQL e PostgreSQL, que têm suporte de fornece-dores terceirizados com serviços adicionais. Os prin-cipais SGBDRs estão disponíveis em versões gratuitas para testes durante 30 dias, além de versões pesso-ais, que podem custar menos de US$ 100 e permitir uma funcionalidade muito maior. Os sistemas gigan-tes estão sendo vendidos em formato modular, com componentes para lidar com distribuição, replicação, processamento paralelo, capacidade móvel, e assim por diante, e com um grande número de parâmetros que precisam ser definidos para configuração. Além do mais, eles são vendidos na forma de licenças — as licenças por local permitem uso ilimitado do siste-ma de banco de dados com qualquer número de có-pias rodando na instalação definida pelo comprador. Outro tipo de licença limita o número de usuários simultâneos ou o número total de usuários em de-terminado local. As versões de alguns sistemas para um único usuário isolado, como Microsoft Access, são vendidas por cópia ou incluídas na configuração geral do computador desktop ou laptop. Além disso, recursos de data warehousing e mineração de dados, bem como o suporte para tipos de dados adicionais, estão disponíveis a um custo extra. É possível pagar milhões de dólares anualmente pela instalação e ma-nutenção de grandes sistemas de banco de dados.Também podemos classificar um SGBD com base nas opções de tipos de caminho de acesso para armazenar arquivos. Uma família bem conhecida de SGBDs é baseada em estruturas invertidas de arqui-vo. Por fim, um SGBD pode ser de uso geral ou de uso especial. Quando o desempenho é um aspecto importante, um SGBD de uso especial pode ser pro-jetado e construído para uma aplicação específica; esse sistema não pode ser usado para outras aplica-ções sem mudanças relevantes. Muitos sistemas de reservas aéreas e catálogo telefônico desenvolvidos no passado são SGBDs de uso especial. Eles se en-contram na categoria de sistemas de processamento de transação on-line (OLTP — Online Transaction Processing), que precisam dar suporte a um grande número de transações simultâneas sem causar atra-sos excessivos.Vamos detalhar rapidamente o critério principal para classificar SGBDs: o modelo de dados. O mo-delo de dados relacional básico representa um banco de dados como uma coleção de tabelas, onde cada Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 3302 elmas0810_cap02 BR.indd 33 11/30/10 5:23 PMtabela pode ser armazenada como um arquivo sepa-rado. O banco de dados na Figura 1.2 se assemelha a uma representação relacional. A maior parte dos bancos de dados relacionais utiliza a linguagem de consulta de alto nível, chamada SQL, e admite uma forma limitada de visões do usuário. Discutiremos o modelo relacional e suas linguagens e operações nos capítulos 3 a 6, e as técnicas para programar aplica-ções relacionais nos capítulos 13 e 14.O modelo de dados de objeto define um banco de dados em termos de objetos, suas proprieda-des e operações. Os objetos com a mesma estrutu-ra e comportamento pertencem a uma classe, e as classes são organizadas em hierarquias (ou grafos acíclicos). As operações de cada classe são especifi-cadas com procedimentos predefinidos, chamados métodos. Os SGBDs relacionais têm estendido seus modelos para incorporar conceitos de banco de da-dos de objeto e outras funcionalidades; esses siste-mas são chamados de sistemas objeto-relacional ou relacional estendido. Discutiremos os sistemas de bancos de dados de objeto e objeto-relacional no Capítulo 11.O modelo XML surgiu como um padrão para troca de dados pela Web, e foi usado como base para implementar vários protótipos de sistemas com XML nativa. A XML utiliza estruturas de árvore hierárqui-cas e combina conceitos de banco de dados com con-ceitos dos modelos de representação de documentos. Os dados são representados como elementos; com o uso de tags, os dados podem ser aninhados para criar estruturas hierárquicas complexas. Esse modelo é conceitualmente semelhante ao modelo de objeto, mas usa uma terminologia diferente. Funcionalida-des XML têm sido acrescentadas a muitos produtos de SGBD comercial. Apresentaremosuma visão geral da XML no Capítulo 12.Dois modelos de dados mais antigos, histori-camente importantes, agora conhecidos como mo-delos de dados legados, são os modelos de rede e hierárquico. O modelo de rede representa dados como tipos de registro e também representa um tipo limitado de relacionamento 1:N, chamado tipo de conjunto. Um relacionamento 1:N, ou um-para-mui-tos, relaciona uma instância de um registro a muitas instâncias de registros usando algum mecanismo de ligação com ponteiros nesses modelos. A Figura 2.8 mostra um diagrama de esquema de rede para o ban-co de dados da Figura 2.1, em que os tipos de regis-tros aparecem como retângulos e os tipos de conjun-tos aparecem como setas direcionadas e rotuladas.O modelo de rede, também conhecido como mo-delo CODASYL DBTG,14 possui uma linguagem que trata um registro por vez e que deve estar embutida em uma linguagem de programação hospedeira. A DML do modelo de rede foi proposta no Database Task Group (DBTG) Report de 1971 como uma ex-tensão da linguagem COBOL. Ela oferece comandos para localizar registros diretamente (por exemplo, FIND ANY USING ou FIND DUPLICATE USING ). Tem comandos para navegar dentro dos tipos conjunto (por exemplo, GET OWNER, GET {FIRST, NEXT, LAST} MEMBER WITHIN WHERE ). Tem também comandos para armazenar novos dados (por exemplo, STORE ) e torná-los parte de um tipo con-junto (por exemplo, CONNECT TO ). A linguagem também trata diver-sos aspectos adicionais, como a posição dos tipos de HISTORICO_ESCOLARTURMADISCIPLINAS_OFERECIDASNOTAS_ALUNOTEM_UME_UMAPRE_REQUISITONOTAS_TURMAALUNO DISCIPLINAFigura 2.8O esquema da Figura 2.1 na notação de modelo de rede.14 CODASYL DBTG significa Conference on Data Systems Languages Database Task Group, que é o nome do comitê que especificou o modelo de rede e sua linguagem.34 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 34 11/30/10 5:23 PMregistro e dos tipos de conjunto, que são definidos pela posição atual do processo de navegação no ban-co de dados. Ela é usada predominantemente pelos sistemas IDMS, IMAGE e SUPRA nos dias de hoje.O modelo hierárquico representa os dados como estruturas de árvore hierárquicas. Cada hierarquia simboliza uma série de registros relacionados. Não existe uma linguagem-padrão para o modelo hierár-quico. Uma DML hierárquica popular é a DL/1 do sistema IMS. Ela dominou o mercado de SGBD por mais de 20 anos, entre 1965 e 1985, e ainda é um sistema muito usado no mundo inteiro, gerenciando uma grande porcentagem dos dados dos bancos de dados do governo, de serviços de saúde, de bancos e do setor de seguros. Sua DML, chamada DL/1, foi um padrão de fato na indústria por um longo tempo. Ela tem comandos para localizar um registro (por exemplo, GET {UNIQUE, NEXT} WHE-RE ) e facilidades para navegar nas hie-rarquias (por exemplo, GET NEXT WITHIN PARENT ou GET {FIRST, NEXT} PATH WHERE ). Possui funcio-nalidades para armazenar e atualizar registros (por exemplo, INSERT , REPLACE ). As questões relacionadas à posição do registro durante a navegação também são tratadas com outros recursos na linguagem.ResumoNeste capítulo, apresentamos os principais concei-tos usados em sistemas de banco de dados. Definimos um modelo de dados e destacamos três categorias principais: � Modelos de dados de alto nível ou conceituais (baseados em entidades e relacionamentos). � Modelos de dados de baixo nível ou físicos. � Modelos de dados representativos ou de imple-mentação (baseados em registro, orientados a objeto).Destacamos a separação do esquema, ou descrição de um banco de dados, do próprio banco de dados. O esque-ma não muda com muita frequência, enquanto o estado do banco de dados muda todas as vezes em que dados são inseridos, excluídos ou modificados. Depois, descrevemos a arquitetura de SGBD, que permite três níveis de esquema: � Um esquema interno que descreve a estrutura fí-sica do armazenamento do banco de dados. � Um esquema conceitual que é uma descrição de alto nível do banco de dados inteiro. � Esquemas externos que descrevem as visões de diferentes grupos de usuários.Um SGBD que separa nitidamente os três níveis pre-cisa ter mapeamentos entre os esquemas para transfor-mar solicitações e resultados das consultas de um nível para o seguinte. A maioria dos SGBDs não separa os três níveis completamente. Usamos a arquitetura de três es-quemas para definir os conceitos de independência lógica e física dos dados.Depois, discutimos os principais tipos de linguagens e interfaces que os SGBDs possuem. Uma linguagem de definição de dados (DDL) é usada para definir o esquema conceitual do banco de dados. Na maioria dos SGBDs, a DDL também define visões do usuário e, às vezes, es-truturas de armazenamento; em outros, existem lingua-gens ou funções separadas para especificar estruturas de armazenamento. Atualmente, essa distinção está desa-parecendo nas implementações relacionais, com a SQL servindo como uma linguagem geral para realizar vários papéis, incluindo definição de visões. A parte de defini-ção de armazenamento (SDL) foi incluída nas primeiras versões da SQL, mas agora costuma ser implementada como comandos especiais para o DBA nos SGBDs rela-cionais. O SGBD compila todas as definições do esquema e armazena suas descrições no catálogo do sistema.Uma linguagem de manipulação de dados (DML) é usada para especificar leituras e atualizações no banco de dados. As DMLs podem ser de alto nível (orientada a conjunto, não procedural) ou de baixo nível (orienta-da a registro, procedural). Uma DML de alto nível pode ser embutida em uma linguagem de programação hos-pedeira, ou pode ser usada como uma linguagem inde-pendente; nesse último caso, ela costuma ser chamada de linguagem de consulta.Discutimos os diferentes tipos de interfaces forne-cidas pelos SGBDs e os tipos de usuários com os quais cada interface está associada. Depois, abordamos o am-biente do sistema de banco de dados, módulos de software de SGBD típicos e utilitários de SGBD para ajudar os usuários e os DBAs a realizar suas tarefas. Continuamos com uma visão geral das arquiteturas de duas e três ca-madas para aplicações de banco de dados, progressiva-mente passando para n camadas, que agora são comuns em muitas aplicações, em especial nas aplicações de ban-co de dados da Web.Por fim, classificamos os SGBDs de acordo com vários critérios: modelo de dados, número de usuários, número de locais, tipos de caminhos de acesso e custo. Discutimos a disponibilidade dos SGBDs e módulos adi-cionais — desde nenhum custo, na forma de software de código aberto, até configurações que custam anualmente milhões de dólares para serem mantidas. Também indi-camos um conjunto variável de licença para os SGBDs e produtos relacionados. A principal classificação dos SGBDs é baseada no modelo de dados. Discutimos ra-pidamente os principais modelos de dados usados nos SGBDs disponíveis atualmente no mercado.Capítulo 2 Conceitos e arquitetura do sistema de banco de dados 3502 elmas0810_cap02 BR.indd 35 11/30/10 5:23 PMPerguntas de revisão 2.1. Defina os seguintes termos: modelo de dados, es-quema de banco de dados, estado de banco de dados, esquema interno, esquema conceitual, es-quema externo, independência de dados, DDL, DML, SDL, VDL, linguagem de consulta, lin-guagem hospedeira, sublinguagem de dados, uti-litário de banco de dados, catálogo, arquitetura cliente/servidor, arquitetura de três camadas e arquitetura de n camadas. 2.2. Discuta as principais categorias de modelos de dados. Quais são as diferenças básicas entre o modelo relacional, o de objeto e a XML? 2.3. Qual é a diferençaentre um esquema de banco de dados e um estado de banco de dados? 2.4. Descreva a arquitetura de três camadas. Por que precisamos de mapeamentos entre os níveis de esquema? Como diferentes linguagens de defini-ção de esquema dão suporte a essa arquitetura? 2.5. Qual é a diferença entre a independência lógica e a independência física dos dados? Qual é a mais difícil de se alcançar? Por quê? 2.6. Qual é a diferença entre DMLs procedurais e não procedurais? 2.7. Discuta os diferentes tipos de interfaces de fácil utilização e os tipos de usuários que normalmen-te utilizam cada tipo. 2.8. Com que outro software um SGBD interage? 2.9. Qual é a diferença entre as arquiteturas cliente/servidor de duas e três camadas? 2.10. Discuta alguns tipos de utilitários e ferramentas de banco de dados e suas funções. 2.11. Qual é a funcionalidade adicional na arquitetura de n camadas (n > 3)?Exercícios 2.12. Pense nos diferentes usuários para o banco de da-dos mostrado na Figura 1.2. De que tipos de aplicações cada usuário precisaria? A que cate-goria de usuário cada um pertenceria e de que tipo de interface cada um precisaria? 2.13. Escolha uma aplicação de banco de dados com a qual você esteja acostumado. Crie um esquema e mostre um exemplo de banco de dados para essa aplicação, usando a notação das figuras 1.2 e 2.1. Que tipos de informações e restrições adicionais você gostaria de representar no esque-ma? Pense nos diversos usuários de seu banco de dados e crie uma visão para cada tipo. 2.14. Se você estivesse criando um sistema baseado na Web para fazer reservas e vender passagens aéreas, qual arquitetura de SGBD você escolheria, com base na Seção 2.5? Por quê? Por que as outras ar-quiteturas não seriam uma boa escolha? 2.15. Considere a Figura 2.1. Além das restrições rela-cionando os valores das colunas de uma tabela às colunas de outra tabela, também existem restrições que impõem limitações sobre valores de uma colu-na ou uma combinação de colunas de uma tabela. Uma restrição desse tipo impõe que uma coluna ou um grupo de colunas deva ser exclusivo em to-das as linhas na tabela. Por exemplo, na tabela ALUNO, a coluna numero_aluno deve ser exclusiva (para impedir que dois alunos diferentes tenham o mesmo numero_aluno). Identifique a coluna ou o grupo de colunas das outras tabelas que precisam ser exclusivos em todas as linhas na tabela.Bibliografia selecionadaMuitos livros-texto de banco de dados, incluindo Date (2004), Silberschatz et al. (2006), Ramakrishnan e Gehrke (2003), Garcia-Molina et al. (2000, 2009) e Abi-teboul et al. (1995), oferecem uma discussão sobre os diversos conceitos de banco de dados apresentados aqui. Tsichritzis e Lochovsky (1982) é o livro-texto mais antigo sobre modelos de dados. Tsichritzis e Klug (1978) e Jardine (1977) apresentam a arquitetura de três esquemas, que foi sugerida inicialmente no relatório CODASYL DBTG de 1971 e, mais tarde, em um relatório do American Natio-nal Standards Institute (ANSI, instituto norte-americano de padrões) de 1975. Uma análise profunda do modelo de dados relacional e algumas de suas possíveis extensões são apresentadas em Codd (1990). O padrão proposto para bancos de dados orientados a objeto é descrito em Cattell et al. (2000). Muitos documentos descrevendo XML estão disponíveis na Web, como XML (2005).Alguns exemplos de utilitários de banco de dados são as ferramentas Connect, Analyze e Transform, da ETI (), e a ferramenta de adminis-tração de banco de dados, DBArtisan, da Embarcadero Technologies ().36 Sistemas de banco de dados02 elmas0810_cap02 BR.indd 36 11/30/10 5:23 PM 2Modelo de dados relacional e SQLparte03 elmas0810_cap03 BR.indd 37 11/30/10 5:23 PMEste capítulo abre a Parte 2 do livro, que aborda os bancos de dados relacionais. O modelo de dados relacional foi introduzido inicialmente por Ted Codd, da IBM Research, em 1970, em um artigo clássico (Codd, 1970), que atraiu atenção imediata devido a 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 monta-gem 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ási-cas do modelo e suas restrições.As primeiras implementações comerciais do mo-delo relacional se tornaram disponíveis no início da década de 1980, como o sistema SQL/DS no siste-ma operacional MVS, da IBM, e o SGBD, da Oracle. Desde então, o modelo foi implantado em uma gran-de quantidade de sistemas comerciais. Os SGBDs re-lacionais (SGBDRs) populares atuais incluem o DB2 e Informix Dynamic Server (da IBM), o Oracle e Rdb (da Oracle), o Sybase SGBD (da Sybase) e o SQLSer-ver e Access (da Microsoft). Além disso, vários siste-mas de código aberto, como MySQL e PostgreSQL, estão disponíveis.Por causa da importância do modelo relacional, toda a Parte 2 é dedicada a esse modelo e algumas das linguagens associadas a ele. Nos capítulos 4 e 5, descreveremos a linguagem de consulta SQL, que é o padrão para SGBDs relacionais comerciais. O Ca-pítulo 6 abordará as operações da álgebra relacional e introduzirá o cálculo relacional — essas são duas linguagens formais associadas ao modelo relacional. O cálculo relacional é considerado a base para a lin-guagem SQL, e a álgebra relacional é usada nos deta-lhes 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 relacional são apresentados em outras partes do livro. O Capí-tulo 9 abordará as estruturas de dados do modelo relacional para construções dos modelos ER e EER (apresentados nos capítulos 7 e 8), e apresentará algoritmos para projetar um esquema de banco de dados relacional mapeando um esquema conceitual no modelo ER ou EER para uma representação re-lacional. Esses mapeamentos são incorporados em muitas ferramentas de projeto de banco de dados e CASE.1 Os capítulos 13 e 14, na Parte 5, discutirão as técnicas de programação usadas para acessar sis-temas de banco de dados e a noção de conexão com bancos de dados relacionais por meio dos protoco-los-padrão ODBC e JDBC. O Capítulo 14 também apresentará o tópico de programação de banco de dados na Web. Os capítulos 15 e 16, na Parte 6, apresentarão outro aspecto do modelo relacional, a saber, as restrições formais das dependências fun-cionais e multivaloradas. Essas dependências são usadas para desenvolver uma teoria de projeto de banco de dados relacional baseada no conceito co-nhecido como normalização.Os modelos de dados que precederam o relacio-nal incluem os modelos hierárquico e de rede. Eles foram propostos na década de 1960 e implementa-dos nos primeiros SGBDs durante o final da década 1 CASE significa Computer-Aided Software Engineering (engenharia de software auxiliada por computador).cap ítulo 3O modelo de dados relacional e as restrições em bancos de dados relacionais03 elmas0810_cap03 BR.indd 38 11/30/10 5:23 PMde 1960 e início da década de 1970. Por causa de sua importância histórica e da existência da base de usuários para esses SGBDs, incluímos um re-sumo dos destaques desses modelos nos apêndices D e E, que estão disponíveis no site de apoio do livro (em inglês). Esses modelos e sistemas agora são conhecidos como sistemas de banco de dados legados.Neste capítulo, concentramo-nos em descrever os princípios básicos do modelo de dados relacional. Começamos definindo os conceitos de modelagem e a notação do modelo relacional na Seção 3.1. A Se-ção 3.2 é dedicada a uma discussão das restrições re-lacionais que são consideradas uma parte importante do modelo relacional e automaticamente impostas na maioria dos SGBDs relacionais. A Seção 3.3 define as operações de atualização domodelo relacional, dis-cute como as violações de restrições de integridade são tratadas e apresenta o conceito de uma transa-ção. No final há um resumo do capítulo.3.1 Conceitos do modelo relacionalO modelo relacional representa o banco de da-dos como uma coleção de relações. Informalmente, cada relação é semelhante a uma tabela de valores ou, até certo ponto, a um arquivo plano de registros. Ele é chamado de arquivo plano porque cada regis-tro tem uma simples estrutura linear ou plana. Por exemplo, o banco de dados de arquivos mostrado na Figura 1.2 é semelhante à representação do mode-lo relacional básico. No entanto, existem diferenças importantes entre relações e arquivos, conforme ve-remos 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 represen-ta um fato que normalmente corresponde a uma enti-dade ou relacionamento do mundo real. Os nomes da tabela e de 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 entida-de particular de aluno. Os nomes de coluna — Nome, Numero_aluno, Tipo_aluno e Curso — especificam como interpretar os valores de dados em cada linha, com base na coluna em que cada valor se encontra. Todos os va-lores em uma coluna são do mesmo tipo de dado.Na terminologia formal do modelo relacional, uma linha é chamada de tupla, um cabeçalho da co-luna é 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 é repre-sentado por um domínio de valores possíveis. Ago-ra, vamos definir esses termos — domínio, tupla, atributo e relação — de maneira formal.3.1.1 Domínios, atributos, tuplas e relaçõesUm domínio D é um conjunto de valores atômi-cos. Com atômico, queremos dizer que cada valor no domínio é indivisível em se tratando do modelo re-lacional formal. Um método comum de especificação 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 dez dígitos válidos no Brasil. � Numeros_telefone_local. O conjunto de núme-ros de telefone de oito dígitos válidos dentro de um código de área em particular no Brasil. O uso de números de telefone locais está rapida-mente se tornando obsoleto, sendo substituído por números padrão de dez dígitos. � Cadastro_pessoa_fisica. O conjunto de núme-ros do CPF com onze dígitos. (Esse é um identifi-cador exclusivo atribuído a cada pessoa no Bra-sil para fins de emprego, imposto e benefícios.) � Nomes. O conjunto de cadeia de caracteres que representam nomes de pessoas. � Medias_nota. Possíveis valores para calcular a média das notas; cada um deve ser um núme-ro real (ponto flutuante) entre 0 e 4. � Idades_funcionario. Idades possíveis dos fun-cionários em uma empresa; cada um deve ser um valor inteiro entre 15 e 80. � Nomes_departamento_academico. O conjun-to de nomes de departamentos acadêmicos em uma universidade, como Ciência da Com-putação, Economia e Física. � Codigos_departamento_academico. O conjun-to de códigos de departamentos acadêmicos, como ‘CC’, ‘ECON’ e ‘FIS’.Estas são chamadas definições lógicas de do-mínios. Um tipo de dado ou formato também é es-pecificado 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 caracte-res na forma (dd)dddd-dddd, onde 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 Idades_funcionario é um número inteiro entre 15 e 80. Para Nomes_departamento_academico, o tipo de dado é o conjunto de todas as cadeias de Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 3903 elmas0810_cap03 BR.indd 39 11/30/10 5:23 PMLuiz CarlosVenturaRealceLuiz CarlosVenturaRealceLuiz CarlosVenturaRealceLuiz CarlosVenturaRealcecaracteres 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 relacional R, indicado por R(A1, A2, ..., An), é composto de um nome de relação R e uma lista de atributos, A1, A2, ..., An. Cada atributo Ai é o nome de um papel desempenhado por algum domínio D no esquema de relação R. D é chamado de domínio de Ai, e indicado por dom(Ai). Um esque-ma de relação é usado para descrever uma relação; R é chamado de nome dessa relação. O grau (ou arida-de) de uma relação é o número de atributos n desse esquema de relação.Uma relação de grau sete, que armazena infor-mações sobre alunos universitários, teria sete atribu-tos descrevendo cada aluno, da seguinte forma:ALUNO(Nome, Cpf, Telefone_residencial, Ende-reco, Telefone_comercial, Idade, Media)Usando o tipo de dado de cada atributo, a defi-nição às vezes é escrita como:ALUNO(Nome: string, Cpf: string, Telefone_re-sidencial: string, Endereco: string, Telefone_co-mercial: string, Idade: integer, Media: real)Para este esquema de relação, ALUNO é o nome da relação, que tem sete atributos. Na definição ante-rior, mostramos a atribuição de tipos genéricos, como string ou inteiro, aos atributos. Mais precisamente, podemos especificar os seguintes domínios já defi-nidos para alguns dos atributos da relação ALUNO: dom(Nome) = Nomes; dom(Cpf) = Cadastro_pessoa_fisica; dom(Telefone_residencial) = Numeros_telefone_nacional,3 dom(Endereco), dom(Telefone_comercial) = Numeros_telefone_nacional e dom(Media) = Media. Também é possível referenciar atributos de um es-quema de relação por sua posição dentro da relação; assim, o segundo atributo da relação ALUNO é Cpf, enquanto o quarto atributo é Endereco.Uma relação (ou estado de relação)4 r do esque-ma de relação R(A1, A2, ..., An), também indicada por r(R), é um conjunto de n tuplas r = {t1, t2, ..., tm}. Cada n tuplas t é uma lista ordenada de n valores t = , em que cada valor vi, 1 ≤ i ≤ n, é um elemento de dom(Ai) ou é um valor especial NULL. (Valores NULL serão discutidos mais adiante, na Se-ção 3.1.2.) O valor i-ésimo na tupla t, que corresponde ao atributo Ai, é referenciado como t[Ai] ou t.Ai (ou t[i] se usarmos a notação posicional). Os termos in-tençã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 3.1 mostra um exemplo de uma relação ALUNO, que corresponde ao esquema ALUNO já espe-2Um esquema de relação às vezes é chamado de scheme de relação.3 Nos EUA, com o grande aumento nos números de telefone causado pela proliferação dos telefones móveis, a maioria das áreas metropolitanas agora possui vários códigos de área, de modo que a discagem local com sete dígitos foi descontinuada na maioria das áreas. Mudamos esse domínio para Numeros_telefone_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ância da relação. Não usaremos esse termo porque instância também é usado para se referir a uma única tupla ou linha.Figura 3.1Os atributos e tuplas de uma relação ALUNO.Nome Cpf Telefone_residencial Endereco Telefone_comercial Idade MediaBruno Braga 305.610.243-51 (17)3783-1616 Rua das Paineiras, 2918 NULL 19 3,21Carlos Kim 381.620.124-45 (17)3785-4409 Rua das Goiabeiras, 125 NULL 18 2,89Daniel Davidson295Resumo .......................................................... 300Perguntas de revisão ....................................... 300Exercícios ....................................................... 300Bibliografia selecionada .................................. 300Parte 5: Técnicas de programação de banco de dados .....................................301Capítulo 13 Introdução às técnicas de programação SQL .................. 30213.1 Programação de banco de dados: técnicas e problemas ............................................ 30313.2 SQL embutida, SQL dinâmica e SQLJ ... 30513.3 Programação de banco de dados com chamadas de função: SQL/CLI e JDBC ... 31413.4 Procedimentos armazenados de banco de dados e SQL/PSM ................................ 32013.5 Comparando as três técnicas ............... 322Resumo .......................................................... 323Perguntas de revisão ....................................... 323Exercícios ....................................................... 323Bibliografia selecionada .................................. 324Capítulo 14 Programação de banco de dados Web usando PHP ....................32514.1 Um exemplo simples em PHP .............. 32514.2 Visão geral dos recursos básicos da PHP .. 32714.3 Visão geral da programação de banco de dados em PHP ..................................... 332Resumo .......................................................... 335Perguntas de revisão ....................................... 335Exercícios ....................................................... 335Bibliografia selecionada .................................. 335Parte 6: Teoria e normalização de projeto de banco de dados .......................... 336Capítulo 15 Fundamentos de dependências funcionais e normalização para bancos de dados relacionais ...33715.1 Diretrizes de projeto informais para esquemas de relação ............................ 33815.2 Dependências funcionais ..................... 34615.3 Formas normais baseadas em chaves primárias ............................................. 34715.4 Definições gerais da segunda e terceira formas normais ................................... 35315.5 Forma normal de Boyce-Codd ............. 35515.6 Dependência multivalorada e quarta forma normal ................................................. 35715.7 Dependências de junção e quinta forma normal ................................................. 359Resumo .......................................................... 360Perguntas de revisão ....................................... 360Sumário ix00 elmas0810_iniciais BR.indd 9 11/30/10 5:27 PMExercícios ....................................................... 361Exercício de laboratório ................................. 363Bibliografia selecionada .................................. 363Capítulo 16 Algoritmos de projeto de banco de dados relacional e demais dependências ....................... 36416.1 Outros tópicos em dependências funcionais: regras de inferência, equivalência e cobertura mínima ......... 36516.2 Propriedades de decomposições relacionais ........................................... 36916.3 Algoritmos para projeto de esquema de banco de dados relacional ................... 37416.4 Sobre nulos, tuplas suspensas e projetos relacionais alternativos ........................ 37716.5 Discussão adicional sobre dependências multivaloradas e 4FN .......................... 38116.6 Outras dependências e formas normais .. 383Resumo .......................................................... 385Perguntas de revisão ....................................... 386Exercícios ....................................................... 386Exercícios de laboratório ............................... 387Bibliografia selecionada .................................. 387Parte 7: Estruturas de arquivo, indexação e hashing ...................................... 388Capítulo 17 Armazenamento de disco, estruturas de arquivo básicas e hashing .....38917.1 Introdução ........................................... 38917.2 Dispositivos de armazenamento secundários .......................................... 39217.3 Buffering de blocos .............................. 39717.4 Gravando registros de arquivo no disco .. 39717.5 Operações em arquivos ....................... 40117.6 Arquivos de registros desordenados (arquivos de heap) ............................... 40317.7 Arquivos de registros ordenados (arquivos classificados) ........................................ 40417.8 Técnicas de hashing ............................. 40617.9 Outras organizações de arquivo primárias ............................................. 41417.10 Paralelizando o acesso de disco usando tecnologia RAID ................................ 41517.11 Novos sistemas de armazenamento ... 418Resumo .......................................................... 419Perguntas de revisão ....................................... 420Exercícios ....................................................... 421Bibliografia selecionada .................................. 423Capítulo 18 Estruturas de indexação para arquivos ................................ 42418.1 Tipos de índices ordenados de único nível ..42418.2 Índices multiníveis ............................... 43318.3 Índices multiníveis dinâmicos usando B-trees e B+-trees .................................. 43518.4 Índices em chaves múltiplas ................. 44518.5 Outros tipos de índices ........................ 44718.6 Algumas questões gerais referentes à indexação ............................................ 450Resumo .......................................................... 452Perguntas de revisão ....................................... 453Exercícios ....................................................... 453Bibliografia selecionada .................................. 455Parte 8: Processamento de consulta, otimização e ajuste de banco de dados ......................................... 456Capítulo 19 Algoritmos para processamento e otimização de consulta ...........45719.1 Traduzindo consultas SQL para álgebra relacional ............................................. 45919.2 Algoritmos para ordenação externa ..... 45919.3 Algoritmos para operações SELEÇÃO e JUNÇÃO .............................................. 46119.4 Algoritmos para operações PROJEÇÃO e de conjunto ......................................... 46919.5 Implementando operações de agregação e JUNÇÃO EXTERNA ............................. 47019.6 Combinando operações com pipelining .. 47219.7 Usando a heurística na otimização da consulta ............................................... 47219.8 Usando seletividade e estimativas de custo na otimização da consulta ................... 47919.9 Visão geral da otimização da consulta no Oracle ................................................. 48719.10 Otimização de consulta semântica ..... 487Resumo .......................................................... 488Perguntas de revisão ....................................... 488Exercícios ....................................................... 488Bibliografia selecionada .................................. 489Capítulo 20 Projeto físico e ajuste de banco de dados .............................. 49020.1 Projeto físico em bancos de dados relacionais ........................................... 49020.2 Visão geral do ajuste de banco de dados em sistemas relacionais ............................. 494Resumo .......................................................... 498x Sistemas de banco de dados00 elmas0810_iniciais BR.indd 10 11/30/10 5:27 PMPerguntas de revisão ....................................... 498Bibliografia selecionada .................................. 498Parte 9: Processamento de transações, controle de concorrência e recuperação422.111.232-70 NULL Avenida da Paz, 3452 (17)4749-1253 25 3,53Roberta Passos 489.220.110-08 (17)3476-9821 Rua da Consolação, 265 (17)3749-6492 28 3,93Barbara Benson 533.690.123-80 (17)3239-8461 Rua Jardim, 7384 NULL 19 3,25AtributosNome da relaçãoALUNOTuplas40 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 40 11/30/10 5:23 PMLuiz CarlosVenturaRealceLuiz CarlosVenturaRealceLuiz CarlosVenturaNotaParei aqui 20/08 17:10cificado. Cada tupla na relação representa uma entida-de de aluno em particular (ou objeto). Apresentamos a relação como uma tabela, onde cada tupla aparece como uma linha e cada atributo corresponde a um ca-beçalho de coluna, indicando um papel ou interpreta-ção dos valores nesta coluna. Valores NULL represen-tam 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 se segue. Uma relação (ou estado de relação) r(R) é uma relação matemática de grau n sobre os domínios dom(A1), dom(A2), ..., dom(An), que é um subconjunto do produto carte-siano (indicado por ×) dos domínios que definem R:r(R) ⊆ (dom(A1) × dom(A2) × ... × dom(An))O produto cartesiano especifica todas as combi-nações possíveis de valores dos domínios subjacen-tes. Logo, se indicarmos o número total de valores, ou cardinalidade, em um domínio D como |D| (consi-derando que todos os domínios são finitos), o núme-ro total de tuplas no produto cartesiano é|dom(A1)| × |dom(A2)| × ... × |dom(An)|Esse produto de cardinalidades de todos os do-mínios representa o número total de possíveis ins-tâ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 determinado mo-mento — o estado de relação atual — reflete ape-nas as tuplas válidas que representam um estado em particular do mundo real. Em geral, à medida que o estado do mundo real muda, também muda o esta-do 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 armazenadas originalmente na relação.É 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_te-lefone_nacional desempenha o papel de Telefone_re-sidencial, 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 po-deria ser Telefone_celular.3.1.2 Características das relaçõesA definição dada de relações implica certas ca-racterí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. Ma-tematicamente, os elementos de um conjunto não possuem ordem entre eles; logo, as tuplas em uma relação não possuem nenhuma ordem em particu-lar. 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 o primeiro, segun-do, i-nésimo e último registros no arquivo. De modo semelhante, quando exibimos 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 fa-tos 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 3.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 pre-ferência para ordenação de qualquer outra relação. Logo, a relação apresentada na Figura 3.2 é conside-Nome Cpf Telefone_residencialEndereco Telefone_comercialIdade MediaDaniel Davidson 422.111.232-70 NULL Avenida da Paz, 3452 (17)4749-1253 25 3,53Barbara Benson 533.690.123-80 (17)3239-8461 Rua Jardim, 7384 NULL 19 3,25Roberta Passos 489.220.110-08 (17)3476-9821 Rua da Consolação, 265 (17)3749-6492 28 3,93Carlos Kim 381.620.124-45 (17)3785-4409 Rua das Goiabeiras, 125 NULL 18 2,89Bruno Braga 305.610.243-51 (17)3783-1616 Rua das Paineiras, 2918 NULL 19 3,21ALUNOFigura 3.2A relação ALUNO da Figura 3.1 com uma ordem de tuplas diferente.Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 4103 elmas0810_cap03 BR.indd 41 11/30/10 5:23 PMrada idêntica àquela mostrada na Figura 3.1. Quan-do uma relação é implementada como um arquivo ou exibida como uma tabela, uma ordenação em particu-lar pode ser especificada sobre os registros do arquivo ou das linhas da tabela.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 ordenada 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 de uma relação pode ser dada, tornando a ordem dos valores em uma tu-pla desnecessária. Nessa definição, um esquema de relação R = {A1, A2, ..., An} é um conjunto de atri-butos (em vez de uma lista), e um estado de relação r(R) é um conjunto finito de mapeamentos r = {t1, t2, ..., tm}, onde cada tupla ti é um mapeamento de R para D, e D é a união (indicada por ∪) dos domí-nios de atributo; ou seja, D = dom(A1) ∪ dom(A2) ∪ ... ∪ dom(An). Nessa definição, t[Ai] deve estar em dom(Ai) para 1 ≤ i ≤ n 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 considera-da um conjunto de pares (, ), em que cada par dá o valor do mapeamento a partir de um atributo Ai para um valor vi de dom(Ai). A or-dem dos atributos não é importante, pois o nome do atributo aparece com seu valor. Por essa definição, as duas tuplas mostradas na Figura 3.3 são idênticas. Isso faz sentido em um nível abstrato, já que não há realmente motivo para preferir ter um valor de atri-buto aparecendo antes de outro em uma tupla.Quando uma relação é implementada como um arquivo, os atributos são fisicamente ordenados como campos dentro de um registro. Geralmente, usaremos a primeira definição da relação, onde os atributos e os valores dentro das tuplas são ordenados, porque isso simplifica grande parte da notação. Porém, a defini-ção alternativa dada aqui é mais geral.5Valores e NULLs nas tuplas. Cada valor em uma tupla é um valor atômico; ou seja, ele não é di-visível em componentes dentro da estrutura do mo-delo relacional básica. Logo, atributos compostos ou multivalorados (ver Capítulo 7) não são permitidos. Esse modelo às vezes é chamado de modelo relacio-nal plano. Grande parte da teoria por trás do mo-delo relacional foi desenvolvida com essa suposição em mente, que é chamada pressuposto da primeira forma normal.6 Assim, atributos multivalorados pre-cisam ser representados por relações separadas, e os atributos compostos são representados apenas por seus atributos de componentes simples no modelo relacional básico.7Um conceito importante é o dos valores NULL, que são usados para representar os valores de atribu-tos que podem ser desconhecidos ou não se aplicam a uma tupla. Um valor especial, chamado NULL, é usadonesses casos. Por exemplo, na Figura 3.1, algu-mas tuplas ALUNO têm NULL para seus telefones co-merciais, pois eles não trabalham (ou seja, o telefone comercial não se aplica a esses alunos). Outro aluno tem um NULL para o telefone residencial, talvez por-que ele não tenha um telefone residencial ou ele tem, mas nós não o conhecemos (o valor é desconhecido). Em geral, podemos ter vários significados para va-lores 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 indefini-do). Um exemplo do último tipo de NULL ocorrerá se acrescentarmos um atributo Tipo_visto (tipo do vis-to) à relação ALUNO, que se aplica apenas a tuplas que representam alunos estrangeiros. É possível criar diferentes códigos para diversos significados de valo-res NULL. A incorporação de diferentes tipos de valores NULL nas operações do modelo relacional (ver Capí-tulo 6) provou ser muito difícil e, portanto, está fora do escopo de nossa apresentação.t = t = Figura 3.3Duas tuplas idênticas quando a ordem dos atributos e valores não faz parte da definição da relação.5 Como veremos, a definição alternativa da relação será útil quando discutirmos o processamento e a otimização da consulta no Capítulo 19.6 Discutiremos esse pressuposto da primeira forma normal com mais detalhes no Capítulo 15.7 Extensões do modelo relacional removem essas restrições. Por exemplo, os sistemas objeto-relacional (Capítulo 11) permitem atributos estruturados complexos, assim como os modelos relacionais não de primeira forma normal ou aninhados.42 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 42 11/30/10 5:23 PMO significado exato de um valor NULL determina como ele será aplicado durante agregações aritméti-cas ou comparações com outros valores. Por exem-plo, 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 têm o mesmo ende-reço. Durante o projeto do banco de dados, é melhor evitar ao máximo valores NULL. Discutiremos isso melhor nos capítulos 5 e 6, no contexto de operações e consultas, e no Capítulo 15, 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 interpretado como uma declaração ou um tipo de afirmação (ou asserção). Por exemplo, o esquema da relação ALUNO da Figura 3.1 afirma que, em geral, uma entidade de aluno tem um Nome, Cpf, Telefone_residencial, Endereco, Telefone_co-mercial, Idade e Media. Cada tupla na relação pode en-tão ser interpretada como um fato ou uma instância em particular da afirmação. Por exemplo, a primeira tupla na Figura 3.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 represen-tar fatos sobre entidades, enquanto outras podem re-presentar fatos sobre relacionamentos. Por exemplo, um esquema de relação CURSAR (Cpf_aluno, Codi-go_disciplina) afirma que os alunos cursaram discipli-nas acadêmicas. Uma tupla nessa relação relaciona um aluno a disciplina cursada. Logo, o modelo rela-cional representa fatos sobre entidades e relaciona-mentos 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. Apresentaremos o mo-delo Entidade-Relacionamento (ER) com detalhes no Capítulo 7, no qual os conceitos de entidade e rela-cionamento serão descritos minuciosamente. Os pro-cedimentos de mapeamento no Capítulo 9 mostram como diferentes construções dos modelos de dados conceituais ER e EER (modelo ER estendido, abor-dado no Capítulo 8, na Parte 3) são convertidas em relações.Uma interpretação alternativa de um esquema de relação é como um predicado; nesse caso, os va-lores em cada tupla são interpretados como valores que satisfazem o predicado. Por exemplo, o predica-do ALUNO (Nome, Cpf, ...) é verdadeiro para as cinco tuplas na relação ALUNO da Figura 3.1. Essas tuplas representam cinco proposições ou fatos diferentes no mundo real. Essa interpretação é muito útil no con-texto das linguagens de programação lógicas, como Prolog, pois permite que o modelo relacional seja usado nessas linguagens (ver Seção 26.5). Um pressu-posto, chamado pressuposto do mundo fechado, afir-ma que os únicos fatos verdadeiros no universo são aqueles presentes dentro da extensão (estado) da(s) relação(ões). Qualquer outra combinação de valores torna o predicado falso.3.1.3 Notação do modelo relacionalUsaremos a seguinte notação em nossa represen-tação: � Um esquema de relação R de grau n é indica-do por R(A1, A2, ..., An). � As letras maiúsculas Q, R, S indicam nomes de relação. � As letras minúsculas q, r, s indicam estados de relação. � As letras t, u, v indicam tuplas. � Em geral, o nome de um esquema de relação, como ALUNO, também indica o conjunto atu-al de tuplas nessa relação — o estado de rela-ção atual —, enquanto ALUNO(Nome, Cpf, ...) refere-se apenas ao esquema de relação. � Um atributo A pode ser qualificado com o nome de relação R ao qual pertence usando a notação de ponto R.A — por exemplo, ALUNO.Nome ou ALUNO.Idade. Isso porque o mesmo nome pode ser usado para dois atributos em relações diferentes. Contudo, todos os nomes de atributo em uma relação em particular precisam ser distintos. � Uma n-tupla t em uma relação r(R) é indica-da por t = , onde vi é o valor correspondente ao atributo Ai. A notação a seguir refere-se a valores componentes de tu-plas: � Tanto t[Ai] quanto t.Ai (e às vezes t[i]) refe-rem-se ao valor vi em t para o atributo Ai. � Tanto t[Au, Aw, ..., Az] quanto t.(Au, Aw, ..., Az), onde Au, Aw, ..., Az é uma lista de atribu-tos de R, que referem-se à subtupla de valores de t correspondentes aos atri-butos especificados na lista.Como um exemplo, considere a tupla t = da relação ALUNO na Figura 3.1; temos t[Nome] = e t[Cpf, Media, Idade] = .Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 4303 elmas0810_cap03 BR.indd 43 11/30/10 5:23 PM3.2 Restrições em modelo relacional e esquemas de bancos de dados relacionaisAté aqui, discutimos as características de relações isoladas. No banco de dados relacional, normalmen-te haverá muitas relações, e as tuplas nessas relações costumam estar relacionadas de várias maneiras. O estado do banco de dados inteiro corresponderá 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 repre-senta, conforme discutimos 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 relacional na forma de restrições. As restrições nos bancos de dados geralmente podem ser divididas em três categorias principais: 1. Restrições que são inerentes no modelo de da-dos. Chamamos estas de restrições inerentes baseadas no modelo ou restrições implícitas. 2. Restrições que podem ser expressas direta-mente nos esquemas do modelo de dados, em geral especificando-as na DDL (linguagem de definição de dados; ver Seção 2.3.1). Chama-mos estas de restrições baseadasem esquema ou restrições explícitas. 3. Restrições que não podem ser expressas dire-tamente nos esquemas do modelo de dados, e, portanto, devem ser expressas e impostas pelos programas de aplicação. Chamamos estas de restrições baseadas na aplicação ou restrições semânticas ou regras de negócios.As características das relações que discutimos na Seção 3.1.2 são as restrições inerentes do mode-lo relacional 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 que podem ser expressas no esquema do modelo relacional por meio da DDL. As restrições da terceira categoria são mais gerais, relacionam-se ao significado e também ao compor-tamento dos atributos, e são difíceis de expressar e impor dentro do modelo de dados, de modo que nor-malmente são verificadas nos programas de aplica-ção que realizam as atualizações no banco de dados.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 pro-jeto de um banco de dados relacional e em um pro-cesso chamado normalização, que será discutido nos capítulos 15 e 16.As restrições baseadas em esquema incluem res-trições de domínio, restrições de chave, restrições so-bre NULLs, restrições de integridade de entidade e restrições de integridade referencial.3.2.1 Restrições de domínioAs 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 maneiras como os domínios podem ser especifi-cados na Seção 3.1.1. Os tipos de dados associados aos domínios normalmente incluem os tipos de da-dos numéricos padrão para inteiros (como short in-teger, integer e long integer) e números reais (float e double). 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 possíveis 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 explicitamente listados. Em vez de descrevê-los com detalhes aqui, discutiremos os tipos de dados oferecidos pelo pa-drão relacional SQL na Seção 4.1.3.2.2 Restrições de chave e restrições sobre valores NULLNo modelo relacional formal, uma relação é de-finida como um conjunto de tuplas. Por definição, to-dos os elementos de um conjunto são distintos; logo, todas 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 subconjun-tos de atributos de um esquema de relação R com a propriedade de que duas tuplas em qualquer estado de relação r de R não deverão ter a mesma combi-nação de valores para esses atributos. Suponha que indiquemos um subconjunto de atributos desse tipo como SCh; então, para duas tuplas distintas quais-quer t1 e t2 em um estado de relação r de R, temos a restrição de que:t1[SCh] ≠ t2[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 exclusivi-dade 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 44 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 44 11/30/10 5:23 PMconjunto 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 re-lação não podem ter valores idênticos para (to-dos) os atributos na chave. Essa primeira pro-priedade também se aplica a uma superchave. 2. Ela é uma superchave mínima — ou seja, uma superchave da qual não podemos remover ne-nhum atributo e ainda mantemos uma restri-ção de exclusividade na condição 1. Essa pro-priedade não é exigida por uma superchave.Embora a primeira propriedade se aplique a cha-ves e superchaves, a segunda propriedade é exigida apenas para chaves. Assim, uma chave também é uma superchave, mas não o contrário. Considere a relação ALUNO da Figura 3.1. O conjunto de atribu-tos {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 supercha-ve. No entanto, a superchave {Cpf, Nome, Idade} não é uma chave de ALUNO, pois remover Nome ou Ida-de, ou ambos, do conjunto ainda nos deixa com uma superchave. Em geral, qualquer superchave formada com base em um único atributo também é uma cha-ve. Uma chave com múltiplos atributos precisa exigir que todos os seus atributos juntos tenham uma pro-priedade 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 exclusivamente a tupla correspondente a Bruno Braga na relação ALUNO. Observe que um conjunto de 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 é deter-minada com base no significado dos atributos, e a propriedade é invariável no tempo: ela precisa per-manecer verdadeira quando inserimos novas tuplas na relação. Por exemplo, não podemos e não deve-mos designar o atributo Nome da relação ALUNO da Figura 3.1 como uma chave porque é possível que dois alunos com nomes idênticos existam em algum ponto em um estado válido.9Em 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 3.4 tem duas chaves candi-datas: Placa e Numero_chassi. É comum designar uma das chaves candidatas como chave primária da relação. Essa é a chave candidata cujos valores são usados para identificar tuplas na relação. Usa-mos a convenção de que os atributos que formam a chave primária de um esquema de relação são su-blinhados, como mostra a Figura 3.4. Observe que, quando um esquema de relação tem várias chaves candidatas, a escolha de uma para se tornar a chave primária é um tanto quanto arbitrária; porém, nor-malmente é melhor escolher uma chave primária com um único atributo ou um pequeno número de atributos. As outras chaves candidatas são desig-nadas como chaves únicas (unique keys), e não são sublinhadas.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áli-do, diferente de NULL, para o atributo Nome, então Nome de ALUNO é restrito a ser NOT NULL.3.2.3 Bancos de dados relacionais e esquemas de banco de dados relacionalAs definições e restrições que discutimos até aqui se aplicam a relações isoladas e seus atributos. Um 8 Observe que Cpf também é 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 esses nomes idênticos.CARROPlaca Numero_chassi Marca Modelo AnoItatiaia ABC-7039 A6935207586 Volkswagen Gol 02Itu TVP-3470 B4369668697 Chevrolet Corsa 05Santos MPO-2902 X8355447376 Fiat Uno 01Itanhaem TFY-6858 C4374268458 Chevrolet Celta 99ItatibaRSK-6279 Y8293586758 Renault Clio 04Atibaia RSK-6298 U0283657858 Volkswagen Parati 04Figura 3.4A relação CARRO, com duas chaves candidatas: Placa e Numero_chassi.Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 4503 elmas0810_cap03 BR.indd 45 11/30/10 5:23 PMbanco de dados relacional costuma conter muitas re-lações, com tuplas nas relações que estão relaciona-das de várias maneiras. Nesta seção, definimos um banco de dados relacional e um esquema de banco de dados relacional.Um esquema de banco de dados relacional S é um conjunto de esquemas de relação S = {R1, R2, ..., Rm} e um conjunto de restrições de integridade RI. Um estado de banco de dados relacional10 DB de S é um conjunto de estados de relação DB = {r1, r2, ..., rm}, tal que cada ri é um estado de Ri e tal que os estados da relação ri satisfazem as restrições de integridade es-pecificadas em RI. A Figura 3.5 mostra um esquema de banco de dados relacional que chamamos de EM-PRESA = {FUNCIONARIO, DEPARTAMENTO, LOCA-LIZACAO_DEP, PROJETO, TRABALHA_EM, DEPEN-DENTE}. Os atributos sublinhados representam chaves primárias. A Figura 3.6 mostra um estado de banco de dados relacional correspondente ao esquema EM-PRESA. Usaremos esse esquema e estado de banco de dados neste capítulo e nos capítulos 4 a 6 para desen-volver consultas de exemplo em diferentes linguagens relacionais.Quando nos referimos a um banco de dados relacional, 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 integrida-de é chamado de estado inválido, e um estado que satisfaz a todas as restrições no conjunto definido de restrições de integridade RI é chamado de esta-do válido.Na Figura 3.5, o atributo Dnumero em DEPAR-TAMENTO e LOCALIZACAO_DEP significa o conceito do mundo real — o número dado a um departamen-to. O mesmo conceito é chamado Dnr em FUNCIO-NARIO e Dnum em PROJETO. Os atributos que re-presentam o mesmo conceito do mundo real podem ou não ter nomes idênticos em diferentes relações. Como alternativa, os atributos que representam di-ferentes conceitos podem ter o mesmo nome em dife-rentes relações. Por exemplo, poderíamos ter usado o nome de atributo Nome para Projnome de PROJETO e Dnome de DEPARTAMENTO; nesse caso, teríamos dois atributos compartilhando o mesmo nome, mas representando diferentes conceitos do mundo real — nomes de projeto e nomes de departamento.FUNCIONARIOPnome Minicial Unome Cpf Datanasc Endereco Sexo Salario Cpf_supervisor DnrdepARtAmeNtOLOCALIZACAO_deppROJetOtRABALHA_emdepeNdeNteDnome Dnumero Cpf_gerente Data_inicio_gerenteProjnome Projnumero Projlocal DnumFcpf Pnr HorasFcpf Nome_dependente Sexo Datanasc ParentescoDnumero DlocalFigura 3.5Diagrama de esquema para o esquema de banco de dados relacional EMPRESA.10 Um estado de banco de dados relacional às vezes é chamado de instância de banco de dados relacional. No entanto, como mencionamos anteriormente, não usaremos o termo instância porque ele também se aplica a tuplas isoladas.46 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 46 11/30/10 5:23 PMEm algumas versões antigas do modelo relacio-nal, era feita uma suposição de que o mesmo con-ceito 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 con-ceito de Cadastro de Pessoa Física aparece duas vezes na relação FUNCIONARIO da Figura 3.5: uma no pa-pel 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 relacional precisa ter uma linguagem de definição de dados (DDL) para estabelecer um es-quema de banco de dados relacional. Os SGBDs rela-cionais atuais costumam usar principalmente SQL para essa finalidade. Apresentaremos a DDL SQL nas se-ções 4.1 e 4.2.Restrições de integridade são especificadas em um esquema de banco de dados e espera-se que sejam mantidas em cada estado de banco de dados válido desse esquema. Além das restrições de domínio, cha-ve e NOT NULL, dois outros tipos de restrições são considerados parte do modelo relacional: integridade de entidade e integridade referencial.3.2.4 Integridade, integridade referencial e chaves estrangeirasA restrição de integridade de entidade afirma que nenhum valor de chave primária pode ser NULL. Isso porque o valor da chave primária é usado para identificar tuplas individuais em uma relação. Ter va-lores 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 conseguiríamos distingui-las ao tentar referenciá-las por outras relações.As restrições de chave e as restrições de inte-gridade de entidade são especificadas sobre relações individuais. A restrição de integridade referencial é especificada entre duas relações e usada para man-ter a consistência entre tuplas nas duas relações. In-formalmente, a restrição de integridade referencial afirma que uma tupla em uma relação que referen-cia outra relação precisa se referir a uma tupla exis-tente nessa relação. Por exemplo, na Figura 3.6, o atributo Dnr de FUNCIONARIO fornece o número de departamento para o qual cada funcionário trabalha; logo, seu valor em cada tupla FUNCIONARIO precisa combinar com o valor de Dnumero de alguma tupla na relação DEPARTAMENTO.Para definir a integridade referencial de maneira mais formal, primeiro estabelecemos o conceito de uma chave estrangeira (ChE — foreign key). As con-dições para uma chave estrangeira, dadas a seguir, especificam a restrição de integridade referencial en-tre os dois esquemas de relação R1 e R2. Um conjunto de atributos ChE no esquema de relação R1 é uma chave estrangeira de R1 que referencia a relação R2 se ela satisfizer as seguintes regras: 1. Os atributos em ChE têm o mesmo domínio (ou domínios) que os atributos de chave pri-mária ChP de R2; diz-se que os atributos ChE referenciam ou referem-se à relação R2. 2. Um valor de ChE em uma tupla t1 do estado atual r1(R1) ocorre como um valor de ChE para alguma tupla t2 no estado atual r2(R2) ou é NULL. No primeiro caso, temos t1[ChE] = t2[ChP], e dizemos que a tupla t1 referencia ou refere-se à tupla t2.Nessa definição, R1 é chamada de relação que referencia e R2 é a relação referenciada. Se essas con-dições se mantiverem, diz-se que é mantida uma res-trição de integridade referencial de R1 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 deve-mos ter um conhecimento claro do significado ou pa-pel que cada atributo, ou conjunto de atributos, que fazem parte nos diversos esquemas de relação do ban-co de dados. As restrições de integridade referencial surgem com frequência dos relacionamentos entre as entidades representadas pelos esquemas de relação. Por exemplo, considere o banco de dados mostrado na Figura 3.6. Na relação FUNCIONARIO, o atributo Dnr refere-se ao departamento para o qual um fun-cionário trabalha; portanto, designamos Dnr para ser a chave estrangeira de FUNCIONARIO que referencia a relação DEPARTAMENTO. Isso significa que um valor de Dnr em qualquer tupla t1 da relação FUNCIONARIO precisa combinar com um valor da chave primária de DEPARTAMENTO — o atributo Dnumero — em algu-ma tupla t2 da relação DEPARTAMENTO, ou o valor de Dnr pode ser NULL se o funcionário não pertencer a um departamento ou for atribuído a um departa-mento mais tarde. Por exemplo, na Figura 3.6, a tupla para o funcionário ‘João Silva’ referencia a tupla parao departamento ‘Pesquisa’, indicando que ‘João Silva’ trabalha para esse departamento.Observe que uma chave estrangeira pode se re-ferir a sua própria relação. Por exemplo, o atributo Cpf_supervisor em FUNCIONARIO refere-se ao super-visor de um funcionário; este é outro funcionário, re-presentado por uma tupla na relação FUNCIONARIO. Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 4703 elmas0810_cap03 BR.indd 47 11/30/10 5:23 PMPnome Minicial Unome Cpf Datanasc Endereco Sexo Salario Cpf_supervisor DnrJoão B Silva 12345678966 09-01-1965 Rua das Flores, 751, São Paulo, SP M 30.000 33344555587 5Fernando T Wong 33344555587 08-12-1955 Rua da Lapa, 34, São Paulo, SP M 40.000 88866555576 5Alice J Zelaya 99988777767 19-01-1968 Rua Souza Lima, 35, Curitiba, PR F 25.000 98765432168 4Jennifer S Souza 98765432168 20-06-1941 Av. Arthur de Lima, 54, Santo André, SP F 43.000 88866555576 4Ronaldo K Lima 66688444476 15-09-1962 Rua Rebouças, 65, Piracicaba, SP M 38.000 33344555587 5Joice A Leite 45345345376 31-07-1972 Av. Lucas Obes, 74, São Paulo, SP F 25.000 33344555587 5André V Pereira 98798798733 29-03-1969 Rua Timbira, 35, São Paulo, SP M 25.000 98765432168 4Jorge E Brito 88866555576 10-11-1937 Rua do Horto, 35, São Paulo, SP M 55.000 NULL 1FUNCIONARIODnome Dnumero Cpf_gerente Data_inicio_gerentePesquisa 5 33344555587 22-05-1988Administração 4 98765432168 01-01-1995Matriz 1 88866555576 19-06-1981Projnome Projnumero Projlocal DnumProdutoX 1 Santo André 5ProdutoY 2 Itu 5ProdutoZ 3 São Paulo 5Informatização 10 Mauá 4Reorganização 20 São Paulo 1Novosbenefícios 30 Mauá 4Fcpf Nome_dependente Sexo Datanasc Parentesco33344555587 Alicia F 05-04-1986 Filha33344555587 Tiago M 25-10-1983 Filho33344555587 Janaína F 03-05-1958 Esposa98765432168 Antonio M 28-02-1942 Marido12345678966 Michael M 04-01-1988 Filho12345678966 Alicia F 30-12-1988 Filha12345678966 Elizabeth F 05-05-1967 EsposaFcpf Pnr Horas12345678966 1 32,512345678966 2 7,566688444476 3 40,045345345376 1 20,045345345376 2 20,033344555587 2 10,033344555587 3 10,033344555587 10 10,033344555587 20 10,099988777767 30 30,099988777767 10 10,098798798733 10 35,098798798733 30 5,098765432168 30 20,098765432168 20 15,088866555576 20 NULLDnumero Dlocal1 São Paulo4 Mauá5 Santo André5 Itu5 São PaulodepARtAmeNtO LOCALIZACAO_deptRABALHA_em pROJetOdepeNdeNteFigura 3.6Um estado de banco de dados possível para o esquema de banco de dados relacional EMPRESA.Logo, Cpf_supervisor é uma chave estrangeira que referencia a própria relação FUNCIONARIO. Na Figura 3.6, a tupla que o funcionário ‘João Silva’ re-ferencia é a tupla do funcionário ‘Fernando Wong’, indicando que ‘Fernando Wong’ é o supervisor de ‘João Silva’.Podemos exibir em forma de diagrama as restri-ções de integridade referencial, 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 3.7 mostra o esquema da Fi-48 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 48 11/30/10 5:23 PMgura 3.5 com as restrições de integridade referencial mostradas dessa maneira.Todas as restrições de integridade deverão ser es-pecificadas no esquema de banco de dados relacional (ou seja, definidas como parte de sua definição) se quisermos impor essas restrições sobre os estados do banco de dados. Logo, a DDL inclui meios para es-pecificar os diversos tipos de restrições de modo que o SGBD possa impô-las automaticamente. A maioria dos SGBDs relacionais admite restrições de chave, in-tegridade de entidade e integridade referencial. Essas restrições são especificadas como uma parte da defi-nição de dados na DDL.3.2.5 Outros tipos de restriçõesAs restrições de integridade anteriores estão in-cluídas na linguagem de definição de dados porque ocorrem na maioria das aplicações de banco de da-dos. 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 espe-cificadas e impostas em um banco de dados relacio-nal. Alguns exemplos dessas restrições são o salário de um funcionário não deve ser superior ao salário de seu supervisor e o número máximo de horas que um funcionário pode trabalhar em todos os projetos por semana é 56. Essas restrições podem ser especificadas e impostas em programas de aplicação que atualizam o banco de dados, ou usando uma linguagem de es-pecificação de restrição de uso geral. Mecanismos chamados triggers (gatilhos) e assertions (afirmações) podem ser usados. Em SQL, os comandos CREATE ASSERTION e CREATE TRIGGER podem ser usados para essa finalidade (ver Capítulo 5). É mais comum verificar esses tipos de restrições em programas de aplicação do que usar linguagens de especificação de restrição, pois estas às vezes são difíceis e comple-xas de se usar, conforme discutiremos na Seção 26.1.Outro tipo de restrição é a de dependência fun-cional, que estabelece um relacionamento funcional FUNCIONARIOPnome Minicial Unome Cpf Datanasc Endereco Sexo Salario Cpf_supervisor DnrdepARtAmeNtODnome Dnumero Cpf_gerente Data_inicio_gerenteLOCALIZACOeS_depDnumero DlocalpROJetOProjnome Projnumero Projlocal DnumtRABALHA_emFcpf Pnr HorasdepeNdeNteFcpf Nome_dependente Sexo Datanasc ParentescoFigura 3.7Restrições de integridade referencial exibidas no esquema de banco de dados relacional EMPRESA.Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 4903 elmas0810_cap03 BR.indd 49 11/30/10 5:23 PMentre dois conjuntos de atributos X e Y. Essa restri-ção especifica que o valor de X determina um valor exclusivo de Y em todos os estados de uma relação; isso é indicado como uma dependência funcional X → Y. Usaremos dependências funcionais e outros tipos de dependências nos capítulos 15 e 16 como ferramentas para analisar a qualidade dos projetos relacionais e 'normalizar' relações para melhorar sua qualidade.Os tipos de restrições que discutimos até aqui po-dem ser chamados de restrições de estado, pois defi-nem as restrições às quais um estado válido do banco de dados precisa satisfazer. Outro tipo de restrição, chamadas restrições de transição, pode ser definido para lidar com mudanças de estado no banco de da-dos.11 Um exemplo de uma restrição de transição é: 'o salário de 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.3.3 Operações de atualização, transações e tratamento de violações de restriçãoAs operações do modelo relacional podem ser ca-tegorizadas em recuperações e atualizações. As ope-rações da álgebra relacional, que podem ser usadas para especificar recuperação, serão discutidas com detalhes no Capítulo 6. Uma expressão da álgebra relacional 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 operadores relacionais para recuperar es-ses dados. Esta relação resultado torna-se a respos-ta para a (ou resultado da) consulta do usuário. O Capítulo 6 também introduz a linguagem chamada cálculo relacional, que é usada para definir a nova relação de forma declarativa sem dar uma ordem es-pecífica das operações.Nesta seção, concentramo-nos nas operações de modificação ou atualização do banco de dados. Exis-tem três operações básicas que podem mudar os esta-dos das relações no banco de dados: Inserir, Excluir e Alterar (ou Modificar). Elas inserem novos dados, ex-cluem dados antigosou modificam registros de dados existentes. Insert é usado para inserir uma ou mais no-vas tuplas em uma relação, Delete é usado para excluir tuplas, e Update (ou Modify) é usado para alterar os valores de alguns atributos nas tuplas existentes. Sem-pre que essas operações são aplicadas, as restrições de integridade especificadas sobre o esquema de banco de dados relacional 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 cau-sar uma violação. Usamos o banco de dados mostra-do na Figura 3.6 para os exemplos e discutimos ape-nas as restrições de chave, restrições de integridade de entidade e as restrições de integridade referencial, mostradas na Figura 3.7. Para cada tipo de operação, damos alguns exemplos e discutimos as restrições que cada operação pode violar.3.3.1 A operação InserirA operação Inserir oferece uma lista de valores de atributo para que uma nova tupla t possa ser in-serida 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 tipo de dado apropriado. As restrições de chave podem ser viola-das se um valor de chave na nova tupla t já existir em outra tupla na relação r(R). A integridade de en-tidade pode ser violada se qualquer parte da chave primária 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 essa discussão. � Operação: Inserir em FUNCIONARIO. 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 FUNCIONARIO. Resultado: Esta inserção viola a restrição de chave porque outra tupla com o mesmo valor de Cpf já existe na relação FUNCIONARIO, e, portanto, é rejeitada.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.50 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 50 11/30/10 5:23 PM � Operação: Inserir em FUNCIONARIO. Resultado: Esta inserção viola a restrição de integridade referencial especificada sobre Dnr em FUNCIONARIO porque não existe uma tu-pla referenciada correspondente em DEPAR-TAMENTO com Dnumero = 7. � Operação: Inserir em FUN-CIONARIO. Resultado: Esta inserção satisfaz todas as res-trições, de modo que é aceitável.Se uma inserção violar uma ou mais restri-ções, a opção padrão é rejeitar a inserção. Nesse caso, seria útil se o SGBD pudesse oferecer um motivo ao usuário sobre a rejeição da inserção. Outra opção é tentar corrigir o motivo da rejeição da inserção, mas isso normalmente não é usado para violações causadas pela operação Inserir; em vez disso, é usado com mais frequência na corre-ção de violações das operações Excluir e Alterar. Na primeira operação, o SGBD poderia pedir ao usuário para oferecer um valor para Cpf, e po-deria então aceitar a inserção se um valor de Cpf válido fosse fornecido. Na operação 3, o SGBD poderia pedir que o usuário mudasse o valor de Dnr para algum valor válido (ou defini-lo como NULL), ou poderia pedir ao usuário para inserir uma tupla DEPARTAMENTO com Dnumero = 7 e poderia aceitar a inserção original somente depois que uma operação fosse aceita. Observe que, no último caso, a violação de inserção pode se pro-pagar de volta à relação FUNCIONARIO se o usuá-rio tentar inserir uma tupla para o departamento 7 com um valor para Cpf_gerente que não existe na relação FUNCIONARIO.3.3.2 A operação ExcluirA operação Excluir pode violar apenas a integri-dade referencial. Isso ocorre se a tupla que está sen-do excluída for referenciada por chaves estrangeiras de outras tuplas no banco de dados. Para especificar a exclusão, uma condição sobre os atributos da rela-ção seleciona a tupla (ou tuplas) a ser(em) excluída(s). Aqui estão alguns exemplos. � Operação: Excluir a tupla em TRABALHA_EM com Fcpf = ‘99988777767’ e Pnr = 10. Resultado: Esta exclusão é aceitável e exclui exatamente uma tupla. � Operação: Excluir a tupla em FUNCIONARIO com Cpf = ‘99988777767’. Resultado: Esta exclusão não é aceitável, pois existem tuplas em TRABALHA_EM que se re-ferenciam a esta tupla. Logo, se a tupla em FUNCIONARIO for excluída, haverá violações de integridade referencial. � Operação: Excluir a tupla em FUNCIONARIO com Cpf = ‘33344555587’. Resultado: Esta exclusão resultará em ain-da mais violações de integridade referencial, pois a tupla envolvida é referenciada por tu-plas das relações FUNCIONARIO, DEPARTA-MENTO, TRABALHA_EM e DEPENDENTE.Várias opções estão disponíveis se uma operação de exclusão causar uma violação. A primeira opção, chamada restrict, é rejeitar a exclusão. A segunda op-ção, chamada cascade, é tentar propagar (ou gerar em cascata) a exclusão excluindo tuplas que referenciam aquela que está sendo excluída. Por exemplo, na ope-ração 2, o SGBD poderia excluir automaticamente as tuplas problemáticas de TRABALHA_EM com Fcpf = ‘99988777767’. Uma terceira opção, chamada set null ou set default, é modificar os valores de atributo que referenciam a causa da violação; cada valor desse tipo é definido para NULL ou alterado para referenciar ou-tra tupla de valor válido. Observe que, se um atribu-to referenciando que causa uma violação faz parte da chave primária, ele não pode ser definido como NULL; caso contrário, ele violaria a integridade de entidade.Combinações dessas três opções também são possíveis. Por exemplo, para evitar que a operação 3 cause uma violação, o SGBD pode excluir auto-maticamente todas as tuplas de TRABALHA_EM e DEPENDENTE com Fcpf = ‘33344555587’. As tuplas em FUNCIONARIO com Cpf_supervisor e a tupla em DEPARTAMENTO com Cpf_gerente = ‘33344555587’ podem ter seus valores Cpf_supervisor e Cpf_gerente alterados para outros valores válidos ou para NULL. Embora possa fazer sentido excluir automaticamente as tuplas de TRABALHA_EM e DEPENDENTE que se referem a uma tupla de FUNCIONARIO, pode não fa-zer sentido excluir outras tuplas de FUNCIONARIO ou uma tupla de DEPARTAMENTO.Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 5103 elmas0810_cap03 BR.indd 51 11/30/10 5:23 PMEm geral, quando uma restrição de integridade referencial é especificada na DDL, o SGBD permi-tirá que o projetista de banco de dados especifique qual das opções se aplica no caso de uma violação da restrição. Discutiremos como especificar essas opções na DDL SQL no Capítulo 4.3.3.3 A operação AlterarA operação Alterar (ou Modificar) é usada para alterar os valores de um ou mais atributos em uma tupla (ou tuplas) de alguma relação R. É necessário especificar uma condição sobre os atributos da rela-ção para selecionar a tupla ou tuplas a serem modifi-cadas. Aqui estão alguns exemplos. � Operação: Alterar o salário da tupla em FUNCIONARIO com Cpf = ‘99988777767’ para 28.000. Resultado: Aceitável. � Operação: Alterar o Dnr da tupla em FUNCIONARIO com Cpf = ‘99988777767’ para 1. Resultado: Aceitável. � Operação: Alterar o Dnr da tupla em FUNCIONARIO com Cpf= ‘99988777767’ para 7. Resultado: Inaceitável, pois viola a integrida-de referencial. � Operação: Alterar o Cpf da tupla em FUNCIONARIO com Cpf = ‘99988777767’ para ‘98765432168’.Resultado: Inaceitável, pois viola a restrição de chave primária, repetindo um valor que já existe como chave primária em outra tupla; isso viola as restrições de integridade referencial porque existem outras relações que se referem ao valor existente de Cpf.Atualizar um atributo que nem faz parte de uma chave primária nem de uma chave estrangeira em geral não causa problemas; o SGBD só precisa verificar para confirmar se o novo valor é do tipo de dado e domí-nio corretos. Modificar um valor de chave primária é semelhante a excluir uma tupla e inserir outra em seu lugar, pois usamos a chave primária para identificar tu-plas. Logo, as questões discutidas anteriormente nas seções 3.3.1 (Operação Inserir) e 3.3.2 (Operação Ex-cluir) entram em cena. Se um atributo de chave estran-geira for modificado, o SGBD deverá garantir que o novo valor referencia a uma tupla existente na relação referenciada (ou que seja definido como NULL). Exis-tem opções semelhantes para lidar com as violações de integridade referencial causadas pela operação Alterar, como as opções discutidas para a operação Excluir. De fato, quando uma restrição de integridade referen-cial for especificada na DDL, o SGBD permitirá que o usuá rio escolha opções separadas para lidar com uma violação causada pela operação Excluir e uma violação causada pela operação Alterar (ver a Seção 4.2).3.3.4 O conceito de transaçãoUm programa de aplicação de banco de dados que executa com um banco de dados relacional nor-malmente executa uma ou mais transações. Uma transação é um programa em execução que inclui algumas operações de banco de dados, como fazer a leitura do banco de dados ou aplicar inserções, ex-clusões ou atualizações a ele. Ao final da transação, ela precisa deixar o banco de dados em um estado válido ou coerente, que satisfaça todas as restrições especificadas no esquema do banco de dados. Uma única transação pode envolver qualquer número de operações de recuperação (a serem discutidas como parte da álgebra e cálculo relacional no Capítulo 6, e como uma parte da linguagem SQL nos capítulos 4 e 5) e qualquer número de operações de atualiza-ção. Essas recuperações e atualizações juntas forma-rão uma unidade atômica de trabalho no banco de dados. Por exemplo, uma transação para aplicar um saque bancário costuma ler o registro da conta do usuário, verificar se existe saldo suficiente e depois atualizar o registro pelo valor do saque.Um grande número de aplicações comerciais, que executam com bancos de dados relacionais em siste-mas de processamento de transação on-line (OLTP — Online Transaction Processing), executa transações que atingem taxas de centenas por segundo. Os con-ceitos de processamento de transação, execução con-corrente de transações e recuperação de falhas serão discutidos nos capítulos 21 a 23.ResumoNeste capítulo, apresentamos os conceitos de mode-lagem, estruturas de dados e restrições, fornecidos pelo modelo relacional de dados. Começamos apresentando os conceitos de domínios, atributos e tuplas. Depois, de-finimos um esquema de relação como uma lista de atri-butos que descrevem a estrutura de uma relação. Uma relação, ou estado de relação, é um conjunto de tuplas que correspondem ao esquema.Várias características diferenciam relações das tabe-las ou arquivos comuns. A primeira é que uma relação não é sensível à ordem das tuplas. A segunda envolve a ordem dos atributos em um esquema de relação e a ordem correspondente dos valores dentro de uma tupla. Oferecemos uma definição alternativa de relação que não exige essas duas ordens, mas continuamos a usar a 52 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 52 11/30/10 5:23 PMprimeira definição, que requer que atributos e valores de tupla sejam ordenados, por conveniência. Depois, discu-timos os valores nas tuplas e apresentamos os valores NULL para representar informações faltantes ou desco-nhecidas. Enfatizamos que valores NULL devem ser evi-tados ao máximo.Classificamos as restrições do banco de dados em restrições inerentes baseadas no modelo, restrições explí-citas baseadas no esquema e restrições baseadas na apli-cação, também conhecidas como restrições semânticas ou regras de negócios. Depois, discutimos as restrições de esquema pertencentes ao modelo relacional, come-çando com as restrições de domínio, depois as restrições de chave, incluindo os conceitos de superchave, chave candidata e chave primária, e a restrição NOT NULL so-bre atributos. Definimos bancos de dados relacionais e esquemas de banco de dados relacionais. Outras restri-ções relacionais incluem a restrição de integridade de en-tidade, que proíbe que atributos de chave primária sejam NULL. Descrevemos a restrição de integridade referencial entre relações, que é usada para manter a consistência das referências entre tuplas de diferentes relações.As operações de modificação no modelo relacio-nal são Inserir, Excluir e Alterar. Cada operação pode violar certos tipos de restrições (consulte a Seção 3.3). Sempre que uma operação é aplicada, o estado do banco de dados após a operação ser executada deve ser verifi-cado para garantir que nenhuma restrição seja violada. Finalmente, apresentamos o conceito de transação, que é importante nos SGBDs relacionais porque permite o agrupamento de várias operações de banco de dados em uma única ação atômica sobre o banco de dados.Perguntas de revisão 3.1. Defina os termos a seguir quando se aplicam ao modelo de dados relacional: domínio, atributo, tupla n, esquema de relação, estado de relação, grau da relação, esquema de banco de dados re-lacional e estado de banco de dados relacional. 3.2. Por que as tuplas em uma relação não são orde-nadas? 3.3. Por que as tuplas duplicadas não são permitidas em uma relação? 3.4. Qual é a diferença entre uma chave e uma super-chave? 3.5. Por que designamos uma das chaves candidatas de uma relação como sendo a chave primária? 3.6. Discuta as características de relações que as tor-nam diferentes das tabelas e arquivos comuns. 3.7. Discuta os diversos motivos que levam à ocor-rência de valores NULL nas relações. 3.8. Discuta as restrições de integridade de entidade e integridade referencial. Por que são consideradas importantes? 3.9. Defina a chave estrangeira. Para que esse concei-to é usado? 3.10. O que é uma transação? Como ela difere de uma operação atualização?Exercícios 3.11. Suponha que cada uma das seguintes operações de atualização seja aplicada diretamente ao esta-do do banco de dados mostrado na Figura 3.6. Discuta todas as restrições de integridade viola-das por cada operação, se houver, e as diferentes maneiras de lidar com essas restrições.a. Inserir em FUNCIONARIO.b. Inserir em PROJETO.c. Inserir em DEPARTAMENTO.d. Inserir em TRABALHA_EM.e. Inserir em DEPENDENTE.f. Excluir as tuplas de TRABALHA_EM com Fcpf = ‘33344555587’.g. Excluir a tupla de FUNCIONARIO com Cpf = ‘98765432168’.h. Excluir a tupla de PROJETO com Projnome = ‘ProdutoX’.i. Modificar Cpf_gerente e Data_inicio_gerente da tupla DEPARTAMENTO com Dnumero = 5 para ‘12345678966’ e ‘01-10-2007’, res-pectivamente.j. Modificar o atributo Cpf_supervisor da tupla FUNCIONARIO com Cpf = ‘99988777767’ para ‘94377554355’.k. Modificar o atributo Horas da tupla TRABA-LHA_EM com Fcpf = ‘99988777767’ e Pnr = 10 para ‘5,0’. 3.12. Considere o esquema do banco de dados rela-cional COMPANHIA AEREA mostradona Figura 3.8, que descreve um banco de dados para infor-mações de voo. Cada VOO é identificado por um Numero_voo, e consiste em um ou mais TRE-CHOs_VOO com Numero_trecho 1, 2, 3, e assim por diante. Cada TRECHO_VOO tem agendados horários de chegada e saída, aeroportos e uma ou mais INSTANCIAs_TRECHO — uma para cada Data em que o voo ocorre. TARIFAs são mantidas para cada VOO. Para cada instância de TRECHO_VOO, RESERVAs_ASSENTO são mantidas, assim como a AERONAVE usada no trecho e os horários de chegada e saída e aero-portos reais. Uma AERONAVE é identificada por um Codigo_aeronave e tem um TIPO_AERONA-VE em particular. PODE_POUSAR relaciona os Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 5303 elmas0810_cap03 BR.indd 53 11/30/10 5:23 PMTIPOs_AERONAVE aos AEROPORTOs em que eles podem aterrissar. Um AEROPORTO é iden-tificado por um Codigo_aeroporto. Considere uma atualização para o banco de dados COM-PANHIA AEREA entrar com uma reserva em um voo em particular ou trecho de voo em determi-nada data.a. Indique as operações para esta atualização.b. Que tipos de restrições você esperaria verifi-car?c. Quais dessas restrições são de chave, de inte-gridade de entidade e de integridade referen-cial, e quais não são?d. Especifique todas as restrições de integridade referencial que se mantêm no esquema mos-trado na Figura 3.8.AeROpORtOCodigo_aeroporto Nome Cidade EstadoVOOtReCHO_VOOINStANCIA_tReCHOtARIFA tIpO_AeRONAVepOde_pOUSARAeRONAVeReSeRVA_ASSeNtONumero_voo Companhia aerea Dias da semanaNumero_voo Numero_trecho Data Numero_assentos_disponiveis Codigo_aeronaveCodigo_aeroporto_partida Horario_partida Codigo_aeroporto_chegada Horario_chegadaNumero_voo Codigo_tarifa Quantidade RestricoesNome_tipo_aeronave Qtd_max_assentos CompanhiaNome_tipo_aeronave Codigo_aeroportoCodigo_aeronave Numero_total_assentos Tipo_aeronaveNumero_voo Numero_trecho Data Numero_assento Nome_cliente Telefone_clienteNumero_voo Numero_trecho Codigo_aeroporto_partida Horario_partida_previstoCodigo_aeroporto_chegada Horario_chegada_previstoFigura 3.8O esquema do banco de dados relacional COMPANHIA AEREA.54 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 54 11/30/10 5:23 PM 3.13. Considere a relação AULA(Num_disciplina, Num_turma, Nome_professor, Semestre, Codigo_edificio, Num_Sala, Turno, Dias_da_semana, Creditos). Isso representa as aulas lecionadas em uma universidade, com Num_Turma única. Iden-tifique 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 cha-ves candidatas seriam válidas. 3.14. Considere as seis relações a seguir para uma apli-cação de banco de dados de processamento de pedido em uma empresa:CLIENTE(Num_cliente, Nome_cliente, Num_cidade)PEDIDO(Num_pedido, Data_pedido, Num_cliente, Num_pedido)ITEM_PEDIDO(Num_pedido, Num_item, 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 de um pedido) é despa-chado do depósito. Suponha que um pedido pos-sa 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 de dados? 3.15. Considere as seguintes relações para um banco de dados que registra viagens de negócios de vendedores em um escritório de vendas:VENDEDOR(Cpf, Nome, Ano_inicio, Numero_departamento)VIAGEM(Cpf, Cidade_origem, Cidade_destino, Data_partida, Data_retorno, Cod_viagem)DESPESA(Cod_viagem, Num_conta, Valor)Uma viagem pode ser cobrada de uma ou mais contas (Num_conta). Especifique as chaves es-trangeiras para esse esquema, indicando quais-quer suposições que você faça. 3.16. Considere as seguintes relações para um banco de dados que registra a matrícula do aluno nas disci-plinas e os livros adotados para cada disciplina:ALUNO(Cpf, Nome, Curso, Datanasc)DISCIPLINA(Num_Disciplina, Dnome, Dept)INSCRICAO(Cpf, Num_disciplina, Semestre, Nota)LIVRO_ADOTADO(Num_disciplina, Semestre, ISBN_livro)LIVRO(ISBN_livro, Titulo_livro, Editora, Autor)Especifique as chaves estrangeiras para este es-quema, indicando quaisquer suposições que você faça. 3.17. Considere as seguintes relações para um banco de dados que registra vendas de automóveis em um revendedor de carros (OPCAO refere-se a algum equipamento opcional instalado em um automóvel):CARRO(Numero_chassi, Modelo, Fabricante, Preco)OPCAO(Numero_chassi, Nome_opcional, Preco)VENDA(Cod_vendedor, Numero_chassi, Data, Preco_venda)VENDEDOR(Cod_vendedor, Nome, Telefone)Primeiro, especifique as chaves estrangeiras para este esquema, indicando quaisquer suposições que você faça. Depois, preencha as relações com algumas tuplas de exemplo, e então mostre um exemplo de uma inserção nas relações VENDA e VENDEDOR que viola as restrições de integrida-de referencial e de outra inserção que não viola. 3.18. O projeto de banco de dados normalmente envol-ve decisões sobre o armazenamento 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 qua-tro grupos separados por hífen em um Cadas-tro de Pessoa Física — XXX-XXX-XXX-XX). Porém, os números do Cadastro de Pessoa Físi-ca 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 onde a divi-são do CPF é útil. 3.19. Considere uma relação ALUNO em um ban-co de dados UNIVERSIDADE com os seguintes atributos (Nome, Cpf, Telefone_local, Endereco, Telefone_celular, Idade, Media). Observe que o telefone celular pode ser de uma cidade e estado diferentes do telefone local. Uma tupla possível da relação é mostrada a seguir:Nome Cpf Telefone_local Endereco Telefone_celular Idade MediaJorge Pereira William Ribeiro123-459-678-975555-1234 Rua Cambará, 33, Bauru, SP8555-4321 19 3,75Capítulo 3 O modelo de dados relacional e as restrições em bancos de dados relacionais 5503 elmas0810_cap03 BR.indd 55 11/30/10 5:23 PMa. Identifique a informação crítica que falta nos atributos Telefone_local 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 Telefone_local e Telefone_celu-lar ou incluiria novos atributos ao esquema para ALUNO?c. Considere o atributo Nome. Quais são as vantagens e desvantagens de dividir esse cam-po de um atributo em três atributos (primeiro nome, nome do meio e sobrenome)?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. 3.20. Mudanças recentes nas leis de privacidade dos EUA não permitiram 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 uni-versidades nos EUA não pode usar SSNs como chaves primárias (exceto para dados financeiros). Na prática, Cod_aluno, um identificador exclu-sivo atribuído a cada aluno, provavelmente será usado como chave primária, em vez do Ssn, pois Cod_aluno pode ser usado por todo o sistema.a. Alguns projetistas de banco de dados são re-lutantes em usar chaves geradas (também co-nhecidas como chaves substitutas) para cha-ves primárias (como Cod_aluno), pois elas são artificiais. Você consegue propor algumas escolhas naturais de chaves que podem ser usadas paraidentificar o registro do aluno no banco de dados UNIVERSIDADE?b. Suponha que você consiga garantir a exclu-sividade de uma chave natural que inclua so-brenome. Você tem garantias de 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 selecionadaO modelo relacional foi introduzido por Codd (1970) em um artigo clássico. Codd também introdu-ziu a álgebra relacional e estabeleceu as bases teóricas para o modelo relacional em uma série de artigos (Codd, 1971, 1972, 1972a, 1974); mais tarde, ele recebeu o Tu-ring Award, a honra mais alta da ACM (Association for Computing Machinery) por seu trabalho sobre o modelo relacional. Em um artigo posterior, Codd (1979) discutiu a extensão do modelo relacional para incorporar mais me-tadados 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 re-lações e incorporar NULLs na álgebra relacional. O modelo resultante é conhecido como RM/ T. Childs (1968) usou inicialmente a teoria de conjunto para modelar bancos de dados. Mais tarde, Codd (1990) publicou um livro exami-nando mais de 300 recursos do modelo de dados relacional e sistemas de banco de dados. Date (2001) oferece uma crí-tica e análise retrospectiva do modelo de dados relacional.Desde o trabalho pioneiro de Codd, muita pesquisa tem sido realizada sobre vários aspectos do modelo rela-cional. Todd (1976) descreve um SGBD experimental cha-mado PRTV que implementa diretamente as operações da álgebra relacional. Schmidt e Swenson (1975) apresentam semântica adicional para o modelo relacional classifican-do diferentes tipos de relações. O modelo Entidade-Rela-cionamento de Chen (1976), que será discutido no Capí-tulo 7, é um meio de comunicar a semântica do mundo real de um banco de dados relacional no nível conceitual. Wiederhold e Elmasri (1979) introduzem diversos tipos de conexões entre relações para aprimorar suas restrições. As extensões do modelo relacional serão discutidas nos capí-tulos 11 e 26. Notas bibliográficas adicionais para outros aspectos do modelo relacional e suas linguagens, sistemas, extensões e teoria serão apresentados nos capítulos 4 a 6, 9, 11, 13, 15, 16, 24 e 25. Maier (1983) e Atzeni e De An-tonellis (1993) oferecem um extenso tratamento teórico do modelo de dados relacional.56 Sistemas de banco de dados03 elmas0810_cap03 BR.indd 56 11/30/10 5:23 PMA linguagem SQL pode ser considerada um dos prin-cipais motivos para o sucesso dos bancos de dados relacionais comerciais. Como ela se tornou um padrão para esse tipo de bancos de dados, os usuários ficaram menos preocupados com a migração de suas aplicações de outros tipos de sistemas de banco de dados — por exemplo, sistemas de rede e hierárquicos — para sis-temas relacionais. Isso aconteceu porque, mesmo que os usuários estivessem insatisfeitos com o produto de SGBD relacional em particular que estavam usando, a conversão para outro produto de SGBD relacional não seria tão cara ou demorada, pois os dois sistemas seguiam os mesmos padrões de linguagem. Na práti-ca, é óbvio, existem muitas diferenças entre diversos pacotes de SGBD relacionais comerciais. Porém, se o usuário for cuidadoso em usar apenas dos recursos que fazem parte do padrão, e se os dois sistemas relacio-nais admitirem fielmente o padrão, entã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 o padrão SQL.Este capítulo apresenta os principais recursos do padrão SQL para SGBDs relacionais comerciais, en-quanto o Capítulo 3 apresentou os conceitos mais im-portantes por trás do modelo de dados relacional for-mal. No Capítulo 6 (seções 6.1 a 6.5), discutiremos as operações da álgebra relacional, que são muito impor-tantes para entender os tipos de solicitações que podem ser especificadas em um banco de dados relacional. Elas também são importantes para processamento e otimi-zação de consulta em um SGBD relacional, conforme veremos no Capítulo 19. No entanto, as operações da álgebra relacional são consideradas muito técnicas para a maioria dos usuários de SGBD comercial, pois uma consulta em álgebra relacional é escrita como uma se-quência de operações que, quando executadas, produz o resultado exigido. Logo, o usuário precisa especificar como — ou seja, em que ordem — executar as opera-ções de consulta. Por sua vez, a linguagem SQL oferece uma interface de linguagem declarativa 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. Embo-ra a SQL inclua alguns recursos da álgebra relacional, ela é baseada em grande parte no cálculo relacional de tupla, que descrevemos na Seção 6.6. Porém, a sintaxe SQL é mais fácil de ser utilizada do que qualquer uma das duas linguagens formais.O nome SQL hoje é expandido como Struc-tured 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 in-terface para um sistema de banco de dados relacional experimental, chamado SYSTEM R. A SQL agora é a linguagem padrão para SGBDs relacionais comer-ciais. Um esforço conjunto entre o American Natio-nal Standards Institute (ANSI) e a International Stan-dards Organization (ISO) levou a uma versão-padrão da SQL (ANSI, 1986), chamada SQL-86 ou SQL1. Um padrão revisado e bastante expandido, denomi-nado SQL-92 (também conhecido como SQL2) foi desenvolvido mais tarde. O próximo padrão reconhe-cido foi SQL:1999, que começou como SQL3. Duas atualizações posteriores ao padrão são SQL:2003 e SQL:2006, que acrescentaram recursos de XML (ver Capítulo 12) entre outras atualizações para a lingua-gem. Outra atualização em 2008 incorporou mais capítulo 4 SQL básica04 elmas0810_cap04 BR.indd 57 11/30/10 5:22 PMrecursos de banco de dados de objeto na SQL (ver Capítulo 11). Tentaremos abordar a última versão da SQL ao máximo possível.SQL é uma linguagem de banco de dados abran-gente: tem instruções para definição de dados, con-sultas e atualizações. Logo, ela é uma DDL e uma DML. Além disso, ela tem facilidades para definir visões sobre o banco de dados, para especificar se-gurança e autorização, para definir restrições de inte-gridade 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, COBOL ou C/C++.1Os padrões SQL mais recentes (começando com SQL:1999) são divididos em uma especificação nú-cleo mais extensões especializadas. O núcleo deve ser implementado por todos os fornecedores de SGBDR que sejam compatíveis com SQL. As extensões po-dem 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 ware-housing, processamento analítico on-line (OLAP), dados de multimídia e assim por diante.Como a SQL é muito importante (e muito gran-de), dedicamos dois capítulos para explicar seus re-cursos. Neste capítulo, a Seção 4.1 descreve os co-mandos de DDL da SQL para criação de esquemas e tabelas, e oferece uma visão geral dos tipos de dados básicos em SQL. A Seção 4.2 apresenta como res-trições básicas, chave e integridade referencial, são especificadas. A Seção 4.3 descreve as construções básicas da SQLpara especificar recuperação de con-sultas, e a Seção 4.4 descreve os comandos SQL para inserção, exclusão e alteração de dados.No Capítulo 5, descreveremos recuperação de consultas SQL mais complexas, bem como comandos ALTER para alterar o esquema. Também descrevere-mos a instrução CREATE ASSERTION, que permite a especificação de restrições mais gerais no banco de dados. Também apresentamos o conceito de triggers, que será abordado com mais detalhes no Capítulo 26, e descreveremos a facilidade SQL para definir views no banco de dados no Capítulo 5. As views também são conhecidas como tabelas virtuais ou ta-belas derivadas porque apresentam ao usuário o que parecem ser tabelas; porém, a informação nessas ta-belas é derivada de tabelas previamente definidas.A Seção 4.5 lista alguns dos recursos da SQL que serão apresentados em outros capítulos do livro; entre eles estão o controle de transação no Capítulo 21, segurança/autorização no Capítulo 24, bancos de dados ativos (triggers) no Capítulo 26, recursos orientados a objeto no Capítulo 11 e recursos de pro-cessamento analítico on-line (OLAP) no Capítulo 29. No final deste capítulo há um resumo. Os capítulos 13 e 14 discutem as diversas técnicas de programa-ção em banco de dados para programação com SQL.4.1 Definições e tipos de dados em SQLA SQL usa os termos tabela, linha e coluna para os termos do modelo relacional formal relação, tupla e atributo, respectivamente. Usaremos os termos cor-respondentes para indicar a mesma coisa. O principal comando SQL para a definição de dados é o CREATE, que pode ser usado para criar esquemas, tabelas (rela-ções) e domínios (bem como outras construções como views, assertions e triggers). Antes de descrevermos a importância das instruções CREATE, vamos discutir os conceitos de esquema e catálogo na Seção 4.1.1 para contextualizar nossa discussão. A Seção 4.1.2 descre-ve como as tabelas são criadas, e a Seção 4.1.3, os tipos de dados mais importantes disponíveis para es-pecificação de atributo. Como a especificação SQL é muito grande, oferecemos uma descrição dos recursos mais importantes. Outros detalhes poderão ser encon-trados em diversos documentos dos padrões SQL (ver bibliografia selecionada ao final do capítulo).4.1.1 Conceitos de esquema e catálogo em SQLAs primeiras versões da SQL não incluíam o con-ceito de um esquema de banco de dados relacional; todas as tabelas (relações) eram consideradas parte do mesmo esquema. O conceito de um esquema SQL foi incorporado inicialmente com SQL2 a fim de agrupar tabelas e outras construções que pertencem à mes-ma aplicação de banco de dados. Um esquema SQL é identificado por um nome de esquema, e inclui um identificador de autorização para indicar o usuário ou conta proprietário do esquema, bem como descritores para cada elemento. Esses elementos incluem tabe-las, restrições, views, domínios e outras construções (como concessões — grants — de autorização) que descrevem o esquema que é criado por meio da instru-ção CREATE SCHEMA. Esta pode incluir todas as defi-nições dos elementos do esquema. Como alternativa, o esquema pode receber um identificador de nome e autorização, e os elementos podem ser definidos mais tarde. Por exemplo, a instrução a seguir cria um esque-1 Originalmente, a SQL tinha instruções para criar e remover índices nos arquivos que representam as relações, mas estes foram retirados do padrão SQL por algum tempo.58 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 58 11/30/10 5:22 PMma chamado EMPRESA, pertencente ao usuário com identificador de autorização ‘Jsilva’. Observe que cada instrução em SQL termina com um ponto e vírgula.CREATE SCHEMA EMPRESA AUTHORIZATION ‘Jsilva’;Em geral, nem todos os usuários estão autoriza-dos a criar esquemas e elementos do esquema. O privi-légio para criar esquemas, tabelas e outras construções deve ser concedido explicitamente às contas de usuá-rio relevantes pelo administrador do sistema ou DBA.Além do conceito de um esquema, a SQL usa o conceito de um catálogo — uma coleção nomeada de esquemas em um ambiente SQL. Um ambiente SQL é basicamente uma instalação de um SGBDR compa-tível com SQL em um sistema de computador.2 Um catálogo sempre contém um esquema especial, cha-mado INFORMATION_SCHEMA, que oferece informa-ções sobre todos os esquemas no catálogo e todos os seus descritores de elemento. As restrições de inte-gridade, 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 compar-tilhar certos elementos, como definições de domínio.4.1.2 O comando CREATE TABLE em SQLO comando CREATE TABLE é usado para es-pecificar uma nova relação, dando-lhe 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 espe-cificadas na instrução CREATE TABLE, depois que os atributos forem declarados, ou acrescentadas depois, usando o comando ALTER TABLE (ver Capítulo 5). A Figura 4.1 mostra exemplos de instruções de defini-ção de dados em SQL para o esquema de banco de dados relacional EMPRESA da Figura 3.7.Em geral, o esquema SQL em que as relações são declaradas é especificado implicitamente no ambiente em que as instruções CREATE TABLE são executadas. Como alternativa, podemos conectar explicitamente o nome do esquema ao nome da relação, separados por um ponto. Por exemplo, escrevendoCREATE TABLE EMPRESA.FUNCIONARIO ...em vez deCREATE TABLE FUNCIONARIO ...como na Figura 4.1, podemos explicitamente (ao in-vés de implicitamente) tornar a tabela FUNCIONARIO parte do esquema EMPRESA.As relações declaradas por meio das instruções CREATE TABLE são chamadas de tabelas da base (ou re-lações da base); isso significa que a relação e suas tuplas são realmente criadas e armazenadas como um arquivo pelo SGBD. As relações da base são distintas das re-lações virtuais, criadas por meio da instrução CREATE VIEW (ver Capítulo 5), que podem ou não corresponder a um arquivo físico real. Em SQL, os atributos em uma tabela da 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 or-denadas dentro de uma relação.É importante observar que, na Figura 4.1, exis-tem 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 estrangeira Cpf_su-pervisor na tabela FUNCIONARIO é uma referência cir-cular, pois se refere à própria tabela. A chave estran-geira Dnr na tabela FUNCIONARIO 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 TA-BLE (ver Capítulo 5). Apresentamos todas as chaves estrangeiras na Figura 4.1, para mostrar o esquema EMPRESA completo em um só lugar.4.1.3 Tipos de dados de atributo e domínios em SQLOs tipos de dados básicos disponíveis para atribu-tos são numérico, cadeia ou sequência de caracteres, cadeia ou sequência de bits, booleano, data e hora. � Os tipos de dados numerico incluem números inteiros de vários tamanhos (INTEGER ou INT e SMALLINT) e números de ponto flutuante (reais) de várias precisões (FLOAT ou REAL e DOUBLE PRECISION). O formato dos números pode ser declarado usando DECIMAL(i, j) — ou DEC(i, j) ou NUMERIC(i, j) — onde i, a precisão, é o número total de dígitos decimais e j, a escala, é o número de dígitos após o ponto decimal. O valor padrão para a escala........499Capítulo 21 Introdução aos conceitos e teoria de processamento de transações ...50021.1 Introdução ao processamento de transações ............................................ 50021.2 Conceitos de transação e sistema ......... 50621.3 Propriedades desejáveis das transações 50821.4 Caracterizando schedules com base na facilidade de recuperação .................... 50921.5 Caracterizando schedules com base na facilidade de serialização ..................... 51121.6 Suporte para transação em SQL .......... 519Resumo .......................................................... 520Perguntas de revisão ....................................... 520Exercícios ....................................................... 521Bibliografia selecionada .................................. 522Capítulo 22 Técnicas de controle de concorrência ..........................52322.1 Técnicas de bloqueio em duas fases para controle de concorrência ..................... 52322.2 Controle de concorrência baseado na ordenação de rótulo de tempo (timestamp) ................. 53122.3 Técnicas de controle de concorrência multiversão .......................................... 53322.4 Técnicas de controle de concorrência de validação (otimista) ............................. 53522.5 Granularidade dos itens de dados e bloqueio de granularidade múltiplo ..... 53622.6 Usando bloqueios para controle de concorrência em índices ....................... 53922.7 Outras questões de controle de concorrência ........................................ 539Resumo .......................................................... 540Perguntas de revisão ....................................... 541Exercícios ....................................................... 542Bibliografia selecionada .................................. 542Capítulo 23 Técnicas de recuperação de banco de dados ................................54323.1 Conceitos de recuperação .................... 54323.2 Recuperação NO-UNDO/REDO baseada em atualização adiada ......................... 54923.3 Técnicas de recuperação baseadas em atualização imediata ............................ 55023.4 Paginação de sombra ........................... 55223.5 O algoritmo de recuperação ARIES ..... 55323.6 Recuperação em sistemas de múltiplos bancos de dados .................................. 55623.7 Backup e recuperação de banco de dados contra falhas catastróficas ................... 557 Resumo .......................................................... 557Perguntas de revisão ....................................... 558Exercícios ....................................................... 558Bibliografia selecionada .................................. 560Parte 10: Tópicos adicionais de banco de dados: segurança e distribuição................ 561Capítulo 24 Segurança de banco de dados ...56224.1 Introdução a questões de segurança de banco de dados .................................... 56224.2 Controle de acesso discricionário baseado na concessão e revogação de privilégios .. 56724.3 Controle de acesso obrigatório e controle de acesso baseado em papel para segurança multinível ............................................ 57024.4 Injeção de SQL .................................... 57524.5 Introdução à segurança do banco de dados estatístico ............................................ 57724.6 Introdução ao controle de fluxo .......... 57924.7 Criptografia e infraestruturas de chave pública ................................................ 58024.8 Questões de privacidade e preservação 58224.9 Desafios da segurança do banco de dados . 58324.10 Segurança baseada em rótulo no Oracle . 584Resumo .......................................................... 586Perguntas de revisão ....................................... 587Exercícios ....................................................... 587Bibliografia selecionada .................................. 588Capítulo 25 Bancos de dados distribuídos ....58925.1 Conceitos de banco de dados distribuído .. 59025.2 Tipos de sistemas de bancos de dados distribuídos ......................................... 59325.3 Arquiteturas de banco de dados distribuídas .......................................... 59625.4 Técnicas de fragmentação, replicação e alocação de dados para projeto de banco de dados distribuído ............................ 60125.5 Processamento e otimização de consulta em bancos de dados distribuídos ............... 60525.6 Visão geral do gerenciamento de transação em bancos de dados distribuídos ......... 611Sumário xi00 elmas0810_iniciais BR.indd 11 11/30/10 5:27 PM25.7 Visão geral do controle de concorrência e recuperação em bancos de dados distribuídos ......................................... 61325.8 Gerenciamento de catálogo distribuído .. 61525.9 Tendências atuais em bancos de dados distribuídos ......................................... 61525.10 Bancos de dados distribuídos em Oracle ..........................................617Resumo .......................................................... 620Perguntas de revisão ....................................... 621Exercícios ....................................................... 622Bibliografia selecionada .................................. 623Parte 11: Modelos, sistemas e aplicações de bancos de dados avançados ...... 625Capítulo 26 Modelos de dados avançados para aplicações avançadas .... 62626.1 Conceitos de banco de dados ativo e triggers ................................................ 62726.2 Conceitos de banco de dados temporal .. 63526.3 Conceitos de banco de dados espacial ... 64526.4 Conceitos de banco de dados multimídia . 65026.5 Introdução aos bancos de dados dedutivos ............................................. 653Resumo .......................................................... 663Perguntas de revisão ....................................... 664Exercícios ....................................................... 665Bibliografia selecionada .................................. 667Capítulo 27 Introdução à recuperação de informações e busca na Web .. 66927.1 Conceitos de recuperação de informações (RI) .................................. 66927.2 Modelos de recuperação ...................... 67427.3 Tipos de consultas em sistemas de RI .. 67927.4 Pré-processamento de textos ................ 68027.5 Indexação invertida ............................. 68227.6 Medidas de avaliação de relevância da pesquisa ............................................... 68427.7 Pesquisa e análise na Web .................... 68627.8 Tendências na recuperação de informações ......................................... 693Resumo .......................................................... 694Perguntas de revisão ....................................... 695Bibliografia selecionada .................................. 696Capítulo 28 Conceitos de mineração de dados ................................... 69828.1 Visão geral da tecnologia de mineração de dados .............................................. 69828.2 Regras de associação ........................... 70128.3 Classificação ........................................ 70928.4 Agrupamento ...................................... 71228.5 Abordagens para outros problemas de mineração de dados ............................. 71328.6 Aplicações de mineração de dados ....... 71528.7 Ferramentas comerciais de mineração de dados ................................................... 716Resumo .......................................................... 717Perguntas de revisão ....................................... 718Exercícios ....................................................... 718Bibliografia selecionada .................................. 719Capítulo 29 Visão geral de data warehousing e OLAP ..................................é zero, e para a precisão, é definido pela implementação. � Tipos de dados de cadeia de caracteres são de tamanho fixo — CHAR(n) ou CHARACTER(n), onde n é o número de caracteres — ou de tamanho variável — VARCHAR(n) ou CHAR 2 A SQL também inclui o conceito de um grupo (cluster) de catálogos dentro de um ambiente.Capítulo 4 SQL básica 5904 elmas0810_cap04 BR.indd 59 11/30/10 5:22 PMCREATE TABLE FUNCIONARIO(Pnome VARCHAR(15) NOT NULL,Minicial CHAR,NOT NULL,Unome VARCHAR(15)Cpf CHAR(11), NOT NULL,Datanasc DATE,Endereço VARCHAR(30),Sexo CHAR,Salario DECIMAL(10,2),Cpf_supervisor CHAR(11), NOT NULL,Dnr INTPRIMARY KEY (Cpf),FOREIGN KEY (Cpf_supervisor) REFERENCES FUNCIONARIO(Cpf),FOREIGN KEY (Dnr) REFERENCES DEPARTAMENTO(Dnumero) );CREATE TABLE DEPARTAMENTO( Dnome VARCHAR(15) NOT NULL,Dnumero INT NOT NULL,Cpf_gerente CHAR(11), NOT NULL,Data_inicio_gerente DATE,PRIMARY KEY (Dnumero),UNIQUE (Dnome),FOREIGN KEY (Cpf_gerente) REFERENCES FUNCIONARIO(Cpf) );CREATE TABLE LOCALIZACAO_DEP( Dnumero INT NOT NULL,Dlocal VARCHAR(15) NOT NULL,PRIMARY KEY (Dnumero, Dlocal),FOREIGN KEY (Dnumero) REFERENCES DEPARTAMENTO(Dnumero) );CREATE TABLE PROJETO( Projnome VARCHAR(15) NOT NULL,Projnumero INT NOT NULL,Projlocal VARCHAR(15),NOT NULL,Dnum INTPRIMARY KEY (Projnumero),UNIQUE (Projnome),FOREIGN KEY (Dnum) REFERENCES DEPARTAMENTO(Dnumero) );CREATE TABLE TRABALHA_EM( Fcpf CHAR(9) NOT NULL,Pnr INT NOT NULL,Horas DECIMAL(3,1) NOT NULL,PRIMARY KEY (Fcpf, Pnr),FOREIGN KEY (Fcpf) REFERENCES FUNCIONARIO(Cpf),FOREIGN KEY (Pnr) REFERENCES PROJETO(Projnumero) );CREATE TABLE DEPENDENTE( Fcpf CHAR(11), NOT NULL,Nome_dependente VARCHAR(15) NOT NULL,Sexo CHAR,Datanasc DATE,Parentesco VARCHAR(8),PRIMARY KEY (Fcpf, Nome_dependente),FOREIGN KEY (Fcpf) REFERENCES FUNCIONARIO(Cpf) );Figura 4.1Instruções CREATE TABLE da SQL para definição do esquema EMPRESA da Figura 3.7.VARYING(n) ou CHARACTER VARYING(n), onde n é o número máximo de caracteres. Ao especificar um valor literal de cadeia de ca-racteres, ele é colocado entre aspas simples (apóstrofos), e é case sensitive (diferencia maiúsculas de minúsculas).3 Para cadeias de caracteres de tamanho fixo, uma cadeia mais curta é preenchida com caracteres em bran-co à direita. Por exemplo, se o valor ‘Silva’ for para um atributo do tipo CHAR(10), ele é preenchido com cinco caracteres em branco para se tornar ‘Silva ’, se necessário. Os es-paç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 str1 apare-cer antes de outra cadeia str2 em ordem al-fabética, então str1 é considerada menor que str2.4 Há também um operador de concatena-ção indicado por || (barra vertical dupla), que pode concatenar duas cadeias de caracteres em SQL. Por exemplo, ‘abc’ || ‘XYZ’ resulta em uma única cadeia ‘abcXYZ’. Outro tipo de dado de cadeia de caracteres de tamanho variável, chamado CHARACTER LARGE OB-JECT ou CLOB, também está disponível para especificar colunas que possuem grandes va-lores de texto, como documentos. O tama-nho 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 cadeia de bits podem ser de ta-manho fixo n — BIT(n) — ou de tamanho variá-vel — BIT VARYING(n), onde n é o número máxi-mo de bits. O valor padrão para n, o tamanho de uma cadeia de caracteres ou cadeia de bits, é 1. Os literais de cadeia de bits literais são colocados entre apóstrofos, mas precedidos por um B para distingui-los das cadeias de caracteres; por exem-plo, B‘10101’.5 Outro tipo de dados de cadeia de bits de tamanho variável, chamado BINARY LARGE OBJECT ou BLOB, também está dispo-nível para especificar colunas que possuem gran-des valores binários, como imagens. Assim como para CLOB, o tamanho máximo de um BLOB pode ser especificado em kilobits (K), megabits 3 Isso não acontece com palavras-chave da SQL, como CREATE ou CHAR. Com as palavras-chave, a SQL é case insensitive, significando que ela trata letras maiúsculas e minúsculas como equivalentes nessas palavras.4 Para caracteres não alfabéticos, existe uma ordem definida.5 Cadeias de bits cujo tamanho é um múltiplo de 4 podem ser especificadas em notação hexadecimal, em que a cadeia literal é precedida por X e cada caractere hexadecimal representa 4 bits.60 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 60 11/30/10 5:22 PM(M) ou gigabits (G). Por exemplo, BLOB(30G) especifica um tamanho máximo de 30 gigabits. � Um tipo de dado booleano tem os valores tra-dicionais TRUE (verdadeiro) ou FALSE (falso). Em SQL, devido à presença de 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 (in-definido). Discutiremos a necessidade de UN-KNOWN e a lógica de três valores no Capítulo 5. � O tipo de dados DATE possui dez posições, e seus componentes são DAY (dia), MONTH (mês) e YEAR (ano) na forma DD-MM-YYYY. O tipo de dado TIME (tempo) tem pelo menos oito po-sições, com os componentes HOUR (hora), MI-NUTE (minuto) e SECOND (segundo) na forma HH:MM:SS. Somente datas e horas válidas de-vem ser permitidas pela implementação SQL. Isso implica que os meses devem estar entre 1 e 12 e as datas devem estar entre 1 e 31; além disso, uma data deve ser uma data válida para o mês correspondente. A comparaçãoCREATE DOMAIN TIPO_CPF AS CHAR(11);Podemos usar TIPO_CPF no lugar de CHAR(11) na Figura 4.1 para os atributos Cpf e Cpf_supervisor de FUNCIONARIO, Cpf_gerente de DEPARTAMENTO, Fcpf de TRABALHA_EM e Fcpf de DEPENDENTE. Um domínio também pode ter uma especificação padrão opcional por meio de uma cláusula DEFAULT, confor-me discutiremos mais adiante para os atributos. Ob-serve que os domínios podem não estar disponíveis em algumas implementações da SQL.4.2 Especificando restrições em SQLEsta seção descreve as restrições básicas que podem ser especificadas em SQL como parte da criação de ta-bela. Estas incluem restrições de chave e integridade re-ferencial, restrições sobre domínios de atributo e NULLs e restrições sobre tuplas individuais dentro de uma rela-ção. Discutiremos a especificação de restrições mais ge-rais, chamadas asserções (ou assertions) no Capítulo 5.4.2.1 Especificando restrições de atributo e defaults de atributoComo a SQL permite NULLs como valores de atributo, uma restrição NOT NULL pode ser especifi-cada se o valor NULL não for permitido para determi-nado 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 4.1.Capítulo 4 SQL básica 6104 elmas0810_cap04 BR.indd 61 11/30/10 5:22 PMTambém é possível definir um valor padrão para um atributo anexando a cláusula DEFAULT a uma definição de atributo. O valor padrão está incluí-do em qualquer nova tupla se um valor explícito não for fornecido para esse atributo. A Figura 4.2 ilustra um exemplo de especificação de um gerente default para um novo departamento e um departamento de-fault para um novo funcionário. Se nenhuma cláusula default for especificada, o valor padrão será NULL para atributos que não possuem a restrição NOT NULL.Outro tipo de restrição pode limitar valores de atri-buto ou domínio usando a cláusula CHECK (verifica-ção) após uma definição de atributo ou domínio.6 Por exemplo, suponha que números de departamento sejam restritos a números inteiros entre 1 e 20; então, pode-mos mudar a declaração de atributo de Dnumero na ta-bela DEPARTAMENTO (ver Figura 4.1) para o seguinte:Dnumero INT NOT NULL CHECK (Dnumero > 0 AND Dnumero 0 AND D_NUMem particular caso ela deva ser removida mais tarde e substituída por outra, conforme discutiremos no Capítulo 5. Dar nomes a restrições é algo opcional.4.2.4 Especificando restrições sobre tuplas usando CHECKAlém das restrições de chave e integridade re-ferencial, que são especificadas por palavras-chave especiais, outras restrições de tabela podem ser espe-cificadas 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 individualmente e são verifica-das sempre que uma tupla é inserida ou modificada. Por exemplo, suponha que a tabela DEPARTAMENTO da Figura 4.1 tivesse um atributo adicional Dep_data_criacao, que armazena a data em que o departamento foi criado. Então, poderíamos 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 (Dep_data_criacao FROM WHERE ;onde � é uma lista de nomes de atributo cujos valores devem ser recuperados pela consulta. � é 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 . Estes correspondem aos operadores da álgebra relacional =, , ≥ e ≠, respectivamente, e aos operadores da linguagem de programação C/C++ =, , >= e !=. A principal diferença sintática é o operador diferente. A SQL possui operadores de comparação adicional que apresentaremos de maneira gradual.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 6 para facilitar a refe-rê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’.C0: SELECT Datanasc, EnderecoFROM FUNCIONARIOWHERE Pnome=‘João’ AND Minicial=‘B’ AND Unome=‘Silva’;Esta consulta envolve apenas a relação FUNCIO-NARIO listada na cláusula FROM. A consulta selecio-na as tuplas FUNCIONARIO individuais que satisfa-zem a condição da cláusula WHERE, depois projeta o resultado nos atributos Datanasc e Endereco listados na cláusula SELECT.A cláusula SELECT da SQL especifica os atributos cujos valores devem ser recuperados, que são chama-dos atributos de projeção, e a cláusula WHERE especi-fica a condição booleana que deve ser verdadeira para qualquer tupla recuperada, que é conhecida como con-dição de seleção. A Figura 4.3(a) mostra o resultado da consulta C0 sobre o banco de dados da Figura 3.6.Podemos pensar em uma variável de tupla implí-cita (ou iterator) na consulta SQL variando ou repe-tindo sobre cada tupla individual na tabela FUNCIO-NARIO 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 é avalia-da como TRUE após substituir seus valores de atributo correspondentes — são selecionadas.Consulta 1. Recuperar o nome e endereço de to-dos os funcionários que trabalham para o depar-tamento ‘Pesquisa’.C1: SELECT Pnome, Unome, EnderecoFROM FUNCIONARIO, DEPARTAMENTOWHERE Dnome=‘Pesquisa’ AND Dnumero=Dnr;Na cláusula WHERE de C1, a condição Dnome = ‘Pesquisa’ é uma condição de seleção que escolhe a tupla de interesse em particular na tabela DEPARTA-MENTO, pois Dnome é um atributo de DEPARTAMEN-TO. A condição Dnumero = Dnr é chamada condição de junção, pois combina duas tuplas: uma de DEPAR-TAMENTO e uma de FUNCIONARIO, sempre que o va-lor de Dnumero em DEPARTAMENTO é igual ao valor de Dnr em FUNCIONARIO. O resultado da consulta C1 é mostrado na Figura 4.3(b). Em geral, qualquer número de condições de seleção e junção pode ser especificado em uma única consulta SQL.9 As cláusulas SELECT e FROM são necessárias em todas as consultas SQL. O WHERE é opcional (ver Seção 4.3.3).64 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 64 11/30/10 5:22 PMWENESMarcador de textoWENESMarcador de textoWENESMarcador de textoWENESTextoWENESTextocelecionaWENESTextoa partir deWENESTextoondeWENESRetânguloWENESRetânguloWENESRetânguloDatanasc Endereco09-01-1965 Rua das Flores, 751, São Paulo, SP(a) Pnome Unome EnderecoJoão Silva Rua das Flores, 751, São Paulo, SPFernando Wong Rua da Lapa, 34, São Paulo, SPRonaldo Lima Rua Rebouças, 65, Piracicaba, SPJoice Leite Av. Lucas Obes, 74, São Paulo, SP(b)Projnumero Dnum Unome Endereco Datanasc10 4 Souza Av. Artur de Lima, 54, Santo André, SP20-06-194130 4 Souza Av. Artur de Lima, 54, Santo André, SP20-06-1941(c)F.Pnome F.Unome S.Pnome S.UnomeJoão Silva Fernando WongFernando Wong Jorge BritoAlice Zelaya Jennifer SouzaJennifer Souza Jorge BritoRonaldo Lima Fernando WongJoice Leite Fernando WongAndré Pereira Jennifer Souza(d)F.Pnome1234567896633344555587999887777679876543216866688444476453453453769879879873388866555576(e)Pnome Minicial Unome Cpf Datanasc Endereco Sexo Salario Cpf_supervisor DnrJoão B Silva 1234567896609-01-1965 Rua das Flores, 751, São Paulo, SPM 30.000 33344555587 5Fernando T Wong 33344555587 08-12-1955 Rua da Lapa, 34, São Paulo, SPM 40.000 88866555576 5Ronaldo K Lima 66688444476 15-09-1962 Rua Rebouças, 65, Piracicaba, SPM 38.000 33344555587 5Joice A Leite 45345345376 31-07-1972 Av. Lucas Obes, 74, São Paulo, SPF 25.000 33344555587 5(g)Cpf Dnome12345678966 Pesquisa33344555587 Pesquisa99988777767 Pesquisa98765432168 Pesquisa66688444476 Pesquisa45345345376 Pesquisa98798798733 Pesquisa88866555576 Pesquisa12345678966 Administração33344555587 Administração99988777767 Administração98765432168 Administração66688444476 Administração45345345376 Administração98798798733 Administração88866555576 Administração12345678966 Matriz33344555587 Matriz99988777767 Matriz98765432168 Matriz66688444476 Matriz45345345376 Matriz98798798733 Matriz88866555576 Matriz(f)Figura 4.3 Resultados das consultas SQL quando aplicados ao estado do banco de dados EMPRESA mostrado na Figura 3.6. (a) C0. (b) C1. (c) C2. (d) C8. (e) C9. (f) C10. (g) C1C.Capítulo 4 SQL básica 6504 elmas0810_cap04 BR.indd 65 11/30/10 5:22 PMUma consulta que envolve apenas condições de seleção e junção mais atributos de projeção é conhe-cida 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 o sobrenome, endereço e data de nascimento do gerente do departamento.C2: SELECT Projnumero, Dnum, Unome, Endereco, DatanascFROM PROJETO, DEPARTAMENTO, FUNCIONARIOWHERE Dnum=Dnumero AND Cpf_gerente=Cpf ANDProjlocal=‘Mauá’;A condição de junção Dnum = Dnumero relaciona uma tupla de projeto a sua tupla de departamento que o controla, enquanto a condição de junção Cpf_geren-te = Cpf relaciona a tupla do departamento que o con-trola à tupla de funcionário que gerencia esse departa-mento. Cada tupla no resultado será uma combinação de um projeto, um departamento e um funcionário, que satisfaz as condições de junção. Os atributos de projeção são usados para escolher os atributos a serem exibidos com base em cada tupla combinada. O resul-tado da consulta C2 aparece na Figura 4.3(c).4.3.2 Nomes de atributos ambíguos, apelido, renomeação e variáveis de tuplaEm 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 tabelas se referir a dois ou mais atribu-tos com o mesmo nome, é preciso qualificar o nome do atributo com o nome da relação, para evitar am-biguidade. 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 3.5 e 3.6, os atributos Dnr e Unome da relação FUN-CIONARIO fossem chamados de Dnumero e Nome, e o atributo Dnome 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 de atributo Nome e Dnumero em C1A para especificar a quais estamos nos referindo, pois os mesmos nomes de atributo são usados nas duas relações:C1A: SELECT Pnome, FUNCIONARIO.Nome, EnderecoFROM FUNCIONARIO, DEPARTAMENTOWHERE DEPARTAMENTO.Nome=‘Pesquisa’ ANDDEPARTAMENTO.Dnumero=FUNCIONARIO.Dnumero;Nomes de atributo totalmente qualificados po-dem ser usados por clareza mesmo que não haja am-biguidade nos nomes de atributo. C1 aparece dessa maneira como C1’ a seguir. Também podemos criar um apelido para cada nome de tabela, para evitar a digitação repetida de nomes de tabela longos (ver C8, a seguir).C1’: SELECT FUNCIONARIO.Pnome, FUNCIONARIO.UNome FUNCIONARIO.Endereco,FROM FUNCIONARIO, DEPARTAMENTOWHERE DEPARTAMENTO.DNome=‘Pesquisa’ ANDDEPARTAMENTO.Dnumero= FUNCIONARIO.Dnr;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 pri-meiro e o último nome do funcionário e o primei-ro e o último nome de seu supervisor imediato.C8: SELECT F.Pnome, F.Unome, S.Pnome, S.UnomeFROM FUNCIONARIO AS F, FUNCIONARIO AS SWHERE F.Cpf_supervisor=S.Cpf;Neste caso, precisamos declarar nomes de re-lação alternativos F e S, chamados apelidos ou va-riáveis de tupla, para a relação FUNCIONARIO. Um apelido pode vir após a palavra-chave AS, como mostramos em C8, ou pode vir diretamente após o nome da relação — por exemplo, escrevendo FUN-CIONARIO F, FUNCIONARIO S na cláusula FROM de C8. Também é possível renomear os atributos da relação dentro da consulta em SQL, dando-lhe ape-lidos. Por exemplo, se escrevermosFUNCIONARIO AS F(Pn, Mi, Un, Cpf, Dn, End, Sexo, Sal, Scpf, Dnr)na cláusula FROM, Pn torna-se um apelido para Pno-me, Mi para Minicial, Un para Unome, e assim por diante.Em C8, podemos pensar em F e S como duas cópias diferentes da relação FUNCIONARIO; a primei-66 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 66 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetânguloWENESRetângulora, F, representa funcionários no papel de supervisio-nados ou subordinados; a segunda, S, representa os funcionários no papel de supervisores. Agora, pode-mos juntar as duas cópias. Naturalmente, na realida-de existe apenas uma relação FUNCIONARIO, e a con-diçã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 6.4.2. Nas versões anteriores da SQL, não era possível especificar uma consulta recursiva geral, com um número desconhe-cido de níveis, em uma única instrução SQL. Uma construção para especificar consultas recursivas foi incorporada na SQL:1999 (ver Capítulo 5).O resultado da consulta C8 aparece na Figura 4.3(d). Sempre que um ou mais apelidos são dados a uma relação, podemos usar esses nomes para repre-sentar diferentes referências a essa mesma relação. Isso permite múltiplas referências à mesma relação dentro de uma consulta.Podemos usar esse mecanismo de nomeação de apelidos em qualquer consulta SQL para especificar variáveis de tupla para cada tabela na cláusula WHE-RE, não importando se a mesma relação precisa ser referenciada mais de uma vez. De fato, essa prática é recomendada, pois resulta em consultas mais fáceis de compreender. Por exemplo, poderíamos especifi-car a consulta C1 como em C1B:C1B: SELECT F.Pnome, F.Unome, F.EnderecoFROM FUNCIONARIO F, DEPARTAMENTO DWHERE D.DNome=‘Pesquisa’ AND D.Dnumero=F.Dnr;4.3.3 Cláusula WHERE não especificada e uso do asteriscoVamos 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 combi-nações de tuplas possíveis — dessas relações será se-lecionado. Por exemplo, a Consulta 9 seleciona todos os Cpfs de FUNCIONARIO (Figura 4.3(e)) e a Consul-ta 10 seleciona todas as combinações de um Cpf de FUNCIONARIO e um Dnome de DEPARTAMENTO, in-dependentemente de o funcionário trabalhar ou não para o departamento (Figura 4.3(f)).Consultas 9 e 10. Selecionar todos os Cpfs de FUNCIONARIO (C9) e todas as combinações de Cpf de FUNCIONARIO e Dnome de DEPARTAMENTO (C10) no banco de dados.C9: SELECT CpfFROM FUNCIONARIO;C10: SELECT Cpf, DnomeFROM FUNCIONARIO, DEPARTAMENTO;É extremamente importante especificar cada condição de seleção e junção na cláusula WHERE. Se alguma condição dessetipo for esquecida, o resulta-do poderá ser relações incorretas e muito grandes. Observe que C10 é semelhante a uma operação de PRODUTO CARTESIANO seguida por uma operação PROJECAO na álgebra relacional (ver Capítulo 6). Se especificarmos todos os atributos de FUNCIONARIO e DEPARTAMENTO em C10, obteremos o PRODUTO CARTESIANO real (exceto pela eliminação de dupli-catas, se houver).Para recuperar todos os valores de atributo das tuplas selecionadas, não precisamos listar os nomes de atributo explicitamente em SQL; basta especifi-car um asterisco (*), que significa todos os atribu-tos. Por exemplo, a consulta C1C recupera todos os valores de atributo de qualquer FUNCIONARIO que trabalha no DEPARTAMENTO número 5 (Figura 4.3(g)), a consulta C1D recupera todos os atributos de um FUNCIONARIO e os atributos do DEPARTA-MENTO em que ele ou ela trabalha para todo funcio-nário no departamento ‘Pesquisa’, e C10A especifica o PRODUTO CARTESIANO das relações FUNCIONA-RIO e DEPARTAMENTO.C1C: SELECT *FROM FUNCIONARIOWHERE Dnr=5;C1D: SELECT *FROM FUNCIONARIO, DEPARTAMENTOWHERE Dnome=‘Pesquisa’ AND Dnr=Dnumero;C10A: SELECT *FROM FUNCIONARIO, DEPARTAMENTO;4.3.4 Tabelas como conjuntos em SQLConforme já dissemos, a SQL normalmente tra-ta 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. A SQL não elimina automaticamente tuplas duplicadas nos resultados das consultas, pelos seguintes motivos:Capítulo 4 SQL básica 6704 elmas0810_cap04 BR.indd 67 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetânguloWENESRetânguloWENESRetânguloWENESRetânguloWENESRetângulo � A eliminação de duplicatas é uma operação dispendiosa. Um modo de implementá-la é classificar as tuplas primeiro e depois elimi-nar as duplicatas. � O usuário pode querer ver as tuplas duplica-das no resultado de uma consulta. � Quando uma função agregada (ver Seção 5.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 na cláusula SELECT, signifi-cando que apenas as tuplas distintas deverão permane-cer no resultado. Em geral, uma consulta com SELECT DISTINCT elimina duplicatas, enquanto uma consulta com SELECT ALL não elimina. A especificação de SE-LECT sem ALL ou DISTINCT — como em nossos exem-plos 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 va-lor de salário aparecerá muitas vezes no resultado da consulta, como mostra a Figura 4.4(a). Se estivermos interessados apenas em valores de salário distintos, queremos que cada valor apareça apenas uma vez, in-dependentemente de quantos funcionários ganham esse salário. Usando a palavra-chave DISTINCT, como em C11A, conseguimos isso, como mostra a Figura 4.4(b).Consulta 11. Recuperar o salário de cada fun-cionário (C11) e todos os valores de salário dis-tintos (C11A).C11: SELECT ALL SalarioFROM FUNCIONARIO;C11A: SELECT DISTINCT SalarioFROM FUNCIONARIO;A SQL incorporou diretamente algumas das ope-rações de conjunto da teoria de conjuntos da matemá-tica, que também fazem parte da álgebra relacional (ver Capítulo 6). Existem operações de união de con-junto (UNION), diferença de conjunto (EXCEPT),11 e interseção de conjunto (INTERSECT). As relações re-sultantes 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 união, 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.Consulta 4. Fazer uma lista de todos os números de projeto para aqueles que envolvam um fun-cionário cujo último nome é ‘Silva’, seja como um trabalhador ou como um gerente do depar-tamento que controla o projeto.C4A: ( SELECT DISTINCT ProjnumeroFROM PROJETO, DEPARTAMENTO, FUNCIONARIOWHERE Dnum=Dnumero AND Cpf_gerente=CpfAND Unome=‘Silva’ )UNION( SELECT DISTINCT ProjnumeroFROM PROJETO, TRABALHA_EM, FUNCIONARIOWHERE Projnumero=Pnr AND Fcpf=CpfAND Unome=‘Silva’ );A primeira consulta SELECT recupera os pro-jetos que envolvem um ‘Silva’ como gerente do de-10 Em geral, uma tabela SQL não precisa ter uma chave, embora, na maioria dos casos, exista uma.11 Em alguns sistemas, a palavra-chave MINUS é usada para a operação de diferença de conjunto, em vez de EXCEPT.Salário30.00040.00025.00043.00038.00055.000(b)Salário30.00040.00025.00043.00038.00025.00025.00055.000(a)Pnome Unome(c)Pnome UnomeFernando Wong(d)Figura 4.4Resultados de consultas SQL adicionais, quando aplicadas ao estado de banco de dados EMPRESA, mostrados na Figura 3.6. (a) C11. (b) C11A. (c) C12. (d) C12A.68 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 68 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetângulopartamento 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 de projeto envolvendo qualquer um deles se-riam recuperados. A aplicação da operação UNION às duas consultas SELECT gera o resultado desejado.A SQL também possui operações multiconjuntos correspondentes, que são acompanhadas da palavra--chave ALL (UNION ALL, EXCEPT ALL, INTERSECT ALL). Seus resultados são multiconjuntos (duplicatas não são eliminadas). O comportamento dessas ope-rações é ilustrado pelos exemplos da Figura 4.5. Ba-sicamente, cada tupla — seja ela uma duplicata ou não — é considerada uma tupla diferente ao aplicar essas operações.4.3.5 Combinação de padrão de subcadeias e operadores aritméticosNesta seção, discutimos vários outros recur-sos da SQL. O primeiro recurso permite condições de comparação apenas sobre partes de uma cadeia de caracteres, usando o operador de comparação LIKE. Isso pode ser usado para combinação de padrão de cadeia. Cadeias parciais são especificadas usando dois caracteres reservados: % substitui um número qualquer de zero ou mais caracteres, e o sublinhado (_) substitui um único caractere. Por exemplo, consi-dere a seguinte consulta.Consulta 12. Recuperar todos os funcionários cujo endereço esteja em São Paulo, SP.C12: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE Endereco LIKE ‘%SaoPaulo,SP%’;Para recuperar todos os funcionários que nasce-ram durante a década de 1950, podemos usar a Con-sulta C12A. Aqui, ‘5’ precisa ser o nono caractere da cadeia (de acordo com nosso formato para data), de modo que usamos o valor ‘_ _ _ _ _ _ _ _ 5 _’, com cada sublinhado servindo como um marcador de lu-gar para um caractere qualquer.Consulta 12A. Encontrar todos os funcionários que nasceram durante a década de 1950.C12: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE Datanasc 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 ca-deia usando a palavra-chave ESCAPE. Por exemplo, ‘AB\_CD\%EF’ ESCAPE ‘\’ representa a cadeia literal ‘AB_CD%EF’, pois \ é especificado como o caracte-re de escape. Qualquer caractere não usado na cadeia pode ser escolhido como caractere de escape. Além disso, precisamos de uma regra para especificar após-trofos ou aspas simples (‘ ’) se eles tiverem de ser in-cluí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 consecu-tivos (’’), de modo que não será interpretado como o término da cadeia. Observe que a comparação de sub-cadeia implica que os valores de atributo não sejam valores atômicos (indivisíveis), conforme assumimos no modelo relacional formal (ver Seção 3.1).Outro recurso permite o uso de aritmética nas con-sultas. Os operadores aritméticos padrão para adição (+), subtração (–), multiplicação (*) e divisão (/) po-dem 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 por cento; podemos fazer a Consulta 13 para ver quais seriam seus novos salários. Este exemplo tam-bém mostra como podemos renomear um atributo no resultado da consulta usando AS na cláusula SELECT.Consulta 13. Mostrar os salários resultantes se cada funcionário que trabalha no projeto ‘Pro-dutoX’ receber um aumento de 10 por cento.C13: SELECT F.Pnome, F.Unome, 1,1 * F.Salario AS Aumento_salarioFROM FUNCIONARIO AS F, TRABALHA_EM AS T, PROJETO AS PWHERE F.Cpf=T.Fcpf AND T.Pnr=P.Projnumero AND P.Projnome=‘ProdutoX’;Figura 4.5Os resultados das operações de 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).Aa1a2a2a3(a)Aa1a2a4a5R SAa1a1a2a2a2a3a4a5(b) TAa2a3(c) TAa1a2(d) TCapítulo 4 SQL básica 6904 elmas0810_cap04 BR.indd 69 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetânguloPara os tipos de dados de cadeia, o operador de concatenação || pode ser usado em uma consulta para anexar dois valores de cadeia. Para tipos de da-dos data, hora, timestamp e intervalo, os operadores incluem incremento (+) ou decremento (–) de uma data, hora ou timestamp por um intervalo. Além disso, um valor de intervalo é o resultado da dife-rença entre dois valores de data, hora ou timestamp. Outro 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 R$ 30.000 e R$ 40.000.C14: SELECT *FROM FUNCIONARIOWHERE (Salario BETWEEN 30.000 AND 40.000) AND Dnr = 5;A condição (Salario BETWEEN 30.000 AND 40.000) em C14 é equivalente à condição ((Salario >= 30.000) AND (Salario FROM [ WHERE ][ ORDER BY ];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 selecio-nar as tuplas dessas relações, incluindo condições de junção, se necessário. ORDER BY especifica uma or-dem para exibir os resultados de uma consulta. Duas cláusulas adicionais, GROUP BY e HAVING, serão des-critas na Seção 5.1.8.No Capítulo 5, apresentaremos recursos mais complexos das consultas SQL. Estes incluem os se-guintes: 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 po-dem combinar registros de várias tabelas de diferen-tes maneiras.4.4 Instruções INSERT, DELETE e UPDATE em SQLEm SQL, três comandos podem ser usados para modificar o banco de dados: INSERT, DELETE e UPDATE. Discutiremos cada um deles.4.4.1 O comando INSERTEm sua forma mais simples, INSERT é usado para acrescentar uma única tupla a uma relação. Te-mos de especificar o nome da relação e uma lista de valores para a tupla. Os valores devem ser listados na mesma ordem em que os atributos correspondentes foram especificados no comando CREATE TABLE. Por exemplo, para acrescentar uma nova tupla à relação FUNCIONARIO mostrada na Figura 3.5 e especificada no comando CREATE TABLE FUNCIONARIO... da Fi-gura 4.1, podemos usar U1:70 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 70 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetânguloU1: INSERT INTO FUNCIONARIOVALUES ( ‘Ricardo’, ‘K’, ‘Marini’, ‘65329865388’, ‘30-12-1962’, ‘Rua Itapira, 44, Santos, SP’, ‘M’, 37.000, ‘65329865388’, 4 );Uma segunda forma da instrução INSERT per-mite 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 em uma nova tupla. Porém, os valores pre-cisam 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 FUNCIONARIO do qual co-nhecemos apenas os atributos Pnome, Unome, Dnr e Cpf, podemos usar U1A:U1A: INSERT INTO FUNCIONARIO (Pnome, Unome, Dnr, Cpf)VALUES (‘Ricardo’, ‘Marini’, 4, ‘65329865388’);Os atributos não especificados em U1A são defi-nidos 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 em uma relação múltiplas tuplas se-paradas 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 integrida-de que podem ser especificadas na DDL. Por exem-plo, se emitirmos o comando em U2 sobre o banco de dados mostrado na Figura 3.6, o SGBD deve rejeitar a operação, pois não existe uma tupla DEPARTAMEN-TO no banco de dados com Dnumero = 2. De modo semelhante, U2A seria rejeitado porque nenhum va-lor de Cpf é fornecido e essa é a chave primária, que não pode ser NULL.U2: INSERT INTO FUNCIONARIO (Pnome, Unome, Cpf, Dnr)VALUES (‘Roberto’, ‘Gomes’, ‘98076054011’, 2);(U2 é rejeitado se a verificação da integridade referencial for oferecida pelo SGBD.)U2A: INSERT INTO FUNCIONARIO (Pnome, Unome, Dnr)VALUES (‘Roberto’, ‘Gomes’, 5);(U2 é rejeitado se a verificação de NOT NULL for oferecida pelo SGBD.)Uma variação do comando INSERT inclui várias tuplas em uma relação em conjunto com a criação da relação e sua carga com o resultadode uma consulta. Por exemplo, para criar uma tabela temporária que possui o sobrenome do funcionário, o nome do pro-jeto e as horas por semana para cada funcionário que trabalha em um projeto, podemos escrever as instru-ções em U3A e U3B:U3A: CREATE TABLE TRABALHA_EM_INFO( Func_nome VARCHAR(15),Proj_nome VARCHAR(15),Horas_semanal DECIMAL(3,1) );U3B: INSERT INTO TRABALHA_EM_INFO ( Func_nome, Proj_nome, Horas_por_semana )SELECT F.Unome, P.Projnome, T.HorasFROM PROJETO P, TRABALHA_EM T, FUNCIONARIO FWHERE P.Projnumero=T.Pnr AND T.Fcpf=F.Cpf;Uma tabela TRABALHA_EM_INFO é criada por U3A e é carregada com a informação da junção re-cuperada do banco de dados pela consulta em U3B. Agora, podemos consultar TRABALHA_EM_INFO como faríamos com qualquer outra relação; quan-do não precisarmos mais dela, poderemos removê--la usando o comando DROP TABLE (ver Capítulo 5). Observe que a tabela TRABALHA_EM_INFO pode não estar atualizada; ou seja, se atualizarmos qual-quer uma das relações PROJETO, TRABALHA_EM ou FUNCIONARIO depois de emitir U3B, a informação em TRABALHA_EM_INFO pode ficar desatualizada. Temos de criar uma visão, ou view (ver Capítulo 5), para manter essa tabela atualizada.4.4.2 O comando DELETEO comando DELETE remove tuplas de uma re-lação. Ele inclui uma cláusula WHERE, semelhante a que é usada em uma consulta SQL, para selecionar as tuplas a serem excluídas. As tuplas são explicita-mente excluídas de apenas uma tabela por vez. No entanto, a exclusão pode se propagar para as tuplas Capítulo 4 SQL básica 7104 elmas0810_cap04 BR.indd 71 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetânguloWENESRetânguloem outras relações, se ações de disparo referencial forem especificadas nas restrições de integridade re-ferencial da DDL (ver Seção 4.2.2).12 Dependendo do número de tuplas selecionadas 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 ta-bela 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 5). Os comandos DELETE em U4A a U4D, se aplicados de maneira independente ao banco de dados da Figura 3.6, excluirão zero, uma, quatro e todas as tuplas, respectivamente, da relação FUNCIONARIO:U4A: DELETE FROM FUNCIONARIOWHERE Unome=‘Braga’;U4B: DELETE FROM FUNCIONARIOWHERE Cpf=‘12345678966’;U4C: DELETE FROM FUNCIONARIOWHERE Dnr=5;U4D: DELETE FROM FUNCIONARIO;4.4.3 O comando UPDATEO comando UPDATE é usado para modificar valores de atributo de uma ou mais tuplas seleciona-das. Assim como no comando DELETE, uma cláusula WHERE no comando UPDATE seleciona as tuplas a serem modificadas em uma única relação. No en-tanto, 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 refe-rencial for especificada nas restrições de integridade referencial da DDL (ver Seção 4.2.2). Uma cláusu-la SET adicional no comando UPDATE especifica os atributos a serem modificados e seus novos valores. Por exemplo, para alterar o local e número de depar-tamento que controla o número de projeto 10 para ‘Santo André’ e 5, respectivamente, usamos U5:U5: UPDATE PROJETOSET Projlocal = ‘Santo André’, Dnum = 5WHERE Projnumero=10;Várias tuplas podem ser modificadas com um único comando UPDATE. Um exemplo é dar a todos os funcionários no departamento ‘Pesquisa’ um au-mento de 10 por cento no salário, como mostra U6. Nesta solicitação, o valor de Salario modificado de-pende 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 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 FUNCIONARIOSET Salario = Salario * 1,1WHERE Dnr = 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.4.5 Recursos adicionais da SQLA SQL possui uma série de recursos adicionais que não descrevemos neste capítulo, mas que discuti-remos em outras partes do livro. São eles: � No Capítulo 5, que é uma continuação deste capítulo, apresentaremos os seguin-tes recursos da SQL: diversas técnicas para especificar consultas de recuperação com-plexas, incluindo consultas aninhadas, fun-ções de agregação, agrupamento, tabelas com junções (join), junções externas (outer joins) e consultas 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 escrever 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 prede-cessor ODBC (Open Data Base Connectivi-ty) e SQL/PSM (Persistent Stored Modules). Discutiremos essas técnicas no Capítulo 13. Também discutiremos como acessar bancos de dados SQL por meio da linguagem de pro-gramação Java usando JDBC e SQLJ. � Cada SGBDR comercial terá, além dos co-mandos SQL, um conjunto de comandos para especificar parâmetros de projeto do 12 Outras ações podem ser aplicadas automaticamente por meio de disparos (ver Seção 26.1) e outros mecanismos.72 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 72 11/30/10 5:22 PMWENESRetânguloWENESRetânguloWENESRetângulobanco de dados físico, estruturas de ar-quivo para relações e caminhos de acesso, como índices. Chamamos esses comandos de linguagem de definição de armazena-mento (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 conceitual. Muitos sistemas ainda têm comandos CREATE INDEX. � A SQL possui comandos de controle de tran-sação. Estes são usados para especificar uni-dades de processamento de banco de dados para fins de controle de concorrência e re-cuperação. Discutiremos esses comandos no Capítulo 21, depois de discutirmos o concei-to de transações com mais detalhes. � A SQL possui construções da linguagem para especificar a concessão e revogação de privilégios aos usuários. Os privilégios nor-malmente correspondem ao direito de usar certos comandos SQL para acessar deter-minadas 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 views a certos usuários. Esses comandos SQL — chamados de GRANT e REVOKE — serão discutidos no Capítulo 24, onde falare-mos sobre segurança e autorização no banco de dados. � A SQL possui construções de linguagem para a criação de triggers. Estas geralmente são conhecidas como técnicas de banco de dados ativo, pois especificam ações que são disparadas automaticamente por eventos, como atua lizações no banco de dados. Dis-cutiremos esses recursos na Seção 26.1, na qual abordaremos os conceitos de banco de dados ativo. � A SQL incorporou muitos recursos dos mo-delos orientados a objeto para ter capaci-dades mais poderosas, levando a sistemas relacionais avançados, conhecidos como objeto-relacional. Capacidades como criar atributos complexos (também chamadas re-lações aninhadas), especificar tipos de dados abstratos (chamados UDTs ou tipos defini-dos pelo usuário) para atributos e tabelas, criar identificadoresde objeto para referen-ciar tuplas e especificar operações sobre tipos serão discutidas no Capítulo 11. � SQL e bancos de dados relacionais podem interagir com novas tecnologias, como XML (ver Capítulo 12) e OLAP (Capítulo 29).ResumoNeste capítulo, apresentamos a linguagem de ban-co de dados SQL. Essa linguagem e suas variações têm sido implementadas como interfaces para muitos SGBDs relacionais comerciais, incluindo Oracle e Rdb, da Ora-cle;13 DB2, Informix Dynamic Server e SQL/DS, da IBM; SQL Server e Access, da Microsoft; e INGRES. Alguns sistemas de código aberto também fornecem SQL, como MySQL e PostgreSQL. A versão original da SQL foi im-plementada no SGBD experimental chamado SYSTEM R, que foi desenvolvido na IBM Research. A SQL foi projetada para ser uma linguagem abrangente, que in-clui instruções para definição de dados, consultas, atua-lizações, especificação de restrição e definição de view. Discutimos os seguintes recursos da SQL neste capítulo: os comandos de definição de dados para criar tabelas, comandos para especificação de restrição, consultas de recuperação simples e comandos de atualização de ban-co de 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 4.1. Como as relações (tabelas) em SQL diferem das relações definidas formalmente no Capítulo 3? Discuta as outras diferenças na terminologia. Por que a SQL permite tuplas duplicadas em uma tabela ou em um resultado de consulta? 4.2. Liste os tipos de dados que são permitidos para atributos SQL. 4.3. Como a SQL permite a implementação das res-trições de integridade de entidade e de integri-dade referencial descritas no Capítulo 3? E as ações de disparo referencial? 4.4. Descreva as quatro cláusulas na sintaxe de uma consulta de recuperação SQL simples. Mostre que tipo de construções pode ser especificado em cada uma das cláusulas. Quais são obrigatórias e quais são opcionais?13 O Rdb foi produzido originalmente pela Digital Equipment Corporation. Ele foi comprado da Digital pela Oracle em 1994, e está recebendo suporte e sendo melhorado.Capítulo 4 SQL básica 7304 elmas0810_cap04 BR.indd 73 11/30/10 5:22 PMExercícios 4.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 ins-truções DDL da SQL apropriadas para definir o banco de dados. 4.6. Repita o Exercício 4.5, mas use o esquema de ban-co de dados COMPANHIA AEREA da Figura 3.8. 4.7. Considere o esquema de banco de dados rela-cional BIBLIOTECA mostrado na Figura 4.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 atuali-zação de um valor de atributo de chave primária em uma tupla referenciada. Justifique suas esco-lhas. 4.8. Escreva as instruções DDL da SQL apropriadas para declarar o esquema de banco de dados re-lacional BIBLIOTECA da Figura 4.6. Especifique as chaves e ações de disparo referencial. 4.9. Como as restrições de chave e chave estrangei-ra podem ser impostas pelo SGBD? A técnica de imposição que você sugere é difícil de imple-mentar? As verificações de restrição podem ser executadas de modo eficiente quando as atuali-zações são aplicadas ao banco de dados? 4.10. Especifique as seguintes consultas em SQL sobre o esquema de banco de dados relacional EM-PRESA mostrado na Figura 3.5. Mostre o re-sultado de cada consulta se ela for aplicada ao banco de dados EMPRESA na Figura 3.6.a. Recupere os nomes de todos os funcionários no departamento 5 que trabalham 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 pri-meiro nome que seu próprio.c. Ache os nomes de todos os funcionários que são supervisionados diretamente por ‘Fer-nando Wong’. 4.11. Especifique as atualizações do Exercício 3.11 usando comandos de atualização da SQL. 4.12. Especifique as consultas a seguir em SQL no es-quema de banco de dados da Figura 1.2.a. Recupere os nomes de todos os alunos sênior se formando em ‘CC’ (Ciência da computação).b. Recupere os nomes de todas as disciplinas lecio-nadas pelo Professor Kleber em 2007 e 2008.c. Para cada matéria lecionada pelo Professor Kle-ber, recupere o número da disciplina, semestre, ano e número de alunos que realizaram a matéria.d. Recupere o nome e o histórico de cada aluno sênior (Tipo_aluno = 4) formando em CC. Um histórico inclui nome da disciplina, número da disciplina, crédito, semestre, ano e nota para cada disciplina concluída pelo aluno. 4.13. Escreva instruções de atualização SQL para rea-lizar ações sobre o esquema de banco de dados mostrado na Figura 1.2.a. Inserir um novo aluno , no banco de dados.b. Alterar a turma do aluno ‘Silva’ para 2.c. Inserir uma nova disciplina, .d. Excluir o registro para o aluno cujo nome é ‘Silva’ e cujo número de aluno é 17.Figura 4.6 Um esquema de banco de dados relacional para um banco de dados BIBLIOTECA.LIVROCod_livro Titulo Nome_editoraLIVRO_AUTORCod_livro Nome_autorEDITORANome Endereco TelefoneLIVRO_COPIASCod_livro Cod_unidade Qt_copiaLIVRO_EMPRESTIMOCod_livroCod_unidadeNr_cartaoData_emprestimoData_devolucaoUNIDADE_BIBLIOTECACod_unidade Nome_unidade EnderecoUSUARIONum_cartao Nome Endereco Telefone74 Sistemas de banco de dados04 elmas0810_cap04 BR.indd 74 11/30/10 5:22 PM 4.14. Crie um esquema de banco de dados relacional para uma aplicação de 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 ban-co de dados.c. Com base em seu uso esperado do banco de dados, escolha alguns atributos que deverão ter índices específicos.d. Implemente seu banco de dados, se você tiver um SGBD que suporta SQL. 4.15. Considere que a restrição CHESUPERFUNC da tabela FUNCIONARIO, conforme especificado na Figura 4.2, seja mudada para:CONSTRAINT CHESUPERFUNCREFERENCES FUNCIONARIO(Cpf)ON DELETE CASCADE ON UPDATE CASCADE,FOREIGN KEY (Cpf_supervisor)Responda às seguintes questões:a. O que acontece quando o comando a seguir é executado no estado de banco de dados mos-trado na Figura 3.6?DELETE FUNCIONARIO WHERE Unome = ‘Brito’b. É melhor usar CASCADE ou SET NULL no caso da restrição ON DELETE de CHESUPERFUNC? 4.16. Escreva instruções SQL para criar uma tabela FUNCIONARIO_BACKUP para fazer o backup da tabela FUNCIONARIO mostrada na Figura 3.6.Bibliografia selecionadaA 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 Re-search, em San Jose, Califórnia. Mostraremos outras refe-rências aos vários aspectos da SQL ao final do Capítulo 5.Capítulo 4 SQL básica 7504 elmas0810_cap04 BR.indd 75 11/30/10 5:22 PMEste capítulo descreve recursos mais avançados da linguagem SQL padrão para bancos de dados re-lacionais. Começamos na Seção 5.1 apresentando re-cursos mais complexos das consultas de recuperação SQL, como consultas aninhadas, tabelas com jun-ções, junções externas, funções de agregação e agru-pamento. Na Seção 5.2, descrevemos o comando CREATE ASSERTION, que permite a especificação de restrições mais gerais sobre o banco de dados. Tam-bém apresentamos o conceito de triggers (gatilhos) e o comando CREATETRIGGER, 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 5.3, descrevemos a facilidade da SQL para de-finir views (visões) no banco de dados. As views tam-bém são chamadas de tabelas virtuais ou derivadas, pois apresentam ao usuário o que parecem ser tabe-las; porém, a informação nessas tabelas é derivada de tabelas previamente definidas. A Seção 5.4 apresenta o comando SQL ALTER TABLE, que é usado para mo-dificar as tabelas e restrições do banco de dados. No final há um resumo do capítulo.Este capítulo é uma continuação do Capítulo 4. O leitor poderá pular partes deste capítulo se desejar uma introdução menos detalhada à linguagem SQL.5.1 Consultas de recuperação SQL mais complexasNa Seção 4.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 permi-tem que os usuários especifiquem recuperações mais complexas do banco de dados. Discutiremos vários desses recursos nesta seção.5.1.1 Comparações envolvendo NULL e lógica de três valoresA SQL tem diversas regras para lidar com valores NULL. Lembre-se, da Seção 3.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 (existe, mas não é conhecido), valor não disponível (existe, mas é propositadamente retido) ou valor não aplicável (o atributo é indefi-nido para essa tupla). Considere os seguintes exem-plos para ilustrar cada um dos significados de NULL. 1. Valor desconhecido. A data de nascimento de uma pessoa não é conhecida, e por isso é re-presentada por NULL no banco de dados. 2. Valor indisponível ou retido. Uma pessoa tem um telefone residencial, mas não deseja que ele seja listado, por isso ele é retido e repre-sentado como NULL no banco de dados. 3. Atributo não aplicável. Um atributo Conjuge seria NULL para uma pessoa que não fosse ca-sada, pois ele não se aplica a essa pessoa.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 é consi-derado diferente de qualquer outro valor NULL nos diversos registros do banco de dados. Quando um capítulo 5Mais SQL: Consultas complexas, triggers, views e modificação de esquema05 elmas0810_cap05 BR.indd 76 11/30/10 5:22 PMNULL está envolvido em uma operação de compara-ção, o resultado é considerado UNKNOWN, ou des-conhecido (e 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 FALSF. Portanto, é necessário definir os resultados (ou valores verdadeiros) das expressões lógicas de três valores quando os conectivos lógicos AND, OR e NOT forem usados. A Tabela 5.1 mostra os valores resultantes.Nas Tabelas 5.1(a) e 5.1(b), as linhas e colunas representam os valores dos resultados das condi-ções de comparação, que normalmente aparece-riam 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 5.1(a). A Ta-bela 5.1(b) mostra o resultado do uso do conecti-vo lógico OR. Por exemplo, o resultado de (FALSE AND UNKNOWN) é FALSE, ao passo que o resultado de (FALSE OR UNKNOWN) é UNKNOWN. A Tabela 5.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 geral é 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 combi-nações de tupla que são 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 5.1.6.A SQL permite consultas que verificam se o va-lor de um atributo é NULL. Em vez de usar = ou 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 sen-do distinto de cada outro valor NULL, de modo que a comparação de igualdade não é apropriada. Aconte-ce que, quando uma condição de junção é especifica-da, 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 5.1.6). A Consulta 18 ilustra isso.Consulta 18. Recuperar os nomes de todos os funcionários que não possuem supervisores.C18: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE Cpf_supervisor IS NULL;5.1.2 Consultas aninhadas, tuplas e comparações de conjunto/multiconjuntoAlgumas consultas precisam que os valores exis-tentes no banco de dados sejam buscados e depois usados em uma condição de comparação. Essas consultas podem ser formuladas convenientemente usando consultas aninhadas, que são blocos select--from-where completos dentro da cláusula WHERE de outra consulta. Essa outra consulta é chamada de consulta externa. A Consulta 4 é formulada em C4 sem uma consulta aninhada, mas pode ser reformula-da para usar consultas aninhadas, como mostramos em C4A. A C4A introduz o operador de comparação IN, que compara um valor v com um conjunto (ou multiconjunto) de valores V e avalia como TRUE se v for um dos elementos em V.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 PROJ-NUMERO dessa tupla estiver no resultado de qual-quer uma das consultas aninhadas.Tabela 5.1Conectivos lógicos na lógica de três valores.AND TRUE FALSE UNKNOWNTRUE TRUE FALSE UNKNOWNFALSE FALSE FALSE FALSEUNKNOWN UNKNOWN FALSE UNKNOWNOR TRUE FALSE UNKNOWNTRUE TRUE TRUE TRUEFALSE TRUE FALSE UNKNOWNUNKNOWN TRUE UNKNOWN UNKNOWN NOTTRUE FALSEFALSE TRUEUNKNOWN UNKNOWN(a) (b) (c)Capítulo 5 Mais SQL: Consultas complexas, triggers, views e modificação de esquema 7705 elmas0810_cap05 BR.indd 77 11/30/10 5:22 PMC4A: SELECT DISTINCT ProjnumeroFROM PROJETOWHERE Projnumero IN( SELECT ProjnumeroFROM PROJETO, DEPARTAMENTO, FUNCIONARIOWHEREDnum=Dnumero ANDCpf_gerente=Cpf AND Unome=‘Silva’ ) OR Projnumero IN( SELECT PnrFROM TRABALHA_EM, FUNCIONARIOWHERE Fcpf=Cpf AND Unome=‘Silva’ );Se uma consulta aninhada retornar um único atri-buto e uma única tupla, o resultado da consulta será um único valor (escalar). Nesses casos, é permitido usar = em vez de IN para o operador de comparação. Em ge-ral, 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 com-parações, colocando-os entre parênteses. Para ilustrar isso, considere a seguinte consulta:SELECT DISTINCT FcpfFROM TRABALHA_EMWHERE (Pnr, Horas) IN ( SELECT Pnr, HorasFROM TRABALHA_EMWHERE Fcpf=‘12345678966’ );Essa consulta selecionará os Fcpfs de todos os fun-cionários que trabalham na mesma combinação (pro-jeto, horas) em algum projeto que o funcionário ‘João Silva’ (cujo Cpf = ‘12345678966’) trabalha. Neste exemplo, o operador IN compara a subtupla de valo-res entre parênteses (Pnr, Horas) dentro de cada tupla em TRABALHA_EM com o conjunto de tuplas com tipos compatíveis produzidas pela consultaaninhada.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 efei-to. Outros operadores que podem ser combinados com ANY (ou SOME) incluem >, >=, . A palavra-chave ALL também pode ser combinada com cada um desses operadores. Por exemplo, a condição de comparação (v > ALL V) retorna TRUE se o valor v é maior do que todos os valores no conjunto (ou multiconjunto) V. Um exemplo é a consulta a seguir, que retorna os nomes dos funcionários cujo salário é maior do que o salário de todos os funcionários no departamento 5:SELECT Unome, PnomeFROM FUNCIONARIOWHERE Salario > ALL ( SELECT SalarioFROM FUNCIONARIOWHERE Dnr=5 );Observe que essa consulta também pode ser es-pecificada usando a função de agregação MAX (ver Seção 5.1.7).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 consulta exterior e outro em uma relação na cláusula FROM da consulta aninhada. A re-gra é que uma referência a um atributo não qualifica-do 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 re-lação PROJETO refere-se à relação PROJETO especifi-cada 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 (variável de tupla) para essa relação. Es-sas regras são semelhantes à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, consi-dere a Consulta 16.Consulta 16. Recuperar o nome de cada fun-cionário que tem um dependente com o mesmo nome e com o mesmo sexo do funcionário.C16: SELECT F.Pnome, F.UnomeFROM FUNCIONARIO AS FWHERE F.Cpf IN ( SELECT D.FcpfFROMDEPENDENTE AS DWHERE F.Pnome=D.Nome_dependente ANDF.Sexo=D.Sexo );78 Sistemas de banco de dados05 elmas0810_cap05 BR.indd 78 11/30/10 5:22 PMNa consulta aninhada de C16, temos de qua-lificar F.Sexo porque se refere ao atributo Sexo de FUNCIONARIO da consulta externa, e DEPENDENTE também tem um atributo chamado Sexo. Se hou-vesse quaisquer referências não qualificadas a Sexo na consulta aninhada, elas se refeririam ao atributo Sexo de DEPENDENTF. No entanto, não teríamos de qualificar os atributos Pnome e Cpf de FUNCIONA-RIO se eles aparecessem na consulta aninhada, pois a relação DEPENDENTE não tem atributos chamados Pnome e Cpf, de modo que não existe ambiguidade.É 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.5.1.3 Consultas aninhadas correlacionadasSempre que uma condição na cláusula WHERE de uma consulta aninhada referencia algum atribu-to de uma relação declarada na consulta externa, as duas consultas são consideradas correlacionadas. Po-demos entender melhor uma consulta correlaciona-da 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 FUNCIO-NARIO, avalie a consulta aninhada, que recupera os valores de Fcpf para todas as tuplas de DEPENDENTE com o mesmo sexo e nome da tupla em FUNCIONA-RIO; se o valor de Cpf da tupla FUNCIONARIO estiver no resultado da consulta aninhada, então selecione essa tupla FUNCIONARIO.Em geral, uma consulta escrita com blocos ani-nhados 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 escrito como em C16A:C16A:SELECT F.Pnome, F.UnomeFROM FUNCIONARIO AS F, DEPENDENTE AS DWHERE F.Cpf=D.Fcpf AND F.Sexo=D.SexoAND F.Pnome=D.Nome_dependente;5.1.4 As funções EXISTS e UNIQUE em SQLA 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 resulta- do 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, formula-mos a Consulta 16 de uma forma alternativa, que usa EXISTS, como em C16B:C16B: SELECT F.Pnome, F.UnomeFROM FUNCIONARIO AS FWHERE EXISTS ( SELECT *FROM DEPENDENTE AS DWHERE F.Cpf=D.Fcpf AND F.Sexo= D.Sexo AND F.Pnome= D.Nome_ dependente);EXISTS e NOT EXISTS costumam ser usados em conjunto com uma consulta aninhada correlaciona-da. Em C16B, a consulta aninhada referencia os atri-butos Cpf, Pnome e Sexo da relação FUNCIONARIO da consulta externa. Podemos pensar em C16B da seguinte forma: para cada tupla FUNCIONARIO, ava-lie a consulta aninhada, que recupera todas as tuplas DEPENDENTE com os mesmos Fcpf, Sexo e Nome_de-pendente que a tupla FUNCIONARIO; se houver pelo menos uma tupla EXISTS no resultado da consulta aninhada, então selecionar a tupla FUNCIONARIO. Em geral, 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 FAL-SE caso contrário. Em seguida, ilustramos o uso de NOT EXISTS.Consulta 6. Recuperar os nomes de funcionários que não possuem dependentes.C6: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE NOT EXISTS ( SELECT*FROM DEPENDENTEWHERECpf=Fcpf );Em C6, a consulta aninhada correlacionada re-cupera todas as tuplas de DEPENDENTE relaciona-das a uma tupla FUNCIONARIO em particular. Se não existir nenhuma, a tupla FUNCIONARIO é seleciona-da, porque a condição da cláusula WHERE será ava-liada como TRUE nesse caso. Podemos explicar C6 da seguinte forma: para cada tupla FUNCIONARIO, a Capítulo 5 Mais SQL: Consultas complexas, triggers, views e modificação de esquema 7905 elmas0810_cap05 BR.indd 79 11/30/10 5:22 PMconsulta aninhada correlacionada seleciona todas as tuplas DEPENDENTE cujo valor de Fcpf combina com o Cpf de FUNCIONARIO; se o resultado for vazio, ne-nhum dependente estará relacionado ao funcionário, de modo que selecionamos essa tupla FUNCIONARIO e recuperamos seu Pnome e Unome.Consulta 7. Listar os nomes dos gerentes que pos-suem pelo menos um dependente.C7: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE EXISTS ( SELECT *FROM DEPENDENTEWHERE Cpf=Fcpf )ANDEXISTS ( SELECT *FROM DEPARTAMENTOWHERE Cpf=Cpf_gerente );Uma maneira de escrever essa consulta é mostrada em C7, onde especificamos duas consultas aninhadas correlacionadas; a primeira seleciona todas as tuplas de DEPENDENTE relacionadas a um FUNCIONARIO, e a segunda seleciona todas as tuplas de DEPARTAMENTO gerenciadas pelo FUNCIONARIO. Se pelo menos uma da primeira e pelo menos uma da segunda existir, selecio-namos a tupla FUNCIONARIO. Você consegue reescre-ver essa consulta usando apenas uma única consulta aninhada ou nenhuma consulta aninhada?A consulta C3, recuperar o nome de cada funcio-ná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 e72029.1 Introdução, definições e terminologia .. 72029.2 Características dos data warehouses .... 72129.3 Modelagem de dados para data warehouses .......................................... 72229.4 Criando um data warehouse ................ 72629.5 Funcionalidade típica de um data warehouse ........................................... 72829.6 Data warehouses versus visões ............ 72929.7 Dificuldades de implementação de data warehouses .......................................... 729Resumo .......................................................... 730Perguntas de revisão ....................................... 731Bibliografia selecionada .................................. 731Apêndice A Notações diagramáticas alternativas para modelos ER ..732Apêndice B Parâmetros de discos .............735Apêndice C Visão geral da linguagem QBE ...737C.1 Recuperações básicas em QBE .............. 737C.2 Agrupamento, agregação e modificação de banco de dados em QBE ....................... 740Bibliografia .................................................744Índice remissivo ......................................... 766xii Sistemas de banco de dados00 elmas0810_iniciais BR.indd 12 11/30/10 5:27 PMEste livro é uma introdução aos conceitos funda-mentais necessários para projetar, usar e imple-mentar sistemas de banco de dados e aplicações de banco de dados. Nossa apresentação enfatiza os fundamentos da modelagem e do projeto de banco de dados, as linguagens e os modelos fornecidos pe-los sistemas de gerenciamento de banco de dados e as técnicas de implementação do sistema de banco de dados. O propósito do livro é que ele seja usado como um livro-texto para a disciplina de sistemas de banco de dados e como livro de referência. Nosso objetivo é oferecer uma apresentação profunda e atualizada dos aspectos mais importantes dos siste-mas e aplicações de banco de dados, bem como das tecnologias relacionadas. Consideramos que os leito-res estejam acostumados aos conceitos elementares da programação e estruturação de dados, e que eles tenham tido algum contato com os fundamentos de organização do computador.NovidadesOs recursos-chave a seguir foram acrescentados nessa edição: � Uma reorganização da ordem dos capítulos, permitindo que os professores comecem com projetos e exercícios de laboratório bem mais cedo no curso. � O material sobre SQL, padrão de banco de dados relacional, foi antecipado no livro para os capítulos 4 e 5, para permitir que os pro-fessores focalizem esse importante assunto no início do curso. � O material sobre bancos de dados objeto--relacional e orientado a objeto foi atuali-zado para que se adapte aos padrões SQL e ODMG mais recentes, e consolidado em um único capítulo (Capítulo 11). � A apresentação da XML foi expandida e atualizada, sendo antecipada no livro para o Capítulo 12. � Os capítulos sobre teoria de normalização fo-ram reorganizados de modo que o primeiro capítulo (Capítulo 15) focaliza os conceitos de normalização intuitivos, enquanto o se-gundo capítulo (Capítulo 16) aborda as teo-rias formais e os algoritmos de normalização. � A apresentação das ameaças à segurança do banco de dados foi atualizada com uma dis-cussão sobre ataques de Injeção de SQL e técnicas de prevenção no Capítulo 24, e uma visão geral da segurança baseada em rótulo, com exemplos. � Nossa apresentação sobre bancos de dados espaciais e bancos de dados de multimídia foi expandida e atualizada no Capítulo 26. � Um novo Capítulo 27, sobre técnicas de recuperação de informações, foi acrescen-tado, discutindo sobre modelos e técnicas de recuperação, consulta, navegação e in-dexação de informações a partir de docu-mentos da Web; apresentamos as etapas de processamento típicas em um sistema de recuperação de informações, as medidas de avaliação e como as técnicas de recupera-ção de informação estão relacionadas aos bancos de dados e à pesquisa na Web.Organização desta ediçãoExistem mudanças organizacionais significativas nesta edição, bem como melhoria nos capítulos indi-Prefácio00 elmas0810_iniciais BR.indd 13 11/30/10 5:27 PMviduais. O livro agora é dividido em onze partes, da seguinte forma: � Parte 1 (capítulos 1 e 2) inclui os capítulos introdutórios. � A apresentação sobre bancos de dados re-lacionais e SQL foi movida para a Parte 2 (capítulos de 3 a 6) do livro; o Capítulo 3 apresenta o modelo relacional formal e as restrições do banco de dados relacional; o material sobre SQL (capítulos 4 e 5) agora é apresentado antes da nossa apresentação so-bre álgebra e cálculo relacional no Capítulo 6, para permitir que os professores iniciem projetos em SQL mais cedo em um curso, se desejarem (essa reordenação também é basea-da em um estudo que sugere que os alunos dominam SQL melhor quando ela é ensinada antes das linguagens relacionais formais). � A apresentação sobre modelagem de entidade--relacionamento e projeto de banco de dados agora está na Parte 3 (capítulos 7 a 10), mas ain-da pode ser abordada antes da Parte 2, se o foco do curso for o projeto de banco de dados. � A Parte 4 aborda o material atualizado sobre bancos de dados objeto-relacional e orientado a objeto (Capítulo 11) e XML (Capítulo 12). � A Parte 5 inclui os capítulos sobre técnicas de programação de banco de dados (Capítu-lo 13) e programação de banco de dados na Web usando PHP (Capítulo 14, que foi ante-cipado no livro). � A Parte 6 (capítulos 15 e 16) inclui os capí-tulos sobre normalização e teoria de projeto (passamos todos os aspectos formais dos algo-ritmos de normalização para o Capítulo 16). � A Parte 7 (capítulos 17 e 18) contém os capí-tulos sobre organizações de arquivo, indexa-ção e hashing. � A Parte 8 inclui os capítulos sobre técnicas de processamento e otimização de consulta (Ca-pítulo 19) e ajuste de banco de dados (Capí-tulo 20). � A Parte 9 inclui o Capítulo 21 sobre concei-tos de processamento de transação; o Capí-tulo 22 sobre controle de concorrência; e o Capítulo 23 sobre recuperação do banco de dados contra falhas. � A Parte 10, sobre tópicos adicionais de banco de dados, inclui o Capítulo 24 sobre seguran-ça de banco de dados e o Capítulo 25 sobre bancos de dados distribuídos. � A Parte 11 sobre modelos e aplicações avan-çadas de banco de dados inclui o Capítulo 26 sobre modelos de dados avançados (bancos de dados ativos, temporais, espaciais, multi-mídia e dedutivos); o novo Capítulo 27 sobre recuperação de informações e busca na Web; e os capítulos sobre mineração de dados (Ca-pítulo 28) e data warehousing (Capítulo 29).Conteúdo desta ediçãoA Parte 1 descreve os conceitos introdutórios básicos necessários para um bom conhecimento dos modelos de banco de dados, sistemas e linguagens. Os capítulos 1 e 2 introduzem bancos de dados, usuá-rios típicos e conceitos, terminologia e arquitetura de SGBD.A Parte 2 descreve o modelo de dados relacional, o padrão SQL e as linguagens relacionais formais. O Capítulo 3 descreve o modelo relacional básico, suas restrições de integridade e operações de atuali-zação. O Capítulo 4 descreve algumas partes básicas do padrão SQL para bancos de dados relacionais, incluindo definição de dados, operações de modifi-cação de dados e consultas SQL simples. O Capítu-lo 5 apresenta consultas SQL mais complexas, bem como os conceitos SQL de triggers, asserções, visões e modificação de esquema. O Capítulo 6 descreve as operações da álgebra relacional e introduz o cálculo relacional.A Parte 3 aborda vários tópicos relacionados à modelagem conceitual do banco de dados e o projeto de banco de dados. No Capítulo 7, os conceitos do modelo Entidade-Relacionamento (ER) e diagramas ER são apresentados e usados para ilustrar o projeto conceitual do banco de dados. O Capítulo 8 focali-za os conceitos de abstração de dados e modelagem semântica dos dados, mostrando como o modelo ERC3B. Este é um exemplo de certos ti-pos de consultas que exigem quantificação universal, conforme discutiremos na Seção 6.6.7. Um modo de escrever essa consulta é usar a construção (S2 EXCEPT S1), conforme explicaremos a seguir, e verificar se o resultado é vazio.1 Essa opção aparece como C3A.C3A: SELECT Pnome, UnomeFROM FUNCIONARIOWHERE NOT EXISTS ( (SELECT ProjnumeroFROM PROJETOWHERE Dnum=5)EXCEPT ( SELECT PnrFROM TRABALHA_EMWHERE Cpf=Fcpf) );Em C3A, a primeira subconsulta (que não está correlacionada à consulta externa) seleciona todos os projetos controlados pelo departamento 5, e a segunda subconsulta (que está correlacionada) seleciona todos os projetos em que o funcionário em particular traba-lha. Se a diferença de conjunto do resultado da primeira subconsulta menos (SUBTRAÇÃO) (EXCEPT) o resultado da segunda subconsulta for vazio, isso significa que o funcioná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 do que C3A, que usa NOT EXISTS e EXCEPT.C3B: SELECT Unome, Pnome FROM FUNCIONARIO WHERE NOT EXISTS ( SELECT * FROM TRABALHA_EM T1 WHERE ( T1.Pnr IN ( SELECT Projnumero FROM PROJETO WHERE Dnum=5 ) AND NOT EXISTS ( SELECT * FROM TRABALHA_EM T2 WHERE T2.Fcpf=Cpf AND T2.Pnr=B.Pnr )));Em C3B, a consulta aninhada externa seleciona quaisquer tuplas de TRABALHA_EM (T1) cujo Pnr é de um projeto controlado pelo departamento 5, se não houver uma tupla em TRABALHA_EM (T2) com o mesmo Pnr e o mesmo Cpf daquele da tupla FUN-CIONARIO em consideração na consulta externa. Se não existir tal tupla, selecionamos a tupla FUNCIO-NARIO. A forma de C3B combina com a reformulação da Consulta 3 a seguir: selecionar cada funcionário de modo que não exista um projeto controlado pelo de-partamento 5 em que o funcionário não trabalha. Isso corresponde ao modo como escreveremos essa con-sulta no cálculo relacional de tupla (ver Seção 6.6.7).Existe outra função em SQL, UNIQUE(C), que re-torna TRUE se não houver tuplas duplicadas no resul-tado da consulta C; caso contrário, ela retorna FALSF. Isso pode ser usado para testar se o resultado de uma consulta aninhada é um conjunto ou um multiconjunto.5.1.5 Conjuntos explícitos e renomeação de atributos em SQLVimos várias consultas com uma consulta ani-nhada na cláusula WHERF. Também é possível usar um conjunto explícito de valores na cláusula WHE-RE, em vez de uma consulta aninhada. Esse conjunto é delimitado por parênteses em SQL.1 Lembre-se de que EXCEPT é um operador de diferença de conjunto. A palavra-chave MINUS às vezes é usada, por exemplo, no Oracle.80 Sistemas de banco de dados05 elmas0810_cap05 BR.indd 80 11/30/10 5:22 PMConsulta 17. Recuperar os números do CPF de todos os funcionários que trabalham nos proje-tos de números 1, 2 ou 3.C17: SELECT DISTINCT FcpfFROM TRABALHA_EMWHERE Pnr IN (1, 2, 3);Em SQL, é possível renomear qualquer atributo que apareça no resultado de uma consulta acrescen-tando o qualificador AS seguido pelo novo nome dese-jado. Logo, a construção AS pode ser usada para ape-lidar os nomes tanto do atributo quanto da relação, e ele pode ser usado nas cláusulas SELECT e FROM. Por exemplo, a C8A mostra como a consulta C8 da Seção 4.3.2 pode ser ligeiramente alterada para recuperar o último nome de cada funcionário e seu super-visor, enquanto renomeia os atributos resultantes como Nome_funcionario e Nome_supervisor. Os no-vos nomes aparecerão como cabeçalhos de coluna no resultado da consulta.C8A: SELECT F.Unome AS Nome_funcionario, S.Unome AS Nome_supervisorFROM FUNCIONARIO AS F, FUNCIONARIO AS SWHERE F.Cpf_supervisor=S.Cpf;5.1.6 Tabelas de junção em SQL e junções externas (outer joins)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 consul-ta. Essa construção pode ser mais fácil de compreen-der do que misturar todas as condições de seleção e junção na cláusula WHERF. Por exemplo, considere a consulta C1, que recupera o nome e o endereço de todos os funcionários que trabalham para o departa-mento ‘Pesquisa’. Pode ser mais fácil especificar a jun-ção das relações FUNCIONARIO e DEPARTAMENTO primeiro, e depois selecionar as tuplas e atributos de-sejados. Isso pode ser escrito em SQL como em C1A:C1A: SELECT Pnome, Unome, EnderecoFROM (FUNCIONARIO JOIN DEPARTAMENTO ON Dnr=Dnumero)WHERE Dnome=‘Pesquisa’;A cláusula FROM em C1A contém uma única ta-bela de junção. Os atributos dessa tabela são todos os atributos da primeira tabela, FUNCIONARIO, se-guidos por todos os atributos da segunda tabela, DE-PARTAMENTO. O conceito de uma tabela de junção também permite que o usuário especifique diferentes tipos de junção, como NATURAL JOIN ( junção natu-ral), e vários tipos de OUTER JOIN ( junção externa). Em uma NATURAL JOIN sobre duas reações R e S, nenhuma condição de junção é especificada; cria-se uma condição EQUIJOIN implícita para cada par de atributos com o mesmo nome de R e S. Cada par de atributos desse tipo é incluído apenas uma vez na relação resultante (ver seções 6.3.2 e 6.4.4 para mais detalhes sobre os vários tipos de operações de junção na álgebra relacional).Se os nomes dos atributos de junção não forem os mesmos nas relações da base, é possível renomear os atributos de modo que eles combinem, e depois aplicar a NATURAL JOIN. Nesse caso, a construção AS pode ser usada para renomear uma relação e todos os seus atributos na cláusula FROM. Isso é ilustrado em C1B, onde a relação DEPARTAMENTO é renomea-da como DEP e seus atributos são renomeados como Dnome, Dnr (para combinar com o nome do atribu-to de junção desejado Dnr na tabela FUNCIONARIO), Cpf_gerente e Data_incio_gerente. O significado da condição de junção para esse NATURAL JOIN é FUN-CIONARIO.Dnr=DEPT.Dnr, porque esse é o único par de atributos com o mesmo nome após a renomeação:C1B: SELECT Pnome, Unome, EnderecoFROM (FUNCIONARIO NATURAL JOIN (DEPARTAMENTO AS DEP (Dnome, Dnr, Cpf_gerente, Data_inicio_gerente)))WHERE Dnome=‘Pesquisa’;O tipo padrão de junção em uma tabela de jun-ção é chamado de inner join, onde uma tupla é in-cluída no resultado somente se uma tupla combinar na outra relação. Por exemplo, na consulta C8A, so-mente os funcionários que possuem um supervisor são incluídos no resultado; uma tupla FUNCIONARIO cujo valor para Cpf_supervisor é NULL é excluída. Se o usuário exigir que todos os funcionários sejam in-cluídos, uma OUTER JOIN precisa ser usada explici-tamente (veja a definição de OUTER JOIN na Seção 6.4.4). Em SQL, isso é tratado especificando explici-tamente a palavra-chave OUTER JOIN em uma tabela de junção, conforme ilustrado em C8B:C8B: SELECT F.Unome AS Nome_funcionario,S.Unome AS Nome_supervisorFROM (FUNCIONARIO AS F LEFT OUTER JOIN FUNCIONARIO AS S ON F.Cpf_supervisor =S.Cpf);Capítulo 5 Mais SQL: Consultas complexas, triggers, views e modificação de esquema 8105 elmas0810_cap05 BR.indd 81 11/30/10 5:22 PMExistem diversas operações de junção externa, que discutiremos com mais detalhes na Seção 6.4.4. Em SQL, as opções disponíveis para especificar tabe-las de junção incluem INNER JOIN (apenas pares de tuplas que combinam com a condição de junção são recuperadas, o mesmo que JOIN), LEFT OUTER JOIN (toda tupla na tabela da esquerda precisa aparecer no resultado; se ela não tiver uma tupla combinando, ela é preenchida com valores NULL para os atributos da tabela da direita), RIGHT OUTER JOIN (toda tupla na tabela da direita precisa aparecer no resultado;pode ser estendido para incorporar essas ideias, le-vando ao modelo de dados ER-Estendido (EER) e diagramas EER. Os conceitos apresentados no Capí-tulo 8 incluem subclasses, especialização, generaliza-ção e tipos (categorias) de união. A notação para os diagramas de classe da UML também é apresentada nos capítulos 7 e 8. O Capítulo 9 discute o projeto de banco de dados relacional usando o mapeamen-to ER e EER para relacional. Terminamos a Parte 3 com o Capítulo 10, que apresenta uma visão geral das diferentes fases do processo de projeto de banco de dados nas empresas para aplicações de banco de dados de tamanho médio e grande.A Parte 4 aborda os modelos de dados orienta-dos a objeto, objeto-relacional e XML, e suas lingua-gens e padrões afiliados. O Capítulo 11 introduz os xiv Sistemas de banco de dados00 elmas0810_iniciais BR.indd 14 11/30/10 5:27 PMconceitos para bancos de dados de objeto e mostra como eles foram incorporados ao padrão SQL a fim de acrescentar capacidades de objeto aos sistemas de bancos de dados relacionais. Depois, aborda o pa-drão do modelo de objeto ODMG e sua definição de objeto e linguagens de consulta. O Capítulo 12 abor-da o modelo e linguagens XML (eXtensible Markup Language), discutindo como a XML está relacionada aos sistemas de banco de dados. Apresenta os con-ceitos e linguagens do modelo XML, comparando-o com modelos de banco de dados tradicionais. Tam-bém mostra como os dados podem ser convertidos entre a XML e representações relacionais.A Parte 5 é sobre técnicas de programação de ban-co de dados. O Capítulo 13 aborda os tópicos de programação SQL, como SQL embutida, SQL dinâ-mica, ODBC, SQLJ, JDBC e SQL/CLIENTE. O Ca-pítulo 14 introduz a programação de banco de dados na Web, usando a linguagem de scripting PHP em nossos exemplos.A Parte 6 aborda a teoria da normalização. Os capítulos 15 e 16 abordam os formalismos, as te-orias e os algoritmos desenvolvidos para o projeto de banco de dados relacional por normalização. Esse material inclui dependências funcionais e ou-tros tipos de dependências e formas normais das relações. A normalização intuitiva passo a passo é apresentada no Capítulo 15, que também defi-ne dependências multivaloradas e de junção. Os algoritmos de projeto relacional baseados na nor-malização, junto com o material teórico em que os algoritmos são baseados, são apresentados no Capítulo 16.A Parte 7 descreve as estruturas de arquivo fí-sicas e os métodos de acesso usados nos sistemas de banco de dados. O Capítulo 17 descreve os princi-pais métodos de organização de arquivos de registros em disco, incluindo o hashing estático e dinâmico. O Capítulo 18 descreve as técnicas de indexação para arquivos, incluindo estruturas de dados em árvore B e B+ e arquivos de grade.A Parte 8 focaliza o processamento de consulta e o ajuste de desempenho de banco de dados. O Capí-tulo 19 apresenta os fundamentos do processamento e otimização de consulta, e o Capítulo 20 discute so-bre o projeto físico e ajuste de banco de dados.A Parte 9 discute o processamento de tran-sações, controle de concorrência e técnicas de recuperação, incluindo discussões de como esses conceitos são realizados em SQL. O Capítulo 21 introduz as técnicas necessárias para os sistemas de processamento de transação e define os con-ceitos de facilidade de recuperação e serialização dos schedules. O Capítulo 22 oferece uma visão geral dos vários tipos de protocolos de controle de concorrência, com foco no bloqueio em duas fa-ses. Também trata das técnicas de ordenação de timestamp (rótulos de tempo) e controle de con-corrência otimista, além do bloqueio de granulari-dade múltiplo. Finalmente, o Capítulo 23 focaliza os protocolos de recuperação de banco de dados e oferece uma visão geral dos conceitos e técnicas que são usadas nessa recuperação.As partes 10 e 11 abordam diversos tópicos avançados. O Capítulo 24 oferece uma visão geral da segurança do banco de dados, incluindo o modelo do controle de acesso discricionário com comandos SQL para o GRANT e o REVOKE de privilégios, o mode-lo de controle de acesso obrigatório com categorias de usuários e poli-instanciação, uma discussão sobre privacidade de dados e seu relacionamento com se-gurança, e uma visão geral dos ataques de Injeção de SQL. O Capítulo 25 oferece uma introdução aos bancos de dados distribuídos e discute a arquitetura cliente/servidor em três camadas. O Capítulo 26 in-troduz vários modelos de banco de dados avançados para aplicações avançadas. Estes incluem bancos de dados ativos e triggers, além de bancos de dados tem-porais, espaciais, multimídia e dedutivos. O Capítulo 27 é um capítulo novo, sobre técnicas de recupera-ção de informações e como elas estão relacionadas a sistemas de banco de dados e a métodos de pesquisa na Web. O Capítulo 28, sobre mineração de dados (data mining), oferece uma visão geral do processo de mineração de dados e descoberta de conhecimen-to, discute algoritmos para mineração, classificação e agrupamento de regra de associação, e aborda rapi-damente outras técnicas e ferramentas comerciais. O Capítulo 29 introduz os conceitos de data warehou-sing e OLAP.O Apêndice A oferece uma série de notações dia-gramáticas alternativas para exibir um esquema ER ou EER conceitual. Estas podem ser usadas em substi-tuição à notação que usamos, se o professor preferir. O Apêndice B oferece alguns parâmetros físicos impor-tantes de discos. O Apêndice C oferece uma visão ge-ral da linguagem de consulta gráfica QBE. Os apên-dices D e E (disponíveis no site de apoio do livro, http://www.aw.com/elmasri_br) abordam sistemas de banco de dados legados, com base nos modelos de banco de dados hierárquico e de rede. Eles têm sido usados há mais de trinta anos como base para muitas aplicações de banco de dados e sistemas de processamento de transações comerciais. Considera-mos importante expor os alunos de gerenciamento de banco de dados a essas técnicas legadas de modo que possam ter uma ideia melhor de como a tecnologia de banco de dados progrediu.Prefácio xv00 elmas0810_iniciais BR.indd 15 11/30/10 5:27 PMO Apêndice A oferece uma série de notações diagramáticas alternativas para exibir um esquema ER ou EER conceitual. Estas podem ser usadas em substituição à notação que usamos, se o professor preferir. O Apêndice B oferece alguns parâmetros físicos importantes de discos. O Apêndice C oferece uma visão geral da linguagem de consulta gráfica QBE. Os apêndices D e E (disponíveis na Sala Virtual, sv.pearson.com.br) abordam sistemas de banco de dados legados, com base nos modelos de banco de dados hierárquico e de rede. Eles têm sido usados há mais de trinta anos como base para muitas aplicações de banco de dados e sistemas de processamento de transações comerciais. Consideramos importante expor os alunos de gerenciamento de banco de dados a essas técnicas legadas de modo que possam ter uma ideia melhor de como a tecnologia de banco de dados progrediu.OrientaçõesExistem muitas maneiras diferentes de minis-trar um curso de banco de dados. Os capítulos das partes 1 a 7 podem ser usados em um curso intro-dutório sobre sistemas de banco de dados, na or-dem em que aparecem ou na ordem preferida dos professores. Capítulos e seções selecionadas podem ser omitidas, e o professor pode acrescentar outros capítulos do restante do livro, dependendo da ênfa-se do curso. Ao final da seção inicial de muitos dos capítulos do livro, listamos seções que são candida-tas a serem omitidas sempre que uma discussão me-nos detalhada do assunto for desejada. Sugerimos incluir até o Capítulo 15 em um curso introdutório de banco de dados e incluir partes selecionadas de outros capítulos, dependendo da base dos alunos e da cobertura desejada. Para uma ênfase em técni-cas de implementação de sistemas, os capítulos das partes 7, 8 e 9 devem substituir alguns dos capítulosanteriores.Os capítulos 7 e 8, que abordam a modelagem con-ceitual usando os modelos ER e EER, são importantes para um bom conhecimento conceitual dos bancos de dados. Porém, eles podem ser abordados parcialmente ou mais adiante em um curso ou até mesmo omitidos, se a ênfase for sobre a implementação do SGBD. Os capítulos 17 e 18, sobre organizações de arquivos e indexação, também podem ser abordados mais cedo, mais tarde ou ainda omitidos, se a ênfase for sobre modelos de banco de dados e linguagens. Para alu-nos que concluíram um curso sobre organização de arquivos, partes desses capítulos podem ser indicadas como material de leitura ou alguns exercícios podem ser passados como revisão para esses conceitos.Se a ênfase de um curso for em projeto de banco de dados, então o professor deverá abordar os capí-tulos 7 e 8 mais cedo, seguidos pela apresentação dos bancos de dados relacionais. Um curso sobre o ciclo de vida completo do projeto e implementação de ban-cos de dados incluiria o projeto conceitual (capítulos 7 e 8), bancos de dados relacionais (capítulos 3, 4 e 5), mapeamento do modelo de dados (Capítulo 9), nor-malização (Capítulo 15) e implementação de progra-mas de aplicação com SQL (Capítulo 13). O Capítulo 14 também deverá ser abordado se a ênfase for em programação e aplicações de banco de dados na Web. A documentação adicional sobre linguagens de pro-gramação e SGBDRs específicos seria necessária.O livro foi escrito de modo a possibilitar a abor-dagem de tópicos em várias sequências. O gráfico de dependência dos capítulos, a seguir, mostra as prin-cipais dependências entre os capítulos. Conforme o diagrama ilustra, é possível começar com vários tó-picos diferentes após os dois capítulos introdutórios. Embora o gráfico possa parecer complexo, é impor-tante observar que, se os capítulos forem usados na ordem, as dependências não serão perdidas. O gráfi-co pode ser consultado por aqueles que desejam usar uma ordem de apresentação alternativa.Para um curso de um semestre baseado neste livro, capítulos selecionados podem ser atribuídos como material de leitura. O livro também pode ser usado para uma sequência de curso em dois semes-tres. O primeiro curso, Introdução ao Projeto e Sis-temas de Bancos de Dados, pode abranger a maioria dos capítulos 1 a 15. O segundo curso, Modelos e Técnicas de Implementação de Bancos de Dados, pode abranger a maioria dos Capítulos de 16 a 29. A sequência de dois semestres também pode ser elabo-rada de várias outras maneiras, dependendo da pre-ferência de cada professor.Site de apoio do livroNo Companion Website deste livro (www.aw.com/elmasri_br), professores e estudantes podem acessar materiais adi-cionais 24 horas por dia.Para professores: � Apresentações em PowerPoint. � Banco de imagens. � Manual de soluções (em inglês).Esse material é de uso exclusivo para professores e está protegido por senha. Para ter acesso a ele, os professores que adotam o livro devem entrar em con-tato com seu representante Pearson ou enviar e-mail para universitarios@pearson.com.Para estudantes: � Manual de laboratório (em inglês). � Apêndices D e E (em inglês).AgradecimentosÉ um grande prazer reconhecer o auxílio e as contribuições de muitos indivíduos para este esforço. Primeiro, gostaríamos de agradecer ao nosso editor, Matt Goldstein, por sua orientação, encorajamento e apoio. Gostaríamos de agradecer o excelente tra-balho de Gillian Hall, pela gerência de produção, e Rebecca Greenberg, por uma revisão completa do li-vro. Agradecemos às seguintes pessoas da Pearson, que contribuíram para a sexta edição: Jeff Holcomb, Marilyn Lloyd, Margaret Waples e Chelsea Bell.xvi Sistemas de banco de dados00 elmas0810_iniciais BR.indd 16 11/30/10 5:27 PM(www.pearson.com.br/elmasri), professores e (www.pearson.com/elmasri),Na Sala Virtual (sv.pearson.com.br), professores e estudantes podem acessar materiais adicionais 24 horas por dia.Materiais adicionaisSham Navathe gostaria de agradecer a con-tribuição significativa de Saurav Sahay para o Capítulo 27. Vários alunos atuais e do passado também contribuíram para os diversos capítulos nesta edição: Rafi Ahmed, Liora Sahar, Fariborz Farahmand, Nalini Polavarapu e Wanxia Xie (ex--alunos); e Bharath Rengarajan, Narsi Sriniva-san, Parimala R. Pranesh, Neha Deodhar, Balaji Palanisamy e Hariprasad Kumar (alunos atuais). Discussões com seus colegas Ed Omiecinski e Leo Mark, da Georgia Tech, e Venu Dasigi, da SPSU, Atlanta, também contribuíram para a revisão do material.Gostaríamos de repetir nossos agradecimentos àqueles que revisaram e contribuíram de alguma ma-neira para as edições anteriores de Sistemas de banco de dados. � Primeira edição. Alan Apt (editor), Don Ba-tory, Scott Downing, Dennis Heimbinger, Julia Hodges, Yannis Ioannidis, Jim Larson, Per-Ake Larson, Dennis McLeod, Rahul Pa-tel, Nicholas Roussopoulos, David Stemple, Michael Stonebraker, Frank Tompa e Kyu--Young Whang. � Segunda edição. Dan Joraanstad (editor), Rafi Ahmed, Antonio Albano, David Beech, Jose Blakeley, Panos Chrysanthis, Suzanne Dietrich, Vic Ghorpadey, Goetz Graefe, Eric Hanson, Jun-guk L. Kim, Roger King, Vram Kouramajian, Vijay Kumar, John Lowther, Sanjay Manchanda, Toshimi Minoura, Inderpal Mumick, Ed Omie-cinski, Girish Pathak, Raghu Ramakrishnan, Ed Robertson, Eugene Sheng, David Stotts, Marian-ne Winslett e Stan Zdonick.1, 2Introdução7, 8Modelos ER, EER3Modelo relacional6Álgebra relacional13, 14Programação de BD e Web9ER e ERR para relacional17, 18Organização de arquivo, indexação28, 29Mineração de dados, Warehousing24, 25Segurança, DDB10Projeto de BD, UML21, 22, 23Transações, CC, recuperação11, 12ODB, ORDB, XML4, 5SQL26, 27Modelos avançados, RI15, 16FD, MVD, normalização19, 20Processamento de consulta, otimização, ajuste de BDPrefácio xvii00 elmas0810_iniciais BR.indd 17 11/30/10 5:27 PM � Terceira edição. Maite Suarez-Rivas e Ka-therine Harutunian (editores); Suzanne Die-trich, Ed Omiecinski, Rafi Ahmed, Francois Bancilhon, Jose Blakeley, Rick Cattell, Ann Chervenak, David W. Embley, Henry A. Etlinger, Leonidas Fegaras, Dan Forsyth, Farshad Fotouhi, Michael Franklin, Sreejith Gopinath, Goetz Craefe, Richard Hull, Sushil Jajodia, Ramesh K. Karne, Harish Kotbagi, Vijay Kumar, Tarcisio Lima, Ramon A. Ma-ta-Toledo, Jack McCaw, Dennis McLeod, Rokia Missaoui, Magdi Morsi, M. Naraya-naswamy, Carlos Ordonez, Joan Peckham, Betty Salzberg, Ming-Chien Shan, Junping Sun, Rajshekhar Sunderraman, Aravindan Veerasamy e Emilia E. Villareal. � Quarta edição. Maite Suarez-Rivas, Ka-therine Harutunian, Daniel Rausch e Juliet Silveri (editores); Phil Bernhard, Zhengxin Chen, Jan Chomicki, Hakan Ferhatosma-noglu, Len Fisk, William Hankley, Ali R. Hurson, Vijay Kumar, Peretz Shoval, Jason T. L. Wang (revisores); Ed Omiecinski (que contribuiu para o Capítulo 27). Os colabo-radores da Universidade do Texas em Ar-lington são Jack Fu, Hyoil Han, Babak Ho-jabri, Charley Li, Ande Swathi e Steven Wu; os colaboradores da Georgia Tech são Wei-min Feng, Dan Forsythe, Angshuman Guin, Abrar Ul-Haque, Bin Liu, Ying Liu, Wanxia Xie e Waigen Yee. � Quinta edição. Matt Goldstein e Katheri-ne Harutunian (editores); Michelle Brown, Gillian Hall, Patty Mahtani, Maite Suarez--Rivas, Bethany Tidd e Joyce Cosentino Wells (da Addison-Wesley); Hani Abu-Salem, Jamal R. Alsabbagh, Ramzi Bualuan, Soon Chung, Sumali Conlon, Hasan Davulcu, James Gel-ler, Le Gruenwald, Latifur Khan, Herman Lam, Byung S. Lee, Donald Sanderson, Jamil Saquer, Costas Tsatsoulis e Jack C. Wileden (revisores); Raj Sunderraman (que contribuiu com os projetos de laboratório); Salman Azar (que contribuíram com alguns exercícios no-vos); Gaurav Bhatia, Fariborz Farahmand, Ying Liu, Ed Omiecinski, Nalini Polavarapu, Liora Sahar, Saurav Sahay e Wanxia Xie (daGeorgia Tech).Por último, mas não menos importante, gosta-ríamos de agradecer nossas famílias pelo apoio, pelo encorajamento e pela paciência.R.E.S.B.N.xviii Sistemas de banco de dados00 elmas0810_iniciais BR.indd 18 11/30/10 5:27 PM 1Introdução aos bancos de dadosparte01 elmas0810_cap01 BR.indd 1 11/30/10 5:24 PMBancos de dados e sistemas de banco de dados são um componente essencial da vida na sociedade moderna; a maioria de nós encontra diariamente di-versas atividades que envolvem alguma interação com um banco de dados. Por exemplo, quando vamos ao banco para depositar ou retirar fundos, fazemos uma reserva de hotel ou de voo, acessamos o catálogo de uma biblioteca virtual para procurar uma referência bibliográfica, ou compramos algo on-line — como um livro, um brinquedo ou um computador —, pro-vavelmente essas atividades envolverão alguém ou algum programa de computador que acessa um ban-co de dados. Até mesmo a compra de produtos em um supermercado atualiza automaticamente o ban-co de dados que mantém o controle de estoque dos itens.Essas interações são exemplos do que podemos chamar de aplicações de banco de dados tradicio-nais, em que a maior parte da informação armaze-nada e acessada é textual ou numérica. Nos últimos anos, os avanços na tecnologia levaram a interes-santes novas aplicações dos sistemas de banco de dados. A nova tecnologia de mídia tornou possível armazenar imagens, clipes de áudio e streams de vídeo digitalmente. Esses tipos de arquivo estão se tornando um componente importante dos bancos de dados de multimídia. Os sistemas de informa-ções geográficas (GIS — Geographic Information Systems) podem armazenar e analisar mapas, da-dos sobre o clima e imagens de satélite. Sistemas de data warehousing e de processamento analítico on--line (OLAP — On-Line Analytical Processing) são usados em muitas empresas para extrair e analisar informações comerciais úteis de bancos de dados muito grandes, para ajudar na tomada de decisão. A tecnologia de tempo real e banco de dados ativo é usada para controlar processos industriais e de ma-nufatura. Além disso, técnicas de pesquisa de banco de dados estão sendo aplicadas à World Wide Web para melhorar a busca por informações necessárias feita pelos usuários que utilizam a Internet.No entanto, para entender os fundamentos da tecnologia de banco de dados, devemos começar das aplicações básicas de banco de dados tradicional. Na Seção 1.1, começamos definindo um banco de dados, e depois explicamos outros termos básicos. Na Seção 1.2, oferecemos um simples exemplo de banco de dados UNIVERSIDADE para ilustrar nossa discussão. A Seção 1.3 descreve algumas das princi-pais características dos sistemas de banco de dados, e as seções 1.4 e 1.5 classificam os tipos de pessoas cujas funções envolvem o uso e a interação com sis-temas de banco de dados. As seções 1.6, 1.7 e 1.8 oferecem uma discussão mais profunda sobre as di-versas capacidades oferecidas pelos sistemas de ban-co de dados e discutem algumas aplicações típicas. No final do capítulo é apresentado um resumo.O leitor que quiser uma introdução rápida aos sistemas de banco de dados pode estudar as seções 1.1 a 1.5, depois pular ou folhear as seções 1.6 a 1.8 e seguir para o Capítulo 2.1.1 IntroduçãoOs bancos de dados e sua tecnologia têm um im-pacto importante sobre o uso crescente dos compu-tadores. É correto afirmar que os bancos de dados desempenham um papel crítico em quase todas as áreas em que os computadores são usados, incluindo negócios, comércio eletrônico, engenharia, medicina, genética, direito, educação e biblioteconomia. O ter-mo banco de dados (do original database) é tão uti-lizado que precisamos começar por sua definição. E nossa definição inicial é bastante genérica.capítulo 1Bancos de dados e usuários de banco de dados01 elmas0810_cap01 BR.indd 2 11/30/10 5:24 PMUm banco de dados é uma coleção de dados1 relacionados. Com dados, queremos dizer fatos conhecidos que podem ser registrados e possuem sig-nificado implícito. Por exemplo, considere os nomes, números de telefone e endereços das pessoas que você conhece. Você pode ter registrado esses dados em uma agenda ou, talvez, os tenha armazenado em um disco rígido, usando um computador pessoal e um software como Microsoft Access ou Excel. Essa coleção de dados relacionados, com um significado implícito, é um banco de dados.Essa definição de banco de dados é bastante genérica; por exemplo, a coleção de palavras que compõem esta página de texto pode ser considerada dados relacionados e, portanto, constitui um banco de dados. Porém, o uso comum do termo banco de dados normalmente é mais restrito e tem as seguintes propriedades implícitas: � Um banco de dados representa algum aspecto do mundo real, às vezes chamado de mini-mundo ou de universo de discurso (UoD — Universe of Discourse). As mudanças no mi-nimundo são refletidas no banco de dados. � Um banco de dados é uma coleção logica-mente coerente de dados com algum signi-ficado inerente. Uma variedade aleatória de dados não pode ser corretamente chamada de banco de dados. � Um banco de dados é projetado, construído e populado com dados para uma finalidade espe-cífica. Ele possui um grupo definido de usuários e algumas aplicações previamente concebidas nas quais esses usuários estão interessados.Em outras palavras, um banco de dados tem al-guma fonte da qual o dado é derivado, algum grau de interação com eventos no mundo real e um público que está ativamente interessado em seu conteúdo. Os usuários finais de um banco de dados podem realizar transações comerciais (por exemplo, um cliente com-pra uma câmera) ou eventos podem acontecer (por exemplo, uma funcionária tem um filho), fazendo que a informação no banco de dados mude. Para que um banco de dados seja preciso e confiável o tempo todo, ele precisa ser um reflexo verdadeiro do minimundo que representa; portanto, as mudanças precisam ser refletidas no banco de dados o mais breve possível.Um banco de dados pode ter qualquer tamanho e complexidade. Por exemplo, a lista de nomes e en-dereços referenciados anteriormente pode consistir em apenas algumas centenas de registros, cada um com 1O livro original utiliza a palavra data em singular e plural, pois isso é comum na literatura de banco de dados; o contexto determinará se ela está no singular ou no plural. (Em inglês padrão, data é usado para o plural e datum, para o singular.)uma estrutura simples. Por sua vez, o catálogo com-putadorizado de uma grande biblioteca pode conter meio milhão de entradas organizadas sob diferentes categorias — por sobrenome do autor principal, por assunto, por título do livro —, com cada uma das categorias organizada alfabeticamente. Um banco de dados de tamanho e complexidade ainda maior é mantido pela Receita Federal para monitorar formu-lários de imposto de renda preenchidos pelos contri-buintes. Se considerarmos que existem 100 milhões de contribuintes e que cada um deles preenche uma mé-dia de cinco formulários com aproximadamente 400 caracteres cada um, teríamos um banco de dados de 100 × 106 × 400 × 5 caracteres (bytes) de informa-ção. Se a Receita Federal mantém o registro dos três últimos anos de cada contribuinte, além do ano atual, teríamos um banco de dados de 8 × 1011 bytes (800 gigabytes). Essa imensa quantidade de informações precisa ser organizada e gerenciada de modo que os usuários possam consultar, recuperar e atualizar os dados quando necessário.Um exemplo de um grande banco de dados co-mercial é a Amazon.com. Ela contém dados de mais de 20 milhões de livros, CDs, vídeos, DVDs, jogos, eletrônicos, roupas e outros itens. O banco de da-dos ocupa mais de dois terabytes (um terabyte é 1012 bytes de armazenamento) e está armazenado em 200 computadores diferentes (denominados servidores). Cerca de 15 milhões de visitantesacessam a Ama-zon.com todos os dias e utilizam o banco de dados para fazer compras. O banco de dados é continua-mente atualizado à medida que novos livros e outros itens são acrescentados ao estoque e as quantidades em estoque são atualizadas à medida que as compras são feitas. Cerca de cem pessoas são responsáveis por manter o banco de dados da Amazon atualizado.Um banco de dados pode ser gerado e manti-do manualmente, ou pode ser computadorizado. Por exemplo, um catálogo de cartão de biblioteca é um banco de dados que pode ser criado e mantido manual-mente. Um banco de dados computadorizado pode ser criado e mantido por um grupo de programas de aplicação escritos especificamente para essa tarefa ou por um sistema gerenciador de banco de dados. Va-mos tratar apenas dos bancos de dados computado-rizados neste livro.Um sistema gerenciador de banco de dados (SGBD — Database Management System) é uma co-leção de programas que permite aos usuários criar e manter um banco de dados. O SGBD é um siste-ma de software de uso geral que facilita o processo de Capítulo 1 Bancos de dados e usuários de banco de dados 301 elmas0810_cap01 BR.indd 3 11/30/10 5:24 PMdefinição, construção, manipulação e compartilha-mento de bancos de dados entre diversos usuários e aplicações. Definir um banco de dados envolve es-pecificar os tipos, estruturas e restrições dos dados a serem armazenados. A definição ou informação descritiva do banco de dados também é armazenada pelo SGBD na forma de um catálogo ou dicionário, chamado de metadados. A construção do banco de dados é o processo de armazenar os dados em al-gum meio controlado pelo SGBD. A manipulação de um banco de dados inclui funções como consulta ao banco de dados para recuperar dados específicos, atualização do banco de dados para refletir mudan-ças no minimundo e geração de relatórios com base nos dados. O compartilhamento de um banco de dados permite que diversos usuários e programas acessem-no simultaneamente.Um programa de aplicação acessa o banco de dados ao enviar consultas ou solicitações de dados ao SGBD. Uma consulta2 normalmente resulta na recu-peração de alguns dados; uma transação pode fazer que alguns dados sejam lidos e outros, gravados no banco de dados.Outras funções importantes fornecidas pelo SGBD incluem proteção do banco de dados e sua ma-nutenção por um longo período. A proteção inclui proteção do sistema contra defeitos (ou falhas) de hardware ou software e proteção de segurança con-tra acesso não autorizado ou malicioso. Um banco de dados grande pode ter um ciclo de vida de muitos anos, de modo que o SGBD precisa ser capaz de man-ter o sistema, permitindo que ele evolua à medida que os requisitos mudam com o tempo.Não é absolutamente necessário utilizar softwa-re de SGBD de uso geral para implementar um ban-co de dados computadorizado. Poderíamos escrever nosso próprio conjunto de programas para criar e manter o banco de dados, com efeito criando nosso próprio software de SGBD de uso especial. Em ambos os casos — se usarmos um SGBD de uso geral ou não —, em geral temos de implementar uma quan-tidade considerável de software complexo. De fato, a maioria dos SGBDs é constituída de sistemas de software muito complexos.Para completar nossas definições iniciais, chamaremos a união do banco de dados com o software de SGBD de sistema de banco de dados. A Figura 1.1 ilustra alguns dos conceitos que dis-cutimos até aqui.2 O termo consulta (ou query), que originalmente significa uma pergunta ou uma pesquisa, é usado livremente para todos os tipos de interações com bancos de dados, incluindo a modificação dos dados.3Usamos o termo arquivo informalmente aqui. Em um nível conceitual, um arquivo é uma coleção de registros que podem ou não estar ordenados.Sistema de banco de dadosUsuários/programadoresProgramas de aplicação/ConsultasSoftware para processar consultas/programasSoftware para acessar dados armazenadosBanco de dados armazenadoDefinição do banco de dados armazenado (metadados)Software de SGBDFigura 1.1Diagrama simplificado de um ambiente de sistema de banco de dados.1.2 Um exemploVamos considerar um exemplo simples ao qual a maioria dos leitores pode estar acostumada: um banco de dados UNIVERSIDADE para manter informações re-ferentes a alunos, disciplinas e notas em um ambiente universitário. A Figura 1.2 mostra a estrutura e alguns exemplos de dados para o banco de dados UNIVERSIDA-DE. O banco de dados está organizado como cinco ar-quivos, e cada um armazena registros de dados do mes-mo tipo.3 O arquivo ALUNO armazena dados sobre cada aluno, o arquivo disciplina armazena dados sobre cada disciplina, o arquivo TURMA armazena dados sobre cada turma de uma disciplina, o arquivo HISTORICO_ESCO-LAR armazena as notas que os alunos recebem nas várias turmas que eles concluíram, e o arquivo PRE_REQUISI-TO armazena os pré-requisitos de cada disciplina.Para definir esse banco de dados, precisamos es-pecificar a estrutura dos registros de cada arquivo, de-terminando os diferentes tipos de elementos de dados a serem armazenados em cada registro. Na Figura 1.2, cada registro de ALUNO contém os dados que represen-4 Sistemas de banco de dados01 elmas0810_cap01 BR.indd 4 11/30/10 5:24 PMcontém os dados que representam o Nome_disciplina, Numero_disciplina, Creditos e Departamento (o depar-tamento que oferece a disciplina); e assim por diante. Também precisamos especificar um tipo de dado para cada elemento de dado em um registro. Por exemplo, podemos especificar que o Nome de ALUNO é uma sequência de caracteres alfabéticos; Numero_aluno de ALUNO é um inteiro, e Nota de HISTORICO_ESCOLAR é um único caractere do conjunto {‘A’, ‘B’, ‘C’, ‘D’, ‘F’}. Também podemos usar um esquema de codificação para representar os valores de um item de dados. Por exemplo, na Figura 1.2, representamos Tipo_aluno de um ALUNO como 1 para novato, 2 para segundo ano, 3 para júnior, 4 para sênior e 5 para aluno formado.Para construir o banco de dados UNIVERSIDADE, armazenamos dados para representar cada aluno, disciplina, turma, histórico escolar e pré-requisito como um registro no arquivo apropriado. Observe que os registros nos diversos arquivos podem es-tar relacionados. Por exemplo, o registro para Silva no arquivo ALUNO está relacionado a dois registros no arquivo HISTORICO_ESCOLAR, que especifica as no-tas de Silva em duas turmas. De modo semelhante, cada registro no arquivo PRE_REQUISITO relaciona--se a dois registros de disciplina; um representando a disciplina e o outro representando o pré-requisito. A maioria dos bancos de dados de tamanho médio e grande inclui muitos tipos de registros e possui mui-tos relacionamentos entre os registros.A manipulação do banco de dados envolve con-sulta e atualização. Alguns exemplos de consultas são os seguintes: � Recuperar uma lista de todas as disciplinas e notas de ‘Silva’. � Listar os nomes dos alunos que realizaram a disciplina ‘Banco de dados’ oferecida no segun-do semestre de 2008 e suas notas nessa turma. � Listar os pré-requisitos do curso de ‘Banco de dados’.Alguns exemplos de atualizações incluem: � Alterar o tipo de aluno de ‘Silva’ para segun-do ano. � Criar outra turma para a disciplina ‘Banco de dados’ para este semestre. � Inserir uma nota ‘A’ para ‘Silva’ na turma ‘Banco de dados’ do último semestre.Essas consultas e atualizações informais preci-sam ser especificadas corretamente na linguagem de consulta do SGBD antes de serem processadas.Nesse estágio, é útil descrever o banco de dados como parte de uma tarefa maior conhecida como sis-tema de informação dentro de qualquer organização. ALUNONome Numero_aluno Tipo_aluno CursoSilva 17 1 CCBraga 8 2 CCDISCIPLINANome_disciplinaNumero_disciplinaCreditos DepartamentoIntrod. à ciência da computaçãoCC1310 4 CCEstruturas de dadosCC3320 4