Sistemas

Gerenciadores de
Bancos de Dados

Autor:
Andrea Cristina Oliveira Alves
Apostila de Sistemas Gerenciadores de Bancos de Dados

2007
Capítulo I - Introdução

No início da década de 60, foram lançados os primeiros sistemas gerenciadores de

banco de dados (SGBD), tendo como principal proposta o aumento na produtividade nas
atividades de desenvolvimento e manutenção de sistemas, até então realizadas de forma
artesanal em linguagens de programação convencionais de primeira e segunda geração.

Oriundos do ambiente de mainframes, os SGBD tornaram-se mais populares e

amigáveis com o advento da microinformática. Cada vez mais as fronteiras entre esses
dois mundos estreitam-se e a concorrência pelo domínio do mercado de SGBD, tem levado
seus diversos fabricantes a sofisticarem seus produtos. Cada nova versão lançada,
incorpora novidades como interfaces gráficas, ferramentas de apoio ao desenvolvimento,
utilitários para gerenciamento de BD e facilidades para extração de dados. Essa evolução
vem tornando o trabalho de programadores, analistas e usuários menos artesanal, com
reflexos na qualidade e produtividade.

1.1. Principais conceitos

1.1.1. Bancos de Dados: Coleção de dados inter-relacionados, que representam

informações sobre um domínio específico; Ex.: Agenda telefônica, 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 manipulação das informações dos bancos de dados e o desenvolvimento de
programas aplicativos. Ex.: MySQL- Oracle- SQL Server
 Sistema de
Programas de
Banco de Dados
Aplicação/Consulta

SGBD
Software para processar
manipulação

Banco de dados
Software de Acesso aos
Dados

Meta Dados Dados

1.1.3. TABELAS

Uma tabela é uma coleção de REGISTROS do mesmo tipo, ou seja,

referentes a um mesmo assunto e com o mesmo formato padrão (layout).
Constitui o componente do sistema no qual são armazenados os dados,
que combinados através dos programas servem de base para a geração
da informação desejada pelo usuário, através de relatórios e consultas
on-line. Um sistema de controle de notas, por exemplo, pode armazenar seus
dados em diversas tabelas, cada uma contendo informações sobre um
determinado item do sistema: ALUNO, PROFESSOR, MATÉRIA, NOTA,
etc.

Essas informações podem ser combinadas através de programas para

gerar, por exemplo, o BOLETIM ESCOLAR, a PAUTA ou uma tela de
CONSULTA DE NOTAS.
1.1.4. REGISTRO

Um registro é constituído por conjunto de campos valorados (contendo dados). Consiste na

unidade de armazenamento e recuperação da informação em um arquivo. Geralmente, os
registros de um arquivo possuem um formato padrão (layout), definido pela seqüência, tipo
e tamanho dos campos que o compõem. Porém, algumas linguagens de programação
permitem a criação de registros com layouts deferentes em um mesmo arquivo, recurso
este que raramente é utilizado.

1.1.5. CAMPO

É a unidade básica formadora de um registro. Constitui a célula da informação. É a menor

porção de um arquivo que pode ser referenciada por um programa. Cada campo possui
NOME, TIPO e TAMANHO.

1.1.6. CHAVE PRIMÁRIA (PRIMARY KEY - PK)

A CHAVE PRIMÁRIA (ou simplesmente CHAVE) é o identificador único de um registro em

um arquivo. Pode ser constituída de um campo (CHAVE SIMPLES) ou pela combinação de
dois ou mais campos (CHAVE COMPOSTA), de tal maneira, que não existam dois registros
no arquivo com o mesmo valor de chave primária.

Em regra, todo arquivo deve possuir uma chave primária, que permita a identificação
inequívoca do registro, especialmente, para dar maior consistência aos processos de
inclusão, alteração e exclusão de dados. Para que não ocorram duplicatas nos valores da
chave, os campos que a compõem são de PREENCHIMENTO OBRIGATÓRIO (NOT
NULL). Na escolha da chave primária de um arquivo deve-se buscar campos que
possuam ESTABILIDADE no valor armazenado. A escolha do NÚMERO DO TELEFONE
como chave de um cadastro de clientes, por exemplo, seria inadequada, por que esse valor
pode mudar com freqüência. Sem considerar que o cliente pode ter mais de um telefone...
Deve-se também evitar a escolha de campos que possam causar AMBIGÜIDADE em
relação 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 várias formas. Por exemplo: LUÍS, LUIZ, LOUIS, LOYS, LUYS.

Se desejássemos cobrar uma fatura de um cliente com um nome como esse, a

probabilidade de erramos o cliente seria grande. Além disso, a extensão do campo (30 ou
mais caracteres) é um outro aspecto que aumenta a possibilidade de erros.

1.1.7. CHAVE SECUNDÁRIA

A chave secundária pode ser formada por um campo ou pela combinação de campos
(SIMPLES / COMPOSTA). Ë utilizada como parâmetro (filtro) para seleção de registros no
arquivo em consultas, emissão de relatórios ou processos de atualização simultânea de um
grupo de registros. Por exemplo, para aumentarmos o valor do salário dos analistas em
10%, poderíamos utilizar o campo FUNÇÃO do arquivo CADASTRO DE FUNCIONÁRIOS
como parâmetro (chave secundária) no processo de seleção dos registros a serem
alterados. Em síntese, a chave secundária é o campo ou combinação de campos do
arquivo que permite a recuperação de mais de um registro no arquivo.
Portanto, não possui a característica de unicidade proposta para a chave primária.

1.1.8. CHAVE ESTRANGEIRA

É um atributo ou conjunto de atributos cujos valores aparecem necessariamente na chave

primária de uma tabela. Este mecanismo permite a implementação de relacionamentos no
modelo relacional.
Exemplo:
Departamento (CodDep, NomeDepto)
Empregado(CodEmp, NomeEmp, CodDepto, CatFunc)

Exercícios

1. Defina com suas palavras a diferença entre Bancos de dados e Sistemas

Gerenciadores de Bancos de dados.

2. Dê exemplos de arquivos, registros e campos

3. Simule a criação de um banco de dados. Este banco deverá conter 3 tabelas.

Defina chave primária, secundária e estrangeira para as tabelas criadas.
Capitulo II - Características de SGDB´S
2.1. Controle de Redundância

No processamento tradicional de arquivos, cada grupo de usuários deve manter seu

