Sistemas Gerenciadores de Bancos de Dados

Autor: Andrea Cristina Oliveira Alves

Apostila de Sistemas Gerenciadores de Bancos de Dados

2007

Captulo I - Introduo
No incio da dcada de 60, foram lanados os primeiros sistemas gerenciadores de banco de dados (SGBD), tendo como principal proposta o aumento na produtividade nas atividades de desenvolvimento e manuteno de sistemas, at ento realizadas de forma artesanal em linguagens de programao convencionais de primeira e segunda gerao.

Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares e amigveis com o advento da microinformtica. Cada vez mais as fronteiras entre esses dois mundos estreitam-se e a concorrncia pelo domnio do mercado de SGBD, tem levado seus diversos fabricantes a sofisticarem seus produtos. Cada nova verso lanada, incorpora novidades como interfaces grficas, ferramentas de apoio ao desenvolvimento, utilitrios para gerenciamento de BD e facilidades para extrao de dados. Essa evoluo vem tornando o trabalho de programadores, analistas e usurios menos artesanal, com reflexos na qualidade e produtividade.

1.1. Principais conceitos

1.1.1. Bancos de Dados: Coleo de dados inter-relacionados, que representam informaes sobre um domnio especfico; Ex.: Agenda telefnica, Base de dados de uma empresa, Acervo de uma biblioteca.

1.1.2. Sistema Gerenciador de Bancos de dados: Software com recursos suficientes para facilitar a manipulao das informaes dos bancos de dados e o desenvolvimento de programas aplicativos. Ex.: MySQL- Oracle- SQL Server

Programas de Aplicao/Consulta

Sistema de Banco de Dados

SGBD Software para processar manipulao

Banco de dados
Software de Acesso aos Dados

Meta Dados

Dados

1.1.3. TABELAS

Uma tabela uma coleo de REGISTROS do mesmo tipo, ou seja, referentes Constitui que da a o um mesmo assunto do dos pelo e com no o mesmo so de de formato padro os a e (layout). dados, gerao consultas

componente atravs desejada

sistema

qual

armazenados base para

combinados informao

programas usurio,

servem atravs

relatrios

on-line. Um sistema de controle de notas, por exemplo, pode armazenar seus dados em diversas item do tabelas, cada uma contendo informaes sobre um

determinado etc.

sistema:

ALUNO,

PROFESSOR,

MATRIA,

NOTA,

Essas gerar, por

informaes exemplo, o

podem

ser

combinadas ESCOLAR, a

atravs PAUTA

de ou

programas uma tela

para de

BOLETIM

CONSULTA DE NOTAS.

1.1.4. REGISTRO

Um registro constitudo por conjunto de campos valorados (contendo dados). Consiste na unidade de armazenamento e recuperao da informao em um arquivo. Geralmente, os registros de um arquivo possuem um formato padro (layout), definido pela seqncia, tipo e tamanho dos campos que o compem. Porm, algumas linguagens de programao permitem a criao de registros com layouts deferentes em um mesmo arquivo, recurso este que raramente utilizado.

1.1.5. CAMPO

a unidade bsica formadora de um registro. Constitui a clula da informao. a menor poro de um arquivo que pode ser referenciada por um programa. Cada campo possui NOME, TIPO e TAMANHO.

1.1.6. CHAVE PRIMRIA (PRIMARY KEY - PK)

A CHAVE PRIMRIA (ou simplesmente CHAVE) o identificador nico de um registro em um arquivo. Pode ser constituda de um campo (CHAVE SIMPLES) ou pela combinao de dois ou mais campos (CHAVE COMPOSTA), de tal maneira, que no existam dois registros no arquivo com o mesmo valor de chave primria.

Em regra, todo arquivo deve possuir uma chave primria, que permita a identificao inequvoca do registro, especialmente, para dar maior consistncia aos processos de incluso, alterao e excluso de dados. Para que no ocorram duplicatas nos valores da chave, os campos que a compem so de PREENCHIMENTO OBRIGATRIO (NOT NULL). Na escolha da chave primria de um arquivo deve-se buscar campos que possuam ESTABILIDADE no valor armazenado. A escolha do NMERO DO TELEFONE como chave de um cadastro de clientes, por exemplo, seria inadequada, por que esse valor pode mudar com freqncia. Sem considerar que o cliente pode ter mais de um telefone... Deve-se tambm evitar a escolha de campos que possam causar AMBIGIDADE em relao aos valores nele contidos. Nesse sentido, seria inadequado a escolha do campo NOME para chave de um cadastro de clientes, haja vista, que um mesmo nome pode ser

escrito

de

vrias

formas.

Por

exemplo:

LUS,

LUIZ,

LOUIS,

LOYS,

LUYS.

Se desejssemos cobrar uma fatura de um cliente com um nome como esse, a probabilidade de erramos o cliente seria grande. Alm disso, a extenso do campo (30 ou mais caracteres) um outro aspecto que aumenta a possibilidade de erros.

1.1.7. CHAVE SECUNDRIA

A chave secundria pode ser formada por um campo ou pela combinao de campos (SIMPLES / COMPOSTA). utilizada como parmetro (filtro) para seleo de registros no arquivo em consultas, emisso de relatrios ou processos de atualizao simultnea de um grupo de registros. Por exemplo, para aumentarmos o valor do salrio dos analistas em 10%, poderamos utilizar o campo FUNO do arquivo CADASTRO DE FUNCIONRIOS como parmetro (chave secundria) no processo de seleo dos registros a serem alterados. Em sntese, a chave secundria o campo ou combinao de campos do arquivo que permite a recuperao de mais de um registro no arquivo.

Portanto, no possui a caracterstica de unicidade proposta para a chave primria.

