a tecnicas de implementacao de banco de dados

Escola Estadual deEducação Profissional - EEEPEnsino Médio Integrado à Educação Profissional

Curso Técnico em Informática

Técnicas de Implementaçãode Bancos de Dados

Governador

Vice Governador

Secretário Executivo

Assessora Institucional do Gabinete da Seduc

Cid Ferreira Gomes

Francisco José Pinheiro

Antônio Idilvan de Lima Alencar

Cristiane Carvalho Holanda

Secretária da Educação

Secretário Adjunto

Coordenadora de Desenvolvimento da Escola

Coordenadora da Educação Profissional – SEDUC

Maria Izolda Cela de Arruda Coelho

Maurício Holanda Maia

Maria da Conceição Ávila de Misquita Vinãs

Thereza Maria de Castro Paes Barreto

TÉCNICAS DE IMPLEMENTAÇÃO DE BANCO DE DADOS

SUMÁRIO

Funcionalidades de Sistemas de Banco de Dados

Níveis de Abstração de um Sistema de Banco de Dados

Classificação dos Sistemas de Banco de Dados

Arquitetura de Sistemas de Banco de Dados

Armazenamento de Dados

Políticas de Alocação de Arquivos

Técnicas RAID

Gerenciamento de Buffer

Processamento de Consultas

Processamento de Transações

Serialização de Transações

Controle de Concorrência

Técnicas de Recuperação

Linguagem Estruturada de Pesquisa - SQL

Cláusulas SQL

Escola Estadual de Educação Profissional [EEEP]Escola Estadual de Educação Profissional [EEEP] Ensino Médio Integrado à Educação Profissional

INFORMÁTICA - Técnica de Implementação de Banco de Dados 1

FUNCIONALIDADES DE SISTEMAS DE BANCO DE DADOS

A importância da informação na maioria das organizações tem determinado o desenvolvimento de um conjunto de conceitos e técnicas para a administração eficaz destes dados. Sistemas de banco de dados são projetados para gerir grandes volumes de informações. O gerenciamento de informações implica a definição das estruturas de armazenamento das informações e a definição dos mecanismos para a manipulação dessas informações. Ainda, um sistema de banco de dados deve garantir a segurança das informações armazenadas contra eventuais problemas com o sistema, além de impedir tentativas de acesso não autorizadas. Se dados são compartilhados por diversos usuários, o sistema deve evitar a ocorrência de resultados anômalos.

Portanto, um Sistema Gerenciador de Banco de Dados (SGBD), basicamente, é um

sistema computadorizado de manutenção de registros, ou seja, um sistema cujo objetivo global é proporcionar um ambiente tanto conveniente quanto eficiente para a recuperação e armazenamento das informações do banco de dados.

Antes do advento dos SGBDs, as organizações usavam os Sistemas de Processamento de Arquivos para armazenar informações. Neste sistema, registros permanentes eram armazenados em vários arquivos e diversos programas de aplicação foram escritos para extrair e gravar registros nos arquivos apropriados.



Obter informações organizacionais em sistemas de processamento de arquivos

apresenta numerosas desvantagens:

Inconsistência e redundância dos dados: cada programa terá seus próprios arquivos, o mesmo dado pode estar em vários locais ao mesmo tempo;

Dificuldades de acesso aos dados: novas consultas não previstas levarão muito tempo para serem programadas;

Isolamento dos dados: dados dispersos em arquivos dispersos em diferentes formatos dificultam a programação;

Problemas de integridade: restrições devem ser implementadas no software; Problemas de atomicidade: em caso de falha é preciso que os dados sejam

restaurados completamente; Anomalias de acesso concorrente: vários usuários podem estar

lendo/escrevendo dados simultaneamente; Problemas de segurança: nem todos os usuários do sistema devem ser

capazes de acessar todos os dados, e é difícil impor tais restrições de segurança.

Estas dificuldades, dentre outras, provocaram o desenvolvimento dos SGBDs, onde estes são constituídos por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado de banco de dados, contém informações sobre uma empresa em particular.



NÍVEIS DE ABSTRAÇÃO DE UM SISTEMA DE BANCO DE DADOS

Um SGBD é uma coleção de arquivos e programas inter-relacionados que permitem ao usuário o acesso para consultas e alterações desses dados. O maior benefício de um banco de dados é proporcionar ao usuário uma visão abstrata dos dados. Isto é, o sistema acaba por ocultar determinados detalhes sobre a forma de armazenamento e manutenção desses dados.

Já que muitos usuários dos sistemas de banco de dados não são treinados em computação, os técnicos em desenvolvimento de sistemas omitem essa complexidade desses usuários por meio de diversos níveis de abstração, de modo a facilitar a interação dos usuários com o sistema.



Nível Físico: o mais baixo, descreve como os dados estão realmente armazenados (complexo e mais baixo nível);

Nível Lógico: descreve quais dados estão armazenados e a relação entre eles (estruturas simples, ocultando a complexidade real);

Nível de Visão: o mais alto, descreve apenas a parte do banco de dados (as relevantes para um usuário).

No nível físico, um registro de cliente, conta ou empregado pode ser descrito como um bloco consecutivo de memória. No nível lógico, cada registro é descrito por um tipo definido, assim como é definida a inter-relação entre esses tipos de registros. Finalmente, no nível de visão, os usuários do computador veem um conjunto de programas de aplicação que escondem os detalhes dos tipos de dados. CLASSIFICAÇÃO DOS SISTEMAS DE BANCO DE DADOS

Os sistemas de banco de dados podem ser classificados de acordo com duas

métricas: o modelo de dados e a sua arquitetura. Em referência aos modelos de sistemas de banco de dados, destacam-se os sistemas

de banco de dados relacionais, os sistemas de banco de dados orientado a objetos e os sistemas de banco de dados objeto-relacional.

Um Banco de Dados Relacional é um conceito abstrato que define maneiras de armazenar, manipular e recuperar dados estruturados unicamente na forma de tabelas, construindo um banco de dados. Os bancos de dados relacionais (BDR) surgiram em meados da década de 1970. Porém, apenas alguns anos mais tarde as empresas passaram a utilizá-los no lugar de arquivos planos. Foram desenvolvidos para prover acesso facilitado aos dados, possibilitando que os usuários utilizassem uma grande variedade de abordagens no tratamento das informações. A arquitetura de um banco de dados relacional pode ser descrita de maneira informal ou formal. Na descrição informal estamos preocupados com aspectos práticos da utilização e usamos os termos tabela, linha e coluna. Na descrição formal estamos preocupados com a semântica formal do modelo e usamos termos como relação (tabela), tupla (linhas) e atributo (coluna).

Um Banco de Dados Orientado a Objetos é um banco de dados em que cada informação é armazenada na forma de objetos. O gerenciador do banco de dados para um orientado a objeto é referenciado por vários como ODBMS ou OODBMS.

Existem dois fatores principais que levam a adoção da tecnologia de banco de dados orientados a objetos. A primeira, é que em um banco de dados relacional se torna difícil de manipular com dados complexos. Segundo, os dados são geralmente manipulados pela aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java, Python ou Delphi (Object Pascal), e o código precisa ser traduzido entre a representação do dado e as tuplas da tabela relacional, o que além de ser uma operação tediosa de ser escrita, consome tempo. Esta perda entre os modelos usados para representar a informação na aplicação e no banco de dados é também chamada de “perda por resistência”.



Banco de Dados Objeto-Relacional (BDOR) ou sistema de gerenciamento de banco de dados relacional de objetos (SGBDRO) é um sistema de gerenciamento de banco de dados (SGBD) semelhante a um banco de dados relacional, porém com um modelo de banco de dados orientado a objetos: objetos, classes e herança são suportados diretamente nos esquemas do banco de dados e na linguagem de consulta. Além disso, ele suporta extensão do modelo de dados com a personalização de tipos de dados e métodos.

Já tratando o aspecto relacionado à arquitetura dos sistemas de banco de dados,

destacamos as arquiteturas centralizadas e distribuídas. Nos sistemas de banco de dados centralizados todos os componentes do banco de

dados residem no mesmo computador, centralizando a arquitetura e o gerenciamento do sistema. Levanta-se a dificuldade quanto à estabilidade deste host centralizador da arquitetura.

Na arquitetura distribuída o critério para a distribuição das funcionalidades, se dá pela função, controle e dados. Sistemas de banco de dados cliente-servidor são caracterizados pela distribuição das funções do SGBD entre os clientes e o servidor, onde várias funções de um sistema computacional podem ser delegadas a diversos módulos de software e hardware. Sistemas de banco de dados paralelos definem a distribuição do controle de funções do SGBD entre diversos sistemas computacionais. Os sistemas de banco de dados distribuídos a distribuição é em relação aos dados através de SGBDs homogêneos, onde os dados utilizados por várias aplicações podem ser distribuídos em diferentes sites de processamento.

Ainda existem os sistemas de banco de dados heterogêneos na qual a distribuição

dos dados se dão através de SGBDs heterogêneos e autônomos. Estes sistemas são divididos em sistemas de banco de dados múltiplos e sistemas de banco de dados federados. Por fim os sistemas de banco de dados móveis que possuem distribuição de função e dados do SGBD entre clientes e servidores em ambientes de computação móvel.



ARQUITETURA DE SISTEMAS DE BANCO DE DADOS

Um sistema de banco de dados está dividido em módulos específicos, de modo a

atender a todas as funções do sistema. Algumas das funções do sistema de banco de dados podem ser fornecidas pelo sistema operacional. Na maioria das vezes, o sistema operacional do computador fornece apenas as funções essenciais, e o sistema de banco de dados deve ser construído nessa base. Assim, o projeto do bando 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 administração de memória. Os componentes de processamento de consultas incluem:

Compilador DML, que traduz comandos DML (Linguagem de Manipulação de

Dados) da linguagem de consulta em instruções de baixo nível, inteligíveis ao componente de execução de consultas. Além disso, o compilador DML tenta transformar a solicitação do usuário em uma solicitação equivalente, mas mais eficiente, buscando, assim, uma boa estratégia para a execução da consulta.

