Introduo Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a um conjunto de programas para acesso

o a esses dados. O conjunto de dados, comumente chamado banco de dados, contm informaes sobre uma empresa em particular. O principal objetivo de um SGBD proporcionar um ambiente tanto conveniente quanto eficiente para a recuperao e armazenamento das informaes dos bancos de dados. Sistemas de banco de dados so projetados para gerir grandes volumes de informaes. O gerenciamento de informaes implica a definio das estruturas de armazenamento de informaes e a definio dos mecanismos para a manipulao dessas informaes. Ainda, um sistema de banco de dados deve garantir a segurana das informaes armazenadas contra eventuais problemas com o sistema, alm de impedir tentativas de acesso no autorizadas. Se os dados so compartilhados por diversos usurios, o sistema deve evitar a ocorrncia de resultados anmalos. A importncia da informao na maioria das organizaes que estabelece o valor do banco de dados tem determinado o desenvolvimento de um grande conjunto de conceitos e tcnicas para a administrao eficaz desses dados. Objetivos de um Sistema de Banco de dados Considere a rea de um banco responsvel por todas as informaes de seus cliente e de suas contaspoupana. Um modo de guardar as informaes no computador armazen-las em sistemas de arquivos permanentes. Para permitir aos usurios a utilizao dessas informaes, o sistema deve apresentar um conjunto de programas de aplicaes que tratam esses arquivos, incluindo: Um programa para dbito e crdito na contabilidade. Um programa para incluir novos registros na contabilidade. Um programa para balano da contabilidade. Um programa para gerar relatrios mensais. Essas aplicaes foram desenvolvidas por programadores a fim de atender s necessidades das organizaes bancrias. Novos programas foram incorporados a esses sistemas para atender a necessidades que foram surgindo. Por exemplo, suponha que novas regras sejam promulgadas pelo governo obrigando que os bancos ofeream meios para a checagem de suas contas. Com isso, novos arquivos permanentes sero criados contendo dados para checagem de todas as contas mantidas pelo banco e novos programas de aplicaes sero necessrios a fim de adequar-se a nova situao, que de fato no foi originada pela caderneta de poupana, como o tratamento de saldos negativos. Assim, conforme passa o tempo, mais arquivos e mais programas de aplicaes so adicionados ao sistema. O sistema de processamento de arquivos tpico que acabamos de descrever pode ser aceito pelos sistemas operacionais convencionais. Registros permanentes so armazenados em vrios arquivos e diversos programas de aplicao so escritos para extrair e gravar registros nos arquivos apropriados. Antes do advento dos SGBDs, as organizaes usavam esses sistemas para armazenar informaes. Obter informaes organizacionais em sistemas de processamento de arquivos apresenta numerosas desvantagens: Inconsistncia e redundncia de dados. J que arquivos e aplicaes so criados mantidos por diferentes programadores, em geral durando longos perodos de tempo, comum que os arquivos possuam formatos diferentes e os programas sejam escritos em diversas linguagens de programao. Ainda mais, a mesma informao pode ser repetida em diversos lugares (arquivos). Por exemplo, o endereo e o telefone de um cliente em particular pode aparecer tanto no arquivo de contas quanto no arquivo de checagem de contas. Esta redundncia aumenta os custos de armazenamento e acesso. Ainda, pode originar inconsistncia de dados; isto , as vrias cpias dos dados podero divergir ao longo do tempo. 74

Por exemplo, a mudana de endereo de um cliente pode refletir nos arquivos de contas, mas no ser alterada no sistema como um todo. Dificuldade de acesso aos dados. Suponha que um dos empregados da empresa precise de uma relao com os nomes de todos os cliente que moravam em determinada rea de acidade cujo CEP 78733. O empregado pede, ento, ao departamento de processamento de dados que crie tal relao. Como esse tipo de solicitao no foi prevista no projeto do sistema no h nenhuma aplicao disponvel para atende-la. No entanto, h uma aplicao para gerar a relao de todos os clientes da empresa. Assim, o empregado tem duas alternativas: separar manualmente da lista de todos os clientes aqueles de que necessita ou requisitar ao departamento de processamento de dados um programador para escrever o programa necessrio. Ambas as alternativas so, obviamente, insatisfatrias. Suponha que o tal programa seja escrito e que dias depois o mesmo empregado necessite selecionar os clientes que possuem saldo superior a dez mil dlares. Como esperado, tal programa no existe. Novamente o empregado tem as mesmas duas opes, nenhuma delas insatisfatria. O fato que um ambiente com um sistema de processamento de arquivos convencional no atende s necessidades de recuperao de informaes de modo eficiente. Sistemas mais efetivos (com respostas mais rpidas e adequadas) para a recuperao de informaes precisam ser desenvolvidos. Isolamento de dados. Como os dados esto dispersos em vrios arquivos, e estes arquivos podem apresentar diferentes formatos, difcil escrever novas aplicaes para recuperao apropriada dos dados. Problema de integridade. Os valores dos dados atribudos e armazenados em um banco de dados devem satisfazer certas restries para manuteno da consistncia. Por exemplo, o balano de uma conta bancaria no pode cair abaixo de um determinado valor. Os programadores determinam o cumprimento dessas restries por meio da adio de cdigo apropriado aos vrios programas de aplicaes. Entretanto, quando aparecem novas restries difcil alterar todos os programas para increment-las. O problema ampliado quando as restries atingem diversos itens de dados em diferentes arquivos. Problemas de atomicidade. Um sistema computacional, como qualquer outro dispositivo mecnico ou eltrico, est sujeito a falhas. Em muitas aplicaes crucial assegurar que, uma vez detectada uma falha, os dados sejam salvos em seu ltimo estado consistente, anterior a ela. Considere um programa para transferir 50 dlares da conta A para uma conta B. Se ocorrer falha no sistema durante sua execuo, possvel que os 50 dlares sejam debitados da conta A sem serem creditados na conta B, criando um estado inconsistente no banco de dados. Logicamente, essencial para a consistncia do banco de dados que ambos, dbito e crdito, ocorram ou nenhum deles seja efetuado. Isto , a transferncia de fundos deve ser uma operao atmica deve ocorrer por completo ou no ocorrer. difcil garantir essa propriedade em um sistema convencional de processamento de arquivos. Anomalias no acesso concorrente. Muitos sistemas permitem atualizaes simultneas nos dados para aumento do desempenho do sistema como um todo e para melhores tempos de resposta. Nesses tipos de ambiente, a interao entre atualizaes concorrentes pode resultar em inconsistncia de dados. Suponha que o saldo de uma conta bancria A seja 500 dlares. Se dois clientes retiram fundos da conta A (digamos 50 e 100 dlares, respectivamente), essas operaes, ocorrendo simultaneamente, podem resultar em erro (ou gerar inconsistncia). Suponha que, na execuo dos programas, ambos os clientes leiam o saldo antigo e retirem, cada um, seu valor correspondente, sendo o resultado armazenado. Os dois programas concorrendo, ambos leem o valor 500 dlares, resultado, em 450 e 400 dlares, respectivamente. Dependendo de qual deles registre seu resultado primeiro, o saldo da conta A ser 450 ou 400 dlares, em vez do valor correto de 350 dlares. Para resguardar-se dessa possiblidade, o sistema deve manter algum tipo de superviso. Como os dados podem sofrer acesso de diferentes programas, os quais no foram coordenados previamente, a superviso bastante dificultada. Problemas de segurana. Nem todos os usurios de banco de dados esto autorizados ao acesso a todos os dados. Por exemplo, em um sistema bancrio, os funcionrios do departamento pessoal devem ter 75

acesso apenas ao conjunto de pessoas que trabalham no banco. Uma vez que os programas de aplicao so inseridos no sistema como um todo, difcil garantir a efetividade das regras de segurana. Estas dificuldades, entre outras, provocaram o desenvolvimento dos SGBDs. A seguir mostraremos os conceitos e algoritmos que foram desenvolvidos para os sistemas de banco de dados que resolvem os problemas mencionados anteriormente. Uma aplicao tpica em banco de dados armazena um grande nmero de registros, sendo que estes registros so frequentemente simples e pequenos. Viso dos Dados Um SGBD uma coleo de arquivos e programas inter-relacionados que permitem ao usurio o acesso para consultas e alteraes desses dados. O maior benefcio de um banco de dados proporcionar ao usurio uma viso abstrata dos dados. Isto , o sistema acaba por ocultar determinados detalhes sobre a forma de armazenamento e manuteno desses dados. Abstrao de Dados Para que se possa usar um sistema, ele precisa ser eficiente na recuperao de informaes. Esta eficincia est relacionada forma pela qual foram projetadas as complexas estruturas de representao desses dados no banco de dados. J que muitos dos usurios dos sistemas de banco de dados no so treinados em computao, os tcnicos em desenvolvimento de sistemas omitem essa complexidade desses usurios por meio dos diversos nveis de abstrao de modo a facilitar a interao dos usurios com o sistema: Nvel fsico. o mais baixo nvel de abstrao que descreve como esses dados esto de fato armazenados. No nvel fsico, estruturas de dados complexas de nvel baixo so descritas em detalhes. Nvel lgico. Este nvel mdio de abstrao descreve quais dados esto armazenados no banco de dados e quais os inter-relacionamentos entre eles. Assim, o banco de dados como um todo descrito em termos de um nmero relativamente pequeno de estruturas simples. Embora a implementao dessas estruturas simples no nvel lgico possa envolver estruturas complexas no nvel fsico, o usurio do nvel lgico no necessariamente precisa estar familiarizado com essa complexidade. O nvel lgico de abstrao utilizado pelos administradores do banco de dados que precisam decidir quais informaes devem pertencer ao banco de dados. Nvel de viso. O mais alto nvel de abstrao descreve apenas parte do banco de dados. A despeito das estruturas simples do nvel lgico, alguma complexidade permanece devido ao tamanho dos banco de dados. Muitos dos usurios do banco de dados no precisam conhecer todas as suas informaes. Pelo contrrio, os usurios normalmente utilizam apenas parte do banco de dados. Assim, para que estas interaes sejam simplificadas, um nvel de viso definido. O sistema pode proporcionar diversas vises do mesmo banco de dados.

76

O inter-relacionamento entre esses trs nveis de abstrao est ilustrado na fig. 1.1. Uma analgica com o conceito de tipos de dados em linguagens de programao pode ajudar a esclarecer a distino entre os nveis de abstrao. As linguagens de programao de mais alto nvel do suporte noo de tipos de dados. Por exemplo, nas linguagens semelhantes ao Pascal, podemos declarar um registro como se segue:

Esse cdigo define um novo registro chamado cliente com quatro campos. Cada campo tem um nome e um tipo a ele associado. Um banco pode ter diversos tipos de registro, incluindo: conta, com os campos nmero_conta e saldo; empregado, com os campos nome_empregado e salario. No nvel fsico, um registro de cliente, conta ou empregado pode ser descrito como um bloco consecutivo de memria (p.e., palavras ou bytes). O compilador esconde esse nvel de detalhes dos programadores. Analogamente, o sistema de banco de dados esconde muitos dos detalhes de armazenamento em nvel mais baixo dos programadores do banco de dados. Os administradores de banco de dados podem estar familiarizados com certos detalhes da organizao fsica dos dados. No nvel lgico, cada registro descrito por um tipo definido, como ilustrado no segmento de cdigo de programa visto, assim como definida a inter-relao entre esses tipos de registros. Os programadores trabalham com a linguagem de programao nesse nvel de abstrao. Da mesma forma, os administradores de banco de dados, usualmente, trabalham nesse nvel de abstrao. Finalmente, no nvel de viso, os usurios do computador veem um conjunto de programas de aplicao que esconde os detalhes dos tipos de dados. Nesse nvel, algumas vises do banco de dados so definidas e os usurios tm acesso a essas vises. Mais do que esconder detalhes prprios do nvel lgico, essas vises tambm fornecem mecanismos de segurana, de modo a restringir o acesso dos usurios a determinadas partes do banco de dados. Por exemplo, em um banco, as telefonistas devem ter acesso apenas s informaes dos extratos bancrios dos clientes, no devem ter acesso a informaes salariais dos empregados do banco. Instncias e Esquemas Um banco de dados muda ao longo do tempo por meio das informaes que neles so inseridas ou excludas. O conjunto de informaes contidas em determinado banco de dados, em um dado momento chamado instncia do banco de dados. O projeto geral do banco de dados chamado esquema. Os esquemas so alterados com pouca frequncia. Analogias com conceitos de linguagem de programao, como tipos de dados, variveis e valores, so teis aqui. Voltando definio do registro clientes, note que, na declarao de seu tipo, no definimos qualquer varivel. Para declarar uma varivel em linguagens semelhantes ao Pascal, escrevemos var cliente1: cliente; A varivel cliente1 corresponde agora a uma rea de memria que contm um registro tipo cliente. Um esquema de banco de dados corresponde definio do tipo em uma linguagem de programao. Uma varivel de um tipo tem um valor em particular em dado instante. Assim, esse valor corresponde a uma instncia do esquema do banco de dados. Os sistemas de banco de dados apresentam diversos esquemas, referentes aos nveis de abstrao que discutimos. No nvel mais baixo h o esquema fsico; no nvel intermedirio, o esquema lgico; e no nvel mais 77

alto, os subesquemas. Em geral, os sistemas de banco de dados do suporte a um esquema fsico, um esquema lgico e vrios subesquemas. Independncia de Dados Os sistemas de banco de dados apresentam diversos esquemas, referentes ao nveis de abstrao j discutidos. No nvel mais baixo h o esquema fsico; no nvel intermedirio, o esquema lgico; e no nvel mais alto, os subesquemas. Em geral, os sistemas de banco de dados do suporte a um esquema fsico, um esquema lgico e vrios subesquemas. Independncia de Dados A capacidade de modificar a definio dos esquemas em determinado nvel, sem afetar o esquema superior, chamado independncia de dados. Existem dois nveis de independncia de dados: 1. Independncia de dados fsica a capacidade de modificar o esquema fsico sem que, com isso, qualquer programa de aplicao precise ser reescrito. Modificaes no nvel fsico so necessrias, ocasionalmente, para aprimorar o desempenho. 2. Independncia de dados lgica a capacidade de modificar o esquema lgica sem que, com isso, qualquer programa de aplicao precise ser reescrito. Modificaes no nvel lgico so necessrias sempre que uma estrutura lgica do banco de dados alterada (p.e., quando novas moedas so inseridas no sistema de um banco). A independncia de dados lgica mais difcil de ser alcanada que a independncia fsica, uma vez que os programas de aplicao so mais fortemente dependentes da estrutura lgica dos dados do que de seu acesso. O conceito de independncia de dados de vrias formas similar ao conceito de tipo de dados empregado nas linguagens modernas de programao. Ambos os conceitos omitem detalhes de implementao do usurio, permitindo que ele se concentre em sua estrutura geral em vez de se concentrar nos detalhes tratados no nvel mais baixo. Modelo de Dados Sob a estrutura do banco de dados est o modelo de dados: um conjunto de ferramentas conceituais usadas para a descrio dos dados, relacionamentos entre dados, semntica de dados e regras de consistncia. Os vrios modelos que vm sendo desenvolvidos so classificados em trs diferentes grupos: modelos lgicos com base em objetos, modelos lgicos com base em registros e modelos fsicos. Modelos Lgicos com Base em Objetos Os modelos lgicos com base em objetos so usados na descrio do nvel lgico e de vises. So caracterizados por dispor de recursos de estruturao bem mais flexveis e por viabilizar a especificao explcita das restries de dados. Existem vrios modelos nessa categoria, e outros ainda esto por surgir. Alguns so amplamente conhecidos, como: Modelo entidade-relacionamento. Modelo orientado a objeto. Modelo semntico de dados. Modelo funcional de dados. Modelo Entidade-Relacionamento O modelo de dados entidade-relacionamento (E-R) tem por base a percepo do mundo real como um conjunto de objetos bsicos, chamados entidades, e do relacionamento entre eles. Uma entidade uma coisa ou um objeto do mundo real que pode ser identificado por outros objetos. Por exemplo, cada pessoa uma entidade, as contas dos clientes de um banco tambm podem ser consideradas entidades. As entidades soa 78

descritas no banco de dados por meio de seus atributos. Por exemplo, os atributos nmero_conta e saldo descrevem uma conta bancria em particular. Um relacionamento uma associao entre entidades. Por exemplo, um relacionamento depositante associa um cliente a cada conta que ele possui. O conjunto de todas as entidades de um mesmo tipo, assim como o conjunto de todos os relacionamentos de mesmo tipo so denominados conjunto de entidades e conjunto de relacionamentos, respectivamente. Alm das entidades e dos relacionamento, o modelo E-R representa certas regras, as quais o contedo do banco de dados precisa respeitar. Uma regra importante o mapeamento das cardinalidades, as quais expressam o nmero de entidades s quais a outra entidade se relaciona por meio daquele conjunto de relacionamentos. Toda estrutura lgica do banco de dados pode ser expressa graficamente por meio do diagrama E-R, cujo construtores dos seguintes componentes so: Retngulos, que representam os conjuntos de entidades. Elipses, que representam os atributos. Losangos, que representam os relacionamentos entre os conjuntos de entidades. Linhas, que unem os atributos aos conjuntos de entidades e o conjunto de entidades aos seus relacionamentos. Cada componente rotulado com o nome da entidade ou relacionamento que representa. Como ilustrao, considere uma parte do sistema bancrio composta pelos clientes e suas respectivas contas. O diagrama E-R correspondente mostrado na fig. 1.2.

Modelo Orientado a Objetos Como o modelo E-R, o modelo orientado a objetos tem por base um conjunto de objetos. Um objeto contm valores armazenados em variveis instncias dentro do objeto. Um objeto tambm contm conjuntos de cdigos que operam esse objeto. Esses conjuntos de cdigos so chamados mtodos. Os objetos que contm os mesmos tipos de valores e os mesmos mtodos so agrupados em classes. Uma classe pode ser vista como uma definio de tipo para objetos. Essa combinao compacta de dados e mtodos abrangendo uma definio de tipo similar ao tipo abstrato em uma linguagem de programao. O nico modo pelo qual um objeto pode conseguir acesso aos dados de outro objeto por meio do mtodo desse outro objeto. Essa ao chamada de enviar mensagem ao objeto. Assim, a interface de mtodos de um objeto define a parte externa visvel de um objeto. A parte interna de um objeto as instncias variveis e o cdigo do mtodo no so visveis externamente. O resultado so dois nveis de abstrao de dados. Modelos Lgicos com Base em Registros Modelos lgicos com base em registros so usados para descrever os dados no nvel lgico e de viso. Em contraste com os modelos com base em objetos, este tipo de modelo usado tanto para especificar a estrutura lgica do banco de dados quanto para implementar uma descrio de alto nvel.

79

Os modelos com base em registro so assim chamados porque o banco de dados estruturado por meio de registros de formato fixo de todos os tipos. Cada registro define um nmero fixo de campos ou atributos, e cada atributo tem um tamanho fixo. Modelo Relacional O modelo relacional usa um conjunto de tabelas para representar tanto os dados com a relao entre eles. Cada tabela possui mltiplas colunas e cada uma possui um nome nico. A fig. 1.3 apresenta um exemplo de banco de dados relacional condensado em duas tabelas: uma mostrando os clientes do banco e a outra, suas contas. Modelo de Rede Os dados no modelo de rede so representados por um conjunto de registros (como no Pascal) e as relaes entre estes registros so representados por links (ligaes), as quais podem ser vistas pelos ponteiros. Os registros so organizados no banco de dados por um conjunto arbitrrio de grficos. A fig. 1.4 apresenta um exemplo de banco de dados em rede, usando as mesmas informaes da fig. 1.3. Modelo Hierrquico O modelo hierrquico similar ao modelo em rede, pois os dados e suas relaes so representados, respectivamente, por registros e links. A diferena que no modelo hierrquico os registros esto organizados em arvores em vez de grficos arbitrrios. A fig. 1.5 apresenta um exemplo de modelo de banco de dados hierrquico, usando as mesmas informaes da fig. 1.4.

80

Diferena entre Modelos O modelo relacional difere dos modelos hierrquico e em rede por no usar nem ponteiros nem links. Ele relaciona os registros por valores prprios a eles. Como no necessrio o uso de ponteiros, houve a possibilidade do desenvolvimento de fundamentos matemticos para sua definio.

81

Modelos Fsicos de Dados Os modelos fsicos de dados so usados para descrev-los no nvel mais baixo. Em contraste com os modelos lgicos, h poucos modelos fsicos de dados em uso. Dois deles so amplamente conhecidos: o modelo unificado (unifying model) e o modelo de partio de memria (frame-memory model). Os modelos fsicos captam os aspectos de implementao do sistema de banco de dados. Linguagens de Banco de Dados Um sistema de banco de dados proporciona dois tipos de linguagens: uma especfica para os esquemas do banco de dados e outra para expressar consultas e atualizaes. Linguagens de Definicao de Dados Um esquema de dados especificado por um conjunto de vises expressas por uma linguagem especial chamada linguagem de definio de dados (data-definition language DDL). O resultado da compilao dos parmetros DDLs armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionrio de dados ou diretrio de dados. Um dicionrio de dados um arquivo de metadados isto , dados a respeito de dados. Em um sistema de banco de dados, esse arquivo ou diretrio consultado antes que o dado real seja modificado. A estrutura de memria e o mtodo de acesso usados pelo banco de dados so especificados por um conjunto de definies em um tipo especial de DDL, chamado linguagem de definio e armazenamento de dados (data storage and definition language). O resultado da compilao dessas definies um conjunto de instrues para especificar os detalhes de implementao dos esquemas do banco de dados os detalhes normalmente so ocultados dos usurios. Linguagem de Manipulao dos Dados Os nveis de abstrao j discutidos no se aplicam apenas definio ou estrutura dos dados, mas tambm a sua manipulao. Por manipulao de dados entendemos: 82

A recuperao das informaes armazenadas no banco de dados. Insero de novas informaes no banco de dados. A remoo de informaes do banco de dados. A modificao das informaes do banco de dados.

No nvel fsico, precisamos definir algoritmos que permitam o acesso eficiente aos dados. Nos nveis mais altos de abstrao, enfatizamos a facilidade de uso. O objetivo proporcionar uma interao eficiente entre homens e sistema. A linguagem de manipulao de dados (DML) a linguagem que viabiliza o acesso a manipulao dos dados de forma compatvel ao modelo de dados apropriado. So basicamente dois tipos: DMLs procedurais exigem que o usurio especifique quais dados so necessrios e como obt-los. DMLs no procedurais exige que o usurio especifique quais dados so necessrios, sem especificar como obt-los. As DMLs no procedurais so normalmente mais fceis de aprender e de usar. Entretanto, como o usurio no especifica como obter os dados, essas linguagens pode gerar cdigo menos eficiente que os gerados por linguagens procedurais. Podemos resolver esse tipo de problema por meio de vrias tcnicas de otimizao. Uma consulta uma solicitao para recuperao de informaes. A parte de uma DML responsvel pela recuperao de informao chamada linguagem de consultas (query language). Embora tecnicamente incorreto, comum o uso do termo linguagem de consultas como sinnimo de linguagem de manipulao de dados. Gerenciamento de Transaes Frequentemente, muitas operaes em um banco de dados constituem uma nica unidade lgica de trabalho. Voltamos ao exemplo usado na transferncia de fundos entre contas bancrias, responsvel pelo dbito na conta A e crdito na conta B. Antes de mais nada, essencial que ocorram ambas as operaes, de crdito e dbito, ou nenhuma delas dever ser realizada. Isto , ou a transferncia de fundos acontece como um todo ou nada deve ser feito. Esse tudo-ou-nada chamado atomicidade. Ainda mais, necessrio que a transferncia de fundos preserve a consistncia do banco de dados. Ou seja, a soma de A+B deve ser preservada. Essas exigncias de corretismo so chamadas de consistncia. Finalmente, depois da execuo com sucesso da transferncia de fundos, os novos valores de A e B devem persistir, a despeito das possibilidades de falhas no sistema. Esta persistncia chamada durabilidade. Uma transao uma coleo de operaes que desempenha uma funo lgica nica dentro de uma aplicao do sistema de banco de dados. Cada transao uma unidade de atomicidade e consistncia. Assim, exigimos que as transaes no violem nenhuma das regras de consistncia do banco de dados. Ou seja, o banco de dados estava consistente antes do incio da transao e deve permanecer consistente aps o trmino com sucesso de uma transao. Entretanto, durante a execuo de uma transao, ser necessrio aceitar inconsistncias temporariamente. Essa inconsistncia temporria, embora necessria pode gerar problemas caso ocorra uma falha. responsabilidade do programador definir, de modo apropriado, as diversas transaes, tais que cada uma preserve a consistncia do banco de dados. Por exemplo, a transao para a transferncia de fundos da conta A para a conta B poderia ser composta por dois programas distintos: um para dbito na conta A e outro para crdito na conta B. A execuo destes dois programas um aps o outro ir manter a consistncia do banco de dados. Entretanto, cada programa executado isoladamente no leva o banco de dados de um para outro estado inconsistente. Logo, esses programas separados no so transaes. Assegurar as propriedades de atomicidade e durabilidade tambm responsabilidade do sistema de banco de dados especialmente, os componentes de gerenciamento de transaes. Na ausncia de falhas, todas as transaes se completam com sucesso e a atomicidade garantida. No entanto, devido aos vrios tipos de falhas possveis, uma transao pode no se completar com sucesso. Se estivermos empenhados em garantir a 83

atomicidade, uma transao incompleta no poder comprometer o estado do banco de dados. Assim, o banco de dados precisa retornar ao estado anterior em que se encontrava antes do incio dessa transao. responsabilidade do sistema de banco de dados detectar as falhas e recuperar o banco de dados, garantindo seu retorno a seu ltimo estado consistente. Por fim, quando muitas transaes atualizam o banco de dados concorrentemente, a consistncia do banco de dados pode ser violada, mesmo que essas transaes, individualmente, estejam corretas. responsabilidade do gerenciador de controle de concorrncia controlar a interao entre transaes concorrentes de modo a garantir a consistncia do banco de dados. Os sistemas de banco de dados projetados para o uso em computadores pessoais podem no apresentar todas essas funes. Administrao de Memria Normalmente, os banco de dados exigem um grande volume de memria. Um banco de dados corporativo usualmente medido em termos de gigabytes ou, para banco de dados de grande porte (largest database), terabytes. Um gigabyte corresponde a 1000 megabytes (1 bilho de bytes) e um terabyte 1 milho de megabytes (1 trilho de bytes). J que a memria do computador no pode armazenar volumes to grandes de dados, as informaes so armazenadas em discos. Os dados so transferidos dos discos para a memria quando necessrio. Uma vez que essa transferncia relativamente lenta comparada velocidade do processador, imperativo que o sistema de banco de dados estruture os dados de forma a minimizar a necessidade de movimentao entre disco e memria. O objetivo de um sistema de banco de dados simplificar e facilitar o acesso aos dados. Vises de alto nvel ajudam a alcanar esses objetivos. Os usurios do sistema no devem desnecessariamente importunados com detalhes fsicos relativos implementao do sistema. Todavia, um dos fatores mais importantes de satisfao ou insatisfao do usurio com um sistema de banco de dados justamente seu desempenho. Se o tempo de resposta demasiado, o valor do sistema diminui. O desempenho de um sistema de banco de dados depende da eficincia das estruturas usadas para a representao dos dados, e do quanto esse sistema est apto a operar essas estruturas de dados. Como acontece com outras reas dos sistemas computacionais, no se trata somente do consumo de espao e tempo, mas tambm da eficincia de um tipo de operao sobre outra. Um gerenciador de memria um mdulo de programas para interface entre o armazenamento de dados em um nvel baixo e consultas e programas de aplicao submetidos ao sistema. O gerenciamento de memria responsvel pela interao com o gerenciamento de arquivos. Uma linha de dados armazenada no disco usando os sistema de arquivos que, convencionalmente, fornecido pelo sistema operacional. O gerenciador de memria traduz os diversos comandos DML em comandos de baixo nvel de sistema de arquivos. Assim, o gerenciador de memria responsvel pelo armazenamento, recuperao e atualizao de dados no banco de dados. O Administrador de Banco de Dados Uma das principais razoes que motivam o uso do SGBDs o controle centralizado tanto dos dados quanto dos programas de acesso a esses dados. A pessoa que centraliza esse controle do sistema chamado administrador de dados (DBA). Dentre as funes de um DBA destacamos as seguintes: Definicao do esquema. O DBA cria o esquema do banco de dados original escrevendo um conjunto de definies que so transformadas pelo compilador DDL em um conjunto de tabelas armazenadas de modo permanente no dicionrio de dados. Esquema e modificaes na organizao fsica. Os programadores realizam relativamente poucas alteraes no esquema do banco de dados ou na descrio da organizao fsica de armazenamento por meio de um conjunto de definies que sero usadas ou pelo compilador DDL ou pelo compilador de armazenamento de dados e definio de dados, gerando modificaes na tabela apropriada, interna ao sistema (p.e., no dicionrio de dados).

84

Fornecer autorizao de acesso ao sistema. O fornecimento de diferentes tipos de autorizao no acesso aos dados permite que o administrador de dados regule o acesso dos diversos usurios s diferentes partes do sistema. Os dados referentes autorizao de acesso so armazenados em uma estrutura especial do sistema que consultada pelo sistema de banco de dados toda vez que o acesso quele dado for solicitado. Especificao de regras de integridade. Os valores dos dados armazenados no banco de dados devem satisfazer certas restries para manuteno de sua integridade. Por exemplo, o nmero de horas que um empregado pode trabalhar durante uma semana no deve ser superior a um limite especificado (digamos, 40 horas). Tal restrio precisa ser explicitada pelo administrador de dados. As regras de integridade so tratadas por uma estrutura especial do sistema que consultada pelo sistema de banco de dados sempre que uma atualizao est em curso no sistema.

Usurios de Banco de Dados A meta bsica de um sistema de banco de dados proporcionar um ambiente para recuperao de informaes e para o armazenamento de novas informaes no banco de dados. H quatro tipos de usurios de sistemas de banco de dados, diferenciados por suas expectativas de interao com o sistema. Programadores de aplicao: so profissionais em computao que interagem com o sistema por meio de chamadas DML, as quais so envolvidas por programas escritos na linguagem hospedeira (p.e., COBOL, PL/1, C). Esses programas so comumente referidos como programas de aplicao. Exemplos em um sistema bancrio incluem programas para gerar relao de cheques pagos, para crdito em contas, para dbitos em conta ou para transferncia de fundos entre contas. Uma vez que a sintaxe da DML , em geral, completamente diferente de uma linguagem hospedeira, as chamadas DML so, normalmente, precedidas por um caractere especial antes que o cdigo apropriado possa ser gerado. Um pr-processamento, chamado pr-compilador DML, converte os comandos DML para as chamadas normais em procedimentos da linguagem hospedeira. O programa resultante , ento, submetido ao compilador da linguagem hospedeira, a qual gera o cdigo de objeto apropriado. Existem tipos especiais de linguagem de programao que combinam estruturas de controle de linguagens semelhantes ao Pascal com estruturas de controle para manipulao dos objetos do banco de dados (p.e., relaes). Estas linguagens, muitas vezes chamadas linguagens de quarta gerao, frequentemente incluem recursos especiais para facilitar a gerao de formulrios e a apresentao de dados no monitor. A maior parte dos sistemas de banco de dados comerciais inclui linguagens de quarta gerao. Usurios sofisticados: interagem com o sistema sem escrever programas. Formulam suas solicitaes ao banco de dados por meio de linguagens de consultas. Cada uma dessas solicitaes submetida ao processador de consultas cuja funo quebrar as instrues DML em instrues que o gerenciador de memria entenda. Os analistas que submetem consultas para explorar dados no banco de dados caem nessa categoria. Usurios especialistas: so usurios sofisticados que escrevem aplicaes tradicionais especializadas de banco de dados que no podem ser classificadas como aplicaes tradicionais em processamento de dados. Dentre elas esto os sistemas para projetos auxiliados por computador, sistemas especialistas e sistemas de base de conhecimento, sistemas que armazenam dados de tipos complexos (por exemplo, dados grficos e de udio) e sistemas para modelagem de ambiente (environment-modeling systems). Usurios navegantes: so usurios comuns que interagem com o sistema chamando um dos programas aplicativos permanentes j escritos, como, por exemplo, um usurio que pede a transferncia de 50 dlares da conta A para a B por telefone, usando para isso um programa chamado transfer. Esse programa pede ao usurio o valor a ser transferido, o nmero da conta para crdito e o nmero da conta para dbito. Viso Geral da Estrutura do Sistema 85

Um sistema de banco de dados est dividido em mdulos especficos, de modo a atender a todas as funes do sistema. Algumas das funes do sistema de banco de dados podem ser fornecidas pelo sistema operacional. Na maioria das vezes, o sistema operacional do computador fornece apenas as funes essenciais, e o sistema de banco de dados deve ser construdo nessa base. Assim, o projeto do banco de dados deve considerar a interface entre o sistema de banco de dados e o sistema operacional. Os componentes funcionais do sistema de banco de dados podem ser divididos pelos componentes de processamento de consultas e pelos componentes de administrao de memria. Os componentes de processamento de consultas incluem: Compilador DML, que traduz comando DML da linguagem de consulta em instrues de baixo nvel, inteligveis ao componente de execuo de consultas. Alm disso, o compilador DML tenta transformar a solicitao do usurio em uma solicitao equivalente, mas mais eficiente, buscando, assim, uma boa estratgia para execuo da consulta. Pr-compilador para comandos DML inseridos em programas de aplicao, que convertem comandos DML em chamadas de procedimentos normais da linguagem hospedeira. O pr-compilador precisa interagir com o compilador DML de modo a gerar o cdigo apropriado. Interpretador DDL, que interpreta os comandos DDL e registra-os em um conjunto de tabelas que contm metadados. Componentes para o tratamento de consultas, que executam instrues de baixo nvel geradas pelo compilador DML.

Os componentes para administrao do armazenamento de dados proporcionam a interface entre os dados de baixo nvel, armazenados no banco de dados, os programas de aplicaes e as consultas submetidas ao sistema. Os componentes de administrao de armazenamento de dados incluem: Gerenciamento de autorizaes e integridade, que testam o cumprimento das regras de integridade e a permisso ao usurio no acesso ao dado. Gerenciamento de transaes, que garante que o banco de dados permanecer em estado consistente (correto) a despeito de falhas no sistema e que transaes concorrentes sero executadas sem conflitos em seus procedimentos. Administrao de arquivos, que gerencia a alocao de espao no armazenamento em disco e as estruturas de dados usadas para representar estas informaes armazenadas em disco. Administrao de buffer, responsvel pela intermediao de dados do disco para a memria principal e pela deciso de quais dados colocar em memria cache. Alm disso, algumas estruturas de dados so exigidas como parte da implementao fsica do sistema: Arquivo de dados, que armazena o prprio banco de dados. Dicionrio de dados, que armazena os metadados relativos estrutura do banco de dados. O dicionrio de dados muito usado. Portanto, grande nfase dada ao desenvolvimento de um bom projeto com uma implementao eficiente do dicionrio. ndices, que proporcionam acesso rpido aos itens de dados que so associados a valores determinados. Estatsticas de dados, armazenam as informaes estatsticas relativas aos dados contidos no banco de dados. Essas informaes so usadas pelo processador de consultas para seleo de meios eficientes para execuo de uma consulta.

86

Modelo Entidade-Relacionamento O modelo entidade-relacionamento (E-R) tem por base a percepo de que o mundo real formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre esses objetos. Foi desenvolvido para facilitar o projeto do banco de dados, permitindo a especificao do esquema da empresa, que representa toda estrutura lgica do banco de dados. O modelo E-R um dos modelos com maior capacidade semntica; os aspectos semnticos do modelo se referem tentativa de representar o significado dos dados. O modelos E-R extremamente til para mapear, sobre um esquema conceitual, o significado e interaes das empresas reais. Devido a essa utilidade, muitas das ferramentas de projeto foram concebidas para o modelo E-R. Conceitos Bsicos Existem trs noes bsicas empregadas pelo modelo E-R: conjunto de entidades, conjunto de relacionamentos e os atributos. Conjunto de Entidades Um entidade uma coisa ou um objeto no mundo real que pode ser identificada de forma unvoca em relao a todos os outros objetos. Por exemplo, cada pessoa na empresa uma entidade. Uma entidade tem um conjunto de propriedades, e os valores para alguns conjuntos dessas propriedades devem ser nicos. Por exemplo, o nmero social 677-89-9011 identifica uma nica pessoa na empresa. Tambm, pode-se pensar em emprstimos como entidades, e o emprstimo nmero L-15 referente agncia Perryridge identifica univocamente uma entidade emprstimo. Uma entidade pode ser concreta, como uma pessoa ou um livro, ou pode ser abstrata, como um emprstimo, uma viagem de frias ou um conceito. Um conjunto de entidades um conjunto que abrange entidades de mesmo tipo que compartilham as mesmas propriedades: os atributos. O conjunto de todas as pessoas que so clientes de um banco de dados, por exemplo, pode ser definido como o conjunto de entidades clientes. Analogamente, o conjunto de entidades emprstimo poderia representar o conjunto de todos os emprstimos que o banco em questo viabiliza. As entidades individuais que constituem um conjunto so chamadas extenses do conjunto de entidades. Assim, todos os clientes do banco so as extenses do conjunto de entidades cliente. Os conjuntos de entidades no so necessariamente separados. Por exemplo, possvel definir um conjunto de entidades com todos os empregados do banco (empregado) e um conjunto de entidades com todos os clientes do banco (cliente). A entidade pessoa pode pertencer ao conjunto de entidades empregado, ou ao conjunto de entidades cliente, ou a ambos, ou a nenhum. Uma entidade representada por um conjunto de atributos. Atributos so propriedades descritivas de cada membro de um conjunto de entidades. A designao de um atributo para um conjunto de entidades expressa que o banco de dados mantm informaes similares de cada uma das entidades do conjunto de entidades; entretanto, cada entidade pode ter seu prprio valor em cada atributo. Atributos possveis ao conjunto de entidades clientes so nome_cliente, seguro_social, rua_cliente, e cidade_cliente. Atributos possveis para o conjunto de entidades emprstimo so nmero_emprstimo e conta. Para cada atributo existe um conjunto de valores possveis, chamado domnio, ou conjunto de valores, daquele atributo. O domnio do atributo nome_cliente pode ser o conjunto de todos os textos string de um certo tamanho. Similarmente, o domnio do atributo nmero_emprstimo pode ser o conjunto de todos os inteiros positivos. Desse modo, um banco de dados inclui uma coleo de conjuntos de entidades, cada qual contendo um nmero de entidades de mesmo tipo. A fig. 2.1 mostra parte do banco de dados de uma empresa bancria contendo dois conjuntos entidades: cliente e emprstimo.

87

Formalmente, um atributo de um conjunto de entidades uma funo que relaciona o conjunto de entidades a seu domnio. Desde que um conjunto de entidades possua alguns atributos, cada entidade pode ser descrita pelo conjunto formado pelos pares (atributos, valores de dados), um par para cada atributo do conjunto de entidades. Por exemplo, uma entidade em particular de cliente pode ser descrita pelo conjunto {(nome, Hayes), (seguro_social, 677-89-9011), (rua_cliente, Main), (cidade_cliente, Harrison)}, o que significa que essa entidade descreve o cliente Hayes, que possui o seguro social nmero 677-89-90211 e mora na Rua Main em Harrison. Podemos notar, a esta altura, uma integrao entre o esquema abstrato e a empresa real que est sendo modelada. Os valores dos atributos que descrevem as entidades constituem uma poro significativa dos dados que sero armazenados no banco de dados. Um atributo, como usado no modelo E-R, pode ser caracterizado pelos seguintes tipos: Atributos simples ou compostos. Em nosso exemplo anterior, todos os atributos eram simples: isto , no eram divididos em partes. Os atributos compostos, por outro lado, podem ser divididos em partes (isto , outros atributos). Por exemplo, nome_cliente pode ser estruturado em prenome, nome_intermediario e sobrenome. O uso de atributos compostos ajudam-nos a agrupar atributos correlacionados, tornando o modelo mais claro. Note que os atributos compostos podem estar hierarquizados. Retornando o exemplo do atributo composto endereo_cliente, seu atributo rua pode vir a ser subdividido posteriormente em nmero_rua, nome_rua, e nmero_apto. Esses exemplos de atributos compostos para clientes so apresentados na fig. 2.2. Atributos monovalorados ou multivalorados. Os atributos usados em nossos exemplos foram todos de valores simples para uma entidade em particular. Ou seja, o atributo nmero_emprstimo de uma entidade especfica refere-se apenas a um nmero de emprstimo. Esses atributos so chamados monovalorados. Pode haver instncias em que um atributo possua um conjunto de valores para uma nica entidade. Considere o conjunto de entidades empregado com o atributo nome_dependente. Qualquer empregado em particular pode ter um, nenhum ou vrios dependentes; entretanto, diferentes entidades empregado dentro do conjunto e empregados tero diferentes nmeros de valores para o atributo nome_dependente. Esse tipo de atributo dito multivalorado. Quando necessrio, pode-se estabelecer limites inferiores e superiores para o nmero de ocorrncias em um atributo multivalorado. Por exemplo, um banco pode ter um nmero limite de registros de endereos para um cliente normal, um ou dois endereos. O estabelecimento de limites, neste caso, exprime que o atributo endereo_cliente do conjunto de entidades cliente pode possuir de zero a dois valores. Atributos nulos. Um atributo nulo usado quando uma entidade no possui valor para determinado atributo. Por exemplo, se um empregado em particular no possui dependentes, o valor do atributo 88

nome_dependente para esse dependente dever ser nulo, e isso significa que esse atributo no aplicvel. Nulo tambm pode significar que o valor do atributo desconhecido. Um valor desconhecido pode caracterizar omisso (o valor existe de fato, mas no temos essa informao) ou no conhecimento (no sabemos se o valor existe de fato). Por exemplo, se o valor do seguro_social de determinado cliente nulo, assume-se que seu valor foi omitido, j que exigido para efeitos de impostos. Um valor nulo para o atributo nmero_apartamento pode significar que o nmero do apartamento foi omitido, ou que o nmero existe mas no sabemos qual , ou que o endereo no um prdio de apartamentos e, portanto, no faz parte do endereo do cliente.

Atributo derivado. O valor desse tipo de atributo pode ser derivado de outros atributos ou entidades a ele relacionados. Por exemplo, digamos que o conjunto de entidades cliente possui o atributo emprstimos_tomados, que representa o nmero de emprstimos tomados do banco por um cliente. Podemos derivar o valor desse atributo contando o nmero das entidades emprstimos associadas ao cliente em questo. Como outro exemplo, consideremos que o conjunto de entidades empregado est relacionado aos atributos data_contratao e tempo_de_casa, os quais representam o primeiro dia de emprego no banco e o tempo total que o empregado est trabalhando, respectivamente. O valor do tempo_de_casa pode ser derivado do valor da data_contratao e tempo_de_casa, os quais representam o primeiro dia de emprego no banco e o tempo total que o empregado est trabalhando, respectivamente. O valor do tempo_de_casa pode ser derivado do valor data_contratao e da data_corrente. Neste caso, a data_contratao pode ser referida como um atributo da base ou um atributo armazenado.

Um banco de dados para uma empresa bancria pode incluir um nmero diferente de conjuntos de entidades. Por exemplo, aliado ao que foi dito sobre clientes e emprstimos, um banco tambm possui contas, que esto representadas pelo conjunto de entidades conta com os atributos nmero_conta e saldo. Tambm, se um banco tem um nmero diferente de agncias, ento deveramos captar informaes sobre todas essas agncias. Cada conjunto de entidades agncia pode ser descrito pelos atributos nome_agncia, cidade_agncia e fundos. Conjuntos de Relacionamentos Um relacionamento uma associao entre uma ou vrias entidades. Por exemplo, podemos definir um relacionamento que associa o cliente Hayes com o emprstimo L-15. Esse relacionamento especifica que o cliente Hayes cliente com o emprstimo nmero L-15. Um conjunto de relacionamentos um conjunto de relacionamentos do mesmo tipo. De modo formal, a relao matemtica com n2 conjunto de entidades (podendo ser no-distintos). Se E1, E2, ..., Em so conjuntos de entidades, ento um conjunto de relacionamentos R um subconjunto de em que (e1, e2, ..., en) so relacionamentos. Considere dois conjuntos de entidades da fig. 2.1, cliente e emprstimo. Definimos o conjunto de relacionamentos devedor para denotar a associao entre clientes e emprstimos bancrios contrados pelo clientes. Essa associao apresentada na fig. 2.3.

89

Como exemplo, consideremos dois tipos de conjuntos de entidades, emprstimo e agncia. Podemos definir o conjunto de relacionamento agncia_emprstimo denotando a associao entre um emprstimo bancrio e a agncia onde esse emprstimo mantido. A associao entre os conjuntos de entidades referida como uma participao; isto , o conjunto de entidade E1, E2, ..., En participa do conjunto de relacionamentos R. Uma instncia de relacionamento em um esquema E-R representa a existncia de uma associao entre essa entidade e o mundo real no qual insere a empresa que est sendo modelada. Ilustramos a entidade cliente chamada Hayes, que possui o seguro social nmero 677-89-9011, e a entidade emprstimo L-15 participam na instncia do relacionamento devedor. Essa instncia do relacionamento representa que, no mundo real da empresa, uma pessoa chamada Hayes que possui o seguro social nmero 677-89-9011 tomou um emprstimo que tem o nmero L-15. A funo que uma entidade desempenha em um relacionamento chamada papel. Uma vez que os conjunto de entidades participantes em um conjunto de relacionamentos so geralmente distintos, papis so implcitos e no so, em geral, especificados. Entretanto, so uteis quando o significado de um relacionamento precisa ser esclarecido. Este o caso quando os conjuntos de entidades e os conjuntos de relacionamentos mais de uma vez, em diferentes papis. Nesse tipo de conjunto de relacionamentos, que algumas vezes chamado conjunto de relacionamentos recursivos, nomes explcitos de papis so necessrios para especificar como uma entidade participa de uma instncia de relacionamento. Por exemplo, considere o conjunto de entidades empregado que mantm informaes sobre todos os empregados do banco. Podemos ter um conjunto de relacionamentos trabalha_para que modelado para ordenar os pares de entidades de empregado. O primeiro empregado de um par tem o papel de gerente, enquanto o outro tem o papel de empregado. Deste modo, todos os relacionamentos de trabalha_para so caracterizados pelos pares (gerente, empregado); os pares (empregado, gerente) so excludos. Um relacionamento tambm pode ter atributos descritos. Considere o conjunto de relacionamentos depositante com o conjunto das entidades cliente e conta. Poderemos associar o atributo data_acesso a essa relao para especificar a data do ltimo aceso feito pelo cliente em sua conta. O relacionamento depositante entre as entidades correspondentes ao cliente Jones e conta A-217 descrita por {(data-acesso, 23 de maio de 2013)}, a qual significa que o mais recente acesso que Jones fez a sua conta A-217 foi em 23 de maio de 2013.

O conjunto de relacionamentos devedor e agncia_emprstimo um exemplo de conjunto de relacionamentos binrio isto , um relacionamento que envolve dois conjuntos de entidades. A maior parte dos conjuntos de relacionamentos nos sistemas de banco de dados so binrios. Ocasionalmente, entretanto, os conjuntos de relacionamentos envolvem mais de dois conjuntos de entidades. Como exemplo, podemos combinar os conjuntos de relacionamentos devedor e agncia_emprstimo formado o conjunto de 90

relacionamentos CEA, envolvendo os conjuntos de entidades cliente, emprstimo e agncia. Assim, o relacionamento ternrio entre as entidades correspondente ao cliente Hayes, o emprstimo nmero L-15, e a agncia Perryridge especifica que o cliente Hayes tem o emprstimo L-15 na agncia Perryridge. O nmero de conjuntos de entidades que participa de um conjunto de relacionamento tambm o grau desse conjunto de relacionamento. Um conjunto de relacionamento binrio de grau dois; um relacionamento ternrio de grau trs. Metas de Projeto Um conjunto de entidades e um conjunto de relacionamento no so noes precisas e possvel definir um conjunto de entidades e de relacionamentos entre eles de vrias formas diferentes. Uso de Conjuntos de Entidades ou Atributos Considere o conjunto de entidades empregado com os atributos nome_empregado e nmero_telefone. Pode ser facilmente verificado que o telefone uma entidade sujeita a seus prprios atributos, como nmero_telefone e localizao (o escritrio onde o telefone est instalado). Sob esse ponto de vista, o conjunto de entidades deve ser redefinido, conforme segue: O conjunto de entidades empregado com o atributo nome_empregado. O conjunto de entidades telefone com os atributos nmero_telefone e localizao. O conjunto de relacionamentos emp_telefone, o qual denota a associao entre os empregados e os telefones que podem ter. Qual , ento, a principal diferena entre essas duas definies de um empregado? No primeiro caso, a definio implica que todo empregado possui, precisamente, um nmero de telefone a ele associado. No segundo caso, entretanto, a definio estabelece que o empregado pode ter vrios nmeros de telefones (incluindo zero) a ele associados. Assim, a segunda definio mais geral que a primeira e pode refletir com maior preciso as situaes reais. Mesmos se nos for dado que cada empregado tem, precisamente, um nmero de telefone a ele associado, a segunda definio pode, ainda assim, ser mais apropriada, caso um mesmo telefone possa ser compartilhado por diversos empregados. No seria apropriado, no entanto, aplicar a mesma tcnica ao atributo nome_empregado; difcil sustentar que nome_empregado seja uma entidade por si s (em contraste com telefone). Assim, apropriado manter nome_empregado como atributo do conjunto de entidades empregado. Duas questes aparecem naturalmente: o que constitui um atributo e o que constitui um conjunto de entidades? Infelizmente, no existe uma resposta simples. As distines dependem, principalmente, da estrutura real da empresa que est sendo modelada e da semntica associada aos atributos em questo. Uso dos Conjuntos de Entidades e Conjunto de Relacionamentos Nem sempre fica claro se um objeto melhor expresso por um conjunto de entidades ou por um conjunto de relacionamentos. J assumimos anteriormente que um emprstimo bancrio modelado como uma entidade. Uma alternativa modelar o emprstimo no como uma entidade, mas como um relacionamento entre clientes e agncias, com nmero_emprstimo e conta como atributos descritivos. Cada emprstimo representado por um relacionamento entre um cliente e uma agncia. Se todo emprstimo tomado por exatamente um cliente e est associado a exatamente uma agncia, podemos resolver o projeto de modo satisfatrio caso o emprstimo seja representado como relacionamento. Entretanto, com um projeto assim, no poderemos representar convenientemente uma situao na qual vrios clientes tomam um emprstimo conjunto. Precisaremos definir um relacionamento em separado para cada componente de um emprstimo conjunto. Ento, precisaremos replicar os valores dos atributos descritivos, nmero_emprstimo e conta, para cada um dos relacionamentos. Dois problemas so consequncia dessa 91

replicao: (1) os dados so armazenados diversas vezes, desperdiando espao em memria; e (2) as atualizaes deixam, potencialmente, os dados em um estado inconsistente, quando os valores diferem nos atributos de dois relacionamentos que deveriam, supostamente, possuir valores iguais. O meio pelo qual se evitam tais replicaes aplicado formalmente pela teoria da normalizao. Uma linha mestra possvel na opo pelo uso de um conjunto de entidades ou pelo uso de um conjunto de relacionamentos recorrer ao conjunto de relacionamentos para descrever uma ao que ocorre entre entidades. Essa abordagem pode ser til tambm para decidir se certos atributos podem ser expressos de maneira mais apropriada como relacionamentos. Conjunto de relacionamentos Binrios versus n-simos sempre possvel recompor um conjunto de relacionamentos no-binrios (n-simos, com n>2) por um nmero de conjuntos de relacionamentos binrios distintos. Para simplificar, considere o conjunto de relacionamento ternrio (n=3) abstrato R, relacionados aos conjuntos de entidades A, B e C. Poderemos recompor o conjunto R em um conjunto de entidades E, e criar trs conjuntos de relacionamentos: RA, relacionando E e A RB, relacionando E e B RC, relacionando E e C Se o conjunto de relacionamentos R possui quaisquer atributos, estes so designados pelo conjunto de entidades E (j que todo o conjunto de entidades deve ter ao menos um atributo para distinguir seus membros). Para cada relacionamento (ai, bi, ci) do conjunto de relacionamentos R, podemos criar uma nova entidade ei no conjunto de entidades E. Ento, em cada um dos trs novos conjuntos de relacionamentos, inserimos um relacionamento, como segue: (ei, ai) em RA (ei, bi) em RA (ei, ci) em RA Podemos generalizar esse processo de modo direto para os conjuntos de relacionamentos n-simo. Assim, conceitualmente podemos restringir o modelo E-R para conter apenas conjuntos de relacionamentos binrios. Entretanto, essa restrio nem sempre desejvel. Pode ser que seja necessria a criao de um atributo de identificao para o conjunto de entidades criado para substituir o conjunto de relacionamentos. Este atributo, juntamente com o conjunto extra de relacionamentos criados, aumenta a complexidade do projeto e as necessidades de armazenamento como um todo. Um conjunto de relacionamentos n-simo mostra claramente todos os conjuntos de entidades que participam de uma determinada relao. O projeto correspondente, usando somente conjunto de relacionamentos binrios, torna mais difcil estabelecer as restries dessa participao. Mapeamento de Restries O esquema E-R de uma empresa pode definir certas restries, as quais o contedo do banco de dados deve respeitar. Mapeamento das Cardinalidades O mapeamento das cardinalidades, ou rateio de cardinalidades, expressa o nmero de entidades s quais outra entidade pode estar associada via um conjunto de relacionamentos. O mapeamento de cardinalidades mais til na descrio dos conjuntos de relacionamentos binrios, embora, ocasionalmente, possam contribuir para a descrio de conjuntos de relacionamentos que envolvam mais de dois conjuntos de entidades. 92

Para um conjunto de relacionamentos R binrio entre os conjuntos de entidades A e B, o mapeamento das cardinalidades deve seguir uma das instrues abaixo: Um para um. Uma entidade em A est associada no mximo a uma entidade em B, e uma entidade em B est associada a no mximo uma entidade em A (fig. 2.4a). Um para muitos. Uma entidade em A est associada a vrias entidades em B. Uma entidade em B, entretanto, pode estar associada a qualquer nmero de entidades em B e uma entidade em B est associada a um nmero qualquer de entidades em A (fig. 2.5a).

O mapeamento apropriado de cardinalidades para um conjunto de relacionamentos em particular , obviamente, dependente das situaes reais que esto sendo modeladas pelo conjunto de relacionamentos. Como ilustrao, considere o conjunto de relacionamentos devedor. Se, em um banco em particular, um emprstimo pode se destinar a apenas um cliente e um cliente pode contrair diversos emprstimos, ento o conjunto de relacionamentos entre cliente e emprstimo de um para muitos. Esse tipo de relacionamento apresentado na fig. 2.3. Se um emprstimo puder ser tomado por mais de um cliente (como normalmente acontece com os vrios scios de um negcio), o relacionamento seria de muitos para muitos.

O rateio de cardinalidades de um relacionamento pode afetar a colocao dos atributos nos relacionamentos. Atributos em conjuntos de relacionamentos um para um ou um para muitos deve ser associados a um dos conjuntos de entidades participantes, em vez de serem associados ao conjunto de relacionamentos. Por exemplo, consideremos depositante como um conjunto de relacionamentos um para muitos, tal que um cliente pode possuir diversas contas, mas cada conta est vinculada a apenas um cliente. Nesse caso, o atributo data_acesso poderia estar associado ao conjunto de entidades conta, como mostrados na 93

fig. 2.6; de modo a tornar a figura mais clara, so apresentados apenas alguns dos atributos dos dois conjuntos de entidades. J que cada entidade conta participa de um relacionamento com no mximo uma instncia de cliente, fazer esta designao de atributo pode ter o mesmo significado que colocar data_acesso no conjunto de relacionamentos depositante. Atributos de conjuntos de relacionamentos um para muitos podem apenas ser reposicionados no conjunto de entidades do lado muitos desse relacionamento. Em conjuntos de relacionamentos um para um, o atributo do relacionamento pode ser associado a qualquer uma das entidades participantes.

As decises de projeto, como decidir onde colocar atributos descritivos como um atributo de entidade ou relacionamento devem refletir as caractersticas da empresa que est sendo modelada. O projetista pode optar por manter data_acesso como um atributo de depositante para explicitar que um acesso ocorreu em uma interao entre os conjuntos de entidades cliente e conta. A escolha de onde colocar um atributo mais clara quando se trata de conjuntos de relacionamentos muitos para muitos. Retornando ao exemplo, especifiquemos o que talvez seja um dos mais realsticos casos de conjuntos de relacionamentos muitos para muitos, depositante, que expressa que um cliente pode ter uma ou mais contas e que uma conta pode estar vinculada a um ou mais clientes. Se quisermos expressar a data do ltimo acesso de um cliente a uma dada conta, o atributo data_acesso dever ser atribudo ao conjunto de relacionamentos depositante, em vez de ser alocado a uma das duas entidades participantes. Se data_acesso fosse atributo de conta, no poderamos determinar qual dos clientes responsvel pelo acesso mais recente conta em questo. Quando um atributo determinado pela combinao dos conjuntos de entidades participantes em vez de estar associado a cada uma das entidades, separadamente, esse atributo precisa ser associado ao conjunto de relacionamentos muitos para muitos. A colocao de data_acesso como atributo do conjunto de relacionamentos mostrada na fig. 2.7; novamente, para tornar a figura mais simples, so apresentados apenas alguns dos atributos dos dois conjuntos de entidades.

94

Dependncia de Existncia Outra classe importante de restries a dependncia de existncia. Especificamente, se a existncia da entidade x depende da existncia da entidade y, ento x dito dependente da existncia de y. Operacionalmente, se y for excludo, o mesmo deve acontecer com x. A entidade y chamada entidade dominante e a x chamada entidade subordinada. Como ilustrao, considere o conjunto de entidades emprstimo e o conjunto de entidades pagamento, que mantm todas as informaes dos pagamentos realizados para um determinado emprstimo. O conjunto de entidades pagamento descrito pelos atributos nmero_pagamento, data_pagamento e total_pagamento. Criamos um conjunto de relacionamentos pagamento_emprstimo entre esses dois conjuntos de entidades pagamento descrito pelos atributos nmero_pagamento, data_pagamento e total_pagamento. Criamos um conjunto de relacionamentos pagamento_emprstimo entre estes dois conjuntos de entidade que de um para muitos do emprstimo para o pagamento. Toda entidade pagamento est associada a uma entidade emprstimo. Se uma entidade emprstimo excluda, ento todas as entidades pagamento a ela associadas devero ser excludas tambm. Em contraste, uma entidade pagamento pode ser excluda do banco de dados sem afetar em nada qualquer emprstimo. O conjunto de entidades emprstimo, portanto, dominante e pagamento subordinado ao conjunto de relacionamentos pagamento_emprstimo. A participao de um conjunto de entidades E no conjunto de relacionamentos R dita total se todas as entidades em E participam de pelo menos um relacionamento R. Se somente algumas entidades em E participam do relacionamento R, a participao do conjunto de entidades em E participam do relacionamento R, a participao do conjunto de entidades E no relacionamento R dito parcial. A participao total est estreitamente relacionada existncia de dependncia. Por exemplo, desde que toda entidade pagamento esteja associada a alguma entidade emprstimo pelo relacionamento pagamento_emprstimo, a participao de pagamento no conjunto de relacionamentos pagamento_emprstimo total. Por outro lado, um indivduo pode ser cliente de um banco, tendo ou no contrado um emprstimo nele. Da, possvel que apenas parte do conjunto de entidades cliente esteja relacionada ao conjunto de entidades emprstimo e a participao de cliente no conjunto de relacionamentos devedor , portanto, parcial. Chaves

95

 importante especificar como as entidades dentro de um dado conjunto de entidades e os relacionamentos dentro de um conjunto de relacionamentos podem ser identificados. Conceitualmente, entidades e relacionamentos individuais so distintos, entretanto, na perspectiva do banco de dados, a diferena entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chave permite-nos fazer tais distines. Conjunto de Entidades Uma superchave um conjunto de um ou mais atributos que, tomados coletivamente, nos permitem identificar de maneira unvoca uma entidade em um conjunto de entidades. Por exemplo, o atributo seguro_social do conjunto de entidades cliente suficiente para distinguir uma entidade cliente de outra. Assim, o seguro_social uma superchave. Do mesmo modo, a combinao de nome_cliente e seguro_social superchave para o conjunto de entidades cliente. O atributo nome_cliente no superchave de cliente, pois algumas pessoas podem ter o mesmo nome. O conceito de superchave no suficiente para nossos propsitos, j que, como vimos, uma superchave pode conter atributos externos. Se K uma superchave, entoa qualquer superconjunto de K. Nosso interesse por superchaves para as quais nenhum subconjunto possa ser uma superchave. Essas superchaves so chamadas chaves candidatas. possvel que vrios conjuntos diferentes de atributos possam servir como superchave. Suponha que uma combinao de nome_cliente e rua_cliente seja suficiente para distinguir todos os membros do conjunto de entidades cliente. Ento, (seguro_social) e (nome_cliente, rua_cliente) so chaves candidatas. Embora os atributos seguro_social e nome_cliente, juntos, possam distinguir as entidades cliente, sua combinao no forma uma chave candidata, uma vez que seguro_social, sozinho, uma chave candidata. Chaves candidatas precisam ser escolhidas com cuidado. Como notamos, obviamente o nome de uma pessoa no suficiente, j que homnimos so possveis. Nos Estados Unidos, o nmero de seguro_social pode ser uma chave candidata. Em outros pases onde os habitantes normalmente no possuem nmero de seguro social, as empresas podem gerar seu prprio nmero de identificao, como nmero do cliente ou nmero de identificao de estudantes ou nmero de identificao, como nmero do cliente ou nmero de identificao de estudantes ou qualquer outra combinao nica de outros atributos como chave. Uma das combinaes mais frequentemente usadas o nome, data de nascimento e endereo, j que extremamente difcil que mais de uma pessoa tenha os mesmos valores para todos esses atributos. Podemos usar o termo chave primria para caracterizar a chave candidata que escolhida pelo projetista do banco de dados como de significado principal para a identificao de entidades dentro de um conjunto de entidades. Uma chave (primria, candidata e super) duas entidades individuais em um conjunto no podem ter, simultaneamente, mesmos valores em seus atributos-chave. A especificao de uma chave representa uma restrio ao mundo real da empresa que est sendo modelada. Conjuntos de Relacionamentos A chave primria de um conjunto de entidades permite-nos distinguir as vrias entidades de um conjunto. Precisamos, de modo similar, de um mecanismo para a identificao dos vrios relacionamentos em um conjunto de relacionamentos. Seja R um conjunto de relacionamentos envolvendo os conjuntos de entidades E1, E2, ..., En. Seja uma chave_primria (Ei) denotando o conjunto de atributos que formam a chave primrias sejam nicos (se no forem, use um esquema apropriado para rebatiz-los). A composio da chave primria para um conjunto de relacionamentos depende de uma estrutura de atributos associada ao conjunto de relacionamentos R. Se o relacionamento R no possui atributo, ento o conjunto de atributos: descreve um relacionamento individual do conjunto R. Se o conjunto de relacionamento r possui os atributos a1, a2, ..., an a ele associados, ento o conjunto de atributos: 96

descreve um relacionamento em particular do conjunto R. Em ambos os casos acima, o conjunto de atributos: forma uma superchave do conjunto de relacionamentos. A estrutura da chave primria para o conjunto de relacionamentos depende do mapeamento da cardinalidade do conjunto de relacionamentos. Como ilustrao, considere o conjunto de entidades cliente e empregado e um conjunto de relacionamentos cliente_bancrio que representa a associao entre um cliente e um bancrio (uma entidade empregado). Suponha que um conjunto de relacionamentos seja de muitos para muitos, suponha tambm que o conjunto de relacionamentos possui o atributo tipo a ele associado, representando a natureza do relacionamento (como um agente de emprstimo ou como um atendente pessoal). A chave primria cliente_bancrio constitui-se da unio das chaves primrias de cliente e empregado. Entretanto, se um cliente pode ser atendido exclusivamente por um bancrio isto , se um relacionamento cliente_bancrio muitos para um ento, a chave primria de cliente_bancrio simplesmente a chave primria de cliente. Para relacionamentos um para um, qualquer uma das chaves primrias pode ser usada. A designao de chaves primrias mais complicada para relacionamentos no-binrios. Diagrama Entidade-Relacionamento Toda estrutura lgica do banco de dados pode ser expressa graficamente pelo diagrama E-R. A relativa simplicidade e clareza desta tcnica de diagramao pode explicar, em grande parte, a ampla disseminao do uso do modelo E-R. A seguir so apresentados seus principais componentes: Retngulos, que representam os conjuntos de entidades. Elipses, que representam os atributos. Losangos, que representam os conjuntos de relacionamentos. Linhas, que unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de relacionamentos. Elipses duplas, que representam atributos multivalorados. Linhas duplas, que indicam a participao total de uma entidade em um conjunto de relacionamentos. Como mostrado na fig. 2.8, os atributos de um conjunto de entidades que so membros de uma chave primria devem ser sublinhados. Considere o diagrama entidade-relacionamento da fig. 2.8, que consiste de dois conjuntos de entidades, cliente e emprstimo, relacionados pelo conjunto de relacionamentos devedor. Os atributos associados a cliente so nome_cliente, seguro_social, rua_cliente e cidade_cliente. Os atributos associados a emprstimo so nmero_emprstimo e total. O conjunto de relacionamentos devedor pode ser muitos para muitos, um para um, muitos para um ou um para um. Para fazer a distino entre esses tipos, desenhamos uma linha direcionada ( ) ou uma linha sem direcionamento (-) entre o conjunto de relacionamentos e o conjunto de entidades em questo. Uma linha direcionada do conjunto de relacionamentos devedor para o conjunto de entidades emprstimo especifica que devedor um conjunto de relacionamentos um para um ou muitos para um, de cliente para emprstimo; devedor no pode ser um conjunto de relacionamentos muitos para muitos ou um para muitos, de cliente para emprstimo. Uma linha no direcionada do conjunto de relacionamentos devedor para o conjunto de entidades emprstimo especifica que devedor um conjunto de relacionamentos muitos para muitos ou um para muitos, de cliente para emprstimo.

97

Voltando ao diagrama E-R da fig. 2.8, podemos ver que o conjunto de relacionamentos devedor muitos para muitos. Se o conjunto de relacionamentos dever for um para muitos, de cliente para emprstimo, ento a linha de devedor para cliente deveria ser direta, com a seta apontando para o conjunto de entidades cliente (fig. 2.9a). Similarmente, se o conjunto de relacionamentos devedor for muitos para um, de cliente para emprstimo, ento a linha de devedor para emprstimo deveria ser uma seta pontando para o conjunto de entidades emprstimo (fig. 2.9b). Finalmente, se o conjunto de relacionamentos devedor for um para um, ento ambas as linhas de devedor deveriam ser setas: uma apontando para o conjunto de entidades emprstimo e outra apontando para o conjunto de entidades clientes (fig. 2.10). Se um conjunto de relacionamentos tambm tem atributos a ele relacionados, ento deveremos fazer a ligao desses atributos com o conjunto de relacionamentos. Por exemplo, na fig. 2.11, temos o atributo descrito data_acesso atrelado ao conjunto de relacionamentos depositante para especificar a data mais recente de acesso do cliente conta. Indicamos os papeis desempenhados no diagrama E-R por meio da denominao nas linhas que ligam os losangos aos retngulos. A fig. 2.12 mostra os papeis desempenhados, gerente e empregado, entre o conjunto de entidades empregado e o conjunto de relacionamentos trabalha_para. Conjuntos de relacionamentos no-binrios podem ser facilmente especificados no diagrama E-R. A fig. 2.13 apresenta trs conjuntos de entidades, cliente, emprstimo e agncia, interligados pelo conjunto de relacionamentos CEA. Esse diagrama especifica que um cliente pode contrair diversos emprstimos e que um emprstimo pode pertencer a diferentes clientes. Esse diagrama especifica que um cliente pode contrair diversos emprstimos e que um emprstimo pode pertencer a diferentes clientes. A seguir, vemos uma seta apontando para agncia indicando que cada par emprstimo-cliente est associado a uma agncia bancria especfica. Se o diagrama tem uma seta apontando para cliente e outra apontando para agncia, o diagrama especificaria que cada emprstimo est associado a um cliente especfico de uma determinada agncia bancria.

98

99

Conjunto de Entidades Fracas Um conjunto de entidades pode no ter atributos suficientes para formar uma chave primria. Esse tipo de conjunto de entidades denominado conjunto de entidades fracas. Um conjunto de entidades que tem uma chave primria chamado um conjunto de entidades fortes. Como ilustrao, considere o conjunto de entidades pagamento, com trs atributos: nmero_pagamento, data_pagamento e total_pagamento. Embora cada 100

entidade pagamento seja distinta, os pagamentos de emprstimos no tem uma chave primria; este um conjunto de entidades fracas. Para um conjunto de entidades fracas ser significativo, ele deve fazer parte de um conjunto de relacionamentos um para muitos. Esse conjunto de relacionamentos no deve ter nenhum atributo significativo, j que qualquer atributo exigido pelo conjunto de relacionamentos no deve ter nenhum atributo significativo, j que qualquer atributo exigido pelo conjunto de relacionamentos pode ser associado ao conjunto de entidades fracas. Os conceitos de conjuntos de entidades fortes e fracas no possuir chave primria, precisamos, todavia, de um significado para a distino entre todas aquelas entidades em um conjunto de entidades que dependem de uma entidade forte em particular. O identificador de um conjunto de entidades fracas um conjunto de atributos que permite que essa distino seja feita. Por exemplo, o identificador do conjunto de entidades fracas pagamento o atributo nmero_pagamento, assim, para cada emprstimo, um nmero de pagamento identifica um determinado pagamento para aquele emprstimo. O identificador de um conjunto de entidades fracas tambm chamado de chave parcial de um conjunto de entidades fracas tambm de chave parcial de um conjunto de entidades. A chave primaria de um conjunto de entidades fracas formado pela chave primria, precisamos, todavia, de um significado para a distino entre todas aquelas entidades fortes ao qual a existncia do conjunto de entidades fracas est vinculada mais o identificador do conjunto de entidades fracas. No caso do conjunto de entidades pagamento, sua chave primria {nmero_emprstimo, nmero_pagamento}, em que nmero_emprstimo identifica a entidade dominante pagamento e nmero_pagamento identifica a entidade pagamento dentro de determinado emprstimo. O conjunto de entidades dominantes de identificao dito proprietrio do conjunto de entidades fracas por ele identificada. O relacionamento que associa o conjunto de entidades fracas a seu proprietrio o relacionamento identificador. Em nosso exemplo, pagamento_emprstimo o relacionamento identificador de pagamento. Um conjunto de entidades fracas identificado no diagrama E-R pela linha dupla usada no retngulo e no losango do relacionamento correspondente. Na fig. 2.14, o conjunto de entidades fracas pagamento dependente do conjunto de entidades fortes emprstimo pelo conjunto de relacionamentos pagamento_emprstimo. A figura tambm apresenta o uso de linhas duplas para identificar participao total a participao do conjunto de entidades (fracas) pagamento no relacionamento pagamento_emprstimo total, significando que todo pagamento precisa estar relacionado via pagamento_emprstimo a alguma conta. Finalmente, a seta de pagamento_emprestimo para emprstimo indica que cada pagamento para um nico emprstimo. O identificador de um conjunto de entidades fracas. Mesmo que um conjunto de entidades fracas tenha sempre sua existncia dependente de uma entidade dominante, a dependncia de existncia no resulta, necessariamente, em um conjunto de entidades fracas; isto , o conjunto de entidades subordinadas pode ter uma chave primria.

101

Em alguns casos, o projetista do banco de dados pode optar por expressar um conjunto de entidades fracas como um atributo composto multivalorado do conjunto de entidades proprietrio. Em nosso exemplo, essa alternativa exigiria que o conjunto de entidades emprstimo tivesse um atributo composto multivalorado pagamento, consistindo de nmero_pagamento, data_pagamento e total_pagamento. Um conjunto de entidades fracas pode ser modelado de forma mais apropriada, como um atributo, se ele apenas participar da identificao do relacionamento e ele tiver poucos atributos. Por outro lado, ser mais conveniente optar por um conjunto de entidades fracas quando os conjuntos participantes no relacionamento no constiturem o relacionamento identificador e quando o conjunto de entidades fracas possuir diversos atributos. Recursos de Extenso do E-R Apesar de ser possvel modelar a maioria dos banco de dados apenas com os conceitos bsicos do E-R, alguns aspectos de um banco de dados podem ser expressos de modo mais conveniente por meio de algumas extenses do modelo bsico do E-R. Especializao Um conjunto de entidades pode conter subgrupos de entidades que so, de alguma forma, diferentes de outras entidades do conjunto. Por exemplo, um subconjunto de entidades dentro de um conjunto de entidades pode possuir atributos que no so compartilhados pelas demais entidades do conjunto. O modelo E-R proporciona um significado para a representao desses agrupamentos distintos entre as entidades. Considere o conjunto de entidades conta com os atributos nmero_conta e saldo. Um saldo futuramente classificado como um dos seguintes grupos: conta_poupana conta_movimento Cada um desses tipos de contas descrito como um conjunto de atributos que, alm de todos os atributos do conjunto de entidades conta, possui outros atributos adicionais. Por exemplo, as entidades conta_poupana podem ser descritas pelo atributo taxa_juros, enquanto as entidades conta_movimento podero possuir o limite_cheque_especial. O processo de especializao de conta permite-nos distinguir os tipos de contas. Um conjunto de entidades pode ser especializado por mais de uma caracterstica de diferenciao. Em nosso exemplo, a distino entre as entidades conta seu tipo. Em nosso exemplo, a distino entre as entidades conta seu tipo. Outra especializao coexistente poderia ser estabelecida entre os cheques especiais, resultando nos conjuntos de entidades pessoa_fsica e pessoa_juridica. Quando mais de um tipo de especializao formado em um conjunto de entidades, uma entidade em particular pode pertencer a pessoa_fisica e conta_movimento. Podemos aplicar o agrupamento por especializao, repetidamente, para refinar o esquema que est sendo projetado. Por exemplo, um banco pode oferecer os trs tipos de conta movimento: 1. Conta movimento padro com taxa de trs dlares mensais e 25 folhas de cheques por ms gratuitas. Para essas contas, o banco emite o extrato bancrio mensal com os nmeros dos cheques. 2. Conta movimento especial que exige um saldo mnimo de mil dlares, pagando 2% em juros, e sem limites na emisso de cheques. Neste caso, o banco monitora o saldo mnimo e os juros mensais pagos. 3. Conta movimento snior para clientes com idade superior a 65 anos que no pagam taxa de servios e permite uso ilimitado de cheques, sem custo. Um registro sobre a data de aniversario do cliente associado a esse tipo de conta. A especializao da conta_movimento pelo tipo de conta cria os seguintes conjuntos de entidades: 1. Padro, com o atributo nmero_cheque. 2. Especial, com o atributo saldo_mnimo e taxa_juros. 3. Snior, com o atributo data_aniversrio. 102

Em termos de diagrama E-R, a especializao representada pelo tringulo rotulado de ISA, como demonstrado na fig. 2.15. Este rtulo-padro ISA indica que, por exemplo, uma conta poupana uma conta. Este relacionamento ISA pode ser tambm entendido como um relacionamento de super ou subclasse. Os conjuntos de entidades em nvel superior e inferior so representados do mesmo modo que os conjuntos de entidades regulares, ou seja, por um retngulo contendo o nome do conjunto de entidades.

Generalizao O refinamento do conjunto de entidades em nveis sucessivos de subgrupos indica um processo top-down de projeto, no qual as diferenciaes so feitas de modo explcito. O projeto pode ser realizado de modo bottomup, no qual vrios conjuntos de entidades so sintetizados em um conjunto de entidades em alto nvel, com base em atributos comuns. O projetista do banco de dados poderia identificar, em uma primeira modelagem, o conjunto de entidades conta_padro com os atributos nmero_conta, saldo e saldo_negativo e o conjunto de entidades conta_poupanca com os atributos nmero_conta, saldo e taxa_juros. Existem similaridades entre o conjunto de entidades conta_movimento e o conjunto de entidades conta_poupana, j que possuem atributos comuns. Esse compartilhamento de atributos pode ser expresso pela generalizao, que exprime o relacionamento existente entre os conjuntos de entidades de nvel superior e um ou mais conjuntos de entidades de nvel inferior. E no nosso exemplo, conta um conjunto de entidades de nvel superior e conta_poupana e conta)movimento so conjuntos de entidades de nvel inferior. Conjuntos de entidades superiores e inferiores podem tambm ser designados em termos de super e subclasses, respectivamente. O conjunto de entidades conta uma superclasse de conta_poupanca e conta_movimento so subclasses. Na prtica, a generalizao simplesmente o inverso da especializao. Aplicaremos ambos os processos, combinados, ao longo do projeto do esquema E-R de uma empresa. Em termos do diagrama E-R propriamente 103

dito, no faremos distino entre a especializao e a generalizao. Novos nveis de representao de entidades sero diferenciadas (especializao) ou sintetizadas (generalizao) de modo que o esquema possa expressar totalmente a aplicao do banco de dados e atender s necessidades de seus usurios. As diferenas das duas abordagens podem ser caracterizadas pelo ponto de partida e seus objetivos gerais. A especializao parte de um nico conjunto de entidades; ela enfatiza as diferenas entre as entidades pertencentes ao conjunto por meio do estabelecimento das diferenas expressas nos conjuntos de entidades de nvel inferior. Estes conjuntos de entidades de nvel inferior podem possuir atributos, ou mesmo participar de relacionamentos que no podem ser aplicados a todas as entidades do conjunto de entidades de nvel superior. De fato, o projetista usa especializao justamente para representar tais distines. Se conta_poupana e conta_movimento no possuem atributos nicos; no h necessidade de especializar o conjunto de entidades conta. O uso da generalizao procede para o reconhecimento de um nmero de conjunto de entidades que compartilham caractersticas comuns (so descritos pelos mesmos atributos e participam dos mesmos conjuntos de relacionamentos). Com base nessas caractersticas comuns, a generalizao sintetiza esses conjuntos de entidades de nvel superior. A generalizao suada para enfatizar as similaridades entre os conjuntos de entidades de nvel inferior, omitindo suas diferenas; isso permite tambm uma representao mais econmica, evitando repeties de atributos compartilhados. Herana de Atributos Uma propriedade decisiva das entidades de nveis superior e inferior criadas pela especializao e pela generalizao a herana de atributos. Os atributos dos conjuntos de entidades de nvel superior so herdados pelos conjuntos de entidade de nvel inferior. Por exemplo, conta_poupana e conta_movimento herdam os atributos de conta. Assim, conta_poupana identificado por seus atributos nmero_conta, saldo e taxa_juros; conta_movimento identificado por seus atributos nmero_conta, saldo e limite_cheque_especial. Os conjuntos de entidade de nvel inferior (ou subclasses) tambm herdam a participao em conjuntos de relacionamentos dos quais participam seus conjuntos de entidades de nvel superior(ou superclasse). Tanto que o conjunto de entidades conta_poupana e conta_movimento participam do conjunto de relacionamentos depositante. Os conjuntos de entidades padro, especial e snior de nvel inferior herdam os atributos e a participao nos relacionamentos de conta_movimento e conta. Se uma dada poro do modelo E-R chegou especializao ou generalizao, os resultados so basicamente os mesmos: Conjuntos de entidades de nvel superior com atributos e relacionamentos que so aplicados a todos os seus conjuntos de entidades de nvel inferior. Conjunto de entidades de nvel inferior com caractersticas distintas que so apenas aplicadas a um conjunto de entidades de nvel inferior em particular. Como se percebe, embora frequentemente nos refiramos apenas generalizao, as propriedades que discutimos pertencem totalmente a ambos os processos. A fig. 2.15 apresenta uma hierarquia nos conjuntos de entidades. Na figura, conta_movimento um conjunto de entidades de nvel superior aos conjuntos de entidades padro, especial e snior. Hierarquicamente, um dado conjunto de entidades somente poder ser envolvido, como um conjunto de entidades de nvel inferior, por meio de um relacionamento ISA. Se um conjunto de entidades um conjunto de entidades de nvel inferior em mais de um relacionamento ISA, a estrutura resultante chamada reticulada. Restries de Projeto Para modelagem mais apurada de uma empresa, o projetista do banco de dados pode optar por definir algumas restries em uma generalizao em particular. Um tipo de restrio envolve a determinao das

104

entidades que podem participar de um dado conjunto de entidades de nvel inferior. Tais escolhas podem ser uma das seguintes: Definida por condio. Um conjunto de entidades de nvel inferior definido por condio selecionado com base na satisfao ou no de condies ou predicados preestabelecidos. Por exemplo, considere que o conjunto de entidades de nvel superior conta possui o atributo tipo_conta. Todas as entidades conta evoluem para um dos atributos tipo_conta. Somente aquelas entidades que satisfaam a condio tipo_conta = conta_poupana, podem pertencer ao conjunto de entidades de nvel inferior conta_poupana. Todas as entidades que satisfaam a condio tipo_conta = conta_movimento so includas em conta movimento. Desde que todas as entidades de nvel inferior sejam classificadas com base nos mesmos atributos (neste caso, tipo_conta), esse tipo de generalizao chamado definida_por_atributo. Definida pelo usurio. Um conjunto de entidades de baixo nvel definido pelo usurio no tem seus membros classificados por uma condio; as entidades so designadas a um determinado conjunto de entidades por usurios do banco de dados. Por exemplo, suponhamos que, depois de trs meses de trabalho, os empregados do banco sejam convocados para compor um dentre os quatro grupo de trabalho existentes. Esses grupos so representados por quatro conjuntos de entidades de baixo nvel, derivados do conjunto de entidades de alto nvel empregado. A escolha de um determinado empregado para participar de um conjunto de entidades de um grupo especfico no originada automaticamente pela definio de uma condio explcita. Pelo contrrio, a escolha para compor determinado grupo feita por critrios individuais, pesando na deciso a opinio do usurio, e sua implementao feita por uma operao que adiciona a entidade ao conjunto de entidades. O segundo tipo de restrio determina se uma entidade pode ou no pertencer a mais de um conjunto de entidades de nvel inferior dentro de uma generalizao simples. Os conjuntos de entidades de nvel inferior podem ser um dos seguintes: Manuteno exclusivos. Restries mutuamente exclusivas exigem que uma entidade pertena a apenas um conjunto de entidades de nvel inferior. Em nosso exemplo, uma entidade conta pode satisfazer a apenas uma condio para o atributo tipo_conta; uma entidade pode ser tanto uma conta poupana como uma conta movimento, mas nunca ambas. Sobrepostos. Em generalizaes sobrepostas, uma mesma entidade pode pertencer a mais de um conjunto de entidades de nvel inferior dentro de uma generalizao simples. Para ilustrao, retornemos ao exemplo dos grupos de trabalho dos empregados do banco e suponhamos que determinados gerentes participem de mais de um desses grupos. Um determinado empregado pode, portanto, pertencer a mais de um conjunto de entidades formadas pelos grupos de trabalho. Conjuntos de entidades de nvel inferior com sobreposio o caso-padro; restries mutuamente exclusivas devem ser apresentadas explicitamente em uma generalizao (ou especializao). Uma restrio final, a restrio de totalidade em uma generalizao, determina se uma entidade de nvel superior pertence ou no a, no mnimo, um dos conjuntos de entidades de nvel inferior dentro da generalizao. Essa restrio pode ser uma das seguintes: Total. Cada entidade do conjunto de entidades de nvel superior deve pertencer a um conjunto de entidades de nvel inferior. Parcial. Qualquer entidade de nvel superior pode pertencer a qualquer um dos conjuntos de entidades de nvel inferior. A generalizao conta total: todas as entidades contas devem ser contas de poupana ou contas movimento. Como os conjuntos de entidades de alto nvel de uma generalizao so, geralmente, compostos somente pelas entidades de nvel inferior. O conjunto de entidades dos grupos de trabalho ilustram uma especializao parcial. 105

Desde que os empregados participem de um dos grupos somente aps trs meses de trabalho, algumas entidades empregados podem no ser membros de qualquer um dos conjuntos de entidades de grupos de nvel inferior. Podemos caracterizar os conjuntos de entidades de grupos de modo completo como especializao parcial e sobreposta de empregado. A generalizao conta_movimento e conta_poupana de conta total, generalizao mutuamente exclusiva. As restries de totalidade e de sobreposio, entretanto, ano so dependentes uma das outra. Os padres de generalizao podem ser parcial-mutuamente-exclusivas e totalsobrepostas. Podemos ver que certas exigncias para inseres e excluses seguem restries que so aplicadas a dadas generalizaes ou especializaes. Por exemplo, quando uma restrio total aplicada, uma entidade inserida em um conjunto de entidades de nvel superior dever ser inserida em pelo menos um de seus conjuntos de entidades de nvel inferior. Em restries definidas por condio, todas as entidades de nvel superior que satisfaam tal condio devem ser inseridas nos conjuntos de entidades de nvel inferior. Finalmente, uma entidade excluda de um conjunto de entidades de nvel superior tambm dever ser excluda de todos os conjuntos de entidades de nvel inferior s quais pertencem. Agregao Uma das limitaes do modelo E-R que no possvel expressar relacionamentos entre relacionamentos. Para ilustrar a necessidade desse tipo de construtor, consideremos novamente um banco de dados descrevendo informaes sobre clientes e seus emprstimos. Suponha que cada par emprstimo-cliente possui um bancrio, ou agente-emprstimo, responsvel pelo acompanhamento de determinado emprstimo. Usando os construtores do modelo E-R bsico, obteramos o diagrama apresentado na fig. 2.16. Nota-se que o conjunto de relacionamentos devedor e agente_emprstimo poderia ser combinado em um nico conjunto de relacionamentos. No entanto, no podemos faz-lo, porque isso tornaria obscura a estrutura lgica desse esquema. Por exemplo, se combinarmos os conjuntos de relacionamentos devedor e agente_emprestimo, essa combinao deveria especificar que um agente-emprstimo especfico responsvel por uma par emprstimocliente, o que no ocorre. A separao em dois conjuntos de relacionamentos distintos resolve esse problema. Entretanto, existe redundncia de informaes na figura resultante, uma vez que todo par emprstimocliente em agente_emprstimo est tambm em devedor. Se o agente_emprstimo fosse um valor, em vez de uma entidade de empregado, poderamos fazer de agente_emprstimo um atributo multivalorado do relacionamento devedor. Mas, assim, seria ainda mais difcil (nos custos de lgica e execuo) encontrar, por exemplo, o par emprstimo-cliente pelo qual determinado bancrio responsvel. J que um agente de emprstimo uma entidade empregado, essa alternativa descartada em qualquer caso.

106

O melhor modo de modelar a situao acima descrita usando a agregao. Agregao a abstrao por meio da qual os relacionamentos so tratados como entidades de nvel superior. Assim, em nosso exemplo, simbolizamos o conjunto de relacionamentos devedor e o conjunto de entidades cliente e emprstimo como um conjunto de entidades de nvel superior, chamado devedor. Como um conjunto de entidades, tratado da mesma forma que qualquer outro conjunto de entidades. A notao mais comum para a agregao mostrada na fig. 2.17.

107

Projeto de um Esquema de Banco de Dados E-R O modelo de dados E-R nos d uma flexibilidade substancial par ao projeto de um esquema de banco de dados na modelagem de determinada empresa. Vamos agora considerar quais as opes possveis para o projetista dentre o grande nmero de possibilidades. Algumas das possveis opes so: Optar pelo uso de um atributo ou de um conjunto de entidades para representao de um objeto. Se uma concepo real expressa de modo mais preciso por um conjunto de entidades ou por um conjunto de relacionamentos. Optar por um conjunto de relacionamentos ternrio ou por um par de relacionamento binrio. Se se deve usar um conjunto de entidades forte. Um conjunto de entidades forte e seus conjuntos de entidades fracas dependentes podem ser visto como um nico objeto do banco de dados, j que as entidades fracas tm sua existncia vinculada de uma entidade forte. Se o uso da generalizao apropriado. A generalizao, ou uma hierarquia de relacionamentos ISA, contribui para a modularidade, j que atributos comuns a conjuntos de entidades similares podem ser representados em apenas um local do diagrama E-R. Se o uso da agregao for apropriado, agregar grupos de uma parte do diagrama E-R em um conjunto de entidades simples, permitindo-nos tratar do conjunto de entidades agregadas como uma unidade simples, sem abordar os detalhes de suas estruturas internas. Podemos notar que um projetista de banco de dados necessidade de um bom entendimento da empresa que est sendo modelada para que possa tomar essas decises. Fases de Projeto 108

Um modelo de dados de alto nvel proporciona ao projetista uma base conceitual na qual se pode especificar, de modo sistemtico, quais as necessidades dos usurios do banco de dados e como este banco de dados ser estruturado para atender plenamente a todas estas necessidades. A fase inicial do projeto caracterizar todos os dados necessrios na perspectiva do usurio. O resultado dessa fase a especificao das necessidades do usurio (ou levantamento de requisitos). A seguir, o projetista escolhe o modelo de dados e, por meio da aplicao de seus conceitos, transcreve as necessidades especificadas em um esquema conceitual de banco de dados. O esquema desenvolvido nessa fase chamado projeto conceitual e proporcional uma viso detalhada da empresa. Como s estudamos o modelo E-R at agora, iremos us-lo para o desenvolvimento do esquema conceitual. Empregando os termos do modelo E-R, o esquema deve especificar todos os conjuntos de entidades, relacionamentos, atributos e o mapeamento das restries. O projetista rev o esquema para confirmar se todos os dados exigidos esto de fato representados e se no h conflitos entre eles. Ele dever tambm examinar o projeto para remover qualquer tipo de redundncia. Neste momento, seu enfoque descrever os dados e seus relacionamentos, em vez de especificar os detalhes fsicos de armazenamento. O desenvolvimento completo do esquema conceitual ir indicar tambm as necessidades funcionais da empresa. Na especificao das necessidades funcionais, os usurios descrevem os tipos de operaes (ou transaes) que sero realizados nos dados. Os exemplos dessas operaes incluem modificao para atualizao dos dados, pesquisa para recuperao de um determinado dado e remoo de dados. Dever ser feita, nesse estgio do projeto conceitual, uma reviso do esquema dos dados em funo das necessidades funcionais. O transporte do modelo de dados abstrato, para sua implementao, ocorre nas duas fases finais do projeto. Na fase de projeto lgico, o esquema conceitual de alto nvel mapeado para o modelo de implementao de dados do SGBD que ser usado. O esquema de dados resultante usado para a fase subsequente, que a do projeto fsico, especificamente dependente dos recursos do SGBD usado. Esses recursos incluem as formas de organizao de arquivos e estruturas internas de armazenamento. Vamos abordar somente os conceitos do modelo E-R como usados na fase do projeto do esquema conceitual. Dados Necessrios a uma Empresa da rea Bancria A especificao dos requisitos dos usurios pode ser apurada por meio de entrevistas unidas prpria avaliao do projetista sobre a empresa. A descrio resultante dessa fase do projeto a base para a especificao da estrutura conceitual do banco de dados. A lista de itens que se segue apresenta as principais necessidades de uma empresa da rea bancria. Um banco organizado em agncias. Cada agncia localizada em uma cidade e identificada por um nome nico. O banco controla os fundos de cada uma dessas agncias. Os clientes do banco so identificados pelo nmero do seu seguro social. O banco mantm dados como nome, rua, e cidade do cliente. Os clientes podem possuir contas e contrair emprstimos. O cliente pode estar associado a um bancrio especfico que cuida de seus negcios ou atua como um agente de emprstimos. Os empregados do banco tambm so identificados por meio do seu seguro social. A administrao do banco mantm o nome e o nmero do telefone de cada um de seus empregados, os nomes de seus dependentes e o nmero do seguro social de seu gerente. O banco tambm possui a data de contrata do empregado e, com isso, seu tempo de trabalho. O banco oferece dois tipos de contas contas poupana e contas movimento. As contas movimento podem possuir mais de um correntista, e um correntista pode possuir mais de uma conta. Cada conta possui um nico nmero. O banco controla o saldo de cada conta, assim como a data mais recente de acesso a essa conta. Por outro lado, cada conta poupana possui a taxa de juros associada, assim como so tambm registrados os excessos nos limites da conta movimento. 109

Um emprstimo originado em uma agncia em particular pode ter sido obtido por um ou mais clientes. Um emprstimo identificado por um nmero nico. Para cada emprstimo o banco mantm o montante emprestado, assim como os pagamentos das parcelas. Embora o nmero das parcelas de um emprstimos no identifique de modo nico um pagamento especfico dentre os muitos realizados no banco, o nmero da parcela identifica um pagamento especfico dentre os muitos realizados no banco, o nmero da parcela identifica um pagamento efetuado para um emprstimo em particular. A data e o montante so registrados no pagamento de cada parcela.

Em um banco real, poderia ser de interesse manter informaes sobre depsitos e retiradas tanto para as contas poupana quanto para as contas movimento, assim como se mantm informaes sobre o pagamento de parcelas dos emprstimos. Uma vez que a modelagem dos requisitos dos usurios nas necessidades descritas a pouco so semelhantes quelas feitas no incio, podemos optar por um exemplo de aplicao mais reduzido, no fazendo, em nosso modelo, o acompanhamento dos depsitos e das retiradas. Designao de Conjuntos de Entidades em Empresas Bancrias Nossa especificao dos requisitos de dados servem como base inicial para a construo de um esquema conceitual do banco de dados. Para as especificaes relacionadas, comeamos por identificar os conjuntos de dados e seus atributos. O conjunto de entidades agncia, com os atributos: nome_agncia, cidade_agncia, e fundos O conjunto de entidades cliente, com os atributos: nome_cliente, seguro_social, rua_cliente e cidade_cliente Com a possibilidade do atributo adicional nome_bancrio. O conjunto de entidades empregado, com os atributos: seguro_social_empregado, nome_empregado, nmero_telefone, salario e gerente. Recursos adicionais descritivos so os atributos multivalorados nome_dependentes, o atributo bsico data_incio e o atributo descritivo tempo_de_trabalho. Dois conjuntos de entidades contas conta_poupana e conta_movimento com os atributos comuns nmero_conta e saldo; tambm, conta_poupana possui o atributo taxa_de_juros e conta_movimento, o atributo limite_cheque_especial. O conjunto de entidades emprstimo, com os atributos: nmero_emprstimo, total e agncia_origem So possveis os seguintes atributos adicionais: pagamento_emprstimo, composto multivalorado; com os seguintes atributos componentes: nmero_pagamento, data_pagamento e total_pagamento Designao dos conjuntos de Relacionamentos de uma Empresa da rea Bancria Retornemos agora ao esquema do projeto descrito para especificar os seguintes conjuntos de relacionamentos e mapeamentos de cardinalidades: devedor, como conjunto de relacionamentos muitos para um que indica qual a agncia responsvel pelo emprstimo. pagamento_emprstimo, relacionamento um para muitos entre emprstimo e pagamento, que documento que um pagamento est sendo feito para um determinado emprstimo. depositante, com os atributos de relacionamento data_acesso, um conjunto de relacionamentos muitos para muitos entre cliente e conta, indicando que um cliente possui uma conta.

110

agente_cliente, com o atributo de relacionamento tipo, um conjunto de relacionamentos muitos para um expressando que um cliente pode ser atendido por determinado empregado do banco e que um empregado do banco pode atender a um ou mais clientes. trabalha_para, conjunto de relacionamentos entre entidades empregado que determina se se trata de gerente ou empregado; o mapeamento da cardinalidade expressa que um empregado trabalha para um gerente especfico e que um gerente supervisiona um ou mais empregados.

Note que trocamos o atributo nome_agente do conjunto de entidades cliente pelo conjunto de relacionamentos agente_cliente, e o atributo gerente do conjunto de entidades empregado pelo conjunto de relacionamentos trabalha_para. Optamos por manter o conjunto de entidades emprstimo. O conjunto de relacionamentos agncia_emprstimo e pagamento_emprstimo foi substitudo, respectivamente, pelos atributos agncia_origem e pagamento_emprstimo do conjunto de entidades emprstimo. Digrama E-R de uma Emprstimo de uma Empresa da rea Bancria Esquematizando, apresentamos agora o diagrama E-R completo para nosso exemplo de empresa da rea bancria. A fig. 2.18 mostra a representao de um modelo conceitual de um banco, expresso nos termos conceituais de E-R. O diagrama inclui os conjuntos de entidades, atributos, conjuntos de relacionamentos e o mapeamento das cardinalidades concludas durante o processo descrito anteriormente, e j refinado.

111

Reduo de um Esquema E-R a Tabelas Um banco de dados em conformidade com o esquema de banco de dados E-R pode ser representado por uma coleo de tabelas. Para cada conjunto de entidades e para cada relacionamentos, dentro de um banco de dados, existe uma tabela nica registrando o nome do conjunto de entidades ou relacionamentos correspondentes. Cada tabela possui vrias colunas, cada uma delas com um nico nome. Tanto o modelo E-R quanto o modelo relacional so abstratos, ou seja, representaes lgicas de empresas reais. Como esses dois modelos empregam princpios de projetos similares, podemos converte o projeto E-R em projeto relacional. Converter a representao de um banco de dados de um diagrama E-R para um formato de tabela a base para a derivao de um diagrama E-R de um projeto a partir de um banco de dados relacional. Embora existam importantes diferenas entre uma relao e uma tabela, informalmente, uma relao pode ser considerada uma tabela de valores. Representao Tabular dos Conjuntos de Entidades Fortes

112

Seja E um conjunto de entidades fortes descrito pelos atributos a1, a2, ..., an. Representamos essa entidade por uma tabela chamada E com n colunas distintas, cada uma delas correspondendo a um dos atributos de E. Cada linha da tabela corresponde a uma entidade do conjunto de entidades E. Como ilustrao, considere o conjunto de entidades emprstimo do diagrama E-R mostrado na fig. 2.8. Esse conjunto de entidades possui dois atributos: nmero_emprstimo e total. Representaremos esse conjunto de entidades pela tabela chamada emprstimo, com duas colunas, como mostra a fig. 2.19. A linha (L-17, 1000) da tabela emprstimo significa que o emprstimo de nmero L-17 de mil dlares. Podemos adicionar uma nova entidade ao banco de dados pela insero de uma linha na tabela. Tambm podemos excluir ou modificar as linhas.

Denotaremos como D1 o conjunto de todos os nmeros de emprstimos e D2 o conjunto de todos os saldos. Qualquer linha da tabela emprstimo deve consistir de uma 2-tupla (v1, v2), em que v1 um emprstimo (isto , v1 est no conjunto D1) e v2 um total (isto , v2 est no conjunto D2). No geral, a tabela emprstimo conter somente o subconjunto de todas as linhas possveis. Iremos nos referir ao conjunto de todas as linhas possveis de emprstimo como o produto cartesiano de D1 e D2, denotado por: D1xD2. No geral, se tivermos uma tabela com n colunas, denotaremos o produto cartesiano de D1, D2, ..., Dn por: Como outro exemplo, considere o conjunto de entidades cliente do diagrama E-R mostrado na fig. 2.8. Esse conjunto de entidades tem os atributos nome_cliente, seguro_social, rua_cliente e cidade_cliente. A tabela correspondente a cliente tem quatro colunas, como mostra a fig. 2.20.

Representao Tabular dos Conjuntos de Entidades Fracas Seja A um conjunto de entidades fracas com os atributos a1, a2, ..., an. Seja B um conjunto de entidades fortes, do qual A dependente. Seja a chave primria de B composta pelos atributos b1, b2, ..., bn. Representamos o conjunto de entidades A pela tabela chamada A com uma coluna para cada um dos atributos do conjunto: 113

Como ilustrao, considere o conjunto de entidades pagamento mostrado no diagrama E-R da fig. 2.14. Esse conjunto de entidades tem trs atributos: nmero_pagamento, data_pagamento e total_pagamento. A chave primria do conjunto de entidades emprstimo, do qual pagamento dependente, o nmero_emprstimo. Assim, pagamento representado por uma tabela com quatro colunas chamadas nmero_emprstimo, nmero_pagamento, data_pagamento e total_pagamento, como mostrado na fig. 2.21.

Representao Tabular do Conjunto de Relacionamentos Seja R um conjunto de relacionamentos; seja a1, a2, ..., an o conjunto de atributos formado pela unio das chaves primarias de cada um dos conjuntos de entidades participantes de R; e seja os atributos descritivos b1, b2, ..., bn (se houver) de R. Representamos esse conjunto de relacionamentos pela tabela chamada R, com uma coluna para cada atributo do conjunto: Para ilustrar, considere o conjunto de relacionamentos devedor no diagrama E-R da fig. 2.8. Esse conjunto de relacionamentos envolve os dois conjuntos de entidades seguintes: cliente, com a chave primria seguro_social. Emprstimo, com a chave primria nmero_emprstimo. Uma vez que o conjunto de relacionamentos no possui atributos prprios, a tabela devedor possui duas colunas, a de seguro_social e nmero_emprstimo, como mostra a fig. 2.22.

Tabelas Redundantes 114

O caso do conjunto de relacionamentos unindo um conjunto de entidades fracas ao seu conjunto de entidades fortes correspondente um caso especial. Como pudemos ver anteriormente, esses relacionamentos so muitos para um e no possuem atributos descritivos. Alm disso, a chave primria de um conjunto de entidades fracas inclui a chave primria do conjunto de entidades fortes. No diagrama E-R da fig. 2.14, o conjunto de entidades fracas pagamento dependente do conjunto de entidades fortes emprstimo por meio do conjunto de relacionamentos pagamento_emprstimo. A chave primria de pagamento {nmero_emprstimo, nmero_pagamento} e a chave primria de emprstimo {nmero_emprstimo}. Desde que pagamento_emprstimo no possui atributos descritivos, a tabela para pagamento_emprstimo poderia ter duas colunas, nmero_emprstimo e nmero_pagamento. A tabela para o conjunto de entidades pagamento tem quatro colunas, nmero_emprstimo, nmero_pagamento, data_pagamento e total_pagamento. Assim, a tabela pagamento_emprstimo redundante. Em geral, a tabela para o conjunto de relacionamentos unindo o conjunto de entidades fracas com seu conjunto de entidades fortes correspondente redundante e no precisa ser apresentada em uma representao tabular do diagrama E-R. Combinao de tabelas Considere um conjunto de relacionamento muitos para um AB entre os conjuntos de entidades A e B. Usando nosso esquema de construo de tabelas previamente descrito, teremos trs tabelas: A, B e AB. Entretanto, se existe dependncia de A sobre B (isto , para cada entidade a em A, a existncia de a depende da existncia de alguma entidade b em B), ento podemos combinar as tabelas A e AB para formar uma tabela simples consistindo da unio das colunas de ambas as tabelas. Como ilustrao, considere o diagrama E-R da fig. 2.23. O conjunto de relacionamentos entre conta e agncia, agncia_conta, muitos para um. Daqui para frente, uma linha dupla no diagrama E-R indica que a participao de conta em conta_agncia total. Da, uma conta no pode existir sem que esteja associada a uma agncia em particular. Portanto, necessitamos somente de duas tabelas: conta, com os atributos nmero_conta, saldo e nome_agncia. agncia, com atributos nome_agncia, cidade_agncia e fundos.

Atributos Multivalorados Vimos que, em geral, os atributos do diagrama E-R so mapeados diretamente em colunas nas tabelas apropriadas. Atributos multivalorados, entretanto, constituem uma exceo; novas tabelas so criadas para esses tipos de atributos. Para um atributo multivalorado M, criamos a tabela T com uma coluna C que corresponde a M e as colunas correspondentes chave primria do conjunto de entidades ou conjunto de relacionamento do qual M atributo. Como ilustrao, considere o diagrama E-R apresentado na fig. 2.18. o diagrama inclui o atributo multivalorado nome_dependente. Para esse atributo multivalorado, criamos a tabela nome_dependente com as colunas nomed, referente ao atributo nome_dependente do empregado, e seguro_social_empregado,

115

representando a chave primria do conjunto de entidades empregado. Cada dependente de um empregado representado por uma nica linha na tabela. Representao Tabular da Generalizao Existem dois modos diferentes de transformar um diagrama E-R que contenha generalizao em tabelas. Embora nos refiramos generalizao mostrada na fig. 2.15, preferimos simplificar essa discusso incluindo somente o primeiro grupo dos conjuntos de entidades de nvel inferior isto , os atributos conta_poupana e conta_movimento. 1. Criar a tabela para o conjunto de entidades de nvel superior. Para cada conjunto de entidades de nvel inferior, criar uma tabela que inclua uma coluna para cada um dos coluna para cada um dos atributos daquele conjunto de entidades mais uma coluna para cada atributo da chave primria do conjunto de entidades mais uma coluna para cada atributo da chave primria do conjunto de entidades de nvel superior. Assim, para o diagrama da fig. 2.15, teremos trs tabelas: conta, com os atributos nmero_conta e saldo. conta_poupana, com os atributos nmero_conta e taxa_juros. conta_movimento, com os atributos nmero_conta e limite_cheque_especial. 2. Se a generalizao mutuamente exclusiva e total isto , se nenhuma entidade membro de mais de um conjunto de entidades de nvel imediatamente inferior ao conjunto de entidades de nvel superior e se todas as entidades do conjunto de entidades de nvel inferior , ento, uma outra representao alternativa possvel. Para cada conjunto de entidades de nvel inferior, cria-se uma tabela que inclua uma coluna para cada um dos atributos do conjunto de entidades mais uma coluna para cada atributo do conjunto de entidades de nvel superior. Ento, para o diagrama E-R da fig. 2.15, teremos duas tabelas. Conta_poupana, com atributos nmero_conta, saldo e taxa_juros. Conta_movimento, com os atributos nmero_conta, saldo e limite_cheque_especial. As relaes correspondentes a conta_poupana e conta_movimento para essas tabelas tm, ambas, saldo como chave primria. Se o segundo mtodo for usado para generalizaes com sobreposio, alguns valores, como saldo, podem ser armazenados duas vezes sem necessidade. Similarmente, se a generalizao no for total isto , se algumas contas no forem nem de poupana nem de movimento, ento tais contas no podero ser representadas usando o segundo mtodo. Representao Tabular da Agregao A transformao de um diagrama E-R com agregao para forma tabular bastante direta. Considere o diagrama da fig. 2.17. A tabela para o conjunto de relacionamentos agente_emprstimo inclui uma coluna para cada atributo, uma para a chave primria do conjunto de entidades empregado e uma para o conjunto de relacionamentos devedor. Poderia tambm incluir uma coluna para cada um dos atributos descritivos do conjunto de relacionamentos agente_emprstimo, se eles existirem. Usando o mesmo procedimento anterior para o resto do diagrama, criamos as seguintes tabelas: cliente, com os atributos nome_cliente, seguro_social, rua_cliente e cidade_cliente. emprstimo, com os atributos nmero_emprstimo e total. devedor, com os atributos seguro_social e nmero_emprstimo. empregado, com os atributos seguro_social_empregado, nome_empregado, e nmero_telefone. agente_emprstimo, com os atributos seguro_social, nmero_emprstimo e seguro_social_empregado.

116

Arquiteturas de Sistemas de Banco de Dados A arquitetura de um sistema de banco de dados fortemente influenciada pelo sistema bsico computacional sobre o qual o sistema de banco de dados executado. Aspectos da arquitetura de computadores como rede, paralelismo e distribuio tm influncia na arquitetura do banco de dados. Rede de computadores permite que algumas tarefas sejam executadas no servidor do sistema e outras sejam executadas no cliente. Essa diviso de trabalho tem levado ao desenvolvimento de sistemas de banco de dados cliente-servidor. Processamento paralelo em um sistema de computadores permite que atividades do sistema de banco de dados sejam realizadas com mais rapidez, reduzindo o tempo de resposta das transaes e, assim, aumentando o nmero de transaes processadas por segundo. Consultas podem ser processadas de forma a explorar o paralelismo oferecido pelo sistema operacional. A necessidade de processamento paralelo de consultas tem levado ao desenvolvimento de sistemas de banco de dados paralelos. A distribuio de dados pelos ns da rede ou pelos diversos departamentos de uma organizao permitem que esses dados residam onde so gerados ou mais utilizados, mas, ainda assim, estejam acessveis para outros ns de outros departamentos. Dispor de diversas cpias de um banco de dados em diferentes ns tambm permite a organizaes de grande porte manter operaes em seus bancos de dados mesmo quando um n afetado por um desastre natural, como inundaes, incndios ou terremotos. Sistemas de banco de dados distribudos tm se desenvolvido para tratar dados distribudos geogrfica ou administrativamente por diversos sistemas de banco de dados. Vamos agora estudar a arquitetura dos sistemas de banco de dados, comeando com os sistemas centralizados tradicionais e passando por sistemas de banco de dados cliente-servidor, paralelos e distribudos. Sistemas Centralizados Sistemas de banco de dados centralizados so aqueles executados sobre um nico sistema computacional que n ao interagem com outros sistemas. Tais sistemas podem ter a envergadura de um sistema de banco de dados de um s usurio executado em um computador pessoal at sistemas de alto desempenho em sistema de grande porte. Um sistema computacional genrico moderno consiste em uma ou poucas CPUs e dispositivos de controle que so conectados por meio de um bus comum que proporciona acesso memria compartilhada (fig. 16.1). As CPUs tm memrias cache locais que armazenam cpias de partes da memria para acesso rpido aos dados. Cada dispositivo de controle atende a um tipo especfico de dispositivo (por exemplo, um drive de disco, um dispositivo de udio ou de vdeo). A CPU e os dispositivos de controle podem trabalhar concorrentemente, competindo pelo acesso memria. A memria cache parcialmente reduz a conteno de acesso memria, uma vez que reduz o nmero de tentativas de acesso da CPU memria compartilhada.

117

Dividimos em dois modos a forma pela qual os computadores so usados: por um sistema de um nico usurio e sistemas multiusurios. Computadores pessoais e estaes de trabalho caem na primeira categoria. Um sistema monousurio tpico uma unidade de trabalho de uma nica pessoa, com uma nica CPU e um ou dois discos rgidos, com um sistema operacional que pode dar suporte a apenas um nico usurio. Um sistema multiusurio tpico, por outro lado, possui um nmero maior de discos e rea de memria, podendo ter diversas CPUs e um sistema operacional multiusurio. Atende a um grande nmero de usurios que esto conectados ao sistema por meio de terminais. Tais sistemas so frequentemente chamados de sistemas servidor. Sistemas de banco de dados projetados para ser monousurios, como os de computadores pessoais, normalmente no proporcionam muitos recursos comuns aos banco de dados multiusurios. Em particular, ele no do suporte ao controle de concorrncia, o que no necessrio quando somente um usurio pode gerar atualizaes. A recuperao de perdas nesse tipo de sistema , seno inexistente, primitiva por exemplo, fazendo um backup do banco de dados antes de qualquer atualizao. Muitos desses sistemas no do suporte SQL, fornecendo linguagens de consulta bem mais simples, como uma variante da QBE. Embora os sistemas de computadores de propsito geral possuam atualmente mltiplos processadores, eles tm paralelismo de granulao-grossa, com um nmero limitado de processadores (entre dois e quatro, normalmente), todos compartilhando a memria principal. Os banco de dados rodando em tais equipamentos normalmente no promovem o particionamento de uma consulta entre processadores: ao contrrio, cada consulta roda em um nico processador, permitindo que diversas consultas sejam executada concorrentemente. Assim, tais sistemas proporcionam alto throughput, isto , um grande nmero de transaes processador por segundo, embora uma transao, individualmente, no seja necessariamente processada com maior rapidez. Banco de dados processados em equipamento de um s processador j dispem de recursos multitarefas, nos quais diversos processos podem ser executados em um mesmo processador de modo compartilhado, dando ao usurio a impresso de que diversos processos so executados em paralelo. Assim, equipamentos com paralelismo de granulao-grossa parecem, na lgica, idnticos a um equipamento de um nico processador; sistemas de banco de dados projetados para equipamentos time-shared podem facilmente ser adaptados para esse ambiente. Em contrate, os equipamentos de granulao-fina tm um grande nmero de processadores, e os sistemas de banco de dados rodando nesse tipo de equipamento podem processar unidades de tarefas (consultas, por exemplo) submetidas pelos usurios em paralelo. 118

Sistemas Cliente-Servidor Como os computadores pessoais tm se tornado mais rpidos, mais poderosos e baratos, h uma tendncia de seu uso nos sistemas centralizados. Terminais conectados a sistemas centralizados esto sendo substitudos por computadores pessoais. Simultaneamente, interfaces com o usurio usadas funcionalmente para manuseio direto com sistemas centralizados esto sendo adequadas ao trato com computadores pessoais. Como resultado, sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitaes de sistemas clientes. A estrutura geral de um sistema cliente-servidor exibida na fig. 16.2. As funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias front-end e back-end como mostra a fig. 16.3. O back-end gerencia as estruturas de acesso, desenvolvimento e otimizao de consultas, controle de concorrncia e recuperao. O front-end dos sistemas de banco de dados consiste em ferramentas como formulrios, gerador de relatrios e recursos de interface grfica. A interface entre front-end e o back-end feita por meio da SQL ou de um programa de aplicao.

Sistemas servidores podem ser caracterizados, de modo geral, como servidores de transaes e servidores de dados. Sistemas servidores de transaes, tambm chamados sistemas servidores de consultas (query-server), proporcionam uma interface por meio da qual os clientes podem enviar pedidos para determinada ao e, em resposta, eles executam a ao e mandam de volta os resultados ao cliente. Usurios podem especificar pedidos por SQL ou por meio de um programa de aplicao usando um mecanismo de chamada de procedimento remota (remote-procedure-call). Sistemas servidores de dados permitem que os servidores interajam com clientes que fazem solicitaes de leitura e atualizao de dados em unidades como arquivos ou pginas. Por exemplo, servidores de arquivos que proporcionam uma interface sistema-arquivo na qual os clientes podem criar, atualizar, ler e remover arquivos. Servidores de dados para sistemas de banco de dados oferecem muito mais recursos: do suporte a unidades de dados como pginas, tuplas ou objetos menores que um arquivo. Proporcionam meios para indexao de dados e transaes, tal que os dados nunca se tornem inconsistentes se um equipamento cliente ou processo falhar.

119

Servidores de Transaes Em sistemas centralizados, o front-end e o back-end so ambos executados dentro de um nico sistema. Entretanto, a arquitetura de servidores de transaes segue a diviso funcional entre front-end e back-end. Devido grande exigncia de processamento para cdigo de interface grfica e ao aumento do poder de processamento dos computadores pessoais, o recurso para front-end possvel em computadores pessoais. Os computadores pessoais agem como clientes de sistemas servidores, os quais armazenam grandes volumes de dados e do suporte aos recursos de back-end. Clientes enviam solicitaes ao sistema servidor no qual essas transaes so executadas e os resultados so enviados de volta ao cliente que tem a responsabilidade de exibir esses dados. Padres do tipo ODBC (open database connectivity) visam atender interface de clientes e servidores. ODBC so programas de aplicao de interface que possibilitam aos clientes a criao de comandos SQL que so enviados para o servidor, no qual so executados. Qualquer cliente que use uma interface ODBC pode se conectar a qualquer servidor que fornea essa interface. Nas primeiras geraes de sistemas de banco de dados, a falta desse tipo de padro levou ao uso de software de mesmo fabricante tanto para back-end quanto para front-end. Com a difuso de padres para interfaces, diversos fabricantes passaram a disponibilizar ferramentas de front-end e os servidores back-end. Gupta SQL e PowerBuilder so exemplos de sistemas front-end independentes dos servidores back-end. Logo, alguns programas de aplicao, como as planilhas eletrnicas e pacotes para anlise estatstica, usaro interfaces cliente-servidor para acesso direto aos dados de um servidor back-end. Com efeito, eles funcionam como front-ends especializados para tarefas especficas. Interfaces cliente-servidor no ODBC so tambm usadas para alguns sistemas de processamento de transaes. So definidas por uma interface de programa de aplicao na qual os clientes enviam chamadas de procedimento transacional remota (transactional remote procedure call) para o servidor. Essas chamadas parecem chamadas de procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de procedimentos remotas feitas pelo cliente so encapsuladas em uma nica transao para o servidor. Assim, se a transao for abortada, o servidor poder reverter os resultados da chamada de procedimento remota. Como os equipamentos pequenos e individuais apresentam atualmente custo bem menor de aquisio e manuteno, as grandes corporaes tendem a adotar o down-sizing. Muitas empresas esto substituindo seus equipamentos de grande porte por redes de computadores com estacoes de trabalho ou computadores pessoais conectados a equipamentos servidores back-end. Algumas das vantagens so a maior funcionalidade e o menor custo, mais flexibilidade na disseminao, expanso e alocao dos recursos, melhores interfaces com os usurios e manuteno mais fcil. Servidores de dados Sistemas servidores de dados so usados em redes locais, nas quais h conexes de alta velocidade entre clientes e servidores, os equipamentos clientes so comparveis, em poder de processamento, aos equipamentos servidores e as tarefas executadas so do tipo processamento intensivo. Em tal ambiente, faz sentido o trfego de dados para o equipamento cliente, para o processamento local (o que pode levar certo tempo) e ento o envio dos dados de volta para o servidor. Note que essa arquitetura exige ampla funcionalidade back-end (fig. 16.3) nos clientes. Arquiteturas de servidores de dados tm sido comuns nos sistemas de banco de dados orientados a objetos. A origem do interesse nesse tipo de arquitetura surge a partir do momento em que o custo, relativo ao consumo de tempo, da comunicao entre cliente e servidor alta comparada ao tempo de referncia memria local (milissegundos versus menos de cem nanossegundos). Transmisso de pginas versus transferncia de itens. A unidade de comunicao para os dados pode ser de granularidade grossa, como uma pgina, ou de granularidade fina, como uma tupla (ou um objeto, no contexto de banco de dados orientado a objetos).

120

Se a unidade de comunicao um nico item, o overhead para a troca de mensagens alto se comparado ao volume de dados transmitido. Quando um item solicitado, faz sentido tambm enviar outros itens que certamente sero usados em um futuro prximo. A busca de itens antes mesmo que sejam solicitados chamada prefetching. A transferncia de pginas pode ser considerada uma forma de prefetching se diversos itens residirem em uma mesma pgina, j que todos os itens na pgina so transferidos quando um processo deseja ter acesso a um nico item de uma pgina. Bloqueio. Os bloqueios, em geral, so utilizados pelo servidor em itens de dados transitando entre clientes. Uma desvantagem da transferncia de pginas que as mquinas clientes precisam bloquear a unidade da granularidade um bloqueio de uma pgina implica o bloqueio de todos os itens dessa pgina. Mesmo que o cliente no esteja acessando mais de um item dessa pgina, fica implcito o bloqueio sobre todos os itens reservados. Outro cliente que solicite bloqueio nesses itens ser impedido desnecessariamente. Algumas tcnicas para escala de liberao de bloqueio (lock deescalation) j foram propostas, nas quais o servidor pode solicitar de volta para seus clientes a transferncia dos bloqueios dos itens reservados. Se o cliente no precisar de um item reservado, ele pode transferir o bloqueio do item de volta ao servidor, que ento pode ser bloqueado por outro cliente. Data caching. Os dados que navegam para um cliente durante uma transao pode ser cached no cliente, mesmo depois de completada a transao, se houver espao suficiente disponvel. Transaes sucessivas em um mesmo cliente podem acarretar o uso de dados cached. Entretanto, o uso de cache exige certa coerncia: mesmo que uma transao ache um dado cached, preciso ter certeza de que esse dado esteja atualizado, uma vez que ele pode ter sido alterado por um outro cliente depois de ter sido colocado em cache. Assim, uma mensagem precisar ainda ser trocada com o servidor para checar a validade e conseguir um bloqueio sobre o dado. Bloqueio cache (lock caching). Se os dados forem bem particionados entre os clientes, com um cliente raramente solicitando um dado ao mesmo tempo que outro, os bloqueios podem tambm ser armazenados localmente (cached) no equipamento cliente. Suponha que um item de dado esteja em cache e que o bloqueio solicitado para acesso a esse dado tambm esteja em cache. Ento, o acesso pode ser realizado sem qualquer comunicao com o servidor. Entretanto, o servidor precisa controlar os bloqueios em cache: se um cliente solicita um bloqueio ao servidor, o servidor precisa recuperar todos os bloqueios em conflito de itens de dados de qualquer outro equipamento cliente que possua bloqueio em cache. Essa tarefa torna-se muito mais complicada quando so consideradas as falhas de equipamento. Essa tcnica difere da escala de liberao de bloqueios apenas pelo fato de ser realizada ao longo da transao; de resto, ambas as tcnicas so similares.

Sistemas Paralelos Sistemas paralelos imprimem velocidade ao processamento e I/O por meio do uso em paralelos de diversas CPUs e discos. Equipamentos paralelos esto se tornando bastante comuns, fazendo com que o estudo de sistema de bancos de dados paralelos seja tambm cada vez mais importante. O direcionamento das atenes para os sistemas de banco de dados paralelos proveem da demanda de aplicaes que geram consultas em banco de dados muito grandes (da ordem de terabytes isto , 1012 bytes) ou que tenham de processar um volume enorme de transaes por segundo (da ordem de milhares de transaes por segundo). Sistemas de banco de dados centralizados e cliente-servidor no so poderosos o suficiente para tratar desse tipo de aplicao. No processamento paralelo, muitas operaes so realizadas simultaneamente, ao contrrio do processamento serial, no qual os passos do processamento so sucessivos. Um equipamento paralelo de granulao-grossa consiste em poucos e poderosos processadores; um paralelismo intensivo ou de granulaofina usa milhares de pequenos processadores; um paralelismo intensivo ou de granulao-fina usa milhares de pequenos processadores. A maioria das mquinas high-end, atualmente, oferece algum grau de paralelismo de granulao-grossa: dois a quatro processadores em uma nica mquina j comum. Computadores de paralelismo intensivo podem ser diferenciados dos equipamentos de paralelismo de granulao-grossa pelo grau 121

de paralelismo muito mais alto que podem oferecer. Computadores paralelos com centenas de CPUs e discos j esto disponveis comercialmente. So duas as principais formas de avaliar o desempenho de um sistema de banco de dados. A primeira o throughput: o nmero de tarefas realizadas em um dado intervalo de tempo. A segunda o tempo de resposta: o tempo total que o sistema leva para completar uma nica tarefa. Um sistema que processa um grande nmero de pequenas transaes pode aumentar o throughput por meio do processamento de diversas transaes em paralelo. Um sistema que processa um grande volume de transaes pode aumentar o tempo de resposta, assim como o throughput por meio do processamento em paralelo. Acelerao e Escalabilidade Duas metas so importantes no estudo do paralelismo, a acelerao e a escalabilidade. A acelerao refere-se reduo do tempo de execuo de uma tarefa por meio do aumento do grau de paralelismo. A escalabilidade diz respeito ao manuseio de um maior nmero de tarefas por meio do aumento do grau de paralelismo. Considere uma aplicao de banco de dados rodando em um sistema paralelo com um certo nmero de processadores e discos. Agora, suponha que incrementemos o nmero de processadores ou discos e outros componentes do sistema. A meta processar a tarefa em tempo inversamente proporcional aos processadores e discos alocados. Suponha que o tempo de execuo de uma tarefa em um equipamento de grande porte seja TL e que o tempo de execuo da mesma tarefa em uma mquina de menor porte seja TS. A acelerao em funo do paralelismo definida por Ts/TL. O sistema paralelo apresenta um comportamento de acelerao linear se a acelerao for N quando um sistema de maior porte tiver N vezes mais recursos (CPU, disco e assim por diante) que o sistema de menor porte. Se a acelerao menor que N, diz-se que o sistema apresenta comportamento de acelerao sublinear. A fig. 16.4 ilustra as aceleraes linear e sublinear.

A escalabilidade relaciona-se capacidade de processar grande volume de tarefas em um mesmo intervalo de tempo por meio do aumento dos recursos. Seja Que uma tarefa e QN uma tarefa que N vezes maior que Q. Suponha que o tempo de execuo de Que em um determinado equipamento MS seja TS e o tempo de execuo da tarefa QN em um equipamento paralelo ML, que N vezes maior que MS, seja TL. A escalabilidade , ento, definida como TS /TL. o sistema paralelo ML apresenta um comportamento de escalabilidade linear na tarefa Q se TL = TS. Se TL > TS, o sistema apresenta um comportamento de escalabilidade sublinear. A fig. 16.5 ilustra a escalabilidade linear e sublinear. H dois tipos de escalabilidade relevantes em sistemas de banco de dados paralelos, dependendo de como se mede a tarefa: Na escalabilidade em lote (batch), o tamanho do banco de dados aumenta e as tarefas so grandes jobs cujo tempo de execuo depende do tamanho do banco de dados. Um exemplo de tarefa desse tipo a pesquisa em uma relao cujo tamanho proporcional ao tamanho do banco de dados. Assim, o tamanho do banco de dados determinante para a medio do problema. A escalabilidade no 122

processamento em lote tambm vale para as aplicaes cientficas, como na execuo de uma consulta com refinamento de N vezes ou a execuo de uma simulao com N repeties. Na escalabilidade de transao, a taxa de submisso das transaes para o banco de dados aumenta e o tamanho do banco de dados aumenta proporcionalmente taxa de transaes. Esse tipo de escalabilidade o que relevante nos sistemas de processamento de transaes nos quais as transaes so pequenas atualizaes por exemplo, um depsito ou saque de uma conta e a taxa de transaes cresce medida que mais contas so criadas. Esse tipo de processamento de transaes especialmente adequado para execuo em paralelo, uma vez que as transaes podem ser executadas concorrente e independentemente em processadores separados, e cada transao leva, aproximadamente, o mesmo tempo, at mesmo se o banco de dados crescer.

A escalabilidade a mais importante mtrica para medir a eficincia de um sistema de banco de dados paralelo. Normalmente, o objetivo do paralelismo em sistemas de banco de dados garantir um desempenho aceitvel, mesmo se o tamanho do banco de dados e o volume de transaes crescerem. O aumento da capacidade do sistema em funo do paralelismo proporciona um caminho mais suave para o crescimento de uma empresa que a transferncia do sistema centralizado para um equipamento mais rpido (mesmo supondo que tal mquina exista). Entretanto, devemos tambm dar uma olhada nos nmeros relativos ao desempenho absoluto quando avaliamos a escalabilidade: uma mquina cujo crescimento da escalabilidade seja linear pode resultar em um desempenho pior que outra cuja escala de crescimento seja menor que a linear, porque se partiu de uma premissa indevida. Alguns fatores trabalham contra a eficincia das operaes em paralelo e podem reduzir tanto a acelerao quanto a escalabilidade. Custo inicial. Existe um custo inicial associado inicializao de um processo. Em operaes paralelas consistindo de milhares de processos, o tempo de iniciao (startup time) pode se sobrepor ao tempo real de processamento, afetando de modo negativo a acelerao. Interferncia. Uma vez que os processos executando em um sistema paralelo frequentemente mantem seus acessos a recursos compartilhados, alguma lentido pode resultar da interferncia de cada novo processo, j que ele disputar os recursos comuns com os processos existentes, tais como cabos, discos compartilhados ou mesmo bloqueios. Tanto a acelerao quanto a escalabilidade so afetadas por esse fenmeno. Distoro (skew). Com a quebra de uma tarefa em um nmero determinado de passos paralelos reduzimos o tamanho do passo mdio. Nem sempre o tempo de servio do passo mais lento determinar o tempo de servio para a tarefa como um todo. Frequentemente, difcil dividir uma tarefa em partes iguais e o modo de estabelecer essas partes , portanto, distorcido. Por exemplo, se uma tarefa de tamanho menor que 10 ou de tamanho maior que 10; mesmo que uma tarefa tenha tamanho 20, a 123

acelerao obtida executando as tarefas em paralelo de apenas 5, em vez de 10, como poderia ser esperado. Interconexo de Redes Os sistemas paralelos so conjuntos de componentes (processadores, memria, e discos) que podem se comunicar entre si via redes interconectadas. Exemplos de interconexo de redes incluem: Bus. Todos os componentes do sistema podem enviar e receber dados em um nico bus (cabo) de comunicao. O bus pode ser uma ethernet ou um interconector paralelo. Arquiteturas com bus trabalham bem com um pequeno nmero de processadores. Entretanto, no respondem bem ao aumento do paralelismo, j que o bus s pode servir a uma comunicao por vez. Malha (mesh). Os componentes so organizados como ns de uma grade, e cada componente conectado na grade a todos os componentes adjacentes. Em uma malha bidimensional, cada n conectado a quatro ns adjacentes, enquanto em uma malha tridimensional, cada n conectado a seis ns adjacentes. Os ns que no esto diretamente interconectados podem se comunicar roteando mensagens por meios dos ns intermedirios. O nmero de ligaes para comunicao cresce com o crescimento do nmero de componentes e a capacidade de comunicao da malha, portanto responde melhor ao aumento do paralelismo. Hipercbica (hypercube). Os componentes so numerados em binrios e um componente conectado a outro se a representao binaria de seus nmeros diferirem em exatamente um bit. Assim, cada um dos n componentes est conectado a log(n) outros componentes. Isso pode ser verificado quando em uma interconexo hipercbica uma mensagem de um componente pode alcanar outro por meio de, no mximo, log(n) ligaes. Em contraste, em uma malha, um componente pode manter -1 ligacoes com algum outro componente (ou /2 ligacoes, se a interconexo pela malha alcanar as bordas da grade). Assim, atrasos na comunicao em um hipercubo so significativamente menores que em uma malha. Arquiteturas de Banco de Dados Paralelo H diversos modelos arquitetnicos para mquinas paralelas. Entre elas, as mais promissoras so mostradas na fig. 16.6 (na figura, M denota memria, P, processador e os discos so representados por cilindros): Memria compartilhada. Todos os processadores compartilham uma mesma memria. Esse modelo mostrado na fig. 16.6a. Disco compartilhado. Todos os processador compartilham o mesmo disco. Esse modelo mostrado na fig. 16.6b. Sistemas com discos compartilhados so, s vezes, chamados de clusters. Ausncia de compartilhamento. Os processadores no compartilham nem a memria nem disco. Esse modelo apresentado na figura 16.6c. Hierrquico. Esse modelo mostrado na fig. 16.6d; ele um hibrido das arquiteturas anteriores.

124

Memria compartilhada Na arquitetura com memria compartilhada, os processadores e os discos acessam a memria comum, normalmente, por meio de cabo ou por meio de rede de interconexo. A vantagem da memria compartilhada sua extrema eficincia na comunicao entre processadores qualquer processador pode ter acesso aos dados em memria compartilhada sem necessidade de ser movido por software. Um processador pode enviar mensagens a outro processador usando a memria. Essas trocas de mensagens so bem mais rpidas (normalmente, menos de um microssegundo) se comparadas s que usam mecanismos de comunicao. O problema das mquinas com memria compartilhada que a arquitetura no adequada ao uso de mais de 32 ou 64 processadores, uma vez que o bus ou a interconexo por rede torna-se um gargalo (pois compartilhado por todos os processadores). Aps determinado ponto, adicionar mais processadores no resolve; eles gastaro a maior parte de seu tempo esperando sua vez de usar o bus para acesso memria. Arquiteturas de memria compartilhada utilizam, normalmente, grande memria cache em cada processador para que o acesso memria compartilhada seja evitado sempre que possvel. Porm, pelo menos alguns desses dados no estaro em memria cache e os acessos sero dirigidos memria compartilhada. Consequentemente, mquinas com memria compartilhada no possibilitam aumento de escala alm de determinado ponto; as mquinas de memria compartilhada, atualmente, no do suporte a mais de 64 processadores. Disco Compartilhado No modelo de disco compartilhado, todos os processadores podem ter acesso direto a todos os discos, via interconexo por rede, mas os processadores possuem memrias prprias. H duas vantagens da arquitetura de discos compartilhados sobre a de memria compartilhada. Primeiro, uma vez que cada processador possui memria exclusiva, o bus de memria no representa um gargalo. Segundo, essa arquitetura oferece um modo barato de aumentar a tolerncia a falhas: se o processador (ou sua memria) falha, o outro processador pode assumir suas tarefas, j que o banco de dados residente nos discos acessvel a todos os processadores. Podemos fazer o subsistema de discos, ele prprio, tolerante a falhas usando a arquitetura RAID. A arquitetura de discos compartilhados vem obtendo aceitao em diversos tipos de aplicaes; os sistemas construdos sobre arquitetura desse tipo so frequentemente chamados de clusters.

125

O principal problema dos sistemas de discos compartilhados , novamente, o grau de crescimento. Embora o bus de memria no represente mais um gargalo, a restrio agora a interconexo com o subsistema de discos; esse caso particularmente determinante quando o banco de dados acessa muito os discos. Comparando aos sistemas de memria compartilhada, os sistemas de discos compartilhados podem ser usados com um nmero maior de processadores, mas a comunicao entre os processadores lenta (um pouco acima de milissegundos quando no h hardware especfico para a comunicao), uma vez que ela tem de atravessar a rede. Cluster DEC rodando Rdb foi um dos primeiros usurios comerciais a utilizar a arquitetura de discos compartilhados (o Rdb atualmente propriedade da Oracle e chamado de Oracle Rdb). Ausncia de Compartilhamento Em um sistema sem compartilhamento, cada equipamento de um n consiste em um processador, uma memria e discos. O processador de um n pode comunicar-se com outros processadores de outros ns usando intercomunicao de rede de alta velocidade. Um n serve de servidor dos dados alocados em seus discos. Uma vez que as referncias aos discos so atendidas em cada processador por discos locais, o modelo sem compartilhamento transpe os percalos de submeter todos os I/Os por meio de uma nica rede de interconexo; somente consultas, acessos a discos remotos e o resultado das relaes so transportados por meio da rede. Alm disso, as redes de interconexo dos sistemas sem compartilhamento so normalmente projetadas para permitir o crescimento de escala, o que significa que sua capacidade aumenta quanto mais ns so acrescidos. Consequentemente, arquiteturas sem compartilhamento so mais flexveis quanto escala e podem, facilmente, dar suporte a um grande nmero de processadores. Os principais problemas dos sistemas sem compartilhamento so os custos de comunicao e os acessos a discos remotos, que so maiores que no arquitetura com memria ou discos compartilhados, j que a transmisso de dados envolve interao feita por software em ambos os lados. A mquina de banco de dados Teradata foi um dos primeiros sistemas comerciais a usar a arquitetura de banco de dados com ausncia de compartilhamento. Hierrquica A arquitetura hierrquica combina as caractersticas das arquiteturas de compartilhamento de memria e discos com a arquitetura sem compartilhamento. Em seu nvel mais alto, o sistema constitui-se de ns que so conectados por uma rede sem compartilhar discos ou memria entre si. O topo de linha um sistema sem compartilhamento. Cada n do sistema pode ser um sistema com memria compartilhada entre poucos processadores. Alternativamente, cada n poderia ser um sistema de discos compartilhados e cada um desses sistemas que compartilham um conjunto de discos poderia tambm compartilhar memria. Desse modo, o sistema poderia ser construdo obedecendo a uma hierarquia, com o compartilhamento de memria por alguns processadores na base e sem compartilhamento algum no nvel mais alto, com possivelmente uma arquitetura de compartilhamento de discos intermediaria. A fig. 16.6d ilustra uma arquitetura hierrquica de ns com memria compartilhada conectada por uma arquitetura com ausncia de compartilhamento. Sistemas de banco de dados paralelos comerciais atualmente rodam em diversas dessas arquiteturas. Tentativas para reduo da complexidade de programao desse tipo de sistema resultaram em arquiteturas de memria virtual distribuda, nas quais h uma nica memria lgica compartilhada, mas fisicamente h diversos sistemas de memria separados; o acoplamento de hardware com mapeamento da memria virtual por meio de suporte extra de memria oferece uma visa nica de rea de memria virtual dessas memrias separadas. Sistemas Distribudos Em um sistema de banco de dados distribudo, o banco de dados armazenado em diversos computadores. Os computadores de um sistema de banco de dados distribudo comunica-se com outros por 126

intermdio de vrios meios de comunicaes, como redes de alta velocidade ou linhas telefnicas. Eles no compartilha memria principal ou discos. Os computadores em um sistema de banco de dados distribudo podem variar, quanto ao tamanho e funes, desde estacoes de trabalho at sistemas de grande porte (mainframe). Os computadores de um sistema de banco de dados distribudo recebem diversos nomes, como sites ou ns, dependendo do contexto no qual so inseridos. Usaremos preferencialmente o termo site (local, stio) para enfatizar a distribuio fsica desses sistemas. A estrutura geral do sistema distribudo mostrada na fig. 16.7. As principais diferenas entre os banco de dados paralelos sem compartilhamento e os banco de dados distribudos so que, nos banco de dados distribudos, h a distribuio fsica geogrfica, administrao separada e uma intercomunicao menor. Outra importante diferena que, nos sistemas distribudos, distinguimos transaes locais de globais. Uma transao local acessa um nico site, justamente no qual ela se inicia. Uma transao global, por outro lado, aquela que busca acesso a diferentes sites, ou a outro site alm daquele em que se inicia.

Exemplo Ilustrativo Considere o sistema de uma empresa da rea bancria que consiste em quatro agncias em quatro cidades diferentes. Cada agncia possui seu prprio computador, com um banco de dados abrangendo todas as contas referentes quela agncia. Cada uma dessas instalaes , assim, um site. H tambm um nico site que mantem informaes sobre todas as agncias do banco. Cada agncia mantm (entre outras) uma relao conta (Esquema_conta), em que: Esquema_conta = (nome_agncia, nmero_conta, saldo) O site que mantm informaes sobre as quatro agncias possui a relao agncia(Esquema_agncia), em que: Esquema_agncia = (nome_agncia, cidade_agncia, fundos) H outras relaes nos diversos sites; ns a ignoramos em nosso exemplo. Para ilustrar a diferena entre os dois tipos de transaes, consideramos a transao de adicionar 50 dlares conta A-177 localizada na agncia Valleyview. Se uma transao foi iniciada na agncia Valleyview, ela ento considerada local; caso contrrio, ser considerada global. Uma transao para transferir 50 dlares da conta A-177 para a conta A-305, a qual est localizada na agncia Hillside, uma transao global, uma vez que conta em sites diferentes sofrem acessos como resultado de sua execuo. O que faz dessa configurao um sistema de banco de dados distribudo so os seguintes aspectos: 127

Os vrios sites esto disponveis entre si. Os sites compartilham um esquema global comum, embora algumas relaes possam estar armazenadas em alguns sites. Cada site proporciona um ambiente para execuo tanto de transaes locais quanto de transaes globais. Cada site roda o mesmo software para o gerenciamento de banco de dados.

Se houver sistemas gerenciadores de banco de dados diferentes rodando nos sites, torna-se difcil o gerenciamento de transaes globais. Tais sistemas so chamados de sistemas de banco de dados mltiplos (multidatabase) ou sistemas de banco de dados distribudos heterogneos. Tradeoffs H diversas razoes para a utilizao de sistemas de banco de dados distribudos, como o compartilhamento de dados, a autonomia e a disponibilidade. Compartilhamento de dados. A maior vantagem de um sistema de banco de dados distribudo criar um ambiente no qual os usurios de um site podem ter acesso a dados residentes em outros sites. Por exemplo, no sistema distribudo bancrio usado como exemplo, os usurios de uma agncia podem ter acesso aos dados de outra agncia. Sem essa disponibilidade, um usurio que desejasse transferir fundos de uma agncia para outra teria de recorrer a algum mecanismo externo. Autonomia. A primeira vantagem do compartilhamento dos dados por meio da distribuio dos dados que cada site pode manter certo nvel de controle sobre os dados que esto armazenados localmente. Em sistemas centralizados, o administrado do banco de dados central quem gerencia o banco de dados. Em sistemas de banco de dados distribudos h um administrador geral responsvel pelo banco como um todo. Uma parte dessa responsabilidade delegada ao administrador local de cada site. Dependendo do projeto do banco de dados distribudo, os administradores podem possuir diferentes graus de autonomia local provavelmente uma das maiores vantagens dos banco de dados distribudos. Disponibilidade. Se um site sai do ar em um sistema distribudo, os demais sites podem continuar em operao. Particularmente, se os itens de dados so replicados em diversos sites, uma transao que precise de um item de dado em particular pode encontrar tal item presente em diversos sites. Assim, a queda de um site no implica, necessariamente, a queda do sistema. A queda de um site precisa ser detectada pelo sistema, assim como determinadas aes devem ser executadas para recuper-lo da falha. O sistema no poder mais usar os servios do site fora do ar. Finalmente, quando um site volta a funcionar ou quando consertado, necessrio dispor de mecanismos para integr-lo paulatinamente ao sistema. Embora a recuperao de uma falha seja mais complexa nos sistemas distribudos que nos sistemas centralizados, a capacidade da maioria dos sistemas manter-se em operao a despeito da falha de um site acaba por aumentar a disponibilidade. A disponibilidade crucial para os sistemas de banco de dados usados em aplicaes de tempo real. A perda do acesso aos dados em, por exemplo, uma companhia area pode fazer com que um cliente em potencial prefira viajar com uma companhia concorrente. A principal desvantagem dos sistemas de banco de dados distribudos o acrscimo de complexidade necessrio para assegurar a coordenao entre os sites. Esse aumento de complexidade toma diversas formas: Custo de desenvolvimento de software. mais difcil implementar sistemas de banco de dados distribudos, portanto, o custo mais alto. Maior possibilidade de bugs. Uma vez que os sites que constituem o sistema distribudo operam em paralelo, difcil assegurar a preciso dos algoritmos, especialmente durante a ocorrncia e recuperao de falha em parte do sistema. H, potencialmente, a chance de bugs extremamente sutis. 128

Aumento do processamento e overhead. A troca de mensagens e processamento adicional necessrios coordenao entre sites so uma forma de overhead que no ocorre nos sistemas centralizados.

Na escolha do projeto do sistema de banco de dados, o projetista deve ponderar as vantagens e desvantagens da distribuio dos dados. H diversas abordagens para um projeto de banco de dados distribudo, partindo de projetos totalmente distribudos at os que mantm alto nvel de centralizao. Tipos de Redes Sistemas de banco de dados distribudos e sistemas cliente-servidor so apoiados em redes de comunicao. H basicamente dois tipos de redes: redes locais (local-area networks LAN) e redes de longa distncia (wide-area networks WAN). A principal diferena entre as duas o modo pelo qual so distribudas geograficamente. Redes locais so compostas por processadores distribudos sobre pequenas extenses geogrficas, como um nico edifcio ou alguns prdios prximos. Redes de longa distncia, por outro lado, so compostas por determinado nmero de processadores autnomos, distribudos por uma extensa rea geogrfica. Essas diferenas envolvem maiores variaes na velocidade e confiabilidade das redes de comunicao e se refletem no projeto do sistema operacional. Redes Locais As redes locais (LANs) apareceram no incio dos anos 70 como meio de comunicao entre computadores e para compartilhamento de dados. Percebeu-se que, em diversas empresas, numerosos pequenos computadores, cada um com suas prprias aplicaes, so mais econmicos que um nico grande sistema. Como cada pequeno equipamento provavelmente necessita de acesso a um grande nmero de dispositivos perifricos (como discos e impressoras) e como a necessidade de alguma forma de compartilhamento de dados frequentemente em uma empresa, a consequncia natural foi a conexo desses pequenos sistemas em uma rede de computadores. As LANs so normalmente projetadas para cobrir uma pequena rea geogrfica e so, geralmente, usadas me escritrios. Todos os sites deste tipo de sistema esto prximos entre si, assim a comunicao entre eles tende a manter velocidades mais altas e menores taxas de erro que as apresentadas pelas redes de longa distncia. O tipo de ligao mais comum entre os computadores de uma rede local o par tranado, cabo coaxial de banda larga e fibra tica. A velocidade de comunicao gira em torno de um megabyte por segundo, para rede como Appletalk e IBM, redes lentas em anel (token ring), at um gigabit por segundo, para redes ticas experimentais. Dez megabits por segundo bastante comum, essa a velocidade da Ethernet. As redes de fibra tica FDDI (optical-fiber-based) e Fast Ethernet rodam a cem megabits por segundo. Redes com base no protocolo chamado protocolo assncrono (asynchronous transfer mode ATM) podem alcanar velocidades superiores, como 144 megabits por segundo, e esto se tornando bastante populares. Uma LAN tpica consiste em diferentes estaes de trabalho, um ou mais sistemas servidores, vrios dispositivos perifricos compartilhados (como impressora a laser ou unidades de fita magntica) e um ou mais gateways (processadores especializados) que proporcionam acesso a outras redes (fig. 16.8). o esquema Ethernet usado com frequncia em LANs.

129

Redes de Longa Distncia As redes de longa distncia (WANs) apareceram no final da dcada de 1960, principalmente em projetos de pesquisas acadmicas para comunicao eficiente entre sites, permitindo que o hardware e o software pudessem ser compartilhados conveniente e economicamente entre a grande comunidade de usurios. Os sistemas que permitiram a conexo de terminais remotos com um computador central via linhas telefnicas foram desenvolvidos no incio da dcada de 1960, embora no fossem de fato uma WAN. A primeira WAN projetada e desenvolvida foi a Arpanet. Os trabalhos na Arpanet comearam em 1968. A Arpanet desenvolveu-se a partir de quatro redes experimentais at chegar rede mundial, a Internet, compreendendo milhes de sistemas computacionais. A ligao caracterstica da WAN so circuitos telefnicos que usam linhas de fibra tica e (por vezes) canais de satlite. Como exemplo, consideremos a Internet, que conecta computadores pelo mundo. O sistema possibilita que hosts em sites geograficamente separados comuniquem-se entre si. Os computadores hosts diferem uns dos outros no tipo, velocidade, tamanho da palavra, sistema operacional, etc. Os hosts so, geralmente, LANs conectadas a redes regionais. As redes regionais so interligadas a roteadores para formar a rede mundial. As conexes entre as redes usam frequentemente o servio de telefonia chamado T1, que oferece taxas de transferncia de cerca de 44.736 megabits por segundo. As mensagens enviadas para a rede so roteadas por sistemas chamados de roteadores, que controlam o caminho percorrido por cada mensagem atravs da rede. Esse roteamento pode ser dinmico, para aumentar a eficincia da comunicao, ou esttico, para reduzir riscos ou permitir que a carga de comunicao seja processada mais facilmente. Outras WANs em operao usam linhas telefnicas padro como principal meio de comunicao. Os modems so dispositivos que recebem sinal digital de um computador e convertem esses dados em sinais analgicos, que so usados pelo sistema de telefonia. Um modem no site de destino converte o sinal analgico em digital e, assim, o equipamento de destino recebe o dado. A velocidade dos modems varia de 2400 bips a 32 kilobits por segundo. Os sistemas de telefonia que aceitam o padro Rede Digital de Servios Integrados (Integrated Services Digital Network ISDN) permitem que os dados sejam transferidos ponto a ponto a altas taxas, normalmente 128 kilobits por segundo. A rede UNIX, UUCCP, permite que os sistemas se comuniquem uns com os outros um nmero limitado de vezes (e, geralmente, predeterminado), via modems, para troca de mensagens. Essas mensagens so roteadas para outro sistema prximo e, dessa forma, propagadas para todos os hosts da rede (mensagens publicas) ou transferidas para seu destino (mensagens particulares). 130

As WANs so classificadas em dois tipos: WAN conexo descontnua, como aquelas que tm por base a UUCP, em que os hosts esto conectados rede somente por determinados perodos. WAN conexo contnua, como a Internet, cujos hosts esto conectados rede o tempo todo.

O projeto de um sistema de banco de dados distribudo fortemente influenciado pelo tipo de WAN de apoio. Os verdadeiros sistemas de banco de dados distribudos podem rodar apenas sobre as redes conectadas continuamente pelo menos durante as horas em que o banco de dados distribudo est operacional. Redes que no esto continuamente conectadas, geralmente, no permitem transaes entre sites, mas tomam cpias locais dos dados remotos e atualizam periodicamente essas cpias (toda noite, por exemplo). Para aplicaes cuja consistncia no seja crtica, como compartilhamento de documentos, sistemas de trabalho em grupo (groupware systems) como o Lotus Notes, permitem atualizaes em dados remotos feitos localmente e essas atualizaes retornam periodicamente ao site remoto. H conflito potencial de atualizaes entre sites que precisa ser detectado e resolvido. Um mecanismo para deteces de atualizaes conflitantes existe; o mecanismo para resoluo de conflitos de atualizao, entretanto, dependente da aplicao. Arquitetura de sistemas de bancos de dados INTRODUO Agora temos condies de apresentar uma arquitetura para um sistema de bancos de dados. Nosso objetivo ao apresentar essa arquitetura fornecer um arcabouo sobre o qual possamos desenvolver os captulos subsequentes. Esse arcabouo til para descrever conceitos gerais de bancos de dados e explicar a estrutura de sistemas de bancos de dados especficos mas no afirmamos que todo sistema pode se enquadrar bem nesse arcabouo em particular, nem queremos sugerir que essa arquitetura prev o nico arcabouo possvel. Em especial, provvel que sistemas pequenos (ver Captulo 1) no ofeream suporte para todos os aspectos da arquitetura. Porm, a arquitetura em questo de fato parece se ajustar razoavelmente bem maior parte dos sistemas; alm disso, ela basicamente idntica arquitetura proposta pelo ANSI/SPARC Study Group on Data Base Management Systems (a chamada arquitetura ANSI/SPARC consulte as referncias [2.1-2.2]). Contudo, optamos por no seguir a terminologia ANSI/SPARC em todos os detalhes. OS TRS NVEIS DA ARQUITETURA A arquitetura ANSI/SPARC se divide em trs nveis, conhecidos como nvel interno, nvel conceitual e nvel externo, respectivamente (ver Figura 2.1). De modo geral: O nvel interno (tambm conhecido como nvel fsico) o mais prximo do meio de armazenamento fsico ou seja, aquele que se ocupa do modo como os dados so fisicamente armazenados. O nvel externo (tambm conhecido como nvel lgico do usurio) o mais prximo dos usurios ou seja, aquele que se ocupa do modo como os dados so vistos por usurios individuais. O nvel conceitual (tambm conhecido como nvel lgico comunitrio, ou s vezes apenas nvel indireto, sem qualificao) um nvel de simulao entre os outros dois. Observe que o nvel externo se preocupa com as percepes dos usurios individuais, enquanto o nvel conceitual est preocupado com uma percepo da comunidade de usurios. Em outras palavras, haver muitas vises externas distintas, cada qual consistindo em uma representao mais ou menos abstrata de alguma parte do banco de dados completo, e haver exatamente uma viso conceitual, consistindo em uma representao analogamente abstrata do banco de dados em sua totalidade.* (Lembre-se de que a maioria dos usurios no estar interessada em todo o banco de dados, mas somente em alguma poro restrita do banco de dados.) Do mesmo modo, haver precisamente uma viso interna, representando o modo como o banco de dados est fisicamente armazenado.

131

Um exemplo ajudar a esclarecer essas ideias. A Figura 2.2 mostra a viso conceitual, a viso interna correspondente e duas vises externas correspondentes (uma para um usurio PL/I e outra para um usurio COBOL), todas para um simples banco de dados de pessoal. claro que o exemplo inteiramente hipottico ele no pretende se assemelhar a qualquer sistema real e muitos detalhes irrelevantes foram deliberadamente omitidos. Explicao: No nvel conceitual, o banco de dados contm informaes relativas a um tipo de entidade chamada EMPREGADO. Cada empregado individual tem um NUMERO_EMPREGADO (seis caracteres), um NUMERO_DEPARTAMENTO (quatro caracteres) e um SALARIO (cinco dgitos decimais). No nvel interno, os empregados so representados por um tipo de registro armazenado, denominado EMP_ARMAZENADO, com vinte bytes de comprimento. EMP_ARMAZENADO contm quatro campos armazenados: um prefixo de seis bytes (presumivelmente contendo informaes de controle, tais como flags ou ponteiros) e trs campos de dados correspondentes s trs propriedades de empregados. Alm disso, os registros EMP_ARMAZENADO so indexados sobre o campo EMP# por um ndice chamado EMPX, cuja definio no mostrada. O usurio PL/I tem uma viso externa do banco de dados na qual cada empregado representado por um registro PL/I que contm dois campos (nmeros de departamentos no so de interesse para esse usurio, e por isso foram omitidos da viso). O tipo de registro definido por uma declarao de estrutura PL/I comum, de acordo com as regras normais de PL/I. De modo semelhante, o usurio COBOL tem uma viso externa em que cada empregado representado por um registro COBOL contendo, mais uma vez, dois campos (agora, foram omitidos os salrios). O tipo de registro definido por uma descrio comum de registro COBOL, de acordo com as regras normais do COBOL.

Observe que itens de dados correspondentes podem ter nomes diferentes em pontos diferentes. Por exemplo, a referncia ao nmero do empregado chamada EMP# na viso externa de PL/I, EMPNO na viso externa COBOL, NUMERO EMPREGADO na viso conceitual e novamente EMP# na viso interna. claro que o sistema deve estar ciente das correspondncias; por exemplo, ele tem de ser informado de que o campo EMPNO do COBOL derivado do campo conceitual Por abstrata, queremos dizer nesse caso apenas que a representao

132

em questo envolve construes como registros e campos, mais orientadas para o usurio, em oposio a construes como bits e bytes, mais orientadas para a mquina. Observe que faz pouca diferena para as finalidades deste captulo saber se o sistema que est sendo considerado relacional ou no. Contudo, pode ser til indicar de forma resumida como os trs nveis da arquitetura so em geral percebidos especificamente em um sistema relacional: Primeiro, o nvel conceitual em tal sistema ser definitivamente relacional, no sentido de que os objetos visveis nesse nvel sero tabelas relacionais, e os operadores sero operadores relacionais (incluindo, em especial, os operadores de restrio e projeo examinados de forma abreviada no Captulo 1). Em segundo lugar, uma determinada viso externa tambm ser tipicamente relacional, ou algo muito prximo disso; por exemplo, as declaraes de registros PL/I ou COBOL da Figura 2.2 podem ser consideradas de maneira informal, respectivamente, os equivalentes PL/I ou COBOL da declarao de uma tabela relacional em um sistema relacional. Nota: devemos mencionar de passagem que o termo viso externa (em geral abreviado apenas como viso) infelizmente tem um significado bastante especfico em contextos relacionais que no idntico ao significado atribudo ao termo neste captulo. Consulte os Captulos 3 e 9 para ver uma explicao e uma descrio do significado relacional. Terceiro, o nvel interno no ser relacional, porque os objetos nesse nvel no sero apenas tabelas relacionais (armazenadas) em vez disso, eles sero os mesmos tipos de objetos encontrados no nvel interno de qualquer outra espcie de sistema (registros armazenados, ponteiros, ndices, hashing etc.). De fato, o modelo relacional em si no tem absolutamente nenhuma relao com o nvel interno; ele se preocupa, como vimos no Captulo 1, com o modo como o banco de dados visto pelo usurio. Agora vamos prosseguir com o exame dos trs nveis da arquitetura com um nvel muito maior de detalhes, comeando pelo nvel externo. Em toda a nossa descrio, faremos repetidas referncias Figura 2.3, que mostra os principais componentes da arquitetura e seus inter-relacionamentos pelo administrador de banco de dados (DBA) .

133

O NVEL EXTERNO O nvel externo o nvel do usurio individual. Como foi explicado no Captulo 1, um determinado usurio pode ser ou programador de aplicaes ou um usurio final com qualquer grau de sofisticao. (O DBA um caso especial importante; porm, diferentemente de outros usurios, o DBA tambm precisar estar interessado nos nveis conceitual e interno. Consulte as duas sees seguintes.) Cada usurio tem uma linguagem sua disposio: Para o programador de aplicaes, essa linguagem ser uma linguagem de programao convencional (como PL/I, C+ +, Java) ou uma linguagem proprietria especfica para o sistema em questo. Essas linguagens proprietrias so frequentemente chamadas de linguagens de quarta gerao (L4Gs), pelo fato (muito difuso!) de que (a) o cdigo de mquina, a linguagem assembler e a linguagem PL/I podem ser consideradas como trs geraes mais antigas de linguagens e (b) as linguagens proprietrias representam o mesmo tipo de aperfeioamento em relao s linguagens de terceira gerao (L3Gs) que essas linguagens representavam em relao linguagem assembler e esta ltima, por sua vez, representava em relao ao cdigo de mquina. Para o usurio final, a linguagem ser uma linguagem de consulta ou alguma linguagem de uso especial, talvez dirigida por formulrios ou menus, adaptada aos requisitos desse usurio e com suporte de algum programa aplicativo on-line. Para nossos propsitos, o ponto importante sobre todas essas linguagens que elas incluiro uma sublinguagem de dados isto , um subconjunto da linguagem completa relacionado de modo especfico aos objetos e s operaes do banco de dados. A sublinguagem de dados (abreviada como DSL data sublanguage na Figura 2.3) dita embutida na linguagem hospedeira correspondente. A linguagem hospedeira responsvel pelo fornecimento de diversos recursos no relacionados com bancos de dados, como variveis locais, operaes de clculo, lgica de desvios condicionais (if-then-else), e assim por diante. Um dado sistema poderia admitir qualquer nmero de linguagens hospedeira e qualquer nmero de sublinguagens de dados; porm, uma determinada sublinguagem de dados reconhecida por quase todos os sistemas atuais a linguagem SQL, discutida brevemente no Captulo 1. A maioria desses sistemas permite que a SQL seja usada tanto de modo interativo como uma linguagem de consulta autnoma, quanto incorporada a outras linguagens como PL/I ou Java (consulte o Captulo 4 para ver detalhes adicionais). Observe que, embora seja conveniente para propsitos arquiteturais distinguir entre a sublinguagem de dados e 134

a linguagem hospedeira que a contm, as duas podem de fato no ser distintas para o usurio; na verdade, talvez seja prefervel sob a perspectiva do usurio que elas no sejam distintas. Se elas no forem distintas, ou se s puderem ser distinguidas com dificuldade, diremos que elas esto fortemente acopladas. Se forem clara e facilmente distinguveis, dizemos que elas esto fracamente acopladas. Apesar de alguns sistemas comerciais (em especial sistemas de objetos ver Captulo 24) admitirem o acoplamento forte, a maioria no o aceita. Em particular, os sistemas SQL costumam oferecer suporte apenas para o acoplamento fraco. (O acoplamento forte oferece um conjunto de recursos mais uniforme para o usurio, mas sem dvida envolve maior esforo por parte dos desenvolvedores de sistemas, um fato que presumivelmente contribui para o status quo.) Em princpio, qualquer sublinguagem de dados determinada , na realidade, uma combinao de pelo menos duas linguagens subordinadas uma linguagem de definio de dados (DDL Data Definition Language), que d suporte definio ou declarao de objetos dos bancos de dados, e uma linguagem de manipulao de dados (DML Data Manipulation Language), que admite a manipulao ou o processamento desses objetos. Por exemplo, considere o usurio PL/I da Figura 2.2, na Seo 2.2. A sublinguagem de dados para esse usurio consiste nos recursos de PL/I utilizados para a comunicao com o SGBD: A parte de DDL consiste nas construes declarativas de PL/I necessrias para se declararem objetos do banco de dados a prpria instruo DECLARE(DEL), certos tipos de dados de PL/I, possivelmente extenses especiais de PL/I para oferecer suporte a novos objetos no manipulados pela PL/I existente. A parte da DML consiste nas instrues executveis de PL/I que transferem informaes de e para o banco de dados mais uma vez incluindo, possivelmente, novas instrues especiais. Nota: mas precisamente, devemos dizer que a PL/I no inclui na realidade nenhum recurso especfico de bancos de dados na poca em que este livro foi escrito. Em particular, as instrues de DML costumam ser apenas instrues CALL de PL/I que invocam o SGBD (embora essas chamadas possam estar sintaticamente disfaradas de algum modo, a fim de torn-las um pouco mais amistosas para o usurio consulte a discusso sobre a SQL embutida no Captulo 4). Voltando arquitetura: j indicamos que um usurio individual geralmente s estar interessado em alguma parte do banco de dados como um todo; alm disso, a viso que esse usurio tem dessa parte ser em geral um tanto abstrata quando comparada com o modo como os dados esto fisicamente armazenados. O termo ANSI/SPARC para a viso de um usurio individual viso externa. Uma viso externa , portanto, o contedo do banco de dados visto por algum usurio determinado (ou seja, para esse usurio a viso externa o banco de dados). Por exemplo, um usurio do Departamento de Pessoal poderia considerar o banco de dados uma coleo de ocorrncias de registros de departamentos e empregados, e ele poderia no ter nenhum conhecimento das ocorrncias de registros de fornecedores e peas vistas pelos usurios do Departamento de Compras. Nvel Conceitual A viso conceitual uma representao de todo contedo de informao de informaes do banco de dados, mais uma vez (como no caso de uma viso externa) em uma forma um tanto abstrata, em comparao com o modo como os dados so visualizados por qualquer usurio em particular. Em termos gerais, a viso conceitual pretende ser uma viso dos dados como eles realmente so, em vez de forar os usurios a v-los pelas limitaes (por exemplo) da linguagem ou do hardware que eles possam estar utilizando. A viso conceitual consiste em muitas ocorrncias de cada um dos vrios tipos de registros conceituais. Por exemplo, ela pode consistir em uma coleo de ocorrncias de registros de departamentos, junto com uma coleo de ocorrncias de registros de empregados, junto com uma coleo de ocorrncias de registros de fornecedores, mais uma coleo de ocorrncias de registros de peas, e assim por diante. Um registro conceitual no necessariamente o mesmo que um registro externo, nem o mesmo que um registro armazenado. A viso conceitual definida por meio do esquema conceitual, que inclui definies de cada um dos vrios tipos de registros conceituais (mais uma vez, observe um exemplo simples da fig. 2.2). o esquema conceitual escrito por meio de outra linguagem de definio de dados, a DDL conceitual. Se quisermos alcanar a independncia fsica dos dados, ento essas definies de DDL conceitual no devero envolver quaisquer consideraes sobre a representao fsica ou a tcnica conceitual, no dever haver nenhuma referncia a representaes de campos armazenados, sequencias de registros armazenados, ndices, esquemas de hashing, ponteiros ou quaisquer outros detalhes de armazenamento e acesso. Se o esquema conceitual se tornar verdadeiramente independente de dados dessa maneira, ento os esquemas externos, definidos em termos do esquema conceitual, tambm so independentes dos dados. Portanto, a viso conceitual uma viso do contedo total do banco de dados, e o esquema conceitual uma definio dessa viso. Porm, seria enganoso sugerir que o esquema conceitual nada mais do que um 135

conjunto de definies muito semelhante s definies de registros simples, encontradas hoje em (por exemplo) um programa COBOL. As definies no esquema conceitual tm por finalidade incluir muitos recursos adicionais, como as restries de segurana e integridade. Algumas autoridades no assunto chegariam at a sugerir que o objetivo final do esquema conceitual descrever a empresa inteira no apenas seus dados em si, mas tambm o modo como esses dados so usados; como eles fluem de um ponto para outro dentro da empresa, para q eles so usados em cada ponto, quais controles de auditoria ou outros controles devem ser aplicados em cada ponto, e assim por diante. No entanto, devemos enfatizar que nenhum sistema atual admite realmente um esquema conceitual q sequer se aproxime desse grau de complexidade; na maior parte dos sistemas existentes, o esquema conceitual , na verdade, pouco mais que uma simples unio de todos os esquemas externos individuais, juntamente com determinadas restries de segurana e integridade. Porm, sem dvida, possvel q sistemas futuros eventualmente se tornem muito mais sofisticados em seu suporte ao nvel conceitual. O NVEL INTERNO O terceiro nvel da arquitetura o nvel interno. A viso interna uma representao de baixo nvel do banco de dados por inteiro; ela consiste em muitas ocorrncias de cada um dos vrios tipos de registros internos. Registro interno o termo ANSI/SPARC que representa a construo que temos chamado de registro armazenado (e continuaremos a usar essa ltima forma). Assim, a viso interna ainda est muito afastada do nvel fsico, pois ela no lida com registros fsicos tambm chamados blocos ou pginas nem com quaisquer consideraes especficas de dispositivos, como tamanhos de cilindros ou trilhas. Em outras palavras, a viso interna pressupe efetivamente um espao de endereos linear infinito; os detalhes de como esse espao de endereos mapeado no meio de armazenamento fsico so bastante especficos para cada sistema e foram deliberadamente omitidos da arquitetura geral. Nota: o bloco, ou a pgina, a unidade de entrada e sada (E/S) isto , ele representa a quantidade de dados transferidos entre o meio de armazenamento secundrio e a memria principal em uma nica operao de E/S. Os tamanhos de pginas tpicos so 1 K, 2 K ou 4 K bytes (K = 1.024). A viso interna descrita por meio do esquema interno, que no somente define os diversos tipos de registros armazenados mas tambm especifica quais ndices existem, como os campos armazenados esto representados, em que sequncia fsica esto os registros armazenados, e assim por diante (mais uma vez, veja na Figura 2.2 um exemplo simples). O esquema interno escrito usando-se ainda outra linguagem de definio de dados a DDL interna. Nota: neste livro, usaremos normalmente os termos mais intuitivos estrutura de armazenamento ou banco de dados armazenado em vez de viso interna, e ainda definio de estrutura de armazenamento em lugar de esquema interno. Para encerrar lembramos que, em certas situaes excepcionais, os programas aplicativos em particular as aplicaes de natureza utilitria (ver Seo 2.11) podem ter permisso para operar diretamente no nvel interno, e no no nvel externo. No preciso dizer que essa prtica no recomendvel; ela representa um risco de segurana (pois as restries de segurana so ignoradas) e um risco de integridade (pois tambm as restries de integridade so ignoradas), e o programa ter uma inicializao dependente dos dados; porm, s vezes essa poder ser a nica maneira de obter a funcionalidade ou o desempenho exigido do mesmo modo o usurio em uma linguagem de programao de alto nvel poderia ter a necessidade ocasional de descer at a linguagem assembler para satisfazer certos objetivos de funcionalidade ou desempenho.

MAPEAMENTOS Alm dos trs nveis bsicos, a arquitetura da Figura 2.3 envolve, em geral, certos mapeamentos um mapeamento conceitual/interno e vrios mapeamentos externos/conceituais: O mapeamento conceitual/interno define a correspondncia entre a viso conceitual e o banco de dados armazenado; ele especifica o modo como os registros e campos conceituais so representados no nvel interno. Se a estrutura do banco de dados armazenado for alterada isto , se for efetuada uma mudana na definio do banco de dados armazenado o mapeamento conceitual/interno ter de ser alterado de acordo, a fim de q o esquema conceitual possa permanecer invarivel. ( responsabilidade do DBA, ou provavelmente, do SGBD, administrar tais alteraes.) Em outras palavras, os efeitos dessas mudanas devem ser isolados abaixo do nvel conceitual, a fim de preservar a independncia de dados fsica. Definir o esquema interno
136

O DBA tambm deve decidir como sero representados os dados no banco de dados armazenado. Em geral, esse processo chamado projeto de banco de dados fsico.* Tendo elaborado o projeto fsico, o DBA deve ento criar a definio da estrutura de armazenamento correspondente (isto , o esquema interno), usando a DDL interna. Alm disso, ele tambm deve definir o mapeamento conceitual/interno associado. Na prtica, a DDL conceitual ou a DDL interna mais provavelmente a primeira dever incluir os meios para definir esse mapeamento, mas as duas funes (criao do esquema, definio do mapeamento) devem ser claramente distinguveis. Como no caso do esquema conceitual, o esquema interno e o mapeamento correspondente existiro tanto na forma de fonte quanto de objeto. Ligao com usurios tarefa do DBA fazer a ligao com os usurios, a fim de garantir que os dados de que eles necessitam estaro disponveis, e escrever (ou ajudar os usurios a escreverem) os esquemas externos necessrios, usando a DDL externa aplicvel. (Como j foi dito, um dado sistema pode admitir vrias DDLs externas distintas.) Alm disso, os mapeamentos externos/conceituais correspondentes tambm devem ser definidos. Na prtica, a DDL externa provavelmente incluir os meios para especificar esses mapeamentos, mas, de novo, os esquemas e os mapeamentos devem ser claramente distinguveis. Cada esquema externo e o mapeamento correspondente devero existir tanto na forma de fonte quanto de objeto. Outros aspectos da funo de ligao com o usurio incluem a consultoria em projeto de aplicaes, o fornecimento de instruo tcnica, a assistncia para determinao e resoluo de problemas e servios profissionais semelhantes. Definir restries de segurana e integridade Como j vimos, as restries de segurana e integridade podem ser consideradas uma parte do esquema conceitual. A DDL conceitual deve incluir recursos para a especificao de tais restries. Definir normas de descarga e recarga Uma vez que uma empresa esteja comprometida com um sistema de banco de dados, ela se torna dependente de modo crtico do sucesso desse sistema. Em caso de danos a qualquer parte do banco de dados provocados por erro humano, digamos, ou por uma falha de hardware ou do sistema operacional essencial ser capaz de reparar os dados em questo com um mnimo de demora e com o menor efeito possvel sobre o restante do sistema. Por exemplo, em condies ideais, a disponibilidade dos dados que no tenham sido danificados no deve ser afetada. O DBA tem de definir e implementar um esquema apropriado de controle de danos, em geral envolvendo (a) descarga peridica ou dumping do banco de dados para o meio de armazenamento de backup e (b) recarregamento do banco de dados quando necessrio, a partir do dump mais recente. A propsito, a discusso anterior fornece uma razo pela qual seria uma boa ideia espalhar a coleo total de dados por vrios bancos de dados, em vez de manter tudo em um nico lugar; o banco de dados individual poderia muito bem formar a unidade para finalidades de descarga e recarregamento. Nessa linha, observe que j existem sistemas terabyte** isto , instalaes de bancos de dados comerciais que armazenam bem mais de um trilho de bytes de dados, em termos informais e que os sistemas do futuro devero ser muito maiores. E desnecessrio dizer que tais sistemas VLDB (banco de dados muito grande very large database) exigem administrao muito cuidadosa e sofisticada, em especial se houver um requisito de disponibilidade contnua (que normalmente existe). No obstante, por simplicidade, continuaremos a falar como se de fato houvesse um nico banco de dados. * Observe a sequncia: primeiro, defina que dados voc deseja; depois, decida como represent-los no meio de armazenamento. O projeto fsico sempre deve ser feito depois do projeto lgico. **1.o24 bytes = um kilobyte (KB); 1.024 KB = um megabyte (MB); 1.024 MB = um gigabyte (GB); 1.024 GB um terabyte (TB); 1.024 TB = um petabyte (PB); 1.024 PB = um exabyte (EB). Observe que, informalmente, um gigabyte equivale a um bilho de bytes (a abreviatura BB empregada s vezes em lugar de GB).
137

 Monitorar o desempenho e responder a requisitos de mudanas Como foi indicado na Seo 1.4, o DBA responsvel pela organizao do sistema de modo a obter o desempenho que seja o melhor para a empresa, e por fazer os ajustes apropriados isto , a sintonia fina (tuning) conforme os requisitos se alterarem. Por exemplo, poderia ser necessrio reorganizar o banco de dados armazenado de tempos em tempos para assegurar que os nveis de desempenho permanecero aceitveis. Como j mencionamos, qualquer mudana no nvel de armazenamento fsico (interno) do sistema deve ser acompanhada por uma mudana correspondente na definio do mapeamento de nvel conceitual/interno, de modo que o esquema conceitual possa permanecer constante. E claro que a lista anterior no esgota o assunto ela pretende apenas dar uma ideia da extenso e da natureza das responsabilidades do DBA. O SISTEMA DE GERENCIAMENTO DE BANCOS DE DADOS O sistema de gerenciamento de bancos de dados (SGBD) o software que trata de todo o acesso ao banco de dados. Conceitualmente, o que ocorre o seguinte (observe mais uma vez a Figura 2.3): 1. Um usurio faz um pedido de acesso usando uma determinada sublinguagem de dados (em geral, SQL). 2. O SGBD intercepta o pedido e o analisa. 3. O SGBD inspeciona, por sua vez, o esquema externo (ou as verses objeto desse esquema) para esse usurio, o mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e a definio da estrutura de armazenamento. 4. O SGBD executa as operaes necessrias sobre o banco de dados armazenado. Como exemplo, considere as aes relacionadas com a busca de uma determinada ocorrncia de registro externo. Em geral, sero necessrios campos de vrias ocorrncias de registros conceituais e, por sua vez, cada ocorrncia de registro conceitual exigir campos de vrias ocorrncias de registros armazenados. Ento, conceitualmente, o SGBD deve primeiro buscar todas as ocorrncias necessrias de registros armazenados, depois construir as ocorrncias de registros conceituais exigidas e, em seguida, construir a ocorrncia de registro externo. Em cada estgio, podem ser necessrias converses de tipos de dados ou outras converses. Naturalmente, a descrio anterior muito simplificada; em particular, ela implica que todo o processo interpretativo, medida que sugere que os processos de anlise do pedido, inspeo dos diversos esquemas etc., so todos realizados durante a execuo. A interpretao, por sua vez, em geral implica um desempenho sofrvel devido sobrecarga em tempo de execuo. Porm, na prtica talvez seja possvel fazer os pedidos de acesso serem compilados antes do momento da execuo (em particular, diversos produtos atuais de SQL fazem isso consulte as anotaes relativas s referncias [4.12] e [4.26] do Captulo 4). Vamos examinar agora as funes do SGBD com um pouco mais de detalhes. Essas funes incluiro o suporte a pelo menos todos os itens a seguir (observe a Figura 2.4): Definio de dados O SGBD deve ser capaz de aceitar definies de dados (esquemas externos, o esquema conceitual, o esquema interno e todos os mapeamentos associados) em forma fonte e convert-los para a forma objeto apropriada. Em outras palavras, o SGBD deve incluir componentes de processador de DDL ou compilador de DDL para cada uma das diversas linguagens de definio de dados (DDLs). O SGBD tambm deve entender as definies da DDL, no sentido de que, por exemplo, ele entende que os registros externos EMPREGADO incluem um campo SALARIO; ele deve ento ser capaz de usar esse conhecimento para analisar e responder a pedidos de manipulao de dados (por exemplo, obtenha todos os empregados com salrio < R$ 50.000,00). Manipulao de dados O SGBD deve ser capaz de lidar com solicitaes do usurio para buscar, atualizar ou excluir dados existentes no banco de dados, ou para acrescentar novos dados ao banco de dados. Em outras
138

palavras, o SGBD deve incluir um componente processador de DML ou compilador de DML para lidar com a linguagem de manipulao de dados (DML data manipulation language). Em geral, as solicitaes de DML podem ser planejadas ou no-planejadas: a. Uma solicitao planejada aquela para a qual a necessidade foi prevista com bastante antecedncia em relao ao momento em que a solicitao executada. O DBA provavelmente ter ajustado o projeto de banco de dados fsico de modo a garantir um bom desempenho para solicitaes planejadas. b. Em contraste, uma solicitao no-planejada uma consulta ad hoc, isto , uma solicitao cuja necessidade no foi prevista com antecedncia mas, em vez disso, surgiu no ltimo instante. O projeto de banco de dados fsico pode estar ou no adaptado de forma ideal para a solicitao especfica sendo considerada. Para usar a terminologia introduzida no Captulo 1 (Seo 1.3), as solicitaes planejadas so caractersticas de aplicaes operacionais ou de produo, ao passo que as solicitaes noplanejadas so caractersticas de aplicaes para apoio deciso. Alm disso, as solicitaes planejadas em geral sero emitidas a partir de programas aplicativos escritos previamente, enquanto as solicitaes no-planejadas sero, por definio, emitidas de modo interativo por meio de algum processador de linguagem de consulta. Nota: como vimos no Captulo 1, o processador de linguagem de consulta na realidade uma aplicao on-line embutida, no uma parte do SGBD per se; ele foi includo na Figura 2.4 por completitude. Otimizao e execuo As requisies de DML, planejadas ou no-planejadas, devem ser processadas pelo componente otimizador, cujo propsito determinar um modo eficiente de implementar a requisio. A otimizao discutida em detalhes no Captulo 17. As requisies otimizadas so ento executadas sob o controle do gerenciador em tempo de execuo (run time). Nota: na prtica, o gerenciador em tempo de execuo provavelmente invocar algum tipo de gerenciador de arquivos para obter acesso aos dados armazenados. Os gerenciadores de arquivos so descritos resumidamente no final desta seo. Segurana e integridade de dados O SGBD deve monitorar requisies de usurios e rejeitar toda tentativa de violar as restries de segurana e integridade definidas pelo DBA (consulte a seo anterior). Essas tarefas podem ser executadas em tempo de compilao ou em tempo de execuo, ou ainda em alguma mistura dos dois. Recuperao e concorrncia de dados O SGBD ou, mais provavelmente, algum outro componente de software relacionado, cm geral chamado gerenciador de transaes ou monitor de processamento de transaes (monitor TP) deve impor certos controles de recuperao e concorrncia. Os detalhes desses aspectos do sistema esto alm do escopo deste captulo; consulte a Parte IV deste livro, que contm uma descrio em profundidade do assunto. Nota: o gerenciador de transaes no mostrado na Figura 2.4 porque, em geral, ele no faz parte do SGBD propriamente dito. Dicionrio de dados O SGBD deve fornecer uma funo de dicionrio de dados. O dicionrio de dados pode ser considerado um banco de dados em si (mas um banco de dados do sistema, no um banco de dados impem restries - de segurana e integridade do usurio), O dicionrio contm dados sobre os dados (s vezes chamados metadados ou descritores) ou seja, definies de outros objetos do sistema, em vez de dados brutos somente. Em particular, todos os vrios esquemas e mapeamentos (externos, conceituais etc.) e todas as diversas restries de segurana e integridade estaro armazenados, tanto na forma de fonte quanto de objeto, no dicionrio. Um dicionrio completo tambm incluir muitas informaes adicionais mostrando, por exemplo, os programas que utilizam determinadas partes do banco de dados, os usurios que exigem certos relatrios, os terminais conectados ao sistema, e assim por diante. O dicionrio poderia at estar na verdade, provavelmente deve estar integrado ao banco de dados que define e, portanto, incluir sua prpria definio. Por certo, deve haver a opo de consultar o dicionrio como qualquer outro banco de dados para que, por exemplo, seja possvel saber que programas e/ou usurios tero maior probabilidade de serem afetados
139

por alguma alterao proposta no sistema. Consulte o Captulo 3 para ver uma discusso adicional sobre o assunto. Nota: estamos entrando agora em uma rea sobre a qual existe muita confuso de terminologia. Algumas pessoas fariam referncia ao que estamos chamando de dicionrio como um diretrio ou catlogo, o que implica que diretrios ou catlogos so de algum modo inferiores a um verdadeiro dicionrio e reservariam o termo dicionrio para designar uma variedade especfica (importante) de ferramenta para desenvolvimento de aplicaes. Outros termos que tambm so algumas vezes empregados para designar essa ltima variedade de objetos so repositrio de dados (ver Captulo 13) e enciclopdia de dados.

desnecessrio dizer que o SGBD deve realizar todas as funes identificadas anteriormente de forma to eficiente quanto possvel. Podemos resumir tudo o que foi mencionado antes afirmando que a funo geral do SGBD fornecer a interface do usurio para o sistema de banco de dados. A interface do usurio pode ser definida como a fronteira no sistema abaixo da qual tudo invisvel para o usurio. Por definio, portanto, a interface do usurio est no nvel externo. Contudo, como veremos no Captulo 9, h algumas situaes em que improvvel que a viso externa seja significativamente diferente da poro relevante da viso conceitual subjacente, pelo menos nos produtos SQL comerciais de hoje. Conclumos esta seo com uma breve comparao entre os sistemas de gerenciamento de bancos de dados discutidos anteriormente e os sistemas de gerenciamento de arquivos (gerenciadores de arquivos ou servidores de arquivos). Em linhas gerais, o gerenciador de arquivos o componente do sistema operacional bsico que administra arquivos armazenados; portanto, em termos informais, ele est mais prximo ao disco que o SGBD. (Na verdade, o SGBD costuma ser montado sobre algum tipo de gerenciador de arquivos.) Desse 140

modo, o usurio de um sistema de gerenciamento de arquivos ser capaz de criar e destruir arquivos armazenados e de executar operaes simples de busca e atualizao sobre registros armazenados em tais arquivos. No entanto, em contraste com o SGBD: Os gerenciadores de arquivos no tm conhecimento da estrutura interna dos registros armazenados e, por isso, no podem lidar com requisies que dependam de um conhecimento dessa estrutura. Em geral, eles fornecem pouco ou nenhum suporte para restries de segurana e integridade. Em geral, eles fornecem pouco ou nenhum suporte para controles de recuperao e concorrncia. No h verdadeiramente um conceito de dicionrio de dados no nvel do gerenciador de arquivos. Eles proporcionam muito menos independncia de dados que o SGBD. Em geral, os arquivos no esto integrados ou compartilhados no mesmo sentido que o banco de dados (normalmente, eles so privativos de algum usurio ou alguma aplicao em particular). O GERENCIADOR DE COMUNICAES DE DADOS Nesta seo, consideraremos resumidamente o tpico de comunicaes de dados. As requisies a bancos de dados de um usurio final so, na verdade, transmitidas da estao de trabalho do usurio que pode estar fisicamente afastada do prprio sistema de banco de dados para alguma aplicao on-line (embutida ou no), e da at o SGBD, sob a forma de mensagens de comunicao. De modo semelhante, as respostas do SGBD e da aplicao on-line para a estao de trabalho do usurio tambm so transmitidas sob a forma de mensagens. Todas essas transmisses de mensagens tm lugar sob o controle de outro componente de software, o gerenciador de comunicaes de dados (gerenciador DE data communications). O gerenciador DE no faz parte do SGBD, mas um sistema autnomo. Porm, como o gerenciador DE e o SGBD so claramente obrigados a trabalhar em harmonia, s vezes os dois so considerados parceiros de igual nvel em um empreendimento cooperativo de nvel mais alto, denominado sistema de banco de dados/comunicaes de dados (sistema DB/DE), no qual o SGBD toma conta do banco de dados e o gerenciador DE manipula todas as mensagens de e para o SGBD ou, mais precisamente, de e para aplicaes que utilizam o SGBD. Porm, neste livro, teremos pouco a dizer sobre o manejo de mensagens como essas (o que, por si s, um assunto extenso). A Seo 2.12 descreve resumidamente a questo das comunicaes entre sistemas distintos (ou seja, entre mquinas diferentes em uma rede de comunicaes, como a Internet), mas esse , na realidade, um tpico parte. ARQUITETURA CLIENTE/SERVIDOR Descrevemos at agora neste captulo os sistemas de bancos de dados sob o ponto de vista da chamada arquitetura ANSI/SPARC. Em particular, a Figura 2.3 forneceu uma representao simplificada dessa arquitetura. Nesta seo, examinaremos os sistemas de bancos de dados sob uma perspectiva um pouco diferente. Naturalmente, o objetivo geral desses sistemas fornecer suporte ao desenvolvimento e execuo de aplicaes de bancos de dados. Portanto, sob um ponto de vista de mais alto nvel, um sistema de banco de dados pode ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um servidor (tambm chamado back end) e um conjunto de clientes (tambm chamados front ends). Consulte a Figura 2.5. Explicao: O servidor o prprio SGBD. Ele admite todas as funes bsicas de SGBDs discutidas na Seo 2.8 definio de dados, manipulao de dados, segurana e integridade de dados, e assim por diante. Em particular, ele oferece todo o suporte de nvel externo, conceitual e interno que examinamos nas Sees 2.3 a 2.6. Assim, o termo servidor neste contexto to-somente um outro nome para o SGBD. Os clientes so as diversas aplicaes executadas sobre o SGBD tanto aplicaes escritas por usurios quanto aplicaes internas, ou seja, aplicaes fornecidas pelo fabricante do SGBD ou por produtores independentes. No que se refere ao servidor, claro que no existe nenhuma diferena entre aplicaes escritas pelo usurio e aplicaes internas todas elas empregam a mesma interface para o servidor, especificamente a interface de nvel externo discutida na Seo 2.3.

141

Nota: certas aplicaes especiais chamadas utilitrios poderiam constituir uma exceo ao que vimos antes, pois s vezes elas podem precisar operar diretamente no nvel interno do sistema (conforme mencionamos na Seo 2.5). Esses utilitrios devem ser considerados componentes integrais do SGBD, em vez de aplicaes no sentido usual. Os utilitrios sero discutidos com mais detalhes na prxima seo. Vamos aprofundar o exame da questo de aplicaes escritas pelo usurio versus aplicaes fornecidas pelo fabricante: Aplicaes escritas pelo usurio so basicamente programas aplicativos comuns, escritos (em geral) em uma linguagem de programao convencional de terceira gerao (L3G), como C ou COBOL, ou ento em alguma linguagem proprietria de quarta gerao (L4G) embora em ambos os casos a linguagem precise ser de algum modo acoplada a uma sublinguagem de dados apropriada, conforme explicamos na Seo 2.3. Banco de dados Aplicaes fornecidas por fabricante (chamadas frequentemente de ferramentas tools) so aplicaes cuja finalidade bsica auxiliar na criao e execuo de outras aplicaes! As aplicaes criadas so aplicaes adaptadas a alguma tarefa especfica (elas podem no ser muito semelhantes s aplicaes no sentido convencional; de fato, a finalidade das ferramentas permitir aos usurios, em especial aos usurios finais, criar aplicaes sem ter de escrever programas em uma linguagem de programao convencional). Por exemplo, uma das ferramentas fornecidas pelo fabricante ser um gerador de relatrios, cuja finalidade permitir que os usurios finais obtenham relatrios formatados a partir do sistema sob solicitao. Qualquer solicitao de relatrio pode ser considerada um pequeno programa aplicativo, escrito em uma linguagem de gerao de relatrios de nvel muito alto (e finalidade especial). As ferramentas fornecidas pelo fabricante podem ser divididas em diversas classes mais ou menos distintas: a. Processadores de linguagem de consulta. b. Geradores de relatrios. c. Subsistemas grficos de negcios. d. Planilhas eletrnicas. e. Processadores de linguagem natural. f. Pacotes estatsticos. g. Ferramentas para gerenciamento de cpias ou extrao de dados. h. Geradores de aplicaes (inclusive processadores L4G). i. Outras ferramentas para desenvolvimento de aplicaes, inclusive produtos de engenharia de software auxiliada pelo computador (CASE computer-aided software engineering). Os detalhes dessas ferramentas e de vrias outras esto alm do escopo deste livro; entretanto, observamos que, tendo em vista que (como foi dito antes) toda a importncia de um sistema de banco de dados est em dar suporte criao e execuo de aplicaes, a qualidade das ferramentas disponveis , ou deve ser, um fator preponderante na deciso sobre o banco de dados (isto , o processo de escolha do produto de banco de dados apropriado). Em outras palavras, o SGBD em si no o nico fator que precisa ser levado em considerao, nem mesmo necessariamente o fator mais significativo. Encerramos esta seo com uma referncia para o que se segue. Como o sistema por completo pode estar to claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em 142

mquinas diferentes. Em outras palavras, existe o potencial para o processamento distribudo. O processamento distribudo significa que mquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicaes, de tal modo que uma nica tarefa de processamento de dados possa ser dividida entre vrias mquinas na rede. Na verdade, essa possibilidade to atraente por urna variedade de razes, principalmente de ordem econmica que o termo cliente/servidor passou a se aplicar a quase exclusivamente ao caso em que o cliente e o servidor esto de fato localizados em mquinas diferentes. Examinaremos o processamento distribudo com mais detalhes na Seo 2.12. UTILITRIOS Utilitrios so programas projetados para auxiliar o DBA com diversas tarefas administrativas. Como mencionamos na seo anterior, alguns programas utilitrios operam no nvel externo do sistema e, portanto, so na verdade apenas aplicaes de uso especial; alguns podem nem mesmo ser fornecidos pelo fabricante do SGBD, mas sim por algum fabricante independente. Porm, outros utilitrios operam diretamente no nvel interno (em outras palavras, eles realmente fazem parte do servidor) e, desse modo, devem ser oferecidos pelo fornecedor do SGBD. Aqui esto alguns exemplos dos tipos de utilitrios que costumam ser necessrios na prtica: Rotinas de carga, a fim de criar a verso inicial do banco de dados a partir de um ou mais arquivos do sistema operacional. Rotinas de descarregamento/recarregamento, a fim de descarregar o banco de dados, ou partes dele, para o meio de armazenamento de backup e recarregar dados dessas cpias de backup ( claro que o utilitrio de recarregamento basicamente idntico ao utilitrio de carga que acabamos de mencionar). Rotinas de reorganizao, a fim de rearranjar os dados no banco de dados armazenado por vrias razes (em geral, relacionadas com o desempenho) por exemplo, para agrupar dados de algum modo particular no disco, ou para reaver o espao ocupado por dados que se tornaram obsoletos. Rotinas estatsticas, a fim de calcular diversas estatsticas de desempenho, tais como tamanhos de arquivos e distribuio de valores de dados ou contagens de E/S etc. Rotinas de anlise, a fim de analisar as estatsticas mencionadas antes. A lista precedente representa apenas uma pequena amostra das funes em geral oferecidas pelos utilitrios; existe uma srie de outras possibilidades.

PROCESSAMENTO DISTRIBUDO Repetindo o que mencionamos na Seo 2.10, a expresso processamento distribudo significa que mquinas diferentes podem estar conectadas entre si em uma rede de comunicaes como a Internet, de tal modo que uma nica tarefa de processamento de dados possa se estender a vrias mquinas na rede. (A expresso processamento paralelo tambm utilizada algumas vezes com significado quase idntico, exceto pelo fato de que as diferentes mquinas tendem a manter uma certa proximidade fsica em um sistema paralelo e no precisam estar to prximas em um sistema distribudo por exemplo, elas poderiam estar geograficamente dispersas no ltimo caso.) A comunicao entre as vrias mquinas efetuada por algum tipo de software de gerenciamento de rede possivelmente uma extenso do gerenciador DE discutido na Seo 2.9 ou, com maior probabilidade, um componente de software separado. So possveis muitos nveis ou variedades de processamento distribudo. Conforme mencionamos na Seo 2.10, um caso simples envolve a execuo do back end do SGBD (o servidor) em uma das mquinas e dos front ends da aplicao (os clientes) em outra. Ver Figura 2.6. Como vimos no final da Seo 2.10, o termo cliente/servidor, embora seja estritamente uma expresso relacionada com a arquitetura, passou a ser quase um sinnimo da disposio ilustrada na Figura 2.6, na qual o cliente e o servidor funcionam em mquinas diferentes. De fato, h muitos argumentos em favor de um esquema desse tipo: O primeiro basicamente o argumento usual sobre o processamento paralelo: especificamente, muitas unidades de processamento esto sendo agora aplicadas na tarefa global, enquanto o processamento do servidor (o banco de dados) e o processamento do cliente (a aplicao) esto sendo feitos em paralelo. O tempo de resposta e a vazo (throughput) devem assim ser melhorados. Alm disso, a mquina servidora pode ser uma mquina feita por encomenda para se ajustar funo de SGBD (uma mquina de banco de dados) e pode assim fornecer melhor desempenho de SGBD.

143

 Do mesmo modo, a mquina cliente poderia ser uma estao de trabalho pessoal, adaptada s necessidades do usurio final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rpidas e, de modo geral, maior facilidade de utilizao para o usurio.

Vrias mquinas clientes distintas poderiam ser capazes (na verdade, normalmente sero capazes) de obter acesso mesma mquina servidora. Assim, um nico banco de dados poderia ser compartilhado entre vrios sistemas clientes distintos (ver Figura 2.7). Alm dos argumentos anteriores, existe tambm o fato de que a execuo do(s) cliente(s) e do servidor em mquinas diferentes combina com a maneira como as empresas operam na realidade. E bastante comum que uma nica empresa um banco, por exemplo opere muitos computadores, de tal modo que os dados correspondentes a uma parte da empresa sejam armazenados em um computador e os dados de outra parte sejam armazenados em outro computador. Prosseguindo com o exemplo do banco, muito provvel que os usurios de uma agncia precisem ocasionalmente obter acesso a dados armazenados em outra agncia. Portanto, observe que as mquinas clientes poderiam ter seus prprios dados armazenados, e a mquina servidora poderia ter suas prprias aplicaes. Dessa forma, em geral caia maquina atuar como um servidor para alguns usurios e como cliente para outros (ver Figura 2.8); em outras palavras, cada mquina admitir um sistema de banco de dados por inteiro, no sentido estudado em sees anteriores deste captulo. O ltimo ponto a mencionar que uma nica mquina cliente poderia ser capaz de obter acesso a vrias mquinas servidoras diferentes (a recproca do caso ilustrado na Figura 2.7). Esse recurso desejvel porque, como mencionamos antes, as empresas em geral operam de tal maneira que a totalidade de seus dados no fica armazenada em uma nica mquina, mas se espalha por muitas mquinas diferentes, e as aplicaes s vezes precisaro ter a capacidade de conseguir acesso a dados de mais de uma mquina. Basicamente, esse acesso pode ser fornecido de dois modos distintos: Um dado cliente pode ser capaz de obter acesso a qualquer nmero de servidores, mas somente um de cada vez (ou seja, cada requisio individual ao banco de dados tem de ser direcionada para apenas um servidor). Em um sistema desse tipo no possvel, dentro de uma nica requisio, combinar dados de dois ou mais servidores diferentes. Alm disso, o usurio de tal sistema tem de saber qual mquina em particular contm cada um dos fragmentos de dados. O cliente pode ser capaz de obter acesso a muitos servidores simultaneamente (isto , uma nica solicitao ao banco de dados poderia ter a possibilidade de combinar dados de vrios servidores). Nesse caso, os servidores aparentam para o cliente de um ponto de vista lgico ser realmente um nico servidor, e o usurio no precisa saber qual mquina contm cada um dos itens de dados.

144

Esse ltimo caso constitui um exemplo daquilo que se costuma chamar sistema de banco de dados distribudo, O tema de bancos de dados distribudos um grande tpico por si s; levado a sua concluso lgica, o suporte completo a bancos de dados distribudos implica que uma nica aplicao deve ser capaz de operar de modo transparente sobre dados espalhados por uma variedade de bancos de dados diferentes, gerenciados por uma variedade de SGBDs diferentes, funcionando em uma variedade de mquinas distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de comunicaes diferentes onde de modo transparente significa que a aplicao opera, de um ponto de vista lgico, como se os dados fossem todos gerenciados por um nico SGBD funcionando em uma nica mquina. Esse recurso pode parecer algo muito difcil de conseguir, mas altamente desejvel de uma perspectiva prtica, e os fabricantes esto trabalhando arduamente para tornar realidade esses sistemas. Discutiremos em detalhes os sistemas de bancos de dados distribudos no Captulo 20.

145

Normalizao O conceito de normalizao foi introduzido por E. F. Codd em 1970 (primeira forma normal). Esta tcnica um projeto matemtico formal, que tem seus fundamentos na teoria dos conjuntos. Atravs deste processo pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta purificado em relao s anomalias de atualizao (incluso, alterao e excluso) as quais podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados, dependncias parciais em relao a uma chave concatenada, redundncia de dados desnecessrios, perdas acidentais de informao, dificuldade na representao de fatos da realidade observada e dependncias transitivas entre atributos. Os conceitos abordados podem ser aplicados s duas formas de utilizao da normalizao: - sentido de cima para baixo (TOP-DOWN): Aps a definio de um modelo de dados, aplica-se a normalizao para se obter uma sntese dos dados, bem como uma decomposio das entidades e relacionamentos em elementos mais estveis, tendo em vista sua implementao fsica em um banco de dados; - sentido de baixo para cima (BOTTON-UP): Aplicar a normalizao como ferramenta de projeto do modelo de dados, usando os relatrios, formulrios e documentos utilizados pela realidade em estudo, constituindo-se em uma ferramenta de levantamento. Anomalias de Atualizao Observando-se o formulrio de PEDIDO apresentado na fig. 12.1, podemos considerar que uma entidade formada com os dados presentes ter a seguinte apresentao: Atributos da entidade PEDIDO: o nmero do pedido o prazo de entrega o cliente o endereo o cidade o UF o CGC o inscrio estadual o cdigo do produto (*) o unidade do produto (*) o quantidade do produto (*) o descrio do produto (*) o valor unitrio do produto (*) o valor total do produto (*) o valor total do pedido (*) o cdigo do vendedor o nome do vendedor (*) Atributos que se repetem no documento

146

Caso a entidade fosse implementada como uma tabela em um banco de dados, as seguintes anomalias iriam aparecer: anomalia de incluso: ao ser includo um novo cliente, o mesmo tem que estar relacionado a uma venda; anomalia de excluso: ao ser excludo um cliente, os dados referentes as suas compras sero perdidos; anomalia de alterao: caso algum fabricante de produto altere a faixa de preo de uma determinada classe de produtos, ser preciso percorrer toda a entidade para se realizar mltiplas alteraes. Primeira forma normal (1FN) Em uma determinada realidade, s vezes encontramos algumas informaes que se repetem (atributos multivalorados), retratando ocorrncias de um mesmo fato dentro de uma nica linha e vinculadas a sua chave primria. Ao observarmos a entidade PEDIDO, apresentada acima, visualizamos um certo grupo de atributos (produtos solicitados) se repete (nmero de ocorrncias no definidas) ao longo do processo de entrada de dados na entidade. A 1FN diz que: cada ocorrncia da chave primria deve corresponder a uma e somente uma informao de cada atributo, ou seja, a entidade no deve conter grupos repetitivos (multivalorados).

147

Para se obter entidades na 1FN, necessrio decompor cada entidade no normalizada em tantas entidades quanto for o nmero de conjuntos de atributos repetitivos. Nas novas entidades criadas, a chave primria a concatenao da chave primria da entidade original mais o(s) atributo(s) do grupo repetitivo visualizado(s) como chave primria desse grupo. Para a entidade PEDIDO, temos: Entidade no normalizada:

Ao aplicarmos a 1FN sobre a entidade PEDIDO, obtemos mais uma entidade chamada de ITEM-DEPEDIDO, que herdar os atributos repetitivos e destacados da entidade PEDIDO.

148

Um PEDIDO possui no mnimo 1 e no mximo N elementos de ITEM-DE-PEDIDO e um ITEM-DE-PEDIDO pertence a 1 e somente 1 PEDIDO, logo o relacionamento POSSUI do tipo 1:N. Variao Temporal e a Necessidade de Histrico Observamos que normalmente, ao se definir um ambiente de armazenamento de dados, seja ele um banco de dados ou no, geralmente se mantm a ltima informao cadastrada, que s vezes, por sua prpria natureza, possui um histrico de ocorrncias. Mas como a atualizao sempre feita sobre esta ltima informao, perdem-se totalmente os dados passados. A no-observao deste fato leva a um problema na hora de uma auditoria de sistemas, que em vez de utilizar uma pesquisa automatizada sobre os histricos, se v obrigada a uma caada manual cansativa sobre um mar imenso de papeis e relatrios, e que na maioria das vezes se apresenta incompleta ou inconsistente devido a valores perdidos (documentos extraviados) ou no documentados. Com a no-utilizao de histricos e a natural perda destas informaes, a tomada de decises por parte da alta administrao de uma empresa pode levar a resultados catastrficos para a corporao. Toda vez que a deciso de armazenar o histrico de algum atributo for tomada, cria-se explicitamente um relacionamento de um para muitos (1-N), entre a entidade que contm o atributo e a entidade criada para conter o histrico deste atributo. Passa a existir ento uma entidade dependente, contendo (no mnimo) toda data em que houve alguma alterao do atributo bem como o respectivo valor do atributo para cada alterao. A chave desta entidade de histrico ser concatenada, e um de seus atributos ser a data de referncia. 149

Com base nesta necessidade de armazenamento de histricos, aps a aplicao da 1FN devemos observar para cada entidade definida, quais de seus atributos se transformaro com o tempo, se preciso armazenar dados histricos deste atributo e em caso afirmativo, observar o perodo de tempo que devemos conservar este histrico, ou atravs de quantas alteraes foram realizadas neste atributo. Dependncia Funcional Para descrevermos as prximas formas normais, se faz necessria a introduo do conceito de dependncia funcional, sobre o qual a maior parte da teoria de normalizao foi baseada. Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A dependente funcional de um outro atributo B contido na mesma entidade, se a cada valor de B existir nas linhas da entidade em que aparece, um nico valor de A. Em outras palavras, A depende funcionalmente de B. Ex.: Na entidade PEDIDO, o atributo PRAZO-DE-ENTREGA depende funcionalmente de NMERO-DOPEDIDO. O exame das relaes existentes entre os atributos de uma entidade deve ser feito a partir do conhecimento (conceitual) que se tem sobre a realidade a ser modelada. Dependncia Funcional Total (Completa) e Parcial Na ocorrncia de uma chave primria concatenada, dizemos que um atributo ou conjunto de atributos depende de forma completa ou total desta chave primria concatenada, se e somente se, a cada valor da chave (e no parte dela), est associado um valor para cada atributo, ou seja, um atributo no (dependncia parcial) se apresenta com dependncia completa ou total quando s dependente de parte da chave primria concatenada e no dela como um todo. Ex.: dependncia total na entidade ITEM-DO-PEDIDO, o atributo QUANTIDADE-DO-PRODUTO depende de forma total ou completa da chave primria concatenada (NMERO-DO-PEDIDO+CODIGO-DO-PRODUTO). A dependncia total ou completa s ocorre quando a chave primria for composta por vrios (concatenados) atributos, ou seja, em uma entidade chave primria composta de um nico atributo no ocorre este tipo de dependncia. Dependncia Funcional Transitiva Quando um atributo ou conjunto de atributos A depende de outro atributo B que no pertence chave primria, mas dependente funcional desta, dizemos que A dependente transitivo de B. Ex.: dependncia transitiva na entidade PEDIDO, os atributos ENDEREO, CIDADE, UF, CGC e INSCRIOESTATUAL so dependentes transitivos do atributo CLIENTE. Nesta mesma entidade, o atributo NOME-DOVENDEDOR dependente transitivo do atributo CODIGO-DO-VENDEDOR. Com base na teoria sobre as dependncias funcionais entre atributos de uma entidade, podemos continuar com a apresentao das outras formas normais. Segunda Forma Normal (2FN) Devemos observar se alguma entidade possui chave primria concatenada, e para aqueles que satisfizerem esta condio, analisar se existe algum atributo ou conjunto de atributos que dependem desta chave parcial, ou seja, uma entidade para estar na 2FN no pode ter atributos com dependncia parcial em relao chave primria. Ex.: A entidade ITEM-DO-PEDIDO apresenta uma chave primria concatenada e por observao, notamos que os atributos UNIDADE-DO-PRODUTO, DESCRIO-DO-PRODUTO e VALOR-UNITARIO depende de forma parcial do atributo CODIGO-DO-PRODUTO, que faz parte da chave primria. Logo devemos aplicar a 2FN sobre esta entidade. Quando aplicamos a 2FN sobre ITEM-DO-PEDIDO, ser criada a entidade PRODUTO que herdar os atributos UNIDADE-DO-PRODUTO, DESCRIO-DO-PRODUTO e VALOR-UNITRIO e ter como chave primria o CODIGO-DO-PRODUTO. 150

Um PRODUTO participa de no mnimo 1 e no mximo N elementos de ITEM-DE-PEDIDO e um ITEM-DEPRODUTO s pode conter 1 e somente 1 PRODUTO. Logo, o novo relacionamento criado do tipo N:1. Terceira Forma Normal (3FN) Uma entidade est na 3FN se nenhum de seus atributos possui dependncia transitiva em relao a outro atributo da entidade que no participe da chave primria, ou seja, no exista nenhum atributo intermedirio entre a chave primria e o prprio atributo observado. Terceira Forma Normal (3FN) Uma entidade est na 3FN se nenhum de seus atributos possui dependncia transitiva em relao a outro atributo da entidade que no participe da chave primria, ou seja, no exista nenhum atributo intermedirio entre a chave primria e o prprio atributo observado.

151

Ao retirarmos a dependncia transitiva, devemos criar uma nova entidade que contenha os atributos que contenha os atributos que dependem transitivamente de outro e sua chave primria o atributo que causou esta dependncia. Alm de no conter atributos com dependncia transitiva, entidades na 3FN no devem conter atributos que sejam o resultado de algum clculo sobre outro atributo, que de certa forma pode ser encarada como uma dependncia funcional. Ex.: Na entidade PEDIDO, podemos observar que o atributo NOME-DO-VENDEDOR depende transitivamente do atributo CODIGO-DO-VENDEDOR que no pertence chave primria. Para eliminarmos esta anomalia devemos criar a entidade VENDEDOR, com o atributo NOME-DO-VENDEDOR e tendo como chave primria o atributo CODIGO-DO-VENDEDOR. Encontramos ainda o conjunto de atributos formados por ENDEREO, CIDADE, UF, CGC e INSCRIOESTADUAL que dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a entidade VENDEDOR, com o atributo NOME-DO-VENDEDOR e tendo como chave primria o atributo CODIGO-DOVENDEDOR. Encontramos ainda o conjunto de atributos formados por ENDEREO, CIDADE, UF, CGC e INSCRIOESTADUAL que dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a entidade CLIENTE que conter os atributos ENDEREO, CIDADE, UF, CGC e INSCRIO-ESTADUAL. Para chave primria desta entidade vamos criar um atributo chamado CODIGO-DO-CLIENTE que funcionar melhor como chave primria do que NOME-DO-CLIENTE, deixa este ltimo como simples atributo da entidade CLIENTE.

152

Um PEDIDO s feito por um e somente um CLIENTE e um CLIENTE pode fazer de zero (clientes que devem ser contatados mais frequentemente pelos vendedores) at N elementos de PEDIDO. Um PEDIDO s tirado por um e somente um VENDEDOR e um VENDEDOR pode tirar de zero (vendedores que devem ser reciclados em termos de treinamento, para aumentar o poder de venda) a N elementos de PEDIDO. Forma Normal de BOYCE/CODD (FNBC) As definies da 2FN e 3FN, desenvolvidas por Codd, no cobriam certos casos. Esta inadequao foi apontada por Raymond Boyce em 1974. Os casos no cobertos pelas definies de Codd somente ocorrem quando trs condies aparecem juntas: a entidade tenha vrias chaves candidatas; estas chaves candidatas sejam concatenadas (mais de um atributo); as chaves concatenadas compartilham pelo menos um atributo comum. Na verdade, a FNBC uma extenso da 3FN, que no resolvia certas anomalias presentes na informao contida em uma entidade. O problema foi observado porque a 2FN e a 3FN s tratavam dos casos de dependncia parcial e transitiva de atributos fora de qualquer chave, porm quando o atributo observado estiver contido em uma chave (primria ou candidata), ele no captado pelo verificao da 2FN e 3FN. A definio da FNBC a seguinte: uma entidade est na FNBC se e somente se todos os determinantes forem chaves candidatas. Notem que esta definio em termos de chaves candidatas e no sobre chaves primrias. Considere a seguinte entidade FILHO:

153

Por hiptese, vamos assumir que um professor possa estar associado a mais de uma escola e uma sala. Sob esta suposio, tanto a chave (candidata) concatenada NOME-DA-ESCOLA+SALA-DA-ESCOLA bem como NOME-DA-ESCOLA+NOME-DO-PROFESSOR podem ser determinantes. Logo esta entidade atende s trs condies relacionadas anteriormente: as chaves candidatas para a entidade FILHO so: NOME-DO-FILHO+ENDEREO-DO-FILHO+NMERO-DASALA e NOME-DO-FILHO+NOME-DO-PROFESSOR; todas as trs chaves apresentam mais de um atributo (concatenados); todas as trs chaves compartilham um mesmo atributo: NOME-DO-FILHO. Neste exemplo, NOME-DO-PROFESSOR no completamente dependente funcional do NMERO-DASALA, nem NMERO-DA-SALA completamente dependente funcional do NOME-DO-PROFESSOR. Neste caso, NOME-DO-PROFESSOR realmente completamente dependente funcional da chave candidata concatenada NOME-DO-FILHO+NOME-DO-PROFESSOR. Ao se aplicar FNBC, a entidade FILHO deve ser dividida em duas entidades, uma que contm todos os atributos que descrevem o FILHO, e uma segunda que contm os atributos que designam um professor em uma particular escola e nmero de sala.

Quarta Forma Normal (4FN) Na grande maioria dos casos, as entidades normalizadas at a 3FN so fceis de entender, atualizar e de se recuperar dados. Mas s vezes podem surgir problemas com relao a algum atributo no chave, que recebe valores mltiplos para um mesmo valor de chave. Esta nova dependncia recebe o nome de dependncia multivalorada que existe somente se a entidade contiver no mnimo trs atributos. Uma entidade que esteja na 3FN tambm est na 4FN, se ela no contiver mais do que um fato multivalorado a respeito da entidade descrita. Esta dependncia no o mesmo que uma associao M:N entre atributos, geralmente descrita desta forma em algumas literaturas. 154

Ex.: Dada a entidade hipottica a seguir:

Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as diversas peas compradas e os diversos compradores. Com isso apresenta uma dependncia multivalorada entre CODIGOFORNECEDOR e o CODIGO-PEA e entre CDIGO-FORNECEDOR e o CODIGO-COMPRADOR. Embora esteja na 3FN, ao conter mais de um fato multivalor, torna sua atualizao muito difcil, bem como a possibilidade de problemas relativos ao espao fsico de armazenamento poderem ocorrer, causados pela ocupao desnecessria de rea de memria (primria ou secundria), podendo acarretar situaes crticas em termos de necessidade de mais espao para outras aplicaes. Para passarmos a entidade acima para a 4FN, necessria a realizao de uma diviso da entidade original, em duas outras, ambas herdando a chave CODIGO-FORNECEDOR e concatenado, em cada nova entidade, com os atributos CODIGO-PEA e CODIGO-COMPRADOR.

Quinta Forma Normal (5FN) Esta ltima forma normal trata do conceito de dependncia de juno, quando a noo de normalizao aplicada decomposio, devido a uma operao de projeo, e aplicada na reconstruo devido a uma juno. A 5FN trata de casos bastantes particulares, que ocorrem na modelagem de dados, que so os relacionamentos mltiplos (ternrios, quaternrios, ..., n-rios). Ela fala que um registro est na sua 5FN, quando o contedo deste mesmo registro no puder ser reconstrudo (juno) a partir de outros registros menores, extrados deste registro principal. Ou seja, se ao particionar um registro, e sua juno posterior no conseguir recuperar as informaes contidas no registro original, ento este registro est na 5FN. Vamos ilustrar o uso da 5FN utilizando um exemplo de relacionamento ternrio: Ex.: Uma empresa constri equipamentos complexos. A partir de desenhos de projeto desses equipamentos, so feitos documentos de requisies de materiais, necessrios para a construo do equipamento; toda a requisio de um material d origem a um ou mais pedidos de compra. A modelagem deste exemplo, ir mostrar quais materiais de que requisies geraram quais pedidos. Na fig. 12.2 apresentado este relacionamento ternrio.

155

A tabela 2, representante do relacionamento ternrio M-R-P, poderia conter os seguintes dados:

Utilizando uma soma de visualizao da dependncia de juno, obtemos o seguinte grfico de dependncia de juno, mostrado na fig. 12.3.

Uma pergunta surge sobre este problema: possvel substituir o relacionamento ternrio por relacionamentos binrios, como os apresentados na fig. 12.4.

Como resposta, podemos dizer que geralmente no possvel criar esta decomposio sem perda de informao, armazenada no relacionamento ternrio. Realizando uma projeo na tabela anterior, chegamos s entidades apresentadas na fig. 12.5.

156

Se realizarmos, agora, um processo de juno destas trs entidades, teremos: Inicialmente, vamos juntar a entidade 1 com a entidade 2, atravs do campo pedido de compra. Obtemos ento a entidade 4, mostrada na fig. 12.6:

Podemos observar que o registro apontado pela seta no existia na tabela original, ou seja, foi criado pela juno das tabelas parciais. Devemos juntar a entidade 4, resultante da primeira juno, com a entidade 3, atravs dos campos material e requisio. Aps esta ltima operao de juno, obtemos a entidade 5, mostrada na fig. 12.7.

157

Como se pode notar, ao se juntar as trs entidades, fruto da decomposio da entidade original, as informaes destas foram preservadas. Isto significa que o relacionamento M-R-P no est na 5FN, sendo necessrio decomp-lo em relacionamento binrios, os quais estaro na 5FN. A definio da 5FN diz que: uma relao de 4FN estar em 5FN, quando seu contedo no puder ser reconstrudo (existir perda de informao) a partir das diversas relaes menores que no possuam a mesma chave primria. Esta forma normal trata especificamente dos casos de perda de informao, quando da decomposio de relacionamentos mltiplos. Com a 5FN, algumas redundncias podem ser retiradas, como a informao de que o ROTOR 1BW est presente na requisio R3192, ser armazenada uma nica vez, a qual na forma no normalizada pode ser repetida inmeras vezes. Roteiro de Aplicao da Normalizao Entidade ou documento no normalizado, apresentando grupos repetitivo e certas anomalias de atualizao. Aplicao da 1FN - Decompor a entidade em uma ou mais entidades, sem grupos repetitivos; - Destacar um ou mais atributos como chave primria da(s) nova(s) entidade(s), e este ser concatenado com a chave primria da entidade original; - Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s) gerada(s) e a entidade geradora; - Verificar a questo da variao temporal de certos atributos e criar relacionamentos 1:N entre a entidade original e a entidade criada por questes de histrico. Entidades na 1FN Aplicao da 2FN - Para entidades que contenham chaves primrias concatenadas, destacar os atributos que tenham dependncia parcial em relao chave primria concatenada; - Criar uma nova entidade que conter estes atributos, e que ter como chave primria o(s) atributo(s) do(s) qual(quais) se tenha dependncia parcial; - Sero criadas tantas entidades quanto forem os atributos da chave primria concatenada, que gerem dependncia parcial; - Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s) gerada(s) e a entidade geradora. Entidades na 2FN - Verificar se existem atributos que sejam dependentes transitivos de outros que no pertencem chave primria, sendo ela concatenada ou no, bem como atributos que sejam dependentes de clculo realizado a partir de outros atributos; - Destacar os atributos com dependncia transitiva, gerando uma nova entidade com este atributo e cuja chave primria o atributo que originou a dependncia; 158

- Eliminar os atributos obtidos atravs de clculos realizados a partir de outros atributos. Entidades na 3FN aplicao da FNBC - S aplicvel em entidades que possuam chaves primrias e candidatas concatenadas; - Verificar se alguma chave candidata concatenada um determinante, e em caso afirmativo, criar uma entidade com os que dependam funcionalmente deste determinante e cuja chave primria o prpria determinante. Entidades na FNBC - Aplicao da 4FN - Para se normalizar em 4FN, a entidade tem que estar (obrigatoriamente) na 3FN; - Verificar se a entidade possui atributos que no sejam participantes da chave primria e que sejam multivalorados e independentes em relao a um mesmo valor da chave primria; - Retirar estes atributos no chaves e multivalorados, criando novas entidades individuais para cada um deles, herdando a chave primria da entidade desmembrada. Entidades na 4FN - aplicao da 5FN - Aplicada em elemento que estejam na 4FN; - A ocorrncia deste tipo de forma normal est vinculada aos relacionamentos mltiplos (ternrios, etc.) ou entidades que possuam chave primria concatenada com trs ou mais atributos; - Verificar se possvel reconstruir o contedo do elemento original a partir de elementos decompostos desta; - Se no for possvel, o elemento observado no est na 5FN, caso contrrio os elementos decompostos representam um elemento na 5FN. Entidades na forma normal final O processo de normalizao leva ao refinamento das entidades, retirando delas grande parte das redundncias e inconsistncias. Naturalmente, para que haja uma associao entre entidades preciso que ocorram redundncias mnimas de atributos que evidenciam estes relacionamentos entre entidades. Desnormalizao Parece um tanto quanto incoerente apresentar um item falando sobre desnormalizao. Porm os processos de sntese de entidades vistos at aqui levam criao de novas entidades e relacionamentos. Os novos elementos criados podem trazer prejuzos na hora de serem implementados em um SGBD. Devido as caractersticas de construo fsica de certos banco de dados, algumas entidades e relacionamentos devem ser desnormalizados para que o SGBD tenha um melhor desempenho. Hoje em dia, existe um grande debate sobre as chamadas semnticas da normalizao, sua utilidade e facilidade em relao implementao fsica em um sistema operacional. Vrios estudos e algumas consideraes esto sendo realizados, e se chega at a utilizao de banco de dados relacionais no normalizados, por apresentarem maior ligao com a realidade e por terem vnculos matemticos mais amenizados. Outro aspecto da normalizao que todas as definies sobre as formas normais aps a 1FN, ainda no foram exaustivamente examinadas, propiciando assim grandes controvrsias. A reduo das anomalias de atualizao devido s formas normais de alta ordem sofre os ataques bvios dos grandes problemas (fsicos) de atualizao, pois as relaes esto excessivamente normalizadas e com isso uma simples alterao pode encadear um efeito cascata bastante profundo no banco de dados, ocasionando um aumento bastante significativo no tempo.

159

Infelizmente, os argumentos que podem viabilizar o processo de desmoralizao sofrem de uma deficincia e aderncia matemtica. Pesquisas recentes indicam que as estruturas desnormalizadas (apelidadas de forma normal no primeira) tm um atrativo matemtico similar ao que foi o da normalizao. Estas pesquisas esto provendo recentes definies sobre lgebra relacional desnormalizada e extenses linguagem SQL para a manipulao de relaes desnormalizadas. Ao se optar pela desnormalizao, deve-se levar em conta o custo da redundncia de dados e as anomalias de atualizao decorrentes. Chegou-se concluso tambm que o esprito da normalizao contradiz vrios princpios importantes, relativos modelagem semntica e construo de bases de dados em SGBD orientados por objeto. Consideraes Finais sobre Normalizao Antes de qualquer concluso, podemos observar que as formas normais nada mais so do que restries de integridade, e medida que se alimenta este grau de normalizao, torna-se cada vez mais restritivas. Dependendo do SGBD relacional utilizado, essas restries podem se tornar benficas ou no. A forma de atuao da normalizao no ciclo de vida de um projeto de banco de dados pode ser mais satisfatria no desenvolvimento (botton-up) de modelos preliminares, a partir da normalizao da documentao existente no ambiente analisado, bem como de arquivos utilizados em alguns processos automatizados neste ambiente. No caso do desenvolvimento top-down, no qual um modelo de dados criado a partir da visualizao da realidade, a normalizao serve para realizar um aprimoramento deste modelo, tornando-o menos redundante e inconsistente. No caso desta viso, a normalizao torna-se um poderoso aliado da implementao fsica do modelo. Por experincia, podemos afirmar que a construo de um modelo de dados j leva naturalmente ao desenvolvimento de entidades e relacionamentos na 3FN, ficando as demais (FNBC, 4FN, e 5FN) para melhorias e otimizaes. A criao de modelos de dados, partindo-se da normalizao de documentos e arquivos pura e simplesmente, no o mais indicado, pois na verdade estaremos observando o problema e no dando uma soluo para ele. Neste caso, estaremos projetando estruturas de dados que se baseiam na situao atual (muitas vezes catica) e que certamente no vo atender s necessidades reais do ambiente em anlise. Ao passo que, se partimos para a criao do modelo de dados com entidades e relacionamentos aderentes realidade em estudo (mundo real), vamos naturalmente desenvolver uma base de dados ligada viso da realidade e como consequncia iremos solucionar o problema de informao. A aplicao da modelagem de dados, ao longo da nossa vida profissional, tem sido bastante gratificante, mostrando principalmente, que a tcnica de normalizao uma ferramenta muito til como apoio ao desenvolvimento do modelo de dados. Seja ela aplicada como levantamento inicial (documentos e arquivos) bem como otimizador do modelo de dados, tendo em vista certas restries quanto implementao fsica nos banco de dados conhecidos. Todas as ideias sobre eficincia da normalizao passam necessariamente sobre tempo e espao fsico, em funo, principalmente, das consultas efetuadas pelos usurios bem como a quantidade de bytes necessrios para guardar as informaes. Nota-se, atravs da observao, que o projeto do modelo conceitual nem sempre pode ser derivado para o modelo fsico final. Com isso, de grande importncia que o responsvel pela modelagem (analista, AD, etc.) no conhea s a teoria iniciada por Peter Chen, mas tambm tenha bons conhecimentos a respeito do ambiente do banco de dados utilizado pelo local em anlise.

160

Regras de Integridade As regras de integridade fornecem a garantia de que mudanas feitas no banco de dados por usurios autorizados no resultem em perda de consistncia de dados. Assim, as regras de integridade protegem o banco de dados de danos acidentais. J vimos regras de integridade para o modelo E-R. Essas regras possuem a seguinte forma: Declarao de variveis a determinao de certos atributos, como chave candidata, para um dado conjunto de entidades. O conjunto de inseres e atualizaes vlidas restrito quelas que no criem duas entidades com o mesmo valor de chave candidata. Forma de um relacionamento muitos para muitos, um para muitos, um para um. O conjunto de relacionamentos um para um ou um para muitos restringe o conjunto de relacionamentos vlidos entre os diversos conjuntos de entidades. Em geral, uma regra de integridade constitui um predicado arbitrrio pertencente ao banco de dados. Entretanto, predicados arbitrrios podem representar altos custos para serem testados. Assim, normalmente, as regras de integridade so limitadas s que podem ser verificadas com o mnimo tempo de processamento. Restries de Domnios Vimos que um domnio de valores vlidos pode ser associado a qualquer atributo. Vimos tais restries so especificadas em SQL DDL. Restries de domnio so as mais elementares formas de restries de integridade. Elas so facilmente verificadas pelo sistema sempre que um novo item de dado incorporado ao banco de dados. possvel que diversos atributos tenham um mesmo domnio. Por exemplo, os atributos nome_cliente e nome_empregado podem ter o mesmo domnio: o conjunto de todos os nomes de pessoas. Entretanto, os domnios de saldo e nome_agncia certamente sero distintos. Ser, talvez, menos claro o caso nome_cliente e nome_agncia que podem ter o mesmo domnio. No nvel de implementao, os nomes de agncia e clientes so strings de caracteres. No entanto, essas linguagens inibem os quebra-galhos, que so frequentemente necessrios na programao de sistemas. Uma vez que os sistemas de banco de dados so projetados para atender a diversos usurios que no so especialistas em banco de dados, os benefcios de tipos fortemente definidos geralmente apresentam mais desvantagens do que vantagens. Apesar disso, muito dos sistemas existentes permitem apenas um reduzido nmero de domnios de tipos. Poucos sistemas, particularmente os sistemas de banco de dados orientado a objeto, oferecem um conjunto rico de tipos de domnios que podem ser facilmente ampliados. A clusula check da SQL-92 permite modos poderosos de restries de domnios que a maioria dos sistemas de tipos das linguagens de programao no permite. Especificamente, a clusula check permite ao projeto do esquema determinar um predicado que deva ser satisfeito por qualquer valor designado a uma varivel cujo tipo seja o domnio. Por exemplo, uma clusula check pode garantir que o domnio relativo ao turno de trabalho de um operrio contenha somente valores maiores que um dado valor (turno mnimo), como ilustrado aqui: create domain turno_trabalho numeric (5,2) o domnio de turno_trabalho declarado como um nmero decimal com um total de cinco dgitos, dois dos quais colocados aps o ponto decimal, e o domnio possui uma restrio que assegura que o turno de trabalho no seja inferior a 4,00. A clusula constraint valor_teste_turno opcional e usada para dar o nome valor_teste_turno restrio. O nome usado para indicar quais restries foram violadas em determinada atualizao. A clusula check pode tambm ser usada para restringir os valores nulos em um domnio, como ilustrado a seguir:

161

Como outro exemplo, o domnio pode ser restrito a determinado conjunto de valores por meio do uso da clusula in:

Integridade Referencial Frequentemente, desejamos garantir que um valor que aparece em uma relao para um dado conjunto de atributos tambm aparea para um certo conjunto de atributos de outra relao. Essa condio chamada integridade referencial Conceitos Bsicos Considere um par de relaes r(R) e s(S) e a juno natural . Pode existir uma tupla tr em r que no possa ser combinada a nenhuma tupla em s. Isto , no existe nenhum tS em s tal que . Tais tuplas so chamadas de tuplas pendentes. Dependendo do conjunto de entidades ou relacionamentos que est sendo modelado, tuplas pendentes podem ou no ser aceitveis. Sabemos que existe um tipo diferente de juno a juno externa para operar relaes contendo tuplas pendentes. No estamos abordando consultas aqui, mas o modo de tratar a existncia, quando desejada, de tuplas pendentes no banco de dados. Suponha que exista a tupla t1 na relao conta, com t1[nome_agncia] = Lunartown, mas que no haja nenhuma tupla na relao agncia para Lunartown. Essa situao pode ser indesejvel. Esperamos que a relao agncia possua todas as agncias do banco. Portanto, a tupla t1 faz referncia a uma conta de uma agncia inexistente. Obviamente, gostaramos de implementar uma regra de integridade que proba tuplas pendentes desse tipo. No entanto, nem todos os tipos de tuplas pendentes so indesejveis. Suponha que exista uma tupla t2 na relao agncia, com t2[nome_agncia]= Mokan, mas no h nenhuma tupla da relao conta com referncia agncia Mokan. Nesse caso, existe uma agncia que no possui nenhum conta. Embora essa seja uma situao incomum, pode ocorrer quando uma agncia est sendo aberta ou fechada. Assim, no devemos proibir esse tipo de situao. A diferena entre esses dois exemplos tem origem em dois fatos: O atributo nome_agncia do Esquema_conta uma chave estrangeira (foreign key) cuja referncia a chave primria do Esquema_agncia. O atributo nome_agncia do Esquema_agncia no uma chave estrangeira. No exemplo de Lunartown, a tupla t1 de conta tem um valor para a chave estrangeira nome_agncia que no aparece em agncia. No exemplo da agncia Mokan, a tupla t2 de agncia tem um valor nome_agncia que no aparece em conta, mas nome_agncia no uma chave estrangeira. Assim, a diferena entre nossos dois exemplos de tuplas pendentes a existncia de uma chave estrangeira. Seja r1(R1) e r2(R2) relaes com chaves primrias K1 e K2, respectivamente. Dizemos que um subconjunto de R2 uma chave estrangeira associada a K1 em relao a r1 se garantido que, para todo t2 em r2, existe uma tupla t1 em r1, tal que t1[K1] = t2[]. Exigncias desse tipo so chamadas de regras de integridade referencial ou subconjunto dependente. O ltimo termo advm do fato de ser possvel escrever a regra de integridade referencial anterior como deve ser igual a K1. (r1). Note que, para a regra de integridade referencial ter sentido, cada

Integridade Referencial no Modelo E-R Regras de integridade referencial aparecem com frequncia. Se derivarmos nosso esquema de bancos de dados relacional em tabelas originadas de diagramas E-R, ento toda relao resultante de um conjunto de relacionamentos possui regras de integridade referencial. A fig. 6.1 mostra um conjunto de relacionamentos R de 162

n elementos, relacionando os conjuntos de entidades E1, E2, ..., En. Seja Ki a chave primria de Ei. Os atributos para o esquema da relao referente ao conjunto de relacionamentos R incluem K1K2... Kn. Cada Ki do esquema de R uma chave estrangeira que leva a uma regra de integridade referencial.

Outra fonte de regras de integridade referencial so os conjuntos de entidades fracas. Vimos que o esquema da relao para um conjunto de entidades fracas precisa incluir a chave primria do conjunto de entidades do qual ele dependente. Assim, o esquema da relao para cada conjunto de entidades fracas inclui uma chave estrangeira que leva a uma regra de integridade referencial. Modificaes no Banco de Dados As modificaes no banco de dados podem originar violao das regras de integridade referencial. Colocamos aqui a verificao necessria a cada tipo de modificao no banco de dados para que se possa preservar a seguinte regra de integridade referencial: Insero. Se uma tupla t2 inserida em r2, o sistema deve garantir que exista uma tupla t1 em r1 tal que t1[K]=t2[]. Isto : Remoo. Se uma tupla t1 removida de r1, o sistema deve tratar tambm no conjunto de tuplas em r2 que so referidos por t1: . Se esse conjunto vazio, o comando de remoo foi rejeitado devido a algum erro ou a tupla que faz referncia a t1 deve ser removida. Esta ltima alternativa pode levar a uma remoo em cascata se algumas tuplas fizerem referncia a tuplas que se referem a t1 e assim por diante. Atualizao. Precisamos considerar duas situaes de atualizaes: as que se referem relao (r2) e as referidas pela relao (r1). o Se uma tupla t2 da relao r2 atualizada e a atualizao modifica os valores da chave estrangeira , ento feita uma verificao similar insero. Seja t2 o novo valor da tupla t2. O sistema o dever assegurar que: Se uma tupla t1 da relao r1 atualizada e a atualizao modifica os valores de uma chave primria (K), ento dever ser feito um teste similar ao realizado para a remoo. O sistema dever computar usando o valor antigo de t1 (o valor existente antes da aplicao da atualizao). Se esse conjunto no for vazio, a atualizao ser rejeitada como uma ocorrncia de erro ou as atualizaes sero realizadas em cascata, de modo similar ao que ocorre na remoo. Integridade Referencial em SQL possvel definir chaves primrias, secundrias e estrangeiras como parte do comando create table da SQL: 163

A clusula primary key do comando create table inclui a lista dos atributos que constituem a chave primria. A clusula unique do comando create table inclui a lista dos atributos que constituem uma chave candidata. A clusula foreign key do comando create table inclui a lista dos atributos que constituem a chave estrangeira quanto o nome da relao qual a chave estrangeira faz referncia.

Ilustramos as declaraes de chaves estrangeiras e primrias usando definies de parte de nosso banco em SQL DDL, mostrado na fig. 6.2. Note que no nos detivemos em modelar de modo preciso o mundo real no exemplo do banco de dados de uma empresa da rea bancria. No mundo real, diversas pessoas podem ter o mesmo nome, assim nome_cliente no pode ser chave primria para cliente. No mundo real, alguns outros atributos, como o nmero do seguro social, ou uma combinao de atributos como nome e endereo, poderiam ser usados como chave primria. Usamos nome_cliente como chave primria para conferir simplicidade e conciso a nosso esquema de banco de dados. Podemos usar a forma simplificada para declarar que uma nica coluna uma chave estrangeira: A SQL tambm d suporte a uma outra maneira de formular a clusula chave estrangeira, em que uma lista de atributos da relao por ela referida pode ser explicitamente especificada, e esses atributos so usados no lugar da chave primria; essa lista de atributos precisa ser declarada como chave candidata de uma relao referida.

Quando uma regra de integridade referencial violada, o procedimento normal rejeitar a ao que ocasionou essa violao. Entretanto, a clusula relativa a foreign key em SQL-92 pode especificar que, se uma remoo ou atualizao na relao a que ela faz referncia violar uma regra de integridade, ento, em vez de rejeitar a ao, executam-se passos para modificao da tupla na relao que contm a referncia, de modo a garantir a regra de integridade. Considere a seguinte definio de regra de integridade para a relao conta: 164

Devido clusula on delete cascade associada declarao da chave estrangeira, se a remoo de uma tupla de agncia resultar na violao da regra de integridade anterior, a remoo no ser rejeitada. Ao contrrio, a remoo feita em cascata na relao conta, de modo que as tuplas que se referirem a uma agncia removida sejam tambm removidas. De modo similar, a atualizao de um campo referido por uma regra de integridade no ser rejeitada se ela violar uma regra de integridade; pelo contrrio, o campo nome_agncia das tuplas da relao conta ser tambm atualizado. A SQL-92 permite, tambm, que a clusula foreign key especifique outros tipos de aes alm de cascata, como alterar o campo em questo (no caso, nome_agncia) com nulos, ou um valor-padro, caso a regra seja violada. Se houver uma cadeia de dependncias entre chaves estrangeiras de diversas relaes, uma remoo ou uma atualizao em uma das extremidades poder propagar-se ao longo de toda a cadeia. Se uma atualizao ou remoo em cascata provoca a violao de uma regra de integridade que no pode ser tratada por uma operao de cascata seguinte, o sistema aborta a transao. Como resultado, todas as mudanas causadas pela transao, assim como as aes em cascata decorrentes, sero desfeitas. A semntica de chaves em SQL torna-se mais complexa pelo fato da SQL permitir valores nulos. As seguintes regras, algumas das quais arbitrrias, so usadas para tratar esses valores nulos. Todos os atributos de uma chave primria so declarados implicitamente como not null. Atributos de uma declarao unique (isto , atributos de uma chave candidata) podem ser nulos, contanto que no sejam declarados no-nulos de outro modo. A restrio para garantia da unicidade em uma relao violada somente se duas tuplas da relao tm o mesmo valor para todos os atributos da regra unique e todos os valores forem no-nulos. Assim, qualquer nmero de tuplas pode ser igual em todas as colunas declaradas como nicas, sem que haja violao da regra de integridade, contanto que ao menos uma das colunas tenha um valor nulo. Atributos nulos em chaves estrangeiras so permitidos, contanto que no tenha sido declarados como no-nulos de outro modelo. Se todas as colunas de uma chave estrangeira so no-nulas em uma determinada tupla, a definio usual de regra de integridade em chave estrangeira ser empregada naquela tupla. Se qualquer uma das colunas da chave nula, a tupla automaticamente aprovada na regra de integridade. Essa definio arbitrria e nem sempre uma boa opo, assim a SQL fornece, tambm, construtores que possibilitam mudana de comportamento em relao aos valores nulos. Dada a complexidade e arbitrariedade natural das formas e comportamentos de restries (ou regras) de integridade SQL em relao a valores nulos, melhor assegurar que todas as colunas especificadas em unique e foreign key sejam declaradas, no permitindo nulos. Asseres Uma assero um predicado que expressa uma condio que desejamos que seja sempre satisfeita no banco de dados. Restries de domnio e regras de integridade referencial so formas especiais de asseres. Dispensamos substancial ateno a essas formas de asseres, porque so facilmente verificadas e aplicadas em grande parte das aplicaes em banco de dados. Entretanto, existem muitas restries que no podem ser expressas usando somente essas formas especiais. Exemplos dessas restries compreendem: A soma de todos os totais em conta emprstimo de cada uma das agncias deve ser menor que a soma de todos os saldos da contas dessa agncia. 165

Todo emprstimo deve ter ao menos um cliente que mantenha uma conta com saldo mnimo de mil dlares. Uma assero em SQL-92 toma a seguinte forma:

As duas regras mencionadas podem ser escritas como mostrado a seguir. J que a SQL no oferece um construtor para todo X, P(X) (em que P um predicado), somos forados a implementar o construtor usando o construtor no existe X tal que nenhum P(X), pode ser escrito em SQL.

Quando uma assero criada, o sistema verifica sua validade. Se as asseres so vlidas ento qualquer modificao posterior no banco de dados ser permitida somente quando a assero no for violada. Quando as asseres so complexas, a verificao pode gerar um aumento significativo em tempo de processamento. Por isso, as asseres so usadas com muito cuidado. Esse grande overhead para teste e manuteno de asseres tem levado alguns profissionais ligados ao desenvolvimento de sistemas de banco de dados a excluir as asseres gerais ou a fornecer apenas formas especiais de asseres, que possam ser verificadas facilmente. Gatilhos (Triggers) Um gatilho um comando que executado pelo sistema automaticamente, em consequncia de uma modificao no banco de dados. Duas exigncias devem ser satisfeitas para a projeo de um mecanismo de gatilho: 1. Especificar as condies sob as quais o gatilho deve ser executado. 2. Especificar as aes que sero tomadas quando um gatilho for disparado. Os gatilhos so mecanismos teis para avisos a usurios ou para executar automaticamente determinadas tarefas quando as condies para isso so criadas. Como ilustrao, suponha que, em vez de permitir saldos negativos em conta, o banco crie condies para que a conta corrente seja zerada e o saldo negativo seja transferido para uma conta emprstimo. Essa conta emprstimo ter o mesmo nmero da conta corrente em questo. Para esse exemplo, a condio para o disparo de um gatilho uma atualizao na relao conta que resulta em um valor negativo para saldo. Suponha que Jones tenha feito um resgate em uma conta que gerou um saldo negativo. Suponha que t denote a tupla de conta com um valor negativo para saldo. As aes a tomar so as seguintes: Inserir uma nova tupla s na relao emprstimo com:

166

(Note que, se t[saldo] for negativo, impedimos que t[saldo] receba um valor positivo em um total de emprstimo.) Inserir uma nova tupla u na relao devedor com:

Tornar t[saldo] igual a 0.

O padro SQL-92 no dispe de gatilhos, embora a proposta original da SQL do Sistema R proponha alguns recursos para gatilhos. Alguns sistemas existentes possuem seus prprios recursos de gatilho no padronizados. Ilustraremos, aqui, como um gatilho para saldo negativo poderia ser escrito na verso original de SQL.

167

A palavra-chave new usada antes de T.saldo indica que o valor de T.saldo aps a atualizao dever ser usado; se ele for omitido, o valor existente antes da atualizao ser, ento, usado. Os gatilhos so chamados, algumas vezes, de regras (rules), ou regras ativas (active rules), mas no devem ser confundidos com as regras da Datalog, que tratam realmente de definies de vises. Dependncia Funcional A noo de dependncia funcional uma generalizao da noo de chave. Dependncias funcionais representam um papel importante no projeto de banco de dados. Conceitos Bsicos Dependncias funcionais so restries ao conjunto de relaes vlidas. Elas permitem expressar determinados fatos em nosso banco de dados relativos empresa que desejamos modelar. Eis o conceito de superchave como segue. Seja R o esquema de uma relao. Um subconjunto K de R uma superchave de R em qualquer relao vlida r(R) para todos os pares de t1 e t2 de tuplas em r tal que t1t2, ento t1[K]t2[K]. isto , nenhum par de tuplas em qualquer relao validade r(R) deve ter o mesmo valor no conjunto de atributos K. A noo de dependncia funcional generaliza a noo de superchave. Seja R e R. A dependncia funcional: realiza-se em R se, em qualquer relao validade r(R), para todos os pares de tuplas t1 e t2 em r, tal que t1[] = t2[], t1[] = t2[] tambm ser verdade. Usando a notao de dependncia funcional, dizemos que K uma superchave de R se K R. isto , K uma superchave se, para todo t1[K]=t2[K], t1[R]=t2[R] (isto , t1=t2). A dependncia funcional permite-nos expressar restries que as superchaves no expressam. Considere o esquema: esquema_info_emprstimo=(nome_agncia, nmero_emprstimo, nome_cliente, total) O conjunto de dependncias funcionais que queremos garantir para esse esquema relao :

Entretanto, no esperamos realizar dependncia funcional para: j que, em geral, um emprstimo pode ser contrado por mais de um cliente (por exemplo, para ambos os membros de um casal, marido-mulher). Podemos usar dependncia funcional de dois modos: 1. Usando-as para o estabelecimento de restries sobre um conjunto de relaes vlidas. Devemos, assim, concentr-las somente quelas relaes que devem satisfazer um dado conjunto de dependncias funcionais. Se desejarmos restringi-las a relaes do esquema R que satisfaam um conjunto F de dependncias funcionais, dizemos que F realiza-se em R. 2. Usando-as para verificao de relaes, de modo a saber se as ltimas so vlidas sob um dado conjunto de dependncias funcionais. Se desejarmos restringi-las a relaes do esquema R que satisfaam um conjunto F de dependncias funcionais, dizemos que r satisfaz F. Consideremos a relao r da fig. 6.3 para verificar quais dependncias funcionais so satisfeitas. Observe que A C satisfeita. Duas tuplas tm valor a1 em A. essas tuplas tm um mesmo valor de C denominado cI. de modo similar, duas tuplas com valor a2 em A tm mesmo valor c2 em C, mas eles possuem valor diferentes em A, a2 e a3, respectivamente. Assim, encontramos um par de tuplas t1 e t2 tal que t1[C]=t2[C], mas t1[A]t2[A].

168

Diversas outras dependncias funcionais so satisfeitas por r, incluindo, por exemplo, a dependncia funcional AB D. Note que usamos AB como notao simplificada para [A,B], reduzindo-se a um padro mais prtico. Observe que no existe nenhum par de tuplas distintas t1 e t2 tal que t1[AB]=t2[AB]. Portanto, se t1[AB]=t2[AB], entoa necessrio que t1=t2 e, assim, t1[D]=t2[D]. Logo, r satisfaz AB D. Algumas dependncias funcionais so consideradas triviais porque so satisfeitas por todas as relaes. Por exemplo, A A satisfeita por todas as relaes que contm o atributo A. Na leitura literal da definio de dependncia funcional, podemos notar que, para todos os atributos t1 e t2 tal que t1[A]=t2[A] ser tambm verdade. De modo similar, AB A satisfeita para todas as relaes envolvendo o atributo A. Em geral, uma dependncia funcional da forma trivial se . Para distinguir os conceitos de uma relao que satisfaz uma dependncia e de uma dependncia realizando-se em um esquema, retornaremos ao exemplo do banco. Se considerarmos a relao cliente (com o esquema_cliente), como mostrado na fig. 6.4, notamos que rua_cliente cidade_cliente satisfeita. Entretanto, acreditamos que, no mundo real, duas cidades podem possuir duas ou mais ruas com o mesmo nome. Assim, possvel, em algum tempo, haver uma instncia da relao cliente na qual rua_cliente cidade_cliente no satisfeita. Logo, no incluiremos rua_cliente cidade_cliente no conjunto das dependncias funcionais que so realizadas no Esquema_cliente.

Na relao emprstimo (do esquema_emprstimo) na fig. 6.5, vemos que nmero_emprstimo total satisfeita. Ao contrrio do que ocorre em cidade_cliente e rua_cliente no esquema_cliente, acreditamos que, em empresas reais, eles so modelados de modo a garantir que cada conta tenha somente um total. Portanto, queremos que a condio nmero_emprstimo total seja sempre satisfeita para a relao emprstimo. Em outras palavras, necessitamos da restrio nmero_emprstimo total para o esquema_emprstimo.

169

Na relao agncia da fig. 6.6, vemos que nome_agncia fundos satisfeita, assim como fundos nome_agncia. Gostaramos de garantir que nome_agncia fundos fosse realizada em esquema_agncia. Entretanto, no queremos que fundos nome_agncia seja realiza, uma vez que possvel haver diversas agncias com o mesmo valor de fundos. Embora a SQL no fornea um modo simples para especificao de dependncia funcional podemos escrever consultas para verificao de dependncias funcionais, assim como criar asseres para garantia de dependncias funcionais.

Conforme segue, consideramos que, quando projetamos um banco de dados relacional, primeiro relacionamos as dependncias funcionais que sempre precisam ser realizadas. No exemplo do banco, nossa relao de dependncias funcionais engloba as seguintes: No esquema_agncia: nome_agncia cidade_agncia nome_agncia fundos No esquema_cliente: nome_cliente cidade_cliente nome_cliente rua_cliente No esquema_emprstimo: nmero_emprstimo total nmero_emprstimo nome_agncia No esquema_devedor: nenhuma dependncia funcional

170

No esquema_conta: nmero_conta nome_agncia nmero_conta saldo No esquema_depositante: nenhuma dependncia funcional

Clausura de um Conjunto de Dependncias Funcionais No basta considerar um dado conjunto de dependncias funcionais. preciso considerar todos os conjuntos de dependncias funcionais que so realizados. Podemos mostrar que, dado um conjunto F de dependncias funcionais, prova-se que outras dependncias funcionais realizam-se. Dizemos que esse tipo de dependncia funcional logicamente implcito em F. Suponha um dado esquema de relao R = (A, B, C, G, H, I) o conjunto de dependncias funcionais: A B A C CG H CG I B H A dependncia funcional: A H logicamente implcita. Isto , podemos mostrar que, sempre que um dado conjunto de dependncias funcionais se realiza, A H tambm se realiza. Suponha que t1 e t2 so duas tuplas, tais que: t1[A] = t2[A] J que dado que A B, dessa definio de dependncia funcional decorre que: t1[B] = t2[B] Ento, desde que B H seja dada, decorre desta definio de dependncia funcional que: t1[H]=t2[H] Portanto, mostramos que, sempre que t1 e t2 forem tuplas, tais que t1[A]=t2[A], necessariamente t1[H] = t2[H]. Mas essa exatamente a definio de A H. Seja F um conjunto de dependncias funcionais. A clausura de F o conjunto de todas as dependncias funcionais logicamente implcitas em F. Denotamos a clausura de F por F+. Dado F, podemos computar F+ diretamente da definio formal de dependncia funcional. Se F for grande, esse processo pode tornar-se lento e difcil. Tal qual a computao de F+, exige argumentos do tipo dado anteriormente para mostrar que A H est em clausura em nosso conjunto de exemplo de dependncias. Existem tcnicas mais simples para o raciocnio da dependncia funcional. A primeira tcnica tem por base trs axiomas ou regras para inferncia da dependncia funcional. Para aplicao dessas regras, precisamos encontrar todos os F+ de um dado F. Nas regras a seguir, adotamos a conveno do uso de letras gregas para conjuntos de atributos e de letras maisculas do alfabeto romano para atributos individuais. Usamos para denotar . Regra de reflexividade. Se um conjunto de atributos e , ento realiza-se. Regra de incremento. Se realiza-se e um conjunto de atributos, ento tambm realizase. Regra de transitividade. Se realiza-se e realiza-se, ento realiza-se.

171

Essas regras so slidas, porque elas no geram nenhuma dependncia funcional incorreta. As regras so completas, porque, para um dado conjunto F de dependncias funcionais, elas nos permitem criar todo F+. Para simplificar, relacionamentos regras adicionais: Regra de unio. Se e , ento tambm realiza-se. Regra de decomposio. Se realiza-se, ento e tambm realizam-se. Regra pseudotransitiva. Se e , ento tambm realiza-se. Apliquemos nossas regras ao esquema do exemplo apresentado anteriormente R=(A, B, C, G, H, I) e ao conjunto F de dependncias funcionais {A B, A C, CG H, CG I, B H}. Relacionamos diversos membros de F+ aqui: A H. Desde que A B e B H realizam-se, aplicamos a regra da transitividade. Observe que foi mais fcil aplicar os axiomas de Armstrong para mostrar que A H se realiza do que raciocinando diretamente sobre as definies, como fizemos anteriormente. CG HI. J que CG H e CG I, a regra da pseudotransitividade implica a realizao de AG I. Clausura de Conjunto de Atributos Para verificar se um conjunto uma superchave, precisamos conceber um algoritmo para computar o conjunto de atributos determinados funcionalmente por . Podemos deduzir que esse algoritmo tambm til como parte do processamento da clausura de um conjunto de dependncias funcionais F. Seja um conjunto de atributos. Chamamos o conjunto dos atributos funcionalmente determinados por , sob um conjunto de dependncias funcionais F, de clausura de sob F, denotada por +. A fig. 6.7 mostra um algoritmo, escrito em pseudo-Pascal, para computar +. O conjunto de dependncias funcionais F e o conjunto de atributos funcionam como entrada. A sada armazenada na varivel resultado. Para ilustrao de como o algoritmo da fig. 6.7 funciona, iremos us-lo para processar (AG)+ com as dependncias funcionais definidas anteriormente. Comearemos com resultado = AG. A primeira execuo do lao while para verificao da dependncia funcional ir chegar a: A B obriga-nos a incluir B no resultado. Para perceber esse fato, observemos que A B est em F, A resultado (o que AG), assim, resultado := resultado B. A C obriga que resultado se torne ABCG. CG H obriga que resultado se torne ABCGH. CG I obriga que resultado se torne ABCGHI. Na segunda vez em que executamos o lao while, no ser adicionado nenhum outro atributo a resultado, e o algoritmo terminar.

Vejamos por que o algoritmo da fig. 6.7 est correto. J que sempre se realiza (pela regra da reflexidade), o primeiro passo correto. Exigimos que, para qualquer subconjunto de resultado, . J que comeamos o lao while com resultado sendo verdadeiro, podemos adicionar ao resultado somente se resultado e . Mas, ento, pela regra reflexiva, resultado e, pela transitividade, . Outra aplicao da transitividade mostra que (usando e ). A regra da unio implica que resultado , assim determina, funcionalmente, qualquer resultado novo gerado pelo lao while. Dessa forma, qualquer atributo obtido pelo algoritmo est em +.

172

 fcil perceber que o algoritmo encontra todos os atributos de +. Se h um atributo de + que no esteja ainda em resultado, ento preciso que haja uma dependncia funcional , para a qual resultado, e que ao menos um atributo em no esteja em resultado. Por outro lado, no pior caso, esse algoritmo pode tomar tempo proporcional ao quadrado do tamanho de F. H um algoritmo mais rpido (embora ligeiramente mais complexo) que consome tempo proporcionalmente linear ao tamanho de F. Cobertura Cannica Suponha que tenhamos um conjunto de dependncias funcionais F sobre o esquema de uma relao. Sempre que uma atualizao realizada na relao, o sistema de banco de dados deve garantir que todas as dependncias funcionais em F sejam satisfeitas no novo estado do banco de dados, ou dever reverter as alteraes caso no o sejam. Podemos reduzir os esforos exigidos para o teste por meio da simplificao de um dado conjunto de dependncias funcionais, com ou sem a alterao daquele conjunto de clausura. Qualquer banco de dados que satisfaa um conjunto simplificado de dependncias funcionais deve tambm satisfazer o conjunto original e viceversa, uma vez que os dois conjuntos tm a mesma clausura. Entretanto, o conjunto simplificado mais facilmente verificado. O conjunto simplificado pode ser construdo com descrevemos a seguir. Primeiro, precisamos de algumas definies. Um atributo de uma dependncia funcional extrnseco se podemos remov-lo sem alterar a clausura do conjunto de dependncias funcionais. Formalmente, atributos extrnsecos so definidos conforme segue. Considere um conjunto de dependncias funcionais F e a dependncia funcional em F. O atributo A extrnseco a se A , e F implica logicamente (F { }) {( A) }. O atributo A extrnseco a se A , e o conjunto de dependncias funcionais (F { }) {( A)} implica logicamente F. Uma cobertura cannica Fc para F o conjunto de dependncias tal que F implique logicamente todas as dependncias de FC e FC implique logicamente todas as dependncias em F. Alm disso, FC deve apresentar as seguintes propriedades: Nenhuma dependncia funcional em FC contm um atributo extrnseco. Cada lado esquerdo da dependncia funcional em FC nico. Isto , no h duas dependncias 1 1 e 2 2 em Fc tal que 1= 2. Uma cobertura cannica para um conjunto de dependncias funcionais F pode ser computada como:

Pode-se mostrar que a cobertura cannica de F, FC, possui a mesma clausura de F; ento, verificar se F satisfeita. Entretanto, Fc mnima em certo sentido ela no contm atributos extrnsecos e as dependncias funcionais, com mesmo lado esquerdo, foram combinadas. mais econmico verificar FC que testar o prprio F. Considere o seguinte conjunto de dependncias funcionais F do esquema (A, B, C): A BC B C A B AB C Vejamos como computar a cobertura cannica para F. 173

H duas dependncias funcionais com o mesmo conjunto de atributos do lado esquerdo da seta: A BC A B Combinamos essas dependncias funcionais em A BC. A extrnseco em AB C porque F implica logicamente (F {AB C}) {B C}. Essa assero verdadeira porque B C j est em nosso conjunto de dependncias funcionais. C extrnseco em A BC, uma vez que A BC est implcita logicamente por A B e B C. Assim, nossa cobertura cannica : A B B C

Dado um conjunto F de dependncias funcionais, pode ser que uma dependncia funcional total no conjunto seja extrnseca, no sentido de que, tirando-as, no h mudana na clausura de F. podemos mostrar que uma cobertura cannica FC de F no contm nenhuma dependncia funcional extrnseca. Suponha que, de modo contrrio, houvesse tal dependncia funcional extrnseca em FC. O lado direito dos atributos da dependncia poderia ser extrnseco, o que no possvel na definio da cobertura cannica.

174

Projeto e implementao de um banco de dados relacional Genericamente, o objetivo do projeto de um banco de dados relacional gerar um conjunto de esquemas de relaes que nos permita armazenar informaes sem redundncia desnecessria e, ainda, nos permita recuperar informaes facilmente. Uma das abordagens possveis seria projetar esquemas na forma normal apropriada. Para determinar se um esquema de relao atende a uma das formas normais, precisamos de informaes adicionais sobre a empresa real cujo banco de dados estamos modelando. J vimos como podemos usar dependncias funcionais para expressar fatos acerca dos dados. Armadilhas no Projeto de banco de dados Relacional Antes de prosseguir com nossa discusso sobre formas normais e dependncias de dados, vejamos o que determina a qualidade de um projeto de banco de dados. Entre as propriedades indesejveis em um bom projeto de banco de dados de banco de dados temos: Informaes repetidas. Inabilidade para representao de certas informaes. Podemos discutir esses problemas usando uma modificao no projeto de banco de dados. Entre as propriedades indesejveis em um bom projeto de banco de dados temos: Informaes repetidas. Inabilidade para representao de certas informaes. Podemos discutir esses problemas usando uma modificao no projeto de banco de dados no exemplo que temos usado de uma empresa de rea bancria; diferente do usado anterior, a informao acerca de emprstimos ser agora representada em uma nica relao, linha_de_crdito, que ser definido pelo esquema de relao: esquema_linha_de_crdito=(nome_agncia, cidade_agncia, fundos, nome_cliente, nmero_emprstimo, total) A fig. 7.1 mostra uma instncia da relao linha_de_crdito (esquema_linha_de_crdito). Uma tupla t da relao linha_de_crdito tem o seguinte significado intuitivo: t[fundos] so os fundos totais de uma determinada agncia cujo nome t[nome_agncia]. t[cidade_agncia] a cidade onde determinada agncia de nome t[nome_agncia] est localizada. t[nmero_emprstimo] o nmero atribudo ao emprstimo feito na agncia denominada t[nome_agncia] para o cliente de nome t[nome_cliente]. t[total] o montante da dvida do emprstimo cujo nmero t[nmero_emprstimo].

Suponha que desejamos adicionar um novo emprstimo ao nosso banco de dados. Digamos que o 175

emprstimo, no valor de 1,5 mil dlares, foi contrado na agncia Perryridge para o cliente Adams. O nmero_emprstimo ser L-31. Em nosso projeto, precisamos de uma tupla com valores em todos os atributos do esquema_linha_de_crdito. Assim, necessrio repetir os dados sobre fundos e cidade referentes agncia Perryridge na adio da tupla (Perryridge, Horseneck, 1700000, Adams, L-31, 1500) na relao linha_de_crdito. De modo geral, dados sobre fundos e localizao da agncia devem aparecer toda vez que um emprstimo contrado naquela agncia. A necessidade de repetio de informaes imposta pelo nosso projeto alternativo indesejvel. Repeties desperdiam espao. Alm disso, dificulta atualizaes no banco de dados. Suponha, por exemplo, que a agncia Perryridge se mude de Horseneck para Newtown. Em nosso projeto original, uma tupla da relao agncia ser alterada. Nesse projeto alternativo, diversas tuplas da relao linha_de_crdito devero sofrer alteraes. Assim, as atualizaes sero mais custosas no novo projeto que no original. Quando realizarmos a alterao no projeto alternativo, precisamos ter certeza de que todas as tuplas pertencentes agncia Perryridge sero alteradas, seno nosso banco de dados ir apresentar duas cidades para a agncia Perryridge. Essa observao fundamental para entender por que o projeto considerado ruim. Sabemos que uma agncia bancria est localizada em apenas uma cidade, naturalmente. Por outro lado, sabemos que uma agncia pode conceder diversos emprstimos. Em outras palavras, a dependncia funcional nome_agncia cidade_agncia se realiza no esquema_linha_de_crdito, mas no esperamos que a dependncia funcional pode ser usada para especificao formal quando o projeto de banco de dados bom. Outro problema com o projeto esquema_linha_de_crdito que no podemos representar diretamente a informao relativa a uma agncia (nome_agncia, cidade_agncia, fundos), salvo se houver ao menos um emprstimo concedido pela agncia. O problema que as tuplas da relao linha_de_crdito exigem valores para nmero_emprstimo, total e nome_cliente. Uma soluo para esse problema introduzir valores nulos para tratar as atualizaes por meio de vises. Recorde-se, entretanto, de que difcil trabalhar com valores nulos. Se no estamos dispostos a tratar com valores nulos, ento s poderemos criar informaes sobre as agncias quando o primeiro emprstimo na agncia for realizado. Pior, poderemos perder essa informao quando todos os emprstimos da agncia forem pagos. Logicamente, essa situao impensvel, j que, em nosso projeto original, as informaes a respeito das agncias esto disponveis independente de existirem ou no emprstimos mantidos pela agncia, e sem a necessidade de usar valores nulos. Decomposio O exemplo de um maus projeto sugere que poderamos decompor um esquema de relao com diversos atributos em vrios esquemas com diversos atributos em vrios esquemas com menor nmero de atributos. Decomposies descuidadas, entretanto, podem gerar outro tipo de projeto de m qualidade. Considere uma alternativa de projeto, em que esquema_linha_de_crdito decomposto nos dois esquemas que se seguem: esquema_agncia_cliente = (nome_agncia, cidade_agncia, fundos, nome_cliente) esquema_cliente_emprstimo = (nome_cliente, nmero_emprstimo, total) Usando a relao linha_de_crdito da fig. 7.1, construmos nossas novas relaes cliente_agncia (esquema_agncia_cliente) e cliente_emprstimo (esquema_cliente_emprstimo), como se segue:

Mostramos as relaes resultados agncia_cliente e nome_cliente nas fig. 7.2 e 7.3, respectivamente. Naturalmente, h casos em que precisamos reconstruir a relao emprstimo. Por exemplo, suponha que desejamos encontrar todas as agncias que tenham emprstimos cujos totais sejam inferiores a mil dlares. 176

Nenhuma relao em nosso banco de dados alternativo contm esses dados. Precisamos reconstruir a relao linha_de_crdito. Parece que podemos faz-lo escrevendo:

A fig. 7.4 mostra o resultado do processamento de agncia_cliente cliente_emprstimo. Quando comparamos essa relao e a primeira relao linha_de_crdito (fig. 7.1), notamos algumas diferenas. Embora todas as tuplas que aparecem em linha_de_crdito apaream em agncia_cliente h tuplas em agncia_cliente exemplo, agncia_cliente cliente_emprstimo,

cliente_emprstimo que no esto em linha_de_crdito. Em nosso cliente_emprstimo tem as seguintes tuplas adicionais:

177

Considere a consulta encontre todas as agncias que tenham feito um emprstimo com totais menores que mil dlares. Se olharmos a fig. 7.1, veremos que somente as agncias Mianus e Round Hill possuem totais de emprstimo menores que mil dlares. Entretanto, quando aplicamos a expresso obtemos trs nomes de agncias: Mianus, Round Hill e Downtown. Examinaremos esse exemplo mais de perto. Se acontecer de um cliente contrariar vrios emprstimo em diferentes agncias, no poderemos identificar a qual agncia pertence qual emprstimo. Assim, da juno de agncia_cliente e cliente_emprstimo, no obtemos somente as tuplas que tnhamos originalmente em linha_de_crdito, mas tambm diversas tuplas adicionais. Embora haja mais tuplas em agncia_cliente cliente_emprstimo, temos, na verdade, menos informao. De qualquer modo, no poderemos representar nas informaes do banco de dados quais clientes so devedores de quais agncias. Devido a essa perda de informao, chamamos a decomposio do esquema_linha_de_crdito em esquema_agncia_cliente e esquema_cliente_emprstimo de decomposio com perda (lossy decomposition), ou uma decomposio com perda na juno (lossy-join decomposition). Quando a decomposio no implica perda de informao, ela chamada decomposio sem perda na juno (lossless-join decomposition). Deve estar claro diante de nosso exemplo que uma decomposio com perda na juno , em geral, uma m opo de projeto de banco de dados. Examinaremos essa decomposio mais atentamente para descobrir por que ela representa perda. H um atributo comum entre esquema_agncia_cliente e esquema_cliente_emprstimo: O nico modo de representarmos um relacionamento entre, por exemplo, nmero_emprstimo e nome_agncia por meio de nome_cliente. Essa representao no adequada, porque um cliente pode contrair diversos emprstimos e, ainda, esses emprstimos no so necessariamente obtidos na mesma agncia. Consideremos outra alternativa de projeto, na qual esquema_linha_de_crdito decomposta nos dois esquemas seguintes:

H um atributo em comum entre os dois esquemas:

178

Assim, o nico modo de representar um relacionamento entre, por exemplo, nome_cliente e fundos por meio de nome_agncia. A diferena entre esse exemplo e o precedente que o valor dos fundos de uma agncia o mesmo, qualquer que seja o cliente em questo, enquanto a linha de crdito oferecida pela agncia, especialmente no montante envolvido, depende do cliente em questo. Para um dado nome_agncia, h exatamente um valor de fundos e exatamente uma cidade_agncia; j um tratamento similar no pode ser oferecido para nome_cliente. Isto , a dependncia funcional: nome_agncia fundos cidade_agncia realiza-se, mas nome_cliente no determina funcionalmente nmero_emprstimo. A noo de juno sem perda fundamental para a maioria dos projetos de banco de dados. Portanto, refaremos o exemplo anterior de modo mais precisa e mais formal. Seja R um esquema de relao. Um conjunto de esquemas de relaes {R1, R2, ..., Rn} uma decomposio de R se: Isto , {R1, R2, ..., Rn} uma decomposio de R se, para i = 1, 2, ..., n, cada Ri um subconjunto de R e todo atributo de R aparece ao menos uma vez em Ri. Seja r uma relao do esquema R, e seja ri = para i=1,2,..., n. Isto , {r1, r2, ..., rn} o banco de dados que resulta da decomposio de R em {R1, R2, ..., Rn}. Neste caso, sempre vlido: Para verificar se essa declarao verdadeira, considere uma tupla t da relao r. quando computamos as relaes r1, r2, ..., rn, a tupla t origina uma tupla ti em cada ri, i=1, 2, ..., n. Essas n tuplas podem ser combinadas . para reconstruir t quando computamos r1 r2 ... rn. Portanto, toda tupla em r aparece em De modo geral, r . Como ilustrao, considere nosso exemplo anterior, no qual: n=2 R = esquema_linha_de_crdito R1 = esquema_agncia_cliente R2 = esquema_cliente_emprstimo r = a relao mostrada na fig. 7.1. r1 = a relao mostrada na fig. 7.2. r2 = a relao mostrada na fig. 7.3. r1 r2 = a relao mostrada na fig. 7.4.

Note que as relaes das fig. 7.1 a 7.4 no so as mesmas. Para decomposies sem perda, precisamos impor restries ao conjunto das relaes possveis. Conclumos que a decomposio do esquema_linha_de_crdito em esquema_agncia e esquema_info_emprstimos ocorre sem perdas porque a dependncia funcional nome_agncia cidade_agncia fundos realiza-se em esquema_agncia. Seja C a representao de um conjunto de restries do banco de dados. Uma decomposio {R1, R2, ..., Rn} do esquema de relao R uma decomposio sem perda na juno de R se para todas as relaes r no esquema R vlido sob C:

Normalizao usando dependncias funcionais Podemos usar um dado conjunto de dependncias funcionais para projetar um banco de dados relacional, evitando a maior das propriedades no desejadas, j discutidas. Quando projetamos tais sistemas, pode tornar-se desnecessrio decompor uma relao em diversas relaes menores. Usando a dependncia funcional, podemos definir algumas formas normais que representam bons projetos de banco de dados. 179

Propriedades Desejveis da Decomposio Podemos ilustrar nossos conceitos por meio do esquema_linha_de_crdito:

O conjunto de dependncias funcionais F que desejamos que se realizem para o esquema_linha_de_crdito so: nome_agncia fundos cidade_agncia nmero_emprstimo total nome_agncia O esquema_linha_de_crdito um exemplo de projeto ruim de banco de dados. Suponha que tenhamos decomposto esse esquema nas trs relaes a seguir: esquema_agncia= (nome_agncia, fundos, cidade_agncia) esquema_emprstimo= (nome_agncia, nmero_emprstimo, total) esquema_devedor= (nome_cliente, nmero_emprstimo) Afirmamos que essa decomposio apresenta diversas propriedades desejveis. Decomposio sem Perda na Juno J sustentamos que, quando decompomos uma relao em outras relaes menores, crucial que a decomposio no resulte em perda de informao. Afirmamos que a decomposio crucial que a decomposio no resulte em perda de informao. Seja R um esquema de relao e F um conjunto de dependncias funcionais sobre R. Sejam R1 e R2 formas de decomposio de R. Essa decomposio uma decomposio sem perda na juno de R se ao menos uma das seguintes dependncias funcionais est em F+:

Mostraremos agora que nossa decomposio para o esquema_linha_de_crdito uma decomposio sem perda na juno mostrando uma sequncia de passos que geraram essa decomposio. Comecemos pela decomposio do esquema_linha_de_crdito em dois esquemas: esquema_agncia = (nome_agncia, cidade_agncia, fundos) esquema_info_emprstimo = (nome_agncia, nome_cliente, nmero_emprstimo, total) Uma vez que nome_agncia cidade_agncia fundos, a regra incremental (augmentation) para a dependncia funcional implica: nome_agncia nome_agncia cidade_agncia fundos J que esquema_agncia esquema_info_emprstimo = {nome_agncia}, ento nossa decomposio inicial uma decomposio sem perda na juno. A seguir, decomporemos esquema_info_emprstimo em:

Esse passo resulta em uma decomposio sem perda na juno, desde que nmero_emprstimo seja um atributo comum e nmero_emprstimo total nome_agncia. Preservao da dependncia Outra meta do projeto de um banco de dados relacional a preservao da dependncia. Quando ocorre uma atualizao no banco de dados, o sistema deve checar se ele criar uma relao ilegal isto , uma relao que no que no satisfaa todas as dependncias funcionais. Se checarmos de modo eficiente essas atualizaes, 180

poderemos projetar esquemas de banco de dados relacionais capazes de validar atualizaes sem necessidade de junes. Para decidir se uma juno ou no necessria, precisamos determinar quais dependncias funcionais devem ser testadas, verificando cada uma das relaes individualmente. Seja F um conjunto de dependncias funcionais de um esquema R e seja R1, R2, ..., Rn uma decomposio de R. A restrio de F para Ri o conjunto Fi de todas as dependncias funcionais em F+ que contenha somente os atributos de Ri. J que todas as dependncias funcionais em uma restrio contm atributos de apenas um esquema de relao, possvel testar se tais dependncias so satisfeitas checando somente uma relao. O conjunto de restries F1, F2, ..., Fn o conjunto das dependncias que podem ser checadas eficientemente. Agora precisamos nos certificar de que suficiente testar somente as restries. Seja F = . F um conjunto de dependncias funcionais do esquema R, mas, em geral, FF. Entretanto, mesmo que FF, pode ser que F+=F+. Se o ltimo verdadeiro, ento toda a dependncia de F est compreendida logicamente em F, e, se verificarmos que F satisfeita, podemos verificar que F tambm o . Dizemos que uma decomposio decomposio com preservao da dependncia se possui a propriedade F+=F+. A fig. 7.5 mostra um algoritmo para o teste da preservao da dependncia. A entrada o conjunto dos esquemas das relaes decompostas D = {R1, R2, ..., Rn} e um conjunto de dependncias funcionais F. Podemos agora mostrar que nossa decomposio do esquema_linha_de_crdito uma decomposio com preservao de dependncia. Consideramos cada membro do conjunto F das dependncias funcionais que desejamos impostas sobre esquema_linha_de_crdito e mostraremos que cada uma pode ser testada em ao menos uma relao da decomposio. Podemos testar a dependncia funcional: nome_agncia cidade_agncia fundos usando esquema_agncia= (nome_agncia, cidade_agncia, fundos). Podemos testar a dependncia funcional: nmero_emprstimo total nome_agncia usando esquema_emprstimo= (nome_agncia, nmero_emprstimo, total). Como no exemplo mostrado anteriormente, frequentemente mais fcil no aplicar o algoritmo da fig. 7.5 para o teste da preservao da dependncia, j que o primeiro passo, o processamento de F+, toma tempo exponencial.

Redundncia de Informaes A decomposio do esquema_linha_de_crdito no sofre o problema da repetio da informao que foi discutido anteriormente. No esquema_linha_de_crdito necessrio repetir, em cada emprstimo, a cidade e os fundos relativos agncia.

181

A decomposio separa os dados a respeito da agncia e do emprstimo em relaes distintas eliminando, desse modo, a redundncia. Similarmente, observe que, se um nico emprstimo feito para diversos clientes, repetiremos o total do emprstimo para cada um dos clientes (assim como a cidade e os fundos da agncia). Na decomposio, a relao do esquema esquema_devedor contm o relacionamento nmero_do_emprstimo e nome_do_cliente que nenhum outro esquema contm. Temos, portanto, somente na relao do esquema esquema_devedor contm o relacionamento nmero_do_emprstimo e nome_do_cliente que nenhum outro esquema contm. Temos, portanto, somente na relao do esquema esquema_devedor, uma tupla para cada cliente com um emprstimo. Nas outras relaes que contm o atributo nmero_emprstimo (as dos esquemas esquema_emprstimo, e esquema_devedor) aparece somente uma tupla por emprstimo. Evidentemente, desejvel a ausncia de redundncia mostrada nessa decomposio. O grau alcanado por essa ausncia de redundncia representado pelas diversas formas normais. Forma Normal de Boyce-Codd Uma das mais procuradas formas normais a forma normal de Boyce-Codd (FNBC). Uma relao do esquema R est na FNBC com respeito a um conjunto F de dependncias funcionais se para todas as dependncias funcionais em F+ da forma , em que R e R, ao menos uma das seguintes realiza-se: uma dependncia funcional trivial (isto , ). uma superchave para o esquema R. Um projeto de banco de dados est na FNBC se cada membro do conjunto de relaes dos esquemas que constituem o projeto est na FNBC. Como exemplo, consideremos os seguintes esquemas de relaes e suas respectivas dependncias funcionais:

Afirmamos que o esquema_cliente est na FNBC. Notamos que uma chave candidata para o esquema nome_cliente. A nica dependncia funcional no trivial no que se realiza no esquema_cliente tem nome_cliente chave candidata, dependncias funcionais com nome_cliente do lado esquerdo da seta no violam a definio da FNBC. Analogamente, pode-se mostrar facilmente que a relao do esquema esquema_agncia est na FNBC. O esquema esquema_info_emprstimo, entretanto, no est na FNBC. Primeiro, note que nmero_emprstimo no superchave do esquema_info_emprstimo, j que poderia haver um par de tuplas representando um nico emprstimo adquirido por duas pessoas por exemplo:

Como no fizemos a lista das dependncias funcionais que no so admitidas no caso precedente, nmero_emprstimo no uma chave candidata. Entretanto, a dependncia funcional nmero_emprstimo total no trivial. Portanto, esquema_info_esquema no satisfaz a definio FNBC. Afirmamos que o esquema_info_emprstimo no conveniente, uma vez que est sujeito ao problema de informaes redundantes j descrito. Observemos que, se existir diversos nomes de clientes associados a um emprstimo, em uma relao do esquema_info_emprstimo, ento somos foradas a repetir o nome da agncia e o total do emprstimo a cada cliente. 182

Podemos eliminar essa redundncia redesenhando nosso banco de dados de modo que todos os esquemas estejam em FNBC. Uma abordagem para esse problema tomar um projeto que no est na FNBC como ponto de partida e decompor os esquemas necessrios. Considere a decomposio do esquema_info_emprstimo em dois outros esquemas:

Essa decomposio uma decomposio sem perda na juno. Para determinar se esses esquemas esto na FNBC, precisamos determinar quais dependncias funcionais se aplicam a elas. Nesse exemplo, fcil perceber que: nmero_emprstimo total nome_agncia aplica-se a esquema_emprstimo e que somente dependncias funcionais aplicam-se a esquema_devedor. Embora nmero_emprstimo no seja uma superchave para esquema_info_emprstimo, ele chave candidata para esquema_emprstimo. Assim, ambos os esquemas de nossa decomposio esto em FNBC. Assim, possvel evitar redundncia quando h diversos clientes associados a um nico emprstimo. H exatamente uma tupla para cada emprstimo na relao do esquema_emprstimo e uma tupla para cada emprstimo de cada cliente na relao do esquema_devedor. Logo, no precisamos repetir o nome da agncia e o total para cada cliente associado a um emprstimo. Podemos agora determinar um mtodo geral para criar uma coleo de esquemas na FNBC. Se R no est na FNBC, podemos decompor R em um grupo de esquemas R1, R2, ..., Rn na FNBC usando o algoritmo da fig. 7.6, que no s gera decomposies na FNBC, como todas as decomposies sem perda na juno. Para perceber por que nosso algoritmo gera somente decomposies sem perda na juno, note que, quando substitumos um esquema Ri por (Ri ) e (,), a dependncia realiza-se e .

Vejamos a aplicao do algoritmo de decomposio FNBC no esquema_linha_de_crdito que usamos anteriormente como exemplo de um projeto deficiente de banco de dados: esquema_linha_de_crdito = (nome_agncia, cidade_agncia, fundos, nome_cliente, nmero_emprstimo, total) O conjunto de dependncias funcionais que exigimos que se realizem so:

Uma chave candidata para esse esquema {nmero_emprstimo, nome_cliente}. Aplicamos o algoritmo da fig. 7.6 para o exemplo com esquema_linha_de_crdito, conforme segue: A dependncia funcional nome_agncia fundos cidade_agncia realiza-se no esquema_linha_de_crdito, mas nome_agncia no uma superchave. Assim, esquema_linha_de_crdito no est na FNBC. Substitumos o esquema_linha_de_crdito por:

183

A nica dependncia funcional no trivial que se realiza no esquema_agncia contm nome_agncia no lado esquerdo da seta. Uma vez que nome_agncia uma chave para o esquema_agncia, a relao esquema_agncia est na FNBC. A dependncia funcional nmero_emprstimo total nome_agncia realiza-se no esquema_info_emprstimo, mas nmero_emprstimo no chave para o esquema_info_emprstimo. Substitumos esquema_info_emprstimo por:

esquema_emprstimo e esquema_devedor esto na FNBC.

Assim, a decomposio do esquema_linha_de_crdito resulta nos trs esquemas de relaes esquema_agncia, esquema_emprstimo, e esquema_devedor, cada um dos quais na FNBC. Esses esquemas de relao so os mesmos j usados anteriormente. Nem toda decomposio na forma FNBC tem dependncia preservada. Considere a seguinte relao: esquema_bancrio= (agncia_nome, nome_cliente, nome_bancrio) que informa que um cliente possui atendimento personalizado, de responsabilidade de um bancrio determinado, em uma dada agncia. O conjunto F de dependncias funcionais necessrias ao esquema_bancrio so:

Naturalmente, esquema_bancrio no est na FNBC, uma vez que nome_bancrio no uma superchave. Se aplicarmos o algoritmo da fig. 7.6, obtemos a seguinte decomposio em FNBC:

A decomposio dos esquemas preserva somente nome_bancrio nome_agncia (e as dependncias triviais), mas a clausura {nome_bancrio nome_agncia} no engloba nome_cliente nome_agncia nome_bancrio. Uma violao dessa dependncia pode ser detectada somente por meio de uma juno. Para verificar se a decomposio de esquema_bancrio nos esquemas esquema_bancrio_agncia e esquema_cliente_bancrio no acontece com preservao da dependncia, aplicamos o algoritmo da fig. 7.5. Consideremos que as restries F1 e F2 de F para cada um dos esquemas so:

Assim, uma cobertura cannica para o conjunto F F1. fcil perceber que a dependncia funcional nome_cliente nome_agncia nome_bancrio no est + + + + em F mesmo que esteja em F . Portanto, F F e a decomposio no preserva a dependncia. O exemplo precedente demostra que nem toda decomposio FNBC preserva a dependncia. Alm disso, ela demonstra que nem sempre as trs metas de projeto podem ser satisfeitas: 1. FNBC 2. Sem perda na juno 3. Preservao da dependncia No podemos realiza-las neste exemplo porque toda decomposio FNBC do esquema_bancrio falha na preservao de nome_cliente nome_agncia nome_bancrio. 184

Terceira Forma Normal Nos caos em que no conseguimos alcanar todos os trs critrios de projeto, abandonamos FNBC e aceitamos uma forma normal mais fraca chamada terceira forma normal (3FN). Vemos que sempre possvel alcanar decomposio sem perda na juno, decomposio com preservao da dependncia que est na 3FN. A FNBC exige que todas as dependncias no triviais sejam da forma , em que uma superchave. A 3FN suaviza essa restrio permitindo dependncias funcionais no-triviais cujo lado esquerdo da seta no seja superchave. Um esquema de relao R est na 3FN com respeito a um conjunto de dependncias funcionais F se, para todas as dependncias funcionais F+ da forma , em que R e R, ao menos uma das seguintes condies for realizada: uma dependncia funcional trivial. uma superchave de R. Cada atributo de A em est contido em uma chave candidata de R. A definio da 3FN permite algumas dependncias funcionais que no so permitidas na FNBC. A dependncia , que satisfaz apenas a terceira condio da definio da 3FN, no permitida na FNBC, mas permitida na 3FN. Essas dependncias so um exemplo de dependncias transitivas. Observe que, se um esquema de relao est na FNBC, ento todas as dependncias funcionais so da forma superchave determina um conjunto de atributos, ou a dependncia trivial. Assim, um esquema FNBC no pode conter nenhuma dependncia transitiva. Como resultado, todo esquema FNBC tambm da 3FN, e a FNBC, portanto, mantm regras mais restritivas que a 3FN. Retornemos ao nosso exemplo do esquema_bancrio. Mostramos que esse esquema de relao no tem a dependncia preservada, com decomposio sem perda da juno em FNBC. Esse esquema, entretanto, sai da 3FN. Para essa verificao, notamos que {nome_cliente, nome_agncia} uma chave candidata para esquema_bancrio, assim o nico atributo no contido em chave candidata de esquema_bancrio nome_bancrio. As nicas dependncias funcionais no-triviais da forma nome_bancrio incluem {nome_cliente, nome_agncia} como parte de . J que {nome_cliente, nome_agncia} chave candidata, essas dependncias no violam a definio da 3FN. A fig. 7.7 mostra um algoritmo para chegar preservao de dependncia, com decomposio sem perda na juno em 3FN. O fato de cada esquema de relao Ri estar na 3FN decorre diretamente de nossa exigncia de que o conjunto de dependncias funcionais F seja da forma cannica. O algoritmo assegura a preservao das dependncias explicitando um esquema para cada dependncia. Ele assegura que a decomposio sem perda na juno por meio da garantia de que ao menos um esquema contm uma chave candidata para o esquema que est sendo decomposto. Para ilustrar o algoritmo da fig. 7.7 consideramos a seguinte extenso do esquema_bancrio: esquema_info_bancrio= (nome_agncia, nome_cliente, nome_bancrio, nmero_seo) A principal diferena aqui que inclumos o nmero da seo do bancrio como parte da informao. As dependncias funcionais para esse esquema de relao so:

Uma vez que esquema_bancrio contm uma chave candidata para o esquema_info_bancrio, terminamos o processo de decomposio.

185

Comparao entre FNBC e 3FN Vimos duas formas normais de esquemas de banco de dados relacionais: 3FN e FNBC. Uma vantagem de um projeto na 3FN saber que sempre possvel obt-la sem sacrificar uma decomposio sem perda na juno ou preservao da dependncia. Apesar disso, h uma desvantagem na 3FN. Se no a eliminarmos todas as dependncias transitivas, teremos de usar valores nulos para representao de alguns dos possveis relacionamentos significativos entre itens de dados, e h ainda o problema da repetio da informao. Como ilustrao, considere novamente o esquema_bancrio e suas dependncias funcionais associadas. Dado nome_bancrio nome_agncia, podemos desejar representar em nosso banco de dados relacionamentos entre valores de nome_bancrio e valores de nome_agncia. No entanto, se fizermos isso, ser preciso ter um valor correspondente para nome_cliente ou usar valores nulos para o atributo nome_cliente. Outra dificuldade com esquema_bancrio a repetio da informao. Como ilustrao, considere uma instncia de esquema_bancrio mostrada na fig. 7.8. Note que a informao de que Johnson est trabalhando na agncia Perryridge repetida.

Se formos forados a escolher entre FNBC e preservao da dependncia com 3FN, geralmente prefervel optar pela 3FN. Se no pudermos verificar eficientemente a preservao da dependncia, termos de pagar alto custo em desempenho do sistema ou corremos riscos em relao integridade de dados de nosso banco de dados. Nenhuma dessas opes atraente. Com tais alternativas, o limite redundncia imposto pelas dependncias transitivas sob a 3FN o menos pior. Assim, normalmente optamos por manter a preservao da dependncia e sacrificar a FNBC. Em resumo, repetimos que as trs metas de projeto para um banco de dados relacional so: 1. FNBC 186

2. Juno sem perda 3. Preservao da dependncia Se no pudermos alcanar as trs, aceitamos: 1. 3FN 2. Juno sem perda 3. Preservao da dependncia Normalizao usando Dependncias Multivaloradas H esquemas de relao na FNBC que no esto normalizados o bastante, no sentido de que eles ainda sofrem de problemas de repetio de informao. Considere novamente nosso exemplo relativo ao banco. Assuma que, como alternativa de projeto para o esquema de um banco de dados de uma empresa na rea bancria, tenhamos o esquema: esquema_BC = (nmero_emprstimo, nome_cliente, rua_cliente, cidade_cliente) Podemos perceber que esse esquema no est na FNBC por causa da dependncia funcional nome_cliente rua_cliente cidade_cliente que afirmamos anteriormente, e porque nome_cliente no uma chave do esquema_BC. Entretanto, consideremos que nosso banco est atraindo clientes ricos que possuem diversos endereos (digamos, casa de inverno e casa de vero). Ento, no desejaremos mais a dependncia funcional nome_cliente rua_cliente cidade_cliente. Se retirarmos essa dependncia funcional, concluiremos que o esquema_BC est na FNBC com respeito ao nosso conjunto de dependncias funcionais modificadas. Ainda, mesmo que o esquema_BC esteja na FNBC com respeito ao nosso conjunto de dependncias funcionais modificadas. Ainda, mesmo que o esquema_BC esteja na FNBC, ns teremos o problema da repetio de informaes que tnhamos anteriormente. Para tratar esse problema, precisamos definir uma nova forma de restrio, chamada dependncia multivalorada. Como fizemos com as dependncias funcionais, usaremos as dependncias funcionais multivaloradas para definir uma forma normal para os esquemas das relaes. Essa forma normal, chamada quarta forma normal (4FN), mais restritiva que a FNBC. Podemos ver que todo esquema na 4FN est tambm na FNBC, mas h esquemas na FNBC que no esto na 4FN. Dependncias Multivaloradas As dependncias funcionais rejeitam certas tuplas como participantes de uma relao. Se A B, ento no podemos ter duas tuplas com os mesmos valores de A, mas diferentes valores de B. Dependncias multivaloradas no rejeitam a existncia de certas tuplas. Pelo contrrio, elas exigem que outras tuplas, de uma certa forma, estejam presentes na relao. Por essa razo, por vezes, as dependncias funcionais so chamadas dependncias geradas por igualdade (equality-generating dependencies) e dependncias multivaloradas so referidas como dependncias geradas por tuplas (tuple-generating dependencies). Seja R um esquema de relao e seja R e R. A dependncia multivalorada realiza-se em R se, para qualquer relao r(R), para todos os pares de tuplas t1 e t2 de r, tal que t1[] =t2 [], existem tuplas t3 e t4 em r tal que

Essa definio menos complexa do que parece. Na fig. 7.9, damos uma apresentao tabular para t1, t2, t3 e t4. Intuitivamente, a dependncia multivalorada diz que um relacionamento entre e independente do relacionamento entre e R . Se uma dependncia multivalorada satisfeita para todas as relaes do esquema R, ento uma dependncia multivalorada trivial do esquema R. Assim, trivial se =R. 187

Para ilustrar as diferenas entre dependncia funcional e multivalorada, consideremos novamente o esquema_BC e a relao bc (esquema_BC) da fig. 7.10. Precisamos repetir o nmero do emprstimo de um mesmo cliente. Essa repetio desnecessria, j que o relacionamento entre o cliente e seu endereo independente do relacionamento entre o cliente e um emprstimo. Se um cliente (digamos, Smith) tem um emprstimo (digamos, o de nmero L-23), queremos que o emprstimo seja associado a todos os endereos de Smith. Assim, a relao da fig. 7.11 no validade. Para tornar essa relao vlida, precisamos adicionar as tuplas (L-23, Smith, Main, Manchester) e (L-27, Smith, North, Rye) relao bc da fig. 7.11.

Comparando o exemplo anterior com nossa definio de dependncia multivalorada, percebemos que desejamos que a dependncia multivalorada nome_cliente rua_cliente cidade_cliente se realize (a dependncia multivalorada nome_cliente nmero_emprstimo faz a mesma coisa. Assim, verificamos que so equivalentes). Como fizemos para as dependncias funcionais, podemos usar a dependncia multivalorada de dois modos: 1. Para testar relaes para determinar se elas so validades sob um dado conjunto de dependncias funcionais e multivaloradas. 2. Para especificar restries sobre um conjunto de relaes vlidas; devemos, assim, nos restringir somente quelas relaes que satisfazem um dado conjunto de dependncias funcionais e multivaloradas. Note que, se uma relao r no satisfaz uma dada dependncia multivalorada, podemos criar uma relao r que satisfaa a dependncia multivalorada adicionando tuplas a r. Teoria das Dependncias Multivaloradas Como foi feito para a dependncia funcional, para 3FN e para FNBC, precisamos determinar todas as dependncias multivaloradas que esto logicamente implcitas em um dado conjunto de dependncias multivaloradas. Adotamos o mesmo enfoque tomado anteriormente para as dependncias funcionais. Seja D um conjunto de dependncias funcionais e multivaloradas. A clausura D+ de D o conjunto de todas as dependncias 188

funcionais e multivaloradas logicamente implcitas em D. Como fizemos para as dependncias funcionais, podemos computar D+ por meio de D, usando a definio formal de dependncias funcionais e dependncias multivaloradas. Entretanto, normalmente mais fcil ponderar acerca de conjuntos de dependncias multivaloradas. Entretanto, normalmente mais fcil ponderar acerca de conjuntos de dependncias usando um sistema de regras de inferncias. A seguinte lista de regras de inferncias para dependncias funcionais e dependncias multivaloradas slida e completa. Recorde que as regras para solidez no criam qualquer dependncia que no esteja logicamente implcita em D e regras completas permite-nos criar todas as dependncias em D+.

Seja R= (A, B, C, G, H, I) um esquema de relao. Suponha que A BC realiza-se. A definio de dependncia multivalorada implica que, se t1[A] = t2[A], ento existem as tuplas t3 e t4 tal que:

A regra de complementao coloca que, se A BC, ento A GHI. Observe que t3 e t4 satisfazem a definio de que A GHI simplesmente mudando os subescritos. Podemos proporcionar uma justificativa similar para as regras 5 e 6 usando a definio de dependncia multivalorada. Regra 7, a regra da replicao, envolve dependncias funcionais e multivaloradas. Suponha que A BC realiza-se em R. Se t1[A] =t2[A] e t1[BC] =t2[BC], ento as prprias t1 e t2 podem ser as tuplas t3 e t4 exigidas na definio da dependncia multivalorada A BC. Regra 8, a regra da coalescncia, a mais difcil de se verificar entre as oito regras. Podemos simplificar a computao da clausura de D usando as seguintes regras, as quais podemos provar usando as regras 1 a 8. Regra da unio multivalorada. Se e realizam-se, ento tambm realiza-se. Regra da interseo. Se e realizam-se, ento realiza-se. Regra da diferena. Se e realizam-se, ento realiza-se e realiza-se. Apliquemos nossas regras no seguinte exemplo. Seja R = (A, B, C, G, H, I) com o seguinte conjunto de dependncias D dado:

Relacionamos alguns membros de D+ aqui: 189

A CGHI: desde que A B, a regra da complementao (regra 4) implica que A R B A, R B A = CGHI, assim A CGHI. A HI: desde que A B e B HI, a regra da transitividade multivalorada (regra 6) implica que A HI B. Desde que HI B = HI, A HI. B H: para mostrar isso, precisamos aplicar a regra da transitividade multivalorada (regra 6) implica que A HI B. Desde que HI B = HI, A HI. B H: para mostrar isso, precisamos aplicar a regra da coalescncia (regra 8). B HI realiza-se. Desde que H HI e CG H e CG HI = , satisfazemos a regra da coalescncia, com estando em B, estando em HI, estando em CG e estando em H. Conclumos que B H. A CG: tambm sabemos que A CGHI e A HI. Pela regra da diferena, A CGHI. Desde que CGHI HI = CG. A CG.

Quarta Forma Normal Retornemos a nosso exemplo esquema_BC no qual a dependncia multivalorada nome_cliente rua_cliente cidade_cliente realiza-se, mas nenhuma dependncia funcional no-trivial realiza-se. Vimos anteriormente que, embora esquema_BC esteja na FNBC, o projeto no adequado, uma vez que precisamos repetir as informaes acerca do endereo do cliente a cada emprstimo. Podemos ver que possvel usar a dependncia multivalorada dada para melhorar o projeto do banco de dados, por meio da decomposio esquema_BC em uma decomposio na quarta forma normal (4FN). Um esquema de relao R est na 4FN com respeito a um conjunto D de dependncias funcionais e , em que R e R, ao multivaloradas se, para todas as dependncias multivaloradas em D+ da forma menos uma das seguintes condies se realize: uma dependncia multivalorada trivial. uma superchave para o esquema R. Um projeto de banco de dados est na 4FN se cada membro do conjunto dos esquemas de relaes que constituem o projeto estiver na 4FN. Note que a definio da 4FN difere da definio da FNBC somente no uso de dependncias multivaloradas em vez de dependncias funcionais. Todo esquema na 4FN est na FNBC. Para constatar esse fato, notamos que, se um esquema R no est na FNBC, ento h uma dependncia funcional no-trivial realizando-se em R, na qual no superchave. Desde que implica que (pela regra da replicao), R no poder estar na 4FN. A analogia entre 4FN e FNBC aplica-se ao algoritmo para a decomposio de um esquema para a 4FN. A fig. 7.12 mostra o algoritmo para a decomposio na 4FN. Ele idntico ao algoritmo de decomposio para FNBC mostrado na fig. 7.6, exceto pelo fato de usar dependncia multivalorada em vez da dependncia funcional. Se aplicarmos o algoritmo da fig. 7.12 para o esquema_BC, conclumos que nome_cliente nmero_emprstimo uma dependncia multivalorada no-trivial e nome_cliente no uma superchave para o esquema_BC pelos dois esquemas: esquema_devedor = (nome_cliente, nmero_emprstimo) esquema_cliente = (nome_cliente, rua_cliente, cidade_cliente) Esse par de esquemas, que esto na 4FN, eliminam o problema encontrado anteriormente em relao redundncia do esquema_BC. Como no caso em que tratamos somente das dependncias funcionais, estamos interessados em decomposies sem perda na juno e com preservao das dependncias. Os fatos seguintes sobre dependncias multivaloradas e sem perda na juno mostram que o algoritmo da fig. 7.12 cria somente decomposies sem perda na juno:

190

Seja o esquema de relao R e seja D um conjunto de dependncias funcionais e multivaloradas de R. Seja R1 e R2 decomposies de R. Esta decomposio sem perda na juno de R se e somente se ao menos uma das seguintes dependncias multivaloradas estiver em D+:

Lembre-se de que estabelecemos anteriormente que, se R1 R2 R1 ou R1 R2 R2, ento R1 e R2 so decomposies sem perda na juno de R. O fato precedente ressalta que as dependncias multivaloradas constituem uma forma mais genrica de juno sem perda. Ele indica que, para toda decomposio sem perda na juno de R em dois esquemas R1 e R2, uma das duas dependncia R1 R2 R1 ou R1 R2 R2 deve se realizar. A questo da preservao da dependncia quando temos dependncia multivalorada no to simples quanto quando temos somente dependncias funcionais. Seja R um esquema de relao e sejam R1, R2, ..., Rn decomposies de R. Lembre-se de que, para um conjunto de dependncias funcionais F, a restrio F1 de F para Ri so todas as dependncias funcionais em F+ que incluem somente atributos de Ri. Agora, consideremos um conjunto D, tanto de dependncias funcionais quanto de dependncias multivalorados. A restrio de D para R1 o conjunto Di, consistindo: Todas as dependncias funcionais em D+ que incluem somente atributos de Ri. Todas as dependncias multivaloradas da forma. Ri em que Ri e est em D+.

Uma decomposio do esquema R nos esquemas R1, R2, ..., Rn uma decomposio com preservao da dependncia com respeito ao conjunto D de dependncias funcionais e multivaloradas se, para todo conjunto de relaes r1(R1), r2(R2), ..., rn (Rn), tal que, para todo i, ri satisfaa Di, l houver uma relao r(R) que satisfaa D e para qual ri= Ri(r) para todo i. Apliquemos o algoritmo para decomposio na 4FN da fig. 7.12 em nosso exemplo de R = (A, B, C, G, H, I) com D = {A B, B HI, CG H}. Podemos, ento, testar a decomposio resultante em relao preservao da dependncia. R no est na 4FN. Observe que A B no trivial, ainda A no uma superchave. Usando A B na primeira iterao do while, substitumos R por dois esquemas, (A, B) e (A, C, G, H, I). fcil perceber que (A,B) est na 4FN desde que todas as dependncias multivaloradas que valem em (A, B) sejam triviais. Entretanto, o esquema (A, C, G, H, I) no est na 4FN. Aplicando a dependncia multivalorada CG H (que decorre na dependncia funcional dada CG H pela regra da replicao), substitumos (A, C, G, H, I) pelos dois esquemas, (C, G, H) e (A, C, G, I). O esquema (C, G, H) est na 4FN, mas o esquema (A, C, G, I) no est. Para perceber que (A, I C, G, I) no est na 4FN, lembremos que foi mostrado anteriormente que A HI est em D+. Portanto, A est na restrio de D para (A, C, G, I). Assim, na terceira iterao do lao while, substitumos (A, C, G, I) pelos dois esquemas (A, I) e (A, C, G). O algoritmo ento termina e a decomposio 4FN {(A, B), (C, G, H), (A, I), (A, C, G)}. 191

Essa decomposio para a 4FN no preserva a dependncia, uma vez que ela falha na preservao da dependncia multivalorada B HI. Considere a fig. 7.13m que mostra as quatro relaes que poderiam resultar da projeo de uma relao em (A, B, C, G, H, I) nos quatro esquemas de nossa decomposio. A restrio de D B porque no h para (A, B) A B e algumas dependncias triviais. fcil perceber que r1 satisfaz A nenhum par de tuplas com o mesmo valor de A. Observe que r2 tenha os mesmos valores em qualquer atributo. Um comando similar pode ser feito para r3 e r4. Portanto, a verso decomposta de nosso banco de dados satisfaz a todas as dependncias da restrio de D. Entretanto, no h nenhuma relao r em (A, B, C, G, H, I) que . A relao satisfaa D e possa ser decomposta em r1, r2, r3 e r4. A fig. 7.14 mostra a relao r = r no satisfaz B HI. Qualquer relao s contendo r e satisfazendo B HI deve incluir a tupla (a2, b1, c2, g2, h1, i1). Entretanto, CGH(s) inclui uma tupla (c2, g2, h1) que no est em r2. Assim, nossa decomposio falha da deteco da violao de B HI.

Vimos que, se estamos definindo um conjunto de dependncias funcionais e multivaloradas, vantajoso chegar a um projeto de banco de dados que tenha como critrios: 1. 4FN 2. Preservao de dependncia 3. Juno sem perda Se tudo o que tivermos forem dependncias funcionais, ento o primeiro critrios ser apenas a FNBC. Vimos tambm que nem sempre possvel alcanar todas as trs condies. Obtivemos sucesso na decomposio do exemplo do banco, mas falhamos no exemplo do esquema R= (A, B, C, G, H, I). Quando no conseguimos alcanar as trs metas, abrimos mo da 4FN aceitando FNBC ou mesmo 3FN, se necessrio, assegurando a preservao da dependncia. Normalizao usando dependncias na Juno

192

Vimos que a propriedade sem perda na juno uma das diversas propriedades para o projeto de um banco de dados. De fato, essa propriedade essencial: sem ela, h perda de informao. Quando restringimos o conjunto das relaes vlidas entre as que satisfazem um conjunto de dependncias funcionais e multivaloradas, podemos usar essas dependncias para mostrar que certas decomposies so decomposies sem perda na juno. Por causa da importncia desse conceito de sem perda na juno, til conseguir restringir um conjunto de relaes vlidas sobre uma esquema R para aquelas relaes para as quais uma dada decomposio uma decomposio sem perda na juno. Vamos agora definir o que dependncia de juno. Apenas como tipos de dependncias conduzidas por outras formas normais, dependncias de juno sero direcionadas a uma forma normal chamada forma normal de projeo de juno Project-join normal form (FNPJ). Dependncias de juno (Join Dependencies) Seja R um esquema de relao e R1, R2, ..., Rn seja uma decomposio de R. A dependncia de juno * (R1, R2, ..., Rn) usada para restringir o conjunto de relaes legais para aquelas para as quais R1, R2, ..., Rn uma decomposio sem perda na juno de R. Formalmente, se R= , dizemos que uma relao r(R) satisfaz a dependncia de juno * (R1, R2,..., Rn) se: Uma dependncia de juno trivial se um dos Ri for o prprio R. Considere a dependncia de juno *(R1, R2) do esquema R. Essa dependncia exige que, para toda r(R)vlida: Seja r contendo duas tuplas t1 e t2, conforme segue:

Assim, t1[R1

R2]=t2[R1

R2], mas t1 e t2 tm diferentes valores em todos os outros atributos.

Computemos . A fig. 7.15 mostra e . Quando computamos a juno, temos duas tuplas, alm de t1 e t2, exigidas na fig. 7.16 por t3 e t4. Se *(R1, R2) vale, ento, sempre que tivermos as tuplas t1 e t2, devemos tambm ter t3 e t4. Assim, a fig. 7.16 mostra uma representao tabular da dependncia de juno *(R1, R2). Compare a fig. 7.16 com a fig. 7.9, na qual temos a representao tabular de . Se tivermos e =R1, podemos ver que as duas representaes tabulares nessas figuras so as mesmas. De fato, *(R1, R2) apenas um outra forma de determinar . Usando as regras da complementao e do incremento para dependncias multivaloradas, podemos mostrar que R1 implica R2. Assim, *(R1, R2) equivalente a R2. Essa observao no causa surpresa tendo em vista que, conforme observamos anteriormente, R1 e R2 formam uma decomposio de R sem perda na juno se, e somente se, R2 ou R1.

193

Toda dependncia de juno da forma *(R1, R2) , portanto, equivalente a uma dependncia multivalorada. No entanto, h dependncias de juno que no so equivalentes a nenhuma dependncia multivalorada. O exemplo mais simples desse tipo de dependncia o esquema R=(A, B, C). A dependncia de juno: *((A, B), (B, C), (A, C)) no equivalente a nenhuma coleo de dependncias multivaloradas. A fig. 7.17 mostra uma representao tabular dessa dependncia de juno. Para notar que nenhum conjunto de dependncias multivaloradas implicam logicamente *((A, B), (B, C), (A, C)), consideramos a fig. 7.17 como uma relao r(A, B, C), como mostra a fig. 7.18.

A relao r satisfaz a dependncia de juno *((A, B), (B, C), (A, C)), como podemos verificar computando: e mostrando que o resultado exatamente r. Entretanto, r no satisfaz qualquer dependncia multivalorada notrivial. Para percebemos isso, verificamos que r no satisfaz nenhuma das A B, A C, B A, B C, C A, ou C B.

194

Da mesma forma que a dependncia multivalorada um modo de estabelecer a independncia de um par de relacionamentos, uma dependncia de juno um modo de estabelecer que os membros de um conjunto de relacionamentos so todos independentes. Essa noo de independncia de relacionamentos consequncia natural do modo pelo qual geralmente definimos uma relao. Considere: esquema_info_emprstimo=(nome_agncia, nome_cliente, nmero_emprstimo, total) de nosso exemplo bancrio. Podemos definir uma relao info_emprstimo (esquema_info_emprstimo) com o conjunto de todas as tuplas do esquema_info_emprstimo) com o conjunto de todas as tuplas do esquema_info_emprstimo, tal que: O emprstimo representado por nmero_emprstimo feito pela agncia de nome nome_agncia. O emprstimo representado por nmero_emprstimo feito pelo cliente chamado nome_cliente. O emprstimo representado por nmero_emprstimo est no total de nome total. A definio anterior da relao info_emprstimo uma conjugao de trs predicados: um em nmero_agncia e nome_agncia, um em nmero_emprstimo e nome_cliente e um em nmero_emprstimo e total. Supreendentemente, pode ser mostrado que a definio intuitiva anterior de info_emprstimo implica logicamente a dependncia de juno *((nmero_emprstimo, nome_agncia), (nmero_emprstimo, nome_cliente), (nmero_emprstimo, total)). Assim, as dependncias de juno tm um aspecto intuitivo e correspondem a um dos trs critrios apresentados para um bom projeto de banco de dados. Para dependncias funcionais e multivaloradas, temos de fornecer um sistema de regras de inferncias que devem ser vlidas e completas. Infelizmente, nenhum conjunto de regras conhecido para dependncias de junes. Esse fato nos leva a considerar classes mais genricas de dependncias que as dependncias de junes para construir um conjunto de regras de inferncias slido e completo.

Forma Normal de Projeo de Juno Forma normal de projeo de juno (FNPJ) definida de maneira similar a FNBC e a 4FN, exceto pelo fato das dependncias de junes serem usadas. Um esquema de relao r est em FNPJ com respeito a um conjunto D de dependncias funcionais, multivaloradas e de juno se, para todas as dependncias de junes ReR= , ao menos uma das seguintes for em D+ na forma *(R1, R2, ..., Rn), em que cada Ri validade: *(R1, R2, ..., Rn) uma dependncia de juno trivial. Todo Ri superchave para R. Um projeto de banco de dados est na FNPJ se cada membro de um conjunto de esquemas de relaes que constituem o projeto estiver na FNPJ. A FNPJ chamada quinta forma normal (5FN) em parte da literatura sobre normalizao de banco de dados. Retornaremos ao nosso exemplo bancrio. Dada a dependncia de juno *((nmero_emprstimo, nome_agncia), (nmero_emprstimo, nome_cliente), (nmero_emprstimo, total)), esquema_info_emprstimo no est na FNPJ. Para colocar esquema_info_emprstimo na FNPJ, precisamos decomp-la em trs esquemas especficos por meio da dependncia de juno: (nmero_emprstimo, nome_agncia), (nmero_emprstimo, nome_cliente) e (nmero_emprstimo, total). Como todas as dependncias multivaloradas so tambm dependncias de juno, fcil perceber que todo esquema na FNPJ est tambm na 4FN. Assim, em geral, no precisamos chegar decomposio com preservao de dependncia na FNPJ para um dado esquema. Forma Normal Domnio-chave 195

A abordagem que utilizamos para a normalizao toma por base a definio de restries (funcional, multivalorada ou dependncia de juno) e ento usa essa restrio para definir a forma normal. A forma normal domnio-chave (FNDC) baseia-se em trs noes: 1. Declarao de domnio. Seja A um atributo e dom um conjunto de valores. A declarao de domnio A dom exige que o valor de A em todas as tuplas seja um valor em dom. 2. Declarao de chaves. Seja R um esquema de relao com K R. A declarao da chave key(K) necessita que K seja uma superchave do esquema R isto , K R. Note que todas as declaraes de chaves so dependncias funcionais, mas nem todas as dependncias funcionais so declaraes de chaves. 3. Restries gerais. Uma restrio geral um predicado do conjunto de todas as relaes de um dado esquema. As dependncias que estudamos nesse captulo so exemplos de restries gerais. Normalmente, uma restrio geral um predicado expresso em uma forma agregada, como a lgica de primeira ordem. Damos agora um exemplo de uma restrio geral que no funcional, multivalorada ou dependente de juno. Suponha que todas as contas que comecem com o dgito 9 sejam contas especiais com altas taxas de juros, cujo saldo mnimo 2500 dlares. Ento inclumos como restrio geral: se o primeiro dgito de t[nmero_conta] for 9, ento t[saldo]2500. Declaraes de domnio e declaraes de chave so fceis de testar em um sistema de banco de dados prtico. Restries gerais, entretanto, podem ser extremamente custosas (em termos de tempo de processamento e espao) para testar. O proposito de um projeto de banco de dados na FNPJ permitir-nos o teste de restries gerais usando somente restries de domnio e chaves. Formalmente, seja D um conjunto de restries de domnio e K, um conjunto de restries por chaves para o esquema de relao R. Suponha que G represente as restries gerais de R. O esquema R est na FNDC se D K implica logicamente G. Retornemos s restries gerais que demos para as contas. As restries implicam que nosso projeto de banco de dados no est na FNDC. Para criar um projeto na FNDC, precisamos de dois esquemas no lugar do esquema_conta: esquema_conta_regular=(nome_agncia, nmero_conta, saldo) esquema_conta_especial=(nome_agncia, nmero_conta, saldo) Conservamos, como restries gerais, todas as dependncias que tnhamos no esquema_conta. As restries de domnio para esquema_conta_especial exigem que, para cada conta: O nmero da conta comece por 9. O saldo da conta seja maior que 2500. As restries de domnio para esquema_conta_regular exigem que o nmero da conta no comece por 9. O projeto resultante est na FNDC. Comparemos a FNDC com outras formas normais estudadas. Nas outras formas normais, no levamos em considerao restries de domnio. Assumimos (de modo implcito) que o domnio de cada atributo possui domnio infinito, como o conjunto de todos os inteiros ou conjunto de todas as cadeias de caracteres. Permitimos restries por chaves (de fato, permitimos dependncias funcionais). Para cada forma normal, permitimos uma forma especfica de restrio geral (um conjunto de dependncias funcionais, multivaloradas ou de juno). Assim, podemos reescrever as definies de FNPJ, 4FN, FNBC e 3FN de modo a mostra-las como casos especiais de FNDC. A seguir reescreveremos nossa definio de FNPJ inspirada na FNDC. Seja o esquema da relao R = (A1, A2, ..., An). Seja dom(Ai) o domnio do atributo Ai e sejam infinitos esses domnios. Ento, todas as restries de domnio D so da forma Ai dom(Ai). Sejam as restries gerais um conjunto G de dependncias funcionais 196

multivaloradas ou de juno. Se F um conjunto de dependncias funcionais em G, seja o conjunto K de restries por chave aquelas dependncias funcionais no triviais em F+ da forma R. O esquema R est na FNPJ se e somente se ele estiver na FNDC com respeito a D, K e G. Uma consequncia da FNDC que toda insero e remoo anmala eliminada. A FNDC constitui a ltima forma normal porque permite restries arbitrrias, em vez de dependncias, e permite ainda testes eficientes para essas restries. Naturalmente, se um esquema no est na FNDC, podemos alcan-la por meio de decomposies, mas tais decomposies, como j foi visto, no so sempre decomposies com preservao da dependncia. Assim, embora a FNDC seja a meta de um projetista de banco de dados, poder ser sacrificada em projetos reais. Abordagens Alternativas para Projeto de Banco de Dados Vamos reexaminar a normalizao de esquemas de relao com nfase nos efeitos dessa normalizao no projeto de um banco de dados real. Adotamos como abordagem comear com um nico esquema de relao e, ento, decomp-lo. Uma de nossas metas escolher uma decomposio que resulte em decomposio sem perda na juno. Para considerar essa ausncia de perda na juno, assumimos ser vlido falar em juno de todas as relaes de um banco de dados decomposto. Considere o banco de dados da fig. 7.19, representamos a relao info_emprstimo decomposta na FNPJ. Na fig. 7.19, representamos uma situao na qual ainda no determinamos o total do emprstimo L-58, mas desejamos registrar a existncia do dado no emprstimo. Se computarmos uma juno natural dessas relaes, notaremos que todas as tuplas referentes ao emprstimo L-58 desaparecero. Em outras palavras, no h nenhuma relao info_emprstimo correspondente s relaes da fig. 7.19. Tuplas que desaparecem quando computamos a juno so tuplas pendentes. Formalmente, seja r1(R1), r2(R2), ..., rn(Rn) um conjunto de relaes. Uma tupla t de uma relao ri uma tupla pendente se t no est na relao:

As tuplas pendentes podem ocorrer em aplicaes de banco de dados reais. Representam informaes incompletas, como ocorreu em nosso exemplo quando desejamos armazenar dados sobre um emprstimo que estava ainda em processo de negociao. A relao r1 r2 ... rn chamada relao universal, uma vez que envolve todos os atributos do universo definido por R1 R2 ... Rn. O nico modo por meio do qual podemos escrever uma relao universal para o exemplo da fig. 7.19 incluindo valores nulos na relao universal. Vimos que valores nulos originam srias dificuldades. Pesquisas a respeito de valores nulos e relaes so discutidos em notas bibliogrficas. Devido dificuldade de manuseio de valores nulos, pode ser mais adequado tratar as relaes de um projeto decomposto como a representao do banco de dados, em vez das relaes universais cujos esquemas foram decompostos durante o processo de normalizao.

197

Note que no devemos introduzir informaes incompletas no banco de dados da fig. 7.19 sem recorrer ao uso de valores nulos. Por exemplo, no podemos introduzir um nmero de emprstimo se no conhecermos ao menos uma das seguintes informaes: O nome do cliente. O nome da agncia. O total do emprstimo. Assim, uma decomposio em particular define uma forma restritiva para uma informao incompleta que aceitvel em nosso banco de dados. A forma normal que definimos gera bons projetos de banco de dados do ponto de vista da representao de informaes incompletas. Retornando novamente ao exemplo da fig. 7.19, poderamos desejar no permitir o armazenamento do seguinte fato: h emprstimos (cujo nmero desconhecido) para Jones cujo montante cem dlares. Uma vez que nmero_emprstimo nome_cliente total, o nico modo de podermos relacionar nome_cliente e total por meio de nmero_emprstimo. Se desejarmos saber o nmero do emprstimo, no poderemos diferenciar esse emprstimo de outros cujos nmeros so desconhecidos. Em outras palavras, no conseguimos armazenar dados cujos atributos-chave sejam desconhecidos. Observe que as formas normais que definimos no nos permitem armazenar esse tipo de informao sem a utilizao de valores nulos. Assim, nossas formas normais permitem a representao de informaes incompletas no desejveis. Se permitimos tuplas suspensas em nosso banco de dados, podemos preferir uma viso alternativa do processo de projeto de banco de dados. Em vez de decompor uma relao universal, podemos sintetizar uma coleo de esquemas na forma normal de um determinado conjunto de atributos. Estamos interessados nas mesmas formas normais, independente de usar decomposio ou sntese. A abordagem da decomposio melhor entendida e mais largamente utilizada. Outra consequncia da abordagem usada no projeto de um banco de dados que os nomes dos atributos devem ser nicos nas relaes universais. No podemos usar nome para referncia tanto para nome_cliente quanto para nome_agncia. Geralmente, prefervel usar nomes nicos, como vnhamos fazendo. Ainda assim, se definssemos nossos esquemas de relaes diretamente, em vez de usarmos relaes universais, obteramos relaes com esquema tais como os que se seguem para nosso exemplo bancrio: agncia_emprstimo (nome, nmero) cliente_emprstimo (nmero, nome) tot (nmero, total) Observe que, com as relaes anteriores, expresses como agncia_emprstimo cliente_emprstimo

no tm sentido. Na verdade, a expresso, agncia_emprstimo cliente_emprstimo aponta os emprstimos feitos para clientes cujos nomes sejam os mesmos do nome da agncia. Em linguagens como SQL, entretanto, h operaes de juno no-naturais, ento, em uma consulta envolvendo agncia_emprstimo e cliente_emprstimo, precisamos de referncias no ambguas para nome usando, para isso, o nome da relao como prefixo. Nesses ambientes, os diversos papeis de nome (como nome da agncia e nome do cliente), so menos problemticos e provavelmente de utilizao mais simples. Acreditamos que usar o critrio do papel nico cada nome de atributo tem um nico significado no banco de dados geralmente prefervel que a utilizao de um mesmo nome em diversos papeis. Quando o critrio do papel nico no adotado, o projetista do banco de dados deve ser cuidadoso durante a construo de um projeto de banco de dados relacional normalizado.

198

SQL 2003 Durante o desenvolvimento do sistema R, a IBM desenvolveu a linguagem SEQUEL, primeira linguagem de acesso aos SGBDs relacionais. Com o desenvolvimento de um nmero cada vez maior de SGBDs, fez-se necessrio especificar um padro da linguagem, chamada SQL, em 1986. Esse lanamento foi um esforo particular da ANSI em conjunto com a ISO. A padronizao de uma linguagem de consulta foi responsvel pelo sucesso dos SGBDs relacionais. Em linhas gerais, os comandos da linguagem SQL podem ser divididos em sublinguagens, tais como a Linguagem de Manipulao de Dados (DML) e a Linguagem de Definio de Dados (DDL). A DML trata dos comandos ligados manipulao de Dados, definindo comandos para a seleo, incluso, alterao e excluso dos dados das tabelas. J a DDL, rene os comandos para a criao e manuteno de estruturas e objetos do banco de dados, tais como tabelas, vises e ndices. Os fornecedores de Gerenciadores de Banco de Dados no hesitaram em adotar a SQL. Entretanto, criaram variaes prprias da linguagem, adicionando funes ou comandos que, muitas vezes, em virtude de seu sucesso, acabaram se incorporando em verses posteriores do padro. Contudo, a maior parte do padro implementado de forma idntica nos principais SGBDs, possibilitando a portabilidade de aplicaes e maior facilidade para os conhecedores da linguagem. A linguagem passou por aperfeioamento em 1989 e, em 1992, foi lanada a SQL-92, ou SQL2. Embora muitos dos conceitos especificados na SQL-92 somente tenham sido implementados por SGBDs relacionais cresceu rapidamente. A SQL:2003 a mais nova verso do padro SQL. Nesta verso foi feita uma grande reviso do padro SQL3 e adicionada uma nova parte, ligada ao tratamento de XML. Tipos de Dados Em banco de dados relacionais e relacionais estendidos, as informaes ficam armazenadas em tabelas. As tabelas so as materializaes das relaes do modelo relacional. Elas tm linhas e colunas, onde cada linha representa a instncia de um item armazenado e cada coluna uma informao relativa ao item em questo. A cada coluna de uma tabela est associado um tipo de dados, fazendo com que somente dados do tipo adequado sejam armazenados na coluna. A SQL define alguns tipos de dados que so implementados em alguns SGBDs. Ele define, tambm, os comandos para criao, alterao e excluso de tabelas. Tipos de dados bsicos Em banco de dados relacionais e relacionais-estendidos, as informaes so armazenadas em tabelas. Cada tabela poder conter vrias colunas, as quais esto armazenados dados. A cada coluna existir um tipo de dados associado. O tipo de dados de cada coluna definido durante a criao da tabela. O padro de SQL define vrios tipos de dados simples. Permite, tambm, que o usurio defina tipos de dados prprios, a partir da composio de tipos definidos pela linguagem. A tabela 2.1 apresenta os principais tipos de dados definidos no padro da linguagem SQL. A partir desta, podemos dividir os tipos de dados em cinco grupos: (i) relativos a cadeias de caracteres; (ii) relativos a dados numricos; (iii) para armazenamento de objetos grandes; (iv) para armazenamento de informao booleana e (v) tipos de dados relativos a datas e horas.

199

Os vrios fornecedores de SGBDs utilizam variaes prprias de dados definidos no SQL:2003. Criando Tabelas Uma tabela a materializao de um local para armazenamento de dados. Tais dados so agrupados em linhas. Cada linha contm um conjunto de uma ou mais colunas. Todas as linhas tm o mesmo nmero de colunas. Cada coluna possui seu tipo de dados prprio, que o mesmo para todas as linhas. Ao criarmos uma tabela, devemos especificar o seu nome, quais colunas que a compe e quais os tipos de dados das colunas em questo. Alm disso, podem ser definidas restries de integridade e regras de domnio, entre outros. Assim, podemos especificar, durante a criao de uma tabela, por exemplo, que uma coluna referese chave primria da tabela ou que uma dada coluna somente poder conter determinados valores. Quando uma tabela criada, ela no contm dados, ou seja, linhas. Somente depois os dados so inseridos. Entretanto, algumas colunas da tabela podem no ter o seu preenchimento obrigatrio. Para estas, quando nenhum dado for fornecido durante a incluso, includo o valor NULL (nulo). A princpio, todas as colunas, independente de seus tipos de dados, podem apresentar o valor NULL no seu contedo, em uma ou mais linhas. Ou seja, uma coluna definida como de tipo INTEGER pode suportar nmeros inteiros ou o valor NULL. Da mesma forma, uma coluna CHAR suporta cadeia de caracteres ou o valor NULL. Notamos que NULL indica ausncia de valor definido. diferente de zero ou de uma cadeia de caracteres de comprimento zero. Ao criarmos uma tabela, podemos especificar que uma ou mais colunas no podem conter o valor NULL. Ou seja, tais colunas tm o seu preenchimento obrigatrio. Quando nada informado para uma coluna, ela aceita NULL no seu contedo. Utilizamos o comando CREATE TABLE para criao de tabelas. A sintaxe bsica do comando a seguinte: CREATE TABLE NOME_TABELA( COL1 TIPO_COL1 [NOT NULL], COL2 TIPO_COL2 [NOT NULL], COLN TIPO_COLN [NOT NULL] 200

) Exemplo de criao de tabela no Oracle 10g: CREATE TABLE EDITORA ( CODIGO NUMBER(2) NOT NULL, NOME VARCHAR2(80) NOT NULL ) Podemos, na criao de tabelas, especificar vrios tipos de restries. Para uma dada coluna, a SQL:2003 nos permite que restries sejam especificadas aps o nome do tipo de dados da coluna em questo. As principais restries so: Chave primria: devemos posicionar a expresso PRIMARY KEY ao lado da definio do tipo de dados da coluna em questo. Chave estrangeira: posicionamos a expresso FOREIGN KEY REFERENCES NOME_TABELA ao lado da definio do tipo da coluna. FOREIGN KEY opcional. NOME_TABELA deve ser substitudo pelo nome da tabela que referenciada pela chave estrangeira. A tabela referenciada pela chave estrangeira deve ser criada antes da criao da chave estrangeira. Chave alternada: a expresso UNIQUE deve ser usada ao lado da definio do tipo de dados da coluna. UNIQUE faz com que no seja possvel inserir valores repetidos na coluna. Restrio de domnio: para verificar que o valor de uma coluna deve estar contido em uma lista ou faixa de valores, utilizamos a palavra CHECK, seguida de uma expresso booleana delimitada por parnteses. CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO Onde: Constraint indica a definio de uma restrio de integridade. Nome_Restricao nome dada a restrio (CONSTRAINT) que est sendo criada. Tipo_Restricao tipo da restrio que est sendo criada: PRIMARY KEY, FOREIGN KEY OU UNIQUE, por exemplo. No caso de uma chave estrangeira, FOREIGN KEY opcional e o comando deve ser complementado com a clusula REFERENCES. A designao de um nome para cada restrio bastante til para o controle de erros que porventura ocorram. Suponha que, por exemplo, durante a execuo de um programa que acessa um banco de dados, tentese incluir um valor repetido em linhas de uma coluna marcada como chave primria de uma tabela. Neste caso, o SGBD no permite operao e um erro ocorre. O SGBD informa, na mensagem de erro, o nome da restrio que foi violada. Isto permite que a aplicao trate o erro corretamente ou, ainda que seja mais facilmente detectado o ponto onde a aplicao deve ser alterada de forma a no permitir que tal situao ocorra. Por isso, interessante que o nome da CONSTRAINT indique o tipo de restrio, a tabela a que se refere e, quando possvel, a coluna que sofre a restrio. Consideremos a coluna CPF da tabela AUTOR. Esta coluna no deve aceitar valores repetidos. Para isso, utilizamos a seguinte definio para a coluna: CPF CHAR(11) NOT NULL UNIQUE Por exemplo, para criar a tabela EDITORA no banco de dados Oracle 10g: CREATE TABLE EDITORA ( CODIGO NUMBER(2) NOT NULL PRIMARY KEY, NOME VARCHAR2 (80) NOT NULL ) Para criar a tabela ASSUNTO, definindo PK_ASSUNTO como nome para a CONSTRAINT chave primria, utilizamos, no Oracle 10g: CREATE TABLE ASSUNTO( SIGLA CHAR(1) NOT NULL CONSTRAINT PK_ASSUNTO PRIMARY KEY, DESCRICAO VARCHAR2(50) 201

) Vejamos agora, um exemplo da definio de chave estrangeira, a partir da criao da tabela LIVRO. Atribuiremos o nome PK_LIVRO para a restrio de chave primria, FK_LIVRO_ASSUNTO para a restrio de chave estrangeira da coluna que referencia a tabela ASSUNTO e FK_LIVRO_EDITORA para a restrio de chave estrangeira da coluna que referencia a tabela EDITORA. CREATE TABLE LIVRO( CODIGO NUMBER(3) NOT NULL CONSTRAINT PK_LIVRO PRIMARY KEY, TITULO VARCHAR2(80) NOT NULL, PRECO NUMBER(10,2), LANCAMENTO DATE, ASSUNTO CHAR(1) CONSTRAINT FK_LIVRO_ASSUNTO REFERENCES ASSUNTO, EDITORA NUMBER(2) CONSTRAINT FK_LIVRO_EDITORA REFERENCES EDITORA ) Restries de domnio podem ser implementadas atravs da clusula CHECK, seguida da expresso booleana delimitada por parnteses. Para a montagem da expresso booleana podemos utilizar operadores de comparao (<,>,>=,<=, =, <>) e predicados como LIKE e IN. Exemplos: Para definirmos a coluna SIGLA, que no admite valores nulos, somente possa aceitar os valores R, B e F: SIGLA CHAR(1) NOT NULL CHECK (SIGLA IN(R, B, F)) Para definirmos que a coluna MATRICULA somente aceitar valores maiores que 1000: MATRICULA INTEGER CHECK (MATRICULA > 1000) Podemos, tambm, atribuir um valor padro para as colunas de uma tabela. O valor padro ser automaticamente atribudo coluna durante a criao de uma linha, caso nenhum valor tenha sido fornecido. Sua definio d-se no momento da criao da tabela atravs da clusula DEFAULT, conforme apresentado a seguir: COL1 TIPO_COLUNA DEFAULT VALOR_PADRAO Por exemplo: SEXO CHAR(1) DEFAULT M A utilizao de restries de integridade no banco de dados pode ser bastante til para a manuteno da correo das informaes. A definio de chaves primrias e restries UNIQUE impedem que sejam includos valores repetidos em uma dada coluna. A definio de chaves estrangeiras faz com que somente sejam permitidos valores que existam na tabela referenciada. A tabela 2.6 apresenta um contedo da tabela EDITORA:

202

Na tabela LIVRO que criamos anteriormente, especificamos a coluna EDITORA como chave estrangeira para a tabela EDITORA. Dessa forma, se considerarmos o contedo da tabela EDITORA apresentado na tabela acima, ento a coluna EDITORA da tabela LVIRO somente poder conter os valores NULL, 1, 2, 3 e 4. Se tentarmos incluir quaisquer outros valores, o SGBD gerar um erro e no permitir a incluso das informaes. Considere, agora, que existe uma linha na tabela LIVRO onde a coluna EDITORA possua o valor 2. Consideremos que um usurio tente excluir, da tabela EDITORA, a linha de cdigo 2. Se isto for possvel, teremos uma inconsistncia nos dados, pois existir um valor na chave estrangeira da tabela LIVRO que no existe na chave primria da tabela EDITORA. De acordo com o padro SQL possvel especificar, durante a definio da restrio, trs diferentes aes a serem tomadas pelo SGBD, quando tal situao ocorrer: Impedir a excluso da linha da tabela pai (EDITORA) caso existam outras tabelas que referenciem o valor a ser excludo. A linha no excluda e um erro gerado. Esta a situao padro, a qual ocorrer sempre que uma chave estrangeira for definida, a menos que declaremos o contrrio. especificada atraves da opo ON DELETE RESTRICT; ASSUNTO CHAR(1) CONSTRAINT FK_LIVRO_ASSUNTO REFERENCES ASSUNTO ON DELETE RESTRICT Alterar o valor da coluna da chave estrangeira na tabela filho (LIVRO), tornando-o NULL para as linhas que possuam o valor que est sendo apagado na tabela pai. A linha da tabela pai tambm apagada. Esta ao especificada atraves da clusula ON DELETE SET NULL; ASSUNTO CHAR(1) CONSTRAINT FK_LIVRO_ASSUNTO REFERENCES ASSUNTO ON DELETE SET NULL

Apagar as linhas da tabela filho onde existir, na coluna de chave estrangeira, o valor que est sendo apagado na tabela pai. A linha da tabela pai tambm apagada. Esta ao definida atraves da clusula ON DELETE CASCADE. ASSUNTO CHAR(1) CONSTRAINT FK_LIVRO_ASSUNTO REFERENCES ASSUNTO ON DELETE CASCADE Existe, ainda, um outro formato para a especificao de restries em tabelas. Podemos especificar restries aps a declarao de todas as colunas. Neste caso, deveremos seguir o formato: CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO (COLUNA1_RESTRICAO, COLUNA2_RESTRICAO,...)

203

Eis a sintaxe do Oracle 10g: CREATE TABLE LIVRO ( CODIGO NUMBER(3), TITULO VARCHAR2(80) NOT NULL, PRECO NUMBER(10,2), LANCAMENTO DATE, ASSUNTO CHAR(1), EDITORA NUMBER(2) CONSTRAINT PK_LIVRO PRIMARY KEY (CODIGO), CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY (ASSUNTO) REFERENCES ASSUNTO, CONSTRAINT FK_LIVRO_EDITORA FOREIGN KEY (EDITORA) REFERENCES EDITORA ) Alterando tabelas A SQL:2003 nos d a opo de alterar tabelas j existentes no banco de dados. Para isso, utilizamos o comando ALTER TABLE. Este comando pode ser utilizado em conjunto com as clusulas adicionais para executar, entre outras, uma das seguintes opes: Incluir novas colunas em uma tabela existente; Excluir colunas existentes em uma tabela; Adicionar a definio de uma restrio a uma tabela existente; Excluir a definio de uma restrio existente em uma tabela. Incluindo novas colunas em uma tabela j existente Para incluir novas colunas em uma tabela, utilizamos o comando ALTER TABLE, conforme a seguir: ALTER TABLE NOME_TABELA ADD [COLUMN] NOME_COLUNA TIPO_COLUNA RESTRICOES Por exemplo, vamos adicionar a coluna IDENTIDADE tabela AUTOR, j criada no banco de dados. ALTER TABLE AUTOR ADD IDENTIDADE CHAR(10) Excluindo colunas existentes em uma tabela Para excluir colunas existentes em uma tabela, utilizamos o comando ALTER TABLE no formato apresentado a seguir: ALTER TABLE NOME_TABELA DROP [COLUMN] NOME_COLUNA Por exemplo, vamos remover a coluna IDENTIDADE da tabela AUTOR, j criada no banco de dados: ALTER TABLE AUTOR DROP COLUMN IDENTIDADE Adicionando a definio de uma restrio a uma tabela existente ALTER TABLE NOME_TABELA ADD CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO (COLUNA1_RESTRICAO, COLUNA2_RESTRICAO, ...) 204

Por exemplo, suponha que tenhamos criado a tabela LIVRO sem especificar nenhuma restrio. Vamos agora adicionar essas restries atraves de trs comandos: Adicionando a chave primria: ALTER TABLE LIVRO ADD CONSTRAINT PK_LIVRO PRIMARY KEY (CODIGO) Adicionando a chave estrangeira a tabela ASSUNTO: ALTER TABLE LIVRO ADD CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY (ASSUNTO) REFERENCES ASSUNTO Adicionando a chave estrangeira para a tabela EDITORA: ALTER TABLE LIVRO ADD CONSTRAINT FK_LIVRO_EDITORA FOREIGN KEY (EDITORA) REFERENCES EDITORA Excluindo a definio de uma restrio existente em uma tabela Alterando tabelas Podemos tambm alterar tabelas j definidas no banco de dados. Para isso utilizamos o comando ALTER TABLE. Este comando pode ser utilizado em conjunto com as clusulas adicionais para executar, entre outras, uma das seguintes opes: Incluir novas colunas em uma tabela existente; Excluir colunas existentes em uma tabela; Adicionar a definio de uma restrio em uma tabela j existente; Excluir a definio de uma restrio existente em uma tabela. Incluir novas colunas em uma tabela existente Para incluir novas colunas em uma tabela existente, utilizamos o comando ALTER TABLE conforme a seguir: ALTER TABLE NOME_TABELA ADD [COLUMN] NOME_COLUNA TIPO_COLUNA RESTRICOES Por exemplo: vamos adicionar a coluna IDENTIDADE tabela AUTOR, j criada no banco de dados. ALTER TABLE AUTOR ADD IDENTIDADE CHAR(10) Excluindo colunas existentes em uma tabela, utilizamos o comando ALTER TABLE no formato apresentado a seguir: ALTER TABLE NOME_TABELA DROP [COLUMN] NOME_COLUNA Exemplo, vamos remover a coluna IDENTIDADE da tabela AUTOR, j criada no banco de dados: ALTER TABLE AUTOR DROP COLUMN IDENTIDADE Adicionando a definio de uma restrio a uma tabela existente Para incluir uma nova restrio a uma tabela existente, tambm utilizamos o comando ALTER TABLE. A sintaxe bsica utilizada : 205

ALTER TABLE NOME_TABELA ADD CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO (COLUNA1_RESTRICAO, COLUNA2_RESTRICAO, ...) Por exemplo: Suponha que tenhamos criado a tabela LIVRO sem especificar nenhuma restrio. Vamos, agora, adicionar as restries a essa tabela, atravs de trs comandos. Adicionando a chave primria: ALTER TABLE LIVRO ADD CONSTRAINT PK_LIVRO KEY(CODIGO) Adicionando a chave estrangeira para a tabela ASSUNTO: ALTER TABLE LIVRO ADD CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY(ASSUNTO) REFERENCES ASSUNTO Adicionando a chave estrangeira para a tabela EDITORA: ALTER TABLE EDITORA ADD CONSTRAINT FK_LIVRO_EDITORA FOREIGN KEY (EDITORA) REFERENCES EDITORA Excluindo a definio de uma restrio existente em uma tabela O comando ALTER TABLE tambm pode ser utilizado para excluir uma restrio j existente em uma tabela. Para isso, utilizamos o seguinte formato: ALTER TABLE NOME_TABELA DROP CONSTRAINT NOME_RESTRICAO Por exemplo, desejamos excluir a chave primria da tabela LIVRO: ALTER TABLE LIVRO DROP CONSTRAINT PK_LIVRO Desejamos destruir a chave estrangeira da tabela LIVRO que aponta para a tabela EDITORA. ALTER TABLE LIVRO DROP CONSTRAINT FK_LIVRO_EDITORA Destruindo tabelas Para destruir uma tabela utilizamos o comando DROP TABLE. Sua sintaxe bsica : DROP NOME NOME_TABELA [CASCADE] Exemplo: Para destruir a tabela LIVRO. DROP TABLE LIVRO

206

Comandos Bsicos Incluso de Dados Para incluirmos dados em uma tabela, devemos utilizar o comando INSERT. Sua sintaxe bsica, segundo a qual inserimos uma linha em uma tabela mostrada a seguir: INSERT INTO NOME_TABELA (COL1, COL2, ..., COLN) VALUES (VAL1, VAL2, ..., VALN) Considere a tabela LIVRO j apresentada anteriormente. A tabela 3.1 apresenta um exemplo de instncia da tabela LIVRO apresentado. Notamos que existe um livro com valor nulo para o campo LANCAMENTO. Isso significa que ele ainda no foi lanado.

A descrio completa dos assuntos est na tabela ASSUNTO. Nesta existem vrios assuntos cadastrados, independentemente se existe um livro do assunto em questo. Tomemos a tabela 3.2 como exemplo de instncia da tabela EDITORA.

Para concluirmos as trs primeiras linhas na tabela LIVRO, devemos realizar os seguintes comandos INSERT: INSERT INTO LIVRO (CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES (1, BANCO DE DADOS PARA WEB, 31.2, 10/01/1999, B, 1) INSERT INTO LIVRO (TITULO, CODIGO, LANCAMENTO, PRECO, ASSUNTO, EDITORA) VALUES (PROGRAMANDO EM LINUGAGEM C, 2, 01/10/1997, 30, P, 1) Notamos que a diferena dos dois primeiros comandos anteriores est na diferena da ordem. Quando especificamos o nome no h uma limitao na ordenao das mesmas. A especificao dos nomes das colunas permite, ainda, que no sejam inseridos dados para todas as colunas de uma tabela. Considere o caso do livro de cdigo 4, que no possui data de lanamento. Ao inseri-lo, podemos omitir a coluna LANCAMENTO do comando INSERT a ser utilizado: INSERT INTO LIVRO (CODIGO, TITULO, PRECO, ASSUNTO, EDITORA) VALUES (4, BANCO DE DADOS PARA INFORMATICA, 48, B, 2) 207

Neste caso, ser inserido o valor NULL para LANCAMENTO. Note que, se essa coluna possuir uma restrio para no aceitar valores nulos, e no estiver definido um valor padro, o comando no poder ser executado. Outra forma de executar o comando anterior, especificando todas as colunas da tabela, atravs da utilizao da palavra NULL: INSERT INTO LIVRO (CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES (4, BANCO DE DADOS PARA BIOINFORMATICA, 48, NULL, B, 21) Caso estejamos inserindo valores para todas as colunas da tabela, podemos omitir seus nomes. Entretanto, nesse caso, devemos especificar os valores a serem inseridos na mesma ordem em que as colunas da tabela foram criadas: Errado: INSERT INTO LIVRO VALUES (R, 42, 5, 01/09/1996, REDES DE COMPUTADORES, 2) Correto: INSERT INTO LIVRO (CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES (5, REDES DE COMPUTADORES, 42, 01/09/1996, R, 2) Quando inclumos dados em tabelas que possuem chaves estrangeiras referenciando outras tabelas, os valores que esto sendo inseridos nas colunas da chave estrangeira j devem constar na chave primria da tabela referenciada. Consulta simples A consulta simples a dados armazenados , usualmente, a operao realizada com mais freqncia em sistemas comerciais. medida que a quantidade de linhas em tabelas cresce e que utilizamos varias tabelas em uma mesma consulta, no s a complexidade do comando SQL aumenta, como tambm o tempo de resposta da consulta pode ser muito alto, exigindo, assim, mais ateno na montagem do comando. Para a realizao de consulta ao banco de dados, utilizamos o comando SELECT. A sintaxe bsica do comando SELECT : SELECT COL1, COL2, ..., COLN FROM NOME_TABELA Considere a instncia da tabela LIVRO apresentado anteriromente. Se quisermos recuperar as colunas TITULO e CODIGO dessa tabela, devemos executar o comando: SELECT CODIGO, TITULO FROM LIVRO Se quisermos recuperar todas as colunas da tabela LIVRO podemos especific-la no comando SELECT ou utilizar o caractere *. As consultas: SELECT CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA FROM LIVRO e SELECT * FROM LIVRO

208

Quando especificamos as colunas no comando SELECT, elas sero apresentadas no resultado, na ordem especificada. Quando o caractere * utilizado, as colunas estaro ordenadas da mesma forma que o foram na criao da tabela. A clusula WHERE Os resultados de comandos como apresentado anteriormente possuem todas as linhas da tabela. No entanto, na maioria das consultas queremos consultar apenas as informaes referentes a algumas linhas. Essas linhas devem atender a alguma condio. A clusula WHERE permite que sejam especificadas linhas sobre as quais ser aplicada. A instruo pode ser um comando SELECT ou comandos de atualizao e excluso de dados. WHERE sempre usada com expresses lgicas, a qual pode ser operadores de comparao (>,<,>=,<=, =, <>), operadores lgicos (AND, OR e NOT) e predicados prprios de linguagem SQL, tais como IS(NOT) NULL, IS (NOT) LIKE, IN e EXISTS. Os operadores lgicos AND e OR so usados para conectar comparaes. A expresso lgica ter um resultado que poder assumir os valores verdadeiro ou falso. A instruo especificada ser executada para as linhas que tornarem o resultado da expresso lgica verdadeiro. Por exemplo: Preo superior a R$ 50,00 WHERE PRECO > 50 Preo igual a R$ 50,00 e de assunto p WHERE PRECO > 50 AND ASSUNTO = P Preo inferior a R$ 50,00 ou de assunto P WHERE PRECO < 50 OR ASSUNTO = P Lanamento nulo WHERE LANCAMENTO IS NULL Quando realizamos comparaes com colunas de tipos cadeias de caracteres, frequentemente queremos encontrar valores que possuem determinados caracteres ou sequencias de caracteres. Para tal, usamos o predicado LIKE em conjunto com um ou mais caracteres coringa. O caractere coringa usado para substituir um ou mais caracteres que no conhecemos. Os caracteres coringa so % e _. O caractere % utilizado para substituir uma cadeia ilimitada de caracteres onde ele posicionado, enquanto _ substitui zero ou apenas um caractere. Por exemplo: WHERE TITULO IS LIKE %BANCO_ DE DADOS% Atualizao de informaes Os dados inseridos em tabelas do banco de dados podem ser modificados. Para tal, utiliza-se o comando UPDATE. Sua sintaxe : UPDATE NOME_TABELA SET COL1 = VAL1, COL2 = VAL2, ..., COLN = VALN WHERE EXPRESSAO_LOGICA Considerando a tabela LIVROS, temos os seguintes exemplos: Atualizar o preo de todos os livros fornecendo um aumento de 10%. UPDATE LIVRO SET PRECO = PRECO * 1.1 Atualizar o preo do livro Programando em Linguagem C para R$ 32,00. UPDATE LIVRO SET PRECO = 32 WHERE TITULO = PROGRAMANDO EM LINGUAGEM C 209

Alterar o titulo e o preo do livro de cdigo 2 para Programao em Linguagem C e R$ 42,00, respectivamente. UPDATE LIVRO SET PRECO = 42, TITULO = PROGRAMACAO EM LINGUAGEM C WHERE CODIGO = 2 Quando atualizamos os dados de uma ou mais colunas marcadas como chaves estrangeiras, os novos valores j devem constar na chave primria da tabela referenciada. Excluso de linhas O comando DELETE utilizado para excluir linhas de uma tabela. Sua sintaxe a seguinte: DELETE FROM NOME_TABELA WHERE EXPRESSAO_LOGICA Nos exemplos a seguir, utilizaremos novamente a tabela LIVROS: Excluir todos os livros da tabela. DELETE FROM LIVRO Excluir os livros que tenham preo superior a R$ 100,00 e que no tenham sido lanados. DELETE FROM LIVRO WHERE LANCAMENTO IS NULL AND PRECO > 100 Excluir os livros que tenham R como assunto ou que ainda no tenham sido lanados. DELETE FROM LIVRO WHERE ASSUNTO = R OR LANCAMENTO IS NULL Agrupamento Dados Na linguagem SQL so definidas vrias funes que operam sobre grupos de dados. Tais funes, usualmente, realizam operaes ou comparaes sobre um conjunto de dados e retornam, como resultado, uma relao de apenas uma linha ou uma coluna. So chamadas Funes Agregadas. Contagem Muitas vezes necessrio contar uma quantidade de linhas que satisfaz uma determinada condio. Para isso, utilizamos a funo COUNT. Assim como as outras funes que sero apresentadas mais adiante, a funo COUNT recebe um parmetro e retorna um numero. Como parmetro para a funo COUNT podemos utilizar o nome de uma coluna ou o caractere *. No caso da utilizao do caractere * o resultado obtido a contagem do numero de linhas da tabela. No caso da utilizao de uma coluna como parmetro, o reesultado obtido o numero de ocorrncias no nulas desta coluna na tabela pesquisada. Por exemplo: Contar a quantidade de linhas da tabela LIVRO: SELECT COUNT(*) FROM LIVRO Contar a quantidade de linha da tabela LIVRO com a coluna de cdigo preenchida: SELECT COUNT(CODIGO) FROM LIVRO A funo COUNT retornar zero quando nenhuma linha atender ao critrio utilizado. Soma 210

Outra operao comumente utilizada a soma. Para realizar a soma de valores de uma coluna para um grupo de dados, utilizamos a funo SUM. Exemplo: Somatrio dos preos da tabela de livros: SELECT SUM(PRECO) FROM LIVRO A funo SUM retornar o somatrio dos valores no-nulos da coluna utilizada como parmetro. Retornar NULL se todos os valores desta coluna forem nulos ou se nenhum valor atender ao critrio de seleo. Mdia Para obter a mdia aritmtica dos valores de uma coluna utilizada como parmetro, utilizamos o comando AVG, informando, como parmetro para a mesma, o nome da coluna para a qual desejamos obter a mdia. A funo AVG retornar a mdia considerando apenas os valores no-nulos da coluna especificada. Exemplo: SELECT AVG(PRECO) FROM LIVRO Valor Mximo Para obter o valor mximo de uma coluna em um conjunto de dados, utilizamos a funo MAX. Assim como a funo AVG, MAX recebe um parmetro e retorna o valor NULL se em todas as linhas da tabela consultada o valor da coluna em questo for nulo, ou se nenhuma linha atender ao valor do critrio de seleo. Exemplo: SELECT MAX(PRECO) FROM LIVRO WHERE ASSUNTO = P Valor mnimo Em oposio funo MAX, temos a funo MIN, que retorna o menor valor de uma coluna para a tabela especificada. Menor preo da tabela de livros, para cujos livros o assunto seja B: SELECT MIN(PRECO) FROM LIVRO WHERE ASSUNTO = B Outras funes Podemos destacar: STDDEV_POP: desvio padro da populao; STDDEV_SAMP: desvio padro da amostra; VAR_POP: varincia calculada como o quadrado de STDDEV_POP; VAR_SAMP: varincia calcula como o quadrado de STDDEV_SAMP. Clusula GROUP BY Para utilizarmos uma funo de agregao em conjunto com colunas da tabela na clusula SELECT, devemos utilizar a clusula GROUP BY. A sintaxe de utilizao da clusula GROUP BY a seguinte: SELECT COL1, COL2, ..., COLN, FUNCAO1, , FUNCAON FROM NOME_TABELA WHERE CONDICAO 211

GROUP BY COL1, COL2, ..., COLN A utilizao da clusula GROUP BY faz com que os dados sejam sumarizados pelas colunas que so especificadas na mesma. Assim, somente valores distintos destas colunas farao parte do resultado. Neste caso, torna-se possvel utilizar funes agregadas, as quais iro operar sobre as linhas que foram utilizadas para montar cada grupo (sumarizao) de dados. Vejamos alguns exemplos: Qual o preo mdio dos livros de cada assunto? SELECT ASSUNTO, AVG(PRECO) FROM LIVRO GROUP BY ASSUNTO Quantos livros existem para cada assunto? SELECT ASSUNTO, COUNT(*) FROM LIVRO GROUP BY ASSUNTO Qual o preo do livro mais caro de cada assunto, dentre aqueles que j foram lanados? SELECT ASSUNTO, MAX(PRECO) FROM LIVRO WHERE LANCAMENTO IS NOT NULL GROUP BY ASSUNTO Quantos livros j foram lanados para cada editora? SELECT EDITORA, COUNT(*) FROM LIVRO WHERE LANCAMENTO IS NOT NULL GROUP BY EDITORA Clusula HAVING A clusula WHERE no nos permite realizar no nos permite realizar restries com base nos resultados das funes agregadas. Para isso, devemos utilizar a clusula HAVING. A clusula HAVING ser seguida de uma expresso lgica que poder ser composta ou no, de forma idntica ao que foi apresentado na clusula WHERE. Assim como a clusula WHERE, a clusula HAVING serve de filtro para as linhas constantes do resultado do comando SQL. A principal diferena entre essas clusulas se d no fato de que, no caso da clusula WHERE, o filtro aplicado quando as linhas so recuperadas do banco de dados, fazendo com que estas nem cheguem a ser consideradas quando da realizao de agrupamentos ou na execuo da funo de agregao. J as restries descritas na clusula HAVING sero aplicadas somente aps a recuperao das linhas no banco de dados, da montagem dos grupos e da execuo de funes agregadas. Por isso, possvel utilizar funes agregadas em expresses lgicas da clusula HAVING. Sintaxe bsica: SELECT COL1, COL2, ..., COLN FROM NOME_TABELA WHERE EXPRESSAO_LOGICA_WHERE GROUP BY COL1, COL2,..., COLN HAVING EXPRESSAO_LOGICA_HAVING Exemplo: Quais os assuntos cujo preo mdio dos livros ultrapassa R$50,00? 212

SELECT ASSUNTO FROM LIVRO GROUP BY ASSUNTO HAVING AVG(PRECO) > 50 Quais os assuntos que possuem mais de dois livros? SELECT ASSUNTO, COUNT(*) FROM LIVRO GROUP BY ASSUNTO HAVING COUNT(*) > 1 Quais os assuntos que possuem mais de dois livros j lanados? SELECT ASSUNTO, COUNT(*) FROM LIVRO GROUP BY ASSUNTO HAVING COUNT(*) > 1 Quantos livros j foram lanados por assunto? SELECT ASSUNTO, COUNT(*) FROM LIVRO WHERE LANCAMENTO IS NULL GROUP BY ASSUNTO

213

Operando, Ordenando e Formatando Resultados Usando apelidos No possvel atribuir apelidos tanto a colunas quanto a tabelas, e referenci-las atravs de seus apelidos. Apelidos para colunas atribuir um apelido a uma coluna resultante de uma consulta extremamente fcil. Veja a sintaxe: SELECT COL1 AS MINHA_COLUNA FROM NOME_TABELA Quaisquer construes particionadas na clusula SELECT, como as funes, podem receber apelidos. Por exemplo: Considere a consulta que retorna o maior preo da tabela de livros para livros cujo assunto seja P: SELECT MAX(PRECO) AS PRECO_MAXIMO FROM LIVRO WHERE ASSUNTO = P Apelidos para as tabelas em nossas consultas ao banco de dados podemos fazer referncia a uma coluna explicitando a sua tabela de origem como uma construo no formato: NOME_TABELA.NOME_COLUNA. Na verdade, h situaes onde somos obrigados a utilizar esse tipo de construo. Em alguns casos, as tabelas so representadas por nomes extensos e utilizar a construo anterior pode no ser s cansativo quanto tornar o comando extenso e confuso. Nessas situaes, possuir um apelido menor e expressivo para a tabela interessante. Na verdade, no se trata somente de questo de clareza de comando. H situaes onde somos obrigados a utilizar apelidos para tabelas e relaes. Vejamos, ento, como fornecer apelidos para tabelas: SELECT COL1 FROM NOME_TABELA_ORIGINAL AS NOVO_NOME_TABELA Abaixo, a tabela LIVRO substituda pelo apelido L: SELECT MAX(L.PRECO) AS PRECO_MAXIMO FROM LIVRO L WHERE L.ASSUNTO = P Constantes e concatenao A SQL permite definir constantes que sero repetidas em todas as linhas do resultado de uma consulta, o que atende ao caso anterior. Para isso, basta especificar a constante desejada na clusula SELECT do comando. Por exemplo: SELECT LIVRO: AS TEXTO, TITULO FROM LIVRO Neste exemplo, a cadeia de caracteres LIVRO: foi tratada como uma coluna independente. A linguagem SQL define o operador de concatenao ||, e deve ser utilizado entre as colunas ou textos que desejamos concatenar. Vejamos o exemplo da utilizao de concatenao do exemplo anterior: SELECT LIVRO: || TITULO AS TEXTO FROM LIVRO Realizando operaes aritmticas

214

Da mesma forma que utilizamos a clusula SELECT, podemos realizar operaes aritmticas sobre os resultados de uma consulta. Os operadores +, -, *, e / podem ser utilizados em expresses matemticas. Alm disso, parnteses tambm podem ser utilizados, para determinar prioridades na execuo das operaes. Por exemplo: Listar os novos preos dos livros se os valores fossem reajustados em 10%. SELECT TITULO, PRECO*1.1 AS NOVO_PRECO FROM LIVRO Podemos reescrever a consulta para demonstrar a utilizao de outros operadores mas obtendo o mesmo resultado. SELECT TITULO, PRECO + (PRECO/10) AS NOVO_PRECO FROM LIVRO Notamos que as operaes realizadas modificam somente o resultado das consultas, no alterando os dados das tabelas. Aplicando Funes Formatando os resultados de uma consulta atravs de funes do SGBD pode fornecer resultados mais compreensveis e, tambm, fazer com que a consulta retorne informaes em formato adequado para exibio ao usurio final. Alm disso, muitas vezes, podemos utilizar funes que manipulam os resultados de consultas SQL formatando-os ou alterando-os. Cadeia de caracteres o padro SQL define vrias funes que manipulam e formatam cadeias de caracteres. Nesta seo so apresentadas as principais: UPPER, LOWER, TRIM, SUBSTRING e LENGHT. As funes UPPER, LOWER, TRIM e LENGHT recebem uma cadeia de caracteres (ou uma coluna de dados do tipo cadeia de caracteres) como parmetro e retornam um resultado do mesmo tipo. J a funo SUBSTRING, que tambm retorna uma cadeia de caracteres como resultado, recebe trs parmetros como entrada, sendo dois numricos e uma cadeia de caracteres. A funo UPPER retornam o seu parmetro de entrada com todos os caracteres convertidos para maisculas. Em oposio funo UPPER, a funo LOWER retorna todos os caracteres convertidos para minsculos. Vejamos um exemplo: SELECT UPPER(LIVRO:) || LOWER(TITULO) AS TEXTO FROM LIVRO A funo TRIM retira os caracteres espao contidos nas margens da cadeia de caracteres que recebe como parmetro. Exemplo: Consulta: SELECT TRIM( LIVRO: ) || TITULO AS TEXTO FROM LIVRO WHERE ASSUNTO = P A funo SUBSTRING retorna o trecho da cadeia de caracteres que ela recebe como parmetro. O trecho a ser retornado definido por outros dois parmetros de entrada: a posio de incio do trecho e o seu comprimento. Exemplo: Listar os dez primeiros caracteres dos ttulos dos livros: SELECT SUBSTRING(TITULO, 1, 10) AS TRECHO FROM LIVRO

215

LENGTH retorna o comprimento da cadeia de caracteres que recebe como parmetro. Retornar nulo, caso receba NULL como parmetro. Exemplo: SELECT LENGTH(TITULO) AS COMPRIMENTO FROM LIVRO WHERE ASSUNTO = R Datas A formatao de campos relacionados a datas e horrios uma das que apresenta o maior nmero de variaes entre as implementaes dos SGBDs padres para SQL. Dentre as funes mais utilizadas, temos as funes DAY, MONTH e YEAR. Estas funes recebem uma data como parmetro e retornam o dia, o ms e o ano da data, respectivamente. Exemplo: Selecionar o dia da publicao do livro de cdigo 1 SELECT DAY(LANCAMENTO) AS DIAS FROM LIVRO WHERE CODIGO = 1 Selecionar o ms e o ano da publicao dos livros cujo assunto R: SELECT MONTH(LANCAMENTO) AS MS, YEAR(LANCAMENTO) AS ANO FROM LIVRO WHERE ASSUNTO = R Nmeros A linguagem SQL e os SGBDs oferecem vrias funes predefinidas para a manipulao de nmeros. Na tabela 5.1 so apresentadas as principais funes matemticas definidas pela SQL. A maioria das funes da tabela 5.1 recebe apenas um parmetro de entrada numrico e retorna um nmero.

Tambm so comuns implementaes de funes trigonomtricas para a SQL. Dentre as principais funes trigonomtricas, temos as apresentadas na tabela 5.2:

216

A utilizao das funes algbricas e trigonomtricas apresentadas semelhante das funes de cadeias de caracteres apresentadas anteriormente. Veja o exemplo para a funo CEIL: SELECT CEIL(PRECO) FROM LIVRO WHERE CODIGO = 3 Eliminando repeties Quando utilizamos consultas sobre tabelas, podemos obter linhas repetidas. Para eliminar repeties, em relaes resultantes de consultas, foi definido o predicado DISTINCT. Este predicado poder ser utilizado isoladamente na clusula SELECT ou em conjunto com outras funes SQL. Para eliminar resultados distintos de uma consulta, basta posicionar o predicado DISTINCT aps a clusula SELECT e antes da especificao das colunas a serem recuperados. Vejamos um exemplo: recuperar os assuntos distintos da tabela de livros: SELECT DISTINCT ASUNTO AS ASSUNTO FROM LIVRO O predicado DISTINCT pode ainda ser utilizado com a funo COUNT, quando posicionado junto ao seu parmetro de entrada. Neste caso, possvel contar os valores distintos de uma coluna, por exemplo. SELECT COUNT(DISTINCT ASSUNTO) FROM LIVRO Ordenando os resultados Ao realizarmos consultas SQL no sabemos, a priori, quais e em que ordem as linhas do resultado sero apresentadas. No entanto, muitas vezes, desejamos obter os resultados ordenados por uma ou mais colunas. Para isso, devemos utilizar a clusula ORDER BY. A clusula ORDER BY sempre posicionada como a ltima de um comando SELECT. Vejamos um exemplo de sintaxe: SELECT COL1, COL2, ..., COLN FROM NOME_TABELA WHERE CONDICAO GROUP BY COL1, COL2, ..., COLN HAVING EXPRESSAO_LOGICA ORDER BY COL1 [DESC,ASC], COL2 [DESC, ASC] Consulta: Gerar a listagem dos livros contendo assunto, ttulo, e preo. A listagem dever estar ordenada em ordem crescente de assunto e decrescente de preo. SELECT ASSUNTO, TITULO, PRECO 217

FROM LIVRO ORDER BY ASSUNTO, PRECO DESC Gerar listagem dos livros contendo assunto, ttulo e preo. A listagem dever estar ordenada em ordem crescente de ttulo e descente de preo. SELECT ASSUNTO, TITULO, PRECO FROM LIVRO ORDER BY 2, PRECO DESC A SQL:2003 nos permite, ainda, utilizar funes, como SUBSTRING, na clusula ORDER BY.

218

Junes Nos comandos apresentados anteriormente, somente uma tabela era acessada por vez. Entretanto, muitas vezes precisamos acessar informaes de mais de uma tabela em uma mesma consulta. Para acessar mais de uma tabela em um mesmo comando SELECT, devemos realizar operaes chamadas junes. Existem vrios tipos de juntos, como a interna, a externa e a natural. As diferenas entre as junes se do na forma como as tabelas da consulta so combinadas para a montagem dos resultados. Para coletar informaes de mais de uma tabela, realizamos junes. As junes so ligaes entre tabelas, realizadas atravs dos valores de uma ou mais colunas. Usualmente, essas ligaes ocorrem entre a chaveprimria de uma tabela e a chave estrangeira de outra. No caso de nosso exemplo, temos que a coluna ASSUNTO da tabela LIVRO a chave estrangeira para a coluna SIGLA, chave-primria da tabela ASSUNTO. Assim, neste caso, a ligao entre as informaes de uma tabela com a outra se dar atravs das colunas ASSUNTO e SIGLA. A juno entre tabelas faz com que seja gerada uma relao resultante contendo todas as colunas das tabelas originais. Para a juno entre as tabelas anteriores ser gerada uma relao contendo as colunas CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA, SIGLA e DESCRICAO. Essa relao ser gerada somente para a execuo da consulta e sobre ela podero ser aplicadas as operaes apresentadas anteriormente. As linhas que participaro da relao resultante sero escolhidos com base no tipo de juno que est sendo realizada e com o predicado de juno. Juno Interna A juno interna entre tabelas a modalidade de juno que faz com que somente participarem da relao resultante as linhas das tabelas de origem que atenderem clusula de juno. A sintaxe bsica para a realizao da juno interna : SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON FROM NOME_TABELA INNER JOIN NOME_TABELA2 ON NOME_TABELA.COL1 = NOME_TABELA2.COL1 WHERE CONDICAO GROUP BY COL1, COL2, ..., COLN HAVING EXPRESSAO_LOGICA ORDER BY COL1, COL2, , COLN Por exemplo: Quais os ttulos dos livros j lanados e a descrio dos seus assuntos? SELECT TITULO, DESCRICAO FROM LIVRO INNER JOIN ASSUNTO ON SIGLA = ASSUNTO WHERE LANCAMENTO IS NOT NULL No exemplo anterior, nem todas as linhas da tabela ASSUNTO (cuja instncia est representada na tabela 3.2) fazem parte do resultado da consulta. Isto ocorre porque estamos utilizando uma juno interna, onde somente participam do resultado as linhas nas quais os valores das colunas de juno possuem correspondente em ambas as tabelas. As junes externas, apresentadas a seguir, permitiro que linhas onde no existam valores correspondentes em ambas as tabelas participam. Os primeiros SGBDs possuram a clusula INNER JOIN. Mas as junes internas j eram utilizadas. Para tal, as tabelas eram listadas na clusula FROM, separadas por virgulas, e as condies de juno eram descritas na

219

clusula WHERE. Nesta construo, as condies de juno so listadas juntamente com as condies de seleo. Veja o exemplo da juno interna sem a clusula INNER JOIN: SELECT TITULO, DESCRICAO FROM LIVRO, ASSUNTO WHERE ASSUNTO = SIGLA AND LANCAMENTO IS NOT NULL Em consultas complexas formuladas dessa forma, comum que alguma importante condio seja esquecida. Embora bastante difundidas, aconselhvel que construes deste tipo sejam substitudas pela sintaxe contendo a clusula INNER JOIN. Suponha que, agora, busquemos gerar uma listagem contendo o ttulo do livro, o nome da editora que o publicou e a descrio do assunto de que trata. Para isso, teremos que utilizar o acesso a trs tabelas. Por exemplo: SELECT TITULO, NOME, DESCRICAO FROM LIVRO INNER JOIN EDITORA E ON EDITORA = E.CONTEUDO INNER JOIN ASSUNTO ON ASSUNTO = SIGLA Em consultas onde ocorrem junes, todas as clusulas apresentadas anteriormente como (WHERE, GROUP BY, HAVING e ORDER BY) continuam vlidas. Por exemplo: Montar a listagem das editoras e dos ttulos dos livros que lanaram, ordenada pelo nome da editora e, em seguida, pelo ttulo do livro. Apresentar somente os livros j lanados. Consulta: SELECT NOME, TITULO FROM EDITORA E INNER JOIN LIVRO ON EDITORA = E.CODIGO WHERE LANCAMENTO IS NOT NULL ORDER BY NOME, TITULO Junes Externas Nas consultas onde se realizam junes internas, somente participam dos resultados as linhas cujas colunas de juno possuem os mesmos valores em ambas as tabelas participantes da juno. Nesta seo, sero apresentadas trs formas de executar a juno externa, modalidade de juno onde a no inexistncia de valores correspondentes no limita a participao de linhas no resultado de uma consulta. Juno externa esquerda Suponha que desejamos obter uma listagem de todas as editoras cadastradas em nosso banco de dados e, para aquelas que possuam livros publicados, o nome dos mesmos. Vamos ter que utilizar uma juno externa. Eis a sintaxe da juno externa esquerda: SELECT COL1, COL2, ..., COLN, FUNCAO1, FUNCAO2 FROM NOME_TABELA LEFT OUTER JOIN NOME_TABELA2 ON NOME_TABELA.COL1 = NOME_TABELA2. COL1 WHERE CONDICAO GROUP BY COL1, COL2, ..., COLN HAVING EXPRESSAO_LOGICA 220

ORDER BY COL1, COL2, , COLN A nica diferena para sintaxe da juno interna a substituio do termo INNER JOIN pelo termo LEFT OUTER JOIN, indicador da juno externa esquerda. Em uma juno externa esquerda, a juno ocorre de forma que todas as linhas pertencentes tabela posicionada esquerda do termo LEFT OUTER JOIN no comando e que atendem aos critrios definidos na clusula WHERE faro parte do resultado, independente se existem valores correspondentes na coluna de juno da tabela posicionada direita do comando. Caso no existam valores correspondentes na tabela direita, as colunas selecionadas desta tabela, nas linhas onde no existe correspondncia, tero valor NULL. Montando a listagem de todas as editoras cadastradas em nossa base de dados e, para aquelas que possuam livros publicados, relacionar, tambm, o ttulo dos mesmos. Vamos ordenar os resultados pelo nome da editora e pelo ttulo do livro. SELECT NOME, TITULO FROM EDITORA E LEFT OUTER JOIN LIVRO ON EDITORA = E.CODIGO ORDER BY NOME, TITULO Outro exemplo: Mostrar a listagem completa de assuntos contendo, tambm, os ttulos dos livros e seus respectivos assuntos. Resultados ordenados pela descrio do assunto. Consulta: SELECT DESCRICAO, TITULO FROM ASSUNTO LEFT OUTER JOIN LIVRO ON SIGLA = ASSUNTO ORDER BY DESCRICAO Juno externa Direita A juno externa direita extremamente parecida com a juno externa esquerda. A nica diferena consta no fato de que a tabela da qual todas as linhas constaro do resultado est posicionada direita do termo RIGHT OUTER JOIN no comando. Sua sintaxe : SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON FROM NOME_TABELA RIGHT OUTER JOIN NOME_TABELA2 ON NOME_TABELA.COL1 = NOME_TABELA2.COL1 WHERE CONDICAO GROUP BY COL1, COL2, ..., COLN HAVING EXPRESSAO_LOGICA ORDER BY COL1, COL2, , COLN Onde, a nica diferena em termos de sintaxe para a juno externa esquerda a substituio do termo LEFT OUTER JOIN pelo termo RIGHT OUTER JOIN, indicador da juno externa direita. Se reescrevermos a consulta do exemplo anterior de forma a obtermos o mesmo resultado e com a utilizao da juno externa direita, teremos a seguinte consulta: SELECT DESCRICAO, TITULO FROM LIVRO RIGHT OUTER JOIN ASSUNTO ON SIGLA = ASSUNTO 221

ORDER BY DESCRICAO Note que para que as consultas sejam equivalentes, temos que inverter a ordem das tabelas na clusula FROM. Juno Externa Completa Podemos ainda querer montar as listagem de todas as linhas das tabelas participantes que atendam aos critrios de seleo especificados na clusula WHERE participem do resultado, independente da correspondncia de valores da clusula de juno. A clusula de juno atua de forma a montar a relao quando existir correspondncia entre valores. Quando no existir, as colunas da tabela onde inexiste o valor devem apresentar o valor nulo. Esta a juno externa completa. A diferena da juno externa para as junes direita e esquerda se d no fato de que, naquelas, uma das tabelas somente apresentava os valores com correspondncia outra, a qual apresentava todos os seus valores. Na juno externa completa, as duas tabelas podero apresentar valores sem correspondentes. A sintaxe : SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON FROM NOME_TABELA FULL OUTER JOIN NOME_TABELA2 ON NOME_TABELA.COL1 = NOME_TABELA2.COL1 WHERE CONDICAO GROUP BY COL1, COL2, ..., COLN HAVING EXPRESSAO_LOGICA ORDER BY COL1, COL2, , COLN Onde a nica diferena para a sintaxe da juno externa esquerda a substituio do termo FULL OUTER JOIN, em detrimento de LEFT OUTER JOIN e RIGHT OUTER JOIN, respectivamente. Consideremos agora, a tabela de editoras, cujo exemplo apresentado na tabela 2.6, e a tabela de livros, onde foram adicionados mais livros, ainda sem data prevista para o lanamento, sem editora definida e sem preo. A nossa nova tabela de livros apresentada na tabela 6.1. Vejamos, ento um exemplo para a realizao da juno externa completa.

Listagem com a exibio de todos os ttulos e de todas as editoras, relacionando a obra com a editora que a publica, quando caso. A listagem dever estar ordenada pelo ttulo da obra. Consulta: SELECT TITULO, NOME FROM LIVRO FULL OUTER JOIN EDITORA ON EDITORA.CODIGO = EDITORA ORDER BY TITULO Juno Cruzada 222

Algumas vezes queremos gerar todas as combinaes possveis entre elementos de duas tabelas. uma operao idntica a um produto cartesiano dos elementos das tabelas. Para isso, podemos utilizar um tipo de juno conhecida como CROSS JOIN. Sua sintaxe : SELECT COL1, COL2, ..., COLN, FUNCAO1, , FUNCAON FROM NOME_TABELA CROSS JOIN NOME_TABELA2 WHERE CONDICAO GROUP BY COL1, COL2, , COLN HAVING EXPRESSAO_LOGICA ORDER BY COL1, COL2, , COLN Suponha um torneio onde selees so divididas em dois grupos, A e B, e onde todos os membros do grupo A jogam contra todos os membros do grupo B. A tabela 6.2 representa as selees do Grupo A, euqunato a tabela 6.3, as do grupo B.

Consulta: SELECT A.NOME AS TIME_A, B.NOME AS TIME_B FROM GRUPO_A A CROSS JOIN GRUPO_B B Resultado:

Juno Natural e Baseada em Nomes de Colunas Anteriormente foram apresentadas as junes internas e externas. Agora vamos verificar a juno natural e a juno baseada em nomes de colunas. Ambas so construes que podem ser aplicadas em conjunto com as modalidades apresentadas anteriromente para substituir a utilizao da clusula ON.

223

Na verdade, como, em alguns casos, as tabelas sobre as quais queremos realizar a juno apresentam colunas de mesmo nome e para que, nesses asos, no seja necessrio explicitar o nome das colunas, definida a juno natural. Nesta modalidade de juno, todas as colunas de mesmo nome nas tabelas em questo participam da condio de juno. Para utilizar a juno natural, basta incluir a palavra reservada NATURAL antes das palavras INNER, LEFT, OUTER ou FULL, de acordo com a situao. Ento, no ser necessrio utilizar a clusula ON. Entretanto, realizar automaticamente a juno por todas as colunas de mesmo nome pode ser um problema. Frequentemente encontramos tabelas com colunas de nomes intituladas nome e descrio. No entanto, no comum realizar junes por tais colunas. Para solucionar essa questo, foi elaborada a juno baseada em nomes de colunas. Assim, como no caso da juno natural, neste caso, as colunas de mesmo nome nas diferentes tabelas sero utilizadas para a juno. Entretanto, agora, as colunas no sero utilizadas automaticamente. Ser necessrio especificar quais colunas sero utilizadas. A sintaxe da juno baseada em nomes de coluna : SELECT COL1, COL2, ..., COLN FROM NOME_TABELA [INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER] JOIN NAME_TABELA2 USING [NOME_COLUNA] A principal diferena entre a juno natural e a baseada em nomes de colunas se d no fato de que, na juno natural, todas as colunas de mesmo nome nas tabelas sero utilizadas para realizar a juno, enquanto a juno baseada em nomes de colunas, somente sero utilizadas as colunas que forem listadas. Formatando a Sada e as junes externas Quando utilizamos as funes externas, podemos obter vrios valores nulos em uma ou mais coluna do resultado. A funo COALESCE nos permite substituir os valores nulos por outros que desejamos. Ela recebe uma lista de parmetros e retorna o primeiro que possuir um valor no-nulo. Frequentemente, exigido que todos os parmetros sejam do mesmo tipo de dados. Por exemplo: Obter uma listagem com a descrio de todos os assuntos e os ttulos dos livros de cada um. Quando no existir um assunto associado, deve ser escrita a frase SEM PUBLICAES. Consulta: SELECT DESCRICAO, COALESCE(TITULO, SEM PUBLICAES) AS TITULO FROM ASSUNTO LEFT OUTER JOIN LIVRO ON SIGLA = ASSUNTO ORDER BY DESCRICAO

224

Combinando Comandos Todos os commandos de consulta da linguagem SQL atuam sobre uma relao, que pode ou no estar materializada em formato de uma tabela. O resultado dos comandos de seleo tambm uma relao. Tanto as relaes de entrada quanto as relaes de sada podem possuir diversos nmeros de colunas e linhas. Este tipo de construo permite que utilizemos consultas embutidas na clusula FROM de uma consulta, fazendo com que a sada de um comando SELECT seja utilizada como entrada para outro comando SELECT. Outras formas de combinarmos os dois ou mais comandos SELECT para obter um nico resultado final so subconsultas da clusula WHERE, correlacionadas ou no, e as operaes baseadas nas operaes de conjunto. Subconsultas da clusula WHERE A utilizao de subconsultas na clusula WHERE uma das formas de combinao de duas ou mais consultas para um nico resultado final. Nestas construes, o resultado da subconsulta no apresentado ao usurio, sendo construdo de forma temporria pelo SGBD, o qual utiliza os resultados temporrios em testes das consultas mais externas. Existem dois tipos de subconsultas: correlacionadas e no-correlacionadas. Subconsultas no-correlacionadas Com a utilizao do predicado IN era possvel comparar o valor de uma coluna com uma lista de valores. Na subconsulta no-correlacionada, substitumos a lista de valores do predicado IN por uma consulta. A sintaxe bsica do comando para utilizao da subconsulta no-correlacionada : SELECT COL1, COL2, ..., COLN FROM NOME_TABELA WHERE COLM [NOT] IN (SELECT COLX FROM NOME_TABELA2) Note que, esquerda do predicado [NOT] IN continua posicionada uma coluna (a utilizao do operador NOT opcional). A consulta interna ao predicado IN (aquela que substitui a lista de valores), no tem nenhuma ligao com a consulta externa. Ambas as consultas podero possuir todas as construes apresentadas anteriormente, sem nenhuma restrio adicional devido presena da subconsulta. A consulta interna dever, no entanto, retornar uma coluna apenas. Exemplos: Considerando a base de dados de publicaes composta pelas tabelas ASSUNTO, LIVRO e EDITORA, conforme anteriormente. Desejamos saber os nomes das editoras que possuem livros j lanados. Consulta: SELECT NOME FROM EDITORA WHERE CODIGO IN ( SELECT EDITORA FROM LIVRO WHERE LANCAMENTO IS NOT NULL) Neste exemplo, a subconsulta gera uma relao temporria de uma nica coluna (no exibida ao usurio em nenhum momento) contendo os cdigos de editoras que publicaram livros que j foram lanados. A consulta externa procurar por nomes de editoras para as quais o cdigo consta na relao produzida para subconsulta. Desejamos saber quais assuntos no foram lanados livros. SELECT DESCRICAO FROM ASSUNTO WHERE SIGLA NOT IN (SELECT ASSUNTO FROM LIVRO WHERE LANCAMENTO IS NOT NULL) Neste exemplo, a subconsulta gera uma listagem de assuntos dos livros que j foram lanados. A consulta externa procurar, na tabela de assuntos, quais assuntos no constam na listagem gerada pela subconsulta.

225

Tambm podemos utilizar subconsultas combinadas com operaes de atualizao e excluso de dados. Por exemplo: Desejamos excluir as editoras que no publicaram os livros. O comando para tal operao : DELETE FROM EDITORA WHERE CODIGO NOT IN (SELECT EDITORA FROM LIVRO) Subconsultas Correlacionadas possivel utilizar o predicado IN em conjunto com um commando SQL em uma construo chamada de nocorrelacionada. Agora, veremos outro tipo de construo, chamado de subconsulta no-correlacionada. Agora, veremos outro tipo de construo, chamada de subconsulta correlacionada, pois, neste caso, a subconsulta possui dependncia direta da consulta externa. Na subconsulta correlacionada utilizaremos o predicado EXISTS. O predicado IN permitia testar se valores de uma coluna constavam em uma listagem de valores. O predicado EXISTS testa se uma condio verdadeira ou falsa. Vejamos exemplo da sintaxe para sua utilizao: SELECT COL1, COL2, ..., COLN FROM NOME_TABELA TAB_EXTERNA WHERE [NOT] EXISTS (SELECT COLX FROM NOME_TABELA2 TAB_EXTERNA WHERE TAB_EXTERNA.COLA = TAB_INTERNA.COLA) Na subconsulta do exemplo anterior, existe uma comparao entre uma coluna da tabela externa com uma coluna da tabela interna (em negrito). Este tipo de teste possvel em subconsultas, onde a consulta mais interna poder acessar uma coluna da coluna mais externa, usualmente utilizando o apelido (ou correlation name) da tabela mencionada da coluna mais externa, usualmente utilizando o apelido da tabela mencionada da consulta mais externa. Esse comando comea a ser executado pela consulta mais externa. Ento, para cada linha de NOME_TABELA, a subconsulta ser executada, substituindo-se o valor de TAB_EXTERNA.COLA por seu valor na linha em questo. Se a subconsulta retornar algum valor a clusula EXISTS ser verdadeira e a linha recuperada na consulta mais externa far parte do resultado final. Em caso contrrio, a consulta mais externa realiza o teste para a prxima linha de TAB_EXTERNA.COLA. Note que, na utilizao do predicado EXISTS, no posicionada nenhuma coluna esquerda do mesmo, pois ele no compara valores, e, sim, testa uma condio booleana. Assim, a coluna posicionada na clusula SELECT da subconsulta no influenciar no resultado do comando. Devido existncia, na subconsulta, da utilizao de uma coluna da consulta mais externa em uma comparao, esta construo chamada de consulta correlacionada. Vejamos os exemplos anteriores reescritos para o formato de subconsultas correlacionadas: Desejamos saber os nomes das editoras que possuem livros lanados. SELECT NOME FROM EDITORA ED WHERE EXISTS (SELECT EDITORA FROM LIVRO WHERE LANCAMENTO IS NOT NULL AND ED.CODIGO = EDITORA) Desejamos saber sobre quais assuntos nao foram lanados livros. SELECT DESCRICAO FROM ASSUNTO ASS WHERE NOT EXISTS (SELECT ASSUNTO 226

FROM LIVRO WHERE LANCAMENTO IS NOT NULL AND ASS.SIGLA = ASSUNTO) Assim como no caso do predicado IN, poderemos utilizar EXISTS em commandos de atualizao e excluso de dados. Vejamos a reescrita do comando para excluso das editoras que no possuem livros associados, com a utilizao de EXISTS: DELETE FROM EDITORA E WHERE NOT EXISTS ( SELECT 1 FROM LIVRO WHERE EDITORA = E.CODIGO) Subconsultas substituindo valores Em uma consulta, para cada linha da relao resultante temos, em uma dada coluna, uma pequena relao de uma linha e uma coluna que pode ser substituda por um comando SELECT que retorne apenas uma linha e uma coluna. Tal comando SELECT pode ser formador tanto de uma consulta correlacionada quanto de uma consulta no-correlacionada. Considere que desejamos montar uma relao que contenha em uma coluna a descrio dos assuntos existentes e, em outra, a quantidade de livros lanados de cada assunto. Para obter a coluna ASSUNTOS basta realizar uma seleo sobre a coluna DESCRIO da tabela de assuntos e utilizar o apelido ASSUNTOS para a coluna. Para obter a coluna LIVROS_LANCADOS devemos contar, para cada assunto, quantos livros j lanados existem na tabela de livros do assunto em questo. O comando que monta o resultado anterior o seguinte: SELECT DESCRICAO AS ASSUNTOS, (SELECT COUNT(*) FROM LIVRO L WHERE L.ASSUNTO = A.SIGLA AND LANCAMENTO IS NOT NULL ) AS LIVROS_LANCADOS FROM ASSUNTO A Note que, no comando anterior, foi utilizada uma subconsulta correlacionada substituindo um valor em um comando SELECT e, para a qual, foi dado um apelido (LIVROS_LANCADOS). A subconsulta utilizada possui somente uma coluna onde foi usada a funo COUNT que retorna somente uma linha, de forma a atender ao requisito apresentado anteriormente. Como a correlao desta com a tabela externa (L.ASSUNTO = A.SIGLA) faz com que a contagem de livros seja feita para o assunto adequado. Outro exemplo: Listar o nome das editoras e o preo mdio das publicaes de cada uma. SELECT NOME, (SELECT AVG(PRECO) FROM LIVRO V WHERE V.EDITORA = E.CODIGO AND LANCAMENTO IS NOT NULL) AS PRECO_MEDIO FROM EDITORA E ORDER BY NOME Poderemos utilizar subconsultas que retornem uma relao de uma linha e uma coluna em vrios comandos e locais como, por exemplo, substituindo o valor no comando UPDATE TABELA SET COLUNA = VALOR.

227

Tabelas aninhadas Uma tabela a materializao de uma relao. Quando realizamos uma consulta e posicionamos uma tabela na clusula FROM, estamos fazendo uma consulta sobre uma relao. Logo, podemos substituir uma tabela por uma subconsulta que retorne uma relao. A esta construo chamamos de tabelas aninhadas. Para utilizarmos o resultado de uma consulta como uma tabela, devemos posicionar a consulta delimitada por parnteses em local destinado a uma tabela. Para que possamos acessar as colunas do resultado da subconsulta como se acessssemos as colunas de uma tabela, pode ser necessrio atribuir um apelido para a subconsulta. Vejamos um exemplo de sintaxe para a juno entre uma tabela aninhada e uma tabela: SELECT COL1, COL2, COLN, COLX, COLY, COLZ FROM (SELECT COLX, COLY, COLZ FROM TAB_INTERNA) TAB_CONSULTA INNER JOIN TAB_EXTERNA ON TAB_CONSULTA.COLX = TAB_EXTERNA.COL1 Notamos que a expresso TAB_CONSULTA.COLX representa o acesso coluna COLX do resultado da subconsulta. Qualquer coluna da tabela aninhada poder ser acessada como uma coluna de uma tabela. Listar o nome das editoras e as publicaes das editoras que lanaram ao menos dois livros, ordenados por nome da editora e pelo ttulo da publicao. SELECT NOME, TITULO FROM (SELECT EDITORA, COUNT(*) AS QUANTIDADE FROM LIVRO V WHERE LANCAMENTO IS NOT NULL GROUP BY EDITORA) EDITORA_QUANT INNER JOIN LIVRO ON EDITORA_QUANT.EDITORA = LIVRO.EDITORA INNER JOIN EDITORA ON EDITORA_QUANT.EDITORA = EDITORA.CODIGO WHERE QUANTIDADE >= 2 ORDER BY NOME Essa relao, que no exibida ao usurio, utilizada exatamente como uma tabela e referenciada pelo nome EDITORA_QUANT. Listar os ttulos dos livros dos assuntos para os quais o preo mdio das publicaes superior a R$ 40,00, juntamente com os respectivos assuntos. SELECT TITULO, DESCRICAO AS ASSUNTO FROM ( SELECT ASSUNTO, AVG(PRECO) AS PRECO_MEDIO FROM LIVRO V GROUP BY SIGLA HAVING AVG(PRECO) > 40) ASSUNTO_PRECO INNER JOIN LIVRO ON ASSUNTO_PRECO.ASSUNTO = LIVRO.ASSUNTO INNNER JOIN ASSUNTO ON ASSUNTO_PRECO.ASSUNTO = ASSUNTO.SIGLA Operaes de Conjunto Podemos realizar as operaes tradicionais sobre conjuntos: unio, interseo, e diferena. Unio 228

Quando realizamos junes entre tabelas, formamos uma relao resultante com as colunas que contm as colunas das tabelas originais. Por outro lado, podemos querer realizar um comando SQL que apresente, como resultado, todas as linhas que foram recuperadas por outros dois comandos SQL realizados em separado. Para unir as linhas resultantes de duas ou mais consultas, utilizamos o predicado UNION. O predicado UNION utilizado posicionado entre dois comandos de consulta, da seguinte forma: SELECT COL1, COL2 FROM TABELA1 UNION [ALL] SELECT COL3, COL4 FROM TABELA2 Observamos que os comandos podero acessar tabelas diferentes e utilizar as mais diversas construes da linguagem. Existem, somente, duas regras para utilizao do UNION: (i) os comandos devem retornar o mesmo nmero de colunas e (ii) as colunas correspondentes em cada comando devem possuir os mesmo tipos de dados. O UNION ir atuar fazendo com que o resultado das consultas participante seja combinado com o resultado final. Quando utilizamos o UNION isoladamente, no resultado final no constaro linhas repetidas. Se desejarmos que linhas repetidas apaream, devemos utilizar o predicado ALL logo aps UNION, conforme mostrado antes. * Listar os ttulos dos livros que cujo assunto Banco de Dados ou que foram lanados por editoras que contenham Mirandela no nome. SELECT TITULO FROM LIVRO INNER JOIN ASSUNTO ON ASSUNTO = SIGLA WHERE DESCRICAO = BANCO DE DADOS UNION [ALL] SELECT TITULO FROM LIVRO INNER JOIN EDITORA E ON EDITORA = E.CODIGO WHERE NOME LIKE %MIRANDELA% Interseo Para obtermos a interseo entre os resultados do comando SELECT, utilizamos o comando INTERSECT. O INTERSECT utilizado da mesma forma que o UNION, posicionado entre dois comandos SELECT, e atende s mesmas regras: (i) os comandos devem retornar o mesmo nmero de colunas e (ii) as colunas correspondentes em cada comando devem possuir os mesmos tipos de dados. Ento, o INTERSECT retornar as linhas que estejam presente nos resultados de todas as consultas participantes. Da mesma forma que o UNION, o INTERSECT utilizado isoladamente eliminar as linhas repetidas. Para que as linhas repetidas constem no resultado final, o predicado ALL deve ser utilizado. Listar os ttulos dos livros cujo assunto Programao e que foram lanados por uma editora que contenha a palavra Mirandela no nome, sem repeties. SELECT TITULO FROM LIVRO INNER JOIN ASSUNTO ON ASSUNTO = SIGLA WHERE DESCRICAO = PROGRAMACAO INTERSECT SELECT TITULO FROM LIVRO 229

INNER JOIN EDITORA E ON EDITORA = E.CODIGO WHERE NOME LIKE %MIRANDELA% Diferena Tambm possvel realizar a diferena entre os resultados de comandos SELECT. Neste caso, o predicado utilizado o EXCEPT. O EXCEPT ser utilizado da mesma forma que o UNION e o INTERSECT (entre os comandos SELECT). Estar sujeito s mesmas duas regras apresentadas nos casos anteriores sobre o nmero de colunas e os tipos de dados das mesmas. Isoladamente, ele no permite linhas repetidas no resultado final. Da mesma forma que o UNION e o INTERSECT, ele pode ser utilizado em conjunto com o predicado ALL. Exemplo: Listar os ttulos dos livros cujo assunto Banco de Dados e que no foram lanados por uma editora que contenha a palavra Mirandela no nome. SELECT TITULO FROM LIVRO INNER JOIN ASSUNTO ON ASSUNTO = SIGLA WHERE DESCRICAO = BANCO DE DADOS EXCEPT SELECT TITULO FROM LIVRO INNER JOIN EDITORA E ON EDITORA = E.CODIGO WHERE NOME LIKE MIRANDELA Como o EXCEPT realiza a diferena entre conjuntos, a ordem de declarao das consultas com relao ao predicado EXCEPT altera o resultado final, diferentemente do que acontece com os predicados UNION e INTERSECT. Listar o ttulo dos livros que foram lanados por editora que contenham a palavra Mirandela em seu nome e cujo assunto no Banco de Dados. SELECT TITULO FROM LIVRO INNER JOIN EDITORA E ON EDITORA = E.CODIGO WHERE NOME LIKE %MIRANDELA% EXCEPT SELECT TITULO FROM LIVRO INNER JOIN ASSUNTO ON ASSUNTO = SIGLA WHERE DESCRICAO = BANCO DE DADOS Comandos e Estruturas Avanadas A seguir sero apresentadas construes da SQL:2003 que permitem a realizao de consultas bastante poderosas, como as consultas recursivas, ou de grande utilidade, como o predicado CASE e os comandos para criao e excluso de vises. Tambm apresentado o comando MERGE, para incluso e atualizao de informaes em tabelas. Vises e Vises Temporrias 230

Muitas vezes gostaramos de utilizar os dados contidos em nosso banco de dados como se estivessem em um formato diferente daquele em que realmente esto. Consideremos uma situao em que queremos constantemente queremos consultar o ttulo de um livro, seu preo, o nome da editora que o publica e a descrio do assunto do livro. Estas informaes esto contidas em nosso banco de dados, mas espalhada em trs tabelas. Para uni-las devemos realizar o comando SELECT com junes entre as tabelas. Entretanto, como a consulta realizada constantemente, gostaramos de ter uma diferente viso de nosso banco de dados: gostaramos de ter uma viso onde as informaes j aparecessem unidas. A linguagem SQL nos permite isso atravs da criao de um objeto chamado viso. Vises so tabelas artificiais cujo contedo provm de tabelas reais. Os dados que as compem so definidos atravs de comandos SELECT realizados sobre tabelas dos bancos de dados. Na verdade, os dados continuam armazenados na tabela original. Cada vez que realizamos uma consulta sobre a viso, o SGBD se encarrega de coletar os dados nas tabelas de origem, a partir do comando SELECT que definem a viso como se ela fosse uma tabela. Para criamos vises, utilizamos o comando CREATE VIEW, cuja estrutura bsica apresentada a seguir. CREATE VIEW NOME_VISO AS COMANDO DE CONSULTA Vejamos, a seguir o comando para criao da viso que contm o ttulo dos livros, seus preos, o nome da editora que os publica e a descrio de seus assuntos. CREATE VIEW LIVRO_EDITORA_ASSUNTO AS SELECT TITULO, PRECO, NOME AS EDITORA, DESCRICAO AS ASSUNTO FROM LIVRO INNER JOIN EDITORA ED ON EDITORA = ED.CODIGO INNER JOIN ASSUNTO ON ASSUNTO.SIGLA = LIVRO.ASSUNTO Agora, poderemos consultar a viso como se consultssemos uma tabela de nosso banco de dados. Como exemplo, vamos apresentar o comando para obtermos o ttulo, o nome da editora, e a descrio do assunto dos livros que possuem preo superior a R$ 45,00. Queremos a listagem ordenada por ttulo do livro. SELECT TITULO, EDITORA, ASSUNTO FROM LIVRO_EDITORA_ASSUNTO WHERE PRECO > 45 ORDER BY TITULO A definio de uma viso permanece no banco de dados, de forma que a viso pode ser acessada a qualquer momento. Para apagarmos uma viso, utilizamos o comando DROP VIEW, seguido do nome da viso. A seguir, como exemplo, temos o comando para excluso da viso LIVRO_EDITORA_ASSUNTO DROP VIEW LIVRO_EDITORA_ASSUNTO Na excluso da viso, somente sua definio excluda. Os dados permanecem nas tabelas originais. Por outro lado, podemos querer criar uma viso para ser utilizada em um comando somente, sem que sua definio fique armazenada no banco de dados. Para isto, utilizamos o comando WITH. Uma estrutura simples para o comando WITH apresentada a seguir. WITH NOME_VISO_TEMPORRIA [(NOME_COLUNAS_VISO)] AS (COMANDO_DEFINIO_VISO) COMANDO_DE_CONSULTA 231

Vamos, agora, como exemplo, utilizar o mesmo comando que colocou a viso LIVRO_EDITORA_ASSUNTO na definio de uma viso temporria. Usaremos, tambm, a mesma consulta sobre esta viso que utilizamos anteriormente. WITH CONSULTA_EDITORA_ASSUNTO AS ( SELECT TITULO, PRECO, NOME AS EDITORA, DESCRICAO AS ASSUNTO FROM LIVRO INNER JOIN EDITORA ED ON EDITORA = ED.CODIGO INNER JOIN ASSUNTO ON ASSUNTO.SIGLA = LIVRO.ASSUNTO) SELECT TITULO, EDITORA, ASSUNTO FROM LIVRO_EDITORA_ASSUNTO WHERE PRECO > 45 ORDER BY TITULO Consultas recursivas A incluso de consultas na linguagem SQL permitiu a realizao de comandos que antes deveriam ser realizados somente atravs da utilizao de linguagens de programao. Vamos considerar um frum de mensagens na Intenet. Neste frum, o usurio pode enviar uma mensagem ou responder a outra enviada anteriormente. O usurio pode, inclusive, responder a uma resposta anterior. Um exemplo dessa estrutura apresentado na figura 8.1. Notamos que essa estrutura pode ser visualizada em formato de rvore. Em termos de modelagem, consideremos que a mensagem seja representada por um auto-relacionamento, conforme a figura 8.2. Todas as mensagens podero estar contidas em uma nica tabela do banco de dados, da qual temos um exemplo na tabela 8.1. Nesta tabela, a coluna ID_MENSAGEM chave primria, identificando univocamente cada mensagem da tabela. A coluna ASSUNTO representa o assunto da mensagem. No caso de uma mensagem estar respondendo outra, na coluna ID_MENSAGEMPAI estar contido o identificador da mensagem que est sendo respondida. Em caso contrrio, esta coluna estar vazia.

232

Se desejarmos obter quais as respostas para a mensagem de nmero 1, basta realizarmos uma consulta procurando as linhas onde a coluna ID_MENSAGEMPAI possui o valor 1. Entretanto, podemos querer obter todas as mensagens originadas a partir da pergunta de mensagem de nmero 1, ou seja, todas aquelas que esto diretamente respondendo mensagem de nmero 1, aquelas que respondem a respostas da mensagem de nmero 1 e assim por diante. Para obter todas essas mensagens, termos que utilizar uma consulta recursiva. Consultas recursivas utilizam-se da clusula WITH combina com os comandos SELECT e UNION ALL. A construo a ser utilizada semelhante apresentada anteriormente. A principal diferena reside na construo da consulta que define a viso. Esta dever conter consultas, unidas via UNION ALL. A primeira, mais bsica, define a semente do comando, acessando a linha a partir da qual iremos querer disparar a recurso. A segunda conter uma segunda definio de tabela, ligada primeira, montando a clusula da recurso. Assim, para o exemplo anterior, onde queremos obter todas as mensagens que foram originadas a partir da mensagem de nmero 1, devemos utilizar o seguinte comando listado a seguir. WITH JA_SELECIONADO (ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI) AS (SELECT ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI FROM MENSAGEM WHERE ID_MENSAGEM = 1 UNION ALL SELECT M.ID_MENSAGEM, M.ASSUNTO, M.ID_MENSAGEM_PAI FROM JA_SELECIONADO J, MENSAGEM M WHERE J.ID_MENSAGEM = M.ID_MENSAGEM_PAI) SELECT * FROM JA_SELECIONADO Note, no comando, que utilizamos a consulta SELECT ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI FROM MENSAGEM WHERE ID_MENSAGEM = 1 233

Como semente da recurso, selecionando a primeira linha da tabela temporria J_SELECIONADO. O comando SELECT, que se une a este, acessa as tabelas MENSAGEM e J_SELECIONADO, unindo-as pela chave estrangeira e fazendo com que novas linhas sejam adicionadas viso temporria. Embora as consultas recursivas tenham sido um grande avano, elas tambm criaram um novo problema a ser tratado: o loop infinito. Assim, ao construirmos consultas recursivas, devemos estar atentos para mont-las de forma a que tenham fim. Predicado CASE Algumas vezes queremos selecionar resultados diferentes em funo de uma ou mais condies. O predicado CASE, que pode ser utilizado em conjunto com comandos SELECT, permite que realizemos tal tarefa. Existem duas diferentes construes para o predicado CASE. A construo mais simples possui o seguinte formato: CASE COLUNA WHEN VALOR THEN RESULTADO WHEN VALOR2 THEN RESULTADO2 ... [ELSE RESULTADO_ELSE] END Para os livros cujo assunto B, retornar o ttulo concatenado com a expresso -MUITO INTERESSANTE. Para aqueles cujo assunto P retornar o ttulo concatenado com a expresso -INTERESSANTE MDIO. Para os outros retornar a expressao -SEM INTERESSE concatenada com seu ttulo. Consideremos a Tabela 6.1 como a instncia para a tabela LIVRO. SELECT CASE ASSUNTO WHEN B THEN TITULO || -MUITO INTERESSANTE WHEN P THEN TITULO || -INTERESSE MDIO ELSE TITULO || -SEM INTERESSE END AS IMPORTANCIA FROM LIVRO O segundo formato da expresso CASE permite que testes envolvendo diferentes colunas, variveis e expresses sejam avaliados. Sua estrutura a seguinte: CASE WHEN EXPRESSAO_BOOLEANA THEN RESULTADO WHEN EXPRESSAO_BOOLEANA2 THEN RESULTADO2 ... [ELSE RESULTADO_ELSE] END Consideremos, novamente, o exemplo de instncia para a tabela LIVRO apresentado na tabela 6.1. Para os livros que possuem data de lanamento e o preo superior a R$ 45,00 retornar o ttulo concatenado com a expresso -LIVRO CARO. Para aqueles que no possuem data de lanamento, mas possuem editora, retornar o ttulo concatenado com a expresso - LANCAMENTO EM BREVE. Para aqueles que no possuem editora, retornar o ttulo concatenado com a expressao -LIVRO BARATO. SELECT CASE WHEN LANCAMENTO IS NOT NULL AND PRECO > 40 THEN TITULO || LIVRO CARO WHEN LANCAMENTO IS NOT NULL AND EDITORA IS NOT NULL THEN TITULO || LANCAMENTO EM BREVE 234

WHEN EDITORA IS NULL THEN TITULO || EM PREPARACAO ELSE TITULO || LIVRO BARATO END AS IMPORTANCIA FROM LIVRO CASE pode ser utilizado em consultas SELECT que tenham complexidade que desejemos. Pode, inclusive, ser utilizado na clusula WHERE. Exemplo: As vrias editoras esto estudando a aplicao de diferentes fatores a reajustes de preos. Queremos saber quais os ttulos dos livros que custaro acima de R$50,00 caso a editora VIA-NORTE aplique um reajuste de 10% nos preos de seus livros e a editora ILHAS TIJUCAS aplique um reajuste de 25%. SELECT TITULO FROM LIVRO INNER JOIN EDITORA ON EDITORA = EDITORA.CODIGO WHERE 50 < (CASE WHEN NOME= EDITORA VIA-NORTE THEN PRECO *1.1 WHEN NOME = EDITORA ILHAS TIJUCAS THEN PRECO * 1.25 ELSE PRECO END) Comando MERGE Suponhamos que tenhamos uma tabela de clientes. A descrio da tabela de clientes ser apresentada na figura 8.3. Esta tabela possui vrias linhas, sendo que, algumas delas so referentes a pessoas que tambm atuam como atores e que tambm esto cadastradas na tabela de autores.

Foi decidido que todos os autores sero cadastrados como clientes. Para os autores que j se encontram cadastrados como clientes, deveremos atualizar as informaes na tabela de clientes com base nos dados da tabela de autores. Para realizar tais operaes utilizando os comandos INSERT e UPDATE, teramos que percorrer todas as linhas da tabela de autores, verificando cada uma se o autor j est cadastrado como cliente. Caso no esteja, teramos que realizar um comando INSERT para cadastr-lo. Caso o autor j estivesse cadastrado, teramos que fazer um comando UPDATE, para atualizar essas informaes na tabela de clientes. Para simplificar situaes como essa, foi criado o comando MERGE (algumas vezes conhecidos como UPSERT, devido s suas circunstncias). MERGE faz, automaticamente, comparaes entre informaes de tabelas, inserindo as linhas que no existem e atualizando as outras. Uma sintaxe simplificada para o comando MERGE apresentado a seguir: MERGE INTO TABELA_DESTINO [AS APELIDO_DESTINO] USING TABELA_ORIGEM [AS APELIDO_ORIGEM] ON (EXPRESSAO_BOOLEANA) WHEN MATCHED THEN OPERAO_VERDADEIRO WHEN NOT MATCHED THEN OPERAO_FALSO Vejamos, a seguir, como exemplo, a realizao da incluso e atualizao dos dados de autores como clientes, conforme descrito anteriormente, atravs do comando MERGE. MERGE INTO CLIENTE CLI 235

USING AUTOR AU ON (AU.CPF = CLI.CPF) WHEN MATCHED THEN UPDATE SET CLI.NOME = AU.NOME CLI.ENDERECO = AU.NOME, CLI.DATA_NASCIMENTO = AU.DATA_NASCIMENTO WHEN NOT MATCHED THEN INSERT(CODIGO, NOME, CPF, ENDERECO, DATA_NASCIMENTO) VALUES (AU.MATRICULA, AU.NOME, AU.CPF, AU.ENDERECO, AU.DATA_NASCIMENTO) Transaes e Concorrncia Uma transao formada por um conjunto de comandos SQL que so atmicos no que diz respeito sua execuo e recuperao do banco de dados. Cada comando executado em um banco de dados faz parte de uma transao, mesmo que unitria. As propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade) so importantes propriedades em transaes. Para implement-las, os SGBDs utilizam mecanismos que podem reduzir o nvel de concorrncia do sistema como um todo. SGBDs so sistemas que, em situaes reais podem ser acessados por milhares de usurios concorrentemente. So comuns situaes onde vrios usurios realizam consultas e atualizaes nos mesmos dados. Na situao ideal, cada usurio de um banco de dados deveria executar os seus comandos como se ele fosse o nico usurio. Esse o maior nvel de isolamento a ser obtido. Entretanto, muito baixo o nvel de concorrncia correspondente a tal nvel de isolamento. Neste caso, usurios podero ficar aguardando por informaes durante tempos relativamente longos, espera do trmino de outras transaes. De forma a aumentar os nveis de concorrncia em detrimento do isolamento, a SQL define quatro nveis de isolamento: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ e SERIAZABLE. Iniciando, Alterando e Concluindo Transaes Se uma transao for concluda com sucesso, as alteraes por ele realizadas no podero ser desfeitas. Mesmo que ocorram falhas no sistema, o SGBD deve prover mecanismos para recuperao de informaes de forma a manter o estado que as mesmas possuam quando da confirmao do trmino de uma transao. De forma anloga, se uma transao concluda com fracasso, o SGBD deve desfazer todas as operaes de atualizao dos dados contidas na transao em questo, retornando o banco de dados para o estado em que estava ao incio da transao. Iniciando uma Transao O comando a seguir uma simplificao do comando de incio de uma transao no padro SQL:2003: START TRANSACTION [NIVEL_DE_ISOLAMENTO] Concluindo uma Transao Uma transao pode ser concluda com sucesso ou com fracasso. Para concluirmos uma transao com sucesso, utilizamos o comando: COMMIT [WORK] Para terminar uma transao com fracasso, ou seja, para desfazer todas as aes ocorridas durante a transao, retornando ao seu estado inicial, utilizamos o comando: ROLLBACK [WORK] Por exemplo: Considere a instncia da tabela ASSUNTO representa na tabela 3.2. Considere que uma transao foi iniciada e que os dois comandos a seguir foram executados: 236

INSERT INTO ASSUNTO (SIGLA, DESCRICAO) VALUES (X, XML) UPDATE ASSUNTO SET DESCRICAO = BIOINFORMATICA WHERE SIGLA = B A nova instncia da tabela representada na tabela 9.1. No entanto, essa instncia est sendo vlida para a transao em questo. Ento, consideremos que os comando a seguir foi realizado. ROLLBACK Neste caso, todas as alteraes foram desfeitas, ou seja, a tabela ASSUNTO voltou a ter o contedo da tabela 3.2. Se, ao invs de desfazermos as alteraes, quisssemos mant-las, tomando a instncia representada pela tabela 9.1 definitiva, bastaria realizar o comando COMMIT ao invs do comando ROLLBACK. Inserindo figura da pgina 8.1 Marcando pontos de retorno A SQL permitem que sejam definidos marcadores durante uma transao chamados de pontos de salvamento (SAVEPOINT). A transao pode, ento, ser desfeita at um ponto de salvamento, tornando sem efeito os comandos que foram executados aps o mesmo. Os pontos de salvamento somente so validos dentro de transaes que foram definidos. No possvel retornar um ponto de salvamento aps a concluso da transao, quer seja com sucesso ou com fracasso. Um ponto de salvamento pode ser definido atravs do comando: SAVEPOINT IDENTIFICADOR_DO_SAVEPOINT Para retornar a um ponto de salvamento, devemos utilizar o comando ROLLBACK em conjunto com a clusula TO SAVEPOINT, conforme mostrado a seguir: ROLLBACK [WORK] TO SAVEPOINT IDENTIFICADOR_DO_SAVEPOINT Consideremos a instncia da tabela ASSUNTO representada na tabela 3.2. Considere que uma transao foi iniciada e que os trs comandos a seguir foram executados. INSERT INTO ASSUNTO (SIGLA, DESCRICAO) VALUES (X, XML) SAVEPOINT PONTO1 UPDATE ASSUNTO SET DESCRICAO = BIOINFORMATICA WHERE SIGLA = B A nova instncia da tabela est representada na tabela 9.1. Ento, consideremos que o comando a seguir foi realizado: ROLLBACK TO SAVEPOINT PONTO1 Neste caso, o comando UPDATE foi desfeito. O contedo temporrio da tabela ASSUNTO est representado na tabela 9.2, mas a transao continua ativa. Neste caso, novos comandos podem ser realizados antes da finalizao da transao. Se, neste ponto, o comando COMMIT for executado, a tabela ASSUNTO ser confirmada com contedo idntico ao da tabela 9.2. Se um comando ROLLBACK for executado, contedo da tabela ASSUNTO voltar a ser da tabela 3.2.

237

Para destruir um ponto de salvamento, devemos utilizar o comando: Concorrncia e Nveis de isolamento Cada transao realizada em um SGBD tem um nvel de isolamento. So quatro os nveis de isolamento definidos no padro SQL: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, e SERIAZABLE. O nvel de isolamento mais alto, SERIAZABLE, faz com que as operaes sejam executadas como se a transao em questo fosse a nica ocorrendo no sistema. Esse nvel de isolamento diminui o nvel de concorrncia. Por outro lado, os nveis de isolamento mais baixos, que aumentam os nveis de concorrncia podem levar a aparentes problemas de consistncia das informaes. Consideremos um ambiente onde no existe isolamento entre as transaes. As alteraes realizadas por um usurio so imediatamente vistas por todos. Neste caso, dentre os fenmenos possveis de ocorrer, temos: Leitura Suja leitura de dados no confirmados. Suponha que ocorram os seguintes passos: 1. Duas transaes, T1 e T2 so iniciadas; 2. A transao T1 modifica a linha L1; 3. A transao T2 l a linha L1 antes que T1 termine; 4. T1 termina com fracasso e suas operaes so desfeitas; Neste caso, T2 ter lido uma informao que nunca foi confirmada. Leitura No-Repetida: duas leituras de dados da mesma transao no se repetem. Na segunda leitura, dados antigos no existem ou foram modificados. Suponha que ocorram os seguintes passos: 1. Duas transaes T1 e T2 so iniciadas; 2. A transao T1 l a linha L1; 3. A transao T2 modifica a linha L1, atualizando seus dados ou apagando a linha; 4. A transao T2 concluda com sucesso e suas operaes so confirmadas; 5. A transao T1 l (ou tenta ler) a linha L1. T1 nunca modificou os dados da linha L2, mas no obteve a mesma leitura duas vezes dentro da mesma transao. Leitura Fantasma: na leitura de um conjunto de dados, surgem novas informaes no conjunto. Suponha que ocorram os seguintes passos: 1. Duas transaes T1 e T2 so iniciadas; 2. A transao T1 l um conjunto de linhas que atendem a uma condio C1; 3. A transao T2 executa uma operao de atualizao que cria uma ou mais que atendem condio C1; 4. A transao T1 l, novamente, um conjunto de linhas que atendem a uma condio C1. Embora T1 no tenha criado linhas que atendam condio C1, novas linhas participaro do resultado da consulta; Perda de atualizao: duas transaes que ocorrem simultaneamente atualizam o mesmo dado no banco de dados. Isto pode ocorrer em uma sequencia segundo a qual uma das atualizaes perdida: 1. Duas transaes, T1 e T2, so iniciadas; 2. A transao T1 l o dado D1 e armazena seu valor na varivel X; 3. A transao T2 l o dado D1 e armazena seu valor na varivel Y; 4. A transao T1 atualiza D1 com o valor de 6*X; 5. A transao T2 atualiza D1 com o valor de 0.5*Y; 238

6. A transao T1 termina com sucesso; 7. A transao T2 termina com sucesso. Para a transao T1, ao seu final, o valor de D1 deveria ter sido multiplicado por seis. J para T2, ao seu final, o valor de D1 deveria ser a metade do seu valor original. Se as transaes T1 e T2 fossem executadas em srie, independente da ordem, o valor final de D1 deveria ser a metade do valor original. Entretanto, na ordenao de comandos demonstrada antes, o valor final de D1 a metade do original, como se a atualizao realizada por T1 nunca tivesse sido realizada. Os quatros nveis de isolamento da SQL podem ser definidos de acordo com sua relao com os quatro fenmenos listados. Essa relao mostrada na tabela 9.3.

O nvel de isolamento a ser utilizado pode ser definido atravs de uma clusula nos comandos de incio de uma transao, conforme foi apresentado. Pode, tambm, ser definido em um comando de alterao das propriedades da transao, o comando: SET TRANSACTION ISOLATION LEVEL NIVEL_DE_ISOLAMENTO Por exemplo, alterar o nvel de isolamento de uma transao para SERIAZABLE: SET TRANSACTION ISOLATION LEVEL SERIAZABLE Programas e Gatilhos Armazenados A linguagem SQL uma linguagem diferente das linguagens tradicionais, como C e Pascal. Ao contrrio de linguagens como estas, no SQL especificamos o resultado que queremos obter, sem nos preocuparmos com a sequencia de passos a serem para obteno do resultado. Por isso, a SQL classificada como uma linguagem declarativa. Por outro lado, SGBDs se tornaram pontos cruciais em ambientes coorporativos, sendo acessos por diversos sistemas. A partir da, surgiram, em algumas situaes, duas necessidades: (i) mover a especificao e execuo de rotinas que verificam e implementam regras de negcio para o prprio SGBD, centralizando, assim, tais operaes e as disponibilizando para toda a empresa de uma s vez, e (ii) fornecer ao SGBD algum tipo de comportamento ativo (ou reativo) a determinadas situaes. De forma a permitir a migrao das regras de negcio para o gerenciador de banco de dados foram definidos, na SQL, os conceitos de procedimento e funo armazenados. Estes so pequenos programas compilados, armazenados e executados diretamente no servidor de banco de dados. So invocados atravs de comandos SQL. J para adicionar ao SGBD comportamento reativo, foi introduzido, na linguagem SQL, o conceito de gatilho. Este um mecanismo que permite a execuo automtica de comandos ou, at mesmo, programas, a partir de eventos que ocorrem na base de dados (como a atualizao do contedo de uma clula, por exemplo). Para permitir a definio de blocos de programas a serem armazenados no SGBD, a SQL foi estendida com comandos tpicos de linguagens no-declarativas, como comandos de iterao e de deciso, por exemplo. Estes blocos compem o corpo no s de procedimentos e funes armazenados nos servidores, mas, tambm, de

239

gatilhos. Os SGBDs apresentam tambm, conjuntos prprios de comandos de controle. No Oracle, a linguagem de programao, chama-se PL/SQL. J no SQL Server, chama-se Transact SQL. Bloco de Comandos Para permitir a criao de programas com SQL, foi criado o conceito de blocos de comandos. Alm disso, foram incorporados linguagem vrios comandos de controle similares aos existentes em outras linguagens de programao. Blocos de comandos so pequenos programas compostos de um ou mais comandos SQL. Permitem a especificao de variveis e cursores prprios aos blocos. Sua estrutura a seguinte: BEGIN DECLARAO DE VARIVEIS DECLARAO DE CURSORES LISTA DE COMANDOS SQL END Existe, ainda, no padro SQL:2003, a possibilidade de declarao de handles, objetos que iro tratar excees ocorridas durante a execuo de blocos de comandos. Declarao de Variveis: em um bloco de comandos, podemos declarar quantas variveis locais forem necessrias. Para isso, utilizamos a seguinte estrutura: DECLARE NOME_VARIAVEL1, NOME_VARIAVEL2, ..., NOME_VARIAVELN TIPO_DE_DADOS Cursores OPEN, FETCH e CLOSE: cursores so mecanismos que permitem que as linhas de uma tabela sejam manipuladas uma a uma. Atuam como ponteiros que apontam para as linhas que formam o resultado de uma dada consulta. Podemos recuperar e manipular os valores de cada linha apontada por um cursor. Desta forma, deve existir um comando SELECT associado a um cursor. Para declarar um cursor e seu comando associado, utilizamos o comando DECLARE CURSOR, conforme mostrado a seguir: DECLARE CURSOR FOR COMANDO_SELECT [FOR UPDATE] Um cursor no deve ser, somente, declarado. Para manipularmos os dados, devemos, inicialmente, abrir um cursor. Para isso, utilizaremos o comando OPEN seguido do nome do cursor, conforme a seguir: OPEN NOME_CURSOR Neste momento, o resultado do comando SQL que define o cursor estar pronto para ser manipulado. Ento, para posicionarmos o ponteiro, devemos utilizar o comando FETCH. Esse comando ir posicionar o ponteiro em uma dada linha e atribuir as informaes apontadas para um conjunto de variveis. Ento, aps a atribuio, poderemos manipular as variveis que recebem o valor de um cursor como tratamos quaisquer outras. FETCH ter a seguinte estrutura: FETCH NOME_CURSOR INTO VARIAVEL1, ..., VARIAVELN O comando FETCH , usualmente, utilizado em conjunto com um comando de iterao, como os comandos REPEAT e WHILE, que sero apresentados ainda nesta seo. Ao final de sua utilizao, o cursor deve ser fechado. Para fechar o cursor, utilizamos o comando CLOSE seguido do nome do cursor, conforme representado a seguir: 240

CLOSE NOME_CURSOR Atravs do comando FOR, poderemos declarar, abrir, navegar, e fechar cursores em um nico comando. O comando FOR ser apresentado mais adiante. Atribuio de Valores: podemos utilizar variveis em blocos de comandos. Para atribuirmos valores a variveis, utilizaremos o comando SET da seguinte forma: SET NOME_VARIAVEL = VALOR; Por exemplo: Bloco de comando contendo a declarao de uma varivel X, de tipo caractere de comprimento cinco, e atribuio do valor OI a X. BEGIN DECLARE X CHAR(5); SET X = OI; END Comando FOR: FOR um comando bastante til, pois permite que, atravs de um s comando, seja declarado como cursor, que seu contedo seja percorrido e que tal cursor seja fechado. O cursor fechado automaticamente ao final do comando. FOR deve ser utilizado quando a navegao se faz de forma seqencial e atravs de todas as linhas do resultado da consulta de declarao do cursor. Sua estrutura mostrado a seguir. FOR NOME_CURSOR [CURSOR FOR] COMANDO_SELECT DO LISTA DE COMANDOS SQL END FOR Ao incio de FOR o cursor declarado e aberto. O ponteiro posicionado na primeira linha do resultado da consulta. Ento, os comandos SQL contidos na lista de comandos so executados. Ao chegar a END FOR, a execuo retorna para FOR que, desta vez, percebe que o cursor j est aberto e posiciona o ponteiro na prxima linha do resultado da consulta. Novamente, o conjunto de comandos SQL executado. O lao se repete at que todas as linhas resultantes do comando SELECT tenham sido percorridas. Comando SELECT INTO: atribui um valor a uma varivel. O valor atribudo recuperado a partir de uma consulta. A consulta deve retornar somente uma linha. A seguir apresentado um formato para o comando. SELECT COL1, COL2, ..., COLN INTO VAR1, VAR2, ..., VARN FROM NOME_TABELA Comando IF: para permitir decises, foi incorporado linguagem SQL o comando IF. Esta testa se uma condio booleana verdadeira e, em funo do resultado dos testes, executa um determinado conjunto de comandos. Sua estrutura : IF CONDICAO_BOOLEANA THEN LISTA DE COMANDOS SQL [ELSE IF CONDICAO_BOOLEANA THEN LISTA DE COMANDOS SQL] [ELSE LISTA DE COMANDOS SQL] END IF

241

Comando WHILE: permite que a execuo de um conjunto de comandos se repita enquanto determina se a condio verdadeira. Sua estrutura : WHILE CONDICAO_BOOLEANA DO LISTA DE COMANDOS SQL END WHILE Comando REPEAT: permite que a execuo de um conjunto de comandos se repita enquanto determinada condio for falsa. Os comandos sero executados ao menos uma vez, independente do valor da condio. REPEAT LISTA DE COMANDOS SQL UNTIL CONDICAO_BOOLEANA END REPEAT Comando LOOP: assim como WHILE e REPEAT, LOOP permite a repetio na execuo de um conjunto de comandos. Entretanto, no caso de LOOP, no existe uma condio a ser testada. Para que a repetio termine, outro comando deve ser utilizado. Segundo a SQL, o comando LEAVE termina o lao. Na estrutura de LOOP, que apresentado a seguir, temos LOOP e END LOOP como delimitadores do comando e conjunto de comandos a serem executados, representados por uma lista de comandos SQL. LEAVE deve ser posicionado na lista de comandos SQL. LOOP LISTA DE COMANDOS SQL END LOOP Procedimentos armazenados e Funes Os blocos e comandos apresentados anteriormente permitem a construo de rotinas que sero executadas no servidor de banco de dados. Tais rotinas podem possuir cdigo extenso e serem bastante complexas. Armazenar tais rotinas no servidor e permitr que sejam invocadas a partir da prpria linguagem SQL aumenta em muito a utilidade de sua construo. Para permitir essa definio e armazenamento, esto definidas, na linguagem SQL, os conceitos de procedimentos e funes armazenados no servidor. Procedimentos armazenados Procedimentos armazenados (stored procedures) so procedimentos anlogos aos existentes em linguagens de programao tradicionais, mas que tero seu cdigo-fonte armazenado no servidor de banco de dados, o que capaz de compil-lo e execut-lo. Assim como em outras linguagens, os procedimentos podero receber valores como parmetros. Esses parmetros so definidos no cabealho de procedimentos. Eles tm um nome, um tipo de dados e um modo. Existem trs modos para os parmetros na SQL:2003: (i) parmetros que permitem apenas que os valores externos das variveis sejam passados dentro do procedimento (idntico s passagens por valor de outras linguagens); (ii) modo onde as variveis internas ao procedimento referentes aos parmetros no recebem valores das variveis externas correspondentes, mas alteraes de valores ocorridas nos procedimentos so efetivadas nas variveis externas correspondentes; e (iii) os valores externos so passados para dentro do procedimento e as modificaes ocorridas internamente so efetivadas para as variveis externas (modo semelhante s passagens por referncia de outras linguagens). Parmetros do primeiro modo so identificados pela palavra reservada IN. A palavra OUT identifica os parmetros do segundo modo. J os parmetros que pertencem ao terceiro modo so identificados pela palavra reservada INOUT. O primeiro passo para a utilizao de procedimentos armazenados a sua criao no servidor. Para criar um procedimento armazenado, utilizamos o comando CREATE PROCEDURE. Uma estrutura bsica para este comando apresentado a seguir. CREATE PROCEDURE NOME_PROCEDURE( 242

MODO_PARAM1 NOME_PARAM1 TIPO_PARAM1, MODO_PARAM2 NOME_PARAM2 TIPO_PARAM2, ... MODO_PARAMN NOME_PARAMN TIPO_PARAMN BLOCO_DE_COMANDOS_SQL Consideremos, por exemplo, o procedimento PRECO_MEDIO apresentado a seguir. Ele possui dois parmetros. O primeiro, NMERO_LIVROS, um parmetro de entrada que recebe do ambiente externo o nmero total de livros a ser considerado. O segundo parmetro, PRECO_MEDIO, um procedimento e este valor estar visvel para a varivel externa correspondente ao parmetro. Aps a declarao da linguagem utilizada, est sendo criado um bloco de comandos SQL. Neste bloco, declarada uma varivel (V_VALOR_TOTAL), utilizado um cursor (MEUCURSOR), manipulado atravs do comando FOR, e o valor mdio dos preos dos livros calculado. Tal valor atribudo varivel PRECO_MEDIO, segundo parmetro do procedimento. CREATE PROCEDURE PRECO_MEDIO (IN NMERO_LIVROS INTEGER, OUT PRECO_MEDIO REAL) LANGUAGE SQL BEGIN DECLARE V_VALOR_TOTAL REAL; SET PRECO_MEDIO = 0; SET V_VALOR_TOTAL = 0; FOR MEU_CURSOR AS SELECT PRECO FROM LIVRO DO SET V_VALOR_TOTAL = V_VALOR_TOTAL + PRECO; END FOR; SET PRECO_MEDIO = V_VALOR_TOTAL / NMERO_LIVROS END Aps a criao do procedimento, este fica armazenado no servidor de banco de dados e est pronto para ser utilizado, bastando acion-lo a partir de um bloco de comandos. Para isso, devemos utilizar seu nome e variveis correspondentes aos parmetros entre parnteses, quando for o caso. A seguir temos um exemplo de chamada ao procedimento PRECO_MEDIO: BEGIN DECLARE V_NUMERO INTEGER; DECLARE MDIA REAL; ... PRECO_MEDIO(V_NUMERO, MDIA); ... END Para destruirmos um procedimento de nosso banco de dados, devemos utilizar o comando DROP PROCEDURE seguido do nome do procedimento a ser destrudo, conforme mostrado a seguir. DROP PROCEDURE NOME_PROCEDIMENTO; Como exemplo, vamos destruir o procedimento PRECO_MEDIO: DROP PROCEDURE PRECO_MEDIO; Funes Armazenadas

243

Alm de procedimentos, o SQL permite que armazenemos funes no servidor de banco de dados. A funo pode receber e tratar diversos parmetros de uma mesma maneira que o procedimento. A diferena entre um procedimento e uma funo reside no fato de que a funo sempre retorna um valor. Assim, para criar uma funo, utilizamos o comando CREATE FUNCTION ao invs do comando CREATE PROCEDURE. Como a funo retorna um valor, no comando CREATE FUNCTION devemos especificar o tipo de dados retornado pela funo. O exemplo da estrutura de CREATE FUNCTION similar a CREATE PROCEDURE. A nica diferena, alm do nome do comando, reside na introduo da clusula RETURNS, onde o TIPO_RETORNO representa o tipo de dados retornado pela funo. CREATE FUNCTION NOME_FUNO ( MODO_PARAM1 NOME_PARAM1 TIPO_PARAM1, MODO_PARAM2 NOME_PARAM2 TIPO_PARAM2, ... MODO_PARAMN NOME_PARAMN TIPO_PARAMN ) RETURN TIPO_RETORNO [LANGUAGE NOME_LINGUAGEM] BLOCO DE COMANDOS SQL Dentro do bloco de comandos do corpo da funo devemos ter um comando RETURN seguido do valor a ser retornado pela mesma. Exemplo: RETURN 3.65; A chamada para execuo de funes um pouco diferente da chamada para execuo de procedimentos. Como funes retornam um valor, o nome da funo aparece ao lado direito do comando de atribuio de valores. Por exemplo: BEGIN DECLARE V_NUMERO INTEGER; DECLARE MDIA REAL; ... SET MDIA = FUNC_PRECO_MEDIO(V_NUMERO); ... END Funes armazenadas podem, ainda, ser utilizadas em comandos SQL da mesma forma que as funes da prpria linguagem, j apresentadas anteriormente. Para destruirmos funes, utilizamos o comando DROP FUNCTION seguido do nome da funo. DROP FUNCTION FUNC_PRECO_MEDIO Gatilhos Gatilhos so especificaes de aes a serem realizadas sempre que um dado evento ocorrer sobre um dado objeto. Entre os eventos possveis, temos a incluso, atualizao ou excluso de informaes de uma tabela. Um gatilho executa um conjunto de comandos, definido num bloco de comandos similar aos apresentados anteriormente. Este bloco pode ser executado uma vez para cada evento que disparou o gatilho ou uma vez para cada linha afetada pelo evento em questo. No primeiro caso, dizemos que se trata de um evento ao nvel de comando e, no segundo, ao nvel de linha. Entretanto, podemos querer que o bloco de comandos seja acionado somente em algumas circunstncias e no todas as vezes que o evento disparador do gatilho ocorrer. A linguagem SQL nos permite realizar tal ao atravs da incluso de uma condio booleana na declarao do gatilho. Devido s suas caractersticas, os gatilhos so conhecidos por atenderem regra ECA Evento, Condio e Ao.

244

Um gatilho pode ser executado antes ou aps a execuo do comando que o disparou. Entretanto, em ambos os casos, podemos querer acessar os dados nos formatos que teriam antes ou aps a execuo de tal comando. Ou seja, podemos, por exemplo, aps a realizao de uma atualizao, querer testar se o novo valor de uma dada coluna diferente do valor anterior. Para permitir o acesso duas verses das informaes de uma dada linha dentro de um gatilho, foram definidas as tabelas de transio NEW e OLD. NEW contm a nova verso das informaes e OLD, a verso antiga. Note que os eventos podem ser operaes de incluso, atualizao e excluso. No caso de uma operao de incluso, OLD est vazia, pois a informao no existia antes do evento. Caso o evento seja um operao de excluso, NEW est vazia, pois a informao no mais existe aps o comando. Quando o evento disparador uma operao de atualizao, tanto NEW quanto OLD possuem dados. A seguir, apresentaremos a sintaxe bsica para a declarao de um gatilho: CREATE TRIGGER NOME_GATILHO MOMENTO_EXECUO EVENTO_DISPARADOR ON TABELA_EVENTO [REFERENCING NEW AS NOVO_NOME_N OLD AS NOVO_NOME_O] [NIVEL_GATILHO] [CONDICAO_EXECUCAO] BLOCO_DE_COMANDOS_SQL Por exemplo: Suponha que desejamos armazenar, sempre que um livro sofra um aumento de preo superior a 20%, seu cdigo, seu preo antigo e seu novo preo. Para isto, criamos uma tabela chamada AUDITORIA que tem trs colunas: uma para armazenar o cdigo do livro que sofreu aumento (CODIGO_LIVRO), a segunda para armazenar o preo do livro antes do aumento (VALOR_ANTIGO) e a ltima (VALOR_NOVO), para armazenar o novo preo do livro. Para que a rotina de armazenamento das mudanas de preo ocorra de forma automtica, criamos um gatilho, chamado TESTA_AUMENTO, que disparado sempre que a coluna PREO, da tabela LIVRO, atualizada. Ento, para cada linha afetada pelo comando de atualizao, se o novo valor for superior a 20% do antigo valor, o cdigo do livro, o seu preo antigo e seu novo preo so inseridos na tabela auditoria. Nesse gatilho, utilizaremos N1 como apelido para a tabela NEW e O1 para apelido para a tabela OLD. O comando de criao do gatilho descrito encontra-se a seguir: CREATE TRIGGER TESTA_AUMENTO AFTER UPDATE OF PRECO ON LIVRO REFERENCING NEW AS N1 OLD AS O1 FOR EACH ROW WHEN (N1.PRECO > 1.2 * O1.PRECO) BEGIN INSERT INTO AUDITORIA (CODIGO_LIVRO, VALOR_ANTIGO, VALOR_NOVO) VALUES (:N1.CODIGO, :O1.PRECO, :N1.PRECO) END; Note que, no exemplo, utilizamos o caractere ; para referenciar, a partir do bloco de comandos SQL, as variveis que representam a tabela de transio. Note, ainda, que, para acessarmos os valores das colunas, podemos utilizar o formato NOME_TABELA_TRANSICAO.NOME_COLUNA. No podemos executar gatilhos atravs de chamadas diretas, como fazemos com procedimentos e funes armazenadas. A nica maneira de execut-los atravs de seu evento disparador. Para apagar um gatilho, utilizamos o comando DROP TRIGGER seguido do nome do gatilho. Exemplo: DROP TRIGGER TESTA_AUMENTO; 245

Extenses ao Relacional No final da dcada de 80, a programao orientada a objetos alcanou um grande nmero de adeptos. O debate entre os que defendiam os SGBDs orientados a objetos e entre os adeptos dos SGBDs relacionais tomou maior importncia. A partir deste, surgiram SGBDs que incorporaram caractersticas de orientao a objeto aos modelos relacionais: os SGBDs estendidos ou relacionais a objeto. Vrios SGBDs Relacionais comearam a se tornar relacionais estendidos, at que a SQL incorporou comandos para criao de tipos do usurio e manipulao de dados no-convencionais, entre outros. Tipos de Dados do Usurio A primeira caractersticas dos SGBDs relacionais estendidos a possibilidade do usurio poder criar seus prprios tipos de dados. Tipos de dados definidos pelo usurio podem conter um ou mais atributos, sendo que cada atributo possui, por sua vez, um tipo de dados prprio, podendo este ser um tipo predefinido ou um tipo de dados do usurio. Tipos de dados do usurio em conjunto com seus atributos formam estruturas anlogas ao struct da linguagem C ou ao RECORD da linguagem Pascal. Podemos, tambm, atribuir mtodos a tipos de dados do usurio. Mtodos so rotinas (procedimentos ou funes) que podem ser acionados para tratamento e manipulao de informaes. Outro importante conceito proveniente de orientao a objetos o de herana. Na orientao a objetos, uma classe, chamada de subclasse, pode herdar atributos e mtodos de outra classe, sua superclasse. Na SQL:2003, um tipo de dados do usurio pode ser classificado como NOT FINAL podero ter herdeiros (ou descendentes), ou seja, seus atributos e mtodos podero ser herdados por outros tipos de dados. CREATE TYPE NOME_TIPO [UNDER NOME_SUPER_TIPO] AS ( ATRIBUTO1 TIPO_ATRIBUTO1, ATRIBUTO2 TIPO_ATRIBUTO2, ... ATRIBUTON TIPO_ATRIBUTON ) [TIPO_FINAL] [METHOD NOME_MTODO1 (PARAMETROS_METODO1), METHOD NOME_METODO2 (PARAMETROS_METODO2), ... METHOD NOME_METODON(PARAMETROS_METODON)] Consideremos que nossa base de dados armazena a informao de endereos em diversas tabelas. Para tornar a definio de um endereo mais completa, gostaramos de dividi-lo em vrios campos: logradouro, nmero, complemento, CEP, bairro, cidade e estado. Como temos vrias tabelas com colunas que armazenam endereos, decidimos, por exemplo, criar um tipo de dados chamado TYP_ENDERECO, que contm os campos citados anteriormente com seus atributos. A criao do tipo de dados TYP_ENDERECO apresentado a seguir: CREATE TYP_ENDERECO ( LOGRADOURO VARCHAR(100), NMERO INTEGER, COMPLEMENTO VARCHAR(15), CEP CHAR(8), BAIRRO VARCHAR(30), CIDADE VARCHAR(40), ESTADO VARCHAR(2) ) 246

FINAL No exemplo anterior, o tipo de dados TYP_ENDERECO foi definido como FINAL. Isso significa que ele no pode ter suas propriedades herdadas por outros tipos de dados. TYP_ENDERECO no apresenta nenhum mtodo. Consideremos, agora, como exemplo, que desejamos tornar a definio de nomes mais bem estruturada, criando dois atributos para um nome e sobrenome. Chamemos nosso tipo de dados de TYP_NOME. Alm disso, muitas vezes, desejamos obter o nome completo de uma pessoa. Para tal, criamos um mtodo que seja capaz de concatenar nome e sobrenome. Os atributos e mtodos desse tipo de dados podem ser herdados por outros tipos. A definio do tipo de dados, contendo atributos e mtodos, apresentado a seguir: CREATE TYPE TIP_NOME( PRIMEIRO_NOME VARCHAR(30), SOBRENOME VARCHAR(30) ) NOT FINAL METHOD NOME_COMPLETO RETURNS VARCHAR Utilizando tipo de dados do usurio Os tipos de dados definidos pelo usurio podem ser utilizados na definio de colunas. Assim, podemos criar uma tabela CLIENTE que possui, dentre as suas colunas, a coluna NOME, de tipo de dados TYP_NOME, e a coluna ENDERECO que tem, como tipo de dados, tipo TYP_ENDERECO. O comando de criao da tabela CLIENTE apresentado a seguir: CREATE TABLE CLIENTES( CODIGO INTEGER PRIMARY KEY, NOME TYP_NOME NOT NULL, ENDERECO TYP_ENDERECO NOT NULL CPF CHAR(11) CONSTRAINT UK_CPF UNIQUE, DATA_NASCIMENTO DATE, TELEFONE VARCHAR(12) ) Para utilizarmos colunas cujos tipos so definidos pelo usurios em comandos de seleo, incluso, atualizao e excluso, devemos utilizar o construtor do tipo, que podemos o nome do prprio tipo de dados. Alterando o tipo de dados do usurio Em varias situaes pode ser necessrios alterar um tipo de dados definido pelo usurio. Podemos, por exemplo, querer: (i) adicionar atributos, (ii) remover atributos, (iii) adicionar novos mtodos e (iv) remover mtodos existentes. Para atender a essas necessidades, foi definido o comando ALTER TYPE. Podemos utilizar ALTER TYPE em diferentes construes. A estrutura a seguir deve ser utilizada para adicionarmos um atributo a um tipo. ALTER TYPE NOME_TIPO ADD ATTRIBUTE NOME_ATRIBUTO TIPO_ATRIBUTO Exemplo: ALTER TYPE TYP_ENDERECO ADD ATTRIBUTE PAIS VARCHAR(35) J para remover um atributo, utilizamos o comando ALTER TYPE com o formato abaixo. ALTER TYPE NOME_TIPO DROP ATTRIBUTE NOME_ATRIBUTO [RESTRICT]

247

RESTRICT refora a idia de que nenhum atributo pode ser apagado se o tipo de dados estiver sendo utilizado na definio de qualquer objeto de b d. Exemplo: ALTER TYPE TYP_ENDERECO DROP ATTRIBUTE PAIS Para adicionar novos mtodos, utilizamos o commando com o formato abaixo: ALTER TYPE NOM_TIPO ADD METHOD NOME_METODO [PARAMETROS_METODO] RETURNS TIPO_RETORNO Aps a incluso do mtodo, seu corpo deve ser especificado. Tal especificao ocorre de forma anloga apresentada anteriormente. J para removermos um mtodo do tipo definido pelo usurio, utilizamos o comando ALTER TYPE conforme mostrado a seguir. ALTER TYPE NOME_TIPO DROP METHOD NOME_METODO Removendo tipos de dados do usurio Tipos de dados do usurio podem ser excludos. Para isso, utilizamos o comando DROP TYPE seguido do nome do tipo de dados em questo. A seguir, teremos o exemplo de excluso dos tipos TYP_CLIENTE e TYP_ENDERECO. DROP TYPE TYP_CLIENTE DROP TYPE TYP_ENDERECO Para que possamos excluir um tipo de dados, ele no deve estar sendo utilizado por nenhuma tabela e nem por outro tipo de dados. Armazenando e referenciando objetos Os objetos (de dados) criados a partir dos tipos definidos pelo usurio possuem um identificador nico, chamado OID (object identifier). Podemos referenciar os objetos, atravs de seu OID, utilizando o tipo REF. REF um ponteiro para objetos de um determinado tipo de dados do usurio. Permite implementar vnculos entre relaes onde em um dos lados existe um objeto. Desta forma, podemos criar colunas ou atributos que sejam do tipo REF e que armazenam um ponteiro para um objeto de um dado tipo. Ao valor da coluna, podemos atribuir o valor NULL ou uma referncia ao objeto. Podemos utilizar o valor contido em REF para recuperar o objeto que apontado e para atualizar seu valor. Para criarmos um atributo ou coluna que armazene uma referncia, devemos utilizar a construo: NOME_COLUNA REF NOME_TIPO_DE_DADOS_USUARIO Exemplo: Considere que tenhamos montado um banco de dados para armazenar as equipes que participam de um torneio. De cada jogador, queremos armazenar o nome e a equipe a que pertence. De cada equipe, desejamos armazenar o nome e o nome de seu capito. Para isso, iremos criar dois tipos de dados. Iniciamos criando o tipo que representa as informaes de equipes que, por enquanto, contm apenas o atributo nome. CREATE TYPE TYP_EQUIPE AS ( NOME VARCHAR(30) ) Ento, criamos o tipo de dados para representar as informaes de cada jogador. Este tipo contm dois atributos: o nome, e uma referncia para um objeto do tipo referenciado. 248

CREATE TYPE TIP_JOGADOR AS ( NOME VARCHAR(50), EQUIPE REF(TYP_EQUIPE)) Por fim, alteramos TYP_EQUIPE para conter uma referncia para um objeto que contm as informaes do capito da equipe: ALTER TYPE TYP_EQUIPE ADD ATTRIBUTE CAPITAO REF(TYP_JOGADOR) A SQL:2003 nos permite criar tabela que sejam repositrios de objetos. Nestas tabelas, somente temos um objeto. Uma sintaxe simplificada para sua criao : CREATE TABLE NOME_TABELA OF NOME_TIPO_DADOS ( REF IS NOME_COLUNA, NOME_COLUNA_TIPO_REF WITH OPTIONS SCOPE NOME_TABELA_REFERENCIADA, NOME_COLUNA_TIPO_REF2 WITH OPTIONS SCOPE NOME_TABELA_REFERENCIADA2, NOME_COLUNA_TIPO_REFN WITH OPTIONS SCOPE NOME_TABELA_REFERENCIADAN ) Consideremos o tipo de dados TYP_EQUIPE e TYP_JOGADORES, mencionados anteriormente. Vamos, agora, criar as tabelas EQUIPES e JOGADORES de forma a armazenar objeto dos dois tipos, respectivamente. Inicialmente, criamos a tabela EQUIPES, definindo OID como nome da coluna de referncia. Comando: CREATE TABLE EQUIPES OF TYP_EQUIPE (REF IS OID) Ento, criamos a tabela JOGADORES, definindo, tambm, uma coluna de nome OID como coluna de referncia. Na criao, definimos, ainda, que o atributo EQUIPE aponta para objetos contidos na tabela EQUIPES. Comando: CREATE TABLE JOGADORES OF TYP_JOGADOR (REF IS OID, EQUIPE WITH OPTIONS SCOPE EQUIPES) Agora, utilizamos o comando ALTER TABLE para modificar a tabela EQUIPES de forma a fazer com que a coluna CAPITAO referencie objetos contidos na tabela JOGADORES. O comando a ser utilizado, apresentado a seguir, permite alterar a definio de uma coluna, adicionando um escopo para sua referncia. ALTER TABLE EQUIPES ALTER CAPITAO ADD SCOPE JOGADORES Vamos, agora, como exemplo, incluir equipes e jogadores nas tabelas. Comeamos incluindo trs equipes chamadas Equipe Azul, Equipe Verde e Equipe Laranja. Os comandos de incluso so apresentados a seguir. INSERT INTO EQUIPES (OID, NOME) VALUES (TYP_EQUIPE(1), EQUIPE AZUL) INSERT INTO EQUIPES (OID, NOME) VALUES (TYP_EQUIPE(2), EQUIPE VERDE) INSERT INTO EQUIPES (OID, NOME) VALUES (TYP_EQUIPE(3), EQUIPE LARANJA) Note, nos comandos anteriores, que no inclumos valores para o atributo CAPITAO. Alm disso, utilizamos o nome do tipo de dados como construtor para a obteno de um OID a partir dos valores 1, 2 e 3.

249

Podemos, tambm, incluir dados na tabela de jogadores. Vamos incluir trs jogadores para a Equipe Azul: Joo, Andr, e Pedro. Para isso, executamos os comandos a seguir: INSERT INTO JOGADORES (OID, NOME, EQUIPE) VALUES ( TYP_JOGADOR(1), JOAO, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL)) INSERT INTO JOGADORES (OID, NOME, EQUIPE) VALUES ( TYP_JOGADOR(2), ANDR, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL)) INSERT INTO JOGADORES (OID, NOME, EQUIPE) VALUES ( TYP_JOGADOR(3), PEDRO, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL)) Nos comandos anteriores, utilizamos uma subconsulta para recuperar o objeto referente equipe dos jogadores e inseri-lo na tabela JOGADORES. Vamos, agora, marcar o jogador Andr como capito da equipe Azul. UPDATE EQUIPE SET CAPITAO = ( SELECT OID FROM JOGADORES WHERE NOME = ANDR) WHERE NOME = EQUIPE AZUL Podemos, tambm, realizar consultas sobre os dados contidos em JOGADORES e em EQUIPES. Vejamos exemplos: Desejamos selecionar o nome do capito da Equipe Azul. SELECT CAPITAO -> NOME FROM EQUIPES WHERE NOME = EQUIPE AZUL Desejamos selecionar o nome da equipe do jogador JOAO. SELECT EQUIPE -> NOME FROM JOGADORES WHERE NOME = JOAO Desejamos selecionar o nome do capito da equipe do jogador JOAO. SELECT EQUIPE -> CAPITAO -> NOME FROM JOGADORES WHERE NOME = JOAO Nestes comandos utilizamos -> para acessar os campos dos objetos referenciados pelas colunas de tipo REF. No terceiro exemplo, a partir do objeto referente ao jogador JOAO acessamos o objeto referente Equipe Azul, na tablea de equipes, e, ento, acessamos o objeto referente ao jogdor capito da equipe, Andr, para obter o seu nome. A SQL:2003 define, tambm, dois tipos de colees de objetos: arrays e multisets. Arrays so colees onde cada elemento participante possui uma posio fixa e pode ser acessado por sua posio na coleo. Multisets so colees onde no existe ordenao dos elementos. Assim, Multisets so colees onde no existe ordenao dos elementos. Assim, no h um ndice atravs do qual acessemos um dado elemento. Extenso para OLAP A SQL:2003 apresenta diferentes estruturas para atender a necessidades de aplicaes OLAP. Dentre elas, temos os elementos de agrupamento ROLLUP, CUBE e GROUPING SETS, que so apresentados a seguir. Anteriormente foi apresentada a clusula GROUP BY. Ela faz com que dados sejam agrupados atravs de uma ou mais colunas e permite que se apliquem funes sobre as linhas que participam de cada grupo. ROLLUP, CUBE, 250

e GROUPING SETS so empregados em conjunto com GROUP BY, provendo diferentes comportamentos a essa clusula. ROLLUP Quando utilizamos ROLLUP, o resultado obtido contm linhas representando a realizao do agrupamento em vrios nveis. Sua sintaxe de utilizao a seguinte: SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON FROM NOME_TABELA GROUP BY ROLLUP (COL1, ..., COLN) Como exemplo, considere uma base de dados de vendas. Assuma que existe uma tabela onde so armazenadas informaes das vendas realizadas por uma empresa nos diversos estados do pas. So armazenados os produtos vendidos, a data das vendas e as quantidades vendidas em cada operao. Um exemplo desta tabela apresentado na Tabela 11.1. Considere, como exemplo, que desejamos saber a quantidade total vendida em cada combinao de <produto, ms, estado> existente na tabela. Desejamos que a listagem esteja ordenada por estado, ms de venda, e nome do produto. Para isso, devemos utilizar a consulta a seguir. SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL FROM VENDA GROUP BY ESTADO, MONTH(DATA), PRODUTO ORDER BY ESTADO, MONTH(DATA), PRODUTO Considere que, agora, desejamos montar uma listagem que apresente os totais de vendas, no s para as diversas combinaes de <produto, ms, estado>, mas, tambm, para cada par <ms, estado> e para cada estado isoladamente. Vamos, ento, utilizar o operador ROLLUP: SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL FROM VENDA GROUP BY ROLLUP (ESTADO, MONTH(DATA), PRODUTO) ORDER BY ESTADO, MONTH(DATA), PRODUTO Note a diferena entre os resultados da utilizao da clusula GROUP BY com e sem o operador ROLLUP. Quando utilizamos o operador ROLLUP, alm das linhas obtidas com a realizao do agrupamento, so obtidas novas linhas que contm os subtotais para cada nvel de agrupamento. Uma linha contendo o total geral tambm participa do resultado. Grouping Sets J a utilizao do operador GROUPING SETS faz com que o agrupamento seja realizado, isoladamente, por cada uma das expresses contidas na clusula GROUP BY. Ou seja, o resultado de uma consulta com a utilizao de GROUPING SETS em um clusula GROUP BY com n expresses idntico unio dos resultados de n comandos com a clusula GROUP BY utilizada isoladamente e, em cada um dos n comandos, somente uma das colunas n originais est presente em GROUP BY. GROUPING SETS utilizado de forma idntica a ROLLUP, bastando substituir no comando de consulta, ROLLUP por GROUPING SETS. Vejamos, como exemplo, a utilizao de GROUP SETS na nossa tabela de vendas. SELECT ESTADO, MONTH(DATA) AO MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL FROM VENDA GROUP BY GROUPING SETS (ESTADO, MONTH(DATA), PRODUTO) 251

ORDER BY ESTADO, MONTH(DATA), PRODUTO Note, no exemplo, anterior, que o resultado final idntico ao que seria obtido se realizssemos a consulta trs vezes, onde, em cada uma, somente o comando GROUP BY e uma das trs expresses de agrupamento (ESTADO, MONTH(DATA), PRODUTO) fossem utilizados. CUBE Este operador realizar agrupamentos por cada combinao possvel das expresses contidas na clusula GROUP BY. Ele apresenta, tambm, uma linha com informao condensada de toda a tabela. utilizado de forma idntica a ROLLUP e a GROUP SETS. Vejamos um exemplo de consulta utilizando a tabela VENDA: SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL FROM VENDA GROUP BY CUBE(ESTADO, MONTH(DATA), PRODUTO) ORDER BY ESTADO, MONTH(DATA), PRODUTO Notamos que esto presentes no resultado aqueles que seriam obtidos se realizssemos vrias consultas com a clusula GROUP BY e diversas combinaes entre as colunas ESTADO e PRODUTO e a expresso MONTH(DATA). Nos exemplos anteriores, utilizamos a funo SUM. Comportamento anlogo pode ser obtido se utilizarmos outras funes agregadas, como SUM. No caso da utilizao de AVG em conjunto com ROLLUP, por exemplo, obtemos a mdia por produto, ms e estado, a mdia de vendas por ms e estado, a mdia por estado e, enfim, a mdia final de vendas. Privilgios e Papis Controle de privilgios um importante mecanismo existente em SGBDs. atravs dele possvel garantir que os usurios realizem apenas as operaes que lhe so permitidas. Todo acesso a um SGBD realizado em conjunto com a identificao de um usurio ou tipo de usurio, seja de forma implcita ou explcita. A cada usurio podem estar associados diversos privilgios. De acordo com os privilgios que possui, o usurio pode, por exemplo, se conectar ao banco de dados, criar outros usurios e ler, alterar, incluir ou apagar dados de uma ou mais tabela. possvel ainda, por exemplo, configurar o sistema de forma que um determinado usurio conectado ao SGBD no saiba da existncia de uma ou mais tabelas. Para isso, basta no atribuir a tal usurio os privilgios mnimos para que tome conhecimento da existncia das tabelas em questo. De forma a facilitar o gerenciamento e a atribuio de privilgios a usurios, o padro SQL define a possibilidade de criao de papis (roles), os quais podem ser tratados como conjuntos de privilgios que podem ser atribudos a usurios. Usurios O padro SQL define o conceito de identificadores de usurios como a representao no SGBD de usurios do mundo real. Desta forma, identificadores de usurios representam usurios do SGBD. De acordo com o que foi definido no padro SQL, toda sesso SQL possui um identificador de usurio a ela associado. De acordo com os privilgios, que o identificador de usurio da sesso possuir, so definidos os comandos que podem ou no ser executados na referida sesso. comum que usurios do banco de dados representem aplicaes e no usurios reais. Do ponto de vista do SGBD, no que se refere ao controle de acesso e segurana, esses tipos de usurios no so diferentes entre si, devendo ser tratados de maneira similar, havendo tambm a necessidade de atribuio e revogao de privilgios.

252

Privilgios O padro SQL define um privilegio como sendo uma autorizao para que uma dada ao seja executada. Estas aes geralmente incidem sobre um objeto de banco de dados, como tabelas, vises, gatilhos ou colunas, por exemplo. Dentre as possveis aes indicadas no padro SQL, temos: INSERT [LISTA_DE_COLUNAS] LISTA DE COLUNAS opcional. Permite incluir somente valores para as colunas especificadas na LISTA_DE_COLUNAS, caso esta lista tenha sido especificada, ou para todas as colunas de uma tabela/viso, caso a lista no tenha sido especificada. UPDATE [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite atualizar as colunas de uma tabela/viso especificadas na LISTA_DE_COLUNAS, caso essa lista tenha sido especificada, ou em todas as colunas, caso essa lista no tenha sido especificada. DELETE Apagar dados em uma tabela. SELECT [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite selecionar valores de uma tabela/viso, somente para as colunas especificadas na LISTA_DE_COLUNAS, caso esta lista tenha sido especificada, ou para todas as colunas, caso essa lista no tenha sido especificada. REFERENCES [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite referenciar uma tabela na criao de chaves estrangeiras. Somente as colunas especificadas na LISTA_DE_COLUNAS podero ser referenciadas, caso essa lista tenha sido especificada, ou qualquer coluna, caso a lista no tenha sido especificada. De forma a melhorar os mecanismos de controle de acesso e segurana, os Gerenciadores de Banco de dados apresentam diversos privilgios alm dos especificados no padro. Cada SGBD possui seu prprio modelo de privilgios. Nesses modelos, os privilgios so classificados, geralmente, ao menos como privilgios de objeto e privilgios de sistema. De toda a forma, so comuns em SGBDs privilgios especficos para: Conectar-se a uma instncia do SGBD ou a uma de suas bases de dados; Criar e destruir objetos do banco de dados, como tabelas, ndices, vises, gatilhos, e procedimentos armazenados, dentre outros. Consultar, atualizar, incluir e excluir dados em tabelas (e em vises, para gerenciadores que suportam a realizao dessas operaes nas mesmas). Executar procedimentos e funes armazenados. Alterar as caractersticas do sistema e de suas bases de dados, tais como parmetros de inicializao. Realizar operaes de gerao de cpias de segurana (backup) e recuperao de tais cpias (restore). Em geral, o usurio analista de sistema ou programador no necessitar possuir todos esses privilgios. A maioria de tais privilgios se relaciona com aes que so realizadas especificamente pelo administrador do banco de dados. Usualmente, o administrador do banco de dados que concede os privilgios necessrios para que outros usurios realizem suas aes. Atribuindo privilgios a um usurio Para atribuirmos um privilgio a um usurio (ou seja, para permitimos que um usurio realize uma determinada ao), devemos utilizar o comando GRANT, cuja sintaxe exibida a seguir: GRANT PRIVILEGIOS TO NOME_PRIVILEGIADO [WITH HIERARCHY OPTION][WITH GRANT OPTION] [GRANTED BY NOME_CONCEDENTE] importante notar que, para poder atribuir um privilgio a um dado usurio, o usurio concedente deve possuir privilgios para tal. Como exemplo, consideremos que deve ser permitido ao usurio MARIA realizar qualquer operao dentro da tabela EDITORA. Para atribuir ao referido usurio tais privilgios, pode ser usada a clusula ALL PRIVILEGES. 253

GRANT ALL PRIVILEGES ON EDITORA TO MARIA Considere-se, ainda, que este usurio deveria poder, tambm, selecionar e atualizar dados da tabela LIVRO, mas que no lhe deve ser permitido incluir ou apagar dados desta tabela. O usurio MARIA poder, ainda, conceder privilgios que possui na tabela LIVRO a outros usurios. Para permitir que o usurio MARIA realize tais aes, executa-se o comando a seguir: GRANT SELECT, UPDATE ON LIVRO TO MARIA WITH GRANT OPTION J no que se refere tabela ASSUNTO, o usurio MARIA somente pode alterar apenas a coluna DESCRIO. Para atribuir Maria privilgios necessrios para realizar essa operao, deve ser executado o seguinte comando: GRANT UPDATE(DESCRIO) ON ASSUNTO TO MARIA Conforme mencionado anteriormente, para que os comandos GRANT apresentados nos exemplos possam ser executados com sucesso, devem ser executados por um usurio que possua os privilgios adequados. Usualmente, esse usurio representa o administrador do banco de dados, o qual possui privilgios de sistema que lhe permitem realizar todas, ou quase todas as operaes do banco de dados. No entanto, podem, tambm, ser executados por um usurio que tenha recebido tais privilgios com a opo WITH GRANT OPTION, que lhe permite atribuir privilgios recebidos a outros usurios. Privilgios referentes manipulao de dados em objetos podem, ainda, ser executados pelo usurio dono do objeto em questo. Usualmente, o dono de um objeto de banco de dados o usurio que o criou. Removendo privilgios de um usurio Aps o usurio ter recebido o privilegio para executar uma ao, ele ir manter esse privilgio at que o mesmo seja explicitamente revogado. Para revogar um ou mais privilgios de um usurio, deve-se utilizar o comando REVOKE. Sua estrutura simplificada mostrada a seguir: REVOKE [GRANT OPTION FOR] PRIVILGIOS FROM NOME_PRIVILEGIADO Como exemplo, consideremos que o usurio MARIA no deve mais possuir a habilidade de alterar dados da tabela EDITORA. Para tal, pode-se executar comando como o apresentado a seguir. REVOKE UPDATE ON EDITORA FROM MARIA Consideremos, agora, que no deve mais ser permitido ao usurio MARIA atribuir a todos os outros usurios o privilgio de atualizao da tabela LIVRO. Para tal, pode-se executar o comando apresentado a seguir, que revoga essa habilidade do usurio em questo, mas tambm a possibilidade que o referido usurio possa atualizar dados na tabela LIVRO. REVOKE GRANT OPTION FOR UPDATE ON LIVRO FROM MARIA Podemos ainda considerar a situao onde no mais deve ser permitido ao usurio realizar quaisquer aes na tabela ASSUNTO. Para tal, pode-se executar o comando a seguir, que retira do usurio os privilgios para executar aes na tabela ASSUNTO. REVOKE ALL PRIVILEGES ON ASSUNTO FROM MARIA Papis Em um ambiente de banco de dados de produo podem existir diversos usurios e algumas centenas ou at mesmo milhares de tabelas, entre outros objetos. Muitos dos usurios podem utilizar o mesmo conjunto de objetos, devendo ter privilgios para executar conjuntos similares de aes. Atribuir privilgios referentes a cada um dos objetos para cada usurio de forma individual pode ser uma tarefa bastante trabalhosa. Alm disso, a medida que aumenta o nmero de tabelas ou outros objetos sobre as quais cada usurio deve ter privilgios, aumenta tambm a probabilidade de que, por erro ou por esquecimento 254

pode ficar desapercebido num primeiro momento. No entanto, poder causar problemas mais graves, por exemplo, quando a aplicao que utilize o usurio em questo para acessar o banco de dados esteja em produo. Para facilitar as tarefas de administrao do banco de dados relacionadas com a atribuio e revogao de privilgios, e reduzir o nmero de erros nessas operaes, foi definido o conceito de Papel (Role). Um Papel visa representar todas as aes que um ou mais usurios podem realizar no banco de dados. Assim, aps criar um papel, necessrio atribuir-lhe todas as aes que representa. Em seguida, esse papel pode ser atribudo a um ou mais usurios. Todos os usurios a quem o papel for atribudo recebero todos os privilgios que foram atribudos ao papel em questo. A qualquer momento possvel atribuir ou revogar privilgios de um papel, e atribuir ou revogar o papel de um ou mais usurios. Desta forma, ao ser criado um novo usurio B que deva possuir os mesmos privilgios para execuo de aes que outro usurio A j existente, podemos atribuir ao usurio B os mesmos papis que tiverem sido atribudos ao usurio A. Criando e utilizando Papis Para criamos um papel, utilizamos o comando CREATE ROLE. Sua sintaxe simplificada a seguinte: CREATE ROLE NOME-ROLE Consideremos a base de dados de livros que ser utilizada por vrios usurios que podem ser agrupados segundo dois diferentes perfis: um denominado BIBLIOTECA e outro denominado VISITANTE. Para criar esses papis, utilizamos o comando a seguir: CREATE ROLE BIBLIOTECA CREATE ROLE VISITANTE Os papis somente sero teis se a eles forem associados os privilgios aos quais correspondem. Para aqueles que possurem o papel BIBLIOTECA, dever ser permitido realizar quaisquer operaes sobre os dados das tabelas ASSUNTO, EDITORA, AUTOR, LIVRO e AUTOR_LIVRO. necessrio, ento, que tais privilgios sejam atribudos ao papel BIBLIOTECA. Isto pode ser feito pelo comando GRANT, de forma similar ao que foi realizado para a atribuio de privilgios para um usurio. Nesse caso, deve-se usar o nome do papel na posio de NOMEPRIVILEGIADO. Os cinco comandos a seguir apresentam a atribuio dos privilgios para o papel BIBLIOTECA. GRANT ALL PRIVILEGES ON ASSUNTO TO BIBLIOTECA GRANT ALL PRIVILEGES ON EDITORA TO BIBLIOTECA GRANT ALL PRIVILEGES ON AUTOR TO BIBLIOTECA GRANT ALL PRIVILEGES ON LIVRO TO BIBLIOTECA GRANT ALL PRIVILEGES ON AUTOR_LIVRO TO BIBLIOTECA Alm de atribuir os privilgios ao papel, faz-se necessrio atribuir o papel a cada usurio que deva ter o perfil em questo. Caso deva ser permitido aos usurios MARIA, JOO e ANA o acesso completo aos dados das tabelas ASSUNTO, EDITORA, AUTOR, LIVRO e AUTOR_LIVRO, podemos atribuir o papel BIBLIOTECA a tais usurios. Para isso, utilizamos o comando GRANT de forma similar ao apresentado anteriormente. Porm, neste caso, PRIVILGIOS ser substitudo pelo nome do papel. O NOME_PRIVILEGIADO ir se referir ao usurio que dever possuir os mesmos privilgios que foram atribudos ao papel. O comando a seguir exemplifica a atribuio do papel BIBLIOTECA aos usurios MARIA, JOO e ANA. GRANT BIBLIOTECA TO MARIA, JOAO, ANA

255

Aps a execuo do comando anterior, os usurios MARIA, JOO e ANA podero executar todas as aes definidas nos privilgios atribudos ao papel BIBLIOTECA. Se considerarmos que, aps uma reavaliao dos critrios de segurana do banco de dados, seja definido, por exemplo, que o papel BIBLIOTECA no deve ter acesso aos dados da tabela EDITORA, podemos revogar os privilgios que possui com a utilizao do comando REVOKE. A utilizao do comando REVOKE, nesse caso, ser similar apresentada anteriormente, sendo necessrio que se utilize, como NOME_PRIVILEGIADO, o nome do papel em questo. O exemplo a seguir retira os privilgios sobre a tabela EDITORA do papel BIBLIOTECA. REVOKE ALL PRIVILEGES ON EDITORA FROM BIBLIOTECA Ao executarmos o comando anterior, alguns privilgios para executar aes que so revogados do papel BIBLIOTECA e, consequentemente, de todos os usurios que possuem o referido papel. Ou seja, segundo nosso exemplo, os privilgios para executar aes sobre a tabela EDITORA foram removidos dos usurios MARIA, ANA e JOO. De fato, se for necessrio atribuir um novo privilgio ou revogar um privilgio do papel que os usurios possuem. possvel, tambm, revogar de um usurio a sua participao em um papel. Para isso, tambm utilizado o comando REVOKE. Neste caso, o nome do papel ser utilizado em PRIVILEGIOS e o nome do usurio em NOME_PRIVILEGIADO. Consideremos que o usurio ANA no deva mais ter os privilgios definidos para o papel BIBLIOTECA. O exemplo a seguir revoga o referido papel do usurio ANA. REVOKE BIBLIOTECA FROM ANA Removendo Papis Para removermos papis, podemos utilizar o comando DROP ROLE. Sua sintaxe bsica : DROP ROLE NOME_ROLE O comando a seguir exemplifica a excluso do papel BIBLIOTECA atravs do comando DROP ROLE. DROP ROLE BIBLIOTECA Ao removermos um papel, ele automaticamente retirado de todos os usurios a quem tenha sido atribudo. Desta forma, no ser mais permitido aos usurios que executem as aes definidas no papel que foi removido, a menos que os privilgios para tal sejam diretamente atribudos aos usurios ou que sejam atribudos atravs de outros papis. Com base nos exemplos anteriores, pode-se dizer que ao removermos o papel BIBLIOTECA, o usurio JOO no ter mais privilgios para realizar aes sobre as tabelas LIVROS e LIVRO_AUTOR, dentre outras. Isso porque nenhum privilegio sobre tais tabelas tinha sido explicitamente atribudo a este usurio. Todas as aes que ele podia realizar sobre essas tabelas eram permitidas pois o usurio possua o papel BIBLIOTECA, ao qual foi, agora, removido do sistema.

256

Transao e Concorrncia Normalmente, considera-se que um conjunto de vrias operaes no banco de dados uma nica unidade do ponto de vista do usurio. Por exemplo, a transferncia de fundos de uma conta corrente para uma poupana uma operao nica sob o ponto de vista do cliente; dentro do sistema de banco de dados, porm, ela envolve vrias operaes. Evidentemente, essencial a concluso de todo o conjunto de operaes, ou que, no caso de uma falha, nenhuma delas ocorra. Seria inaceitvel o dbito na conta sem o crdito na poupana. As operaes que formam uma nica unidade lgica de trabalho so chamadas de transaes. Um sistema de banco de dados precisa garantir a execuo apropriada das transaes a despeito de falhas ou a transao executada por completo ou nenhuma parte dela executada. Alm disso, ele deve administrar a execuo simultnea de transaes de modo a evitar a ocorrncia de inconsistncias. Retornando a nosso exemplo de transferncia de fundos, uma transao que calcula o total de dinheiro do cliente poderia trabalhar com o saldo da conta corrente antes do dbito feito pela transao de transferncia e, tambm, verificar o saldo da poupana depois do crdito. Com isso, obteria um resultado incorreto. Conceito de Transao Uma transao uma unidade de execuo de programa que acessa e, possivelmente, atualiza vrios itens de dados. Uma transao, geralmente, o resultado da execuo de um programa de usurio escrito em uma linguagem de manipulao de dados de alto nvel ou em uma linguagem de programao (p.e., SQL, COBOL, C ou Pascal), e determinada por declaraes (ou chamadas de funo) da forma begin transaction e end transaction. A transao consiste em todas as operaes ali executadas, entre o comeo e o fim da transao. Para assegurar a integridade dos dados, exigimos que o sistema de banco de dados mantenha as seguintes propriedades das transaes: Atomicidade. Ou todas as operaes da transao so refletidas corretamente no banco de dados ou nenhuma o ser. Consistncia. A execuo de uma transao isolada (ou seja, sem a execuo concorrente de outra transao) preserva a consistncia do banco de dados. Isolamento. Embora diversas transaes possam ser executadas de forma concorrente, o sistema garante que, para todo par de transaes Ti e Tj, Ti tem a sensao de que Tj terminou sua execuo antes de Ti comear, ou que Tj comeou sua execuo aps Ti terminar. Assim, cada transao no toma conhecimento de outras transaes concorrentes no sistema. Durabilidade. Depois da transao completar-se com sucesso, as mudanas que ela faz no banco de dados persistem, at mesmo se houver falhas no sistema. Essas propriedades so chamadas frequentemente de propriedades ACID; o acrnimo derivado da primeira letra de cada uma das quatro propriedades. Para obter um melhor entendimento das propriedades ACID e da necessidade dessas propriedades, vamos considerar um sistema bancrio simplificado que consiste em vrias contas e um conjunto de transaes que acessam e atualizam essas contas. Por enquanto, vamos supor que o banco de dados reside permanentemente em disco, mas que alguma parte dele reside, temporariamente, na memria principal. O acesso ao banco de dados obtido pelas duas seguintes operaes: read(X), que transfere o item de dados X do banco de dados para um buffer local alocado transao que executou a operao de read. write(X), que transfere o item de dados X do buffer local da transao que executou a write de volta ao banco de dados. Em um sistema de banco de dados real, a operao write (escrita) no resulta necessariamente na atualizao imediata dos dados no disco; a operao write pode ser armazenada temporariamente na memria e ser executada depois no disco. Mas, por enquanto, vamos supor que a operao write atualize o banco de dados imediatamente. 257

Seja Ti uma transao que transfere 50 dlares da conta A para a conta B. Essa transao pode ser definida como:

Vamos considerar cada uma das propriedades ACID (para facilidade de apresentao, vamos considera-las em ordem diferente da ordem A-C-I-D). Consistncia. A exigncia de consistncia aqui significa que a soma de A com B deve permanecer inalterada aps a execuo da transao. Sem a exigncia de consistncia, uma soma em dinheiro poderia ser criada ou destruda pela transao! Pode-se verificar facilmente que, se o banco de dados permanece consistente depois da execuo da transao. Assegurar a permanncia da consistncia aps uma transao em particular responsabilidade do programador da aplicao que codifica a transao. Atomicidade. Suponha que, exatamente antes da execuo da transao Ti, os valores das contas A e B sejam 1000 e 2000 dlares, respectivamente. Agora suponha que, durante a execuo da transao Ti, uma falha aconteceu impedindo Ti de se completar com sucesso. Exemplos desses tipos de falhas incluem falta de energia, falhas de mquina e erros de software. Alm disso, suponha que a falha tenha ocorrido depois da execuo da operao write(A), mas antes da operao write(B). Nesse caso, os valores das contas A e B refletidas no banco de dados so 950 e 2000 dlares. Como resultado da falha sumiram 50 dlares. Em particular, notamos que a soma A+B j no preservada.

Assim, como resultado da falha, o estado do sistema no reflete mais de um estado real do mundo que se supe representado no banco de dados. Chamamos esse estado de inconsistente. Devemos assegurar que essas inconsistncias no sejam perceptveis em um sistema de banco de dados. Porm, observe que o sistema pode, em algum momento, estar em um estado inconsistente. Mesmo que a transao Ti seja executada at o final, h um ponto no qual o valor da conta A 950 dlares e o valor da conta B 2000 dlares, que claramente um estado inconsistente. Porm esse estado dever ser substitudo pelo estado consistente em que o valor da conta A 950 dlares e o valor da conta B 2050 dlares. Assim, se a transao nunca se iniciou ou se for garantida sua execuo completa, esse estado incompatvel no seria visvel, exceto durante a execuo da transao. Essa a razo da exigncia da atomicidade: se a propriedade de atomicidade for garantida, todas as aes da transao sero refletidas no banco de dados ou nenhuma delas o ser. A ideia bsica por trs da garantia da atomicidade a seguinte. O sistema de banco de dados mantm um registro (em disco) dos antigos valores de quaisquer dados sobre os quais a transao executa uma gravao e, se a transao no se completar, os valores antigos so restabelecidos para fazer com que parea que ela nunca foi executada. Assegurar a atomicidade responsabilidade do prprio sistema de banco de dados, mais especificamente ela tratada por um componente chamado de componente de gerenciamento de transaes. Durabilidade. Se a transao se completar com sucesso, e o usurio que a disparou for notificado da transferncia de fundos, isso significa que no houve nenhuma falha de sistema que tenha resultado em perda de dados relativa a essa transferncia de capitais. A propriedade de durabilidade garante que, uma vez completada a transao com sucesso, todas as atualizaes realizadas no banco de dados persistiro, at mesmo se houver uma falha de sistema aps a transao se completar. Suponha agora que uma falha do sistema possa resultar em perda de dados na MP, mas que os dados gravados em disco nunca sejam perdidos. Podemos garantir a durabilidade observando um dos seguintes itens: 258

1. As atualizaes realizadas pela transao foram gravadas em disco, antes da transao completar-se. 2. Informaes gravadas no disco, sobre as atualizaes realizadas pela transao, so suficientes para que o banco de dados possa reconstruir essas atualizaes quando o sistema de banco de dados for reiniciado aps uma falha. Assegurar a durabilidade responsabilidade de um componente do sistema de banco de dados chamado de componente de gerenciamento de recuperao. O componente de gerenciamento de transao e o componente de gerenciamento de transao esto estreitamente relacionados. Isolamento. Mesmo asseguradas as propriedades de consistncia e de atomicidade para cada transao, quando diversas transaes concorrentes so executadas, suas operaes podem ser intercaladas de modo inconveniente, resultando em um estado inconsistente. Por exemplo, conforme vimos, o banco de dados fica temporariamente inconsistente, enquanto a transao transfere fundos de A para B, quando o total reduzido j est escrito em A e o total a ser acrescidos ainda est aguardando ser escrito em B. Se uma segunda transao, em execuo concorrente, ler A e B nesse ponto intermedirio e computar A+B, observar um valor inconsistente. Alm disso, se essa segunda transao executar em A e B atualizaes baseadas nos valores inconsistentes que leu, o banco de dados pode ficar em um estado inconsistente mesmo aps ambas as transaes se completarem. Uma soluo para o problema de execuo concorrente de transaes executar as transaes em srie ou seja, uma aps a outra. Entretanto, a execuo simultnea de transaes proporcionam uma melhoria de desempenho significativa. Por isso, foram desenvolvidas opes que permitem que diversas transaes sejam executadas de modo concorrente. Discutimos os problemas causados pela execuo de transaes concorrentes adiante. A propriedade de isolamento de uma transao garante que a execuo simultnea de transaes resulte em uma situao no sistema equivalente ao estado obtido caso as transaes tivessem sidos executadas uma de cada vez, em qualquer ordem. Assegurar a propriedade de isolamento responsabilidade de um componente do sistema de banco de dados chamado componente de controle de concorrncia e bem como a obedincia a seus princpios. Estado da Transao Na ausncia de falhas, todas as transaes completam-se com sucesso. Entretanto, como observamos anteriormente, nem sempre uma transao pode completar-se com sucesso. Nesse caso, a transao abortada. Se asseguramos a propriedade de atomicidade, uma transao abortada. Se assegurarmos a propriedade de atomicidade, uma transao abortada no deve ter efeito sobre o estado do banco de dados. Assim, quaisquer atualizaes que a transao abortada tiver feito no banco de dados devem ser desfeitas. Uma vez que as mudanas causadas por uma transao abortada sejam desfeitas, dizemos que a transao foi desfeita (rolled back retornada). Gerenciar transaes abortadas responsabilidade do esquema de recuperao. Uma transao completada com sucesso chamada efetivada (committed). Uma transao que foi efetivada e que realizou atualizaes transforma o banco de dados em um novo estado consistente que deve persistir at mesmo se houver uma falha no sistema. Uma vez que uma transao chegue efetivao (commit), no podemos desfazer seus efeitos abortando-a. O nico modo de desfazer os efeitos de uma transao efetivada executar uma transao de compensao, porm nem sempre isso possvel. Logo, a responsabilidade pela criao e execuo de uma transao de compensao deixada a cargo do usurio, no sendo tratada pelo sistema de banco de dados. Precisamos ser mais precisos sobre o que queremos dizer com trmino com sucesso de uma transao. Portanto, estabeleceremos um modelo de transao simples e abstrato. Uma transao deve estar em um dos seguintes estados: Ativa, ou estado inicial; a transao permanece neste estado enquanto estiver executando. Em efetivao parcial, aps a execuo da ltima declarao. Em falha, aps a descoberta de que a execuo normal j no pode se realizar. 259

Abortada, depois que a transao foi desfeita e o banco de dados foi restabelecido ao estado anterior do incio da execuo da transao. Em efetivao, aps a concluso com sucesso.

O diagrama de estado correspondente a uma transao mostrado na fig. 13.1. Dizemos que uma transao foi efetivada somente se ela entrou no estado de efetivao. Analogamente, dizemos que uma transao abortou somente se ela entrou no estado de abortada. Uma transao dita concluda se estiver em efetivao abortada.

Uma transao comea no estado ativo. Quando termina sua ltima declarao, ela entra no estado de efetivao parcial. Nesse momento, a transao completou sua execuo, mas ainda possvel ser abortada, j que seus efeitos ainda podem estar na MP, e com isso uma falha de hardware pode impedir que seja completada com sucesso. Ento, o sistema de banco de dados escreve informaes suficientes no disco, de forma que, at mesmo em uma falha eventual, as atualizaes realizadas pela transao possam ser recriadas quando o sistema for reiniciado. Quando a ltima dessas informaes for escrita, a transao entre no estado de efetivao. Conforme mencionamos anteriormente, por enquanto estaremos supondo que as falhas no resultam em perda de dados no disco. Tcnicas para lidar com a perda de dados sero discutidas a seguir. Uma transao entra no estado de falha quando o sistema determina que ela j no pode prosseguir sua execuo normal (p.e., por causa de erros de hardware ou erros lgicos). Essa transao deve ser desfeita. Ela entra, ento, no estado abortada. Nesse momento, o sistema tem duas opes: Ele pode reiniciar a transao, mas somente se ela foi abortada como resultado de algum erro de hardware ou de software no criado pela lgica interna da transao. Uma transao reiniciada considerada uma transao nova. Ele pode matar a transao. Normalmente, isso feito em decorrncia de algum erro lgico interno que s pode ser corrigido refazendo o programa de aplicao, ou porque a entrada de dados no era adequada ou porque os dados desejados no foram encontrados no banco de dados. Devemos ser cautelosos quando tratamos de escritas externas observveis, como escrever em um terminal ou em uma impressora. Uma escrita desse tipo no pode ser apagada, j que vista externamente ao sistema de banco de dados. A maioria dos sistemas permite que essas escritas aconteam somente depois que essas escritas aconteam somente depois que a transao entra no estado de efetivao. Um modo de implementar esse esquema fazer com que o sistema de banco de dados armazene temporariamente, em um meio de armazenamento no-voltil, qualquer valor associado a uma escrita externa, e fazer com que ele executa a escrita real somente depois que a transao entra no estado de efetivao. Se o sistema falhar depois ter entrado no estado de efetivao, mas antes de completar a escrita externa, quando o sistema for reiniciado, o 260

sistema de banco de dados executar a escrita externa (usando as informaes do meio de armazenamento novoltil). Para certas aplicaes, pode ser conveniente permitir que transaes ativas exibam dados aos usurios, particularmente em transaes de longa durao, de minutos ou horas. Infelizmente, no podemos permitir essas sadas de dados, a menos que estejamos dispostos a comprometer a atomicidade da transao. A maioria dos atuais sistemas de transao assegura a atomicidade e, por isso, probe essa forma de interao com usurios. Implementao de Atomicidade e Durabilidade O componente de gerenciamento de recuperao de um banco de dados implementa o suporte atomicidade e durabilidade. Consideraremos primeiro um esquema simples, mas extremamente ineficiente. Esse esquema supe que somente uma transao esteja ativa por vez, e baseia-se em cpias do banco de dados simplesmente um arquivo no disco. Um ponteiro chamado db_pointer mantido no disco; ele aponta para a cpia corrente do banco de dados. No esquema de banco de dados shadow, uma transao que deseja atualizar o banco de dados primeiro cria uma cpia completa dele. Todas as atualizaes so feitas na nova cpia, deixando a cpia original, chamada cpia shadow, intata. Se, em qualquer momento, a transao tiver de ser abortada, simplesmente apaga-se a novo cpia. Se a transao se completa, sua efetivao ser feita conforme segue. Primeiro, o sistema operacional precisa ter certeza de que todas as pginas da nova cpia do banco de dados tenham sido escritas no discos. Em sistemas Unix, o comando flush (transportar, arrebatar) usada para esse propsito. Depois que o flush se completa, o ponteiro db_pointer atualizado para apontar para a nova cpia do banco de dados e a esta se torna a cpia atual. Ento, a cpia velha apagada. Esse esquema mostrado graficamente na fig. 13.2, em que o estado do banco de dados, antes e aps a atualizao, indicado.

Diz-se que uma transao foi efetivada quando o db_pointer atualizado escrito no disco. Discutiremos, agora, como essa tcnica trata as falhas de transao e de sistema. Primeiramente, consideremos a falha de transao. Se a transao falhar antes da atualizao do db_pointer, o contedo antigo do banco de dados no ser afetado. Simplesmente podemos abortar a transao apagando a cpia nova do banco de dados. Se a transao foi efetivada, todas as atualizaes que ela executou esto no banco de dados apontado pelo db_pointer. Assim, ou todas as atualizaes da transao so efetivadas ou nenhum de seus efeitos estaro refletidos, a despeito da falha da transao. Agora, considere uma falha do sistema. Suponha que a falha do sistema ocorra antes do db_pointer atualizado ser escrito em disco. Quando o sistema reiniciar, ele ler o db_pointer, ver o contedo original do banco de dados e nenhum dos efeitos da transao ser visvel no banco de dados. Agora, suponha que o sistema falha depois que o db_pointer tiver sido atualizado em disco. Antes de atualizar o ponteiro, todas as pginas atualizadas da nova cpia do banco de dados foram escritas no disco. Como mencionamos anteriormente, estamos supondo que, uma vez escrito no disco, o contedo de um arquivo no seja danificado, nem mesmo se

261

houver uma falha de sistema. Portanto, quando o sistema reiniciar, ele ler o db_pointer e ver o contedo do banco de dados depois de todas as atualizaes executadas pela transao. Na verdade, a implementao depende da atomicidade da gravao em db_pointer; ou seja, todos os seus bytes so escritos ou nenhum de seus bytes o ser. Se alguns dos bytes do ponteiro forem atualizados por uma escrita, mas outros no, o ponteiro no ser representativo, e tanto a verso antiga do banco de dados quanto a verso nova podem no ser encontradas quando o sistema for reiniciado. Felizmente, os sistemas de disco fornecem atualizaes atmicas para blocos inteiros, ou pelo menos para um setor de disco. Em outras palavras, o sistema de disco garante que atualizar o db_pointer atomicamente. Assim, as propriedades de atomicidade e durabilidade das transaes so garantidas na tcnica de implementao com cpia shadow, feita pelo componente de gerenciamento de recuperao. Um exemplo simples de uma transao, fora do domnio de banco de dados, seria uma sesso de edio de texto. Uma sesso de edio inteira pode ser modelada como uma transao. As aes executadas pela transao so a leitura e a atualizao de um arquivo. Salvar o arquivo ao trmino da edio corresponde efetivao da transao de edio; sair da sesso do editor sem salvar o arquivo corresponde a abortar a transao de edio. Muitos editores de texto usam essencialmente a implementao descrita acima, para garantir que a sesso de edio seja transacional. Um arquivo novo usado para armazenar o arquivo atualizado. Ao trmino da sesso de edio, se o arquivo atualizado for salvo, um comando de arquivo rename usado para rebatizar o arquivo novo com seu nome corrente. Supe-se que o rename seja implementado como uma operao atmica pelo sistema de arquivo subjacente, e que ele tambm apagar o arquivo antigo. Infelizmente, essa implementao extremamente ineficiente no contexto dos grandes banco de dados, j que a execuo de uma nica transao implica copiar o banco de dados inteiro. Alm disso, essa implementao no permite que transaes concorram uma com as outras. H maneiras prticas de implementar a atomicidade e a durabilidade que so muito menos onerosas e mais poderosas. Execues Concorrentes Os sistemas de processamento de transaes, normalmente, permitem que diversas transaes sejam executadas de modo concorrente. Permitir que mltiplas transaes concorram na atualizao de dados traz diversas complicaes em relao consistncia desses dados, conforme vimos anteriormente. Assegura a consistncia, apesar da execuo concorrente de transaes, exige trabalho adicional; muito mais fcil insistir na execuo de transaes sequencialmente, uma de cada vez, cada uma comeando somente depois que a anterior se completou. Porm, h duas boas razoes para permitir a concorrncia. Uma transao consiste em diversos passos. Alguns envolvem atividade de I/O; outros atividades de CPU. A CPU e os discos em um sistema de computador podem operar em paralelo. Logo, a atividade de I/O pode ser feita em paralelo com o processamento na CPU. Assim, o paralelismo entre CPU e o sistema de I/O pode ser explorado para executar diversas transaes em paralelo. Enquanto uma leitura ou escrita solicitada por uma transao est em desenvolvimento em um disco, outra transao pode estar sendo processada na CPU, e outro disco pode estar executando uma leitura ou escrita solicitada por uma terceira transao. Desse modo, h um aumento no throughput do sistema ou seja, no nmero de transaes que podem ser executadas em um determinado tempo. De forma correspondente, o uso do processador e do disco tambm aumentam; em outras palavras, o processador e o disco ficam menos tempo inativos ou sem executar trabalho til. Pode haver uma mistura de transaes em execuo simultnea no sistema, algumas curtas e outras longas. Se a execuo das transaes for sequencial, uma transao curta pode ser obrigada a esperar at que uma transao longa precedente se complete, o que pode gerar atrasos imprevisveis em sua execuo. Se as transaes esto operando em diferentes partes do banco de dados, melhor deixa-las concorre de modo a compartilhar os ciclos de CPU e os acessos de disco entre si. A execuo concorrente reduz os atrasos imprevisveis na execuo. Se as transaes esto operando em diferentes partes do 262

banco de dados, melhor deixa-las concorrer de modo a compartilhar os ciclos de CPU e os acessos de disco entre si. Alm disso, reduz tambm o tempo mdio de resposta: o tempo mdio para uma transao ser completada aps ser submetida. A motivao para usar a execuo concorrente em um banco de dados essencialmente a mesma para usar a multiprogramao em um sistema operacional. Quando vrias transaes so processadas de modo concorrente, a consistncia do banco de dados pode ser destruda, mesmo que cada transao individual seja executada com correo. Vamos agora apresentar o conceito de escalas de execuo (schedules), para ajudar na identificao de quais ordens de execuo podem garantir a manuteno da consistncia. O sistema de banco de dados deve controlar a interao entre as transaes concorrentes para impedi-las de destruir sua consistncia. Isso feito por meio de uma variedade de mecanismos chamados de esquemas de controle de concorrncia. Considere, novamente, o sistema bancrio simplificado j apresentado, que possui diversas contas, alm de um conjunto de transaes que acessa e atualiza essa contas. Sejam T1 e T2 duas transaes que transferem fundos de uma conta para outra. A transao T1 transfere 50 dlares da conta A para a conta B e definida da seguinte forma:

A transao T2 transfere 10 por cento do saldo da conta A para a conta B e definida da seguinte forma:

Sejam mil e dois mil dlares os valores correntes das contas A e B, respectivamente. Suponha que as duas transaes sejam executadas em sequncia, T1 seguida de T2. Essa sequncia de execuo representada na fig. 13.3. A sequncia dos passos das instrues esto em ordem cronolgica a partir do topo da figura, com as instrues de T1 aparecendo na coluna esquerda e as instrues de T2 aparecendo na coluna direita. Depois que a execuo apresentada na fig. 13.3 terminar, os valores nas contas A e B so 855 e 2145 dlares, respectivamente. Assim, o montante de dinheiro das contas A e B ou seja, a soma A+B preservado depois da execuo de ambas as transaes.

263

Analogamente, se as transaes forem executadas em outra sequncia, desta vez T2 seguida de T1, ento a sequncia de execuo correspondente mostrada na fig. 13.4. Novamente, conforme esperado, a soma A+B preservada, e os valores finais das contas A e B so 850 e 2150 dlares, respectivamente. As sequncias de execuo descritas anteriormente so chamadas de escalas de execuo ou escalas. Elas representam a ordem cronolgica por meio da qual as instrues so executadas no sistema. Claramente, uma determinada escala de execuo de um conjunto de transaes consiste em todas as instrues dessas transaes e deve preservar a ordem na qual as instrues aparecem em cada transao individual. Por exemplo, na transao T1, a instruo write(A) deve aparecer antes da instruo read(B), em qualquer escala vlida. Na discusso a seguir, iremos nos referir primeira sequncia de execuo (T1 seguida de T2) como escala 1 e segunda sequncia de execuo (T2 seguida de T1) como escala 2.

Essas escalas de execuo so sequenciais. Cada escala sequencial consiste em uma sequncia de instrues de vrias transaes em que as instrues que pertencem a uma nica transao aparecem agrupadas. Assim, para um conjunto de n transaes, h n! escalas sequenciais vlidas diferentes. Quando vrias transaes so executadas simultaneamente, a escala correspondente pode j no ser sequencial. Se duas transaes so executadas simultaneamente, o sistema operacional pode executar uma transao durante algum tempo e, ento, voltar primeira transao durante algum tempo e assim por diante, alternadamente. Com diversas transaes, o tempo de CPU compartilhado entre todas. Vrias sequncias de execuo so possveis, j que as vrias instrues, de ambas as transaes podem ser intercaladas. Geralmente, no possvel exatamente prever quantas instrues de uma transao sero executadas antes que a CPU alterne para outra transao. Assim, o nmero de escalas de execuo possveis para um conjunto de n transaes muito maior que n! 264

Retornando ao nosso exemplo anterior, suponha que as duas transaes sejam executadas de modo concorrente. Uma escala de execuo possvel mostrada na fig. 13.5. Aps essa execuo, chegamos ao mesmo estado obtido durante a execuo sequencial na ordem T1 seguida de T2. A soma A+B preservada.

Nem todas as execues concorrentes resultam em um estado correto. Para ilustrar, considere a escala de execuo da fig. 13.6. Depois de sua execuo, chegamos a um estado tal que os valores para as contas A e B so 950 e 2100 dlares, respectivamente. Esse estado final um estado inconsistente, j que apareceram 50 dlares durante a execuo concorrente. Realmente, a soma A+B no preservada na execuo das duas transaes.

Se o controle da execuo concorrente deixado completamente sob a responsabilidade do sistema operacional, muitas escalas de execuo possveis, inclusive aquelas que deixam o banco de dados em um estado inconsistente como a descrita anteriormente, so factveis. uma tarefa do sistema de banco de dados garantir que qualquer escala executada deixe o banco de dados em estado consistente. O componente do sistema de banco de dados que executa esta tarefa chamado de componente de controle de concorrncia. Podemos assegurar a consistncia do banco de dados, sob execuo concorrente, garantindo que qualquer escala executada tenho o mesmo efeito de outra que tivesse sido executada sem qualquer concorrncia. Isto , uma escala de execuo deve, de alguma forma, ser equivalente a uma escala sequencial. Serializao O sistema de banco de dados deve controlar a execuo concorrente de transaes para assegurar que o estado do banco de dados permanea consistente. Antes de examinarmos como o sistema de banco de dados pode cumprir essa tarefa, temos de entender primeiro quais escalas de execuo podem garantir a consistente e quais no iro faz-lo. 265

Considerando que as transaes so programas, difcil, pelo carter da computao, determinar quais so as operaes exatas que uma transao executa, e como as operaes de vrias transaes interagem. Por essa razo, no faremos interpretaes sobre o tipo de operaes que uma transao pode executar em um item de dados. Em vez disso, consideraremos apenas duas operaes: read (leitura) e write (escrita). Supomos assim que, entre uma instruo read (Q) e write(Q) em um item de dado Q, uma transao pode executar uma sequncia arbitrria de operaes na cpia de Q, que est residindo no buffer local no qual se processa a transao. Assim, as nicas operaes significativas de uma transao, do ponto de vista da escala de execuo, so suas instrues de leitura e escrita. Por isso, mostraremos apenas as instrues read e write nas escalas de execuo, conforme fizemos na representao da escala 3 que mostrada na fig. 13.7.

Vamos discutir formas de equivalncia entre escalas de execuo; elas conduzem s noes de serializao de conflito e de viso serializada. Serializao de Conflito Vamos considerar uma escala de execuo S com duas instrues sucessivas, Ii e Ij, das transaes Ti e Tj (ij), respectivamente. Se Ii e Ij referem-se a itens de dados diferentes, ento podemos alternar Ii e Ij sem afetar os resultados de qualquer instruo da escala. Porm, se Ii e Ij referem-se ao mesmo item de dados Q, ento a ordem de dois passos pode importar. Como estamos lidando apenas com instrues read e write, h quatro casos a considerar:

Assim, apenas no caso em que ambas, Ii e Ij, so instrues de read a ordem relativa de suas execues no importante. Dizemos que Ii e Ij entram em conflito caso elas sejam operaes pertencentes a diferentes transaes, agindo no mesmo item de dado, e pelo menos uma dessas instrues uma operao de write. Para ilustrar o conceito de operaes conflitantes consideraremos a escala 3 mostrada na fig. 13.7. A instruo write (A) de T1 entra em conflito com a instruo read(A) de T2. Porm, a instruo write(A) de T2 no est em conflito com a instruo read(B) de T1, porque as duas instrues trabalham itens de dados diferentes. Sejam Ii e Ij instrues consecutivas de uma escala de execuo S. Se Ii e Ij so instrues de transaes diferentes e no entram em conflito, ento podemos trocar a ordem de Ii e Ij para produzir uma nova escala de 266

execuo S. Esperamos que S seja equivalente a S, j que todas as instrues aparecem na mesma ordem em ambas as escalas de execuo com exceo de Ii e Ij , cuja ordem no importa. Como a instruo write(A) de T2 na escala 3 da fig. 13.7 no entra em conflito com a instruo read(B) de T1, podemos trocar essas instrues para gerar uma escala de execuo equivalente, a escala 5, conforme mostra a fig. 13.8. A despeito do estado inicial do sistema, ambas as escalas, 3 e 5, produzem o mesmo estado final no sistema.

Continuaremos a trocar instrues no-conflitantes conforme segue: Trocar a instruo read(B) de T1 pela instruo read(A) de T2. Trocar a instruo write(B) de T1 pela instruo write(A) de T2. Trocar a instruo write(B) de T1 pela instruo read(A) de T2.

O resultado final dessas trocas, conforme mostrado na escala 6 da fig. 13.9, uma escala de execuo sequencial. Assim, mostramos que a escala 3 equivalente a uma escala de execuo sequencial. Essa equivalncia implica que, a despeito do estado inicial do sistema, a escala 3 produzir o mesmo estado final produzido por alguma escala sequencial.

Se uma escala de execuo S puder ser transformada em outra, S, por uma srie de trocas de instrues no-conflitantes, dizemos que S e S so equivalentes no conflito. Retornando a nossos exemplos anteriores, observamos que a escala 1 no equivalente no conflito escala 2. Entretanto, a escala 1 equivalente no conflito escala 3, porque as instrues read(B) e write(B) de T1 podem ser trocadas pelas instrues read(A) e write(A) de T2. O conceito de equivalncia no conflito leva ao conceito de serializao de conflito. Dizemos que uma escala de execuo S conflito serializava se ela equivalente no conflito a uma escala de execuo sequencial. Assim, a escala 3 conflito serializava, j que ela equivalente no conflito escala sequencial 1. Finalmente, considere a escala 7 da fig. 13.10; ela consiste somente nas operaes significativas (ou seja, read e write) das transaes T3 e T4. Essa escala de execuo no conflito serializava, j que no equivalente escala sequencial <T3, T4> ou escala sequencial <T4, T3>.

267

 possvel ter duas escalas de execuo que produzam o mesmo resultado, mas que no sejam equivalentes no conflito. Por exemplo, considere a transao T5, que transfere 10 dlares da conta B para a conta A. Seja a escala 8 definida na fig. 13.11. Verificamos que a escala 8 no equivalente no conflito escala sequencial <T1, T5>, j que, na escala 8, a instruo write(B) de T5 entra em conflito com a instruo read(B) de T1. Assim, apenas pela troca de instrues consecutivas no conflitantes, no conseguimos mover todas as instrues de T1 antes daquelas de T5. Porm, os valores finais das contas A e B depois da execuo da escala 8 ou da escala sequencial <T1, T5> so os mesmos isto , 960, e 2040 dlares, respectivamente.

Podemos ver nesse exemplo que h definies menos triviais de equivalncia de escala que a equivalncia de conflito. Para o sistema determinar se a escala 8 produz o mesmo resultado que a escala sequencial <T1, T5>, ele tem de analisar toda computao executada por T1 e T5, em vez de analisar apenas as operaes read e write. Em geral, tal anlise difcil de implementar e onerosa em termos computacionais. Porm, h outras definies de equivalncia entre escalas de execuo baseadas puramente nas operaes read e write. Viso Serializada Vamos considerar uma forma de equivalncia que menos restritiva que a equivalncia de conflito, embora, assim como a equivalncia de conflito, esteja baseada apenas nas operaes read e write das transaes. Considere duas escalas de execuo S e S, com o mesmo conjunto de transaes participando de ambas. As escalas S e S so ditas equivalente na viso se as trs condies seguintes forem satisfeitas: 1. Para cada item de dados Q, se a transao Ti fizer uma leitura no valor inicial de Q na escala S, ento a transao Ti tambm deve, na escala S, ler o valor inicial de Q. 2. Para cada item de dados Q, se a transao Ti executar um read(Q) na escala S, e aquele valor foi produzido por meio da transao Tj (se houver), ento a transao Ti tambm dever, na escala S, ler o valor de Q que foi produzido por meio da transao Tj. 3. Para cada item de dados Q, a transao (se houver) que executa a operao final write(Q) na escala S tem de executar a operao write(Q) final na escala S.

268

As condies 1 e 2 asseguram que cada transao l os mesmos valores em ambas as escalas e, ento, executa a mesma computao. A condio 3, em conjunto com as condies 1 e 2, assegura que ambas as escalas de execuo resultem no mesmo estado final de sistema. Retornando a nossos exemplos anteriores, notamos que a escala 1 no equivalente em viso escala 2, j que, na escala 1, o valor da conta A lido pela transao T2 foi produzido por T1, enquanto isso no ocorre na escala 2. Porm, a escala 1 equivalente em viso escala 3, porque os valor da conta A e B lidos pela transao T2 foram produzidos por T1 em ambas as escalas. O conceito de equivalncia de viso leva ao conceito de serializao de viso. Dizemos que uma escala de execuo S tem viso serializada se for equivalente, em viso, a uma escala de execuo sequencial. Para ilustrar, suponha que aumentemos a escala 7 com a incluso da transao T6 obtendo a escala 9, conforme pode ser visto na fig. 13.12. A escala 9 a viso serializada. De fato, ela equivalente em viso escala sequencial <T3, T4, T6>, j que uma instruo read(Q) l o valor inicial de Q em ambas as escalas, e T6 executa a escrita final de Q em ambas as escalas.

Toda escala conflito serializava viso serializava, mas h escala viso serializava que no so conflito serializava. Realmente, a escala 9 no conflito serializava, uma vez que qualquer par de instrues consecutivas conflitante e, assim, no possvel nenhuma troca de instrues. Observe que, na escala 9, as transaes T4 e T6 executam operaes write(Q) sem terem executado uma operao read(Q). Esse tipo de escrita chamado de escrita cega (blind write). As escritas cegas aparecem em algumas escalas viso serializava que no so conflito serializava. Recuperao At o momento, estudamos quais escalas de execuo so aceitveis do ponto de vista da consistncia do banco de dados, supondo, de modo implcito, que no ocorram falhas de transao. Veremos agora os efeitos das falhas de transao durante a execuo concorrente. Se uma transao Ti falhar, por qualquer razo, precisamos desfazer seus efeitos para garantir a propriedade de atomicidade da transao. Em um sistema que permite execuo concorrente, tambm necessrio assegurar que qualquer transao Tj que seja dependente de Ti (quer dizer, Tj leu dados escritos por Ti) tambm seja abortada. Para alcanar essa segurana, precisamos colocar restries no tipo de escalas permitidas no sistema. Escala de Execuo Recuperveis Considere a escala 11, mostrada na fig. 13.13, na qual T9 uma transao que executa apenas uma instruo: read(A). Suponha que o sistema permita que T9 seja efetivada imediatamente aps executar a instruo read(A). Assim, T9 efetivada antes que T8 o seja. Agora, suponha que T8 falhe antes da efetivao. Como T9 leu o valor do item de dados A escrito por T8, temos de abortar T9 para assegurar a atomicidade da transao. Porm, T9 j foi efetivada e no poder ser abortada. Assim, temos uma situao em que impossvel se recuperar corretamente da falha de T8.

269

A escala 11, com a efetivao acontecendo imediatamente aps a instruo read(A), um exemplo de escala de execuo no-recupervel que, portanto, no deveria ser permitida. A maioria dos sistemas de banco de dados exige que todas as escalas sejam recuperveis. Uma escala recupervel aquela na qual, para cada par de transaes Ti e Tj, tal que Tj leia itens de dados previamente escritos por Ti, a operao de efetivao de Ti aparea antes da operao de efetivao de Tj. Escalas sem cascata Mesmo em uma escala recupervel, para o sistema recuperar-se corretamente da falha de transao Ti, pode ser que seja necessrio desfazer diversas transaes. Tais situaes ocorrem se as transaes leram dados escritos por Ti. Como ilustrao, considere a escala parcial da fig. 13.14. A transao T10 escreve um valor para A que lido pela transao T11. A transao T11 escreve um valor para A que lido pela transao T11. Suponha que, nesse momento, T10 falhe. T10 dever ser desfeita. Como T11 dependente de T10, T11 dever ser desfeita. Como T12 dependente de T11, T12 dever ser desfeita. Esse fenmeno, no qual a falha de uma nica transao conduz a uma srie de reverses de transao, chamado de retorno em cascata (cascading rollback).

O retorno em cascata indesejvel, j que leva a desfazer uma quantia significativa de trabalho. conveniente restringir as escalas quelas nas quais os retornos em cascata no possam acontecer. Tais escalas so chamadas de escalas sem cascata. Uma escala sem cascata aquela na qual cada par de transaes Ti e Tj, tal que Tj leia um item de dados previamente escrito por Ti, a operao de efetivao de Ti aparea antes da operao de leitura de Tj. fcil verificar que toda escala sem cascata tambm recupervel. Implementao do Isolamento At o momento, vimos quais propriedades uma escala deve ter para deixar o banco de dados em um estado consistente e para permitir o tratamento seguro de possveis falhas de transao. Especificamente, as escalas que so conflito ou viso serializava e sem cascata satisfazem essas exigncias. H vrios esquemas de controle de concorrncia que podemos usar para garantir que, at mesmo quando diversas transaes so executadas de modo concorrente, sejam geradas apenas escalas aceitveis, a despeito de como o sistema operacional compartilha os recursos (como o tempo de CPU) entre as transaes. Como um exemplo trivial de um esquema de controle de concorrncia, considere este: uma transao bloqueia (lock) o banco de dados inteiro antes de comear e libera o bloqueio aps sua efetivao. Enquanto uma transao mantm um bloqueio, nenhuma outra tem permisso para realizar um bloqueio, todas elas so obrigadas a esperar sua liberao. Como resultado dessa poltica de bloqueio, apenas uma transao pode executar um bloqueio de cada vez. Logo, so geradas apenas escalas sequenciais. Estas so trivialmente serializveis e fcil verificar que so tambm sem cascata.

270

Um esquema de controle de concorrncia como esse apresenta um desempenho pobre, j que fora as transaes a esperarem o trmino das precedentes antes que possam comear. Em outras palavras, ele possibilita um baixo grau de concorrncia. A execuo concorrente traz vrios benefcios em relao ao desempenho. O objetivo dos esquemas de controle de concorrncia proporcionar um alto grau de concorrncia, enquanto garante que todas as escalas geradas sejam conflito serializava ou viso serializava, e tambm sejam em cascata. Os esquemas tm diferentes caractersticas em termos do grau de concorrncia observado e da quantidade de overhead em que incorrem. Alguns deles permite que apenas escalas conflito serializava sejam geradas, outros permite que escalas viso serializvel, que no so conflito serializava, tambm sejam geradas. Definio de Transao em SQL Uma linguagem de manipulao de dados deve possuir um construtor para especificar o conjunto de aes que constitui uma transao. O padro SQL especifica que uma transao comea de modo subentendido. As transaes so terminadas por uma das seguintes declaraes SQL: Commit work executa a efetivao da transao corrente e comea uma nova. Rollback work aborta a transao corrente. A palavra-chave work opcional em ambas as declaraes. Se um programa termina sem um desses comandos, as atualizaes so efetivadas ou desfeitas a escolha no especificada pelo padro, e dependente da implementao. O padro especifica tambm que o sistema deve assegurar a serializao e retorno sem cascata. A definio de serializao usada pelo padro a que estabelece que uma escala deve ter o mesmo efeito de uma escala sequencial. Assim, tanto serializao de conflito quanto serializao de viso so aceitveis. O padro SQL-92 tambm permite que se estabelea para uma transao uma execuo de modo no serializava em relao a outras transaes. Por exemplo, uma transao pode operar em nvel de read sem efetivao (read uncommitted), permitindo que as transaes leiam registros mesmo sem suas efetivaes. Essa caractersticas oferecida para transaes longas, cujos resultados no precisam ser exatos. Por exemplo, uma informao aproximada geralmente suficiente para estatsticas usadas na otimizao de consultas. Se essas transaes forem executadas de uma maneira serializava, elas poderiam interferir em outras transaes, provocando atrasos. O nvel de consistncia especificado pela SQL-92 : Serializvel o default (padro). Read repetitivo somente permite leitura de registros que sofreram efetivao e, alm disso, exige que nenhuma outra transao consiga atualizar um registro entre duas leituras feitas por uma transao. Entretanto, a transao pode no ser serializava com respeito a outras transaes. Por exemplo, quando se est procurando registros que satisfaam algumas condies, uma transao pode achar alguns dos registros inseridos por uma transao que sofreu efetivao, mas no encontrar os outros. Read com efetivao permite que apenas registros que sofreram efetivao sejam lidos, mas no exige read repetitivo. Por exemplo, entre duas leituras de um registro feitas por uma transao, os registros podem ter sido atualizados por meio de transaes que obtiveram efetivao. Read sem efetivao permite a leitura de registros que no sofreram efetivao. o nvel mais baixo de consistncia permitido pela SQL-92. Teste de Serializao Ao projetar esquemas de controle de concorrncia, devemos mostrar que as escalas geradas por eles so serializveis. Para faz-lo, primeiro temos de entender como determinar, para uma escala S em particular, se ela serializava. Nesta seo, apresentaremos mtodos para determinar serializao de conflito e serializao de viso. 271

Mostraremos que h um algoritmo simples e eficiente para determinar a serializao de conflito. Entretanto, no h nenhum algoritmo eficiente para determinar a serializao de viso. Teste para Serializao de Conflito Seja S uma escala. Construmos um grfico direcionado, chamado grfico de precedncia de S. Esse grfico consiste em um par G=(V,E), em que V um conjunto de vrtices e E um conjunto de arestas. O conjunto de vrtices consiste em todas as transaes que participam da escala. O conjunto de arestas consiste em todas as transaes que participam da escala. O conjunto de arestas consiste em todas as arestas Ti Tj para as quais uma das seguintes condies se verifica: 1. Ti executa write(Q) antes de Tj executar read(Q). 2. Ti executa read(Q) antes de Tj executar write(Q). 3. Ti executa write(Q) antes de Tj executar write(Q). Se h uma aresta Ti Tj no grfico de precedncia, ento, em qualquer escala sequencial S equivalente a S, Ti deve aparecer antes de Tj. Por exemplo, o grfico de precedncia para a escala 1 mostrado na fig. 13.15a. Ele contm a nica aresta T1 T2, j que todas as instrues de T1 so executadas antes da primeira instruo de T2 ser executada. De forma semelhante, a fig. 13.15b mostra o grfico de precedncia para a escala 2 com a nica aresta T2 T1, j que todas as instrues de T2 so executadas antes da primeira instruo de T1 ser executada.

O grfico de precedncia para a escala 4 mostrado na fig. 13.16. Ele contm a aresta T1 T2, porque T1 executa read(A) antes de T2 executar write(A). Ele tambm contm a aresta T2 T1, porque T2 executa read(B) antes de T1 executar write(B). Se o grfico de precedncia para S tem um ciclo, ento a escala S no conflito serializava. A ordem de serializao pode ser obtida por meio da classificao topolgica, que estabelece uma ordem linear consistente com a ordem parcial do grfico de precedncia. Em geral, vrias ordens lineares possveis podem ser obtidas por meio da classificao topolgica. Por exemplo, o grfico da fig. 13.17a possui ordens lineares aceitveis, conforme ilustrado pelas fig. 13.17b e 13.17c. Assim, para testar a serializao de conflito, precisamos construir o grfico de precedncia e evocar um algoritmo de deteco de ciclos. Algoritmos de deteco de ciclos podem ser encontrados em livros-texto sobre algoritmos. Os algoritmos de deteco de ciclos, como aqueles baseados em depth-first search, so da ordem de n2 operaes, em que n o nmero de vrtices no grfico (ou seja, o nmero de transaes). Assim, temos um esquema prtico para determinar a serializao de conflito. Retornando a nossos exemplos anteriores, observe que os grficos de precedncia para as escalas 1 e 2 (fig. 13.15) realmente no contm ciclos. O grfico de precedncia para a escala 4 (fig. 13.16), por outro lado, contm um ciclo que indica que essa escala no conflito serializava. Teste para Serializao de Viso Podemos modificar o teste do grfico de precedncia para serializao de viso, conforme mostraremos a seguir. Entretanto, o teste resultante oneroso em relao ao tempo de CPU. De fato, testar serializao de viso um problema caro em termos computacionais, como veremos posteriormente.

272

No teste para serializao de conflito, sabemos que, se duas transaes, Ti e Tj, tm acesso a um item de dados Q, e pelo menos uma dessas transaes escreve Q, ento a aresta Ti Tj ou a aresta Tj Ti ser inserida no grfico de precedncia. Porm, isto no mais ocorre no teste para serializao de viso. Como veremos em breve, essa diferena a razo da incapacidade em se chegar a um algoritmo eficiente para esse teste. Considere a escala 9 da fig. 13.12. Se seguirmos a regra do teste para serializao de conflito e criamos o grfico de precedncia, obteremos o grfico da fig. 13.18. O grfico contm um ciclo indicando que a escala 9 no conflito serializava. Entretanto, como vimos anteriormente, a escala 9 viso serializava, j que ela equivalente em viso escala sequencial <T3, T4, T6>. A aresta T4 T3 no deveria ter sido inserida no grfico, j que os valores do item Q produzidos por T3 e T4 no foram usados por quaisquer outras transaes, e T6 produziu um valor final novo de Q. As instrues write(Q) de T3 e T4 so chamadas de gravaes inteis.

Com isso, mostramos que no podemos simplesmente usar o esquema de grfico de precedncia citado anteriormente para testar serializao de viso. Precisamos desenvolver um esquema para decidir se uma aresta deve ou no ser inserida no grfico de precedncia. Seja S uma escala. Suponha que a transao Tj leia o valor do item de dado Q escrito por Ti. claro que, se S viso serializava, ento, em qualquer escalar que S seja equivalente a S, Ti deve preceder Tj. Suponha agora que, na escala S, a transao Tk executou uma write(Q). Ento, na escala S, Tk deve preceder Ti ou deve seguir Tj. 273

Ela no poder aparecer entre Ti e Tj, porque dessa forma Tj no leria o valor de Q escrito por Ti e, assim, S no seria equivalente em viso a S. Tais requisitos no podem ser expressos no modelo simples de grfico de precedncia discutido anteriormente. A dificuldade acontece porque sabemos que, no exemplo precedente, um dos pares de arestas, Tk Ti ou Tj Tk, dever ser inserido no grfico, mas no temos, contudo, formulada a regra para determinar qual a escolha apropriada. Para formul-la, precisamos expandir o grfico de precedncia de modo a incorporar as arestas rotuladas. Chamamos esse grfico de grfico de precedncia rotulado. Como antes, os ns do grfico so as transaes que participam da escala. As regras para a insero de arestas rotuladas so descritas a seguir. Seja S uma escala que consiste nas transaes {T1, T2, ..., Tn}. Sejam Tb e Tf duas transaes fictcias, tais que Tb execute write(Q) para todo Q que sofreu acesso em S e Tf, execute uma read(Q) para todo Q que sofreu acesso em S. Construmos uma nova escala S a partir de S por meio da insero de Tb no incio de S e do acrscimo de Tf no final de S. Construmos o grfico de precedncia rotulado para a escala S conforme segue: 1. Adicione uma aresta , se a transao Tj l o valor do item de dados Q escrito pela transao Ti. 2. Remova todas as arestas que incidam em transaes inteis. Uma transao Ti intil se no houver caminho, no grfico de precedncia, de Ti para a transao Tf. 3. Para todo item de dados Q, tal que Tj l o valor de Q escrito por Ti, Tk executa um write(Q) e TkTb, faa o seguinte: no grfico de precedncia rotulado. a. Se Ti=Tb e TjTf, ento insira a aresta b. Se TiTb e Tj=Tf, ento insira a aresta no grfico de precedncia rotulado. c. Se Ti=Tb e TjTf, ento insira o par de arestas e no grfico de precedncia rotulado, em que p um inteiro maior que 0 que no tenha sido usado anteriormente para rotular arestas. A regra 3c determina que, se Ti escrever um item de dados lido por Tj, ento uma transao Tk que escreva o mesmo item de dados deve vir antes de Ti ou depois de Tj. As regras 3a e 3b so casos especiais resultantes do fato de que, necessariamente, Tb e Tf so a primeira e a ltima transao, respectivamente. Quando aplicamos a regra 3c, no estamos exigindo que Tk esteja simultaneamente antes de Ti e depois de Tj. Em vez disso, poderemos escolher onde Tk aparecer, em uma ordem sequencial equivalente. Como ilustrao, considere novamente a escala 7 (fig. 13.10). O grfico construdo pelos passos 1 e 2 mostrado na fig. 13.19a. Ele contm a aresta , j que T3 l o valor de Q escrito por Tb. ele contm a aresta , j que T3 foi a ltima transao que escreveu Q e, assim, Tf leu aquele valor. O grfico final que corresponde escala 7 mostrado na fig. 13.19b. Ele contm a aresta resultante do passo 3a. Ele contm a aresta como resultado do passo 3b.

274

Agora, considere a escala 9 (fig. 13.12). O grfico construdo nos passos 1 e 2 mostrado na fig. 13.20a. O grfico final mostrado na fig. 13.20b. Ele contm as arestas e como resultado do passo 3a. Contm as arestas (j no grfico) e como resultado do passo 3b.

Finalmente, considere a escala 10 da fig. 13.21. A escala 10 viso serializava, j que equivalente em viso escala sequencial <T3, T4, T7>. O grfico de precedncia rotulado correspondente, construdo nos passos 1 e 2 mostrado na fig. 13.22a. O grfico final mostrado na fig. 13.22b. As arestas e foram inseridas como resultado da regra 3a. O par de arestas aplicao da regra 3c. e foi inserido como resultado de uma nica

275

Os grficos mostrados nas figuras 13.19b e 13.22b contm os seguintes ciclos mnimos, respectivamente:

O grfico da fig. 13.20b, por outro lado, no contm ciclos. Se o grfico no contm ciclos, a escala correspondente viso serializava. Realmente, o grfico da figura 13.20b no contm ciclos, e sua escala correspondente, escala 9, viso serializava. Entretanto, se o grfico contiver um ciclo, essa condio no implica necessariamente que a escala correspondente no seja viso serializava. Realmente, o grfico da fig. 13.19b contm um ciclo, contudo sua escala correspondente, escala 7, no viso serializava. O grfico da fig. 13.22b, por outro lado, contm um ciclo, mas sua escala correspondente, escala 10, viso serializava. Como, ento, determinamos se uma escala viso serializava? A resposta est em uma intepretao apropriada do grfico de precedncia. Suponha que haja n pares de arestas distintas. Ou seja, aplicamos n vezes a regra 3c na construo do grfico de precedncia. Haver ento 2n grficos diferentes, sendo que cada grfico contm apenas uma aresta de cada par. Se algum desses grficos for acclico, ento a escala correspondente ser viso serializava. A ordem de serializao determinada pela remoo das transaes fictcias Tb e Tf e pela classificao topolgica do grfico acclico restante. Volte ao grfico da fig. 13.22b. como h exatamente um par distinto, h dois grficos diferentes que devem ser considerados. Os dois grficos so mostrados na fig. 13.23. Como o grfico da fig. 13.23a acclico, sabemos que a escala correspondente, escala 10, viso serializava. O algoritmo descrito anteriormente obriga testar exaustivamente todos os possveis grficos distintos. Para isso mostrou-se que o problema do teste de um grfico acclico nesse conjunto recai sobre a classe de

276

problemas NP-completos. Qualquer algoritmo para um problema NP-completo quase certamente tomar um tempo exponencial proporcional ao tamanho do problema.

De fato, foi mostrado que o problema do teste para serializao de viso , ele prprio, NP-completo. Assim, muito provavelmente no h um algoritmo eficiente para testar serializao de viso. Entretanto, os esquemas de controle de concorrncia ainda podem usar as condies suficientes para serializao de viso. Ou seja, se as condies suficientes forem satisfeitas, a escala viso serializava, mas pode haver escalas viso serializava que no satisfaam as condies suficientes.

277

Controle de Concorrncia J vimos que uma propriedade fundamental da transao o isolamento. Quando diversas transaes so executadas de modo concorrente em um banco de dados, a propriedade do isolamento pode no ser preservada. necessrio que o sistema controle a interao entre transaes concorrentes; esse controle alcanado por meio de uma larga gama de mecanismo chamados esquemas de controle de concorrncia. Todos os esquemas de controle de concorrncia tm por base a propriedade de serializao (serializability). Isto , todos os esquemas apresentados aqui garantem que a ordenao de processamento serializada. Protocolo com Base em Bloqueios (Lock) Um meio de garantir a serializao obrigar que o acesso aos itens de dados seja feito de maneira mutuamente exclusiva; isto , enquanto uma transao acessa um item de dados, nenhuma outra transao pode modifica-lo. O mtodo mais usado para sua implementao permitir o acesso a um item de dados somente se ele estiver bloqueado. Bloqueios H vrios modos por meio dos quais um item de dado pode ser bloqueado. Vamos nos restringir a dois deles: 1. Compartilhado. Se uma transao Ti obteve um bloqueio compartilhado (denotado por S) sobre o item Q, ento Ti pode ler, mas no escrever Q. 2. Exclusivo. Se uma transao Ti obteve um bloqueio exclusivo (denotado por X) do item Q, ento Ti pode tanto ler como escrever Q. Precisamos que toda transao solicite o bloqueio do item Q de modo apropriado, dependendo do tipo de operao realizada em Q. A solicitao direcionada para o gerenciador do controle de concorrncia. A transao pode realizar suas operaes somente depois que o gerenciador de controle de concorrncia. A transao pode realizar suas operaes somente depois que o gerenciador de controle de concorrncia conceder (grants) o bloqueio para transao. Dado um conjunto de bloqueios, podemos definir uma funo de compatibilidade sobre eles. Seja A e B uma representao arbitrria dos modos de bloqueio. Suponha que uma transao Ti solicite um bloqueio do modo A sobre o item Q, sobre o qual a transao Tj (TiTj) mantm um bloqueio do modo B. Se uma transao Ti consegue um bloqueio sobre Q imediatamente, a despeito da presena de um bloqueio do modo B, ento dizemos que o modo A compatvel com o modo B. Essa funo pode ser convenientemente representada por uma matriz. A relao de compatibilidade entre os dois modos de bloqueio usados aqui apresentada na matriz comp da fig. 14.1. Um elemento comp(A,B) da matriz possui valor verdadeiro se, e somente se, o modo A compatvel com o modo B.

Note que o modo compartilhado compatvel com o modo compartilhado, mas no com o modo exclusivo. A qualquer hora podem ser feitos diversos bloqueios compartilhados simultaneamente (por diferentes transaes) sobre um item de dado em particular. Uma solicitao de bloqueio exclusivo precisa esperar at que um bloqueio compartilhado termine para ser efetivada. Uma transao solicita um bloqueio compartilhado do item de dado Q executando a instruo lock-S(Q). Analogamente, um bloqueio exclusivo solicitado pela instruo lock-X(Q). um item de dado Q pode ser desbloqueado por outra transao, o gerenciador de controle de concorrncia no conceder o bloqueio at que todos os bloqueios incompatveis mantidos pela outra transao sejam desfeitos.

278

A transao Ti pode desbloquear um item de dado a qualquer momento. Note que uma transao precisa manter o bloqueio do item de dado durante todo o tempo de acesso quele item. Alm disso, o desbloqueio imediatamente aps o acesso final nem sempre interessante, j que pode comprometer a serializao. Como ilustrao, considere novamente o sistema bancrio apresentado anteriormente. Sejam A e B duas contas que so acessadas pelas transaes T1 e T2. A transao T1 transfere 50 dlares da conta A para a conta B e tem a forma:

A transao T2 apresenta o saldo total das contas A e B isto , a soma A+B e definida por:

Suponha que os saldos de A e B sejam 100 e 200 dlares, respectivamente. Se essas duas transaes so executadas serialmente, na ordem T1, T2 ou T2, T1, ento a transao T2 mostrar o valor 300 dlares. Se, no entanto, essas transaes forem executadas concorrentemente, a escala de execuo 1, mostrada na fig. 14.2, pode ocorrer. Nesse caso, a transao T2 mostrar o resultado 250 dlares, que no correto. A razo desse erro provm da falta de bloqueio em tempo hbil do item de dado B, com isso T2 mostra uma situao inconsistente. A escala de execuo mostra as aes que so executadas pelas transaes, assim como os pontos em que os bloqueios so concedidos pelo gerenciador de controle de concorrncia. Uma transao que pede um bloqueio no pode executar sua prxima ao at que o bloqueio seja concedido pelo gerenciador de controle de concorrncia; da o bloqueio precisa ser concedido no intervalo de tempo entre a operao de pedido de bloqueio e a ao seguinte da transao. Em que momento, exatamente, o bloqueio concedido imediatamente antes da ao seguinte da transao. Assim, retiraremos a coluna que indica as aes do gerenciador de controle de concorrncia de todas as escalas de execuo apresentadas. Suponha, agora, que os desbloqueios sejam realizados ao final da transao. A transao T3 similar transao T1, com desbloqueio ao final da transao, e definida como:

A transao T2 apresenta o saldo total das contas A e B isto , a soma A+B e definida por: 279

Suponha que os saldos de A e B sejam 100 e 200 dlares, respectivamente. Se essas duas transaes so executadas serialmente, na ordem T1, T2 ou T2, T1, ento a transao T2 mostrar o valor 300 dlares. Se, no entanto, essas transaes forem executadas concorrentemente, a escala de execuo 1, mostrada na fig. 14.2, pode ocorrer. Nesse caso, a transao T2 mostrar o resultado 250 dlares, que no correto. A razo desse erro provm da falta de bloqueio em tempo hbil do item de dado B, com isso T2 mostra uma situao inconsistente. A escala de execuo mostra as aes que so executadas pelas transaes, assim como os pontos em que os bloqueios so concedidos pelo gerenciador de controle de concorrncia. Uma transao que pede um bloqueio no pode executar sua prxima ao at que o bloqueio seja concedido pelo gerenciador de controle de concorrncia; da o bloqueio precisa ser concedido no intervalo de tempo entre a operao de pedido de bloqueio e a ao seguinte da transao. Em que momento, exatamente, o bloqueio concedido dentro desse intervalor no importante; o bloqueio considerado seguro mesmo que concedido imediatamente antes da ao seguinte da transao. Assim, retiraremos a coluna que indica as aes do gerenciador de controle de concorrncia de todas as escalas de execuo apresentadas aqui. Suponha, agora, que os desbloqueios sejam realizados ao final da transao. A transao T3 similar transao T1, com desbloqueio ao final da transao, e definida como:

A transao T4 corresponde T2, com desbloqueio ao final da transao, e definida como:

280

Voc pode notar que a sequncia de leituras e escritas da escala de execuo 1, que resulta no total incorreto de 250 dlares, no ocorre usando T3 e T4. Outras escalas so possveis. T4 no apresentar um resultado inconsistente, qualquer que seja a escala de execuo. Infelizmente, o uso de bloqueio pode causar situaes indesejveis. Considere a escala parcial de T3 e T4 na fig. 14.3. J que T3 mantm um bloqueio exclusivo sobre B, e T4 solicita um bloqueio compartilhado em B, e T4 solicita um bloqueio compartilhado em B, T4 espera que T3 libere B. Analogamente, como T4 mantm um bloqueio compartilhado de A, e T3 est solicitando um bloqueio exclusivo em A, T3 est esperando que T4 libere A. Assim, chegamos a uma situao em que nenhuma dessas transaes pode processar em sua forma normal. Essa situao chamada de deadlock (impasse). Quando um deadlock ocorre, o sistema precisa desfazer uma das duas transaes. Uma vez desfeita a transao, os itens de dados so, ento, avaliados por outras transaes, que podem continuar com suas execues. Retornaremos aos meios de tratamento do deadlock mais adiante.

Se no usarmos o bloqueio, ou desbloqueio, dos itens de dados, to logo seja possvel, aps sua leitura ou escrita, poderemos chegar a resultados inconsistentes. Por outro lado, se no desbloquearmos um item de dados antes de solicitarmos um bloqueio a outro item de dados, o deadlock poder ocorrer. H formas de evitar o deadlock em algumas situaes. Entretanto, em geral, deadlocks so problemas inerentes ao bloqueio, necessrio se desejarmos evitar estados inconsistentes. Os deadlocks podem ser preferveis a estados inconsistentes, j que podem ser tratados por meio do rollback (reverso) da transao, enquanto os estados inconsistentes podem originar problemas reais, no tratados pelo sistema de banco de dados. Exigimos que cada transao do sistema siga determinado conjunto de regras, chamado de protocolo de bloqueio, indicando quando uma transao pode ou no bloquear ou desbloquear cada um dos itens de dados. O protocolo de bloqueio restringe o nmero de escalas de execuo possveis. O conjunto de todas as escalas desse tipo um subconjunto de todas as escalas serializadas possveis. Apresentaremos diversos protocolos de bloqueio que permitem somente escalas com serializao de conflitos. Antes de faz-lo, precisamos de algumas definies. Seja {T0, T1, ..., Tn} um conjunto de transaes participantes de uma escala de execuo S. Dizemos que Ti precede Tj em S, denotando Ti Tj, se h um item de dado Q tal que Ti consegue bloqueio do tipo A sobre Q e depois Tj consegue bloqueio do tipo B sobre Q e comp (A,B) = falso. Se Ti Tj, ento essa precedncia implica que, em qualquer escala serial equivalente, Ti precisa aparecer antes de Tj. Observe que esse grfico similar ao usado anteriormente para testar serializao de conflito. Dizemos que um protocolo de bloqueio garante serializao de conflito se, e somente se, para todas as escalas de execuo legais, as relaes associadas so acclicas. Concesso de Bloqueios Quando uma transao solicita bloqueio sobre um determinado item de dado em particular, e nenhuma outra transao mantm o mesmo item de dado bloqueado de modo conflitante, tal bloqueio pode ser concedido. Entretanto, preciso ter cuidado para evitar o seguinte cenrio. Suponha que a transao T2 tenha um bloqueio compartilhado sobre um item de dado e outra transao T1 solicite um bloqueio exclusivo do mesmo 281

item. Claro que T1 ter de esperar at que o bloqueio compartilhado feito por T2 seja liberado. Enquanto isso, uma transao T3 pode solicitar que um bloqueio compartilhado feito por T2 seja liberado. Enquanto isso, uma transao T3 pode solicitar um bloqueio compartilhado sobre o mesmo item de dado. O bloqueio pedido compatvel com o bloqueio concedido a T2, de modo que o bloqueio compartilhado pode ser concedido a T3. Nessa altura, T2 pode liberar o bloqueio, mas T1 ter de esperar agora, at que T3 termine. Novamente, aparece uma nova transao T4 que solicita um bloqueio compartilhado sobre o mesmo item de dado e ele concedido antes que T3 libere o dado. De fato, possvel que haja uma sequncia de transaes solicitando bloqueios compartilhados sobre um item de dado, e que cada uma delas libere seu bloqueio um pouco antes de que novo bloqueio seja concedido outra transao, de modo que T1 nunca consegue seu bloqueio exclusivo. A transao T1 poder nunca ser processada, e ela chamada de inane (starved). Podemos evitar a inanio de transaes da seguinte forma. Quando uma transao Ti solicita o bloqueio do item de dados Q de um modo particular M, o bloqueio concedido contato que: 1. No haja nenhuma outra transao com bloqueio sobre Q cujo modo de bloqueio seja conflitante com M. 2. No haja nenhuma outra transao que esteja esperando um bloqueio sobre Q e que tenha feito sua solicitao de bloqueio antes de Ti. Protocolo de Bloqueio em Duas Fases Um dos protocolos que garante a serializao o protocolo de bloqueio em duas fases (two-phase locking protocol). Esse protocolo exige que cada transao emita suas solicitaes de bloqueio e desbloqueio em duas fases: 1. Fase de expanso. Uma transao pode obter bloqueios, mas no pode liberar nenhum. 2. Fase de encolhimento. Uma transao pode liberar bloqueios, mas no consegue obter nenhum bloqueio novo. Inicialmente, uma transao est na fase de expanso. A transao adquire os bloqueios de que precisa. To logo a transao libera um bloqueio, ela entra na fase de encolhimento e no poder solicitar novos bloqueios. Por exemplo, as transaes T3 e T4 tm duas fases. Por outro lado, as transaes T1 e T2 no tm duas fases. Note que as instrues de desbloqueio no precisam aparecer no final da transao. Por exemplo, no caso da transao T3, podemos colocar a instruo unlock(B) logo aps a instruo lock-X(A) e ainda assim manter a propriedade do bloqueio em duas fases. Podemos mostrar que o protocolo do bloqueio em duas fases garante a serializao de conflitos. Considere qualquer transao. O ponto da escala no qual a transao obteve seu bloqueio final (o fim da fase de expanso) chamado de ponto de bloqueio da transao. Assim, as transaes podem ser ordenadas de acordo com seus pontos de bloqueio essa ordenao , de fato, uma ordenao serializada de transaes. O bloqueio em duas fases no garante a ausncia de deadlock. Observe que as transaes T3 e T4 possuem duas fases, mas na escala de execuo 2 (fig. 14.3) elas esto em um deadlock. Recordamos que, alm de serem serializada, desejvel que as escalas de execuo no sejam em cascata. O rollback em cascata pode ocorrer sob o protocolo de bloqueio em duas fases. Como ilustrao, considere a escala da fig. 14.4. Cada transao observa o protocolo de bloqueio em duas fases, mas a falha de T5 depois do passo read(A) da transao T7 ocasiona o rollback em cascata de T6 e T7.

282

Os rollbacks em cascata podem ser evitados por uma modificao no bloqueio em duas fases chamado protocolo de bloqueio em duas fases severo (strict two-phase locking). O protocolo de bloqueio em duas fases severo exige, em adio ao bloqueio feito em duas fases, que todos os bloqueios de modo exclusivo tomados por uma transao sejam mantidos at que a transao seja efetivada. Essa exigncia garante que qualquer dado escrito por uma transao que no foi ainda efetivada seja bloqueado de modo exclusivo at que a transao seja efetivada, evitando que qualquer outra transao leia o dado em transao. Outra variante do bloqueio em duas fases o protocolo de bloqueio em duas fases rigoroso, que exige que todos os bloqueios sejam mantidos at que a transao seja efetivada. Pode ser facilmente verificado que, com o bloqueio em duas fases rigoroso, as transaes podem ser serializadas na ordem de sua efetivao. A maioria dos sistemas de banco de dados implementa ou o bloqueio em duas fases severo ou o rigoroso. Considere as duas transaes seguintes para as quais mostramos somente algumas das mais significativas operaes de leitura (read) e escrita (write). A transao T8 definida como:

A transao T9 definida como:

Se empregarmos o protocolo de bloqueio em duas fases, ento T8 precisar bloquear a1 de modo exclusivo. Portanto, qualquer execuo concorrente de ambas as transaes atinge uma execuo serial. Note, entretanto, que T8 precisa de um bloqueio exclusivo de a1 somente ao final de sua execuo, quando ela escreve a1. Assim, se T8 estiver bloqueando ai de modo compartilhado e depois mudar esse bloqueio para o modo exclusivo, poderemos obter mais concorrncia, j que T8 e T9 poderiam manter acesso simultneo a a1 e a2. Essa observao remete-nos ao refinamento do protocolo bsico do bloqueio em duas fases, no qual a converso de bloqueios permitida. Podemos proporcionar um mecanismo para promover um bloqueio compartilhado para exclusivo de promoo (upgrade) e de exclusivo para compartilhamento de rebaixamento (downgrade). A converso de bloqueio no pode ser arbitrria. Pelo contrrio, a promoo s pode acontecer durante a fase de expanso, enquanto o rebaixamento somente ocorre na fase de encolhimento. Retornando a nosso exemplo, as transaes T8 e T9 podem ser executadas concorrentemente sob o protocolo de bloqueio em duas fases refinado, como mostra a escala incompleta da fig. 14.5, em que somente algumas das instrues de bloqueio so mostradas. Note que uma transao tentando a promoo de um bloqueio do item Q pode ser forada a esperar. Essa espera forada ocorre se Q estiver bloqueado por outra transao em modo compartilhado.

283

Tanto quanto o protocolo de bloqueio em duas fases, o bloqueio em duas fases com converso de bloqueio no pode ser arbitrria. Pelo contrrio, a promoo s pode acontecer durante a fase de expanso, enquanto o rebaixamento somente ocorre na fase de encolhimento. Retornando a nosso exemplo, as transaes T8 e T9 podem ser executadas concorrentemente sob o protocolo de bloqueio em duas fases refinado, como mostra a escala incompleta da fig. 14.5, em que somente algumas das instrues de bloqueio so mostradas. Note que uma transao tentando a promoo de um bloqueio do item Q pode ser forada a esperar. Essa espera forada ocorre se Q estiver bloqueado por outra transao em modo compartilhado. Tanto quanto o protocolo de bloqueio em duas fases, o bloqueio em duas fases com converso de bloqueio s gera escalas com serializao de conflito, e as transaes podem ser serializadas por seus pontos de bloqueio. Alm disso, se bloqueios exclusivos so mantidos at o final da transao, as escalas so em cascata. Descreveremos agora um esquema simples, mas muito usado, que gera as instrues de bloqueio e desbloqueio, automaticamente, para uma transao. Quando uma transao Ti emite uma operao read(Q), o sistema emite uma instruo lock-S(Q) seguida de uma instruo read(Q). Quando Ti emite uma operao write(Q), o sistema verifica se Ti ainda mantm um bloqueio compartilhado. Se ainda h, o sistema emite uma instruo upgrade(Q), seguida de uma instruo write(Q). De outro modo, o sistema emite uma instruo lockX(Q), seguida de uma instruo write(Q). Todos os bloqueios obtidos por uma transao so desbloqueados depois da transao ser efetivada ou abortada.

Para um conjunto de transaes, pode haver escalas de serializao de conflito que no sejam obtidas por meio do protocolo de bloqueio em duas fases. Entretanto, para obter escalas de serializao de conflito por meio de protocolos de bloqueio sem usar duas fases, precisamos obter informaes adicionais sobre as transaes ou impor alguma estrutura, ou ordem, sobre o conjunto de itens de dados dos banco de dados. Na ausncia de tais informaes, o bloqueio em duas fases necessrio para a serializao de conflito se Ti uma transao que no est em duas fases, sempre possvel encontrar outra transao Tj que esteja em duas fases, tal que haja uma escala vivel para Ti e Tj que no seja conflitante por serializao. O bloqueio em duas fases severo e o bloqueio em duas fases rigoroso (com converso de bloqueios) so usados extensivamente em sistemas de banco de dados comerciais. Protocolos com Base em Grficos (Graph-Based Protocols) Como dissemos, na ausncia de informaes a respeito do modo de acesso aos itens de dados, o protocolo de bloqueio em duas fases necessrio e suficiente para garantir a serializao. Assim, se desejamos desenvolver protocolos que no usam duas fases, precisamos de informaes adicionais sobre como cada transao desenvolver seu acesso ao banco de dados. H diversos modelos que diferem no tocante quantidade de informaes a proporcionar. O modelo mais simples exige que tenhamos conhecimento anterior sobre a ordem na qual os itens de banco de dados sero acessados. Fornecidas essas informaes, possvel construir protocolos de bloqueio que no sejam em duas fases, mas que, no entanto, garantem a serializao de conflito. Para adquirir esse conhecimento prvio, impomos uma ordenao parcial sobre o conjunto D={d1,d2,...,dn} de todos os itens de dados. Se di dj, ento qualquer transao que mantenha acesso a ambos, di 284

e dj, dever acessar primeiro di e depois dj. Essa ordenao parcial pode resultar da organizao fsica ou lgica dos dados, ou pode ser imposta somente para fins de controle de concorrncia. A ordenao parcial implica que o conjunto D pode ser visto agora como um grfico acclico, chamado grfico de banco de dados. Por maior simplicidade, restringiremos nossa ateno somente queles grficos que so rvores razes. Apresentaremos um protocolo simples, chamado de protocolo de rvore, que restrito para emprego somente nos bloqueios exclusivos. No protocolo de rvore permitida somente a instruo de bloqueio lock-X. Cada transao Ti pode bloquear um item de dado no mximo uma vez e deve observar as seguintes regras: 1. O primeiro bloqueio feito por Ti pode ser sobre qualquer dado. 2. Subsequentemente, um certo item de dado Q pode ser bloqueado por Ti somente se os pais de Q estiverem bloqueados por Ti. 3. Itens de dados podem ser desbloqueados a qualquer momento. 4. Um item de dado que foi bloqueado e desbloqueado por Ti no pode ser rebloqueado por Ti subsequentemente. Como colocamos anteriormente, todas as escalas de execuo que forem legais sob o protocolo de rvore que sero conflito serializadas. Para ilustrar esse protocolo, considere o grfico do banco de dados da fig. 14.6. As quatro transaes seguintes respeitam o protocolo de rvore desse grfico. Mostraremos somente as instrues de bloqueio e desbloqueios:

Uma escala possvel em que participam essas quatro transaes a mostrada na fig. 14.7. Note que, durante a execuo, a transao T10 mantm bloqueio sobre duas subrvores separadas.

Observe que a escala da fig. 14.7 conflito serializada. No apenas pode ser mostrado que o protocolo de rvore garante a serializao de conflito, mas tambm que esse protocolo garante a ausncia de deadlock. 285

O protocolo de bloqueio em rvore apresenta a vantagem de realizar o desbloqueio mais cedo do que feito no protocolo de bloqueio em duas fases. O desbloqueio feito mais cedo pode reduzir os tempos de espera e aumentar a concorrncia. Alm disso, uma vez que o protocolo resistente a deadlocks, nenhum rollback necessrio. Entretanto, o protocolo tem a desvantagem de, em alguns casos, uma transao pode manter o bloqueio de um item de dado que no acessa. Por exemplo, uma transao que precise do acesso aos itens de dados A e J cujo grfico do banco de dados o da fig. 14.6, precisa no somente bloquear A e J, mas tambm os itens de dados B, D e H. Esse bloqueio adicional resulta no aumento de overhead relativo aos bloqueios, na possibilidade de tempo de espera adicional e decrscimo potencial da concorrncia. Alm disso, sem o conhecimento prvio de como os itens de dados sero bloqueados, as transaes tero de bloquear a raiz da rvore, o que reduz consideravelmente a concorrncia. Para um conjunto de transaes, h escalas conflitos serializadas que no podem ser obtidas pelo protocolo de rvore. Ainda, h escalas possveis sob o protocolo de bloqueio em duas fases que tambm no so possveis sob o protocolo de rvore, e vice-versa. Protocolos com Base em Timestamp (Registro de Tempo) Nos protocolos de bloqueio, descritos at agora, a ordem entre cada par de transaes conflitantes determinada durante a execuo do primeiro bloqueio que ambas solicitam e que envolve modos incompatveis. Outro mtodo para a determinao da ordem serializada selecionar uma ordenao entre transaes em andamento. O mtodo mais usado o esquema de ordenao por timestamp. Timestamp A cada transao Ti dos sistema associamos um nico timestamp fixo, denotado por TS(Ti). Esse timestamp criado pelo sistema de banco de dados antes que a transao Ti inicie sua execuo. Se uma transao Ti recebeu o TS(Ti) em uma nova transao Tj entre no sistema, ento TS(Ti)<TS(Tj). H duas formas simples de implementar esse esquema: 1. Usar a hora do relgio do sistema (clock) como timestamp, isto , o timestamp de uma transao igual hora em que a transao entra no sistema. 2. Usar um contador lgico que incrementado sempre que se usa um novo timestamp, isto , o timestamp da transao igual ao valor do contador no momento em que a transao entre no sistema. Os timestamps das transaes determinam a ordem de serializao. Assim, se TS(Ti)<TS(Tj), o sistema precisa garantir que a escala produzida seja equivalente a uma escala serial em que a transao Ti aparece antes da transao Tj. Para implementao desse esquema, associamos a cada item Q dois valores para timestamp: W-timestamp(Q) denota o maior timestamp de qualquer transao que execute uma write(Q) com sucesso. R-timestamp(Q) denota o maior timestamp de qualquer transao que execute uma read(Q) com sucesso. Esses timestamps so atualizados sempre que uma nova instruo read(Q) ou write(Q) for executada. O Protocolo de Ordenao por Timestamp O protocolo de ordenao por timestamp assegura que quaisquer operaes de leitura e escrita sejam executadas por ordem de timestamp. Esse protocolo opera da seguinte forma: 1. Suponha que a transao Ti emita uma read(Q). a. Se TS(Ti)<W-timestamp(Q), ento Ti precisa ler um valor de Q que j foi sobreposto. Assim, a operao read rejeitada e Ti desfeita. b. Se TS(Ti)W-timestamp(Q), ento a operao read executada e R-timestamp(Q) recebe o maior valor entre R-timestamp(Q) e TS(Ti). 2. Suponha que a transao Ti emita um write(Q). 286

a. Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti est produzindo foi necessrio antes e o sistema assumiu que aquele valor nunca seria produzido. Logo, a operao write rejeitada e Ti desfeita. b. Se TS(Ti)<W-timestamp(Q), ento Ti est tentando escrever um valor obsoleto em Q. Logo, essa operao write rejeitada e Ti desfeita. c. De outro modo, a operao write executada e W-timestamp(Q) registrado em TS(Ti). Uma transao Ti que foi desfeita pelo esquema de controle de concorrncia, decorrente de uma operao read ou write, recebe um novo timestamp e reiniciada. Para ilustrar esse protocolo, considere as transaes T14 e T15. A transao T14 mostra o contedo total das contas A e B e definida como:

A transao T15 transfere 50 dlares da conta A para a conta B e ento apresenta o resultado de ambas:

Nas escalas criadas obedecendo ao protocolo de timestamp, assumimos que uma transao recebe um timestamp imediatamente antes de sua primeira instruo. Assim, na escala 3 da fig. 14.8, TS(T14)<TS(T15) e a escala possvel sob o protocolo de timestamp. Notamos que a execuo precedente pode tambm ser realizada pelo protocolo de bloqueio em duas fases. H, entretanto, escalas que so viveis sob o protocolo de bloqueio em duas fases, mas inviveis sob o protocolo de timestamp, e vice-versa.

O protocolo de ordenao por timestamp garante a serializao de conflito. Essa assero provm do fato de que operaes conflitantes so processadas pela ordem do timestamp. O protocolo garante tambm resistncia a deadlocks, j que uma transao nunca espera. O protocolo consegue gerar escalas que no podem ser recuperadas (desfeitas), entretanto ele pode receber uma extenso para fazer escalas cascateadas. Regra de Escrita de Thomas (Thomas Write Rule) Apresentaremos agora uma modificao no protocolo de ordenao por timestamp que aumenta a concorrncia em potencial em relao quele que descrevemos anteriormente. Consideremos a escala 4 da fig. 14.9 e apliquemos a ela o protocolo da ordenao por timestamp. Uma vez que T16 comea antes de T17, podemos considerar que TS(T16)<TS(T17). A operao read(Q) de T16 executada, assim como a operao write(Q) de T17. Quando T16 tenta executar sua operao write(Q), descobrimos que TS(T16)<W-timestamp(Q), j que Wtimestamp(Q) = TS(T17). Assim, a operao write(Q) de T16 rejeitada e a transao T16 precisa ser desfeita.

287

Embora o rollback de T16 seja requerido pelo protocolo da ordenao por timestamp, ele desnecessrio. Uma vez que T17 j escreveu Q, o valor que T16 est tentando escrever nunca ser lido. Qualquer transao Ti com TS(Ti)<TS(T17) dever ler o valor de Q que foi escrito por T17 em vez de o valor escrito por T16. Essa observao sugere uma modificao no protocolo de ordenao por timestamp no qual operaes write obsoletas podem ser ignoradas sob determinadas circunstncias. As regras de protocolo para as operaes read permanecem inalteradas. As regras de protocolo para as operaes write, entretanto, so ligeiramente diferentes das do protocolo de ordenao por timestamp vista anteriormente: 1. Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti est produzindo foi necessrio anteriormente, e assumiu-se que o valor nunca seria produzido. Logo, a operao write rejeitada e Ti desfeita. 2. Se TS(Ti)<W-timestamp(Q), ento Ti est tentando escrever um valor obsoleto para Q. Logo, a operao write pode ser ignorada. 3. De outro modo, a operao write executada e W-timestamp(Q) recebe o valor de TS(Ti). A diferena entre essas regras e as apresentadas anteriormente est na segunda regra. O protocolo de ordenao por timestamp exige que Ti seja desfeita se emitir uma write(Q) e TS(Ti)<W-timestamp(Q). Entretanto, aqui, nos casos em que TS(Ti)W-timestamp(Q). Entretanto, aqui, nos casos em que TS(Ti)R-timestamp(Q), ignoramos writes obsoletas. Essa modificao no protocolo de ordenao por timestamp chamada de regra de escrita de Thomas. A regra de escrita de Thomas faz uso da serializao de viso, eliminando, com efeito, as operaes de write obsoletas das transaes que as emitem. Essa modificao torna possvel a gerao de escalas de execuo serializadas que no poderiam ocorrer sob outros protocolos apresentados aqui. Por exemplo, a escala 4 da fig. 14.9 no-conflito serializada e, assim, no vivel sob qualquer protocolo de bloqueio em duas fases, protocolo de rvore ou de ordenao por timestamp. Sob a regra escrita de Thomas, a operao write(Q) da T16 poderia ser ignorada. O resultado uma escala cuja viso equivalente escala serial <T16, T17>. Protocolos com Base em Validao Nos casos em que a maioria das transaes somente de leitura, a taxa de conflitos entre as transaes pode ser baixa. Assim, algumas dessas transaes, se executadas sem a superviso de um esquema de controle de concorrncia, poderiam deixar o sistema sempre em estado consistente. Um esquema de controle de concorrncia impe overhead relativo execuo de mais cdigo e possvel atraso nas transaes. Pode ser interessante usar um esquema alternativo que resulte em menor overhead. Uma dificuldade enfrentada para a reduo de overhead que no sabemos a priori quais transaes sero envolvidas em conflito. Para obter essa informao, precisamos de um esquema para a monitorao do sistema. Consideramos que cada transao Ti executada em duas ou trs fases diferentes, dependendo se uma transao somente de leitura ou de atualizao. Essas fases so, em ordem, as seguintes: 1. Fase de leitura. Durante essa fase, a execuo da transao Ti tem incio. Os valores de diversos itens de dados so lidos e armazenados em variveis locais para Ti. Todas as operaes de escrita so processadas com variveis locais temporrias, sem alterar de fato o banco de dados. 2. Fase de validao. A transao Ti processa um teste de validao para determinar se pode copiar no banco de dados as variveis locais temporrias que mantm os resultados das operaes de escrita sem, com isso, causar a violao da serializao. 3. Fase de escrita. Se a transao Ti obtm sucesso na validao (passo 2), ento a atualizao aplicada de fato ao banco de dados. Caso contrrio, Ti desfeita. Cada transao precisa passar pelas trs fases, na ordem mostrada. Entretanto, as trs fases de transaes em execuo concorrentes podem ser intercaladas. 288

As fases de leitura e escrita so autoexplicativas. A nica fase que exige mais explicaes a de validao. Para realizar os testes de validao, precisamos saber quando ocorreram as diversas fases da transao Ti. Precisamos, portanto, associar trs timestamps diferentes para a transao Ti: 1. Start(Ti), o momento em que Ti teve incio. 2. Validation(Ti), o momento em que Ti terminou sua fase de leitura e comeou sua fase de validao. 3. Finish(Ti), o momento em que Ti terminou sua fase de escrita. Determinamos a ordem de serializao pela tcnica de ordenao por timestamp, usando o valor do timestamp da Validation(Ti). Assim, o valor de TS(Ti)=Validation(Ti) e, se TS(Tj)<TS(Tk), ento qualquer escala criada precisa ser equivalente escala serializada na qual a transao Tj aparece antes da transao Tk. A razo para escolhermos Validation(Ti) em vez de Start(Ti) como timestamp da transao Ti que, com isso, podemos esperar menor tempo de resposta, com a condio de que as taxas de conflito entre transaes sejam com certeza pequenas. O teste de validao para Ti exige que, para todas as transaes Ti com TS(Ti)<TS(Tj), uma das duas condies a seguir seja realizada: 1. Finish(Ti)<Start(Ti). J que Ti completa sua execuo antes de Tj comear, a ordem de serializao com certeza mantida. 2. No h interseo entre o conjunto de itens de dados escritos por Ti e o conjunto de dados lidos por Tj, e Ti completa sua fase de escrita antes de Tj comear sua fase de validao (Start(Tj)<Finish(Ti)<Validation(Tj)). Essa condio garante que as escritas de Ti e Tj no sejam sobrepostas. Uma vez que a escrita de Ti no afeta a leitura de Tj e que Tj no pode afetar a leitura de Ti, a ordem de serializao com certeza mantida. Como ilustrao, considere novamente as transaes T14 e T15. Suponha que TS(T14)<TS(T15). Ento, a fase de validao consegue produzir a escala de execuo 5, que apresentada na fig. 14.10. Note que a escrita das variveis reais realizada somente aps a fase de validao de T15. Assim, T14 l valores desatualizados de A e B e essa serializada.

O esquema de validao evita, automaticamente, os rollbacks em cascata, j que as escritas reais acontecem somente depois que a transao que emitiu a solicitao de escrita tenha sido efetivada. Granularidade Mltipla Nos esquemas de concorrncia descritos at agora, estivemos usando cada item de dado individual como uma unidade qual a sincronizao aplicada. H circunstncias, no entanto, em que pode ser vantajoso o agrupamento de diversos itens de dados, tratando-os como uma unidade de sincronizao individual. Por exemplo, se uma transao Ti precisa do acesso a todo o banco de dados e um protocolo de bloqueio usado, Ti precisar bloquear cada um dos itens do banco de dados. Logicamente, esse bloqueio um consumidor de tempo. Seria melhor Ti emitir uma nica solicitao de bloqueio a todo o banco de dados. Por outro lado, se uma transao Tj precisa do acesso a somente alguns itens de dados, no necessrio bloquear todo o banco de dados, porque, desse modo, a concorrncia perdida. preciso um mecanismo que permita ao sistema definir diferentes mltiplos de granulao. Podemos desenvolver um desses mecanismos permitindo diversos tamanhos aos itens de dados e definindo uma hierarquia 289

de granularidade de dados, em que as granulaes menores sejam aninhadas s maiores. Tal hierarquia pode ser representada graficamente como uma rvore. Note que a rvore que descrevemos aqui bastante diferente da usada no protocolo de rvore. O n sem ramificaes de uma rvore de granularidade mltipla representa o dado associado a seus descendentes. No protocolo de rvore, cada n representa um item de dado independente. Como ilustrao, considere a rvore da fig. 14.11, consistindo em ns em quatro nveis. O nvel mais alto representa o banco de dados como um todo. Abaixo, h ns do tipo rea; o banco de dados constitudo exatamente dessas reas. Cada rea, por sua vez, possui ns do tipo arquivo como filhos. Cada rea constituda exatamente daqueles arquivos que so seus ns filhos. Nenhum arquivo est em mais de uma rea. Finalmente, cada arquivo possui ns do tipo registro. Como antes, o arquivo constitudo exatamente daqueles registros que so seus ns filhos, e nenhum registro pode estar em mais de um arquivo.

Cada n de uma rvore pode ter bloqueio individual. Como foi feito no protocolo de bloqueio em duas fases, usaremos os modos de bloqueio exclusivo e compartilhado. Quando uma transao bloqueia um n, tanto no modo compartilhado quanto no exclusivo, a transao tambm bloquear todos os descendentes daquele n no mesmo modo de bloqueio. Por exemplo, se a transao Ti bloqueio de forma explcita o arquivo Fc da fig. 14.11, no modo exclusivo, ento ela est bloqueando de forma implcita, no modo exclusivo, todos os registros pertencentes quele arquivo. Ela no precisar fazer, de forma explcita, o bloqueio individual dos registros de Fc. Suponha que uma transao Tj queira bloquear o registro rb6 do arquivo Fb. Dado que Ti bloqueou Fb de forma explcita, segue que rb6 est tambm bloqueado (de forma implcita). Mas, quando Tj emite uma solicitao de bloqueio para rb6, este no bloqueado de modo explcito! Como o sistema determinar se Tj pode bloquear rb6? Tj precisar percorrer a rvore da raiz at o registro rb6. Se algum modo n do caminho estiver bloqueado de modo incompatvel, ento Tj precisar esperar. Suponha, agora, que a transao Tk deseja bloquear todo o banco de dados. Para isso, ela precisa simplesmente bloquear a raiz hierrquica. Note, entretanto, que Tk no deve conseguir o bloqueio no n raiz, j que Ti j est bloqueado, como acontece com parte da rvore (especificamente, o arquivo Fb). Mas, agora, como o sistema determinar se o n raiz poder ser bloqueado? Uma soluo seria pesquisar a rvore inteira. Essa soluo, entretanto, se antepe ao proposito do esquema do bloqueio de granularidade mltipla. Um meio mais eficiente seria introduzir uma nova classe de modo de bloqueio, chamado modo de bloqueio intencional. Se um n bloqueado no modo intencional, o bloqueio explcito ser feito no nvel mais baixo da rvore (isto , na granularidade mais fina). Bloqueios intencionais sero feitos em todos os antecessores do n antes que aquele n seja bloqueado de forma explcita. Assim, uma transao no precisa pesquisar a rvore inteira para determinar se poder bloquear um n. Uma transao que queira bloquear um n digamos, Q precisa percorrer o caminho, pela rvore, do n at Q. Enquanto se percorre a rvore, os bloqueios das transaes so feitos de modo intencional. H um modo intencional associado ao modo compartilhado e um relacionado ao modo exclusivo. Se um n bloqueado no modo compartilhado-intencional (intention-shared IS), o bloqueio explcito est sendo feito no nvel mais baixo da rvore, mas com somente bloqueios de modo compartilhado. Analogamente, se um n bloqueado no modo exclusivo-intencional (intention-exclusive IX), ento o bloqueio explcito est sendo feito no nvel mais baixo, no modo exclusivo ou compartilhado. Finalmente, se um n est bloqueado nos modos de bloqueio apresentada na fig. 14.12. 290

O protocolo de bloqueio de granularidade mltipla garante a serializao. Cada transao Ti pode bloquear um n Q, usando as seguintes regras: 1. A funo de compatibilidade de bloqueio da fig. 14.12 precisa ser observada. 2. A raiz da rvore precisa ser bloqueada primeiro e pode ser bloqueada em qualquer modo. 3. Um n Q pode ser bloqueado por Ti no modo S ou IS somente se o pai de Q for bloqueado por Ti no modo IX ou IS. 4. Um n Que pode ser bloqueado por Ti no modo X, SIX ou IX somente se o pai de Q estiver bloqueado por Ti no modo IX ou no modo SIX. 5. Ti pode bloquear um n somente se ele no desbloqueou outro n anteriormente (isto , Ti tem duas fases). 6. Ti pode desbloquear um n Que somente se nenhum dos filhos de Que estiver bloqueado por Ti. Observe que o protocolo de granularidade mltipla exige que os bloqueios sejam feitos de cima para baixo (top-down da raiz para as folhas), enquanto a liberao deve ser de baixo para cima (bottom-up das folhas para a raiz). Para ilustrar o protocolo, considere a rvore da fig. 14.11 e as seguintes transaes: Suponha que a transao T18 leia o registro ra2 do arquivo Fa. Ento, T18 precisa bloquear o banco de dados, a rea A1, o arquivo Fa no modo IS (nessa ordem) e, finalmente, bloquear ra2 no modo S. Suponha que a transao T19 altere o registro ra9 do arquivo Fa. Ento, T19 precisa bloquear o banco de dados, a rea A1, o arquivo Fa no modo IX e, finalmente, bloquear ra9 no modo X. Suponha que a transao T20 leia todos os registros do arquivos Fa. Ento, T20 precisa bloquear o banco de dados e a rea A1 (nesse ordem) no modo IS e, finalmente, bloquear Fa no modo S. Suponha que a transao T21 leia todo o banco de dados. Ento, poder faz-lo depois de bloquear o banco de dados no modo S. Podemos notar que as transaes T18, T20, e T21 mantm acesso ao banco de dados concorrentemente. A transao T19 pode concorrer com T18, mas no com T20 nem T21. Esse protocolo aumenta a concorrncia e reduz o overhead por bloqueio. Isso particularmente til em aplicaes que misturam: Transaes curtas que mantm acesso em poucos itens de dados. Transaes longas que produzem relatrios a partir de um arquivo ou de um conjunto de arquivos. H protocolos de bloqueio similares que so aplicados a sistemas de banco de dados nos quais a granularidade organizada na forma de grficos acclicos. Esquemas de Multiverso Os esquemas de controle de concorrncia discutidos at aqui garantem a serializao atrasando a operao ou abortando a transao responsvel por tal operao. Por exemplo, uma operao de read pode ser retratada se o valor apropriado em questo ainda estiver sendo escrito; ou pode ser rejeitada se o valor apropriado em questo ainda estiver sendo escrito; ou pode ser rejeitada (isto , a transao que emitiu tal solicitao deve ser abortada) porque o valor lido j foi alterado. Essas dificuldades podem ser evitadas se o sistema providenciar cpias anteriores de cada item de dado. Em um sistema de banco de dados multiverso, cada operao write(Q) cria uma nova verso de Q. Quando emitida uma operao read(Q), o sistema seleciona uma das verses de Q para ser lida seja tal que 291

assegure a serializao. crucial, por razes de desempenho, que uma transao possa determinar fcil e rapidamente qual verso do item de dados poder ser lido. Multiverso com Ordenao por Timestamp A tcnica mais usada nos esquemas de multiverso o timestamp. A cada transao Ti do sistema associado um timestamp nico e esttico, denotado por TS(Ti). Esse timestamp associado antes do incio da execuo da transao, conforme j descrito. Para cada idem de dado Q, uma sequncia de verses < Q1, Q2, ..., Qm> associada. Cada verso Qk contm trs campos de dados: Content (contedo) o valor da verso Qk. W-timestamp(Qk) o timestamp da transao que criou a verso Qk. R-timestamp(Qk) o timestamp mais alto de alguma transao que tenha lido a verso Qk com sucesso. Uma transao digamos, Ti cria uma nova verso Qk do item de dado Q emitindo uma operao write(Q). O campo contedo da verso mantm o valor escrito por Ti. O W-timestamp e o R-timestamp so inicializados por TS(Ti). O valor de R-timestamp atualizado sempre que uma transao Tj l o contedo de Qk e R-timestamp atualizado sempre que uma transao Tj l o contedo de Qk e R-timestamp(Qk)<TS(Tj). O esquema de multiverso com timestamp apresentado a seguir garante a serializao. O esquema opera da forma descrita a seguir. Suponha que uma transao Ti emita uma operao read(Q) ou write(Q). Seja Qk a verso de Q cujo timestamp de escrita o mais alto timestamp, menor ou igual a TS(Ti). 1. Se a transao Ti emitir uma read(Q), ento o valor recebido ser o contedo da verso Qk. 2. Se a transao Ti emitir um write(Q) e TS(Ti)<R-timestamp(Qk), o contedo de Qk sobreposto; caso contrrio, outra verso de Q criada. A justificativa para a regra 1 clara. Uma transao l a verso mais recente anterior a ela. A segunda regra fora o aborto de uma transao se for tarde demais para que se faa uma escrita. Mais precisamente, se Ti tentar escrever uma verso que alguma outra transao j tenha lido, ento no poderemos permitir que essa escrita seja bem-sucedido. As verses que no forem mais necessrias sero removidas conforme a regra seguinte. Suponha que haja duas verses, QK e Qj, de um item de dados e que ambas as verses tenha o W-timestamp menor que o timestamp da ltima transao do sistema. Ento, a mais antiga entre as verses QK e Qj no ser usada novamente e pode ser eliminada. O esquema multiverso ordenada por timestamp possui a adequada propriedade de garantir que uma solicitao de leitura nunca falhe e nunca espere. Em um sistema de banco de dados tpico, em que as operaes de leitura so mais frequentes que as de escrita, essa vantagem de grande importncia prtica. O esquema, entretanto, possui duas propriedades indesejveis. Primeiro, a leitura de um item de dados exige tambm a atualizao do campo R-timestamp, resultando em dois acessos ao disco, em vez de apenas um. Segundo, os conflitos entre transaes so resolvidos por rollback, em vez da imposio de tempo de espera. Essa alternativa pode ser onerosa. Um algoritmo para amenizar o problema ser descrito na prxima seo. Multiverso com Bloqueio em Duas Fases O protocolo de multiverso com bloqueio em duas fases tenta combinar as vantagens do controle de concorrncia multiverso com as vantagens do bloqueio em duas fases. Esse protocolo diferencia transaes somente de leitura das transaes de atualizao. As transaes de atualizao executam um bloqueio em duas fases rigorosas, isto , elas mantm todos os bloqueios at o final da transao. Assim, podem ser serializadas de acordo com sua ordem de efetivao. Cada item de dado possui um nico timestamp. O timestamp no , nesse caso, baseado no horrio, mas em um contador, que ser chamado de ts_counter, que incrementado durante o processo de efetivao.

292

Marcamos o timestamp das transaes somente de leitura por meio do valor corrente do contador, ou seja, lendo o valor de ts_counter antes de comear sua execuo; para a leitura, elas seguem o protocolo de multiverso ordenada por timestamp. Com isso, quando uma transao Ti desse tipo emite uma read(Q), o valor recebido o contedo da verso cujo timestamp o inferior a TS(Ti) mais prximo. Quando uma transao de atualizao l um item, ela impe um bloqueio compartilhado ao item e l a ltima verso do item. Quando uma transao de atualizao deseja escrever um item, ela primeiro consegue o bloqueio exclusivo desse item e, ento, cria uma nova verso do item de dados. A escrita realizada a partir da nova verso e o timestamp da nova verso recebe como valor inicial, que maior que qualquer outro timestamp possvel. Quando uma transao de atualizao Ti completa suas aes, ela realiza o processo de efetivao da seguinte forma: primeiro, Ti adiciona 1 ao valor de ts_counter e transfere esse valor aos timestamp de todas as verses que criou; ento, Ti adiciona 1 ao ts_counter. Somente uma transao de atualizao por vez pode realizar o processo de efetivao. Como consequncia, as transaes somente de leitura que comearem depois de Ti incrementar o ts_counter acessaro o valor atualizado por Ti, enquanto aquelas que comearem antes do incremento de ts_counter, feito por Ti, vero o valor anterior atualizao de Ti. Nesse caso, as transaes somente de leitura jamais precisaro esperar por bloqueios. As verses so eliminadas de modo similar multiverso com ordenao por timestamp. Suponha que haja duas verses, QK e Qj, de um item de dado e que ambas as verses tenham timestamp menor que o da ltima transao somente de leitura processada no sistema. Logo, a mais antiga entre as duas verses QK e Qj no ser mais usada e pode ser eliminada. A multiverso com bloqueio em duas fases ou variaes so aplicadas a alguns sistemas de banco de dados comerciais. Manuseio do Deadlock Um sistema est em estado de deadlock se h um conjunto de transaes, tal que toda a transao desse conjunto est esperando outra transao tambm nele contida. Mais precisamente, h um conjunto de transaes esperando {T0,T1,...,Tn}, tal que T0 est esperando um item de dado mantido por T1, T1 est esperando um item de dado mantido por T2, ..., Tn-1 est esperando um item de dados mantido por Tn e Tn est esperando por um item de dado mantido por T0. Nenhuma dessas transaes poder prosseguir em uma situao dessas. O nico remdio para essa situao indesejvel uma ao drstica do sistema, como reverter uma das transaes envolvidas no deadlock. H dois mtodos principais para o tratamento do deadlock. Podemos usar o protocolo de preveno de deadlock para garantir que o sistema nunca entrar em tal situao. Ou podemos permitir que o sistema entre em estado de deadlock e, ento, remov-lo dessa situao, recuperando-o por meio dos esquemas de deteco de deadlock e recuperao de deadlock. Como vimos, ambos os mtodos podem acabar por reverter uma transao (rollback). A preveno mais utilizada se a probabilidade do sistema que entrar deadlock for relativamente alta; caso contrrio, a deteco e recuperao so mais eficientes. Note que os esquemas de deteco e recuperao implicam overhead relativo, no somente ao tempo de processamento do sistema para manuteno das informaes necessrias e para a execuo do algoritmo de deteco, mas tambm devido s perdas potenciais inerentes advindas da recuperao de um deadlock. Preveno de Deadlock H duas abordagens para a preveno de deadlock. Uma garante que nenhum ciclo de espera poder ocorrer pela ordenao de solicitaes de bloqueios, ou obrigando que todos os bloqueios sejam obtidos juntos. Outra aproxima-se da recuperao do deadlock, fazendo com que a transao seja refeita, em vez de esperar um bloqueio, sempre que a espera possa potencialmente ocorrer um deadlock.

293

O esquema mais simples sob a primeira abordagem obriga cada transao a bloquear todos os itens de dados antes de sua execuo. Alm disso, ou todos so bloqueados de uma vez ou nenhum o ser. H duas desvantagens nesse protocolo. A premiria, normalmente, a dificuldade em prever, antes da transao comear, quais itens de dados precisaro de bloqueio. Segundo, a utilizao do item de dados pode ser bastante reduzida, j que muitos dos itens de dados podem ser bloqueados e no ser usados pro um longo perodo. Outro esquema de preveno de deadlock feito pela imposio de ordenao parcial de todos os itens de dados e pela obrigao de que a transao bloqueie um item de dado somente na ordem especificada na ordenao parcial. Vimos um desses esquemas no protocolo de rvore. A segunda abordagem para a preveno de deadlock a preempo e o rollback de transaes. Na preempo, quando uma transao T2 solicita um bloqueio que est sendo mantido pela transao T1, o bloqueio concedido a T1 pode ser revisto por meio do rollback de T1, e concedido a T2. Para controle da preempo, consideramos um nico timestamp para cada transao. O sistema usa esses timestamps somente para decidir se a transao pode esperar ou ser revertida. O bloqueio ainda usado para controle de concorrncia. Se uma transao for revertida, ela manter seu timestamp antigo quando for reiniciada. So propostos dois esquemas diferentes de preveno de deadlock usando timestamp: 1. O esquema esperar-morrer (wait-die) tem por base uma tcnica de no-preempo. Quando uma transao Ti solicita um item de dado mantido por Tj, Ti pode esperar somente se possuir um timestamp menor que o de Tj (isto , Ti mais antiga que Tj). Caso contrrio, Ti ser revertida (morta). Por exemplo, suponha que as transaes T22, T23 e T24 tenham timestamps 5, 10 e 15, respectivamente. Se T24 solicita um item de dado mantido por T23, ento T24 ser desfeita. Se T24 solicitar um item de dado mantido por T23, ento T24 esperar. Sempre que as transaes forem revertidas, importante garantir que no haja inanio (starvation) isto , que nenhuma transao seja desfeita continuamente e jamais possa continuar seu processamento. Ambos os esquemas, esperar-morrer e ferir-esperar, evitam a inanio: qualquer que seja o momento, possvel encontrar a transao com menor timestamp. Essa transao no ser revertida em nenhum dos esquemas. Uma vez que os timestamps sempre crescem, e dado que as transaes no recebem dois novos timestamps se foram revertidas, a transao revertida, em determinado momento, ter o menor timestamp. Assim, ela no ser revertida novamente. H entretanto, diferenas significativas entre as formas dos dois esquemas operar. No esquema esperar-morrer, a transao mais antiga precisar esperar at que a mais nova libere seus itens dados. Assim, quanto mais antiga a transao, maior a possibilidade de esperar. Em contraste, no esquema ferir-esperar, a transao mais antiga nunca espera a mais nova. No esquema esperar-morrer, se uma transao Ti morre e desfeita porque solicitou um item de dado preso por uma transao Tj, ento Ti pode reemitir a mesma sequncia de solicitaes quando for reiniciada. Se os itens de dados ainda estiverem presos por Tj, ento Ti morrer novamente. Assim, Ti poder morrer diversas vezes antes de conseguir o item de dados necessrio. Compare essa srie de eventos com o que acontece no esquema ferir-esperar. A transao Ti ser ferida e revertida porque Tj solicitou um item de dados preso por ela. Quando Ti reinicia e solicita o item de dado preso por Tj, Ti esperar. Com isso, deve haver menos reverses do esquema ferir-esperar. O maior problema com ambos os esquemas que podem ocorrer rollbacks desnecessrios. Esquemas com Base em Tempo Esgotado (Timeout) Outro enfoque simples para o tratamento de deadlocks tem por base o tempo esgotado para o bloqueio (lock timeouts). Dessa forma, uma transao que tenha solicitado um bloqueio espera por ele determinado perodo de tempo. Se o bloqueio no for conseguido dentro desse intervalo, dito que o tempo da transao est esgotado, assim ela mesma se reverte e se reinicia. Se de fato estiver ocorrendo um deadlock, uma ou mais transaes nele envolvidas tero seu tempo esgotado e se revertem, permitindo a continuao de outras. Esse 294

esquema pode ser considerado alguma coisa entre preveno de deadlock, dado que o deadlock nunca ocorre, e deteco e recuperao, j discutidas. O esquema de tempo esgotado particularmente fcil de ser implementado, trabalha bem se as transaes forem curtas e longas esperas so frequentemente em funo dos deadlocks. Entretanto, em geral difcil decidir por quanto tempo a transao deve esperar. Esperas muito longas implicam atrasos desnecessrios, dado que esteja ocorrendo um deadlock. Esperas muito curtas resultam em transaes sendo revertidas mesmo sem deadlock, desperdiando recursos. A inanio tambm possvel nesse esquema. Ento ocorre a aplicao limitada do esquema com base em tempo esgotado. Deteco de Deadlock e Recuperao Se um sistema no usa um protocolo resistente ao deadlock, ou seja, que garanta que deadlocks no aconteam, ento um esquema para deteco e recuperao precisa ser aplicado. Um algoritmo que examina o estado do sistema evocado periodicamente para determinar se um deadlock est ocorrendo. Se estiver, ento o sistema precisa tentar recuperar-se. Para isso, ele precisa: Manter informaes sobre a alocao corrente dos itens de dados para transaes, assim como qualquer solicitao de itens de dados pendente. Proporcionar um algoritmo que use essas informaes para determinar se o sistema entrou em estado de deadlock. Recuperar-se de um deadlock quando o algoritmo de deteco determinar que ele ocorreu. Deteco de Deadlock Os deadlocks podem ser precisamente descritos em, termos de um grfico chamado grfico de espera. Esse grfico consiste em um par G=(V,E), em que V um conjunto de vrtices e E, um conjunto de arestas. O conjunto de vrtices consiste em todas as transaes do sistema. Cada elemento do conjunto E de arestas um par ordenado Ti Tj. Se Ti Tj est em E, ento o sentido da aresta, da transao Ti para Tj, implica que a transao Ti est esperando que a transao Tj libere o item de dado de que ela precisa. Quando a transao Ti solicita um item de dado que est preso pela transao Tj, ento a aresta Ti Tj inserida no grfico de espera. Essa aresta removida somente quando a transao Tj no estiver mais esperando um item de dado necessrio transao Ti. H um deadlock no sistema se, e somente se, o grfico de espera contiver um ciclo. Cada transao envolvida em um ciclo est em deadlock. Para detectar deadlocks, o sistema precisa manter o grfico de espera e, periodicamente, evocar um algoritmo que verifique a existncia de ciclos. Para ilustrar esses conceitos, considere o grfico de espera da fig. 14.13, que exibe a seguinte situao: A transao T25 est esperando as transaes T26 e T27. A transao T27 est esperando a transao T26. A transao T26 est esperando a transao T28.

Uma vez que no h ciclos, o sistema no est em estado de deadlock. Suponha agora que a transao T28 esteja solicitando um item preso por T27. A aresta T28 T27 ser adicionada ao grfico de espera, alterando o estado do sistema, como mostrado na fig. 14.14. A essa altura, o grfico contm o ciclo: implicando que as transaes T26, T27 e T28 esto todas em deadlock. 295

Consequentemente, impe-se a questo: quando evocaremos o algoritmo de deteco ser evocado com mais frequncia que o usual. Os itens de dados alocados nas transaes em deadlock no estaro disponveis para outras transaes at que o deadlock seja resolvido. Alm disso, o nmero de ciclos no grfico pode crescer tambm. Na pior das hipteses, evocaramos o algoritmo de deteco sempre que uma solicitao de alocao no puder ser atendida imediatamente. Recuperao aps um Deadlock Quando um algoritmo de deteco determina a existncia de um deadlock, o sistema precisa recuperarse desse deadlock. A soluo mais comum reverter uma ou mais transao para quebrar o deadlock. Devem ser tomadas trs aes: 1. Selecionar uma vtima. Dado um conjunto de transaes em deadlock, precisamos determinar quais transaes (ou transao) sero desfeitas para quebrar o deadlock. Poderamos reverter as transaes que representam o menor custo. Infelizmente, o termo mnimo custo no preciso. Muitos fatores podem determinar o custo de um rollback, incluindo: a. A quanto tempo a transao est em processamento e quanto tempo ser ainda necessrio para que a tarefa seja completada. b. Quantos itens de dados a transao usou. c. Quantos itens ainda a transao usar at que se complete. d. Quantas transaes sero envolvidas no rollback. 2. Rollback. Uma vez decidido que uma transao em particular ser revertida, precisamos determinar at que ponto ela dever ser revertida. A soluo mais simples revert-la totalmente: abort-la para depois reinici-la. Entretanto, mais eficaz reverter a transao somente o suficiente para a quebra do deadlock. Mas esse mtodo exige que o sistema mantenha informaes adicionais sobre o estado de todas as transaes em execuo. 3. Inanio. Em um sistema no qual a seleo de vtimas tem por base fatores de custo, pode acontecer de uma mesma transao ser sempre escolhida vtima. Assim, essa transao nunca se completa. Essa situao chamada de inanio. Precisamos garantir que uma transao seja escolhida vtima somente um nmero finito (pequeno) de vezes. A soluo mais comum incluir o nmero de reverso no fator de custos. Operaes de Insero e Remoo At agora restringimos nossa ateno a operaes read e write. Essas restries limita a ao das transaes sobre os itens de dados existentes no banco de dados. Algumas transaes precisam no somente de acesso a itens de dados existentes, mas tambm da capacidade de criar novos itens de dados. Outras precisam remover itens de dados. Para examinar como tais transaes afetam o controle de concorrncia, introduzimos as seguintes operaes adicionais: delete(Q) remove o item de dados Q do banco de dados. insert(Q) insere um novo item de dados Q em um banco de dados e designa um valor inicial para ele. Uma transao Ti que queira operar uma read(Q) depois da remoo de Q resulta em erro lgico em Ti. Analogamente, se uma transao Ti quiser realizar uma operao de read(Q) antes da insero de Q, tambm haver erro lgico em Ti. Tambm ser um erro lgico tentar remover um item de dados inexistente. 296

Remoo Para entender como uma instruo de remoo (delete) afeta o controle de concorrncia, precisamos definir quando ela entra em conflito com outra instruo. Seja Ii e Ij instrues de Ti e Tj, respectivamente, que aparecem nessa ordem na escala de execuo S. Seja Ii= delete(Q). Consideremos as seguintes instrues Ij. Ij = read(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou antes de Ii, Tj poder executar a operao read com sucesso. Ij = write(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou antes de Ii, Tj poder executar a operao write com sucesso. Ij = delete(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou antes de Ii, Ti incorrer em erro lgico. Ij = insert(Q). Ii e Ij entram em conflito. Suponha que o item de dado Q no exista antes da execuo de Ii e Ij. Ento, se Ii comeou antes de Ij, ocorrer erro lgico em Ti. Se Ij comeou antes de Ii no ocorrer nenhum erro lgico. Da mesma forma, se Q existir antes da execuo de Ii e Ij, poder ocorrer erro lgico se Ij comeou antes de Ii, caso contrrio no. Podemos concluir que, se o bloqueio em duas fases for usado, preciso um bloqueio exclusivo sobre o item de dados antes que ele possa ser removido. Sob o protocolo de ordenao por timestamp, um teste que ele possa ser removido. Sob o protocolo de ordenao por timestamp, um teste similar ao indicado para a write precisar ser realizado. Suponha que a transao Ti emita um delete(Q). Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti removeu j havia sido lido pela transao Tj com TS(Tj)>TS(Ti). Ento, a operao delete ser rejeitada e Ti ser revertida. Se TS(Ti)<W-timestamp(Q), ento uma transao Tj com TS(Ti)>TS(Tj) j gravou Q. Com isso, essa operao delete ser rejeitada e Ti ser desfeita. De outro modo a operao delete ser executada. Insero Vimos que uma operao insert(Q) entra em conflito com uma operao delete(Q). Analogamente, insert(Q) entra em conflito com uma operao read(Q) ou uma operao write(Q). nenhuma read ou write pode ser realizada sobre um item de dados antes que ele exista. Uma vez que insert(Q) estabelea um valor para o item de dado Q, a insert tratada de modo similar write para efeito de controle de concorrncia: Sob o protocolo de bloqueio em duas fases, se Ti realizar uma operao insert(Q), Ti estar impondo um bloqueio exclusivo para o novo item de dado Q criado. Sob o protocolo de ordenao por timestamp, se Ti realizar uma operao insert(Q), os valores de Rtimestamp(Q) e W-timestamp(Q) sero registros em TS(Ti). O Fenmeno do Fantasma Considere a transao T29 que executa a consulta SQL a seguir:

A transao T29 obriga o acesso a todas as tuplas da relao conta pertencentes a agncia Perryridge. Seja T30 uma transao que executa a seguinte insero SQL:

Seja S uma escala de execuo envolvendo T29 e T30. Esperamos um conflito em potencial pelas seguintes razes: Se T29 usar a tupla recentemente inserida por T30 para calcular sum(saldo), ento T29 ler o valor inserido por T30. Assim, em uma escala de execuo serializada equivalente a S, T30 deve comear antes de T29. 297

Se T29 no usar a tupla recentemente inserida por T30 para calcular sum(saldo) em uma escala de execuo serializada equivalente a S, T29 deve comear antes de T30. O segundo caso curioso. T29 e T30 no acessam a nenhum tupla em comum, ainda assim entram em conflito. Com efeito, T29 e T30 entram em conflito com uma tupla fantasma. Assim, o fenmeno que acabamos de descrever chamado de fenmeno do fantasma. Se o controle de concorrncia feito com granularidade de tupla, esse conflito pode no ser detectado. Para prevenir esse fenmeno, fazemos com que T29 evite que outras transaes criem novas tuplas na relao conta com nome_agncia= Perryridge. Para encontrar todas as tuplas de conta com nome_agncia = Perryridge, T29 precisa pesquisar toda a relao conta, ou ao menos um ndice na relao. At agora, consideramos de modo implcito que os itens de dados aos quais a transao mantm acesso sejam somente tuplas. Entretanto, T29 um exemplo de transao que procura a informao de quantas tuplas h na relao e T30 exemplifica uma transao que atualiza essa informao. lgico que no suficiente bloquear as tuplas que sofrem acesso; o bloqueio tambm necessrio para informaes sobre os quais tuplas esto na relao. A soluo mais simples para esse problema seria associar um item de dado prpria relao. Transaes, como a T29, que leem informaes acerca de quais tuplas esto na relao deveriam, ento, bloquear no modo compartilhado o item de dado correspondente relao conta. Transao, com a T30, que atualizam as informaes acerca de quais tuplas esto na relao deveriam bloquear o item de dado no modo exclusivo. Desse modo, T29 e T30 entram em conflito devido a itens de dados reais, e no fantasmas. No confunda o bloqueio de uma relao inteira, como no bloqueio de granularidade mltipla, com o bloqueio de um item de dado correspondente relao. Por meio do bloqueio do item de dado, uma transao impede somente que outras transaes alterem informaes sobre as tuplas que pertencem relao. O bloqueio das tuplas ainda necessrio. As transaes que mantm acesso direto a uma tupla podem conseguir o bloqueio de uma tupla mesmo que outra transao tenha bloqueio exclusivo sobre um item de dado correspondente quela transao propriamente dita. A maior desvantagem do bloqueio de um item de dado correspondente a uma relao o baixo grau de concorrncia duas transaes que inserem tuplas diferentes em uma relao no podem ser concorrentes. Uma soluo melhor a tcnica do bloqueio de ndices. Qualquer transao que inserir uma tupla em uma relao deve inserir informaes em todos os ndices mantidos pela relao. Eliminamos o fenmeno do fantasma por meio da imposio de um protocolo de bloqueios para os ndices. Todo valor da chave de pesquisa est associado a um registro do ndice ou a um bucket. Uma consulta, normalmente, usar um ou mais ndices para o acesso relao. Uma consulta, normalmente, usar um ou mais ndices para o acesso relao. Uma insero precisar introduzir uma nova tupla em todos os ndices de uma relao. Em nosso exemplo, assumimos que h um ndice em conta para nome_agncia. Logo, T30 precisa modificar o bucket de Perryridge. Se T29 l o bucket de Perryridge para localizar todas as tuplas pertencentes agncia Perryridge, ento T29 e T30 entraro em conflito naquele bucket. O protocolo de bloqueio de ndices possui a vantagem de criar ndices sobre uma relao por meio da troca de instncias do fenmeno de fantasmas por conflito de bloqueios em ndices bucket. O protocolo opera da seguinte forma: Toda relao precisa ter ao menos um ndice. Uma transao Ti pode bloquear em modo S uma tupla ti de uma relao somente se ela possui um bloqueio modo S sobre o ndice bucket que contm um ponteiro para ti. Uma transao Ti pode bloquear em modo X uma tupla ti de uma relao somente se ela possui um bloqueio modo X sobre o ndice bucket que contm um ponteiro para ti. Uma transao Ti no pode inserir uma tupla ti em uma relao r sem atualizar todos os ndices de r. Ti precisa obter um bloqueio modo X sobre todos os ndices bucket que ela modifica. preciso observar as regras do protocolo de bloqueio em duas fases. 298

H variante da tcnica de bloqueio de ndices para a eliminao do fenmeno do fantasma em outros protocolos de controle de concorrncia j apresentados. Concorrncia em Estruturas de ndices possvel tratar do acesso s estruturas de ndices como qualquer outra estrutura de um banco de dados e aplicar as tcnicas de controle de concorrncia discutidas anteriormente. Entretanto, uma vez que os ndices tm acesso frequente, eles se tornam ponto de grande conteno de bloqueios, originando um baixo nvel de concorrncia. Felizmente, os ndices no tem de receber o mesmo tipo de tratamento das demais estruturas do banco de dados, j que no proporcionam um alto nvel de abstrao para o mapeamento de chaves de pesquisa de tuplas do banco de dados. perfeitamente aceitvel que uma transao verifique um ndice duas vezes e perceba que essa estrutura de ndice foi alterada nesse meio tempo, contanto que o ndice aponte um conjunto correto de tuplas. Assim, aceitvel manter acesso concorrente no-seriado em um ndice, contanto que a preciso do ndice seja mantida. Mostramos a tcnica para o gerenciamento de acessos concorrentes em rvores-B+. As tcnicas que apresentamos para rvores-B+ tm por base o bloqueio, mas nem o bloqueio em duas fases nem o protocolo de rvore so empregados.

299

Sistema de Recuperao Um sistema de computador, como qualquer outro equipamento mecnico ou eltrico, est sujeito a falhas. H grande variedade de falhas, incluindo quebra de disco, falha de energia, erro de software, fogo na sala de equipamento ou mesmo sabotagem. Em cada um desses casos, informaes podem ser perdidas. Portanto, o sistema de banco de dados deve precaver-se para garantir que as propriedades de atomicidade e durabilidade das transaes sejam preservadas, a despeito de tais falhas. Uma parte integrante de um sistema de banco de dados o esquema de recuperao que responsvel pela restaurao do banco de dados para um estado consistente que havia antes da ocorrncia da falha. Classificao de Falha Vrios tipos de falhas podem ocorrer em um sistema, cada um dos quais exigindo um tratamento diferente. O tipo de falha mais simples de tratar aquele que no resulta na perda de informao no sistema. As falhas mais difceis de tratar so aquelas que resulta em perda de informao. Vamos considerar somente os seguintes tipos de falha: Falha de transao. Dois tipos de erros podem causar uma falha de transao: o Erro lgico. A transao no pode mais continuar com sua execuo normal devido a alguma condio interna, como uma entrada inadequada, um dado encontrado, overflow ou limite de recurso excedido. o Erro de sistema. O sistema entrou em um estado inadequado (por exemplo, deadlock), com isso, uma transao no pode continuar com sua execuo normal. A transao, entretanto, pode ser reexecutada posteriormente. Queda do sistema. H algum mau funcionamento de hardware ou um bug no software de banco de dados ou no sistema operacional que causou a perda do contedo no armazenamento voltil e fez o processamento da transao parar. O contedo de armazenamento no-voltil permanece intato e no corrompido. A condio originada por erros de hardware e bugs no software que fazem o sistema parar, mas no corrompem o contedo do armazenamento no-voltil, conhecida como condio falhar-parar. Sistemas bem projetados tm numerosas verificaes internas em nvel de hardware e software que fazem o sistema parar quando h um erro. Consequentemente, a condio falhar-parar uma condio razovel. Falha de disco. Um bloco de disco perde seu contedo em funo da quebra do cabeote ou da falha durante uma operao de transferncia de dados. So usadas, para recuperao do sistema aps a falha, as cpias dos dados em outros discos ou backups de arquivos em meios tercirios, como fitas. Para determinar como o sistema deve recuperar-se das falhas, necessitamos identificar os modos de falha possveis dos equipamentos usados para armazenar dados. Depois, devemos considerar como esses modos de falha afetam o contedo do banco de dados. Ento, poderemos desenvolver algoritmos para assegurar a consistncia do banco de dados e a atomicidade da transao, a despeito das falhas. Esses algoritmos so conhecidos como algoritmos de recuperao, embora tenham duas partes: 1. Aes tomadas durante o processamento normal da transao a fim de garantir que haja informao suficiente para permitir a recuperao de falhas. 2. Aes tomadas em seguida falha, recuperando o contedo do banco de dados para um estado que assegure sua consistncia, a atomicidade da transao e durabilidade. Estrutura de Armazenamento Os vrios itens do banco de dados podem ser armazenados e sofre acesos em diferentes meios de armazenamento. Para compreender como garantir propriedades de atomicidade e durabilidade de uma transao, devemos compreender melhor como funcionam esses meios de armazenamento e seus mtodos de acesso.

300

Tipos de Armazenamento H vrios tipos de meios de armazenamento; eles so distinguidos por sua velocidade relativa, capacidade e resistncia falha. Armazenamento voltil. A informao residente em armazenamento voltil usualmente no sobrevive a quedas no sistema. Exemplos de tal armazenamento so MP e memria cache. O acesso armazenagem voltil extremamente rpido, tanto devido velocidade de acesso da memria em si quanto ao acesso direto a qualquer item de dado possvel no armazenamento voltil. Armazenamento no-voltil. A informao residente em armazenamento no-voltil sobrevive a quedas de sistema. Exemplos de tal armazenamento so o disco e fitas magnticas. Os discos so usados para armazenamento online, ao passo que as fitas so usadas para armazenamento de arquivo. Entretanto, ambos esto sujeitos falha (por exemplo, quebra de cabeote), que pode resultar em perda de informao. No atual estado da tecnologia, o armazenamento no-voltil mais lento que o armazenamento voltil por muitas ordens de magnitude. Essa distino ocorre porque discos e fitas so equipamentos eletromecnicos, em vez de inteiramente baseados em chips, como o armazenamento voltil. Outros meios no-volteis so usados, normalmente apenas no backup de dados. Armazenamento estvel. A informao residente em armazenamento estvel nunca perdida (nunca entendida aqui como uma agulha no palheiro, j que teoricamente nunca no pode ser garantido por exemplo, possvel, embora extremamente improvvel, que um buraco negro engula a Terra e destrua permanentemente todos os dados!). Embora o armazenamento estvel seja teoricamente impossvel de obter, pode-se chegar perto dele usando tcnicas que torna extremamente improvvel a perda de dados. Frequentemente, as distines entre os vrios tipos de armazenamento so menos claras na prtica que em nossa apresentao. Certos sistemas fornecem backup de bateria, de forma que parte da MP pode resistir a quedas de sistema e falhas de energia. Formas alternativas de armazenamento no-voltil, como meio tico, fornecem maior grau de confiabilidade que os discos. Implementao do Armazenamento Estvel Para implementar o armazenamento estvel, temos de replicar a informao em vrios meios de armazenamento ano-volteis (usualmente discos), como modos possveis de falha independentes, e controlar a atualizao das informaes, garantindo que uma eventual falha durante a transferncia de dados no danifique as informaes. Os sistemas RAID garantem que a falha de um nico disco (mesmo durante a transferncia de dados) no resulte em perda de dados. A forma mais simples e mais rpida de RAID o disco espelhado, que mantm duas cpias de cada bloco em discos separados. Outras formas de RAID oferecem custos menores, mas com menor desempenho. Os sistemas RAID, entretanto, no podem se proteger contra perda de dados devido a desastres como incndios ou enchentes. Muitos sistemas armazenam backups em fitas e diferentes locais para proteger-se contra tais desastres. Entretanto, j que as fitas no podem ser transportadas continuamente, as atualizaes ocorridas entre o desastre e o ltimo backup podem ser perdidas. Sistemas mais seguros mantm uma cpia de cada bloco de armazenamento estvel em um site remoto, enviando-a por uma rede de computadores, alm de armazenar o bloco em um sistema de disco local. J que os blocos so enviados ao sistema remoto, como e quando so enviados para o armazenamento local, uma vez completada a operao de sada, essa sada no perdida, mesmo na ocorrncia de um desastre, como um incndio ou uma enchente. Vamos discutir como o meio de armazenamento pode ser protegido de uma falha durante a transferncia de dados. A transferncia de blocos entre a memria e o armazenamento de disco pode resultar em: Concluso bem-sucedida. A informao transferida chegou de forma segura ao seu destino. Falha parcial. Uma falha ocorreu no meio de transferncia e o bloco de destino contm informao incorreta. 301

Falha total. A falha ocorreu cedo o suficiente, de modo que o bloco de destino permanece intato. Exigimos que, se uma falha na transferncia de dados ocorrer, o sistema a detecte e chama um procedimento de recuperao para restabelecer o bloco, levando-o a um estado consistente. Para isso, o sistema deve manter dois blocos fsicos para cada bloco lgico do banco de dados; no caso de discos espelhados, ambos os blocos ento no mesmo local; no caso de backup remoto, um dos blocos local, enquanto o outro est em um site remoto. Uma operao de sada executa como segue: 1. Escreve a informao dentro do primeiro bloco fsico. 2. Quando a primeira escrita se completar com sucesso, escreve a mesma informao no segundo bloco fsico. 3. A sada completada somente aps a segunda escrita completar-se com sucesso. Durante a recuperao, cada par de blocos fsico examinado. Se ambos so iguais e no h erro detectvel, ento nenhuma ao adicional necessria. Se um bloco contm um erro detectvel, ento trocamos seu contedo pelo contedo do segundo bloco. Se ambos os blocos no contm erros detectveis, mas diferem em contedo, ento trocamos o contedo do primeiro bloco pelo valor do segundo. Esse procedimento de recuperao assegura que uma escrita em armazenamento estvel seja bem-sucedida (isto , atualize todas as cpias), ou no resulte em mudana alguma. Exigir a comparao entre cada par de blocos correspondentes durante a recuperao custoso. Podemos reduzir consideravelmente o custo mantendo uma varredura de escritas de bloco que esto em progresso, usando uma pequena quantidade de RAM no-voltil. Os protocolos para escrita de um bloco em um site remoto so similares aos protocolos para escrita de blocos em sistema de disco espelhado. Podemos facilmente expandir esse procedimento para que permita o uso de um nmero arbitrariamente grande de cpias de cada bloco de armazenamento estvel. Embora o uso de um nmero grande de cpias reduza a probabilidade de uma falha para muitos menos que quando se usam duas cpias, em geral suficiente simular o armazenamento estvel somente com duas cpias. Acesso de dados O sistema de banco de dados reside permanentemente em armazenamento no-voltil (usualmente discos) e particionado em unidades de armazenamento de comprimento fixo chamadas de blocos. Os blocos so unidades de transferncia de dados para e a partir do disco e podem conter vrios itens de dados. Assumimos que nenhum item de dado abrange dois ou mais blocos. Essa premissa verdadeira para a maioria das aplicaes de processamento de dados, como em nosso exemplo bancrio. As transaes transferem informaes do disco para a MP e, ento, reenviam essas informaes de volta para o disco. As operaes de entrada e sada (entrar e sair da memria) so feitas em unidades de bloco. Os blocos residentes no disco so chamados de blocos fsicos; os blocos residentes temporariamente na MP so chamados de blocos de buffer. A rea de memria na qual os blocos residem temporariamente chamada de buffer de disco. Movimentos de bloco entre disco e memria principal so iniciados por meio de duas operaes seguintes: 1. input(B) transfere o bloco fsico B para a MP. 2. output(B) transfere o bloco de buffer B para o disco e troca-o, no disco, pelo fsico apropriado. Esse esquema ilustrado na fig. 15.1.

302

Cada transao Ti tem uma rea de trabalho privada na qual cpias de todos os itens de dados acessados e atualizados so mantidas. Essa rea de trabalho criada quando a transao iniciada; ele removida quando a transao iniciada; ela removida quando a transao efetivada ou abortada. Cada item de dados x mantido na rea de trabalho da transao Ti denotado por xi. A transao Ti interage com o sistema de banco de dados pela transferncia de dados para e de sua rea de trabalho at o buffer de sistema. Transferimos os dados usando as duas operaes a seguir: 1. read(X) designa o valor do item de dado X para a varivel local xi. Essa operao executada como segue: a. Se o bloco Bx no qual reside X no est na memria principal, ento emitido um input(Bx). b. Designa a xi o valor de X a partir do bloco de buffer. 2. write(X) designa o valor da varivel local xi para o item de dado X no bloco de buffer. Essa operao executada como segue: a. Se o bloco Bx no qual reside X no est na memria principal, ento emite um input(Bx). b. Designa o valor de xi para X no buffer Bx. Observe que ambas as operaes podem exigir a transferncia de um bloco do disco para a MP. Entretanto, elas no exigem a transferncia de um bloco da MP para o disco. O bloco de buffer ser eventualmente escrito no disco se o gerenciador de buffer necessitar de espao em memria para outros propsitos ou porque o sistema de banco de dados deseja refletir a mudana em B sobre o disco. Dizemos que o sistema de banco de dados fora sadas do buffer B se ele emite um output(B). Quando uma transao necessita do acesso a um item de dado X pela primeira vez, ela deve executar read(X). Todas as atualizaes de X so, ento, realizadas sobre xi. Aps o ltimo acesso X feito pela transao, ela executar um write(X) para refletir a mudana em X no banco de dados propriamente dito. A operao output(Bx) para o buffer de bloco Bx em que X reside no precisa ter efeito imediato aps a execuo do write(X), j que o bloco Bx pode conter outros itens de dados que ainda esto sendo acessados. Ento, a sada real aparecer mais tarde. Observe que, se o sistema cair aps a operao write(X) ter sido executada, mas antes do output(Bx), o novo valor de X nunca ser escrito no disco e, portanto, perdido. Recuperao e Atomicidade Considere novamente nosso sistema bancrio simplificado e a transao Ti transfere 50 dlares da conta A para a conta B, com valores iniciais de A e B sendo mil e dois mil dlares, respectivamente. Suponha que uma queda de sistema tenha ocorrido durante a execuo de Ti, aps output(BA), mas antes do output(BB), em que BA e BB denotam os blocos de buffer em que A e B residem. J que os contedos de memria foram perdidos, no sabemos o destino da transao; ento, poderamos chamar um dos dois possveis procedimentos de recuperao: Reexecutar Ti. Este faz com que o valor de A torne-se 900 dlares, em vez de 950 dlares. Ento, o sistema entra em um estado inconsistente. No reexecutar Ti. No estado corrente do sistema, os valores A e B so de 950 e 2000 dlares, respectivamente. Ento, o sistema entra em um estado inconsistente. Em ambos os casos, o banco de dados deixado em estado inconsistente, logo esse esquema de recuperao simples no funciona. Essa dificuldade ocorre porque modificamos o banco de dados sem ter certeza de que a 303

transao ser efetivada de fato. Entretanto, se Ti realizou diversas modificaes no banco de dados, podem ser necessrias vrias operaes de sada e pode ocorrer uma falha aps algumas dessas modificaes terem sido feitas, mas antes de todas serem realizadas. Para atingir nosso objetivo de atomicidade, primeiro devemos mandar informaes que descrevam essas modificaes para um armazenamento estvel, sem modificar o banco de dados em si. Como veremos, esse procedimento nos permitir enviar todas as modificaes feitas por uma transao efetivada, apesar de possveis falhas. H duas maneiras de realizar tais sadas. Vamos assumir que as transaes so executadas serialmente, isto , somente uma nica transao est ativa de cada vez. Recuperao Baseada em Log A estrutura mais usada para gravar modificaes no banco de dados o log (dirio). O log uma sequncia de registros de log que mantm um arquivo atualizado das atividades no banco de dados. H vrios tipos de registros de log que mantm um arquivo atualizado das atividades no banco de dados. H vrios tipos de registro de log. Um registro de atualizao de log descreve uma nica escrita do banco de dados e tem os seguintes campos: Identificador de transao um identificador nico da transao que realiza operao de escrita (write). Identificao de item de dado um identificador nico do item de dado escrito. Normalmente, a localizao do item de dado no disco. Valor antigo o valor do item de dado anterior escrita. Valor novo o valor que o item de dado ter aps a escrita. H outros registros de log para arquivar eventos significativos durante o processamento de transao, como o incio da transao, sua efetivao ou aborto. Indicamos os vrios tipos de registros de log como seguem: <Ti start>. A transao Ti comeou. <Ti, Xj, V1, V2>. A transao Ti foi efetivada. <Ti abort>. A transao Ti foi abortada. Sempre que uma transao realiza uma escrita, essencial que o registro de log para aquela escrita seja criado antes do banco de dados ser modificado. Havendo o registro de log, podemos enviar a modificao ao banco de dados quando ela for conveniente. Tambm conseguiremos inutilizar (undo) uma modificao que j tenha sido enviada ao banco de dados. Podemos desfaz-la usando o campo de valor antigo do registro de log. Para que os registros de log sejam teis na recuperao aps falhas de sistema e disco, o log deve residir em armazenamento estvel. Por enquanto, assumiremos que todo registro de log ser escrito no final do arquivo de log em armazenamento estvel, to logo seja criado. Veremos quando seguro afrouxar essa exigncia para reduzir o overhead imposto ao registro em log. Introduziremos tambm duas tcnicas de uso de log para garantir atomicidade de transaes apesar das falhas. Repare que o log contm um registro completo de toda atividade do banco de dados. Com isso, o volumo de dados armazenado no log pode tornar-se absurdamente grande. Mostraremos quando seguro apagar informaes de log. Modificaes adiadas do banco de dados A tcnica de adiar modificaes garante a atomicidade de transaes quando todas as modificaes do banco de dados so escritas no log, adiando a execuo de todas as operaes write de uma transao at sua efetivao parcial. Lembre-se de que uma transao considerada parcialmente efetivada quando a ltima ao da transao tiver sido executada. A verso da tcnica de modificao que descrevemos aqui pressupe que as transaes sejam executadas serialmente. Quando uma transao parcialmente efetivada, as informaes no log associadas quela transao so usadas para a execuo das escritas adiadas. Se o sistema cair antes de completar a transao ou se a transao for abortada, ento as informaes do log sero simplesmente ignoradas.

304

A execuo da transao Ti funciona como segue. Um registro <Ti start> escrito no log antes de Ti ter incio. Uma operao write(X) feita por Ti resulta na escrita de um novo registro no log. Finalmente, quando Ti parcialmente efetivada, um registro <Ti commit> escrito no log. Quando uma transao Ti parcialmente efetivada, os registros no log a ela associados so usados para execuo das escritas adiadas. Como uma falha pode ocorrer enquanto essa execuo est em andamento, devemos ter certeza, antes de comea-la, de que todos os registros de log estejam escritos em armazenamento estvel. Uma vez escritas, as atualizaes reais podem ocorrer de fato e a transao entra no estado de efetivao. Observe que somente o novo valor do item de dado necessrio para a tcnica de modificao adiada. Logo, podemos simplificar a estrutura geral do registro de atualizao do log, que vimos anteriormente, por meio da omisso do campo de valor antigo. Para ilustrao, reconsidere nosso exemplo de sistema bancrio simplificado. Seja T0 uma transao que transfere 50 dlares da conta A para a conta B. Essa transao definida como segue:

Seja T1 uma transao que debita cem dlares da conta C. Essa transao definida como:

Suponha que essas transaes sejam executadas serialmente, T0 seguida por Ti e os valores das contas A, B e C antes da execuo, eram de 1000, 2000 e 700 dlares, respectivamente. A poro do log contendo as informaes relevantes sobre essas duas transaes apresentada 15.2.

Como resultado da execuo de T0 e T1, h vrias ordens possveis em que as sadas reais podem ocorrer, tanto para o sistema de banco de dados como para o log. Tal ordem apresentada na fig. 15.3. Note que o valor de A alterado somente aps o registro <T0, A, 950> ter sido colocado no log.

Usando o log, o sistema pode lidar com qualquer falha que resulte em perda de informao no armazenamento voltil. O esquema de recuperao usa o seguinte procedimento: redo(Ti) define o valor de todos os itens de dados atualizados pela transao Ti para os novos valores. O conjunto de itens de dados atualizados por Ti e seus respectivos novos valores podem ser encontrados no log. 305

A operao redo (refazer) deve ser idempotente, isto , execut-la vrias vezes deve ser equivalente a execut-la uma vez s. Essa caracterstica exigida se formos garantir comportamento correto, mesmo que uma falha ocorra durante o processo de recuperao. Aps a ocorrncia de uma falha, o subsistema de recuperao consulta o log para determinar quais transaes tm de ser refeitas. A transao Ti dever ser refeita se, e somente se, o log contiver os registros <Ti start> e <Ti commit>. Assim, se o sistema cair depois que a transao completar sua execuo, as informaes no log sero usadas na restaurao do sistema para o estado consistente anterior. Como ilustrao, retornemos a nosso exemplo bancrio com as transaes T0 e T1 executadas uma aps a outra, T0 seguida por T1. A figura 15.2 mostra o log resultante da execuo completa de T0 e T1. Suponhamos que o sistema caia antes que as transaes terminem, de forma que possamos ver como a tcnica de recuperao restabelece o banco de dados para um estado consistente. Assuma que a queda logo aps o registro de log do passo write (B) da transao T0 ter sido escrito em armazenamento estvel. O log, no momento da queda, mostrado na fig. 15.4a. Quando o sistema retorna, nenhuma ao refazer tem de ser tomada, j que nenhum registro de efetivao aparece no log. Os valores das contas A e B permanecem mil e dois mil dlares, respectivamente. Os registros de log da transao incompleta T0 podem ser removidos do log.

Agora, assumamos que a queda venha logo aps o registro de log para o passo write(C) da transao T1 ter sido escrito em armazenamento estvel. Nesse caso, o log, no momento da queda, est como na fig. 15.4. Quando o sistema retorna, a operao redo (T0) realizada, j que o registro <T0 commit> aparece no log em disco. Aps essa operao, os valores das contas A e B so 950 e 2050 dlares, respectivamente. O valor da conta C permanece 700 dlares. Como antes, os registros de log da transao incompleta T1 podem ser removidos do log. Por ltimo, assumamos que uma queda ocorra logo aps o registro de log <T1 commit> ser escrito em armazenamento estvel. O log, no momento dessa queda, est como mostra a fig. 15.4c. Quando o sistema retorna, dois registros de efetivao esto no log: um para T0 e um para T1. Portanto, as operaes redo(T0) e redo(T1) devem ser processadas. Aps essas operaes, os valores das contas A, B e C so, respectivamente, 950, 2050 e 600 dlares. Finalmente, consideremos o caso em que uma segunda queda de sistema ocorre durante a recuperao da primeira queda. Algumas mudanas devem ter sido feitas no banco de dados como resultado das operaes redo, mas pode ser que nem todas as alteraes tenham ocorrido. Quando o sistema retornar da segunda queda, a recuperao se dar exatamente como nos exemplos anteriores. Para cada registro de efetivao <Ti commit> encontrado no log, a operao redo(Ti) ser processada. Em outras palavras, as aes de recuperao so reinicializadas a partir do comeo. J que redo escreve valores no banco de dados independente de seus valores correntes, o resultado de uma segunda tentativa de redo ser igual ao alcanado caso o redo seja bem-sucedido j na primeiro vez. Modificao Imediata de Banco de Dados A tcnica de atualizao imediata permite que as modificaes no banco de dados sejam enviadas enquanto as transaes ainda esto no estado ativo. As escritas emitidas por transaes ativas so chamadas de modificaes no-efetivadas. Na ocorrncia de uma queda ou de uma falha de transao, o sistema dever usar o campo relativo ao valor antigo dos registros de log para restaurao dos itens de dados modificados, levando-os 306

ao valor anterior ao incio da transao. Essa restaurao conseguida por meio da operao undo (desfazer) descrita a seguir. Antes que uma transao Ti inicie sua execuo, o registro <Ti start> escrito no log. Durante sua execuo, qualquer operao write(X) feita por Ti precedida pela escrita apropriada do novo registro corrente no log. Quando Ti parcialmente efetivada, o registro <Ti commit> escrito no log. J que as informaes do log so usadas na reconstruo do estado do banco de dados, no podemos permitir que a atualizao real do banco de dados ocorra antes da escrita correspondente, em armazenamento estvel, do registro de log. Portanto, exigimos que, antes da execuo de uma operao output(B), os registros de log correspondentes a B sejam escritos em armazenamento estvel. Como ilustrao, reconsideremos nosso sistema bancrio simplificado, com transaes T0 e T1 executadas uma aps a outra com T0 seguida por T1. A poro do log contendo as informaes importantes relativas a essas duas transaes apresentada na fig. 15.5.

Uma ordem possvel de ocorrncia das sadas reais, tanto para o sistema de banco de dados quanto para o log, resultantes da execuo de T0 e T1, descrita na fig. 15.6. Observe que essa ordem no poderia ser obtida na tcnica de modificao adiada.

Usando o log, o sistema pode tratar de qualquer falha que no resulte na perda de informao em armazenamento no-voltil. O esquema de recuperao usa dois procedimentos de recuperao: undo(Ti) retorna aos valores antigos todos os itens de dados atualizados pela transao Ti. redo(Ti) ajusta os valores de todos os itens de dados atualizados pela transao Ti para os valores novos. O conjunto de itens de dados atualizados por Ti e seus respectivos valores antigos e novos podem ser encontrados no log. As operaes undo e redo devem ser idempotentes para garantir o comportamento correto mesmo se uma falha ocorrer durante o processo de recuperao. Aps a falha, o esquema de recuperao consulta o log para determinar quais transaes necessitam ser refeitas e quais necessitam ser inutilizadas. Essa classificao de transaes conseguida como segue: A transao Ti tem de ser inutilizada se o log contm o registro <Ti start>, mas no contm o registro <Ti commit>. A transao Ti tem de ser refeita se o log contm tanto o registro <Ti start> quanto o registro <Ti commit>. Como ilustrao, retornaremos a nosso exemplo bancrio, com as transaes T0 seguida por T1. Suponhamos que o sistema caia antes do trmino das transaes. Deveremos considerar trs casos. O estado dos logs para cada um desses casos mostrado na fig. 15.7. 307

Primeiro, assumamos que a queda ocorra logo aps o registro de log para o passo write(B) da transao T0 ter sido escrito em armazenamento estvel (fig. 15.7a). quando o sistema retorna, ele encontra o registro <T0 start> no log, mas nenhum registro <T0 commit> correspondente. Ento, a transao T0 dever ser inutilizada, de modo que um undo(T0) ser processado. Como resultado, os valores nas contas A e B (no disco) so restaurados em mil e dois mil dlares, respectivamente. A seguir, assumamos que a queda venha logo aps o registro de log para o passo write(C) da transao T1 ter sido escrito em armazenamento estvel (fig. 15.7b). Quando o sistema retornar, duas aes de recuperao necessitam ser tomadas. A operao undo (T1) deve ser realizada, j que o registro <T1 start> aparece no log, mas no h o registro <T1 commit>, e a operao redo(T0) tambm deve ser realizada, j que o log contm tanto o registro <T0 start> como o registro <T0 commit>. No fim do processo de recuperao completo, os valores das contas A, B e C sero 950, 2050 e 700 dlares, respectivamente. Observe que a operao undo(T1) realizada antes de redo(T0). Nesse exemplo, o resultado seria o mesmo se a ordem fosse revertida. Entretanto, fazer primeiro as operaes undo e depois as operaes redo importante no algoritmo de recuperao que veremos adiante. Finalmente, assumamos que a queda ocorra logo aps o registro de log <T1 commit> ter sido escrito em armazenamento estvel (fig. 15.7c). Quando o sistema retorna, tanto T0 como T1 necessitam ser refeitas, j que os registros <T0 start> e <T0 commit> aparecem no log, assim como os registros <T1 start> e <T1 commit>. Aps os procedimentos de recuperao redo(T0) e redo(T1), os valores nas contas A, B e C sero 950, 2050 e 600 dlares, respectivamente. Checkpoints Quando uma falha de sistema ocorre, devemos consultar o log para determinar aquelas transaes que necessitam ser refeitas e aquelas que necessitem ser inutilizadas. A princpio, para isso, deveramos pesquisar todo o log. H duas grandes dificuldades nessa abordagem: 1. O processo de pesquisa consome tempo. 2. Muitas das transaes que, de acordo com nosso algoritmo, necessitam ser refeitas j escreveram suas atualizaes no banco de dados. Embora refaz-las no cause dano algum, a recuperao torna-se mais longa. Para reduzir esses tipos de overhead, introduzimos os checkpoints (pontos de controle). Durante a execuo, o sistema mantm o log usando uma das duas tcnicas descritas anteriormente. Alm disso, o sistema cria checkpoints periodicamente, que exigem a execuo da seguinte sequncia de aes: 1. Sada, para armazenamento estvel, de todos os registros residentes na memria principal; 2. Sada, para disco, de todos os blocos de buffer modificados. 3. Sada, para armazenamento estvel, de um registros de log <checkpoint>. No permitido s transaes processar quaisquer aes de atualizao, como escrever em um bloco de buffer ou escrever um registro de log, enquanto um checkpoint est em progresso. A presena de um registro <checkpoint> no log permite que o sistema dinamize seu procedimento de recuperao. Considere uma transao Ti efetivada antes do checkpoint. Para tal transao, o registro <Ti commit> aparece no log antes do registro <checkpoint>. Quaisquer modificaes feitas por Ti ou j foram escritas no banco de dados antes do checkpoint ou o foram como parte do checkpoint propriamente dito. Ento, no momento de recuperao, no haver necessidade de uma operao redo sobre Ti. 308

Essa observao permite-nos refinar nossos esquemas de recuperao anteriores (continuamos a assumir que as transaes so executadas serialmente). Aps uma falha, o esquema de recuperao examina o log para determinar a ltima transao Ti anterior ao checkpoint mais recente. Isso poder ser feito por uma pesquisa retroativa no log, a partir de seu final at o primeiro registro <checkpoint> (j que estamos pesquisando em ordem cronolgica inversa, o registro encontrado ser o ltimo registro <checkpoint> do log); ento o sistema continuar a pesquisar retroativamente at encontrar o prximo registro <Ti start>. Esse registro identifica uma transao Ti. Uma vez identificada a transao Ti, as operaes redo e undo devem ser aplicadas transao Ti e a todas as transaes Tj que comearam depois da dela. Indiquemos essas transaes pelo conjunto T. O restante (parte anterior) do log pode ser ignorado e at mesmo apagado, se for conveniente. Quais operaes de recuperao devem, exatamente, ser processadas depender da tcnica de modificao em uso, se imediata ou adiada. As operaes de recuperao exigidas, se a tcnica de modificao imediata empregada, so as seguintes: Para todas as transaes Tk em T que no tm nenhum registro <Tk commit> no log ser executado undo(Tk). Para todas as transaes Tk em T tais que o registro <Tk commit> aparece no log ser executado redo(Tk). Obviamente, a operao undo no ser aplicada caso a tcnica de modificao adiada esteja em uso. Como ilustrao, considere o conjunto de transaes {T0,T1,..., T100} executado na ordem dos subescritos. Suponha que o checkpoint mais recente tenha ocorrido durante a execuo da transao T67. Ento, somente as transaes T67, T68, ..., T100 necessitam ser consideradas durante o esquema de recuperao. Cada uma delas ser refeita se tiver sido efetivada; caso contrrio, ser inutilizada. Paginao Shadow Uma alternativa s tcnicas de recuperao de queda baseada em log a paginao shadow (sombra). A tcnica de paginao shadow essencialmente uma melhoria de tcnica de cpia shadow. Sob certas circunstncias, a paginao shadow pode exigir menos acessos a disco que os mtodos baseados em log que acabamos de discutir. Entretanto, tambm h desvantagens nessa abordagem, como veremos. Por exemplo, difcil aplicar a paginao shadow pode exigir menos acessos a disco que os mtodos baseados em log que acabamos de discutir. Entretanto, tambm h desvantagens nessa abordagem, como veremos. Por exemplo, difcil aplicar a paginao shadow em transaes concorrentes. Como antes, o banco de dados particionado em um nmero de blocos de comprimento fixo, chamados de pginas. O termo pgina emprestado dos sistemas operacionais, j que estamos usando um esquema de paginao para gerenciamento de memria. Assumamos que haja n pginas, numeradas de 1 at n. (Na prtica, n pode ser da ordem de centenas de milhares.) Essas pginas no necessitam ser armazenadas em alguma ordem particular no disco (h muitas razes para que isso no acontea). Entretanto, deve haver uma forma de encontrar, para um i qualquer, a i-sima pgina do banco de dados. Usamos, para esse proposito, uma tabela de pgina, como mostrado na fig. 15.8. A tabela de pgina tem n entradas uma para cada pgina do banco de dados. Cada entrada contm um ponteiro para uma pgina no disco. A primeira entrada contm um ponteiro para a primeira pgina do banco de dados, a segunda entrada aponta para a segunda pgina e assim por diante. O exemplo da fig. 15.8 mostra que a ordem lgica das pginas do banco de dados no necessita corresponder ordem fsica em que as pginas esto armazenadas no disco. A ideia bsica da tcnica de paginao shadow manter duas tabelas de pgina durante o processamento da transao: a tabela de pginas atuais e a tabela de pginas shadow. Quando a transao comea, ambas as tabelas so idnticas. A tabela de pgina shadow no alterada durante toda a durao da transao. A tabela de pgina atual alterada quando a transao processa uma operao write. Todas as operaes de entrada (input) e sada (output) usam a tabela de pginas atuais para localizar pginas do banco de dados no disco.

309

Suponha que a transao processe uma operao write(X) e que X resida na i-sima pgina. A operao write executada como segue: 1. Se a i-sima pgina (isto , a pgina em que X reside) ainda no est na MP, ento ser emitido um input(X). 2. Se essa a primeira escrita processada na i-sima pgina por essa transao, ento a tabela de pginas atuais ser modificada conforme segue: a. Encontra-se uma pgina sem uso no disco. Normalmente, o sistema de banco de dados tem acesso a uma lista de pginas sem uso (livres). b. Remove-se a pgina encontrada no passo 2a a partir da lista de quadros de pginas livres. c. Modifica-se a tabela de pginas atuais, tal que a i-sima entrada aponte para a pgina encontrada no passo 2a. 3. Designa-se o valor de xj para X na pgina de buffer.

Comparemos a ao precedente para a operao write com aquela j descrita. A nica diferena adicionamos um novo passo. Os passos 1 e 3 anteriores correspondem aos passos 1 e 2 descritos anteriormente. O passo adicional, passo 2, manipula a tabela de pginas atuais. A fig. 15.9 mostra as tabelas, shadow e atual, para uma transao que realize uma escrita na quarta pgina de um banco de dados constitudo de dez pginas. Intuitivamente, a abordagem de recuperao por meio de pginas shadow consiste em manter uma tabela de pginas atuais. A fig. 15.9 mostra as tabelas, shadow e atual, para uma transao que realize uma escrita na quarta pgina de um banco de dados constitudo de dez pginas. Intuitivamente, a abordagem de recuperao por meio de pginas shadow consiste em manter uma tabela de pginas shadow em armazenamento no-voltil, tal que se possa recuperar o estado do banco de dados anterior execuo da transao, devido a uma queda ou aborto da transao. Quando uma transao efetivada, a tabela de pginas atuais escrita em armazenamento no-voltil. A tabela de pginas atuais torna-se, ento, a nova tabela de pginas shadow e, ento, uma nova transao pode comear. importante que a tabela de pginas shadow seja armazenada em meio no-voltil, j que ela fornece o nico meio de localizao das pginas do banco de dados. A tabela de pginas atuais pode ser mantida na MP (armazenamento voltil). No importa se a tabela de pginas atuais perdida em uma queda, j que o sistema se recupera usando a tabela de pgina shadow.

310

Uma recuperao bem-sucedida exige que, aps uma queda, encontremos a tabela de pginas shadow no disco. Uma forma simples de encontra-la manter, em uma localizao fixa de armazenamento estvel, o endereo em disco da tabela de pgina shadow. Quando o sistema retornar aps uma queda, copiamos a tabela de pginas shadows na MP e a usamos para o processamento subsequente da transao. Devido a nossa definio de operao write, garantimos que a tabela de pginas shadow apontar para as pginas do banco de dados que correspondem ao estado do banco de dados anterior a qualquer transao ativa no momento da queda. Ento, o aborto de transaes automtico. Ao contrrio dos esquemas baseados em log, nenhuma operao undo precisa ser chamada. Para efetivar uma transao, devemos fazer o seguinte: 1. Garantir que todas as pginas de buffer da MP que foram alteradas pela transao sejam enviadas para a sada em disco. (Observe que essas operaes de sada no alteraro as pginas do banco de dados apontadas pela tabela de pginas shadow.) 2. Enviar a tabela de pginas atuais para sada em disco. Observe que no devemos sobrescrever a tabela de pginas atuais, j que poderemos precisar dela para a recuperao aps uma queda. 3. Enviar os endereos de disco da tabela de pgina atuais para a localizao fixa em armazenamento estvel que contm o endereo da tabela de pginas shadow. Essa ao sobrescreve o endereo da tabela de pginas shadow antiga. Portanto, a tabela de pginas atuais tornou-se a tabela de pginas shadow e a transao foi efetivada. Se uma queda ocorrer antes do trmino do passo 3, reverteremos ao estado anterior ao da execuo da transao. Se a queda ocorrer aps o trmino do passo 3, os efeitos da transao ainda assim sero preservados; nenhuma operao redo precisar ser atividade. A paginao shadow oferece diversas vantagens sobre as tcnicas baseadas em log. O overhead relativo ao envio dos registros de log eliminado e a recuperao de falhas significativamente mais rpida (j que nenhum operao undo e redo necessria). Entretanto, h tambm inconvenientes nessa tcnica. Overhead de efetivao. A efetivao de uma nica transao usando paginao shadow exige que diversos blocos sejam enviados blocos de dados reais, tabela de pginas atuais e o endereo de disco da tabela de pginas atuais. Os esquemas baseados em log precisam enviar somente os registros de log que, para as pequenas e mais comuns transaes, cabem dentro de um bloco. Fragmentao de dado. Consideramos estratgias para manter prximas no disco as pginas do banco de dados relacionadas fisicamente. Essa proximidade permite maior rapidez na transferncia de dados. A paginao shadow gera alteraes na localizao das pginas do banco de dados quando elas sofrem 311

atualizaes. Com isso, ou perdemos a proximidade das pginas ou precisaremos recorrer a esquemas mais complexos, com maior overhead para gerenciamento do armazenamento fsico. Coleta de lixo. Cada vez que uma transao efetivada, as pginas do banco de dados contendo a verso antiga do dado, alterado pela transao, tornam-se inacessveis. Na fig. 15.9, a pgina apontada pela quarta entrada da tabela de pginas shadow se tornar inacessvel se a transao daquele exemplo for efetivada. Tais pginas so consideras lixo, j que elas no fazem parte do espao livre nem contm informao til. O lixo tambm pode ser um efeito colateral das quedas. Periodicamente, necessrio encontrar todas as pginas lixo e adicion-las lista de pginas livres. Esse processo, chamado de coleta de lixo, impe overhead e complexidade adicionais ao sistema. H vrios algoritmos-padro para coleta de lixo. Alm dos inconvenientes que mencionamos, a adaptao da paginao shadow a sistemas com transaes concorrentes mais difcil do que registro de log. Em tais sistemas, algum tipo de registro de log normalmente necessrio, mesmo que a paginao shadow seja usada. O prottipo do Sistema R, por exemplo, usava uma combinao de paginao shadow com um esquema de registro de log similar ao j apresentado. relativamente simples ampliar os esquemas de recuperao baseados em log para que trabalhem com transaes concorrentes. Por essas razes, a paginao shadow no to usada. Recuperao com Transaes Concorrentes At agora, consideramos a recuperao em um ambiente no qual uma nica transao executada por vez. Agora, discutiremos como modificar o esquema de recuperao baseado em log para tratar de diversas transaes concorrentes. Independente do nmero de transaes concorrentes, o sistema tem um nico buffer de disco e um nico log. Os blocos de buffer so compartilhados por todas as transaes. Permitiremos, alm de atualizaes imediatas, que um bloco de buffer tenha itens de dados atualizados por uma ou mais transaes. Interao com Controle de Concorrncia O esquema de recuperao depende muito do esquema de controle de concorrncia em uso. Para reverter (rollback) uma transao com falha, devemos inutilizar as atualizaes processadas por ela. Suponha que uma transao T0 tenha de ser desfeita e um item de dado Q que foi atualizado por T0 tenha de recuperar seu valor antigo. Usando os esquemas baseados em log, recuperamos esses valor usando as informaes undo de um registro de log. Suponha agora que uma segunda transao T1 tenha tambm processado uma atualizao sobre Q antes de T0 ser desfeita. Ento, a atualizao processada por T1 ser perdida quando T0 for revertida. Portanto, exigimos que, se uma transao T atualizou um item de dado Q, nenhuma outra transao consiga atualizar o mesmo item de dado at que T tenha sido efetivada ou revertida. Podemos facilmente cumprir essa exigncia pelo bloqueio em duas fases severo isto , bloqueio em duas fases com bloqueios exclusivos mantidos at o final da transao. Reverso de Transao Revertemos uma transao com falha, Ti, usando o log. O log reexaminado, do fim para o comeo; e para cada registro da forma <Ti, Xj, V1, V2> encontrado, o item de dado Xj restaurado em seu valor antigo V1. Esse exame termina quando o registro de log <Ti, start> encontrado. Reexaminar o log de trs para frente importante, j que uma transao pode ter atualizado um item de dados mais de uma vez. Como ilustrao, considere o par de registros de log:

Os registros de log representam uma modificao do item de dado A por Ti, seguido de outra modificao de A por Ti. Reexaminar o log do final para o comeo ajusta A corretamente para 10. Se os logs fossem examinados no sentido inverso, A seria ajustado para 20, cujo valor incorreto. 312

Se o bloqueio em duas fases severo usado para controle de concorrncia, os bloqueios mantidos pela transao T podem ser liberados somente aps a transao ter sido revertida, como descrito. Uma vez que uma transao T (que revertida) tenha atualizado um item de dado, nenhuma outra transao poder atualizar o mesmo item de dado, devido s exigncias de controle de concorrncia mencionadas anteriormente. Portanto, a recuperao do valor antigo do item de dado no apagar os efeitos de qualquer transao. Checkpoints Usamos checkpoints para reduzir o nmero de registros de log que devem ser examinados quando o sistema se recupera de uma queda. J que no tnhamos levado qualquer ocorrncia em conta, foi necessrio considerar somente as seguintes transaes durante a recuperao: Aquelas transaes que iniciaram aps o checkpoint mais recente. Aquela transao, se houver alguma, que estava ativa no momento da escrita do checkpoint mais recente. A situao mais complexa quando as transaes podem ser executadas de modo concorrente, j que vrias transaes poderiam estar ativas no momento em que o checkpoint mais recente foi gerado. Em um sistema com processamento de transaes concorrentes, exigimos que o registro de log relativo ao checkpoint seja da forma <checkpoint L>, em que L a lista de transaes ativas no momento do checkpoint. Novamente, assumimos que as transaes no processam atualizaes tanto nos blocos de buffer como no log enquanto o checkpoint est em andamento. A exigncia de que as transaes no devem realizar quaisquer atualizaes nos blocos de buffer, ou no log, durante o checkpoint pode ser preocupante, j que o processamento de transao ter de parar enquanto um checkpoint estiver em progresso. Um fuzzy checkpoint aquele que permitido s transaes processarem atualizaes mesmo quando os blocos de buffer esto sendo escritos. Recuperao por Reincio Quando um sistema se recupera de uma queda, ele constri duas listas: a lista inutilizar (undo-list), que consiste em transaes a serem inutilizadas, e a lista refazer (redo-list), que consiste em transaes a serem refeitas. Essas duas listas so construdas na recuperao como segue. Inicialmente, ambas esto vazias. Examinando o log de trs para frente, cada registro, at que seja encontrado o primeiro registro <checkpoint>: Para cada registro da forma <Ti commit> encontrado, adicionamos Ti lista refazer. Para cada registro da forma <Ti start> encontrado, se Ti no estiver na lista refazer, ento adicionamos Ti na lista inutilizar. Quando todos os registros de log apropriados tiverem sido examinados, checamos a lista L no registro de checkpoint em questo. Para cada transao Ti em L, se Ti no estiver na lista refazer, ento ser adicionada lista inutilizar. Uma vez construdas as listas refazer e inutilizar, os procedimentos de recuperao prosseguem como segue: 1. Reexaminar o log a partir do registro mais recente e processar um undo para cada registro de log pertencente transao Ti na lista inutilizar. Os registros de log de transaes na lista refazer sero ignorados nessa fase. O exame para quando os registros <Ti start> so encontrados para cada transao Ti na lista inutilizar. 2. Localizar o registro <checkpoint L> mais recente no log. Note que este passo pode implicar exame do log na ordem cronolgica crescente, se o registro de checkpoint foi ultrapassado no passo 1. 3. Examinar o log a partir do registro <checkpoint L> mais recente at o final e processar redo para cada registro de log pertencente a uma transao Ti que est na lista refazer. Ignorar os registros de log de transaes na lista inutilizar nessa fase.

313

 importante processar o log no passo 1, na ordem cronolgica decrescente, para garantir que o estado resultante do banco de dados estar correto. Aps desfazer todas as transaes da lista inutilizar, as transaes da lista refazer so refeitas. importante, nesse caso, processar o log na ordem cronolgica crescente. Completado o processo de recuperao, o processamento da transao reassumido. Quando se usa o algoritmo precedente, importante inutilizar uma transao da lista inutilizar antes de refazer transaes da lista refazer. De outra forma, o seguinte problema pode ocorrer. Suponha que o item de dado A tenha inicialmente o valor 10. Suponha que uma transao Ti tenha atualizado o item de dado A para 20 e depois foi abortada; a reverso da transao restauraria A para o valor 10. Suponha, ento, que outra transao Tj tenha atualizado o item de dado A para 30 e tenha sido efetivada; em seguida, o sistema cai. O estado do log no momento da queda :

Se o passo redo processado primeiro, A ser ajustado para 30; ento, no passo undo, A ser ajustado para 10, o que est errado. O valor final de Q deveria ser 30, que podemos alcanar processando undo antes de redo. Gerenciamento de Buffer Vamos considerar diversos detalhes sutis, embora essenciais, para a implementao de um esquema de recuperao de queda que garanta consistncia de dados e imponha uma quantidade mnima de overhead devido a interaes com o banco de dados. Bufferizao de Registro de Log Anteriormente, assumimos que qualquer registro de log enviado para a sada de armazenamento estvel no momento em que criado. Essa situao impe grande overhead execuo do sistema pelas seguintes razes. Normalmente, a sada para armazenamento estvel ocorre em unidades de blocos. Em muitos casos, um registro de log muito menor que um bloco. Ento, a sada de cada registro de log se traduz em uma sada muito maior no nvel fsico. Alm do mais a sada de um bloco para armazenamento estvel pode significar vrias operaes de sada no nvel fsico. O custo relativo ao processamento de uma sada de bloco para armazenamento estvel suficientemente alto; melhor que saiam diversos registros de log de uma s vez. Para isso, escrevemos os registros de log em um buffer de log na MP, onde permanecem temporariamente, at serem enviados para armazenamento estvel. Mltiplos registros de log podem ser reunidos no buffer de log e enviados para armazenamento estvel em uma nica operao de sada. A ordem dos registros de log no armazenamento estvel deve ser exatamente a mesma na qual foram escritos no buffer de log. Em consequncia do uso da bufferizao do log, um registro de log pode residir somente em MP (armazenamento voltil) por um tempo considervel antes de ser enviado para a sada em armazenamento estvel. J que tais registros de log so perdidos se os sistema cair, devemos impor exigncias adicionais s tcnicas de recuperao para garantia de atomicidade da transao: A transao Ti entra em estado de efetivao aps o registro de log <Ti commit> ter sido enviado para sada em armazenamento estvel. Antes do registro de log <Ti commit> sofrer armazenamento estvel, todos os registros de log pertencentes transao Ti devero ter sido enviados para armazenamento estvel. Antes de um bloco de dados na MP podem ser enviado para o banco de dados (em armazenamento novoltil), todos os registros de log pertencentes a dados naquele bloco devem ter sido enviados para armazenamento estvel.

314

Antes de um bloco de dados na MP poder ser enviado para o banco de dados (em armazenamento novoltil), todos os registros de log pertencentes a dados naquele bloco devem ter sido enviados para armazenamento estvel. A ltima regra chamada de regra write-ahead logging (WAL). (Precedncia de escrita do log, a regra WAL exige somente a informao undo no log tenha sido enviada para sada em armazenamento estvel, permitindo que a informao redo seja escrita mais tarde. A diferena relevante em sistemas nos quais a informao redo e undo armazenada em registros de log separados.) Escrever o log bufferizado no disco s vezes chamado de forar o log (log force). As regras precedentes criam situaes em que certos registros de log devem ser enviados para sada em armazenamento estvel. No h problema decorrente do envio dos registros de log mais cedo que o necessrio. Logo, quando o sistema achar necessrio enviar um registro de log para armazenamento estvel, ele enviar um bloco inteiro de registros de log, se houver registros de log suficientes na MP para preencher um bloco. Se os registros de log forem insuficientes na MP para preencher um bloco. Se os registros de logo forem insuficientes para preencher o bloco, os registros de log na MP sero combinados a um bloco parcialmente completo e sero enviados para sada em armazenamento estvel. Bufferizao de Banco de Dados J descrevemos a hierarquia de armazenamento em dois nveis. O banco de dados est armazenado em armazenamento no-voltil (disco) e os blocos de dados so levados MP quando necessrio. J que a MP normalmente muito menor que o banco de dados inteiro, pode ser necessrio sobrescrever um bloco B1 na MP quando outro bloco B2 necessitar ser levado memria. Se B1 tiver sido modificado, ele dever ser enviado para o banco de dados antes da entrada de B2. Essa hierarquia de armazenamento o conceito-padro de sistema operacional de memria virtual. As regras para a sada de registros de log limitam a liberdade do sistema para sada de blocos de dados. Se a entrada do bloco B2 fizer com que o bloco B1 seja selecionado para a sada, todos os registros de log pertencentes aos dados em B1 devem ser enviados para armazenamento estvel antes de B1 ser enviado para sada. Ento, a sequncia de aes pelo sistema, seria como segue: Enviar registros de log para armazenamento estvel at acabarem os registros de log pertencentes ao bloco B1. Enviar o bloco B1 para sada no disco. Enviar o bloco B2 do disco para a entrada em MP. importante que nenhuma gravao no bloco B1 esteja em progresso enquanto a sequncia precedente de aes estiver em execuo. Essa condio satisfeita quando se usa um meio especial de bloqueio, como segue. Antes que uma transao escreva um item de dado, ela deve adquirir um bloqueio exclusivo sobre o bloco no qual o item de dados reside. O bloqueio poder ser liberado imediatamente aps a atualizao. Antes de um bloco ser enviado para a sada, o sistema obtm um bloqueio exclusivo sobre o bloco, para garantir que nenhuma transao o altere. Completada a sada do bloco, o bloqueio liberado. Os bloqueios que so mantidos por pouco tempo so frequentemente chamados de trancas (latches). As trancas so tratadas de forma distintas dos bloqueios usados pelo sistema de controle de concorrncia. Com isso, elas podem ser liberadas sem considerar qualquer protocolo de bloqueio, como bloqueio em duas fases, exigido pelo sistema de controle de concorrncia. Para ilustrar a necessidade da sequncia anterior de aes, consideremos nosso exemplo bancrio com as transaes T0 e T1. Suponha que o estado do log seja:

e que a transao T0 emita uma read(B). Assuma que o bloco em que B reside no est na MP e que a MP esteja completa. Suponha que o bloco em que reside A seja escolhido para ser enviado ao disco. Se o sistema envia esse bloco para sada no disco e, ento, o sistema cai, os valores no banco de dados para as contas A, B e C so 950, 2000 e 700 dlares, respectivamente. Esse estado do banco de dados inconsistente. Entretanto, devido s exigncias precedentes, o registro de log <T0, A, 1000, 950> dever ser enviado para armazenamento estvel 315

antes da sada do bloco em que A reside. O sistema pode usar o registro de log durante a recuperao para levar o banco de dados de volta a um estado consistente. Regra de Sistema Operacional em Gerenciamento de Buffer Podemos gerenciar o buffer do banco de dados usando uma das duas abordagens: 1. O sistema de banco de dados reserva parte da MP para servir como um buffer gerenciado por ele, e no pelo sistema operacional. O sistema de banco de dados gerencia a transferncia de bloco de dados, de acordo com as exigncias que j discutimos. Essa abordagem tem o inconveniente de limitar a flexibilidade de uso da MP. O buffer deve ser mantido pequeno o suficiente para que outras aplicaes tenha MP suficiente para sua necessidades. Entretanto, mesmo quando outras aplicaes no estiverem rodando, o banco de dados no poder fazer uso de todas a memria disponvel. Da mesma forma, aplicaes que no sejam banco de dados podem no usar aquela parte da MP reservada para o buffer de banco de dados, mesmo se algumas pginas no buffer do banco de dados no estiverem em uso. 2. O sistema de banco de dados implementa seu buffer dentro da memria virtual do sistema operacional. J que o sistema operacional possui informaes sobre as exigncias de memria de todos os processos no sistema, idealmente ele deveria estar capacitado a decidir quais blocos de buffer devem ser forados sada para o disco e quando isso deve ser feito. Mas, para atender precedncia de escrita do log que discutimos, o sistema operacional no poderia escrever pginas de buffer no banco de dados por si s, mas, ao contrrio, solicitar que o sistema de banco de dados forasse a sada dos blocos do buffer. O sistema de banco de dados, por sua vez, s foraria a sada dos blocos do buffer para o banco de dados aps escrever os registros de log relevantes em armazenamento estvel. Infelizmente, quase todos os sistemas operacionais da gerao atual mantm controle completo sobre a memria virtual. O sistema operacional reserva espao em disco para armazenar pginas de memria virtual que no esto na MP; este espao chamado de espao de swap (troca). Se o sistema operacional decidir retirar da memria um bloco Bx, ele ser enviado para o espao de swap no disco, e no h nenhuma forma do sistema de banco de dados conseguir controle dessa sada de blocos do buffer. No entanto, se o buffer de banco de dados estiver na memria virtual, as transferncias entre arquivos de banco de dados e o buffer na memria virtual so gerenciadas pelo sistema de banco de dados, que cumprir as exigncias de precedncia de escrita do log que discutimos. Essa abordagem pode implicar sadas extras de dados para o disco. Se um bloco Bx retirado pelo sistema operacional, esse bloco no ser enviado para o banco de dados. Ao contrrio, ele ser enviado para o banco de dados. Quando o sistema de banco de dados tiver de enviar Bx para o disco, pode ser que o sistema operacional tenha de, primeiro, retirar Bx de seu espao de swap. Ento, ao contrrio de uma nica sada de Bx da memria, exigiremos duas sadas de Bx (uma pelo sistema operacional, e outra pelo sistema de banco de dados), alm de uma entrada extra de Bx na memria. Embora ambas as abordagens padeam de alguns inconvenientes, uma ou outra dever ser escolhida, a menos que o sistema operacional seja projetado para aceitar as exigncias de log do banco de dados. Somente uns poucos sistemas operacionais atuais, como o sistema operacional Mach, aceitam tais exigncias. Falha com Perda de Armazenamento No-voltil At agora, consideramos somente falhas que tm como consequncia a perda de informaes residentes em armazenamento voltil; o contedo do armazenamento no-voltil permanece intacto. Embora as falhas com perda de armazenamento no-voltil sejam raras, precisamos estar preparados para trata-las. Vamos discutir, por enquanto, apenas armazenamento em disco. Nossas discusses se aplicam tambm a outros tipos de armazenamento no-voltil. O esquema bsico descarregar (dump) todo contedo do banco de dados para armazenamento estvel periodicamente digamos, uma vez por dia. Por exemplo, podemos descarregar o banco de dados para uma ou 316

mais fitas magnticas. Se ocorrer uma falha que resulte na perda de blocos fsicos do banco de dados, a descarga mais recente ser usada na restaurao do banco de dados para seu ltimo estado consistente possvel. Uma vez completada essa restaurao, o sistema usa o log para trazer o sistema de banco de dados para um estado consistente recente. Mais precisamente, nenhuma transao pode estar ativa durante o procedimento de descarga, e um procedimento similar para checkpoint (pontos de controle) deve ocorrer: 1. Enviar todos os registros de log residentes em MP para sada de armazenamento estvel. 2. Enviar todos os blocos de buffer para sada em disco. 3. Copiar o contedo do banco de dados em armazenamento estvel. 4. Enviar um registro de log <dump> para sada em armazenamento estvel. Os passos 1, 2 e 4 correspondem aos trs passos usados para checkpoints anteriormente. Para se recuperar da perda de armazenamento no-voltil, restauramos o banco de dados em disco usando a descarga (dump) mais recente. O log , ento, consultado e todas as transaes que foram efetivadas desde a ltima descarga so refeitas. Observe que nenhuma operao undo precisa ser executada. Uma descarga do contedo do banco de dados tambm chamada de archival dump (descarga histrica), j que podemos arquivar as descargas e us-las mais tarde para examinar informaes antigas do banco de dados. Descargas de um banco de dados e checkpoints dos buffers so similares. O procedimento de descarga simples aqui descrito oneroso pelas seguintes razes. Primeiro, todo o banco de dados dever ser copiado em armazenamento estvel, resultando em considervel transferncia de dados. Segundo, j que o processamento das transaes suspenso durante a descarga, ciclos de CPU so perdidos. Tm sido desenvolvidos esquemas de fuzzy dump (descarga indistinta) que permitem a existncia de transaes ativas enquanto a descarga est em progresso. So similares a esquemas de checkpoints. Tcnicas de Recuperao Avanadas As tcnicas de recuperao j descritas requerem que, enquanto uma transao atualizao um item de dado, nenhuma outra transao consiga atualizar o mesmo item de dado, at que a primeira seja efetivada ou revertida. Satisfazemos essa condio por meio do bloqueio em duas fases severo. Embora o bloqueio em duas fases severo seja aceitvel para os registros de relaes ele causa um significativo decrscimo de concorrncia quando aplicado a certas estruturas especiais, como pginas de ndice de rvore-B+. Para aumentar a concorrncia, podemos usar o algoritmo de controle e de concorrncia rvore-B+ permitindo que os bloqueios sejam liberados mais cedo, sem usar duas fases. Como isso, entretanto, as tcnicas de recuperao estudadas tornam-se inaplicveis. Vrias tcnicas de recuperao alternativas tm sido propostas tornam-se inaplicveis. Vrias tcnicas de recuperao alternativas tm sido propostas, aplicveis mesmo com liberao prematura de bloqueio. Descrevemos uma dessas tcnicas de recuperao agora. Log com Undo Lgico Para aes nas quais os bloqueios so liberados mais cedo, no podemos processar as aes undo simplesmente regravando o valor antigo dos itens de dados. Considere uma transao T que insira uma entrada em uma rvore-B+ e, seguindo o protocolo de controle de concorrncia rvore-B+, libere alguns dos bloqueios aps o trmino da operao de insero, mas antes da transao ser efetivada. Aps a liberao dos bloqueios, outras transaes podem realizar inseres ou remoes adicionais, causando desse modo mudanas adicionais nas pginas da rvore B+. Mesmo que a operao libere alguns dos bloqueios previamente, ela dever reter bloqueios suficientes para garantir que no seja permitido a nenhuma outra transao executar qualquer operao conflitante (como ler ou remover o valor inserido). Por essa razo, o protocolo de controle de concorrncia rvore-B+ mantm os bloqueios no nvel de folha da rvore-B+ at o fim da transao. Agora vamos considerar como processar os rollbacks de transaes. Se os valores antigos dos ns internos da rvore-B+ (antes da operao de insero ser executada) forem restaurados durante a reverso da 317

transao, algumas das atualizaes processadas pelas ltimas operaes de insero ou excluso executadas por outras transaes poderiam ser perdidas. Em vez disso, a operao de insero tem de ser inutilizada logicamente isto , pela execuo de uma operao de remoo. Portanto, quando a ao de insero for completada, antes de liberar qualquer bloqueio, ela dever gravar um registro de log <Oi, operation-end, U>, em que U indica a informao de inutilizao e Oi indica um identificador para a operao. Por exemplo, se a operao inseriu uma entrada em uma rvore-B+, a informao undo U indicaria o que remover da rvore-B+. Esse log de informao sobre operaes chamado de log fsico e os correspondentes registros de log so chamados de registros de log fsicos. As operaes de insero e remoo so exemplos de uma classe de operaes que exige operaes undo lgicas, j que liberam os bloqueios previamente; chamamos tais operaes de operaes lgicas. Antes que uma operao lgica tenha incio, ela escreve um registro de log <Oi, operation-begin>, em que Oi o identificador para a operao. Enquanto a operao est sendo executada, o log feito da maneira convencional para todas as atualizaes processadas pela operao. Ento, as informaes usuais dos valores antigos e novos so escritos para cada atualizao. Quando a operao termina, um registro de log de final de operao (operation-end) escrito como explicado anteriormente. Reverso de Transao Vamos considerar primeiro a reverso de transaes durante operao normal (isto , no durante a recuperao do sistema aps uma falha). O log examinado de trs para a frente (ordem cronolgica decrescente) e os registros de log pertencente transao so usado para restaurar os valores antigos dos itens de dados. Ao contrrio de antes, escrevemos registros especiais de log somente redo da forma <Ti, Xj, V> com o valor V sendo sobreposto ao item de dado Xj durante a reverso. Esses registros de log algumas vezes so chamados de registros de log de compensao. Sempre que um registro de log <Oi, operation-end, U> encontrado, aes especiais so tomadas: 1. Revertemos a operao usando a informao undo U do registro de log. As atualizaes processadas durante a reverso da operao so registradas no log exatamente da mesma forma que as atualizaes processadas quando a operao foi executada primeiro. Alm do mais, registros de log referentes ao incio e ao final da operao so gerados exatamente como durante a execuo normal da operao. 2. Quando a verificao retroativa do log continua, saltamos todos os registros de log da transao at encontrados o registro de log <Oi, operation-begin>. Aps o registro de log de incio da operao ser encontrado, os registros de log da transao so processados novamente de maneira usual. Quando a transao Ti for revertida, um registro <Ti abort> ser adicionado ao log. Se ocorrerem falhas enquanto uma operao lgica est em progresso, o registro de logo de fim de operao para aquela operao no ser encontrado quando a transao for revertida. Entretanto, para cada atualizao processada pela operao, a informao undo na forma do valor antigo nos registros de log fsicos est disponvel no log. Observe que saltar os registros de log fsicos, quando o registro de log de fim de operao encontrado durante a reverso, garante que os valores antigos do registro de log fsico no sejam usados na reverso, uma vez que a operao terminou. Se o bloqueio usado para controle de concorrncia, os bloqueios mantidos por uma transao T podem ser liberados somente aps a transao tiver sido revertida, conforme descrito. Checkpoints Os checkpoints so processados conforme j descrito. Atualizaes no banco de dados so temporariamente suspensas e as seguintes aes so executadas: 1. Enviar para sada em armazenamento estvel todos os registros de log residentes na memria principal. 2. Enviar para sada em armazenamento estvel um registro de log <checkpoint L>, em que L uma lista de todas as transaes ativas. 3. Enviar para sada em disco todos os blocos de buffer modificados. 318

Recuperao de Reincio As aes de recuperao, quando o sistema de banco de dados reiniciado aps uma falha, so executadas em duas fases: 1. Na fase redo, reexecutamos as atualizaes de todas as transaes pela varredura do log avanando a partir do ltimo checkpoint. Os registros de log que sero reexecutados englobam os registros de log das transaes que foram revertidas antes do sistema cair e aquelas que no foram efetivas quando ocorreu a queda do sistema. Os registros de log reexecutados incluem os registros de log usuais da forma <Ti, Xj, V1, V2> e os registros de log especiais da forma <Ti, Xj, V2>; o valor V2 escrito para o item de dados Xj em qualquer caso. Essa fase tambm determina todas as transaes que esto na lista de transaes no registro de checkpoint ou que foram iniciadas mais tarde, mas no tm nenhum registro <Ti abort> ou <Ti commit> no log. Todas essas transaes tm de ser revertidas e seus identificadores de transao so colocados em uma lista undo. 2. Na fase undo, refazemos todas as transaes da lista undo. Processamos a reverso reexaminando o log do final para o comeo. Sempre que um registro de log pertencente a uma transao da lista undo encontrado, as aes undo so processadas exatamente como se o registro de log fosse encontrado durante a reverso de uma transao que falhou. Ento, os registros de log de uma transao anteriores a um registro final de operao, mas aps o correspondente registro de incio de operao, so ignorados. Quando um registro de log <Ti start> encontrado para uma transao Ti na lista undo, um registro de log <Ti abort> escrito no log. O exame do log para quando registros de log <Ti start> so encontrados para todas as transaes na lista undo. A fase redo da recuperao de reincio reexecuta todos os registros de log fsico, a partir do mais recente registro de checkpoint. Em outras palavras, essa fase de recuperao de reincio repete todas as aes de atualizao que foram executadas aps o checkpoint e cujos registros de log alcanaram log estvel. Essas aes incluem as transaes incompletas e as aes executadas para reverter transaes com falha. As aes so repetidas na mesma ordem em que foram executas; consequentemente, esse processo chamado de histria repetitiva (repeating history). A histria repetitiva simplifica enormemente os esquemas de recuperao. Fuzzy Checkpoint A tcnica checkpoint descrita exige que todas as atualizaes ao banco de dados sejam temporariamente suspensas enquanto o checkpoint est em progresso. possvel modificar a tcnica para permite que as atualizaes iniciem no momento em que o registro checkpoint escrito, mas antes dos blocos de buffer modificados serem escritos no disco. Ento, o checkpoint gerado um fuzzy checkpoint (ponto de controle indistinto). A ideia a seguinte. Em vez de reexaminar o log de trs para frente a fim de encontrar um registro de checkpoint, armazenamos a localizao em log do ltimo registro de checkpoint em uma posio fixa no disco. Entretanto, essa informao no atualizada quando o registro checkpoint escrito. Ao contrrio, antes do registro checkpoint ser escrito, uma lista com todos os blocos de buffer modificados criada. A informao ltimo checkpoint atualizada somente aps todos os blocos de buffer, da lista de blocos de buffer modificados, terem sido escritos no disco. O protocolo de precedncia de escrita do log deve ser seguido quando os blocos de buffer so enviados para sada. Observe que, em nosso esquema, o registro de log lgico usado somente para propsitos de undo, ao passo que o registro de log fsico usado para propsitos redo (refazer) e undo (inutilizar). H esquemas de recuperao que usam registro de log lgico para propsitos redo. Entretanto, tais esquemas no podem ser usados com fuzzy checkpoint e, portanto, no so muito empregados.

319