1.1.8. CHAVE ESTRANGEIRA

um atributo ou conjunto de atributos cujos valores aparecem necessariamente na chave primria de uma tabela. Este mecanismo permite a implementao de relacionamentos no modelo relacional. Exemplo: Departamento (CodDep, NomeDepto) Empregado(CodEmp, NomeEmp, CodDepto, CatFunc)

Exerccios 1. Defina com suas palavras a diferena entre Bancos de dados e Sistemas Gerenciadores de Bancos de dados. 2. D exemplos de arquivos, registros e campos 3. Simule a criao de um banco de dados. Este banco dever conter 3 tabelas. Defina chave primria, secundria e estrangeira para as tabelas criadas.

Capitulo II - Caractersticas de SGDBS

2.1. Controle de Redundncia No processamento tradicional de arquivos, cada grupo de usurios deve manter seu prprio conjunto de arquivos e dados. Desta forma, acaba ocorrendo redundncias que prejudicam o sistema com problemas como: toda vez que for necessrio atualizar um arquivo de um grupo, ento todos os grupos devem ser atualizados para manter a integridade dos dados no ambiente como um todo; a redundncia desnecessria de dados levam ao armazenamento excessivo de informaes, ocupando espao que poderia estar sendo utilizado com outras informaes. 2.2. Compartilhamento de Dados Um SGBD multiusurio deve permitir que mltiplos usurios acessem o banco de dados ao mesmo tempo. Este fator essencial para que mltiplas aplicaes integradas possam acessar o banco. O SGBD multiusurio deve manter o controle de concorrncia para assegurar que o resultado de atualizaes sejam corretos. Um banco de dados multiusurios deve fornecer recursos para a construo de mltiplas vises. 2.3. Restrio a Acesso no Autorizado Um SGBD deve fornece um subsistema de autorizao e segurana, o qual utilizado pelo DBA para criar contas e especificar as restries destas contas; o controle de restries se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao SGBD. 2.4. Representao de Relacionamentos Complexos entre Dados Um banco de dados pode incluir uma variedade de dados que esto interrelacionados de vrias formas. Um SGBD deve fornecer recursos para se representar uma grande variedade de relacionamentos entre os dados, bem como, recuperar e atualizar os dados de maneira prtica e eficiente. 2.5. Tolerncia a Falhas Um SGBD deve fornecer recursos para recuperao de falhas tanto de software quanto de hardware.

Captulo 3. Arquitetura de SGBDS

3.1. Arquitetura em 3 nveis

A ANSI divide a arquitetura de banco de dados em 3 nveis distintos:

Nvel Externo Nvel do usurio Nvel Interno Nvel fsico Nvel Conceitual Nvel de conjunto de vises de usurios. Faz a ligao entre os outros dois.

3.1.1. Nvel Externo

O nvel externo o nvel do usurio individual. 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. Cada usurio tem uma linguagem sua disposio: Para o programador de aplicaes, essa linguagem ser uma linguagem de programao convencional (como PL/I, C+-f, Java) 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.

Cada usurio utiliza diferentes linguagens para utilizar um sgbd. Algumas destas tcnicas so chamadas de sub-linguagem, ou seja, linguagens que acopladas a outras, produzem os efeitos esperados.

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 departamento empregados, e ele poderia no ter nenhum conhecimento das ocorrncias de registros de fornecedores e peas vistas pelos usurios do Departamento de Compras. Assim, em geral, uma viso externa consiste em muitas ocorrncias de cada um dentre muitos tipos de registros externos (no necessariamente a mesma coisa que uni registro armazenado).* A sublinguagem de dados do usurio definida em termos de registros externos; por exemplo, uma operao DML de busca obter ocorrncias de registros externos, no ocorrncias de registros armazenados. Ou seja, ser feita a busca no nvel conceitual e no no nvel interno.

Para que isto funcione, tem de haver uma definio do mapeamento entre o esquema externo e o esquema conceitual subjacente.

3.1.2. NVEL CONCEITUAL A viso conceitual uma representao de todo o contedo 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 armazenados fisicamente. Em geral, ela tambm ser bastante d if e r e n t e do modo como os dados so visualizados por qualquer usurio em particular. 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, somada a uma coleo de ocorrncias de registros de empregados, mais uma coleo de ocorrncias de registros de fornecedores, somada a uma coleo de ocorrncias de registros de peas (etc. etc.). Um registro conceitual no necessariamente o mesmo que um registro externo, nem o mesmo que um registro armazenado. Na viso conceitual no haver nenhuma informao fsica, como ponteiros ou ndices de acesso. Neste nvel, devero existir todas as restries de segurana e integridade de dados.Na maior parte dos sistemas existentes, o "esquema conceitual" na verdade pouco mais que uma simples reunio de todos os esquemas externos individuais, somados a certas restries de segurana e integridade. Porm,

sem dvida, possvel que sistemas futuros eventualmente sejam muito mais sofisticados em seu suporte do nvel conceitual.

3.1.3.NVEL INTERNO O terceiro nvel da arquitetura o nvel interno. A viso interna uma representaro 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).

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

Para encerrar lembramos que, em certas situaes excepcionais, os programas aplicativos - em particular as aplicaes de natureza utilitria - 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 tuna 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.

3.1.4. MAPEAMENTOS Alm dos trs nveis bsicos, esta arquitetura envolve certos mapeamentos: um mapeamento conceitual/interno e vrios mapeamentos externos/conceitual: o O mapeamento conceitual/interno define a correspondncia entre a viso conceitual e o banco de dados armazenado; o Um mapeamento externo/conceitual define a correspondncia entre uma viso externa especfica e a viso conceitual.