próprio conjunto de arquivos e dados. Desta forma, acaba ocorrendo redundâncias que
prejudicam o sistema com problemas como:

• toda vez que for necessário atualizar um arquivo de um grupo, então todos os
grupos devem ser atualizados para manter a integridade dos dados no ambiente
como um todo;

• a redundância desnecessária de dados levam ao armazenamento excessivo de

informações, ocupando espaço que poderia estar sendo utilizado com outras
informações.

2.2. Compartilhamento de Dados

Um SGBD multiusuário deve permitir que múltiplos usuários acessem o banco de

dados ao mesmo tempo. Este fator é essencial para que múltiplas aplicações integradas
possam acessar o banco.
O SGBD multiusuário deve manter o controle de concorrência para assegurar que o
resultado de atualizações sejam corretos. Um banco de dados multiusuários deve fornecer
recursos para a construção de múltiplas visões.

2.3. Restrição a Acesso não Autorizado

Um SGBD deve fornece um subsistema de autorização e segurança, o qual é

utilizado pelo DBA para criar “contas” e especificar as restrições destas contas; o controle
de restrições se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao
SGBD.

2.4. Representação de Relacionamentos Complexos entre Dados

Um banco de dados pode incluir uma variedade de dados que estão inter-
relacionados de várias 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 prática e eficiente.

2.5. Tolerância a Falhas

Um SGBD deve fornecer recursos para recuperação de falhas tanto de software quanto de
hardware.
Capítulo 3. Arquitetura de SGBD´S

3.1. Arquitetura em 3 níveis

A ANSI divide a arquitetura de banco de dados em 3 níveis distintos:

Nível Externo – Nível do usuário

Nível Interno – Nível físico
Nível Conceitual – Nível de conjunto de visões de usuários. Faz a ligação entre os outros
dois.

3.1.1. Nível Externo

O nível externo é o nível do usuário individual. Um determinado usuário pode ser ou