Pré-compilador para comandos DML, inseridos em programas de aplicação, que convertem comandos DML em chamadas a procedimentos normais da linguagem hospedeira. O pré-compilador precisa interagir com o compilador DML de modo a gerar o código apropriado.

Interpretador DDL, que interpreta os comandos DDL (Linguagem de Definição de Dados) e registra-os em um conjunto de tabelas que contêm metadados1.

Componentes para o tratamento de consultas, que executam instruções de baixo nível geradas pelo compilador DML.

Os componentes para administração do armazenamento de dados proporcionam a

interface entre os dados de baixo nível, armazenados no banco de dados, os programas de aplicações e as consultas submetidas ao sistema. Os componentes de administração de armazenamento de dados incluem:

Gerenciamento de autorizações e integridade, que testam o cumprimento

das regras de integridade e a permissão ao usuário no acesso aos dados. Gerenciamento de transações, que garante que o banco de dados

permanecerá em estado consistente (correto) a despeito de falhas no sistema e que transações concorrentes serão executadas sem conflitos em seus procedimentos.

São dados sobre outros dados. Um item de um metadado pode dizer do que se trata aquele dado, geralmente

uma informação inteligível por um computador. Os metadados facilitam o entendimento dos relacionamentos e a utilidade

das informações dos dados.



Administração de arquivos, que gerencia a alocação de espaço no armazenamento em disco e as estruturas de dados usadas para representar estas informações armazenadas em disco.

Administração de buffer, responsável pela intermediação de dados do disco para a memória principal e pela decisão de quais dados colocar em memória cache2.

Além disso, algumas estruturas de dados são exigidas como parte da implementação

física do sistema:

Arquivo de dados, que armazena o próprio banco de dados. Dicionário de dados, que armazena os metadados relativos à estrutura do

banco de dados. O dicionário de dados é muito usado. Portanto, grande ênfase é dada ao desenvolvimento de um bom projeto com uma implementação eficiente do dicionário.

Índices, que proporcionam acesso rápido aos itens de dados que são associados a valores determinados.

Estatísticas de dados, armazenam informações estatísticas relativas aos dados contidos no banco de dados. Essas informações são usadas pelo processador de consultas para seleção de meios eficientes para execução de uma consulta.

A figura a seguir apresenta estes componentes e a conexão entre eles.

Um dispositivo de acesso rápido, interno a um sistema, que serve de intermediário entre um operador de um

processo e o dispositivo de armazenamento ao qual esse operador acede.



ARMAZENAMENTO DE DADOS

Um dos objetivos de um sistema de banco de dados é simplificar e facilitar o acesso

aos dados. Os usuários do sistema não devem ser incomodados com os detalhes físicos da implementação do sistema.

Existem diversos tipos de armazenamento de dados na maioria dos sistemas computacionais. Essas mídias de armazenamento são classificadas pela velocidade com a qual os dados podem ser acessados, pelo custo da mídia por unidade de dados e pela confiabilidade das mídias. Entre as mídias disponíveis estão:

Cache. O cache é a forma de armazenamento mais rápida e mais cara. A memória é pequena; sua utilização é gerenciada pelo sistema operacional.



Não devemos ficar preocupados com o gerenciamento do armazenamento em cache em um sistema de banco de dados.

Memória principal. A mídia de armazenamento utilizada para os dados que

estão disponíveis para serem trabalhados é a memória principal. Embora a memória principal possa conter muitos megabytes de dados, ela é geralmente muito pequena para armazenar o banco de dados inteiro. Frequentemente, o conteúdo da memória principal é perdido se ocorrer uma falta de energia ou uma falha grave de sistema.

Memória flash. A memória flash difere da memória principal porque os dados

sobrevivem à falta de energia. A memória flash encontrou popularidade como uma substituta dos discos magnéticos no armazenamento de pequenos volumes de dados (de cinco a dez megabytes) em sistemas de computadores de baixo custo, como sistemas de computadores embutidos em outros equipamentos.

Armazenamento em disco magnético. Mídia primária para o armazenamento

de dados por longos períodos e acesso on-line. Normalmente, um banco de dados inteiro é armazenado em disco magnético. Os dados devem ser movidos do disco para a memória principal para serem acessados. Após a execução das operações, os dados que foram modificados devem ser escritos em disco.

Armazenamento ótico. A forma mais popular de armazenamento ótico é o

disco compacto de memória apenas de leitura. Os dados são armazenados oticamente no disco e lidos por laser. Existem dispositivos que combinam armazenamento ótico e magnético utilizando meios óticos para ler magneticamente dados codificados e permitindo escrever sobre dados antigos.

Armazenamento em fita. O armazenamento em fita é usado

primordialmente para backup ou para arquivo de dados. Embora as fitas magnéticas sejam muito mais baratas do que os discos, o acesso aos dados é muito mais lento, porque a fita deve ser acessada sequencialmente a partir do início.

Os vários meios de armazenamento podem ser organizados em uma hierarquia

como mostrado na figura abaixo, de acordo com sua velocidade e custo. Os níveis mais altos são caros, mas rápidos.



POLÍTICAS DE ALOCAÇÃO DE ARQUIVOS

Uma das grandes preocupações nos sistemas de banco de dados em relação ao

armazenamento de arquivos é quanto ao posicionamento do arquivo em disco, em quais blocos encontram-se as partes de um arquivo. Com isso estudamos as políticas de alocação de arquivos, definindo assim quais blocos serão armazenados um arquivo.

Alocação Contínua: os arquivos são armazenados em blocos contíguos em disco.

Como o acesso se dá de forma sequencial aos blocos, é suficiente guardarmos apenas o número do primeiro bloco do disco que contem o arquivo. Uma grande desvantagem fica por conta do crescimento dinâmico dos arquivos provocando assim a fragmentação dos discos.

Alocação em Lista Encadeada: cada arquivo é alocado como uma lista encadeada de blocos de disco, onde cada elemento da lista representa um bloco e a primeira palavra de um bloco contem um ponteiro para o próximo bloco do mesmo arquivo. A grande vantagem do sistema em lista encadeada é a facilidade em localizar todos os dados em disco, sendo necessário apenas guardar o número do primeiro bloco.

Alocação em Lista Encadeada utilizando Índices: possui como grande característica a presença dos ponteiros em uma tabela na memória em uma estrutura a base de índices. A grande solução em relação à estrutura de lista encadeada simples é que agora os blocos são ocupados apenas com dados, diferentemente da anterior que os ponteiros ocupavam alguns bytes no bloco. A desvantagem fica por conta do carregamento em memória da tabela de ponteiros.

Alocação utilizando I-nodes: cada arquivo está associado a uma tabela denominada index-node. O conteúdo de um i-node são os atributos dos arquivos juntamente com os endereços dos blocos de disco, onde estão armazenados os arquivos. Para armazenar os blocos de disco ocupados por grandes arquivos no i-node existem as estruturas de blocos indiretos simples, duplos e triplos.



TÉCNICAS RAID

Ter um grande número de discos em um sistema dá a oportunidade de melhorar a

taxa na qual os dados são lidos ou escritos, se os discos são operados em paralelo. Adicionalmente, essa configuração oferece o potencial e melhorar a confiabilidade do armazenamento de dados, porque informações redundantes podem ser armazenadas em diferentes discos. Assim, a falha em um disco não leva à perda de dados. Uma variedade de técnicas de organizações de disco, coletivamente chamadas de redundante arrays of inexpensive disks (RAID), tem sido proposta para trabalhar as características de desempenho e confiança.

Atualmente, os RAIDs são usados porque proporcionam confiabilidade e taxa de transferência de dados mais alta, em vez de razões econômicas, passando assim a denominar redundante arrays of independent disks, não mais fazendo alusão a termos de custo.

Considerando a confiabilidade, a chance de que um disco de um conjunto de N discos venha a falhar é muito maior do que a chance de um disco específico falhar. Se mantivermos apenas uma cópia dos dados, então cada falha de disco resultará na perda de uma quantidade de dados significativa, o que inaceitável. A solução para esse problema de confiabilidade é introduzir a redundância, ou seja, armazenar informação adicional que não é normalmente necessária, mas que pode ser utilizada na eventual falha de um disco para reconstruir a informação perdida. A abordagem mais simples para introduzir redundância é duplicar cada disco. Essa técnica é chamada de espelhamento ou sombreamento de disco. Um disco lógico, então, consiste de dois discos físicos, e cada operação de escrita é efetuada em ambos os discos.

A taxa de transferência para cada leitura é a mesma de um sistema de disco único, mas o número de leituras por unidade de tempo é dobrado. Com múltiplos discos também podemos melhorar a taxa de transferência por meio da distribuição paralela de dados pelos múltiplos discos. Em sua forma mais simples, a distribuição paralela consiste em distribuir os bits de cada byte pelos múltiplos discos. Em medidas de desempenho, o paralelismo em um sistema de disco proporciona um balanceamento de pequenos e múltiplos acessos, além de, tornar paralelos grandes acessos, de forma a reduzir seu tempo de resposta.

Têm sido propostos numerosos esquemas para prover redundância a baixo custo utilizando a ideia de espelhamento de disco combinada com a paridade de bits. Esses esquemas possuem diferentes relações entre custo e desempenho, e são classificados em níveis chamados níveis de RAID.

.



RAID nível 0 (zero). Refere-se ao arranjo de disco com distribuição paralela baseada

em blocos, mas sem qualquer redundância, tal como espelhamento ou bits de paridade.

RAID nível 1. É o nível de RAID que implementa o espelhamento de disco, também

conhecido como mirror. Para esta implementação são necessários no mínimo dois discos. O funcionamento deste nível é simples: todos os dados são gravados em dois discos diferentes; se um disco falhar ou for removido, os dados preservados no outro disco permitem a não descontinuidade da operação do sistema.

RAID nível 2. é similar ao RAID 4, mas armazena informação ECC (Error Correcting

Code), que é a informação de controle de erros, no lugar da paridade. Este fato possibilita uma pequena proteção adicional, porém o RAID 2 ficou obsoleto pelas novas tecnologias de disco já possuírem este tipo de correcção internamente. O RAID 2 origina uma maior consistência dos dados se houver queda de energia durante a escrita. Baterias de segurança e um encerramento correto podem oferecer os mesmos benefícios.