A propsito, a maioria dos sistemas permite que a definio de certas vises externas seja expressa em-termos de outras (efetivamente, atravs de mapeamentos externos/externos), em vez de sempre exigir uma definio explcita do mapeamento no nvel conceitual - um recurso til se diversas vises externas forem bastante semelhantes umas s outras. Em particular, os sistemas relacionais oferecem essa capacidade. 3.2. ARQUITETURA CLIENTE/SERVIDOR Descrevemos at agora neste captulo os sistemas de bancos de dados sob o ponto de vista da cbamada ar-quitetura ANSI/SPARC. 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 hack end) e um conjunto de clientes (tambm chamados front ends). O servidor o prprio SGBD. Ele admite todas as funes bsicas de SGBDs -definio de dados, manipulao de dados, segurana e integridade cie dados, e assim por diante. Em particular, ele oferece todo o suporte de nvel externo, conceitual e interno que examinamos anteriormente. 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.

Usurios finais

Clientes

Servidor

Banco de dados

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. 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). Observamos que, tendo em vista que 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 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 uma 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.

Exerccios 1. Explique os trs nveis da arquitetura definida pela Ansi/Parc 2. Qual a funo do mapeamento 3. Explique a arquitetura Cliente/Servidor

Captulo 4. Linguagens de Bancos de Dados

Cada SGBD - Sistema Gerenciador de Banco de Dados - possui uma arquitetura interna prpria. A linguagem SQL padro funciona com qualquer banco de dados de estrutura relacional.

4.1.