programador de aplicações ou um usuário final com qualquer grau de sofisticação. (O
DBA é um caso especial importante; porém, diferentemente de outros usuários, o DBA
também precisará estar interessado nos níveis conceitual e interno. Cada usuário tem
uma linguagem à sua disposição:

• Para o programador de aplicações, essa linguagem será uma linguagem de

programação convencional (como PL/I, C+-f, Java)

• Para o usuário final, a linguagem será uma linguagem de consulta ou alguma

linguagem de uso especial, talvez dirigida por formulários ou menus, adaptada aos
requisitos desse usuário.

Cada usuário utiliza diferentes linguagens para utilizar um sgbd. Algumas destas
técnicas são chamadas de sub-linguagem, ou seja, linguagens que acopladas a
outras, produzem os efeitos esperados.

Uma visão externa é, portanto, o conteúdo do banco de dados visto por algum
usuário determinado (ou seja, para esse usuário a visão externa é o banco de dados).
Por exemplo, um usuário do Departamento de Pessoal poderia considerar o banco de
dados uma coleção de ocorrências de registros de departamento empregados, e ele
poderia não ter nenhum conhecimento das ocorrências de registros de fornecedores e
peças vistas pelos usuários do Departamento de Compras.
Assim, em geral, uma visão externa consiste em muitas ocorrências de cada um
dentre muitos tipos de registros externos (não necessariamente a mesma coisa que uni
registro armazenado).* A sublinguagem de dados do usuário é definida em termos de
registros externos; por exemplo, uma operação DML de busca obterá ocorrências de
registros externos, não ocorrências de registros armazenados. Ou seja, será feita a
busca no nível conceitual e não no nível interno.

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

3.1.2. NÍVEL CONCEITUAL

A visão conceitual é uma representação de todo o conteúdo de informações do

banco de dados, mais uma vez (como no caso de uma visão externa) em uma forma
um tanto abstrata em comparação com o modo como os dados são armazenados
fisicamente. Em geral, ela também será bastante d if e r e n t e do modo como os
dados são visualizados por qualquer usuário em particular.
A visão conceitual consiste em muitas ocorrências de cada um dos vários tipos
de registros conceituais. Por exemplo, ela pode consistir em uma coleção de
ocorrências de registros de departamentos, somada a uma coleção de ocorrências
de registros de empregados, mais uma coleção de ocorrências de registros de
fornecedores, somada a uma coleção de ocorrências de registros de peças (etc.
etc.). Um registro conceitual não é necessariamente o mesmo que um registro
externo, nem o mesmo que um registro armazenado.
Na visão conceitual não haverá nenhuma informação física, como ponteiros ou
índices de acesso.
Neste nível, deverão existir todas as restrições de segurança e integridade de
dados.Na maior parte dos sistemas existentes, o "esquema conceitual" é na
verdade pouco mais que uma simples reunião de todos os esquemas externos
individuais, somados a certas restrições de segurança e integridade. Porém,
sem dúvida, é possível que sistemas futuros eventualmente sejam muito mais
sofisticados em seu suporte do nível conceitual.

3.1.3.NÍVEL INTERNO

O terceiro nível da arquitetura é o nível interno. A visão interna é uma representarão

de baixo nível do banco de dados por inteiro; ela consiste em muitas ocorrências de
cada um dos vários tipos de registros internos. "Registro interno" é o termo
ANSI/SPARC que representa a construção que temos chamado de registro
armazenado (e continuaremos a usar essa última forma).

A visão interna é descrita por meio do esquema interno, que não somente define
os diversos tipos de registros armazenados mas também especifica quais índices
existem, como os campos armazenados estão representados, em que sequência
física estão os registros armazenados, e assim por diante

Para encerrar lembramos que, em certas situações excepcionais, os programas

aplicativos - em particular as aplicações de natureza utilitária - podem ter permissão
para operar diretamente no nível interno, e não no nível externo. Não é preciso dizer
que essa prática não é recomendável; ela representa um risco de segurança (pois as
restrições de segurança são ignoradas) e um risco de integridade (pois também as
restrições de integridade são ignoradas), e o programa terá uma inicialização de-
pendente dos dados; porém, às vezes essa poderá ser a única maneira de obter a
funcionalidade ou o desempenho exigido - do mesmo modo o usuário em tuna
linguagem de programação de alto nível poderia ter a necessidade ocasional de
descer até a linguagem assembler para satisfazer certos objetivos de funcionalidade
ou desempenho.
3.1.4. MAPEAMENTOS

Além dos três níveis básicos, esta arquitetura envolve certos mapeamentos: um
mapeamento conceitual/interno e vários mapeamentos externos/conceitual:
o O mapeamento conceitual/interno define a correspondência entre a
visão conceitual e o banco de dados armazenado;
o Um mapeamento externo/conceitual define a correspondência entre uma
visão externa específica e a visão conceitual.

A propósito, a maioria dos sistemas permite que a definição de certas visões

externas seja expressa em-termos de outras (efetivamente, através de mapeamentos
externos/externos), em vez de sempre exigir uma definição explícita do mapeamento no
nível conceitual - um recurso útil se diversas visões externas forem bastante
semelhantes umas às outras. Em particular, os sistemas relacionais oferecem essa
capacidade.

3.2. ARQUITETURA CLIENTE/SERVIDOR

Descrevemos até agora neste capítulo os sistemas de bancos de dados sob o ponto de
vista da cbamada ar-quitetura ANSI/SPARC.

Nesta seção, examinaremos os sistemas de bancos de dados sob uma perspectiva um

pouco diferente. Naturalmente, o objetivo geral desses sistemas é fornecer suporte ao
desenvolvimento e à execução de aplicações de bancos de dados. Portanto, sob um
ponto de vista de mais alto nível, um sistema de banco de dados pode ser
considerado como tendo uma estrutura muito simples em duas partes, consistindo em
um servidor (também chamado hack end) e um conjunto de clientes (também
chamados front ends).

• O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBDs -definição
de dados, manipulação de dados, segurança e integridade cie dados, e assim por diante.
Em particular, ele oferece todo o suporte de nível externo, conceitual e interno que
examinamos anteriormente. Assim, o termo "servidor" neste contexto é tão-somente um
outro nome para o SGBD.

• Os clientes são as diversas aplicações executadas sobre o SGBD - tanto

aplicações escritas por usuários quanto aplicações internas, ou seja, aplicações
fornecidas pelo fabricante do SGBD ou por produtores independentes. No que se
refere ao servidor, é claro que não existe nenhuma diferença entre aplicações escritas
pelo usuário e aplicações internas - todas elas empregam a mesma interface para o
servidor.

Usuários finais

Clientes

Servidor

Banco de dados
Vamos aprofundar o exame da questão de aplicações escritas pelo usuário versus
aplicações fornecidas pelo fabricante:
• Aplicações escritas pelo usuário são basicamente programas aplicativos
comuns, escritos (em geral) em uma linguagem de programação convencional de
terceira geração (L3G), como C ou COBOL, ou então em alguma linguagem
proprietária de quarta geração (L4G) - embora em ambos os casos a linguagem
precise ser de algum modo acoplada a uma sublinguagem de dados apropriada.
• Aplicações fornecidas por fabricante (chamadas frequentemente de
ferramentas - tools) são aplicações cuja finalidade básica é auxiliar na criação e
execução de outras aplicações! As aplicações criadas são aplicações adaptadas a
alguma tarefa específica (elas podem não ser muito semelhantes às aplicações
no sentido convencional; de fato, a finalidade das ferramentas é permitir aos
usuários, em especial aos usuários finais, criar aplicações sem ter de escrever
programas em uma linguagem de programação convencional). Por exemplo,
uma das ferramentas fornecidas pelo fabricante será um gerador de relatórios,
cuja finalidade é permitir que os usuários finais obtenham relatórios formatados
a partir do sistema sob solicitação. Qualquer solicitação de relatório pode ser
considerada um pequeno programa aplicativo, escrito em uma linguagem de
geração de relatórios de nível 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 relatórios.
c. Subsistemas gráficos de negócios.
d. Planilhas eletrônicas.
e. Processadores de linguagem natural.
f. Pacotes estatísticos.
g. Ferramentas para gerenciamento de cópias ou "extração de dados".
h. Geradores de aplicações (inclusive processadores L4G).
i. Outras ferramentas para desenvolvimento de aplicações, inclusive produtos de
engenharia de software auxiliada pelo computador (CASE - computer-aided software
engineering).

Observamos que, tendo em vista que toda a importância de um sistema de banco de

dados está em dar suporte à criação e à execução de aplicações, a qualidade das ferra-
mentas disponíveis é, ou deve ser, um fator preponderante na "decisão sobre o banco
de dados" (isto é, o processo de escolha do produto de banco de dados apropriado). Em
outras palavras, o SGBD em si não é o único fator que precisa ser levado em
consideração, nem mesmo é necessariamente o fator mais significativo.

Encerramos esta seção com uma referência para o que se segue. Como o sistema
por completo pode estar tão claramente dividido em duas partes, servidores e clientes,
surge a possibilidade de executar os dois em máquinas diferentes. Em outras palavras,
existe o potencial para o processamento distribuído. O processamento distribuído
significa que máquinas diferentes podem estar conectadas entre si para formar algum
tipo de rede de comunicações, de tal modo que uma única tarefa de processamento de
dados possa ser dividida entre várias máquinas na rede. Na verdade, essa possibilidade
é tão atraente - por uma variedade de razões, principalmente de ordem económica -
que o termo "cliente/servidor" passou a se aplicar a quase exclusivamente ao caso em
que o cliente e o servidor estão de fato localizados em máquinas diferentes.

Exercícios
1. Explique os três níveis da arquitetura definida pela Ansi/Parc
2. Qual é a função do mapeamento
3. Explique a arquitetura Cliente/Servidor

Capítulo 4. Linguagens de Bancos de Dados

Cada SGBD - Sistema Gerenciador de Banco de Dados - possui uma arquitetura interna
própria. A linguagem SQL padrão 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, atualização, criação e gerenciamento de

banco de dados relacionais. É um método para selecionar determinados registros de um
banco de dados, seguindo um critério especificado a sua escolha. O SQL é considerado
uma linguagem padrão para o gerenciamento de banco de dados relacionais.
Com o SQL é possível definir tabelas, índices, domínios, etc., para a criação e
manutenção de uma base de dados; Fazer consultas simples ou complexas em uma base
de dados; Fazer operações de inclusão, alteração e cancelamento nas tabelas que
compõem o banco de dados de um sistema
 4.2. Linguagem de Definição 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 definição de indices (método de acesso) ou de
restrições de integridade referencial.
Exemplo:

Exemplo de DDL SQL:
CREATE TABLE cliente (
nome VARCHAR(50),
cidade VARCHAR(35),
rua VARCHAR(30)
)

4.3. Linguagem de Manipulação de Dados (DML)

É a linguagem que permite aos usuários do banco de dados manipularem os dados. É
através deste tipo de linguagem que os usuários manipulam os dados. É comumente
utilizada para busca de informação e modificações no banco de dados;

Exemplo de DML SQL:
SELECT cidade, rua
FROM custumer
WHERE nome = “João

Capítulo 5. Transações

5.1. TRANSAÇÕES

Uma transação é uma unidade lógica de trabalho; ela começa com a execução de
uma operação BEGIN TRANSACTION e termina com a execução de uma operação
COMMIT ou ROLLBACK. Considere a possibilidade da existencia de uma transação cuja
finalidade é transferir a quantia R$100 da conta 123 para a conta 456. Como você pode ver,
o que presumivelmente deveria ser uma operação indivisível - "transferir dinheiro de uma
conta para outra" - de fato envolve duas atualizações separadas no banco de dados. Além
do mais, o banco de dados está em um estado incorreto entre essas duas atualizações, no
sentido de que não reflete um estado de coisas válido no mundo real; logicamente, uma
transferência no mundo real, de uma conta para outra, não 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 atualizações. Assim, uma unidade lógica de
trabalho, que é uma transação, não envolve necessariamente uma única operação sobre o
banco de dados. Em vez disso, ela geralmente envolve uma sequência de várias dessas
operações, cuja finalidade é transformar um estado correto do banco de dados em outro
estado também correto, sem necessariamente preservar a correção em todos os pontos
intermediários.
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 ; /* término bem sucedido */
GO TO
/* término mal sucedido */
FINISH ;
UNDO :

Vejamos como ele funciona. Para simplificar, suponha que a transação tenha concluído
com sucesso seu processamento de banco de dados; assim, a instrução no âmbito do
sistema que ela emite é COMMIT, e não ROLLBACK. Ao receber essa requisição 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 transação. Na prática, isso significa que cada participante
do processo - ou seja, cada gerenciador de recursos envolvidos - deve forçar todas as
entradas de log de recursos locais utilizados pela transação em seu próprio log físico (isto
é, para o armazenamento não volátil; aconteça o que acontecer daí por diante, o
gerenciador de recursos terá agora um registro permanente do trabalho que realizou para
a transação, e será capaz de completar o COMMIT de suas atualizações ou cancelá-las,
como for preciso). Supondo-se que a gravação forçada seja bem-sucedida, o gerente de
recursos responderá agora "OK" ao coordenador; caso contrário, ele responderá "Não
OK".

• COMMIT: Depois de receber respostas de todos os participantes, o coordenador força a

gravação de uma entrada em seu próprio log físico, registrando sua decisão a respeito da
transação. Se todas as respostas foram "OK", essa decisão será COMMIT; se qualquer
resposta tiver sido "Não OK", a decisão será "cancelar". De qualquer forma, o
coordenador informará sua decisão a cada participante, e cada participante deverá então
 fazer o COMMIT ou cancelar a transação de modo local, conforme tiver sido instruído.
Observe que cada participante tem de fazer o que lhe diz o coordenador na Fase 2 - esse
é o protocolo. Observe também que o aparecimento do registro de decisão no log físico
do coordenador assinala a transição da Fase l para a Fase 2.

Se o sistema falhar em algum ponto durante o processo geral, o procedimento de

reinicialização procurará o registro de decisão no log do coordenador. Se o encontrar,
então o processo de COMMIT de mas fases poderá continuar do ponto em que foi
interrompido. Se não achar o registro, ele presumirá que a decisão foi "cancelar", e mais
uma vez o processo poderá ser concluído adequadamente.

5.2. Propriedades de Transações

As transações possuem quatro propriedades importantes, que são chamadas

6
"propriedades ACID": Atomicidade, Consistência, Isolamento e Durabilidade. Resumindo:

• Atomicidade: Ou todas as operações da transação são refletidas corretamente

no banco de dados ou nenhuma o será. A idéia básica por trás da garantia
da atomicidade é a seguinte. O sistema de banco de dados mantém um
registro (em disco) dos antigos valores de quaisquer dados sobre os quais a
transação executa uma gravação e, se a transação não se completar, os
valores antigos sãos restabelecidos para fazer com que pareça que ela nunca
foi executada. Assegurar a atomicidade é responsabilidade do próprio sistema
de banco de dados, mais especificamente ela é tratada por um componente
chamado de componente de gerenciamento de transações.
• Consistência: A execução de uma transação isolada (ou seja, sem execução
concorrente de outra transação) preserva a consistência do banco de
dados. Assegurar a permanência da consistência após uma transação em
particular é de responsabilidade do programador da aplicação que codifica a
transação. Essa tarefa pode ser facilitada por meio do teste automático dos
requisitos de integridade.
• Isolamento: Embora diversas transações possam ser executadas de forma
concorrente, o sistema garante que, para todo par de transações 1 e 2, 1 tem a
sensação de que 2 terminou sua execução antes de 1 começar, ou que 2
começou sua execução após 1 terminar. Assim, cada transação não toma
conhecimento do outras transações concorrentes no sistema. Mesmo
asseguradas as propriedades de consistência e de atomicidade para cada
 transação, quando diversas transações concorrentes são executadas, suas
operações podem ser intercaladas de modo inconveniente, resultando em um
estado inconsistente. A propriedade de isolamento de uma transação garante
que a execução simultânea de transações resulte em uma situação no sistema
equivalente ao estado obtido caso as transações 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 concorrência.
• Durabilidade: Depois da transação completar-se com sucesso, as mudanças
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
transação com sucesso, todas as atualizações realizadas no banco de dados
persistirão, até mesmo se houver uma falha de sistema após a transação se
completar. Assegurar a durabilidade é responsabilidade de um componente
do sistema de banco de dados chamado de componente de gerenciamento de
recuperação

5.2.1. Transações Concorrentes

Quando várias transações são executadas de modo concorrente no banco de dados, a

consistência dos dados não pode mais ser garantida. Então, é necessário que o sistema
controle a interação entre as transações concorrentes. Como uma transação é uma
unidade que preserva a consistência, uma execução seqüencial das transações garante a
preservação da consistência. Portanto, exigimos que qualquer escala produzida pelo
processamento concorrente de um conjunto de transações tenha um efeito equivalente a
uma escala produzida quando essas transações são executadas seqüencialmente em
alguma ordem. Do sistema que garante essa propriedade diz-se que ele garante a
serialização. Há várias noções diferentes de equivalência que conduzem aos conceitos de
serialização de conflito e serialização de visão.

A serialização das escalas geradas por transações concorrentes pode ser garantida por
meio de um entre vários mecanismos chamados de esquemas de controle de
concorrência. O componente de gerenciamento de controle de concorrência do banco de
dados é o responsável pela manipulação dos esquemas de controle da concorrência. O
componente de gerenciamento da recuperação de um banco de dados é o responsável por
assegurar as propriedades de atomicidade e durabilidade das transações.

Bloqueio

O protocolo de bloqueio é um conjunto de regras que estabelecem quando uma

transação pode bloquear e desbloquear cada um dos itens de dados do banco de dados. O
protocolo do bloqueio em duas fases permite que uma transação bloqueie um novo item
de dado somente até desbloquear o primeiro deles. O protocolo garante a serialização,
mas não está livre de deadlocks. Na ausência de informações a respeito do tipo de acesso
que será feito no item de dados, o protocolo de bloqueio em duas fases é tanto necessário
quanto suficiente para garantia da serialização.

O esquema da ordenação por timestamp garante a serialização pela seleção da ordem

de execução entre pares de transações. Um único timestamp é associado a cada
transação no sistema. Os timestamps das transações determinam a ordem de serialização.
Assim, se o timestamp da transação T1 é menor que o da transação T2, o esquema
garante que a escala de execução produzida seja equivalente a uma escala serializada na
qual a transação T1 aparece antes da transação T2. Isso é feito revertendo a transação
sempre que a ordem for violada.

Vários protocolos de bloqueio não são resistentes a deadlocks. Um modo de evitar

deadlocks é usando a preempção e o rollback de transações. Para controla a preempção,
marcamos um único timestamp para cada transação. Esses timestamps são usados para
decidir se uma transação deverá ser revertida ou deverá esperar. Se uma transação é
revertida, ela mantém o timestamp antigo quando reiniciada. Os esquemas de esperar-
morrer e de ferir-esperar são dois esquemas com base em preempção. Outro método para
o tratamento de deadlocks é usar o esquema de detecção de deadlock e recuperação.
Para fazê-lo, é construído um gráfico de espera. Um sistema está em estado de deadlock
se, e somente se, o gráfico de espera contém um ciclo. Quando o algoritmo de detecção
identifica um deadlock, o sistema precisa recuperar-se. Isso é feito revertendo uma ou
mais transações para quebra do deadlock.

5.3. RECUPERAÇÃO DO SISTEMA

 Informações podem ser perdidas de um sistema computacional devido à ocorrência
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 transações
mesmo que falhas ocorram. Um mecanismo
de recuperação que restaure o banco de dados para um estado consistente existente ante
s da falha é, portanto, de extrema importância. Os algoritmos de recuperação em banco
de dados são responsáveis por assegurar a consistência do banco de dados e a
atomicidade das transações. Para isto eles devem efetuar ações durante o
processamento normal de uma transação garantindo que haja informação suficiente pra pe
rmitir a recuperação, e ações após a falha, que efetivamente recuperam o conteúdo
do banco de dados para um estado consistente, garantindo a atomicidade
da transação e a durabilidade.

5.3.1.Falhas em Bancos de Dados

Pode-se classificar as falhas da seguinte forma:

●Falha de transação: Esta falha pode ser causada por dois tipos de erro, erro lógico ou
erro de sistema. Erro lógico ocorre quando uma condição interna impede a execução
normal da transação, como uma entrada inadequada ou um dado não encontrado.
Quando o sistema entra num estado inadequado, impedindo a execução normal de
uma transação, como no caso de um deadlockdiz-se que ocorreu um erro de sistema.
●Queda do sistema: Esta falha causa a perda do conteúdo do armazenamento volátil, para
ndo o processamento da transação, sem afetar o conteúdo do armazenamento não-
volátil. Causas comuns desta falha são mau funcionamento de hardware ou bug no
software de banco de dados.
●Falha de disco: Esta falha leva à perda do conteúdo do disco, pode ser causada pela que
bra do cabeçote.

5.3.2. Recuperação e Atomicidade

Ao ocorrer uma falha durante uma transação, soluções do tipo re-executar ou ignorar
poderão levar o banco a um estado inconsistente. O problema está em modificar
o banco de dados sem que a transação será de fato efetivada.
Para evitar inconsistências é necessário que todas ou nenhuma alteração
relacionadas a uma transação sejam feitas no banco. Para manter a atomicidade deve-
se mandar todas as alterações para um armazenamento estável, sem modificar o
banco de dados.
Isto permitir que,
apesar de falhas, manter um estado consistente dos dados. Abaixo estão descritas duas
técnicas de realizar essa gravação.

5.3.3. Recuperação utilizando log

Recuperação baseada em log é técnica mais usada para gravar modificações em um

banco de dados. O log ou journal documenta as atividades em um banco de dados.
Em especial, o log de atualizações documenta todas as alterações de registros. Os
registros do log são gravados antes da modificação no banco, de forma que caso
ocorra uma falha que interrompa uma transação, o banco de dados possa retornar a um
estado consistente. Existem duas políticas de gravação quando se utiliza o log.
No log, há algumas operações primitivas que podem ser registradas:
●start – Marca o inicio de uma transação, junto com o identificador desta.
●update – Marca uma alteração em registro, mantendo o identificador da
transação, do registro e valores atuais e/ou valores anteriores.
●commit – Marca o fim de uma transação
●abort –Marca o aborto de uma transação, sendo executado o rollback, restaurando
o estado anterior.

5.3.4. Checkpoints

Como refazer todas as operações do log é custoso e o tamanho do log tende a crescer
rápido, a recuperação de dados utilizando o log pode ser muito demorada.
Muitas transações já foram efetivadas em disco, não sendo necessário refazê-las.
Uma solução para esse problema é a criação de checkpoints, marcas no log onde todas as
operações de escrita anteriores ao checkpoint já foram efetivadas em disco.
Logo só é preciso refazer as transações concluídas que foram feitas depois da
criação do checkpoint.
Durante a criação do checkpoint, todos os registros de log residentes em memória são
gravados em armazenamento estável, seguido de blocos de buffer modificados.
Somente após isto, é armazenado o registro de log que marca a conclusão do
checkpoint.

Capítulo 6. Integridade de Dados

Integridade de dados é a garantia de que estes dados estão realmente corretos. É

impossível evitar 100% de erros por parte dos operadores de dados, porém, existem
algumas técnicas bastante avançadas para evitar que isto aconteça. A estas regras
chamamos de restrições de integridade.

Vamos pensar no seguinte exemplo: Vamos supor que ao invés de lançar no banco que
um determinado funcionário trabalhou 40 horas por semana, o operador digite 400. Qual
seria uma forma de evitar que isto aconteça? Basta definir através de restrições que a
carga horária de um funcionário só poderá variar entre 0 e 40 horas semanais. Ainda
existirá uma margem de erro, porém a delimitação 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 não
possa haver dois fornecedores com o mesmo código. Caso alguém altere o código de um
fornecedor, devem ser comparados todos os campos que já existem no banco para saber
se não há outro com este código ou se este fornecedor já existe com outro código.
Cada remessa deverá envolver um fornecedor existente, ou seja, isto evita que o operador
lance um código inexistente na hora de enviar o pedido.

6.2. Tipos de restrições de integridade

6.2.1. Integridade de Domínio

A integridade de domínio nada mais é do que a integridade do campo como o tipo de

dados correto, se permite null ou not null, default´s, check, etc. Estes mecanismos foram
criados para dar integridade aos campos. Os tipos de dados também são caracterizados
como integridade de domínio, se o tipo de dado estiver incorreto, ou com mais posições
que o necessário, pode haver ali um risco que quebre a integridade. O check aqui é em
nível 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

através das Primary Keys, uma tabela sem PK é uma tabela sem integridade de entidade.

6.2.3 Integridade Referencial

A integridade referencial é mais conhecida, são as Foreign Keys, nada mais é que eu
aceitar valores em minha entidade que estão em outra entidade, isto é possível a partir da
integridade de entidade, eu apenas consigo criar Foreign Keys a partir de uma Primary
Key, a integridade referencial consiste também em check em nível de tabela e não em
nível de campo, no ato da criação da tabela crio um check, por exemplo:

Tenho uma tabela com 2 campos Medico1, Medico2, e quero que um dos campos sempre
seja preenchido não
importa qual, para isto
CodDep(PK) Nome MatrGerent
preciso de um check

D2 Produção 210 em nível de tabela.

D1 Custos 105 Ex.: Departamento

D5 Pessoal NULL

Empregado

Matr(PK) Nome Endereço Função Salário Depart(FK)

100 Ana R. Pedro I, 12, A. Secretária 500,00 D1

Branco
250 Pedro R. J. Silva, 24, Engenheiro 1500,00 D1
Liberdade

108 André R. Itália, 33, B. Nações Técnico 950,00 D2

210 Paulo R. Pará, 98, B. Estados Engenheiro 1810,00 D2

105 Sônia R. Oliveira, 76, A. Engenheiro 2500,00 D1

Form
Branco
alme
nte, um conjunto de atributos de uma relação R1 é uma chave estrangeira se satisfaz
às seguintes regras:

• Os atributos da chave estrangeira têm o mesmo domínio dos atributos da chave

primária de outra relação R2.
• Um valor da chave estrangeira numa linha l1 de R1 possui o mesmo valor da chave
primária para alguma linha l2 em R2 ou é NULO.
• A integridade referencial estabelece que todo valor de chave estrangeira numa
relação deve corresponder a um valor de chave primária de uma segunda relação
ou deve ser nulo.
• Ex.:

Empregado(matrícula,nome,salário,matr_supervisor)

Ex.: "Nenhum empregado pode ganhar mais que seu gerente"

"O número de horas máximo que um empregado pode trabalhar num projeto é 40 horas".

6.3. Operações de atualização em relações

6.3.1.Inserção

1. Inserir <'102','André',null, 'Engenheiro', '1.980','D2'>

=> é aceito sem problemas

2. Inserir <'100', 'Maria', null, 'Técnica', '950','D1'>

=> viola a restrição de chave.

3. Inserir <null,'Cecília',null,'Engenheiro','1.950','D1'>

=> viola restrição de integridade de entidade.

4. Inserir <'108','Mauro','Rua 4','Técnico','980','B6'>

=> viola a restrição de integridade referencial.

O que fazer quando se detectar uma violação de integridade?

• Rejeitar a inserção (podendo explicar o porquê)

• Tentar corrigir a anomalia para depois inserir.

6.3.2.Remoção

1. Remover da tabela empregado a linha com matrícula = '100'.

remoção aceita sem problemas.

2. Remover da tabela departamento a linha com CodDep = 'D1'.

=> viola a regra de integridade referencial. (empregados que estão alocados neste
departamento.)

O que fazer quando uma violação ocorrer numa remoção?

• Rejeitar a remoção
• Dar o efeito cascata na remoção, removendo todas as linha referenciadas por
aquela linha que está sendo removida.
• Modificar os atributos referenciados para novos valores ou nulos (caso não façam
parte da chave primária).
• Dos três tipos de restrições de integridade discutidas, uma operação de remoção
poderá violar apenas a integridade referencial.

6.3.3. Modificação

1. Modificar o salário do empregado com matrícula='250'

=> operação aceita sem problemas.

2. Modificar o número do departamento da linha de empregado com matrícula '210' para

'D1'

=> operação aceita sem problemas.

3. Modificar o número do departamento de empregado '108' para 'D9'

=> viola a integridade referencial

4. Modificar a matrícula do empregado '100' para '250'

=> viola regra de integridade de chave.

Exercícios: Seja as duas tabelas seguintes:

Curso
Codcurso(PK) Descrição CodUnid

C1 Sistemas de Informação 156

C2 Educação Física 156

C3 Farmácia 156

C4 Administração 156

C5 Pedagogia 156

Aluno

RA(PK) Nome Endereço Curso

1050 Rafael Bandeira Rua das Camélias, 76 C1

1123 Ricardo Azevedo R. Bernardo Sayão, 156 C2

1896 Mirela Domigues R. Roma, 33 C1

1475 Juliana Didone R. Belo horizonte, 197, apto C4

105B.

1112 Carlos Eduardo Rocha R. Carmópolis, 75 C3

Diante destas informações, informe se as alterações abaixo são possíveis nas tabelas
alunos e cursos. Caso não seja possível, informe qual é o tipo de restrição de integridade
que a mesma está violando:

1- Inserir (‘1112’, ‘Ana Maria Bernardes’, ‘Rua das rosas, 350’ , ‘C8’)
2- Inserir (‘1796’, ‘João da Silva’, ‘Rua 107, 52’ , ‘C3’)
3- Inserir (null, ‘Carlos Santana’, ‘Rua Afonso Pena, 12’ , ‘C4’)
4- Deletar (‘C1’, ‘Sistemas de Informação´, ´156’)
5- Alterar o código de curso C2 para C16
6- Alterar o endereço do Aluno cujo RA é 1112.
7- Alterar o código do curso do aluno com RA 1050 para C3
8- Inserir (‘1012’, ‘José Maria Rocha’, ‘Rua do Calvário, 115’ , ‘C10’)
9- Deletar o aluno cujo RA é 1123.
10- Inserir (‘1175’, ‘Silvana Andrade’, ‘Av. João Pinheiro, 46’ , null)

6.3. Procedimentos Armazenados (Store Procedures)

Stored Procedures são semelhantes a sub-rotinas ou subprogramas desenvolvidos
noutras linguagens de programação (p.e. C, Pascal, Basic, Java, etc.), mas que são
guardados no servidor. Aceitam parâmetros de entrada e retornam resultados. Isto é,
como qualquer subprograma, um procedimento permite a passagem de parâmetros de
entrada e de saída, aceitando valores e devolvendo algum tipo de resultado à entidade que
o invocou, que pode ser um outro procedimento, um gatilho ou mesmo uma aplicação
externa cliente. As Stored procedures retornam um valor de status indicando se aconteceu
um erro, e qual foi. São basicamente blocos de instruções SQL compiladas num único
plano de execução.
6.3.1. Propósitos/Vantagens.
- Diminuição do tráfego na rede. A execução destes programas no seio de um
servidor permite reduzir substancialmente o tráfego de rede provocado por
aplicações que solicitem ao servidor a execução de instruções SQL. O servidor
passa a ser assim não só servidor de dados, mas também servidor de programas
para a manipulação dos dados.
- Programação por módulos. Um stored procedure após ser guardado na BD, pode
ser invocado várias vezes num programa. Pode também ser alterado sem que haja
necessidade de alterar em todos os lados.
- Execução mais rápida. Se uma operação tem muitas instruções T-SQL e/ou é
executada muitas vezes, os stored procedures conseguem ser mais rápidos, pois
são compilados e otimizados no momento da sua criação.
- Segurança. Pode ser dada permissão aos utilizadores para executar um stored
procedure, mesmo que não tenham permissão para utilizar o mesmo código
diretamente através de um editor.

Exemplo
– débitos diários de parcelas de empréstimos
create procedure PagaEmpréstimo as
update Empréstimos
set ValorTotal = ValorTotal – ValorParcela,
NroParcelas = NroParcelas – 1
where DiaVencimento = day(getdate())
• Chamada de um storedprocedure
exec PagaEmpréstimo

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 são usados para realizar tarefas relacionadas com validações , restrições de
acesso , rotinas de segurança e consistência de dados ; desta forma estes controles
deixam de ser executados pela aplicação e passam a ser executados pelos Triggers em
determinadas situações :

• Mecanismos de validação envolvendo múltiplas tabelas

• Criação de conteúdo de uma coluna derivada de outras colunas da tabela
• Realizar análise e e atualizações em outras tabelas com base em alterações e/ou
inclusões da tabela atual

A criação de um Trigger envolve duas etapas :

1. Um comando SQL que vai disparar o Trigger ( INSERT , DELETE , UPDATE)

2. A ação que o Trigger vai executar ( Geralmente um bloco de códigos SQL )

Exemplo:
Mostrar ao usuário que o valor do salário não é compatível ao estado civil do funcionário.
a) create trigger SalárioInjusto
after insert, update on Empregados
if exists (select *
from Empregados
where estadoCivil = casado
and salário < 250.00)
begin
print ‘salário injusto para o estado civil!’
exec CorrigeSalário
end
b) Se a data de retorno do vôo for anterior à data de partida, emitir uma mensagem e não
completar a transação.
c) Trigger para executar erro em aumento de salário.
create trigger AumentoSalário
before update on Empregados
referencing NEW salário as SalárioNovo when
salário > SalárioNovo
(Rollback Transaction)
Capítulo 7. Segurança em Bancos de Dados