. Raid nível 3. É uma versão simplificada do RAID nível 2. Nesse arranjo, um único bit

de paridade é computado para cada palavra de dados e escrito em um drive de paridade. À primeira vista, pode parecer que um único bit de paridade dá somente detecção de erro, e não correção de erro. Para o caso de erros aleatórios não detectados, essa observação é verdadeira. Todavia, para o caso de uma falha de drive, ela provê correção total de erros de um bit, uma vez que a posição do bit defeituoso é conhecida. Se um drive falhar, o controlador apenas finge que todos os seus bits são "zeros". Se uma palavra apresentar erro de paridade, o bit que vem do drive extinto deve ter sido um "um", portanto, é corrigido. A fim de evitar o atraso em razão da latência rotacional, o RAID 3 exige que todos os eixos das unidades de disco estejam sincronizados. A maioria das unidades de disco mais recentes não possuem a opção de sincronização do eixo, ou se são capazes disto, faltam os conectores necessários, cabos e documentação do fabricante.



Raid nível 4. Funciona com dois ou mais discos iguais. Um dos discos guarda a

paridade (uma forma de soma de segurança) da informação contida nos discos. Se algum dos discos avariar, a paridade pode ser imediatamente utilizada para reconstituir o seu conteúdo. Os discos restantes, usados para armazenar dados, são configurados para usarem segmentos suficientemente grandes (tamanho medido em blocos) para acomodar um registro inteiro. Isto permite leituras independentes da informação armazenada, fazendo do RAID 4 um array perfeitamente ajustado para ambientes transacionais que requerem muitas leituras pequenas e simultâneas.

Raid nível 5. É frequentemente usado e funciona similarmente ao RAID 4, mas

supera alguns dos problemas mais comuns sofridos por esse tipo. As informações sobre paridade para os dados do array são distribuídas ao longo de todos os discos do array , ao invés de serem armazenadas num disco dedicado, oferecendo assim mais desempenho que o RAID 4, e, simultaneamente, tolerância a falhas. Para aumentar o desempenho de leitura de um array RAID 5, o tamanho de cada segmento em que os dados são divididos pode ser optimizado para o array que estiver a ser utilizado. O desempenho geral de um array RAID 5 é equivalente ao de um RAID 4, exceto no caso de leituras sequenciais, que reduzem a eficiência dos algoritmos de leitura por causa da distribuição das informações sobre paridade. A informação sobre paridade é distribuída por todos os discos; perdendo-se um, reduz-se a disponibilidade de ambos os dados e a paridade, até à recuperação do disco que falhou. Isto causa degradação do desempenho de leitura e de escrita.



Raid nível 6. É um padrão relativamente novo, suportado por apenas algumas

controladoras. É semelhante ao RAID 5, porém usa o dobro de bits de paridade, garantindo a integridade dos dados caso até 2 dos HDs falhem ao mesmo tempo. Ao usar 8 HDs de 20 GB cada um em RAID 6, teremos 120 GB de dados e 40 GB de paridade.

Raid nível 0 (zero) + 1. É uma combinação dos níveis 0 (Striping) e 1 (Mirroring),

onde os dados são divididos entre os discos para melhorar o rendimento, mas também utilizam outros discos para duplicar as informações. Assim, é possível utilizar o bom rendimento do nível 0 com a redundância do nível 1. No entanto, é necessário pelo menos 4 discos para montar um RAID desse tipo. Tais características fazem do RAID 0 + 1 o mais rápido e seguro, porém o mais caro de ser implantado. No RAID 0+1, se um dos discos vier a

falhar, o sistema vira um RAID 0.



Raid nível 1 + 0 (zero). O RAID 1+0, ou 10, exige ao menos 4 discos rígidos. Cada par

será espelhado, garantindo redundância, e os pares serão distribuídos, melhorando desempenho. Até metade dos discos pode falhar simultaneamente, sem colocar o conjunto a perder, desde que não falhem os dois discos de um espelho qualquer — razão pela qual usam-se discos de lotes diferentes de cada ‘lado’ do espelho. É o nível recomendado para bases de dados, por ser o mais seguro e dos mais velozes, assim como qualquer outro uso onde a necessidade de economia não se sobreponha à segurança e desempenho.

Raid nível 50. É um arranjo híbrido que usa as técnicas de RAID com paridade em

conjunção com a segmentação de dados. Um arranjo RAID-50 é essencialmente um arranjo com as informações segmentadas através de dois ou mais arranjos.

Raid nível 100. Basicamente é composto do RAID 10+0. Normalmente ele é

implementado utilizando uma combinação e software e hardware, ou seja, implementa-se o RAID 0 via software sobre o RAID 10 via Hardware.

GERENCIAMENTO DE BUFFER

Um dos principais objetivos do sistema de banco de dados é minimizar o número de

transferência de blocos entre o disco e a memória. Uma maneira de reduzir o número de acessos ao disco é manter o máximo de blocos possíveis em memória principal. O objetivo é maximizar a chance de que, quando um bloco for acessado, ele já esteja na memória principal, assim não haverá a necessidade de acessar o disco.

Como não é possível manter todos os blocos na memória principal, precisamos gerenciar a alocação do espaço disponível na memória principal para o armazenamento dos blocos. O buffer é a parte da memória principal disponível para o armazenamento de cópias dos blocos de disco. Há sempre uma cópia mantida em disco de cada bloco, mas a cópia no disco pode ser uma versão mais antiga do que a versão do buffer. O subsistema responsável pela alocação do espaço disponível em buffer é chamado de gerenciador de buffer.



Os programas em um sistema de bando de dados podem fazer solicitações ao gerenciador de buffer quando precisarem de um bloco do disco. Se o bloco já estiver no buffer, o endereço do bloco na memória principal é passado ao requisitante. Se o bloco não estiver em buffer, o gerenciador primeiramente alocará espaço no buffer para o bloco, retirando algum outro bloco, se necessário, para liberar espaço para o novo bloco. O bloco retirado é escrito de volta no disco apenas se tiver sido modificado desde a última vez em que foi escrito no disco. Então, o gerenciador de buffer lê o bloco do disco copiando-o no buffer e passa o endereço do bloco na memória principal para o requisitante. As ações internas do gerenciador são transparentes para os programas que emitem as solicitações de blocos de discos.

O objetivo da estratégia de substituição de blocos no buffer é minimizar os acessos ao disco. Quando não há mais lugar disponível no buffer, um bloco deve ser removido, antes que um novo bloco possa ser copiado para o buffer. Tipicamente, os sistemas usam o esquema de LRU – menos recentemente utilizado – na qual o bloco que foi referenciado menos recentemente é escrito de volta no disco e removido do buffer. Além destes, existem outras políticas como a FIFO (first in first out) – figura abaixo - ou MRU (most recently used).

A estratégia utilizada por um gerenciado de buffer para a substituição de blocos é

influenciada por outros fatores além do tempo no qual o bloco será referenciado novamente. Se o gerenciador receber informações do subsistema de controle de concorrência indicando quais solicitações estão sendo atrasadas, ele pode usar essas informações para alterar sua estratégia de substituição de blocos. O subsistema de recuperação de falhas também impõe restrições rigorosas à substituição de blocos. Se um bloco tiver sido modificado, o gerenciador de buffer não tem permissão de escrever de volta no disco a nova versão do bloco no buffer, uma vez que isso destruiria a versão antiga. Em vez disso, o gerenciador de blocos deve obter a permissão do subsistema de recuperação de falhas antes de escrever um bloco de volta. O subsistema de recuperação de falhas pode demandar que determinados outros blocos tenham sua saída forçada antes de dar permissão para que o gerenciador de buffer remova o bloco solicitado.



PROCESSAMENTO DE CONSULTAS

Os processamentos de consulta são atividades envolvidas em extrair dados de um

banco de dados. Essas atividades incluem a tradução de consultas expressas em linguagens de alto nível do banco de dados em expressões que podem ser implementadas no nível físico do sistema de arquivos, otimizações, traduções e na avaliação de consultas.

O custo do processamento de uma consulta é determinado pelo acesso ao disco, que é lento se comparado ao acesso à memória. Normalmente, há muitas estratégias possíveis para processar uma determinada consulta, especialmente se a consulta for complexa. A diferença entre uma estratégia boa e uma estratégia ruim, em termos do número de acessos de disco exigidos, é frequentemente significativa, e pode ser de grande magnitude. Consequentemente, vale a pena para o sistema gastar uma quantia significativa de tempo na seleção de uma estratégia boa para processar uma consulta, até mesmo se a consulta for executada somente uma vez.

Os passos envolvidos no processamento de consulta são ilustrados na figura a seguir, tendo como passos básicos: análise sintática e tradução, otimização e avaliação.

Antes de o processamento da consulta ter início, o sistema deve traduzir a consulta em uma forma utilizável. Uma representação interna mais útil é aquela baseada na álgebra relacional estendida. Assim, a primeira ação que o sistema tem de tomar no processamento de uma consulta é traduzi-la em sua forma interna. Na geração da forma interna da consulta, o analisador sintático confere a sintaxe da consulta do usuário, verifica se os nomes das relações que aparecem na consulta são nomes de relações no banco de dados. Uma representação da consulta em uma árvore sintática é gerada, e, então, traduzida para uma expressão algébrica relacional.

Podemos expressar as grandes classes de consultas nas formas de álgebra relacional, cálculo relacional e grafo de consultas.

A álgebra relacional é constituída por operações: Operações unárias



Seleção σ

Projeção π

Operações binárias

União ∪

Diferença -

Produto cartesiano X

Operações derivadas Junção natural

Divisão ÷

Interseção ∩



Uma consulta na representação da álgebra relacional: Consulta C1 Nome dos empregados que não possuem dependentes

πnome_emp(empregado) - πnome_emp(empregado

dependente) Consulta C2 select saldo from conta where saldo < 2500