SQL (Structured Query Language Linguagem de consulta estruturada

uma linguagem usada para a consulta, atualizao, criao e gerenciamento de banco de dados relacionais. um mtodo para selecionar determinados registros de um banco de dados, seguindo um critrio especificado a sua escolha. O SQL considerado uma linguagem padro para o gerenciamento de banco de dados relacionais. Com o SQL possvel definir tabelas, ndices, domnios, etc., para a criao e manuteno de uma base de dados; Fazer consultas simples ou complexas em uma base de dados; Fazer operaes de incluso, alterao e cancelamento nas tabelas que compem o banco de dados de um sistema

4.2.

Linguagem de Definio de Dados (DDL)

a linguagem utilizada para criar o esquema de banco de dados. O resultado de uma DDL pode ser um conjunto de tabelas, a definio de indices (mtodo de acesso) ou de restries de integridade referencial. Exemplo: Exemplo de DDL SQL: CREATE TABLE cliente ( nome cidade rua ) VARCHAR(50), VARCHAR(35), VARCHAR(30)

4.3.

Linguagem de Manipulao de Dados (DML)

a linguagem que permite aos usurios do banco de dados manipularem os dados. atravs deste tipo de linguagem que os usurios manipulam os dados. comumente utilizada para busca de informao e modificaes no banco de dados; Exemplo de DML SQL: SELECT cidade, rua FROM custumer WHERE nome = Joo

Captulo 5. Transaes
5.1. TRANSAES Uma transao uma unidade lgica de trabalho; ela comea com a execuo de uma operao BEGIN TRANSACTION e termina com a execuo de uma operao COMMIT ou ROLLBACK. Considere a possibilidade da existencia de uma transao cuja finalidade transferir a quantia R$100 da conta 123 para a conta 456. Como voc pode ver, o que presumivelmente deveria ser uma operao indivisvel - "transferir dinheiro de uma conta para outra" - de fato envolve duas atualizaes separadas no banco de dados. Alm do mais, o banco de dados est em um estado incorreto entre essas duas atualizaes, no sentido de que no reflete um estado de coisas vlido no mundo real; logicamente, uma transferncia no mundo real, de uma conta para outra, no dever afetar a soma total de reais nas respectivas contas, mas, em nosso exemplo, a quantia de R$100 temporariamente ficar faltando entre as duas atualizaes. Assim, uma unidade lgica de

trabalho, que uma transao, no envolve necessariamente uma nica operao sobre o banco de dados. Em vez disso, ela geralmente envolve uma sequncia de vrias dessas operaes, cuja finalidade transformar um estado correto do banco de dados em outro estado tambm correto, sem necessariamente preservar a correo em todos os pontos intermedirios. BEGIN TRANSACTION; UPDATE CONTA 123 { SALDO := SALDO - $100 } ; IF ocorreu algum erro THEN GO TO UNDO ; END IF ;

UPDATE CONTA 456 { SALDO := SALDO + $100 } ; IF ocorreu algum erro THEN GO TO UNDO ; END IF ; COMMIT ; GO TO FINISH ; UNDO : /* trmino bem sucedido */ /* trmino mal sucedido */

Vejamos como ele funciona. Para simplificar, suponha que a transao tenha concludo com sucesso seu processamento de banco de dados; assim, a instruo no mbito do sistema que ela emite COMMIT, e no ROLLBACK. Ao receber essa requisio de COMMIT, o coordenador executa o seguinte processo em duas fases: Preparar: Primeiro, ele instrui todos os gerenciadores de recursos a ficarem prontos para "seguir qualquer caminho" na transao. Na prtica, isso significa que cada participante do processo - ou seja, cada gerenciador de recursos envolvidos - deve forar todas as entradas de log de recursos locais utilizados pela transao em seu prprio log fsico (isto , para o armazenamento no voltil; acontea o que acontecer da por diante, o gerenciador de recursos ter agora um registro permanente do trabalho que realizou para a transao, e ser capaz de completar o COMMIT de suas atualizaes ou cancel-las, como for preciso). Supondo-se que a gravao forada seja bem-sucedida, o gerente de recursos responder agora "OK" ao coordenador; caso contrrio, ele responder "No OK". COMMIT: Depois de receber respostas de todos os participantes, o coordenador fora a gravao de uma entrada em seu prprio log fsico, registrando sua deciso a respeito da transao. Se todas as respostas foram "OK", essa deciso ser COMMIT; se qualquer resposta tiver sido "No OK", a deciso ser "cancelar". De qualquer forma, o coordenador informar sua deciso a cada participante, e cada participante dever ento

fazer o COMMIT ou cancelar a transao de modo local, conforme tiver sido instrudo. Observe que cada participante tem de fazer o que lhe diz o coordenador na Fase 2 - esse o protocolo. Observe tambm que o aparecimento do registro de deciso no log fsico do coordenador assinala a transio da Fase l para a Fase 2. Se o sistema falhar em algum ponto durante o processo geral, o procedimento de reinicializao procurar o registro de deciso no log do coordenador. Se o encontrar, ento o processo de COMMIT de mas fases poder continuar do ponto em que foi interrompido. Se no achar o registro, ele presumir que a deciso foi "cancelar", e mais uma vez o processo poder ser concludo adequadamente. 5.2. Propriedades de Transaes As transaes possuem quatro propriedades importantes, que so chamadas
6

"propriedades ACID": Atomicidade, Consistncia,

Isolamento e Durabilidade. Resumindo:

Atomicidade: Ou todas as operaes da transao so refletidas corretamente no banco de dados ou nenhuma o ser. A idia 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 sos 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. Consistncia: A execuo de uma transao isolada (ou seja, sem execuo concorrente de outra transao) preserva a consistncia do banco de dados. Assegurar a permanncia da consistncia aps uma transao em particular de responsabilidade do programador da aplicao que codifica a transao. Essa tarefa pode ser facilitada por meio do teste automtico dos requisitos de integridade. Isolamento: Embora diversas transaes possam ser executadas de forma concorrente, o sistema garante que, para todo par de transaes 1 e 2, 1 tem a sensao de que 2 terminou sua execuo antes de 1 comear, ou que 2 comeou sua execuo aps 1 terminar. Assim, cada transao no toma conhecimento do outras transaes concorrentes no sistema. 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. 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 sido 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. Durabilidade: Depois da transao completar-se com sucesso, as mudanas que ela faz no banco de dados persistem, at mesmo se houverem falhas no sistema. 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. Assegurar a durabilidade responsabilidade de um componente

do sistema de banco de dados chamado de componente de gerenciamento de recuperao

5.2.1. Transaes Concorrentes Quando vrias transaes so executadas de modo concorrente no banco de dados, a consistncia dos dados no pode mais ser garantida. Ento, necessrio que o sistema controle a interao entre as transaes concorrentes. Como uma transao uma unidade que preserva a consistncia, uma execuo seqencial das transaes garante a preservao da consistncia. Portanto, exigimos que qualquer escala produzida pelo processamento concorrente de um conjunto de transaes tenha um efeito equivalente a uma escala produzida quando essas transaes so executadas seqencialmente em alguma ordem. Do sistema que garante essa propriedade diz-se que ele garante a serializao. H vrias noes diferentes de equivalncia que conduzem aos conceitos de serializao de conflito e serializao de viso. A serializao das escalas geradas por transaes concorrentes pode ser garantida por meio de um entre vrios mecanismos chamados de esquemas de controle de concorrncia. O componente de gerenciamento de controle de concorrncia do banco de dados o responsvel pela manipulao dos esquemas de controle da concorrncia. O

componente de gerenciamento da recuperao de um banco de dados o responsvel por assegurar as propriedades de atomicidade e durabilidade das transaes. Bloqueio O protocolo de bloqueio um conjunto de regras que estabelecem quando uma transao pode bloquear e desbloquear cada um dos itens de dados do banco de dados. O protocolo do bloqueio em duas fases permite que uma transao bloqueie um novo item de dado somente at desbloquear o primeiro deles. O protocolo garante a serializao, mas no est livre de deadlocks. Na ausncia de informaes a respeito do tipo de acesso que ser feito no item de dados, o protocolo de bloqueio em duas fases tanto necessrio quanto suficiente para garantia da serializao. O esquema da ordenao por timestamp garante a serializao pela seleo da ordem de execuo entre pares de transaes. Um nico timestamp associado a cada transao no sistema. Os timestamps das transaes determinam a ordem de serializao. Assim, se o timestamp da transao T1 menor que o da transao T2, o esquema garante que a escala de execuo produzida seja equivalente a uma escala serializada na qual a transao T1 aparece antes da transao T2. Isso feito revertendo a transao sempre que a ordem for violada. Vrios protocolos de bloqueio no so resistentes a deadlocks. Um modo de evitar deadlocks usando a preempo e o rollback de transaes. Para controla a preempo, marcamos um nico timestamp para cada transao. Esses timestamps so usados para decidir se uma transao dever ser revertida ou dever esperar. Se uma transao revertida, ela mantm o timestamp antigo quando reiniciada. Os esquemas de esperarmorrer e de ferir-esperar so dois esquemas com base em preempo. Outro mtodo para o tratamento de deadlocks usar o esquema de deteco de deadlock e recuperao. Para faz-lo, construdo um grfico de espera. Um sistema est em estado de deadlock se, e somente se, o grfico de espera contm um ciclo. Quando o algoritmo de deteco identifica um deadlock, o sistema precisa recuperar-se. Isso feito revertendo uma ou mais transaes para quebra do deadlock.

5.3. RECUPERAO DO SISTEMA

Informaes podem ser perdidas de um sistema computacional devido ocorrncia de falhas. Estas variam de falta de energia erros de software. Um sistema de banco de dados deve garantir propriedades como atomicidade e durabilidade de suas transaes mesmo que falhas ocorram. Um mecanismo

de recuperao que restaure o banco de dados para um estado consistente existente ante s da falha , portanto, de extrema importncia. Os algoritmos de recuperao em banco de dados so responsveis por assegurar a consistncia do banco de dados e a atomicidade das transaes. Para isto eles devem efetuar aes durante o processamento normal de uma transao garantindo que haja informao suficiente pra pe rmitir a recuperao, e aes aps a falha, que efetivamente recuperam o contedo do banco de dados para um estado consistente, garantindo a atomicidade da transao e a durabilidade.

5.3.1.Falhas em Bancos de Dados

Pode-se classificar as falhas da seguinte forma: Falha de transao: Esta falha pode ser causada por dois tipos de erro, erro lgico ou erro de sistema. Erro lgico ocorre quando uma condio interna impede a execuo normal da transao, como uma entrada inadequada ou um dado no encontrado. Quando o sistema entra num estado inadequado, impedindo a execuo normal de uma transao, como no caso de um deadlockdiz-se que ocorreu um erro de sistema. Queda do sistema: Esta falha causa a perda do contedo do armazenamento voltil, para ndo o processamento da transao, sem afetar o contedo do armazenamento novoltil. Causas comuns desta falha so mau funcionamento de hardware ou bug no software de banco de dados. Falha de disco: Esta falha leva perda do contedo do disco, pode ser causada pela que bra do cabeote.

5.3.2. Recuperao e Atomicidade

Ao ocorrer uma falha durante uma transao, solues do tipo re-executar ou ignorar podero levar o banco a um estado inconsistente. O problema est em modificar o banco de dados sem que a transao ser de fato efetivada.

Para evitar inconsistncias necessrio que todas ou nenhuma alterao relacionadas a uma transao sejam feitas no banco. Para manter a atomicidade devese mandar todas as alteraes para um armazenamento estvel, sem modificar o banco de dados. Isto permitir que, apesar de falhas, manter um estado consistente dos dados. Abaixo esto descritas duas tcnicas de realizar essa gravao.

5.3.3. Recuperao utilizando log

Recuperao baseada em log tcnica mais usada para gravar modificaes em um banco de dados. O log ou journal documenta as atividades em um banco de dados. Em especial, o log de atualizaes documenta todas as alteraes de registros. Os registros do log so gravados antes da modificao no banco, de forma que caso ocorra uma falha que interrompa uma transao, o banco de dados possa retornar a um estado consistente. Existem duas polticas de gravao quando se utiliza o log. No log, h algumas operaes primitivas que podem ser registradas: start Marca o inicio de uma transao, junto com o identificador desta. update Marca uma alterao em registro, mantendo o identificador da transao, do registro e valores atuais e/ou valores anteriores. commit Marca o fim de uma transao abort Marca o aborto de uma transao, sendo executado o rollback, restaurando o estado anterior.

5.3.4. Checkpoints

Como refazer todas as operaes do log custoso e o tamanho do log tende a crescer rpido, a recuperao de dados utilizando o log pode ser muito demorada. Muitas transaes j foram efetivadas em disco, no sendo necessrio refaz-las. Uma soluo para esse problema a criao de checkpoints, marcas no log onde todas as operaes de escrita anteriores ao checkpoint j foram efetivadas em disco. Logo s preciso refazer as transaes concludas que foram feitas depois da criao do checkpoint. Durante a criao do checkpoint, todos os registros de log residentes em memria so gravados em armazenamento estvel, seguido de blocos de buffer modificados.

Somente aps isto, armazenado o registro de log que marca a concluso do checkpoint.

Captulo 6. Integridade de Dados

Integridade de dados a garantia de que estes dados esto realmente corretos. impossvel evitar 100% de erros por parte dos operadores de dados, porm, existem algumas tcnicas bastante avanadas para evitar que isto acontea. A estas regras chamamos de restries de integridade.

Vamos pensar no seguinte exemplo: Vamos supor que ao invs de lanar no banco que um determinado funcionrio trabalhou 40 horas por semana, o operador digite 400. Qual seria uma forma de evitar que isto acontea? Basta definir atravs de restries que a carga horria de um funcionrio s poder variar entre 0 e 40 horas semanais. Ainda existir uma margem de erro, porm a delimitao impede erros gritantes e diminui as possibilidades. Outro exemplo o seguinte: Definir uma regra para que todos os fornecedores de uma determinada localidade tenham status X. Outra regra para que no possa haver dois fornecedores com o mesmo cdigo. Caso algum altere o cdigo de um fornecedor, devem ser comparados todos os campos que j existem no banco para saber se no h outro com este cdigo ou se este fornecedor j existe com outro cdigo. Cada remessa dever envolver um fornecedor existente, ou seja, isto evita que o operador lance um cdigo inexistente na hora de enviar o pedido.

6.2. Tipos de restries de integridade 6.2.1. Integridade de Domnio A integridade de domnio nada mais do que a integridade do campo como o tipo de dados correto, se permite null ou not null, defaults, check, etc. Estes mecanismos foram criados para dar integridade aos campos. Os tipos de dados tambm so caracterizados como integridade de domnio, se o tipo de dado estiver incorreto, ou com mais posies que o necessrio, pode haver ali um risco que quebre a integridade. O check aqui em nvel de campo apenas por exemplo: Tenho um campo Meses e quero que entre valores de 1 at 12 somente.

6.2.2. Integridade de Entidade A integridade de entidade nada mais que a integridade da tabela, isto conseguido atravs das Primary Keys, uma tabela sem PK uma tabela sem integridade de entidade. 6.2.3 Integridade Referencial A integridade referencial mais conhecida, so as Foreign Keys, nada mais que eu aceitar valores em minha entidade que esto em outra entidade, isto possvel a partir da integridade de entidade, eu apenas consigo criar Foreign Keys a partir de uma Primary Key, a integridade referencial consiste tambm em check em nvel de tabela e no em nvel de campo, no ato da criao da tabela crio um check, por exemplo: Tenho uma tabela com 2 campos Medico1, Medico2, e quero que um dos campos sempre seja preenchido no CodDep(PK) D2 D1 D5 Nome Produo Custos Pessoal MatrGerent 210 105 NULL importa qual, para isto preciso de um check em nvel de tabela. Ex.: Departamento

Empregado

Matr(PK) 100

Nome Ana

Endereo R. Pedro I, 12, A.

Funo Secretria

Salrio 500,00

Depart(FK) D1

Branco

250

Pedro

R.

J.

Silva,

24,

Engenheiro

1500,00

D1

Liberdade 108 210 105 Andr Paulo Snia R. Itlia, 33, B. Naes R. Par, 98, B. Estados R. Oliveira, 76, A. Tcnico Engenheiro Engenheiro 950,00 1810,00 2500,00 D2 D2 D1

Form alme

Branco

nte, um conjunto de atributos de uma relao R1 uma chave estrangeira se satisfaz s seguintes regras: Os atributos da chave estrangeira tm o mesmo domnio dos atributos da chave primria de outra relao R2. Um valor da chave estrangeira numa linha l1 de R1 possui o mesmo valor da chave primria para alguma linha l2 em R2 ou NULO. A integridade referencial estabelece que todo valor de chave estrangeira numa relao deve corresponder a um valor de chave primria de uma segunda relao ou deve ser nulo. Ex.:

Empregado(matrcula,nome,salrio,matr_supervisor) Ex.: "Nenhum empregado pode ganhar mais que seu gerente" "O nmero de horas mximo que um empregado pode trabalhar num projeto 40 horas". 6.3. Operaes de atualizao em relaes 6.3.1.Insero 1. Inserir <'102','Andr',null, 'Engenheiro', '1.980','D2'> => aceito sem problemas 2. Inserir <'100', 'Maria', null, 'Tcnica', '950','D1'> => viola a restrio de chave.

3. Inserir <null,'Ceclia',null,'Engenheiro','1.950','D1'> => viola restrio de integridade de entidade. 4. Inserir <'108','Mauro','Rua 4','Tcnico','980','B6'> => viola a restrio de integridade referencial. O que fazer quando se detectar uma violao de integridade? Rejeitar a insero (podendo explicar o porqu) Tentar corrigir a anomalia para depois inserir.

6.3.2.Remoo 1. Remover da tabela empregado a linha com matrcula = '100'. remoo aceita sem problemas. 2. Remover da tabela departamento a linha com CodDep = 'D1'. => viola a regra de integridade referencial. (empregados que esto alocados neste departamento.) O que fazer quando uma violao ocorrer numa remoo? Rejeitar a remoo Dar o efeito cascata na remoo, removendo todas as linha referenciadas por aquela linha que est sendo removida. Modificar os atributos referenciados para novos valores ou nulos (caso no faam parte da chave primria). Dos trs tipos de restries de integridade discutidas, uma operao de remoo poder violar apenas a integridade referencial.

6.3.3. Modificao 1. Modificar o salrio do empregado com matrcula='250'

=> operao aceita sem problemas. 2. Modificar o nmero do departamento da linha de empregado com matrcula '210' para 'D1' => operao aceita sem problemas. 3. Modificar o nmero do departamento de empregado '108' para 'D9' => viola a integridade referencial 4. Modificar a matrcula do empregado '100' para '250' => viola regra de integridade de chave. Exerccios: Seja as duas tabelas seguintes: Curso Codcurso(PK) C1 C2 C3 C4 C5 Descrio Sistemas de Informao Educao Fsica Farmcia Administrao Pedagogia CodUnid 156 156 156 156 156

Aluno RA(PK) 1050 1123 Nome Rafael Bandeira Ricardo Azevedo Endereo Rua das Camlias, 76 R. Bernardo Sayo, 156 Curso C1 C2

1896 1475

Mirela Domigues Juliana Didone

R. Roma, 33 R. Belo horizonte, 197, apto 105B.

C1 C4

1112

Carlos Eduardo Rocha

R. Carmpolis, 75

C3

Diante destas informaes, informe se as alteraes abaixo so possveis nas tabelas alunos e cursos. Caso no seja possvel, informe qual o tipo de restrio de integridade que a mesma est violando:

1- Inserir (1112, Ana Maria Bernardes, Rua das rosas, 350 , C8) 2- Inserir (1796, Joo da Silva, Rua 107, 52 , C3) 3- Inserir (null, Carlos Santana, Rua Afonso Pena, 12 , C4) 4- Deletar (C1, Sistemas de Informao, 156) 5- Alterar o cdigo de curso C2 para C16 6- Alterar o endereo do Aluno cujo RA 1112. 7- Alterar o cdigo do curso do aluno com RA 1050 para C3 8- Inserir (1012, Jos Maria Rocha, Rua do Calvrio, 115 , C10) 9- Deletar o aluno cujo RA 1123. 10- Inserir (1175, Silvana Andrade, Av. Joo Pinheiro, 46 , null) 6.3. Procedimentos Armazenados (Store Procedures)

Stored Procedures so semelhantes a sub-rotinas ou subprogramas desenvolvidos noutras linguagens de programao (p.e. C, Pascal, Basic, Java, etc.), mas que so guardados no servidor. Aceitam parmetros de entrada e retornam resultados. Isto , como qualquer subprograma, um procedimento permite a passagem de parmetros de entrada e de sada, aceitando valores e devolvendo algum tipo de resultado entidade que o invocou, que pode ser um outro procedimento, um gatilho ou mesmo uma aplicao externa cliente. As Stored procedures retornam um valor de status indicando se aconteceu um erro, e qual foi. So basicamente blocos de instrues SQL compiladas num nico plano de execuo.

6.3.1. Propsitos/Vantagens. - Diminuio do trfego na rede. A execuo destes programas no seio de um servidor permite reduzir substancialmente o trfego de rede provocado por aplicaes que solicitem ao servidor a execuo de instrues SQL. O servidor passa a ser assim no s servidor de dados, mas tambm servidor de programas para a manipulao dos dados. - Programao por mdulos. Um stored procedure aps ser guardado na BD, pode ser invocado vrias vezes num programa. Pode tambm ser alterado sem que haja necessidade de alterar em todos os lados. - Execuo mais rpida. Se uma operao tem muitas instrues T-SQL e/ou executada muitas vezes, os stored procedures conseguem ser mais rpidos, pois so compilados e otimizados no momento da sua criao. - Segurana. Pode ser dada permisso aos utilizadores para executar um stored procedure, mesmo que no tenham permisso para utilizar o mesmo cdigo diretamente atravs de um editor.

Exemplo dbitos dirios de parcelas de emprstimos create procedure PagaEmprstimo as update Emprstimos set ValorTotal = ValorTotal ValorParcela, NroParcelas = NroParcelas 1 where DiaVencimento = day(getdate()) Chamada de um storedprocedure exec PagaEmprstimo

6.4.

Gatilhos (Trigger)

Um Trigger bloco de comandos Transact-SQL que automaticamente executado quando um comando INSERT , DELETE ou UPDATE for executado em uma tabela do banco de dados.

Os Triggers so usados para realizar tarefas relacionadas com validaes , restries de acesso , rotinas de segurana e consistncia de dados ; desta forma estes controles deixam de ser executados pela aplicao e passam a ser executados pelos Triggers em determinadas situaes :

Mecanismos de validao envolvendo mltiplas tabelas Criao de contedo de uma coluna derivada de outras colunas da tabela Realizar anlise e e atualizaes em outras tabelas com base em alteraes e/ou incluses da tabela atual

A criao de um Trigger envolve duas etapas : 1. Um comando SQL que vai disparar o Trigger ( INSERT , DELETE , UPDATE) 2. A ao que o Trigger vai executar ( Geralmente um bloco de cdigos SQL ) Exemplo: Mostrar ao usurio que o valor do salrio no compatvel ao estado civil do funcionrio. a) create trigger SalrioInjusto after insert, update on Empregados if exists (select * from Empregados where estadoCivil = casado and salrio < 250.00) begin print salrio injusto para o estado civil! exec CorrigeSalrio end b) Se a data de retorno do vo for anterior data de partida, emitir uma mensagem e no completar a transao. c) Trigger para executar erro em aumento de salrio. create trigger AumentoSalrio before update on Empregados referencing NEW salrio as SalrioNovo when salrio > SalrioNovo (Rollback Transaction)