Bases de dados são as fundações de qualquer negócio eletrônico, sistema de

gestão financeira ou empresarial. Considerando a sua importância no mundo das
aplicações científicas e de negócio é imprescindível prover a proteção dos dados e
informações armazenados. Diversas óticas devem ser consideradas, tais como:
manutenção da integridade referencial e semântica da base; recuperação após falhas e
anomalias em processos concorrentes. Tais considerações previnem a perda da
integridade através da introdução acidental de inconsistência. Em especial, quando se trata
de “segurança de SGBD’s” surge a preocupação com a má utilização dos dados
armazenados, com o alto valor agregado das informações e com a introdução intencional
de inconsistências causadas por má fé dos envolvidos no processo e/ou por acessos não
autorizados, resultando em alteração ou destruição insidiosa das informações.
A proteção de um sistema de banco de dados torna-se uma tarefa bastante difícil
quando se trata de prevenir ataques insidiosos. Manter a integridade nestes casos significa
prevenir a alteração, a destruição e a leitura (roubo) não-autorizada de informações. Deste
ponto em diante o termo “segurança” será usado para se referir à manutenção da
integridade perante ataques insidiosos.

7.1. Esquemas de segurança

7.1.1. Autorização
A correta concessão de permissões aos usuários é um ponto fundamental no
esquema de segurança de uma aplicação que faça uso de banco de dados. A escolha ou
configuração errada de níveis de acesso a usuários pode resultar em resultados
desastrosos tanto do ponto de vista funcionalidade como, principalmente, do ponto de vista
da segurança. Abaixo segue uma breve explanação sobre os diversos níveis de
permissão.