πsaldo (σsaldo<2500(conta))

Fazendo referência ao cálculo relacional, expressamos nossas consultas em

notações próximas às expressões matemáticas. Consulta C3 Nome e salário dos empregados que ganham mais que 5000

C3: { e[nome], e[salário] | e ∈ Empregado ^ e[salário] > 5000 }

Por fim, as consultas em sistemas de banco de dados, são expressas na forma de

grafo de consulta (plano de avaliação). Consulta C4 Nome e salário dos empregados que trabalham no departamento DC

πnome_emp, salário



σnome_dep = ‘DC’

EMPREGADO DEPARTAMENTO Os diferentes planos de avaliação para uma determinada consulta podem ter custos

diferentes. Não se espera que os usuários escrevam suas consultas de uma maneira que sugiram o plano de avaliação mais eficiente. Em vez disso, é responsabilidade do sistema construir um plano de avaliação de consulta que minimize seu custo.

A otimização de consultas é o processo de selecionar o plano de avaliação de consulta mais eficiente para uma consulta. Um aspecto da otimização acontece ao nível da álgebra relacional. Faz-se uma tentativa de encontrar uma expressão que é equivalente à expressão dada, tentando encontrar uma expressão mais eficiente para execução. Para escolher entre diferentes planos de avaliação de consulta, o otimizador deve estimar o custo de cada plano de avaliação. O cálculo do custo exato da avaliação de um plano normalmente não seria possível sem executar o plano de fato. Em vez disso, os otimizadores fazem uso de informações estatísticas sobre as relações, como os tamanhos das relações e as profundidades dos índices, para realizar uma boa estimativa do custo de um plano.

Essas estatísticas incluem: Número de tuplas na relação r. Tamanho de um registro (tupla) da relação r em bytes. Número de valores distintos que aparecem na relação r para um determinado

atributo. Essas estatísticas nos permitem estimar os tamanhos dos resultados de várias

operações, como também o custo para executar as operações.

PROCESSAMENTO DE TRANSAÇÕES

Uma transação é uma unidade de execução de programa que acessa e,

possivelmente, atualiza vários itens de dados. Uma transação, geralmente, é o resultado da execução de um programa de usuário escrito em uma linguagem de manipulação de dados de alto nível ou em uma linguagem de programação, e é delimitada por declarações da



forma begin transaction e end transaction. A transação consiste em todas as operações ali executadas, entre o começo e o fim da transação.

Para assegurar a integridade dos dados, exigimos que o sistema de banco de dados mantenha as seguintes propriedades das transações (ACID):

Atomicidade. Ou todas as operações da transação são refletidas corretamente no bando de dados ou nenhuma o será.

Consistência. A execução de uma transação isolada (ou seja, sem a execução concorrente de outra transação) preserva a consistência do banco de dados.

Isolamento. Embora diversas transações possam ser executadas de forma concorrente, o sistema garante que, para todo par de transações Ti e Tj, Ti tem a sensação de que Tj terminou sua execução antes de Ti começar, ou que Tj começou sua execução após Ti terminar. Assim, cada transação não toma conhecimento de outras transações concorrentes no sistema.

Durabilidade. Depois da transação completar-se com sucesso, as mudanças

que ela faz no banco de dados persistem, até mesmo se houver falhas no sistema.

O acesso ao bando de dados é obtido pelas dias seguintes operações:

read (x), que transfere o item de dados X do banco de dados para um buffer local alocado à transação que executou a operação de read.

write (x), que transfere o item de dados X do buffer local da transação que executou a operação de write de volta ao banco de dados.

Como exemplo, seja Ti uma transação que transfere 50 reais da conta A para a conta

B: Ti: read (A); A := A – 50; write (A); read (B); B := B + 50; write (B); Na ausência de falhas, todas as transações completam-se com sucesso. Entretanto,

como observamos anteriormente, nem sempre uma transação pode completar-se com sucesso. Nesse caso, a transação é abortada. Uma transação completada com sucesso é chamada efetivada (committed). Portanto, uma transação deve estar em um dos seguintes estados:

Ativa, ou estado inicial; a transação permanece neste estado enquanto

estiver executando. Em efetivação parcial, após execução da última declaração.



Em falha, após a descoberta de que a execução normal já não pode se realizar.

Abortada, depois que a transação foi desfeita e o banco de dados foi restabelecido ao estado anterior do início da execução da transação.

Em efetivação, após a conclusão com sucesso. O diagrama de estado correspondente a uma transação é mostrado a seguir.

Dizemos que uma transação foi efetivada somente se ela entrou no estado de

efetivação. Analogicamente, dizemos que uma transação abortou somente se ela entrou no estado de abortada. Uma transação é dita concluída se estiver em efetivação ou abortada.

Os sistemas de processamento de transações, normalmente, permitem que diversas transações sejam executadas de modo concorrente. Permitir que múltiplas transações concorram na atualização de dados traz diversas complicações em relação à consistência desses dados. Assegurar a consistência, apesar da execução concorrente de transações, exige trabalho adicional; é muito mais fácil insistir na execução das transações sequencialmente, uma de cada vez, cada uma começando somente depois que a anterior se completou.

A motivação para usar a execução concorrente em um banco de dados é essencialmente a mesma para usar multiprogramação em um sistema operacional. Quando várias transações são processadas de modo concorrente, a consistência do banco de dados pode ser destruída, mesmo que cada transação individual seja executada com correção. O sistema de banco de dados deve controlar a interação entre as transações concorrentes para impedi-las de destruir sua consistência. Isso é feito por meio de uma variedade de mecanismos chamadas de esquemas de controle de concorrência (Schedule).

Para compreensão do estado concorrente da execução das transações, estudemos alguns cenários com duas transações. A transação T1 transfere 50 reais da conta A para a conta B. Já a transação T2 transfere 10 por cento do saldo da conta A para a conta B.



Sejam mil e dois mil reais os valores correntes das contas A e B, respectivamente.

Suponha que as duas transações sejam executadas em sequencia, T1 seguida de T2.

Depois de executada estas transações sequencialmente, os valores das contas A e B

são 855 e 2.145 reais, respectivamente. Assim, o montante de dinheiro das contas A e B são preservados depois da execução de ambas as transações.

Analogicamente, se as transações forem executadas em outra sequencia, desta vez

T2 seguida de T1, novamente, conforme esperada, a soma A + B é preservada, e os valores finais das contas A e B são 850 e 2.150 reais, respectivamente.



Alternado para cenários de execução concorrente das transações, vejamos o resultado final da execução ao lado. Nesta situação, chegamos ao mesmo resultado obtido durante a execução sequencial na ordem T1 seguida de T2. A soma A + B é preservada.

Nem todas as execuções concorrentes resultam em um estado correto. Para ilustrar, considere a escala de execução da figura ao lado. Depois de sua execução, chegamos a um estado tal que os valores para as contas A e B são 950 e 2.100 reais, respectivamente. Esse estado final é inconsistente, já que apareceram 50 reais durante a execução concorrente. Realmente, a soma A + B não é preservada na execução das duas transações.

SERIALIZAÇÃO DE TRANSAÇÕES

O sistema de banco dados deve controlar a execução concorrente de transações

para assegurar que o estado do banco de dados permaneça consistente. Considerando que as transações são programas, é difícil, pelo caráter da computação, determinar quais são as operações exatas que uma transação executa, e como as operações de várias transações interagem.

A execução concorrente de transações provoca o entrelaçamento de transações. Para termos uma execução correta, temos que garantir um entrelaçamento de transações correto produzindo um estado consistente no banco de dados.



Para tanto, partimos de uma premissa que a execução de uma transação é correta, se executada isoladamente, produzindo sempre como saída um estado consistente do banco de dados. De igual forma, garantimos o padrão de corretude dos schedules a partir do seguinte teorema:

Toda execução serial de transações é correta.

S = T1 T2 T3 ... Tn-1 Tn Seja um schedule S. Se S produz um estado de banco de dados igual ao produzido

por alguma execução serial do mesmo conjunto de transações, então a execução S é correta.

Para que possamos determinar a equivalência de schedules, devemos a partir de um conjunto T = { T1, T2, ..., Tn } de transações, encontrar schedules cujas execuções produzam o mesmo estado no banco de dados que a execução de algum schedule serial sobre o conjunto T.

Existem 3 (três) tipos de equivalência de schedules: Estado final Visão Conflito



Na equivalência de estado final (FSR), dados dois schedules sobre um conjunto T de

transações, estes serão equivalentes de estado final (S ≈FS S’) se, e somente se:

Têm as mesmas operações pertencentes às transações de T Produzem o mesmo estado final no banco de dados, se forem executadas

sobre o mesmo estado inicial

O grande problema desta abordagem fica por conta dos schedules não guardarem os conceitos de estados inicial e final.

Já na equivalência de visão (VSR), dois schedules S e S’sobre um conjunto T de

transações são equivalentes de visão (S ≈V S’) se, e somente se:

Têm as mesmas operações pertencentes a transações de T

Para cada operação ri(x) de Ti ∈ T, o valor lido por ri é o mesmo nos dois

schedules Se wi(x) é a última operação de escrita sobre x em S, então wi(x) é a última

operação sobre x em S’

O desafio encontrado na equivalência de visão é manter o controle sobre todas as operações de leitura e escrita.

Antes de abordarmos a equivalência por conflito, vamos estudar o conceito de

operações em conflito. Operações conflitantes são: Operações de transações distintas Executadas sobre o mesmo objeto e Pelo menos uma delas é uma operação de escrita (write)

T1 = r1(x) w1(x)

T2 = r2(x) w2(y)

S = r2(x) r1(x) w2(y) w1(x)



Com isso, na equivalência de conflito (CSR) dois schedules S e S’ sobre um conjunto

T de transações são equivalentes de conflito (S ≈C S’) se, e somente se:

Têm as mesmas operações pertencentes a transações de T Ordenam (sequenciam) as operações em conflito da mesma forma

Para qualquer duas operações em conflito pi ∈ OP(Ti) e qj ∈ OP(Tj), com i ≠ j,

se pi <s qj, então pi <s’ qj