Captulo 7. Segurana em Bancos de Dados

Bases de dados so as fundaes de qualquer negcio eletrnico, sistema de gesto financeira ou empresarial. Considerando a sua importncia no mundo das aplicaes cientficas e de negcio imprescindvel prover a proteo dos dados e informaes armazenados. Diversas ticas devem ser consideradas, tais como: manuteno da integridade referencial e semntica da base; recuperao aps falhas e anomalias em processos concorrentes. Tais consideraes previnem a perda da integridade atravs da introduo acidental de inconsistncia. Em especial, quando se trata de segurana de SGBDs surge a preocupao com a m utilizao dos dados armazenados, com o alto valor agregado das informaes e com a introduo intencional de inconsistncias causadas por m f dos envolvidos no processo e/ou por acessos no autorizados, resultando em alterao ou destruio insidiosa das informaes. A proteo de um sistema de banco de dados torna-se uma tarefa bastante difcil quando se trata de prevenir ataques insidiosos. Manter a integridade nestes casos significa prevenir a alterao, a destruio e a leitura (roubo) no-autorizada de informaes. Deste ponto em diante o termo segurana ser usado para se referir manuteno da integridade perante ataques insidiosos.

7.1. Esquemas de segurana

7.1.1. Autorizao A correta concesso de permisses aos usurios um ponto fundamental no esquema de segurana de uma aplicao que faa uso de banco de dados. A escolha ou configurao errada de nveis de acesso a usurios pode resultar em resultados desastrosos tanto do ponto de vista funcionalidade como, principalmente, do ponto de vista da segurana. permisso. Abaixo segue uma breve explanao sobre os diversos nveis de