Níveis de permissão para manipulação de dados e informações (DML’s):

- read: leitura, mas não modificação dos dados.
- insert: inserção, mas não a modificação dos dados.
 - update: modificação, mas não a remoção dos dados.
- delete: remoção dos dados.

Tais permissões podem ser concedidas a usuários (ou grupos de usuários)

separadamente ou em conjunto. A negação das permissões também é possível, sendo que
um usuário pode ter todas as permissões, nenhuma delas ou um subconjunto das
mesmas.

Níveis de permissão para manipulação da definição da base (DDL’s)

- index: permite criar índices na base
- resource: permite criar novas relações
- alteration: permite adição ou remoção de atributos de uma relação
- drop: permite a remoção de relações

Numa aplicação de porte deve existir uma distinção bastante clara entre os diversos
níveis de acesso para cada usuário bem como o papel de cada usuário no sistema.
Imaginando uma aplicação como um Enterprise Resource Planning (ERP), existe a
necessidade de determinados usuários possuírem apenas privilégios de read sobre
determinado conjunto de dados ou sobre toda a base de dados. Outros usuários poderiam
ter permissão de insert para determinados tipos de dados como cadastro de funcionários,
departamentos, controle de finanças; enquanto outro conjunto de usuários possuiria nível
de acesso de insert, update e remove para todas as partes da aplicação. Além de todos
os usuários de manipulação de dados, é prudente salientar a necessidade de um usuário
como responsável pela definição e modelagem da base. Concluindo: usuários devem ter
acesso estritamente ao que precisam ter acesso. Usuários de leitura da base, utilizados
para realizar consultas, colhendo informações em função dos dados da base, usualmente,
não devem necessitar de permissão de criação de visões ou gatilhos, por exemplo.