T1=r1(y)r1(x)w1(y) T2=r2(x)r2(y)w2(x) S=r1(y)r1(x)r2(x)w1(y)r2(y)w2(x)

S’=r1(y)r1(x)w1(y)r2(x)r2(y)w2(x) Como exemplo, podemos verificar:

SS = r2(x) w2(x,5) r1(x) w1(x,10) e o valor de inicial de x é 2

S1 = r1(x) r2(x) w2(x,5) w1(x,10)

S1 produz o mesmo estado final que SS, então S1 é serializável por estado final. S1 é

correto, embora não seja serializável por visão (o valor lido por r1(x) é diferente nos dois schedules) e nem por conflito.

Diante do exposto, temos que:

FSR ⊃VSR ⊃CSR

Para determinarmos se um schedule S é serializável por conflito, devemos verificar se S é equivalente por conflito a algum schedule serial SS sobre o mesmo conjunto de transações, como abaixo:

T1=r1(y)r1(x)w1(y) T2=r2(x)r2(y)w2(x)



T3=r3(y)r3(x)w3(z) S=r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)r3(x)w2(x)w3(z)

SS=r3(y)r3(x)w3(z)r1(y)r1(x)w1(y)r2(x)r2(y)w2(x) Ainda podemos definir a serializabilidade por conflito de um determinado schedule

S, por meio do seguinte teorema:

Um schedule S é serializável por conflito ⇔ o grafo de

serialização de S não contém ciclos. Um grafo de serialização de um schedule S está definido para um conjunto T de

transações. SG(S) é um grafo direcionado, com a seguinte definição: SG(S) = (V,E), onde

V = conjunto T de transações, e Ti Tj ∈ E se, e somente se:

Ti e Tj pertencem ao conjunto T de transações

∃ p ∈ OP(Ti), q ∈ OP(Tj), tal que p conflita com q e p <S q

Veja o exemplo abaixo, para um determinado conjunto T = { T1, T2, T3 }. S=r3(y)r1(y)r1(x)r2(x)w1(y)r2(y)r3(x)w2(x)w3(z)

Como podemos observar no schedule acima as operações: r3(y) conflita com w1(y) r3(x) conflita com w2(x) r1(x) conflita com w2(x), e assim podemos definir que o schedule S é

serializável por conflito, pois não produz um grafo cíclico.



CONTROLE DE CONCORRÊNCIA

Vimos que uma propriedade fundamental da transação é o isolamento.

Quando diversas transações são executadas de modo concorrente em um banco de dados, a propriedade do isolamento pode não ser preservada. É necessário que o sistema controle a interação entre transações concorrentes; esse controle é alcançado por meio de uma larga gama de mecanismos chamados esquemas de controle de concorrência.

Todos os esquemas de controle de concorrência têm por base a propriedade da serialização, isto é, todos os esquemas garantem que a ordenação de processamento é serializada. Um meio para garantir a serialização é obrigar que o acesso aos itens de dados seja feito de maneira mutuamente exclusiva, isto é, enquanto uma transação acessa um item de dados, nenhuma outra transação pode modificá-lo. O método mais usado para sua implementação é permitir o acesso a um item de dados somente se ele estiver bloqueado. Há vários modos por meio dos quais um item de dado pode ser bloqueado, dentre eles:

Compartilhado. Se uma transação Ti obteve um bloqueio compartilhado

sobre o item Q, então Ti pode ler, mas não escrever Q. Exclusivo. Se uma transação Ti obteve um bloqueio exclusivo do item Q,

então Ti pode tanto ler como escrever Q.

Precisamos que toda transação solicite o bloqueio do item Q de modo apropriado, dependendo do tipo de operação realizada em Q. A solicitação é direcionada para o gerenciador do controle de concorrência. A transação pode realizar suas operações somente depois que o gerenciador de controle de concorrência conceder (grants) o bloqueio para a transação.

O modo compartilhado é compatível com o modo compartilhado, mas não

com o modo exclusivo. A qualquer hora podem ser feitos diversos bloqueios compartilhados simultaneamente (por diferentes transações) sobre um item de dado em particular. Uma solicitação de bloqueio exclusivo precisa esperar até que um bloqueio compartilhado termine para ser efetivada.

Uma transação solicita bloqueio compartilhado do item de dado Q

executando a instrução lock-S(Q). Analogamente, um bloqueio exclusivo é solicitado pela instrução lock-X(Q). Um item de dado Q pode ser desbloqueado via instrução unlock(Q).

Como ilustração, considere novamente o sistema bancário simplificado.

Sejam A e B duas contas que são acessadas pelas transações T1 e T2. A transação T1 transfere 50 reais da conta A para a conta B e tem a forma:



A transação 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 reais, respectivamente. Se

essas duas transações são executadas serialmente, na ordem T1, T2 ou T2, T1, então a transação T2 mostrará o valor de 300 reais. Se, no entanto, essas transações forem executadas concorrentemente, a escala de execução abaixo pode ocorrer. Nesse caso, a transação T2 mostrará o resultado de 250 reais, que não é correto. A razão deste erro provém da falha de bloqueio em tempo hábil no item de dado B, com isso T2 mostra uma situação inconsistente.



Quando uma transação solicita o bloqueio sobre um determinado item de dado em particular, e nenhuma outra transação mantém o mesmo item de dado bloqueado de modo conflitante, tal bloqueio pode ser concedido. Entretanto, é preciso ter cuidado para evitar o seguinte cenário. Suponha que a transação T2 tenha um bloqueio compartilhado sobre um item de dado e outra transação T1 solicite um bloqueio exclusivo do mesmo item. Enquanto isso, uma transação T3 pode solicitar um bloqueio compartilhado sobre o mesmo item de dado. O bloqueio é compatível 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 transação T4 que solicita um bloqueio compartilhado sobre o mesmo item de dado e ele é concedido antes que T3 libere o dado.

De fato, é possível que haja uma sequência de transações solicitando

bloqueios compartilhados sobre um item de dado, e que cada uma delas libere seu bloqueio um pouco antes de que um novo bloqueio seja concedido à outra transação, de modo que T1 nunca consegue bloqueio exclusivo. A transação T1 poderá nunca ser processada, e ela é chamada de inane.

Podemos evitar a inanição de transações da seguinte forma. Quando uma

transação T1 solicita o bloqueio do item de dados Q de modo particular M, o bloqueio é concedido, contanto que:

1. Não haja nenhuma outra transação com bloqueio sobre Q cujo modo de

bloqueio seja conflitante com M. 2. Não haja nenhuma outra transação que esteja esperando um bloqueio sobre Q e

que tenha feito sua solicitação de bloqueio antes de T1. Um dos protocolos que garante a serialização é o protocolo de bloqueio em

duas fases. Esse protocolo exige que cada transação emita suas solicitações de bloqueio e desbloqueio em duas fases:

1. Fase de expansão. Uma transação pode obter bloqueios, mas não pode liberar nenhum.

2. Fase de encolhimento. Uma transação pode liberar bloqueios, mas não consegue obter nenhum bloqueio novo.

Inicialmente, uma transação está em fase de expansão. A transação adquire

os bloqueios de que precisa. Tão logo a transação libere um bloqueio, ela entra na fase de encolhimento e não poderá solicitar novos bloqueios. O bloqueio em duas fases não garante a ausência de deadlock. Um sistema está em estado de deadlock se há um conjunto de transações, tal que a transação desse conjunto está esperando outra transação também nele contida. Mais precisamente, há um conjunto de transações esperando {T0, T1, ..., Tn}, tal que T0 está esperando por um item de dado mantido por T1, T1 está esperando por um item de dado mantido por T2, ..., Tn-1 está aguardando um item mantido por Tn, e Tn esperando um item de dado mantido por T0. Nenhuma dessas transações poderá prosseguir em uma situação dessas.

Há dois métodos principais para o tratamento de deadlock. Podemos usar o

protocolo de prevenção de deadlock para garantir que o sistema nunca entrará em tal



situação. Ou podemos permitir que o sistema entre em estado de deadlock e, então, removê-lo dessa situação, recuperando-o por meio dos esquemas de detecção e recuperação de deadlock.

São propostos dois esquemas diferentes de prevenção de deadlock usando

timestamp3: 1. O esquema esperar-morrer (wait-die) tem por base uma técnica de não-

preempção. Quando uma transação 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 contrário, Ti será revertida (morta). Por exemplo, suponha que as transações T22, T23 e T24 tenham timestamps 5, 10 e 15, respectivamente. Se T24 solicita um item de dado mantido por T23, então T24 será desfeita.

2. O esquema ferir-esperar (wound-wait) tem por base a técnica de preempção e é uma contrapartida para o esquema esperar-morrer. Quando uma transação Ti solicita um item de dado mantido por Tj, Ti poderá esperar somente se possuir timestamp maior que Tj (ou seja, Ti é mais nova que Tj). Caso contrário, Tj será desfeita (Tj é ferida por Ti). Retornando ao nosso exemplo anterior, com as transações T22, T23 e T24, se T22 solicitar um item de dado mantido por T23, então o item de dado será liberado de T23, e T23 será desfeita. Se T24 solicitar um item de dado mantido por T23, então T24 esperará.

Se um sistema não usa um protocolo resistente ao deadlock, ou seja, que

garanta que deadlocks não aconteçam, então um esquema para detecção e recuperação precisa ser aplicado. Um algoritmo que examina o estado do sistema é evocado periodicamente para determinar se um deadlock está ocorrendo. Se estiver, então o sistema precisa tentar recuperar-se. Para isso, ele precisa:

Manter informações sobre a alocação corrente dos itens de dados para

transações, assim como qualquer solicitação de itens de dados pendente. Proporcionar um algoritmo que use essas informações para determinar se o

sistema entrou em estado de deadlock. Recuperou-se de um deadlock quando o algoritmo de detecção determinar

que ele ocorreu.

Os deadlocks podem ser precisamente descritos em termos de um gráfico chamado de gráfico de espera. Há um deadlock no sistema se, e somente se, o gráfico de espera contiver um ciclo. Cada transação envolvida em um ciclo está em deadlock. Para detectar deadlocks, o sistema precisa manter o gráfico de espera e, periodicamente, evocar um algoritmo que verifique a existência de ciclos.