Nveis de permisso para manipulao de dados e informaes (DMLs): - read: leitura, mas no modificao dos dados. - insert: insero, mas no a modificao dos dados.

- update: modificao, mas no a remoo dos dados. - delete: remoo dos dados.

Tais permisses podem ser concedidas a usurios (ou grupos de usurios) separadamente ou em conjunto. A negao das permisses tambm possvel, sendo que um usurio pode ter todas as permisses, nenhuma delas ou um subconjunto das mesmas.

Nveis de permisso para manipulao da definio da base (DDLs) - index: permite criar ndices na base - resource: permite criar novas relaes - alteration: permite adio ou remoo de atributos de uma relao - drop: permite a remoo de relaes

Numa aplicao de porte deve existir uma distino bastante clara entre os diversos nveis de acesso para cada usurio bem como o papel de cada usurio no sistema. Imaginando uma aplicao como um Enterprise Resource Planning (ERP), existe a necessidade de determinados usurios possurem apenas privilgios de read sobre determinado conjunto de dados ou sobre toda a base de dados. Outros usurios poderiam ter permisso de insert para determinados tipos de dados como cadastro de funcionrios, departamentos, controle de finanas; enquanto outro conjunto de usurios possuiria nvel de acesso de insert, update e remove para todas as partes da aplicao. Alm de todos os usurios de manipulao de dados, prudente salientar a necessidade de um usurio como responsvel pela definio e modelagem da base. Concluindo: usurios devem ter acesso estritamente ao que precisam ter acesso. Usurios de leitura da base, utilizados para realizar consultas, colhendo informaes em funo dos dados da base, usualmente, no devem necessitar de permisso de criao de vises ou gatilhos, por exemplo.