7.1.2. Concessão de privilégios

De acordo com as necessidades organizacionais de cada aplicação, companhia ou

projeto, pode ser necessária a permissão de conceder permissões, mas conhecido como
concessão de privilégios. Consiste em permitir que usuários concedam a outros usuários
as permissões, ou subconjuntos das mesmas, concedidas a eles próprios; criando assim
uma rede, muitas vezes complexas, de propagação de permissões sobre elementos da
base de dados.

7.1.3. Visões

O mecanismo de criação de visões parciais ou agregados de informações da base

permite ao administrador de uma base de dados conceder permissões sobre determinado
subconjunto de uma relação. Embora uma consulta ou ação (insert, delete, update) sobre
uma relação possa ser negada a um usuário, a concessão de uma visão permite que o
mesmo só possua acesso o que é estritamente necessário. Este modelo de segurança de
dados é bastante útil devido à sua facilidade de implementação e sua funcionalidade,
deixando o sistema mais seguro sem perda de poder de ação por parte do usuário
semibloqueado.
Uma visão pode reunir fragmentos de dados de diversas relações montando uma
relação resultante, em alguns casos, bastante complexa sem que um usuário tenha acesso
a mais do que deveria.

7.1.4. Criptografia

Mesmo com todos os esquemas de segregação de informação distribuindo usuários