É uma sequência de caracteres, indicando a data e/ou tempo em que um determinado evento ocorreu.



Para ilustrar esses conceitos, considere o gráfico de espera abaixo, que exibe a seguinte situação:

A transação T25 está esperando as transações T26 e T27. A transação T27 está esperando a transação T26. A transação T26 está esperando a transação T28.

Uma vez que não há ciclos, o sistema não está em estado de deadlock.

Suponha, agora, que a transação T28 esteja solicitando um item preso por T27. A aresta T28 T27 será adicionado ao gráfico de espera, alterando o estado do sistema, como mostrado na figura abaixo.

A essa altura, o gráfico contém o ciclo: T26 T28 T27 T26, implicando

que as transações T26, T27 e T28 estão todas em deadlock. Quando um algoritmo de detecção determina a existência de um deadlock, o

sistema precisa recuperar-se desse deadlock. A solução mais comum é reverter uma ou mais transações para quebrar o deadlock. Devem ser tomadas três ações:

1. Selecionar uma vítima. Dado um conjunto de transações em deadlock,

precisamos determinar quais transações (ou transação) serão desfeitas para quebra do deadlock. Poderíamos reverter as transações que representam o menor custo. Infelizmente, o termo mínimo custo não é preciso. Muitos fatores podem determinar o custo de um rollback, incluindo:

a. A quanto tempo a transação está em processamento e quanto tempo será

ainda necessário para que a tarefa seja completada. b. Quantos itens de dados a transação usou. c. Quantos itens ainda a transação usará até que se complete. d. Quantas transações serão envolvidas no rollback.



2. Rollback. Uma vez decidido que uma transação em particular será revertida, precisamos determinar até que ponto ela deverá ser revertida. Entretanto, é mais eficaz reverter a transação somente o suficiente para a quebra do deadlock. Mas esse método exige que o sistema mantenha informações adicionais sobre o estado de todas as transações em execução.

3. Inanição. Em um sistema no qual a seleção de vítimas tem por base fatores de

custo, pode acontecer de uma mesma transação ser sempre escolhida vítima. Assim, essa transação nunca se completa. Essa situação é chamada de inanição. Precisamos garantir que uma transação seja escolhida vítima somente um número finito de vezes. A solução mais comum é incluir o número de reversão no fator de custos.

TÉCNICAS DE RECUPERAÇÃO

Um sistema de computador, como qualquer outro equipamento mecânico ou

elétrico, está sujeito a falhas. Há grande variedade de falhas, incluindo quebra de disco, falha de energia, erro de software, fogo na sala e equipamento ou mesmo sabotagem. Em cada um desses casos informações podem ser perdidas. Portanto, o sistema de banco de dados deve precaver-se para garantir que as propriedades de atomicidade e durabilidade das transações, sejam preservadas, a despeito de tais falhas. Uma parte integrante do sistema de banco de dados é o esquema de recuperação que é responsável pela restauração do banco de dados para um estado consistente que havia antes da ocorrência de falha.

Vários 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 não resulta na perda de informação no sistema. As falhas mais difíceis de tratar são aquelas que resultam em perda de informação.

Falha de transação. Dois tipos de erros podem causar uma falha de

transação: Erro lógico. A transação não pode mais continuar com sua execução normal

devido a alguma condição interna, como uma entrada inadequada, um dado não encontrado, overflow ou limite de recurso excedido.

Erro de sistema. O sistema entrou em um estado inadequado (deadlock), com isso, uma transação não pode continuar com sua execução normal. A transação, entretanto, pode ser reexecutada posteriormente.

Queda do sistema. Há algum mau funcionamento de harware ou um bug no software de banco de dados ou no sistema operacional que causou a perda do conteúdo no armazenamento volátil e fez o processamento da transação parar. O conteúdo de armazenamento não-volátil permanece intacto e não corrompido.



Falha de disco. Um bloco de disco perde seu conteúdo em função da quebra do cabeçote ou da falha durante uma operação de transferência de dados. São usadas para recuperação do sistema após a falha, as cópias dos dados em outros discos ou backups de arquivos em meios terciários, como fitas.

Para determinar como o sistema deve recuperar-se das falhas, necessitamos identificar os modos de falha possíveis dos equipamentos usados para armazenar dados. Depois, devemos considerar como esses modos de falha afetam o conteúdo do bando de dados. Então, poderemos desenvolver algoritmos para assegurar a consistência do banco de dados e a atomicidade da transação, a despeito das falhas. Esses algoritmos são conhecidos como algoritmos de recuperação, embora tenham duas partes:

Ações tomadas durante o processamento normal da transação a fim de garantir que haja informação suficiente para permitir a recuperação de falhas.

Ações tomadas em seguida à falha, recuperando o conteúdo do banco de dados para um estado que assegure sua consistência, a atomicidade da transação e durabilidade.

O sistema de banco de dados reside permanentemente em armazenamento

não-volátil e é particionado em unidades de armazenamento de comprimento fixo chamadas de bloco. Os blocos são unidades de transferência de dados para e a partir do disco e podem conter vários itens de dados. Movimentos de blocos entre disco e memória principal são iniciados por meio das duas operações

seguintes: 1.input(B) transfere o bloco físico B para a memória principal. 2. output(B) transfere o bloco de buffer B para o disco e troca-o, no disco,

pelo bloco físico apropriado. Cada transação Ti tem uma área de trabalho privada na qual cópias de todos

os itens de dados acessados e atualizados são mantidas. Essa área de trabalho é criada quando a transação é iniciada; ela é removida quando a transação é efetivada ou abortada. Cada item de dados x mantido na área de trabalho da transação Ti é denotado por xi. A transação Ti interage com o sistema de banco de dados pela transferência de dados para e de sua área de trabalho até o buffer de sistema. Transferimos os dados usando as duas operações a seguir:



1. read(X) designa o valor do item de dado X para a variável local xi. Essa operação é executada como segue: a. Se o bloco Bx no qual reside X não está na memória principal então é 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 variável local xi para o item de dado X no bloco de

buffer. Essa operação é executada como segue: a. Se o bloco Bx na qual reside X não está na memória principal, então emite um

input(Bx). b. Designa o valor de xi para X no buffer Bx.

A estrutura mais usada para gravar modificações no banco de dados é o log.

O log é uma sequência de registros de log que mantém um arquivo atualizado das atividades no banco de dados. Há diversos tipos de registros de log. Um registro de atualização de log descreve uma única escrita do banco de dados e tem os seguintes campos:

Identificador de transação é um identificador único da transação que realiza

operação de escrita. Identificador de item de dado é um identificador único do item de dado

escrito. Normalmente, é a localização 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á após a escrita. <Ti start> a transação Ti começou. <Ti, Xj, V1, V2> a transação Ti realizou uma escrita no item de dado Xj. Xj

tinha valor V1 antes da alteração e terá o valor V2 após a escrita. <Ti commit> a transação Ti foi efetivada. <Ti abort> a transação Ti foi abortada.

Sempre que uma transação realiza uma escrita, é essencial que o registro de log para aquela escrita seja criado antes de o banco de dados ser modificado. Havendo o registro de log, podemos enviar a modificação ao banco de dados quando ela for conveniente. Também conseguimos inutilizar uma modificação que já tenha sido enviada ao banco de dados. Podemos desfazê-la usando o campo de valor antigo do registro de log.

A técnica de adiar modificações garante a atomicidade de transações quando todas as modificações do banco de dados são escritas no log, adiando a execução de todas as operações write de uma transação até sua efetivação parcial. Quando uma transação é parcialmente efetivada, as informações no log associadas àquela transação são usadas para a execução das escritas adiadas. Se o sistema cair antes de completar a transação ou se a transação for abortada, então as informações do log são simplesmente ignoradas.

Para ilustração, reconsidere nosso exemplo de sistema bancário simplificado. Seja T0 uma transação que transfere 50 reais da conta A para a conta B. Essa transação é definida como segue:



Seja T1 uma transação que debita 100 reais da conta C.

Suponha que essas transações sejam executadas serialmente, T0 seguida por

T1 e os valores das contas A, B e C antes da execução, eram de 1.000, 2.000 e 700 reais, respectivamente. A porção do log contendo as informações relevantes sobre essas duas transações é apresentada a seguir.

Usando o log, o sistema pode lidar com qualquer falha que resulte em perda

de informação no armazenamento volátil. O esquema de recuperação usa o seguinte procedimento:

redo(Ti) define o valor de todos os itens de dados atualizados pela transação

Ti para os novos valores. Após a ocorrência de uma falha, o subsistema de recuperação consulta o log

para determinar quais transações têm de ser refeitas (redo). A transação 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 transação completar sua execução, as informações no log serão usadas na restauração do sistema para o estado consistente anterior.

Retornemos a nosso exemplo bancário com as transações T0 e T1 executadas

uma após a outra. A figura abaixo mostra o log resultante da execução de T0 e T1.



Assuma que a queda ocorra logo após o registro de log do passo write(B) da

transação T0 ter sido escrito em armazenamento estável (a). Quando o sistema retorna, nenhuma ação refazer tem de ser tomada, já que nenhum registro de efetivação aparece no log. Agora assumamos que a queda venha logo após o registro de log para o passo write(C) da transação T1 ter sido escrito em armazenamento estável (b). Nesse caso, quando o sistema retorna, a operação redo(T0) é realizado, já que o registro <T0 commit> aparece no log em disco.

A técnica de atualização imediata permite que as modificações no banco de

dados sejam enviadas enquanto as transações ainda estão no estado ativo. Na ocorrência de uma queda ou de uma falha de transação, o sistema deverá usar o campo relativo ao valor antigo dos registros de log, para restauração dos itens de dados modificados, levando-os ao valor anterior ao início da transação. Essa restauração é conseguida por meio de operação undo (desfazer) descrita a seguir.

Antes que uma transação Ti inicie sua execução, o registro <Ti start> é escrito