7.1.2. Concesso de privilgios

De acordo com as necessidades organizacionais de cada aplicao, companhia ou projeto, pode ser necessria a permisso de conceder permisses, mas conhecido como concesso de privilgios. Consiste em permitir que usurios concedam a outros usurios as permisses, ou subconjuntos das mesmas, concedidas a eles prprios; criando assim

uma rede, muitas vezes complexas, de propagao de permisses sobre elementos da base de dados.

7.1.3. Vises

O mecanismo de criao de vises parciais ou agregados de informaes da base permite ao administrador de uma base de dados conceder permisses sobre determinado subconjunto de uma relao. Embora uma consulta ou ao (insert, delete, update) sobre uma relao possa ser negada a um usurio, a concesso de uma viso permite que o mesmo s possua acesso o que estritamente necessrio. Este modelo de segurana de dados bastante til devido sua facilidade de implementao e sua funcionalidade, deixando o sistema mais seguro sem perda de poder de ao por parte do usurio semibloqueado. Uma viso pode reunir fragmentos de dados de diversas relaes montando uma relao resultante, em alguns casos, bastante complexa sem que um usurio tenha acesso a mais do que deveria.

7.1.4. Criptografia

Mesmo com todos os esquemas de segregao de informao distribuindo usurios em grupos e nveis de acesso, determinados tipos de aplicaes podem ter necessidade de criptografar dados altamente relevantes para que apenas leitores habilitados a descriptograf-los estejam aptos a fazer uso da informao. Recomenda-se que senhas de usurios, por exemplo, estejam criptografadas na base de dados e apenas a aplicao responsvel pelo acesso ao sistema possua a maneira de reconhecer os dados codificados. H um vasto nmero de tcnicas de criptografia usando-se de avanados recursos tecnolgicos e matemticos para fornecer uma encriptografia segura e eficiente para dados na base. Entretanto, algoritmos complicados de criptografia podem gerar uma excessiva sobrecarga sobre o sistema de maneira a tornar, de certa maneira, invivel o seu uso. Da mesma forma, algoritmos fracos podem ser facilmente quebrados, incorrendo em vulnerabilidade do SGBD. A tarefa de um administrador saber distinguir bem entre a necessidade de sigilo do dado e a funcionalidade da aplicao.