em grupos e níveis de acesso, determinados tipos de aplicações podem ter necessidade
de criptografar dados altamente relevantes para que apenas leitores habilitados a
descriptografá-los estejam aptos a fazer uso da informação. Recomenda-se que senhas de
usuários, por exemplo, estejam criptografadas na base de dados e apenas a aplicação
responsável pelo acesso ao sistema possua a maneira de reconhecer os dados
codificados.
Há um vasto número de técnicas de criptografia usando-se de avançados recursos
tecnológicos e matemáticos 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, inviável 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 aplicação.

Uma boa técnica de criptografia deve ter as seguintes propriedades:

 - relativamente simples de ser decodificada pelos usuários autorizados
- extremamente difícil para um intruso quebrar a chave de codificação e descobrir o
real significado dos dados codificados

7.2. Vulnerabilidades comuns

Falta de maturidade em características de segurança: os SGBD’s possuem um

processo gradativo de suporte a segurança. Muitos produtos comerciais apresentam
brechas que só vão sendo corrigidas ao longo do tempo e do ganho de maturidade do
produto.
Gerenciamento de senhas: na maioria dos SGBD’s não existe um sistema
verificador de senhas fracas, o que permite ao usuário definir senhas fáceis de serem
quebradas.
Brechas para ataque em sistemas operacionais: existem SDBD’s que provêm
funcionalidades que permitem acessar o sistema operacional, como chamadas ao Shell do
sistema. Se um usuário mal intencionado transgride a segurança do SGBD e acessa a
base com determinados privilégios, essas funcionalidades podem incorrer em perigo à
integridade de todo o sistema operacional.
Cavalos de Tróia: imagine uma situação em que um usuário mal intencionado crie
ou altere procedimentos armazenados na base para colher informações sobre mudanças
de senha na base de dados. A cada mudança de senha o SGBD enviaria informações de
usuário/senha para o invasor. O invasor esperaria então até ocorrer uma mudança na
senha de administrador da base e ser notificado da senha de ‘sa’.

