TRABALHO DE BANCO DE DADOS

VÍDEO LOCADORA

LINGUAGEM DE PROGRAMAÇÃO DE BANCO DE

DADOS

UNIP – SWIFT

João Paulo Rodrigues – C12170-3

Felipe Bigatto D’ambrosio – C33436-7
 Índice

SQL: Extenções Procedurais 03

Controle de transações lógicas 04
Controle de concorrência 06
Mecanismos de otimização de consultas 08
Índices 10
Árvores B e B+ 12
Construção do Banco de Dados 13
Referências 17
 SQL – Extensões procedurais: function, procedure, trigger:

A extensão procedural PL/SQL (Procedural Language/Structured Query

Language) é uma extensão da linguagem SQL para o serviço de
gerenciamento de banco de dados da Oracle™, sendo assim, uma linguagem
procedural que estende a linguagem SQL.
Essa extensão permite que a manipulação do banco de dados seja
realizada através de funções, que são acionadas por “triggers” (que podem ser
habilitados ou desabilitados, dependendo da intenção do desenvolvedor do
PL/SQL).
O “trigger” funciona em tempo real no banco de dados (caso esteja
habilitado), sendo acionado sempre que o evento chave de disparo ocorrer.
Embora seja muito útil, é preciso tomar cuidado em relação à quantidade de
“triggers” existentes em um banco de dados (muitos “triggers” podem,
diretamente, afetar o desempenho e agilidade ao acessar dados do BD,
podendo causar lentidão no sistema).
As functions (funções) de PL/SQL funcionam exatamente como funções
de outras linguagens de programação, como por exemplo C, C#, Java, entre
outros. Sempre que ocorre um evento onde um trigger é acionado, uma função
é chamada.
A sintaxe para criar uma função armazenada é muito semelhante a
sintaxe de um procedimento.
Create [OR REPLACE] FUNCTION nome_função
[ (argumento[ {IN | OUT | IN OUT} ] tipo,
…
[ (argumento[ {IN | OUT | IN OUT} ] tipo,
RETURN tipo_retorno {IS | AS}
corpo_funcao
Em que nome_função e o nome da função, argumento e tipo são iguais ao dos
procedimentos, tipo_retorno e o tipo do valor que a função devolve e
corpo_função é o bloco de PL/SQL que contém o código da função.
 Controle de transações lógicas de atualização de dados:

Transação é uma unidade lógica de processamento de operações sobre

um banco de dados.
Uma transação é formada por uma sequência de operações que precisam ser
executadas integralmente para garantir a consistência e a precisão dos dados
de um banco de dados.
Geralmente, uma transação consiste de uma das seguintes instruções:
 Uma operação DDL (Data Definition Language);
 Uma operação DCL (Data Control Language);
 Um conjunto de operações DML (Data Manipulation Language).
Uma transação começa quando for executada a 1ª operação SQL
executável e termina com um dos seguintes eventos:
 Comando COMMIT ou ROLLBACK é emitido;
 Operação DDL ou DCL é executada (COMMIT automático);
 O usuário desconecta do banco de dados (COMMIT automático);
 O sistema falha (ROLLBACK automático).

Quando uma transação termina, o próximo comando SQL inicia

automaticamente a próxima transação.
Transação é uma unidade lógica de processamento de operações sobre
um banco de dados.
Uma transação é formada por uma sequência de operações que
precisam ser executadas integralmente para garantir a consistência e a
precisão dos dados de um banco de dados.
Geralmente, uma transação consiste de uma das seguintes instruções:
 Uma operação DDL (Data Definition Language);
 Uma operação DCL (Data Control Language);
 Um conjunto de operações DML (Data Manipulation Language).

As operações de controle de transações são:

 COMMIT: finaliza a transação atual tornando permanentes todas
as alterações de dados pendentes.
 SAVEPOINT <nome_savepoint>: marca um ponto de gravação
dentro da transação atual, sendo utilizado para dividir uma
transação em partes menores.
  ROLLBACK [TO SAVEPOINT <nome_savepoint>]: ROLLBACK
finaliza a transação atual, descartando todas as alterações de
dados pendentes.

ROLLBACK TO SAVEPOINT descarta o ponto de gravação determinado

e as alterações seguintes ao mesmo.

Exemplo 1:
INSERT INTO Departamento (ID_Depto, NomeDepto, ID_Gerente)
VALUES (10, 'Marketing', 3);
UPDATE Funcionario SET salario = salario * 1.05
WHERE ID_Depto = 5;
COMMIT;
DELETE FROM Funcionario;
ROLLBACK;
No exemplo, o departamento 10 é inserido, os salários dos funcionários
do departamento 5 são atualizados, mas nenhum funcionário é excluído.
Exemplo 2:
INSERT INTO Departamento (ID_Depto, NomeDepto, ID_Gerente)
VALUES (11, 'RH', 2);
SAVEPOINT ponto1;
DELETE FROM Funcionario;
ROLLBACK TO SAVEPOINT ponto1;
UPDATE Funcionario SET salario = salario * 1.05
WHERE ID_Depto = 5;
COMMIT;
No exemplo, o departamento 11 é inserido, os salários dos funcionários
do departamento 5 são atualizados, mas nenhum funcionário é excluído.
Se uma única operação DML falhar durante a execução, será feito
rollback somente dessa operação.
Alguns SGBDs implementam um savepoint implícito à operação que
está sendo executada. Todas as outras alterações são mantidas, mas usuário
deve finalizar as transações explicitamente usando uma operação COMMIT ou
ROLLBACK.

Controle de concorrência:

O controle de concorrência em um SGBD está relacionado diretamente

com os comandos de acesso a banco de dados feitos por uma transação.
Segundo Battisti (2005, p.244), “transação é um conjunto de operações sobre
os dados, que deve acontecer como um todo”.
Todas as operações devem ser finalizadas com sucesso, ou nenhuma
delas deve ser realizada. Caso uma das operações, contida na transação,
venha a falhar, as operações ainda pendentes devem ser canceladas e as
operações já realizadas devem ser revertidas.
Desta forma uma transação sempre estará completa ou não foi
realizada. Transações submetidas por vários usuários podem ser executadas
concorrentemente e diversos problemas podem ocorrer no banco de dados se
esta concorrência não for devidamente controlada. De acordo com ELMASRI
(2005, p.400), dentre os principais problemas, podem ser destacados os
seguintes:
• Atualização perdida: ocorre quando duas transações que acessam os
mesmos itens de bancos de dados tiveram suas operações intercaladas.
• Atualização temporária (Leitura Suja): ocorre quando uma transação
atualizar um item de banco de dados e, a seguir, falhar por alguma razão. Este
item pode ser acessado por outra transação antes que ele retorne ao seu valor
original.
• Sumário Incorreto: se uma transação aplicar uma função agregada
para sumário de um número de registros enquanto outras transações estiverem
atualizando alguns desses registros, pode acontecer da função agregada
calcular alguns valores antes de eles serem atualizados e outros depois de
feita a atualização.
Para efeito de restauração, o sistema precisa manter o controle de
quando a transação inicia, termina e de suas efetivações ou interrupções. De
acordo com (ELMASRI, 2005, p.403), durante sua execução, uma transação,
percorre os seguintes estados:
• Estado Ativo: imediatamente após o início de sua execução.
• Estado de efetivação parcial: quando a transação termina, mas ainda
precisa garantir que nenhuma falha impossibilite a gravação permanente das
mudanças.
 • Estado de efetivação: as gravações serão gravadas permanentemente
no banco de dados (commit)
A figura 1 abaixo ilustra os estados de uma transação.

Figura 1 – Diagrama de transição de estados de execução de uma transação. Fonte: Sistemas

de Bancos de Dados. 4ª ed. São Paulo: Person Addison Wesley, 2005, 724 p.

O controle de concorrência e métodos de restauração do SGBD deverão

impor algumas propriedades às transações que são chamadas propriedades
ACID (ELMASRI, 2005, p.404), descritas a seguir:
 Atomicidade: uma transação é uma unidade atômica de processamento;
ou ela será executada em sua totalidade ou não será de modo nenhum.
 Consistência: uma transação será preservadora de consistência se sua
execução completa fizer o banco de dados passar de um estado
consistente para outro.
 Isolamento: uma transação dever ser executada como se estivesse
isolada das demais. Isto é, a execução de uma transação não deve
sofrer interferência de quaisquer outras transações concorrentes.
 Durabilidade: as mudanças aplicadas ao banco de dados por uma
transação efetivada devem persistir no banco de dados. Essas
mudanças não devem ser perdidas em razão de uma falha.

Conforme ressaltado por ELMASRI (2005, p.415), para assegurar a

propriedade de não interferência ou isolamento de transações concorrentes, os
SGBD’s utilizam protocolos. O protocolo de controle de concorrência mais
usado é o bloqueio. O usuário pode indicar o grau de isolamento desejado
entre transações, definindo como será feito o bloqueio dos dados. O nível de
isolamento é especificado pela declaração ISOLATION LEVEL <isolamento>,
onde o valor de <isolamento> pode ser READ UNCOMMITTED (leitura não
efetivada), READ COMMITTED (leitura efetivada), REPEATABLE READ
(leitura repetível) ou SERIALIZABLE (serializável). O nível de isolamento
padrão é SERIALIZABLE, entretanto, alguns sistemas usam como padrão o
READ COMMITTED.
O nível SERIALIZABLE não permite violações que causam leitura de
sujeira, leitura não repetível e fantasmas.
 Se uma transação for executada em um nível de isolamento mais baixo que
o SERIALIZABLE, podem ocorrer as seguintes violações:
 Leitura suja ( dirty read ): uma transação T1 pode ler a atualização de
uma transação T2, que ainda não tenha sido committed. Se T2 falhar e
for abortada, então T1 terá lido um valor que não existe e é incorreto.
 Leitura não repetitiva ( nonrepeatable read ): uma transação T1 pode ler
um dado valor de uma tabela. Se outra transação T2 posteriormente
atualizar este valor e T1 ler novamente esse valor, T1 verá um novo
valor.
 Fantasmas ( phantoms ): uma transação T1 pode ler um conjunto de
linhas de uma tabela, com base, talvez, em alguma condição
especificada na cláusula WHERE da SQL. Suponha que uma transação
T2 insira uma nova linha que também satisfação à condição da cláusula
WHERE empregada em T1, na tabela utilizada por T1. Se T1 for
repetida, então T1 verá um fantasma, uma linha que antes não existia.

Segue abaixo a figura 2 apresentando as possíveis violações baseadas em

níveis de isolamento.

Figura 2 – Possíveis violações baseadas em Níveis de Isolamento Fonte: Sistemas de Bancos

de Dados. 4ª ed. São Paulo: Person Addison Wesley, 2005, 724 p.

Mecanismos de otimização de consultas:

A otimização é o processo de escolha do modo mais eficiente para a

execução de um comando SQL.
Podem existir diferentes formas para o SGBD executar um comando
SQL: de acordo com a ordem em que as tabelas ou índices sofrerão acesso,
de acordo com as restrições estabelecidas, de acordo com a quantidade de
linhas das tabelas envolvidas, de acordo com os índices disponíveis, etc.
De acordo com VENNAPUSA (2004): “São vários os fatores que podem
influenciar no custo e velocidade das consultas SQL: criação e deleção de índices, alteração de
parâmetros, remodelagem física de tabelas, geração de estatísticas, reescrita de códigos SQL,
entre outros. Não existindo uma formula precisa para um aumento de desempenho.”
(VENNAPUSA, 2004).
 As consultas são objetos de constantes revisões e otimizações, visto
que é o ponto crucial em um sistema de banco de dados, pois constituem a
maior parte das transações envolvidas em uma aplicação.
Através do estudo do desempenho e otimização de consultas SQL,
procura-se a minimização do tempo de resposta do servidor de banco de
dados. Essa minimização influencia na produtividade de trabalho coletivo à
medida que não degrada o desempenho operacional dos sistemas.
Dessa forma, todo sistema que acessa um banco de dados necessita
obter as respostas às consultas em um tempo hábil, pois está em jogo não
somente a paciência do usuário e credibilidade perante o mesmo, mas também
valores monetários obtidos em transações comerciais. Por exemplo, no caso
de instituições financeiras como bancos, a lentidão do sistema pode causar a
perda de clientes e consequentemente seus respectivos investimentos. Outro
fator importante é que, ao se melhorar o desempenho de consultas SQL, pode-
se evitar gastos com investimentos na troca de software e/ou hardware, se os
mesmos estiverem sendo adquiridos na tentativa de se conseguir melhor
desempenho do sistema.
Quando se estuda o aprimoramento de desempenho de consultas SQL,
percebe-se que, mesmo alterando ajustes de configuração e/ou incluindo
hardware mais potente, as mudanças com relação ao aplicativo
frequentemente surtem maiores efeitos de desempenho junto às consultas. Os
sistemas de banco de dados, sejam de qualquer plataforma, podem ser
extraordinariamente rápidos e eficientes com aplicativos bem planejados e
implementados. Em contrapartida, num sistema onde os aplicativos estejam
mal planejados ou implementados de forma deficiente, o banco de dados terá
um desempenho abaixo do esperado.
A chave para se obter um aplicativo bem projetado e implementado é
considerar o fator desempenho por todo o ciclo de desenvolvimento do mesmo
e não considerá-lo apenas ao término da construção para então realizar os
testes de desempenho. O desenvolvedor precisa considerar o desempenho
antes de começar a escrever o código do aplicativo.
Hardware e software apropriados, banco de dados normalizado, e
principalmente a forma com que as consultas SQL são construídas, são itens
que colaboram para a melhora do desempenho de um sistema de banco de
dados.
Em alguns SGBD, existe a presença de um otimizador, como é o caso
do SQLServer. O Otimizador tem como objetivo determinar um modo eficiente
de implementar a requisição feita através de uma consulta SQL ao banco de
dados.
O processamento de consultas, segundo SILBERSCHATZ et al. (1999),
é uma atividade que permite extrair dados de um banco de dados. Esta
atividade inclui a tradução de consultas expressas em linguagens de alto nível
do banco de dados em expressões que podem ser implementadas no nível
físico do sistema de arquivos, otimizações, traduções e avaliação das
consultas.
O custo do processamento de uma consulta é determinado pelo acesso
ao disco. Geralmente, há diversas estratégias possíveis para processar uma
determinada consulta, principalmente se ela for complexa. A diferença entre
uma estratégia boa e uma ruim, em termos do número de acessos de disco
exigidos é frequentemente significativa e pode ser de grande magnitude.
Consequentemente, vale a pena gastar uma quantia significativa de tempo na
seleção de uma estratégia boa para processar uma consulta.
Conforme DATE (2000), a otimização representa ao mesmo tempo um
desafio, visto que, a otimização é uma exigência para os sistemas relacionais
quando se espera um desempenho que atinja níveis pré-determinados, e uma
oportunidade, já que a otimização é favorecida pelo fato das expressões
relacionais estarem em um nível semântico adequado para que seja possível
essa otimização.
Para que o banco de dados apresente um bom desempenho é
preciso partir do pressuposto da existência de uma boa estrutura de banco de
dados, adequadamente normalizada e que possua índices úteis. Além disso, é
preciso escrever consultas de forma otimizada. No entanto, deve-se enfatizar a
importância de se conhecer como o otimizador de consultas funciona para
melhor formular uma consulta ou para entender quais índices podem ser
criados. Deve-se escrever as consultas da maneira mais intuitiva e tentar
otimizá-las apenas se seu desempenho não parecer suficientemente bom
(SOUKUP & DELANEY, 1999).
Para cada tabela envolvida na consulta SQL, o otimizador avalia os
argumentos de pesquisa e avalia até que ponto o índice pode excluir linhas de
uma seleção. Quanto mais linhas puderem ser excluídas, menor será o número
de linhas a serem processadas.
Entretanto, nem sempre o otimizador realiza com êxito seu propósito
pelo fato das consultas não terem sido escritas de forma eficiente.

Índices
Os índices aceleram a recuperação dos dados. Por exemplo, imagine
que você compre um livro de 800 páginas para suas pesquisas acadêmicas e
este não apresente em seu conteúdo um índice reportando o seu conteúdo.
Uma pesquisa talvez não fosse tão pavorosa, mas se você precisar de várias
pesquisas seria muito desagradável ficar horas procurando o conteúdo que
deseja estudar. Por outro lado, um livro que apresente um índice de suas
abordagens, se faz muito mais fácil e torna as pesquisas até prazerosas, pois
teremos condição de irmos direto ao ponto que queremos.
 Um bom exemplo da criação necessária de índices, são aplicações
bancárias que atendem caixas eletrônicos.
Sempre que solicitamos uma determinada transação ou mesmo
informação, tal solicitação tende a ser cada vez mais rapidamente atendida.
E quantos correntistas geralmente têm os grandes bancos?
Será que quanto mais correntistas, mais lenta será a consulta?
Se não os índices, uma pesquisa pelo seu saldo demoraria quase o
tempo de um almoço para retornar seus dados, ou mesmo, retornar uma
resposta a sua solicitação de saque. Uma vez tendo ciência do funcionamento
dos índices, respeitando a sua regra de negócios, uma consulta deverá ter
resposta em tempo satisfatório.
A criação de índices deve ser considerada de acordo com a frequência
de uso de determinados dados e tabelas. Um índice pode ser um instrumento
chave para atender os objetivos da otimização. Entretanto, o mesmo pode ser
capaz de interferir no desempenho de forma negativa. Uma boa regra geral
segundo PRICE (2009) é: “Crie um índice quando uma consulta recuperar até
10% do total de linhas em uma tabela.”
Isso significa que, o critério para a escolha de índices é a seletividade.
Portanto, quando maior for a seletividade, melhor será o índice. Uma coluna
que contém valor exclusivo para cada linha (um número de CPF, por exemplo),
é um atributo candidato à indexação.
Assim, os índices são criados com intuito de eliminar a leitura de toda a
tabela na intenção de encontrar o registro. Mas deve-se tomar cuidado: possuir
mais índices em uma tabela não significa que as consultas serão aceleradas.
Cada operação DML (Data Manipulation Language) que seja submetida a
‘commit’ em uma tabela com índices significa que os índices devem ser
atualizados. Quanto mais índices associados a uma tabela existir, maior será o
esforço realizado pelo SGBD para atualizar todos os índices após uma
instrução DML.
Quando colunas indexadas são modificadas, o SGBD desloca recurso
internamente para manter esses índices atualizados e associados;
A manutenção de índices requer tempo e recursos, portanto, não crie
índices que não serão usados efetivamente;
Quando se contém grande quantidade de dados duplicados, índices
apresentam mais custo que benefícios. Assim como usar índices com atributos
de pouca variação, como “sexo” ou atributos do tipo flag.
Por que não criar índices?
Os índices são muito bons no sentido de desempenho do banco de
dados, otimizam as buscas de dados, mas, por outro lado, consomem muito
espaço em disco, o que pode se tornar concorrente do próprio banco se você o
detém em um espaço generoso ou pode se tornar caro quando de detém o
banco em um storage.

Árvores: B e B+
Árvore B:
Proposta por Bayer e McCreight em 1972 a árvore B opera junto com o
armazenamento secundário e pode ser sintonizada para reduzir os transtornos
impostos por essa armazenagem. Uma propriedade importante das árvores B é
o tamanho de cada nó, que pode ser tão grande quanto o tamanho de um
bloco. Uma árvore B é uma árvore de busca múltipla com as seguintes
propriedades:
1. A raiz tem pelo menos duas sub-árvores, a menos que ela seja uma
folha;
2. Cada nó não-raiz e não-folha contém k-1 chaves e k ponteiros para as
sub-árvores onde: [m/2] ≤ k ≤ m;
3. Cada nó folha contém k-1 chaves, onde [m/2] ≤ k ≤ m;
4. Todas as folhas estão no mesmo nível.

Árvore B+:
Uma árvore B+ é uma estrutura de dados do tipo árvore derivada das
árvores B, mas com uma forma diferente de armazenamento de suas chaves.
Tal organização confere propriedades, algoritmos de inserção, busca e
remoção de chaves diferentes dos utilizados em árvores B, mas com uma
gama de aplicações muito semelhantes em banco de dados e sistemas de
arquivos.
Estruturas de dados como essa são muito empregadas em banco de
dados e sistemas de arquivos como o NTFS para o Microsoft Windows, o
sistema de ficheiros ReiserFS para Unix, o XFS para IRIX e Linux, e o JFS2
para AIX, OS/2 e Linux, usam este tipo de árvore.
Assim como as árvores B, as árvores B+ visam reduzir as operações de
leitura e escrita em memória secundária, uma vez que, essas operações são
demoradas para um sistema computacional e devem ser minimizadas sempre
que possível.
Para definir uma árvore B+ devemos levar em consideração alguns
aspectos relativos ao disco de memória secundária utilizado e a quantidade de
memória primária disponível. Assim, para escolher o tamanho de uma página
de sequence set e, portanto, quantas chaves esta podem armazenar é uma
tarefa dependente do disco utilizado: suponhamos que cada página folha
armazene d chaves.
 O index set, como dito anteriormente, apenas carrega cópias de chaves
para referenciar a busca e sua construção é semelhante ao de uma árvore B.
Suponhamos que estes nós internos possam apontar para n nós filhos, ou seja,
uma árvore B com no máximo n-1 chaves por página.

Com tais suposições, diferentemente das árvores B, os números d e n-1

não são necessariamente iguais, mas, manter o tamanho físico em arquivo
dessas páginas iguais facilita a implementação da estrutura e geralmente o
melhor a se fazer é manter o tamanho físico em arquivo de ambas as páginas
iguais.

Páginas internas:
As páginas internas apresentam apenas referências para a localização
das chaves de busca contidas nas páginas folha. Estas páginas incluem a
página raiz da árvore e todos os nodos internos (exceto as páginas folha). Ou
seja, as páginas internas funcionam como um índice que apenas apontam para
a localização exata de uma chave e sua construção é semelhante ao de uma
árvore B com número mínimo de chaves igual a [n/2]-1 e máximo de n-1 por
página.

Páginas folha:
Nas páginas folha estão abrigadas todas as chaves inseridas e durante
o processo de inserção e remoção de chaves estas podem sofrer overflows ou
underflows conforme estas violem o número máximo igual a d ou mínimo igual
a [d/2] permitido de chaves.
A operação de busca sobre uma árvore B+ pode ser realizada de duas
maneiras: iniciando a busca (linear ou binária) pelo apontador para o ‘sequence
set’ ou pelo apontador para a raiz da árvore. O método mais eficiente é pelo
apontador para a raiz na qual é semelhante ao realizado numa árvore B. Dessa
forma quando buscamos uma chave k, percorremos a árvore de cima para
baixo carregando as páginas internas e selecionando a página apontada pelo
ponteiro correspondente ao intervalo no qual pertence k e caso uma cópia de k
esteja numa página interna devemos carregar a página à direita de k.
Encontrado uma página folha o algoritmo deve buscar k nesta e responder se
ela se encontra ou não.

Construção do Banco de Dados Vídeo Locadora

 Decidimos pela criação do Banco de Dados de uma Vídeo Locadora. No
início, escolhemos esse modelo de “mini mundo” por parecer que seria simples
a sua construção, mas não foi bem assim. Também escolhemos esse tema por
termos muitas opções para determinados tipos de tabelas, tantos que, ao longo
do trabalho, nós excluímos algumas tabelas do projeto que não eram tão
essenciais, e estavam complicando o nosso trabalho. Mesmo após a
eliminação dessas tabelas, nosso projeto ainda ficou com 8 (oito) tabelas, são
elas:

dist_nac = Distribuidor Nacional.

Tabela composta das seguintes colunas; id_dist, nome, email e telefone. Sendo
a coluna id_dist a Chave Primária da tabela. Todas as outras colunas são Não Nulas.

estudios = Estúdios.
Tabela composta das seguintes colunas; id_estudio, nome, país e id_dist.
Sendo a coluna id_estudio a Chave Primária da tabela. A coluna nome é Não Nula, e a coluna
pais pode ser Nula.

A coluna id_dist é uma Chave Estrageira para a tabela dist_nac, e possui as

restrições ON DELETE RESTRICT (impede que uma linha referenciada por ela seja excluída
na tabela dist_nac) e ON UPDATE CASCADE (atualiza a linha quando houver atualização na
tabela referenciada).

filmes = Filmes.
Tabela composta das seguintes colunas; id_filme, nome, diretor, id_estudio,
ano_lanc, gênero e esrb. Sendo a coluna id_filme a Chave Primária da tabela. Todas as
colunas, com exceção da esrb, são NOT NULL.

A coluna id_estudio é uma Chave Estrangeira para a tabela estúdios, e possui

as restrições ON DELETE RESTRICT e ON UPDATE CASCADE.

departamento = Departamento.
Tabela composta das seguintes colunas; id_depto, id_super, nome_depto.
Sendo a coluna id_depto a Chave Primária da tabela. Todas as colunas são NOT NULL. A
coluna id_super é uma chave estrangeira que referencia a tabela empregados.

OBS: A chave estrangeira foi adicionada posteriormente para evitar erros de

criação da tabela por referenciar uma tabela não existente, onde existe um auto relacionamento
entre as duas.

empregados = Empregados.
 Tabela composta das seguintes colunas; matricula, nome, cpf, id_depto,
função, salario. Sendo a coluna matricula a Chave Primária da tabela. Todas colunas são NOT
NULL. A coluna id_depto é uma chave estrangeira que referencia a tabela departamento. A
coluna salário possui uma restrição CHECK, que verifica se o salário do funcionário é maior
que zero.

OBS: A chave estrangeira foi adicionada posteriormente para evitar erros de

criação da tabela por referenciar uma tabela não existente, onde existe um auto relacionamento
entre as duas.

estoque = Estoque.
Tabela composta das seguintes colunas; id_estoque, id_filme, id_disco,
quantidade. Sendo a coluna id_estoque a Chave Primária da tabela. Todas as colunas são
NOT NULL. Essa tabela possui a Chave Estrangeira id_filme, que referencia a tabela Filmes, e
possui as restrições de ON DELETE CASCADE e ON UPDATE CASCADE. Essa tabela
também possui a restrição CHECK, que evita que a coluna quantidade fique negativa.

clientes = Clientes.
Tabela composta das seguintes colunas; id_cliente, cpf, nome, endereço, email
e telefone. Sendo a Chave Primária composta das colunas id_cliente e cpf. Todas as colunas,
com exceção da endereço, são NOT NULL.

locacoes = Locações
Tabela composta das seguintes colunas; n_nota, id_cliente, id_estoque,
prazo_dev, preco. Sendo a coluna n_nota a Chave Primária da tabela. As colunas id_cliente e
id_estoque são Chaves Estrangeiras que referenciam, respectivamente, as tabelas Clientes e
Estoque. Ambas as chaves estrangeiras possuem as restrições ON DELETE CASCADE e ON
UPDATE CASCADE. A coluna preço possui a restrição CHECK, que permite apenas valores
positivos na coluna.

Na construção do banco de dados da Vídeo Locadora, tivemos um

grande problema ao criar as tabelas ‘departamento’ e ‘empregado’, pois as
duas tabelas possuem um auto relacionamento, onde o campo ‘id_super’ da
tabela departamento, deve conter obrigatoriamente um valor que exista na
tabela ‘empregado’, já que não é possível o departamento ter um supervisor
que não seja um empregado. E na tabela ‘empregado’, o campo ‘id_depto’
deve conter obrigatoriamente um valor que exista na tabela ‘departamento’, já
que todo empregado deve estar vinculado a um departamento. Esse auto
relacionamento foi confuso no começo, pois não era possível criar uma tabela
sem que a outra não existisse, e vice-versa. Então com um pouco de pesquisa
e ajuda do professor, decidimos criar as tabelas sem as chaves estrangeiras, e
fazer a inserção de dados em ambas, e só depois fizemos as alterações nelas
(usando o ALTER TABLE) para criação das Chaves Estrangeiras.
Criamos duas visões para esse banco de dados:
  EmpSemSalario: Essa visão tem como objetivo mostrar todos os
dados da tabela empregado com exceção da coluna ‘salário’,
evitando que algum funcionário não autorizado visualize o salário
de outros empregados;
 ClienteRestrito: Semelhante à visão EmpSemSalario, a visão
ClienteRestrito evita que dados pessoais/sigilosos dos clientes,
como, por exemplo, CPF, sejam indevidamente acessados

Para melhor estruturar o banco de dados, criamos um ‘trigger’ e um

‘procedure’ que trabalham juntos da seguinte forma:
 Sempre que um vídeo é locado, um trigger denominado
‘verifica_estoque’ é acionado, chamando um ‘procedure’
denominado ‘valida_estoque’ (que não recebe nada como
parâmetro, e também não retorna nada), que subtrai da tabela
‘estoque’ um item do campo ‘quantidade’ referente ao titulo
alugado.

Criamos, para fins de teste, algumas consultas. Sendo elas:

 Selecionar todos os valores da visão EmpSemSalario, para
validarmos sua funcionalidade;
 Selecionar todos os filmes onde a classificação etária seja menor
ou igual à 12 anos;
 Selecionar, do estoque, todos os títulos cujo sua mídia seja Blu-
Ray;
 Selecionar todos os valores da visão ClienteRestrito, para
validarmos sua funcionalidade.
 Referências:
VENNAPUSA, Priya. Oracle Database 10g: SQL Tunning Workshop. Student Guide Volume 1.
Oracle University. 2004.

ELMASRI, Rames; NAVATHE, Shamkant B. Sistemas de Banco de dados. 4ª ed. São Paulo:
Person Addison Wesley, 2005, 724 p.