Uma boa tcnica de criptografia deve ter as seguintes propriedades:

- relativamente simples de ser decodificada pelos usurios autorizados - extremamente difcil para um intruso quebrar a chave de codificao e descobrir o real significado dos dados codificados

7.2. Vulnerabilidades comuns

Falta de maturidade em caractersticas de segurana: os SGBDs possuem um processo gradativo de suporte a segurana. Muitos produtos comerciais apresentam brechas que s vo sendo corrigidas ao longo do tempo e do ganho de maturidade do produto. Gerenciamento de senhas: na maioria dos SGBDs no existe um sistema

verificador de senhas fracas, o que permite ao usurio definir senhas fceis de serem quebradas. Brechas para ataque em sistemas operacionais: existem SDBDs que provm funcionalidades que permitem acessar o sistema operacional, como chamadas ao Shell do sistema. Se um usurio mal intencionado transgride a segurana do SGBD e acessa a base com determinados privilgios, essas funcionalidades podem incorrer em perigo integridade de todo o sistema operacional. Cavalos de Tria: imagine uma situao em que um usurio mal intencionado crie ou altere procedimentos armazenados na base para colher informaes sobre mudanas de senha na base de dados. A cada mudana de senha o SGBD enviaria informaes de usurio/senha para o invasor. O invasor esperaria ento at ocorrer uma mudana na senha de administrador da base e ser notificado da senha de sa.

Diversas outras vulnerabilidades existem e outras ainda esto por serem descobertas. Por mais que se aplique mecanismos de segurana, invasores podem fazer uso de tcnicas cada vez mais engenhosas para encontrar brechas de segurana e fazer mau uso de acesso indevido. O que se pode fazer tomar medidas que aumentem o custo tanto em dinheiro como em tempo e dificuldade de se atacar um determinado sistema, para que a tentativa de invaso seja praticamente inexeqvel.

7.3. Concluso

Os requisitos de segurana vm crescendo a cada dia, haja vista o aumento exponencial da oferta de servios no ambiente coorporativo e comercial. Diante desta configurao h mais risco de ataques e roubos de informaes dado que a disponibilidade dos sistemas est cada vez maior. A necessidade de segurana em um ambiente de risco como o citado irrevogvel e, diante das mais diferentes necessidades e nveis de proteo aos dados cabe a cada entidade, empresa ou corporao decidir por alternativas que mais lhe satisfaam em relao a custo e benefcio. A maioria dos aplicativos SGBDs atualmente trata com bastante seriedade a questo da segurana. Cada fornecedor trata do problema e organiza o seu esquema de segurana da maneira como acredita ser a mais conveniente mas, independentemente de qual for o produto escolhido como servidor de dados, importante salientar a importncia de polticas educacionais fortes frente aos usurios, escolha e proteo de um sistema operacional seguro, administrao correta do SGBD, entre outras aes que venham a somar ao esquema de segurana fornecido pelo fabricante da base e no simplesmente delegar o cuidado com a proteo ao SGBD.