no log. Durante sua execução, qualquer operação 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.

Usando o log o sistema pode tratar de qualquer falha que não resulte na

perda de informação em armazenamento não-volátil. O esquema de recuperação usa dois procedimentos de recuperação:

undo(Ti) retorna aos valores antigos todos os itens de dados atualizados pela transação Ti.

redo(Ti) ajusta os valores de todos os itens de dados atualizados pela transação Ti para os valores novos.

Após a falha, o esquema de recuperação consulta o log para determinar quais

transações necessitam ser refeitas e quais necessitam ser inutilizadas. Essa classificação de transações é conseguida como segue:

A transação Ti tem de ser inutilizada se o log contém o registro <Ti start>, mas não contém o registro <Ti commit>.

A transação Ti tem de ser refeita se o log contém tanto o registro <Ti start> quanto o registro <Ti commit>.

Quando uma falha de sistema ocorre, devemos consultar o log para determinar aquelas transações que necessitam ser refeitas e aquelas que necessitam ser



inutilizadas. A princípio, para isso, deveríamos pesquisar todo o log. Há duas grandes dificuldades nessa abordagem:

1. O processo de pesquisa consome tempo. 2. Muitas das transações que, de acordo com o algoritmo, necessitam ser refeitas já

escreveram suas atualizações no banco de dados. Embora refazê-las não cause dano algum, a recuperação torna-se mais longa.

Para reduzir esses tipos de overhead, introduzimos os checkpoints (pontos de controle). Durante a execução, o sistema mantém o log usando uma das técnicas descritas anteriormente. Além disso, o sistema cria checkpoints periodicamente, que exigem a execução da seguinte sequência de ações:

1. Saída, para armazenamento estável, de todos os registros residentes na memória principal.

2. Saída, para disco, de todos os blocos de buffer modificados. 3. Saída, para armazenamento estável, de um registro de log <checkpoint>. Não é permitido às transações processar quaisquer ações de atualização,

como escrever em um bloco de buffer ou escrever um registro de log, enquanto um checkpoint está em progresso.

A técnica checkpoint descrita acima exige que todas as atualizações ao banco de dados sejam temporariamente suspensas enquanto o checkpoint está em processo. É possível modificar a técnica para permitir que as atualizações iniciem no momento em que o registro de checkpoint é escrito, mas antes de os blocos de buffer modificados serem escritos no disco. Então, o checkpoint gerado é um fuzzy checkpoint (ponto de controle indistinto).

A idéia é a seguinte. Em vez de reexaminar o log de trás para frente a fim de encontrar um registro de checkpoint, armazenamos a localização em log do último registro de checkpoint em uma posição fixa no disco. Entretanto, essa informação não é atualizada quando o registro checkpoint é escrito. Ao contrário, antes de o registro checkpoint ser escrito, uma lista com todos os blocos de buffer modificados é criada. A informação último checkpoint é atualizada somente após todos os blocos de buffer, da lista de blocos de buffer modificados, terem sido escritos no disco. O protocolo de precedência de escrito do log deve ser seguido quando os blocos de buffer são enviados para saída.

LINGUAGEM ESTRUTURADA DE PESQUISA - SQL

Uma linguagem de consulta é a linguagem por meio da qual os usuários obtêm informações do banco de dados. Essas linguagens são, tipicamente, de nível mais alto que as linguagens de programação tradicionais. As linguagens de consulta podem ser categorizadas como procedurais ou não-procedurais. Em uma linguagem procedural, o usuário deve "ensinar" ao sistema a realização de uma sequência de operações no banco de dados para obter o resultado desejado. Em uma linguagem não-procedural, o usuário descreve a informação desejada sem fornecer um procedimento específico para a obtenção dessas informações.

Os sistemas de banco de dados comerciais oferecem uma linguagem de consulta que incorpora elementos de ambos os enfoques: procedurais e não-procedurais. A álgebra relacional é procedural, enquanto o cálculo relacional de uma tupla e o cálculo relacional de um domínio são não-procedurais.



O nome "SQL" significa "Structured Query Language" - Linguagem Estruturada de Pesquisa. Essa linguagem, de grande utilização, teve seus fundamentos no modelo relacional de Codd (1970). Sua primeira versão recebeu o nome de SEQUEL ("Structured English Query Language"), sendo definida por D. D. CHAMBERLIN, entre outros, em 1974, nos laboratórios de pesquisa da IBM (Califórnia). Em 1975, foi implementado um protótipo de aplicação dessa nova linguagem. Entre 1976 e 1977, o SEQUEL foi revisado e ampliado, e teve seu nome alterado para "SQL" por razões jurídicas.

A SQL se tornou um padrão de fato, no mundo dos ambientes de banco de dados relacionais. Bastava agora se tornar de direito. Então, em 1982, o American National Standard Institute (ANSI) tornou a SQL padrão oficial de linguagem em ambiente relacional.

O modelo relacional é constituído basicamente de tabelas, cada qual contendo linhas (registros, tuplas) e colunas. Os registros na tabela não são ordenados e sua localização se faz por meio de um campo-chave, ou seja, um campo que assume o papel de chave primária da tabela. É por intermédio dessa chave que se identifica uma, e somente uma, ocorrência do valor contido no campo.

Atualmente, a linguagem SQL assume um papel muito importante nos sistemas de gerenciamento de banco de dados, podendo ter muitos enfoques, como apresenta a figura anterior:

• Linguagem interativa de consulta - Por meio de comandos SQL, os usuários podem montar consultas poderosas sem a necessidade da criação de um programa, podendo utilizar Forms ou ferramentas de montagem de relatório;

• Linguagem de programação para acesso a banco de dados - Comandos SQL embutidos em programas de aplicação que acessam os dados armazenados;

• Linguagem de administração de banco de dados - 0 responsável pela administração do banco de dados (DBA) pode utilizar comandos SQL para realizar suas tarefas;

• Linguagem cliente/servidor - Os programas (cliente) dos computadores pessoais usam comandos SQL para se comunicarem por meio de uma rede



local, compartilhando os dados armazenados em um único local (servidor). A arquitetura cliente/servidor minimiza o tráfego de dados pela rede;

• Linguagem para banco de dados distribuído - A SQL auxilia na distribuição dos dados por meio de vários nós conectados ao sistema de computação. Auxilia também na comunicação de dados com outros sistemas;

• Caminho de acesso a outros bancos de dados em diferentes máquinas - A SQL auxilia na conversão entre diferentes produtos de banco de dados colocados em diferentes máquinas (de micro até mainframe).

Por ser uma linguagem de numerosas aplicações, a SQL pode manipular

objetos de diferentes classes entre as funções de um SGBD:

• Definição de dados (DDL) - permite ao usuário a definição da estrutura e

organização dos dados armazenados, e as relações que existem entre eles;

• Manipulação de dados (DML) - permite ao usuário ou a um programa de aplicação, a inclusão, remoção, seleção ou atualização de dados previamente armazenados no banco;

• Controle de acesso - protege os dados de manipulações não autorizadas;

• Compartilhamento de dados - coordena o compartilhamento dos dados por

usuários concorrentes, sem, contudo interferir na ação de cada um deles; • Integridade dos dados - auxilia no processo de definição da integridade dos

dados, protegendo contra corrupções, inconsistências e falhas do sistema de computação.

CLÁUSULAS SQL



Quando o administrador do banco de dados deseja operar com a linguagem

SQL, este faz uso de cláusulas SQL que compõem comandos de definição e manipulação de dados. Dentre estes comandos temos operações de criação, alteração e remoção de tabelas, assim como manipulação dos dados, como inserção, atualização, deleção, e principalmente as várias operações possíveis para selecionarmos os dados.

Além dos comandos que iremos abordar abaixo, existem cláusulas que

permitem criação de visões, trabalho com definição de índices, que auxiliam nas pesquisas, e possibilidades de junções de duas ou mais tabelas em condições de consultas. Possibilidades que podem ser estudadas posteriormente, aumentando o conhecimento à cerca da linguagem de consultas SQL.

a. Cláusula CREATE DATABASE

Para podermos criar e inserir tabelas de uma aplicação em Banco de Dados, dependendo do ambiente de SGBD que estivermos utilizando, criar o DATABASE, ou seja criar um banco de dados no qual estarão residentes as tabelas do nosso sistema.

Exemplos:

1. CREATE DATABASE vendas

Cria o database vendas no device default com tamanho de default de 2 MB.

2. CREATE DATABASE vendas ON default = 256 Cria o database vendas no device default com 256 MB.

b. Cláusula CREATE TABLE



Uma vez que já criamos o DATABASE, ou seja, nosso banco de dados da aplicação, podemos então partir para a criação das nossas tabelas.

Alguns campos podem receber o valor NULL (nulo) e o campo definido como chave primária, além de não poder receber NULL, deve ser UNIQUE (sem repetições).

Exemplos:



Obs.: a cláusula REFERENCE estabelece a restrição de integridade

referencial entre as tabelas (chaves estrangeiras). Porém, só poderão ser incluídas essas restrições se as tabelas referidas na cláusula REFERENCE já tiverem sido criadas.

c. Cláusula ALTER TABLE

É muito comum realizarmos a criação das tabelas, e posteriormente

desejarmos efetuar alteração na estrutura da tabela, como: inserção de um novo campo, alterar o tamanho de um campo, definir um tipo diferente ao campo da tabela, mudar a estrutura das chaves da tabela.

d. Cláusula DROP TABLE

Para realizarmos a deleção da tabela criada, assim como seus dados e suas referências a outras tabelas, usamos o comando DROP.

e. Cláusula INSERT

Após criarmos nosso banco de dados e nossas tabelas, é hora de

inserirmos dados como registros das tabelas criadas. Para isso contamos com o INSERT:

A cláusula VALUE especifica os dados que você deseja inserir na tabela.

Exemplo: desejemos adicionar o produto ‘parafuso’ a tabela produto.

f. Cláusula UPDATE

Podemos por meio do comando de atualização, especificarmos uma determinada coluna e alterar o seu valor, ou através de condições de seleção, identificarmos algumas linhas para que sejam alterados valores.