Diversas outras vulnerabilidades existem e outras ainda estão por serem

descobertas. Por mais que se aplique mecanismos de segurança, invasores podem fazer
uso de técnicas cada vez mais engenhosas para encontrar brechas de segurança 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 invasão seja praticamente inexeqüível.
7.3. Conclusão

Os requisitos de segurança vêm crescendo a cada dia, haja vista o aumento

exponencial da oferta de serviços no ambiente coorporativo e comercial. Diante desta
configuração há mais risco de ataques e roubos de informações dado que a disponibilidade
dos sistemas está cada vez maior. A necessidade de segurança em um ambiente de risco
como o citado é irrevogável e, diante das mais diferentes necessidades e níveis de
proteção aos dados cabe a cada entidade, empresa ou corporação decidir por alternativas
que mais lhe satisfaçam em relação a custo e benefício.
A maioria dos aplicativos SGBD’s atualmente trata com bastante seriedade a
questão da segurança. Cada fornecedor trata do problema e organiza o seu esquema de
segurança da maneira como acredita ser a mais conveniente mas, independentemente de
qual for o produto escolhido como servidor de dados, é importante salientar a importância
de políticas educacionais fortes frente aos usuários, escolha e proteção de um sistema
operacional seguro, administração correta do SGBD, entre outras ações que venham a
somar ao esquema de segurança fornecido pelo fabricante da base e não simplesmente
delegar o cuidado com a proteção ao SGBD.