Exemplo: alterar o valor unitário do produto cuja descrição é ‘parafuso’ de R$ 1.25 para R$ 1.62.

g. Cláusula DELETE

Para apagarmos registros de nossa tabela utilizamos o simples comando de DELETE.

Exemplo: apagar todos os registros da tabela vendedor cuja faixa de comissão seja NULA.

h. Cláusula SELECT

Uma das operações mais comuns em banco de dados é a de selecionar

as informações armazenadas por meio do comando SELECT.

O comando SELECT tem algumas palavras chaves em sua estrutura básica:

SELECT – especifica as colunas da tabelas que queremos selecionar; FROM – determina de qual tabela queremos as colunas; WHERE – informa quais critérios para a seleção.

EXEMPLOS:



1. Selecionando colunas específicas da tabela

Situação problema: desejamos colher informações a cerca das colunas (descrição, unidade, valor_unitário) da tabela produto.

2. Selecionado todas as colunas da tabela

Situação problema: desejamos colher informações a cerca de todas as colunas de nossa tabela vendedor.

3. Alterando o cabeçalho da coluna no momento da seleção

Situação problema: desejamos colher informações a cerca das colunas (código_vendedor, nome_vendedor, salário_fixo, faixa_comissão), entretanto desejamos que na saída da seleção o cabeçalho das colunas sejam alteradas na nossa tabela vendedor.

4. Manipulando dados numéricos – operadores aritméticos

Situação problema: podemos realizar operações aritméticas sobre uma seleção de colunas da nossa tabela vendedor. No caso, fazemos operação de multiplicação em cima do valor contido na coluna salário_fixo.

5. Selecionando apenas algumas linhas da tabela, de acordo com uma condição

Situação problema: desejamos colher informações a cerca das colunas (num_pedido, código_produto, quantidade), de nossa tabela item_do_pedido. Entretanto o resultado apresentado deverá obedecer ao critério de que na coluna quantidade só podermos ter valores iguais a 35.



Situação problema: situação semelhante a anterior, porém quando se trata de uma condição na qual a coluna possui dados do tipo caractere o valor deve aparecer entre aspas simples. Neste caso queremos saber quais os clientes (nome_cliente) da tabela cliente residem na cidade de Niterói.

Situação problema: com o exemplo anterior surgem os conceitos de operadores lógicos (and, or, not). Neste caso desejamos listar todos os produtos (descrição_produto) que tenham unidade igual a M e o valor unitário (val_unit) igual a R$ 1.05 na tabela produto.

Situação problema: já neste caso pretendemos listar todos os clientes com seus respectivos endereços (nome_cliente, endereço), que moram em São Paulo ou estejam na faixa de CEP entre ‘30077000’ e ‘30079000’, pertencentes a tabela cliente.

Situação problema: ainda sobre os operadores lógicos, temos um caso que desejamos saber todos os pedidos (num_pedido) que não possuam prazo de entrega igual a 15 dias, da tabela de pedidos.

Situação problema: listar o código e descrição dos produtos (código_produto, descrição_produto) que tenham seu valor unitário (val_unit) dentro da faixa de preço de R$ 0.32 até R$ 2.00 pertencentes a tabela produto.



Situação problema: no exemplo acima temos a utilização do operador LIKE, que trabalha sobre colunas do tipo CHAR. Juntamente com a utilização deste operador podemos associar os símbolos curinga % - que substitui uma palavra ou _ - que substitui um caractere. Aqui temos a situação de querermos saber todos os produtos (código_produto, descrição_produto) que tenham seu nome iniciando pela letra Q.

Situação problema: agora com a utilização do operador IN fazemos referência a valores que estejam contidos dentro de um conjunto informado. No caso acima desejamos saber todos os vendedores (nome_vendedor) que estejam inseridos nas faixas de comissões ‘A’ ou ‘B’ da tabela vendedor.

Situação problema: desejamos colher todos os campos da tabela cliente na qual os clientes não tenham inscrição estadual, ou seja, a coluna IE seja nula.

6. Ordenando os dados selecionados

Situação problema: com o uso da cláusula ORDER BY podemos ordenar os dados selecionados na pesquisa SELECT. No exemplo acima temos a listagem das colunas (nome_vendedor, salário_fixo) da tabela vendedor ordenados de forma default (ASCENDENTE) pela coluna nome_vendedor.

Situação problema: já no caso acima percebemos que quando desejamos ter uma ordenação DESCENDENTE precisamos referenciar na sintaxe. Aqui temos os clientes listados segundos suas colunas (nome_cliente, cidade, UF) ordenados de forma descendente primeiramente por UF, depois por cidade.



7. Realizando cálculos com as informações selecionadas

Situação problema: podemos também trabalhar com campos que não pertençam à tabela original, mas que seja fruto de cálculos efetuados sobre campos da tabela. Na situação acima temos que mostrar o novo salário fixo dos vendedores (novo_salário), que estejam dentro da faixa de comissão ‘C’, calculado com base em um reajuste de 75% sobre o salário_fixo acrescido de R$ 120.00 de bonificação. Este resultado foi ordenado pelo nome_vendedor.

8. Utilizando funções de agregação sobre conjuntos

Situação problema: fazendo uso de algumas funções na linguagem SQL, podemos solicitar na consulta o menor (MIN) e o maior (MAX) salários contidos na tabela vendedor.

Situação problema: temos a possibilidade também de obtermos a soma por meio da função SUM. No exemplo pretendemos mostrar a quantidade total pedida ao produto de código igual a ‘78’ na tabela item_pedido.

Situação problema: existe a possibilidade de obtermos a média de um grupo de valores, como na situação acima onde desejamos obter a média (AVG) dos salários fixos de todos os vendedores.

Situação problema: podemos também quantificar o número de vezes de um determinado valor ou de uma condição. Neste exemplo queremos saber quantos vendedores (COUNT) ganham acima de R$2.500,00 de salário fixo.



Situação problema: a cláusula DISTINCT foi utilizada para evitar redundâncias nos resultados, eliminando assim repetições de valores em relação a uma coluna. No exemplo anterior pretendemos saber quais as unidades de produtos, diferentes, na tabela produto.

9. Agrupando informações selecionadas

Situação problema: podemos por meio da cláusula GROUP BY produzirmos o agrupamento sobre uma determinada coluna da tabela. No exemplo destacado temos a situação na qual podemos contar o número de produtos (total_produtos = COUNT(*)) que cada pedido contém (GROUP BY num_pedido). Geralmente a cláusula GROUP BY é utilizada em conjunto com as operações COUNT e AVG.

Situação problema: ainda na forma de agrupamento dos resultados, podemos por meio da cláusula HAVING trabalhar com condições de agrupamento. No exemplo temos que listar os pedidos (GROUP BY num_pedido) que possuam mais do que três produtos (HAVING COUNT (*) > 3).



Hino do Estado do Ceará

Poesia de Thomaz LopesMúsica de Alberto NepomucenoTerra do sol, do amor, terra da luz!Soa o clarim que tua glória conta!Terra, o teu nome a fama aos céus remontaEm clarão que seduz!Nome que brilha esplêndido luzeiroNos fulvos braços de ouro do cruzeiro!

Mudem-se em flor as pedras dos caminhos!Chuvas de prata rolem das estrelas...E despertando, deslumbrada, ao vê-lasRessoa a voz dos ninhos...Há de florar nas rosas e nos cravosRubros o sangue ardente dos escravos.Seja teu verbo a voz do coração,Verbo de paz e amor do Sul ao Norte!Ruja teu peito em luta contra a morte,Acordando a amplidão.Peito que deu alívio a quem sofriaE foi o sol iluminando o dia!

Tua jangada afoita enfune o pano!Vento feliz conduza a vela ousada!Que importa que no seu barco seja um nadaNa vastidão do oceano,Se à proa vão heróis e marinheirosE vão no peito corações guerreiros?

Se, nós te amamos, em aventuras e mágoas!Porque esse chão que embebe a água dos riosHá de florar em meses, nos estiosE bosques, pelas águas!Selvas e rios, serras e florestasBrotem no solo em rumorosas festas!Abra-se ao vento o teu pendão natalSobre as revoltas águas dos teus mares!E desfraldado diga aos céus e aos maresA vitória imortal!Que foi de sangue, em guerras leais e francas,E foi na paz da cor das hóstias brancas!

Hino Nacional

Ouviram do Ipiranga as margens plácidasDe um povo heróico o brado retumbante,E o sol da liberdade, em raios fúlgidos,Brilhou no céu da pátria nesse instante.

Se o penhor dessa igualdadeConseguimos conquistar com braço forte,Em teu seio, ó liberdade,Desafia o nosso peito a própria morte!

Ó Pátria amada,Idolatrada,Salve! Salve!

Brasil, um sonho intenso, um raio vívidoDe amor e de esperança à terra desce,Se em teu formoso céu, risonho e límpido,A imagem do Cruzeiro resplandece.

Gigante pela própria natureza,És belo, és forte, impávido colosso,E o teu futuro espelha essa grandeza.

Terra adorada,Entre outras mil,És tu, Brasil,Ó Pátria amada!Dos filhos deste solo és mãe gentil,Pátria amada,Brasil!

Deitado eternamente em berço esplêndido,Ao som do mar e à luz do céu profundo,Fulguras, ó Brasil, florão da América,Iluminado ao sol do Novo Mundo!

Do que a terra, mais garrida,Teus risonhos, lindos campos têm mais flores;"Nossos bosques têm mais vida","Nossa vida" no teu seio "mais amores."

Ó Pátria amada,Idolatrada,Salve! Salve!

Brasil, de amor eterno seja símboloO lábaro que ostentas estrelado,E diga o verde-louro dessa flâmula- "Paz no futuro e glória no passado."

Mas, se ergues da justiça a clava forte,Verás que um filho teu não foge à luta,Nem teme, quem te adora, a própria morte.

Terra adorada,Entre outras mil,És tu, Brasil,Ó Pátria amada!Dos filhos deste solo és mãe gentil,Pátria amada, Brasil!

a tecnicas de implementacao de banco de dados

Documents