UNIDADE 4 - Banco de Dados

Prévia do material em texto

1 
 
UNIDADE 4. 
Implantação de bancos de dados relacionais 
OBJETIVOS DA UNIDADE 
 
• Implantação de bancos de dados relacionais 
• Tecnologias emergentes para bancos de dados 
• Segurança em bancos de dados 
 
 
TÓPICOS DE ESTUDO 
 
Inserindo, eliminando e alterando dados 
// Criando e manipulando tabelas 
// Criação das tabelas 
// Inserindo dados nas tabelas 
// Copiando dados e gerando nova tabela a partir de uma existente 
// Alterando dados da tabela 
// Eliminando dados da tabela 
// Alterando a estrutura da tabela 
 
 
Incluindo restrições de dados em tabelas– 
// Criando visões de dados 
// Criando sequências 
// Criando índices 
 
Tecnologias emergentes para bancos de dados– 
// Banco de dados não relacional e suas aplicações 
// Banco de dados orientado a objetos e suas aplicações 
 
Segurança em banco de dados– 
// Definição de perfis de usuário (roles) 
// Ataques típicos em bancos de dados (SQL injection e outros) 
// Soluções de segurança para bancos de dados 
 
 
2 
 
Inserindo, eliminando e alterando dados 
Olá, aluno! Nesta unidade iremos continuar com os estudos sobre 
a Linguagem SQL para implantação de bancos de dados 
relacionais. Também iremos abordar aspectos de segurança e 
tecnologias emergentes de banco de dados. 
Criaremos uma nova base de dados e algumas tabelas, que serão 
manipuladas através dos principais comandos da Linguagem SQL 
para inserção, exclusão, consulta e alteração de dados e suas 
particularidades. Preparados? Então vamos lá. 
 
CRIANDO E MANIPULANDO TABELAS 
Iremos utilizar o SGBD MariaDB, baseado em MySQL, no modo de 
comandos. Caso você ainda não o tenha, acesse o link disponível 
nas referências bibliográficas dessa unidade (MARIADB 
FOUNDATION, 2019). Uma vez instalado, para acessá-lo, é 
necessário autenticá-lo no MySQL. Para tanto, utilize um dos 
comandos a seguir: 
mysql -u root -p 
Em seguida, será solicitada a senha do usuário root que 
você cadastrou durante a instalação do MariaDB ou 
qualquer outro SGBD. 
Podem ser usados também: 
mysql --user=root --password=sua-senha 
ou 
mysql -h127.0.0.1 -Dmysql -P3306 -uroot -p 
 
 
3 
 
A Figura 1 apresenta todo o processo de autenticação no SGBD. 
 
Agora estamos prontos para continuar com os estudos e 
experimentos da Linguagem SQL. Os comandos podem ser 
digitados em letras minúsculas ou maiúsculas, porém, pode haver 
algum SGBD ou sistema operacional que exija uma ou outra 
forma. 
Nesse material, adotaremos o seguinte padrão: os comandos e 
seus parâmetros em maiúsculo e a maioria dos argumentos em 
minúsculo, apenas para uma melhor leitura e entendimento do 
comando. Os nomes das bases de dados e tabelas em minúsculo; 
os atributos, não sendo sigla, sempre iniciando em maiúsculo e o 
restante em minúsculo. Lembrando que isso não é uma regra da 
Linguagem SQL, mas alguns SGBDs se comportam dessa maneira. 
Antes de iniciarmos, veremos o estado inicial do banco de dados 
MySQL. Vamos mostrar as bases de dados existentes com o 
comando a seguir. Veja o retorno do comando na Figura 2. 
 
SHOW DATABASES; 
4 
 
Lembre-se que sempre nos finais de comandos devemos colocar 
um ponto-e-vírgula: “;”. 
 
Caso você ainda não tenha criado alguma outra base de dados, a 
resposta ao comando será a exibição das bases de dados já 
instaladas com o produto (Figura 2). Essas bases pertencem ao 
próprio MySQL para execução de funcionalidades de controle e 
gerenciamento. 
O SGBD organiza o banco de dados em diversas bases de dados e, 
em cada uma, podemos criar várias tabelas com seus atributos. 
Logo, ao nos referenciarmos ao nosso banco de dados, usaremos o 
termo “base de dados”, que são sinônimos, mas apenas para não 
haver confusão sobre qual base está sendo referida. Cada banco 
de dados organizado pelo SGBD é, portanto, composto por sua 
base de dados, com suas tabelas e atributos totalmente 
independentes e acessados separadamente de outras bases de 
dados no mesmo SGBD. 
Vamos iniciar criando uma nova base de dados chamada 
Controle_de_Vendas, mas, como o MySQL normalmente converterá 
o nome das bases de dados para minúsculo, vamos então 
5 
 
referenciá-la sempre em minúsculo: controle_de_vendas. O 
comando para criação de bases de dados é CREATE DATABASE, 
seguido do nome da base de dados. Logo, o comando deverá ser 
digitado da seguinte forma: 
 
CREATE DATABASE controle_de_vendas; 
 
SHOW DATABASES; – listará as bases criadas. 
SHOW TABLES; – listará as tabelas criadas. 
SHOW CREATE TABLE nome da tabela; – listará a 
estrutura da tabela indicada. 
SHOW CREATE DATABASE nome da base de dados; 
– listará dados sobre a base de dados indicada. 
 
Agora, para acessar a base de dados criada, é necessário o 
comando USE seguido do nome da base de dados: 
USE controle_de_vendas; 
Você perceberá que o prompt de comando do MySQL trará sempre 
o nome da base de dados em uso. Para operar outras bases de 
6 
 
dados, basta apenas dar um comando USE e o nome da outra 
base. 
Para ficar claro o que será feito, analise o Diagrama 1 a seguir com 
o modelo lógico do banco de dados que será implantado. Faça uma 
análise das tabelas que serão criadas, seus atributos e 
relacionamentos. 
Estamos prontos para implantar nossas tabelas. O comando que 
permite criar tabelas é o CREATE TABLE seguido do nome da tabela 
e da lista de atributos, com suas características entre parênteses. 
Exemplo: 
 
7 
 
Algumas ferramentas CASE, como o BRModelo (2019), já criam uma 
boa parte dos scripts SQL para adiantar a tarefa de codificação 
para SQL (Figura 3), mas como é necessário assimilar bem a sintaxe 
de cada comando, é recomendável que você digite comando a 
comando. Por essa razão, todos serão explicados separadamente. 
É possível digitar grandes scripts SQL (códigos em SQL) em um 
editor de texto simples, e posteriormente transferi-los para os 
SGBDs. A maioria dos SGBDs permite que você copie e cole tudo de 
uma vez, mas isso é um recurso de produtividade para quem já 
possui a experiência necessária nos comandos. Para quem está 
iniciando, o ideal é ver e perceber as transformações junto ao 
banco de dados. 
 
8 
 
CRIAÇÃO DAS TABELAS 
Para uma leitura mais clara de cada comando, vamos apresentar 
os códigos com um atributo em cada linha. Para o SGBD é 
indiferente; ele só executará o comando quando encontrar o 
ponto-e-vírgula. Você poderá digitar cada bloco a seguir 
diretamente no prompt do SQL, na sequência que iremos 
apresentar. Entre um e outro CREATE, você pode usar o SHOW 
TABLES; para acompanhar a evolução. 
/* Tabela Clientes: */ 
CREATE TABLE Cliente ( 
Cod_cli INTEGER PRIMARY KEY, 
Nome VARCHAR (50), 
Endereco VARCHAR (50), 
Telefone VARCHAR (20) 
); 
 /* Tabela Fornecedor */ 
CREATE TABLE Fornecedor ( 
Cod_for INTEGER PRIMARY KEY, 
Contato VARCHAR (25), 
Endereco VARCHAR (50), 
Telefone VARCHAR (25) 
); 
 /* Tabela Produto */ 
CREATE TABLE Produto ( 
Cod_pro INTEGER PRIMARY KEY, 
Descricao VARCHAR (50), 
Valor_unitario DOUBLE (6,2), 
Cod_Fornecedor INTEGER, 
Data_cadastro DATE 
); 
9 
 
CREATE TABLE Vendas ( 
NF INTEGER PRIMARY KEY, 
Cod_Cli INTEGER, 
Cod_Pro INTEGER, 
Data_venda DATE, 
Valor_venda DOUBLE, 
Vendedor VARCHAR (50), 
Regiao VARCHAR (25) 
); 
 
Perceba que os primeiros campos de cada tabela são chaves 
primárias, logo, não será permitido repetir valores nesses campos. 
Opcionalmente, um campo pode ser do tipo AUTO_INCREMENT, 
que receberá um novo número sequencial a cada novo registro, 
como um contador, inclusive um campo-chave. Exemplo: 
Numautomático INTEGER NOT NULL AUTO_INCREMENT; 
Os tipos dos campos estão em destaque. São 
eles: INTEGER, VARCHAR, DOUBLE e DATE. Existem variações 
desses tipos, como: INT, CHAR, DATETIME, FLOAT, entre outros. 
O INTEGER só aceitará números inteiros, já DOUBLE, números com 
casas decimais, VARCHAR é do tipo texto (alfanumérico) e DATE é 
do tipo data.Entre parênteses estão as precisões de cada campo, ou seja, seu 
tamanho. Cuidado com o DOUBLE, pois em alguns sistemas você 
terá que usar o ponto em vez da vírgula para separar o decimal. 
Você poderá consultar a estrutura das tabelas criadas com o 
comando DESCRIBE nome da tabela;. Para consultar os comandos 
que originaram a tabela, use o comando SHOW CREATE 
TABLE nome da tabela;. Exemplo: 
SHOW TABLES; /* Apenas mostra as tabelas */ 
DESCRIBE cliente; /* Descreve a tabela */ 
10 
 
SHOW CREATE TABLE cliente; /* Mostra a estrutura 
da tabela */ 
 
INSERINDO DADOS NAS TABELAS 
Vamos agora popular as tabelas. O comando que utilizaremos para 
inserir dados nas tabelas é o INSERT. Os dados são preenchidos na 
ordem em que apresentamos os campos nos parênteses. Seu 
formato geral é: 
INSERT INTO tabela(nomes dos atributos) VALUE (conteúdo de 
cada campo). 
 
Inserindo dados na tabela Cliente: 
INSERT INTO Cliente(Cod_cli, Nome, Endereco, Telefone) VALUE 
(10, “João Santos”, “Al. Gomes, 50 – Bom Retiro/SP”,”11-3456-7899”); 
 
Podemos ainda, em um único comando, adicionar vários registros 
da seguinte forma: 
INSERT INTO Cliente(Cod_cli, Nome, Endereco, Telefone) VALUE 
(34, “Andrea Santos”, “Av. Santara, 4550 – Lapa/SP”, “11-2453-
8899”), 
(22, “Matheus Silva”, “Rua Albuquerque, 2350 – Morumbi/SP”, “11-
6456-7899”), 
(25, “Adriana Simões”, “Rua Menezes, 40b – Penha/SP”, “11-2356-
7812”), 
(67, “Julia Roberta”, “Av. Paulista, 1270 – Centro/SP”, “11-3456-
7889”), 
(13, “Ruy Barbosa”, “Av. Soares, 280 – Guarulhos/SP”, “11-2456-
4894”); 
O problema é que, se você errar algo, deverá digitar novamente 
todo o comando. É possível copiar e colar, mas o ideal é você ir 
11 
 
inserindo cada registro e alternar com o comando SELECT * from 
cliente para observar a tabela, sendo populada gradativamente, 
como pode ser visto na Figura 4. 
 
Inserindo dados na tabela Fornecedor: 
INSERT INTO Fornecedor(Cod_for, Contato, Endereco, 
Telefone) VALUE 
(250, “Suzana”, “Av. Alcântara, 22 – Guarujá/SP”, “13-8853-5699”), 
(100, “Moisés”, “Rua Albuquerque, 150 – Morumbi/SP”, “11-5556-
7899”), 
(150, “Ana Maria”, “Rua Menezes, 34 – Itaim/SP”, “11-2256-7812”), 
(300, “Carlos Roberto”, “Av. São Paulo, 70 – Brás/SP”, “11-4456-
7889”), 
(200, “Estela”, “Av. Brigadeiro, 450 – Santana/SP”, “11-5556-4894”); 
 
12 
 
 
 
Inserindo dados na tabela Produto: 
INSERT INTO Produto(Cod_pro, Descricao, Valor_unitario, 
Cod_Fornecedor, Data_cadastro) VALUE 
(2050, “Processador i3”, 560.40, 300, CURDATE()), 
(1010, “Memória DDR-3”, 340.25, 150, “2019-02-20”), 
(4150, “Monitor 19”, 750.00, 300, CURDATE()), 
(3020, “Teclado 101 TC”, 90.50, 444, “2018-11-14”); 
 
Observe que, opcionalmente, pode-se determinar que a data de 
cadastro de alguns produtos seja fornecida pela função CURDATE(). 
Perceba também que o produto de código 3020 foi cadastrado sem 
que houvesse um código de fornecedor válido (Figura 6), já que 
não existe nenhum fornecedor com o código 444. Mais adiante, 
aprenderemos como evitar esse problema, criando restrições e 
garantindo a integridade dos dados. 
13 
 
 
 
Inserindo dados na tabela Vendas: 
INSERT INTO Vendas(NF, Cod_Cli, Cod_Pro, Data_venda, 
Valor_venda, Vendedor, Regiao) VALUE 
(500010,13,1010,“2019-02-20”, 340.25, “Pedro”, “Zona 
Norte”),(500005,34,2050, “2019-02-20”, 560.40, “Marcos”, “Zona 
Sul”),(500002,25,3333,“2019-03-24”, 900, “Sonia”, “Zona 
Leste”),(500003,13,4150,“2019-03-25”, 750.00, “Paulo”, “Zona 
Norte”); 
Observe que foi registrada uma venda com código de produto 
inexistente, o 3333, assim como ocorreu na tabela Produto, e isso 
não é aceitável para um banco de dados íntegro. Por essa razão, 
aprenderemos a criar restrições para que essas inconformidades 
não ocorram. 
14 
 
 
COPIANDO DADOS E GERANDO NOVA TABELA A 
PARTIR DE UMA EXISTENTE 
É possível fazer a cópia de uma tabela gerando outra com todos os 
dados preservados. O comando genérico é: 
CREATE TABLE nova tabela SELECT * FROM tabela existente; 
 
O exemplo a seguir duplicará a tabela Vendas, gerando a 
tabela VendasCopia: 
CREATE TABLE VendasCopia SELECT * FROM Vendas; 
 
Perceba que será criada uma tabela idêntica à Vendas, com o 
nome VendasCopia, com todos os atributos e dados da tabela de 
origem. Mas muitas vezes desejamos escolher apenas alguns 
campos que queremos para uma nova tabela e em ordem 
diferente das colunas. Veja o exemplo a seguir e seu resultado na 
15 
 
Figura 8, onde apenas três atributos foram escolhidos para compor 
a tabela VendasRegiao: 
CREATE TABLE VendasRegiao SELECT NF,Regiao, 
Data_venda FROM Vendas; 
 
 
A partir desse ponto, como veremos comandos que alterarão 
dados e estruturas das tabelas, vamos também fazer uma cópia da 
tabela de clientes. Para exercitar, duplique todas as tabelas que 
você criou. 
CREATE TABLE Cliente2 SELECT * FROM Cliente; 
 
ALTERANDO DADOS DA TABELA 
16 
 
 
UPDATE nome da tabela SET campo a alterar = novo 
conteúdo WHERE campo-chave ou outro = dado existente; 
Exemplo: 
UPDATE Vendas SET Regiao = “Zona Oeste” WHERE NF = 500005; 
 
No exemplo, apenas a venda com a nota fiscal 500005 terá a região 
trocada de “Zona Sul” para “Zona Oeste”. Preferencialmente, 
devemos usar o campo-chave para realizar a condição de busca 
inequívoca, mas muitas vezes desejamos trocar vários registros ao 
mesmo tempo. Nesse caso, devemos escolher algum campo que 
possa conter conteúdos em comum. Por exemplo, trocar todos os 
conteúdos do campo Região para “Zona Oeste” quando o vendedor 
for “Marcos”. Exemplo: 
UPDATE Vendas SET Regiao = “Zona Oeste” WHERE Vendedor = 
“Marcos”; 
 
Podemos ainda trocar o nome do vendedor para “ANA”, quando o 
código do cliente for 13. Veja que na Figura 7 existem duas vendas 
para esse cliente: 
UPDATE Vendas SET Vendedor = “ANA” WHERE Cod_Cli = 13; 
17 
 
Obviamente, é aconselhável você alternar esses comandos com o 
SELECT para visualizar as mudanças na tabela. Na Figura 9, é 
possível ver como ficou a tabela Vendas depois desses últimos 
comandos. 
 
 
 
DELETE from nome da tabela WHERE campo-chave = condição; 
18 
 
Vejamos vários exemplos diferentes para apagar registros. 
Intercale com o comando SELECT na tabela afetada para 
acompanhar as exclusões. Exemplo para apagar um registro 
específico: 
DELETE FROM VendasCopia WHERE NF=500002; 
 
Exemplo para apagar um grupo de registros do mesmo vendedor: 
DELETE FROM VendasCopia WHERE Vendedor= “Ana”; 
 
Exemplo para apagar um grupo de clientes que começam com a 
letra A, da tabela Cliente2. 
DELETE FROM cliente2 WHERE Nome LIKE “A%”; 
 
Exemplo para apagar TODOS os registros da tabela VendasCopia: 
DELETE FROM VendasCopia; 
 
ALTERANDO A ESTRUTURA DA TABELA 
O comando ALTER TABLE permite alterar a estrutura de tabelas 
sem perda de dados, desde que os ajustes sejam de natureza 
compatível com os campos alterados. Não é possível, por exemplo, 
transformar campos que guardam letras em números. Podemos 
acrescentar, excluir e alterar os campos da tabela. O formato 
genérico do comando é: 
ALTER TABLE nome_da_tabela MODIFY campo 
novo_tipo_do_campo; 
 
 
19 
 
O exemplo a seguir trocará o tipo do campo para INTEGER, se este 
for compatível, como double, int, float, entre outros. Mas nesse 
caso as casas decimais serão perdidas. 
ALTER TABLE vendascopia MODIFY Valor_venda INTEGER; 
 
Podemos ainda acrescentar, eliminar ou renomear campos da 
tabela, trocando o parâmetro MODIFY por outras opções. Vejamos 
os exemplos a seguir. 
Acrescentar campos na tabela: 
ALTER TABLE vendascopia ADD COLUMN Estado Varchar(25); 
ALTER TABLE vendascopia ADD COLUMN Sigla Char(2) NOT 
NULL; 
 
Trocar o nome do campo e definir um valor-padrão inicial: 
ALTER TABLE vendascopia CHANGE Sigla UF Char(2) DEFAULT ‘SP’; 
 
Excluir campo da tabela. Todos os dados da coluna serão perdidos: 
ALTER TABLE vendascopia DROP Sigla;INSERT INTO Vendas(NF, Cod_Cli, Cod_Pro, Data_venda, 
Valor_venda, Vendedor, Regiao) VALUE 
(500080,88,8888,“2019-02-20”, 340.25,”Pedro”,”Zona Norte”); 
 
Incluindo restrições de dados em tabelas 
Em nossa implantação do banco de dados Controle_de_Vendas, 
algumas das tabelas necessitam de um ajuste importante. Vamos 
criar uma declaração de chave estrangeira para as tabelas Produto 
e Vendas, que fazem referência aos campos-chave das tabelas 
20 
 
Fornecedor e Cliente. Conceitualmente falando, Produto e Vendas 
são entidades “fracas”, pois dependem das entidades Fornecedor e 
Cliente para existir, as quais, por sua vez, são entidades “fortes”, 
não dependendo de nenhuma outra. Uma venda depende do 
cliente para comprar, e o produto depende do fornecedor para 
fabricá-lo, mas isso não é recíproco. O cliente e o fornecedor 
existem de forma independente e podem ser cadastrados 
livremente, sem a necessidade de verificação com outras tabelas. 
Quando esta declaração for realizada, o relacionamento entre elas 
estará efetivado e RESTRIÇÕES serão estabelecidas. Isso implica 
dizer que nenhum registro que não obedeça a relação de restrição 
imposta será aceito nas tabelas “fracas” envolvidas, ou seja, a 
inserção de dados será negada se não houver um item 
correspondente nas entidades de referência. Um produto não será 
cadastrado se o fornecedor não for informado ou se não existir na 
tabela Fornecedor. Da mesma forma, uma venda não será 
cadastrada se o cliente ou o produto não existir em suas devidas 
tabelas. 
Perceba que a tabela Produto é uma entidade “forte” quando se 
relaciona com a tabela Vendas, já que não existem vendas sem 
produtos, mas é uma entidade “fraca” quando se relaciona com a 
tabela Fornecedor, já que todo produto necessita de um 
fornecedor. Pode-se ainda afirmar que há uma relação de 
cardinalidade de 1 para N do ponto de vista da tabela Produto, pois 
todo produto poderá ser fornecido por um ou vários fornecedores, 
jamais nenhum, e há uma cardinalidade de 0 para N do ponto de 
vista da tabela Fornecedor, pois um fornecedor poderá ter nenhum 
ou vários produtos. 
Vamos verificar o esquema relacional das quatro primeiras tabelas 
criadas na base de dados Controle_de_Vendas e observar o 
relacionamento entre as chaves primárias e estrangeiras: 
 
Cliente (Cod_cli, Nome, Endereco, Telefone). 
Fornecedor (Cod_for, Contato, Endereco, Telefone). 
21 
 
Produto (Cod_pro, Descricao, Valor_unitario, fk_Cod_Fornecedor, 
Data_cadastro). 
Vendas (NF, fk_Cod_Cli, fk_Cod_Pro, Data_venda, Valor_venda, 
Vendedor, Regiao). 
 
Observe que as chaves primárias aparecem sublinhadas, e as 
chaves estrangeiras em negrito, com uma notação fk (foreign key) 
antes de cada campo, sendo tal notação opcional, mas útil quando 
não houver como destacar esses elementos. 
Importante: como os comandos a seguir 
envolvem restrições entre as tabelas Produto e Fornecedor, 
inconsistências podem aparecer. É altamente recomendável que 
você revise os produtos cadastrados na tabela Produto e 
verifique se todos possuem fornecedor válido cadastrado na 
tabela Fornecedor. Caso contrário, você será alertado a fazê-lo 
pelo próprio SQL, que não conseguirá aplicar as restrições 
impostas pelos novos comandos. Se necessário, altere ou 
elimine o produto que não tenha um fornecedor válido. Caso 
necessite, você poderá criar uma nova base de dados com outro 
nome, criar as mesmas tabelas e inserir novamente todos os 
primeiros registros (Figuras 4, 5, 6 e 7). Também pode usar 
copiar/colar nos scripts, excluindo ou alterando os produtos 
sem fornecedores válidos. Perceba que, no produto de código 
3020, o fornecedor cadastrado é o 444, que propositalmente 
não existe na tabela Fornecedor. Uma vez aplicados os novos 
comandos de restrição, não será mais permitida a entrada de 
fornecedor inexistente na tabela Produto. 
 
Vamos então ver o código SQL necessário para fazer essa 
declaração de chave estrangeira, o relacionamento entre as tabelas 
envolvidas, ou seja, aplicar restrição. Segue o formato genérico 
22 
 
simplificado para declarar uma chave estrangeira e a restrição 
desejada: 
ALTER TABLE Entidade_Fraca ADD 
CONSTRAINT fk_Nome FOREIGN KEY (chave 
estrangeira) REFERENCES Entidade_Forte (chave primária); 
Onde: 
Entidade_Fraca: Também chamada de tabela-filha. 
 
ADD Constraint: Significa “adicionar restrição”. 
 
FK_Nome: É o nome da restrição criada. Para o SQL é um índice para 
facilitar o acesso aos dados relacionados, mas conceitualmente é 
como se fosse o nome do relacionamento. É comum o nome desse 
item ser uma combinação do nome das duas tabelas – por exemplo: 
“Produto e Fornecedor” ficaria fk_Pro_For. 
 
FOREIGN KEY: Parâmetro para declaração da chave estrangeira. 
 
REFERENCES: Parâmetro para declaração da entidade forte ou tabela 
de referência, também chamada de tabela-pai, e sua chave primária. 
 
Os dois exemplos a seguir adicionarão restrições que não 
permitirão que um produto seja cadastrado sem um fornecedor 
válido. Também não permitirão que um fornecedor da tabela 
Fornecedor seja excluído ou que seu código seja alterado (se 
estiver na tabela Produto). Para excluir um fornecedor, antes, o 
produto que o referencia deverá ser excluído, ou o código do 
fornecedor deverá ser trocado por outro válido na tabela Produto. 
Só assim o fornecedor ficará livre para ser excluído na tabela 
Fornecedor. Isso é uma restrição total. Vejamos: 
ALTER TABLE Produto ADD 
CONSTRAINT fk_Produto_Fornecedor FOREIGN 
KEY (Cod_Fornecedor) REFERENCES Fornecedor (Cod_for); 
23 
 
ou 
ALTER TABLE Produto ADD 
CONSTRAINT fk_Pro_For FOREIGN KEY 
(Cod_Fornecedor) REFERENCES Fornecedor (Cod_for) ON 
DELETE NO ACTION ON UPDATE NO ACTION; 
 
Os dois exemplos se equivalem no MySQL. Logo, se nenhum 
parâmetro for informado após o ON DELETE ou no ON UPDATE, 
o NO ACTION será assumido por padrão. Em outros SGBDs pode 
ser diferente. Tais parâmetros informam o que será feito quando 
um registro for excluído ou alterado na tabela-pai, ou seja, a tabela 
de referência no relacionamento. Nesse caso, a restrição máxima 
será mantida, já que nenhuma outra ação foi informada. Perceba 
que o comando é aplicado na tabela entidade_fraca (ou filha) 
Produto, mas, dependendo dos parâmetros, acaba afetando 
também a entidade_forte (ou pai) Fornecedor. 
 
O exemplo a seguir, com parâmetro CASCADE, também impede 
que um produto seja cadastrado sem um fornecedor válido, porém 
tem um comportamento diferente no caso de alterações ou 
exclusões do fornecedor. Se o código do fornecedor na tabela 
Fornecedor for alterado, automaticamente todos os seus produtos 
serão atualizados com o novo código. Se o fornecedor for excluído 
da tabela, todos os produtos com esse fornecedor serão também 
24 
 
automaticamente excluídos. Isso é uma restrição parcial, já que 
permite alguns ajustes. Vejamos: 
ALTER TABLE Produto ADD 
CONSTRAINT fk_Pro_For FOREIGN KEY 
(Cod_Fornecedor) REFERENCES Fornecedor (Cod_for) ON 
DELETE CASCADE ON UPDATE CASCADE; 
 
Pode ser criada uma restrição para alteração (update) de dados 
diferente de exclusão (Delete) de dados entre tabelas relacionadas. 
Na prática, os parâmetros NO ACTION e CASCADE podem ser 
combinados. Exemplo: 
ALTER TABLE Produto ADD 
CONSTRAINT fk_Pro_For FOREIGN KEY (Cod_Fornecedor) REFERE
NCES Fornecedor (Cod_for) ON DELETE NO ACTION ON UPDATE 
CASCADE; 
No exemplo mostrado, a exclusão do fornecedor não será 
permitida (NO ACTION), mas alterações do código do fornecedor 
ocorrerão em efeito cascata (CASCADE), ou seja, se mudar o código 
do fornecedor na tabela Fornecedor, o mesmo ocorre na tabela 
Produto e vice-versa. 
Para eliminar uma restrição deixando as tabelas novamente 
independentes, basta informar o nome da restrição (nome do 
índice) com o comando: 
ALTER TABLE Produto DROP CONSTRAINT fk_Pro_For; 
 
CRIANDO VISÕES DE DADOS 
Visãode dados, ou view, como é mais conhecida, é uma “tabela 
virtual” que permite visualizar resultados de consultas de tabelas 
físicas, que muitas vezes são volumosas, e muita variedade de 
campos, trazendo uma visão mais otimizada dos dados, sem ter 
que reescrever comandos complexos de consultas. Isso simplifica a 
25 
 
interação entre usuário e banco de dados, pois ele pode realizar 
consultas como se fossem tabelas reais. Os dados do banco de 
dados são acessados das tabelas reais, assim que o acesso a 
uma view é solicitado. Elas não armazenam dados, logo, não 
ocupam espaço no banco de dados. 
Entre outros aspectos, permite um maior controle e segurança por 
restringir o acesso total à base de dados por qualquer usuário do 
banco de dados, pois oferece a possibilidade de liberar apenas 
consultas pontuais dependendo do grupo do usuário. 
 A sintaxe genérica do comando é: 
CREATE VIEW nome_da_View AS 
SELECT campos_da_tabela FROM tabela; 
 
Vejamos um exemplo simples, que usa uma view para criar uma 
agenda com os telefones dos fornecedores: 
CREATE VIEW Agenda_for AS SELECT Contato, telefone From 
Fornecedor; 
 
Para testar sua view, basta usar o comando SELECT, como se fosse 
em uma tabela normal: SELECT * FROM Agenda_for;. O mesmo 
para alterar e excluir, exatamente como fazemos em tabelas. 
 Pode-se criar views a partir de consultas mais elaboradas e 
sofisticadas, como: 
CREATE VIEW Vendas_por_Regiao AS SELECT * FROM 
Vendas INNER JOIN produto on Vendas.Cod_Pro = 
produto.cod_pro Where regiao LIKE (“ZONA NORTE”); 
 ou 
CREATE VIEW Vendas_Geral AS SELECT NF, Cod_Cli,vendas.Cod_Pro, 
Descricao, Valor_unitario from Vendas INNER JOIN produto on 
Vendas.Cod_Pro = produto.cod_pro; 
 
CRIANDO SEQUÊNCIAS 
26 
 
O SQL possui um recurso para criar um objeto na base de dados 
que gera uma sequência automática de números. O objeto é um 
elemento externo às tabelas, mas seu valor, sempre incrementado, 
pode ser usado para alimentar atributos que necessitem de um 
campo com essa característica. Uma sequência numérica pode ser 
útil, inclusive, por aplicações externas em que, ao acessarem o 
banco de dados, um novo número e exclusivo pode ser gerado. 
Contudo, dependendo do SGBD adotado, pode haver muitas 
variações deste recurso. 
 O formato genérico do comando é: 
CREATE SEQUENCE objeto_sequencial START WITH valor inicial 
INCREMENT BY incremento; 
 Vejamos alguns exemplos: 
Para gerar um número de 1 em 1, iniciando em 1: 
CREATE SEQUENCE Num_sequencial START WITH 1 INCREMENT 
BY 1; 
Para gerar um número iniciando em 1000 e variando de 10 em 10. 
CREATE SEQUENCE Num_seq START WITH 1000 INCREMENT BY 
10; 
 Para gerar um número iniciando em −100 e variando de −10 em 
−10. 
CREATE SEQUENCE Num_seq START WITH −100 INCREMENT BY –
10; 
Para ver o número atual: SELECT NEXTVAL(Num_seq);. 
Para ver ou gerar o próximo número, use: SELECT 
NEXTVAL(Num_seq);. 
 Para trazer informações sobre o objeto e sua sequência: 
SHOW CREATE SEQUENCE Num_seq \G; 
Para ver todos os objetos criados, use o comando: SHOW TABLES; 
 
27 
 
CRIANDO ÍNDICES 
Na manipulação diária dos bancos de dados, as consultas são 
frequentes e podem causar morosidade no tempo de resposta de 
bancos muito volumosos com milhares ou milhões de dados. 
Diante dessa situação, a criação de índices pode contribuir para 
garantir melhoria nesse tempo de resposta. Os índices ajudam o 
gerenciador do banco de dados a localizar os registros com mais 
facilidade. 
Ao executarmos uma consulta com o comando SELECT, onde são 
filtrados por um ou vários campos, o gerenciador do banco efetua 
uma ação de varredura na tabela, percorrendo-a por inteiro. Caso 
algum registro atenda às condições definidas no filtro, ele é 
selecionado no conjunto de resposta do comando e os demais são 
desconsiderados. Em campos numéricos, os índices são mais 
eficientes. 
Vejamos a sintaxe do comando genérico para criar índices em uma 
tabela: 
CREATE INDEX nome_do_índice ON nome_da_tabela(nome_do_campo); 
Exemplo: 
CREATE INDEX indexnome ON Cliente(Nome) 
 
Dessa forma, se fizermos uma pesquisa na tabela Cliente 
comparando nomes, a pesquisa se dará bem mais rapidamente, 
mas só é perceptível em tabelas volumosas. Exemplo: 
SELECT * FROM Cliente WHERE Nome LIKE "A%"; 
Perceba que, no comando de consulta, o índice criado (indexcli) 
não é explicitado, mas o gerenciador do banco sabe que para o 
campo Nome existe um índice criado. Para um campo-chave é 
desnecessário criar um índice, já que o próprio gerenciador se 
encarrega de indexá-lo. Só devemos criar índices para colunas que 
realmente são frequentemente acessadas para filtrar as pesquisas 
nas consultas, pois podem causar um esforço maior e sobrecarga 
28 
 
nas operações de inclusão, alteração ou exclusão de dados, 
degradando o tempo de resposta do banco de dados. 
Para eliminar um índice, basta usar o comando: 
 
DROP INDEX nomecli ON Cliente; 
 
É possível criar índices durante a criação da própria tabela. 
Exemplo: 
CREATE TABLE Livro( 
ID INT NOT NULL PRIMARY KEY, 
Codigo INT, 
Titulo VARCHAR(50), 
Autor VARCHAR(50), 
INDEX (Codigo), 
INDEX (Autor) 
); 
Tecnologias emergentes para bancos de dados 
Tecnologias emergentes tratam de tendências do emprego de 
tecnologias inovadoras, adaptadas, modernas ou não, mas que 
podem se tornar solução para as questões e necessidades 
crescentes no universo tecnológico, entre eles o dos bancos de 
dados. Muitas tendências podem se tornar realidade rapidamente 
e se confirmar como inovações aplicáveis, enquanto outras talvez 
sejam implantadas em futuros mais longínquos ou caírem no 
ostracismo, podendo voltar em algum momento. 
Usufruir dos benefícios de Big Datas, computação na nuvem, 
soluções via internet, por exemplo, já é realidade em vários 
segmentos, com crescentes necessidades de serviços escaláveis, 
capazes de se expandir. Para algumas áreas mais específicas, com 
grande variedade de tipos de dados e informações 
desestruturadas, em várias áreas do conhecimento, sempre 
apareceram barreiras nos modelos engessados dos bancos de 
dados relacionais, mas agora podem se beneficiar da 
potencialidade dos não relacionais. 
29 
 
No segmento dos bancos de dados, vimos que ao longo da história, 
vários tipos de bancos de dados surgiram, no entanto, ainda hoje o 
banco de dados relacional é o tipo mais implementado no mundo, 
mas devido sua limitação em lidar com dados mais específicos e 
críticos para algumas áreas, os bancos de dados orientados a 
objetos e os não relacionais, por alguns chamados de NoSQL (não 
usam SQL), começam a pegar cada vez mais força e passam a ser 
considerados como possíveis soluções para as lacunas e demandas 
não atendidas nesta área. Abordaremos então algumas 
características desses tipos de bancos de dados. 
 
BANCO DE DADOS NÃO RELACIONAL E SUAS 
APLICAÇÕES 
Bancos de dados não relacionais possuem em sua essência a não 
estruturação dos dados disponibilizados, como fazem os modelos 
relacionais, com tabelas organizadas e bem definidas, seus 
atributos com tipos invioláveis em sua natureza e limitação. São, 
portanto, tradados como bancos de dados não estruturados ou 
semiestruturados, chamados até de NoSQL. São disponibilizados 
de forma distribuída, provendo várias soluções e aplicações, 
principalmente no universo da internet. Elmasri e Navathe (2011) 
nominam esse tipo de banco de dados como “banco de dados de 
internet”, falando sobre como o armazenamento dos dados das 
páginas web tradicionais, por exemplo, diferem de bancos de 
dados estruturados. 
Alguns autores não identificam bancos não relacionais como 
aqueles que simplesmente não usam SQL, mas há uma corrente 
tratando do tema de bancos de dados não relacionais, como 
NoSQL, mas isso não é um consenso, até porque existem soluções 
SQL, mesmo que parciais e limitadas, para manipulação de dados 
não relacionais.Há anos, autores já anunciavam a capacidade de o 
SQL Server permitir transações com fontes de não relacionais: 
30 
 
 
Uma das características dos bancos de dados não relacionais é 
permitir que itens de dados do mesmo tipo possam ter diferentes 
conjuntos de atributos – ao contrário dos bancos de dados 
relacionais, onde dados do mesmo tipo normalmente são 
mantidos em atributos específicos. No modelo semiestruturado, 
não há exigência de um esquema predefinido para um tipo de 
objeto no qual os dados precisam estar em conformidade. Há 
também o modelo não estruturado, no qual a indicação do tipo dos 
dados é muito limitada. Um exemplo típico é um documento de 
texto e comando de marcação que contém informação embutida. 
Páginas web em HTML com alguns dados são consideradas dados 
não estruturados (ELMASRI; NAVATHE, 2011). 
 
BANCO DE DADOS ORIENTADO A OBJETOS E SUAS 
APLICAÇÕES 
A popularização e os benefícios do paradigma da programação 
orientada a objetos e suas diversas linguagens, como Java, C++, C#, 
entre outras, e as limitações impostas pelo modelo relacional, 
principalmente dentro do universo da web, levaram ao surgimento 
do modelo chamado “banco de dados orientado a objetos”. Esse 
tipo pode ser visto como uma extensão do modelo entidade-
relacionamento (ELMASRI; NAVATHE, 2011). 
Para Silberschatz, Korth e Sudarshan (1999), os principais 
fornecedores de banco de dados suportam o modelo de dados 
31 
 
objeto-relacional, que combina as caraterísticas do modelo de 
dados orientado a objetos e o modelo de dados relacional. Bancos 
de dados orientados a objetos podem armazenar objetos e 
compartilhá-los para aplicações diferentes. 
Os principais conceitos da orientação a objetos que compõem a 
estrutura desse banco de dados são: persistência de objetos, 
objetos complexos, presença de identificadores de objetos, 
aplicação de herança, métodos, dados estruturados, coleção, 
encapsulamento e polimorfismo. Alguns exemplos de sistemas 
gerenciadores de banco de dados orientado a objetos, chamados 
de SGBDOO, são o Objectivity/DB, o GemStone e o Jasmine. Os 
diagramas UML podem ser utilizados para representar a 
modelagem de dados em um projeto que envolva banco de dados 
orientado a objetos (MULLER, 2002). 
Algumas aplicações de bancos de dados orientados a objetos são: 
sistemas de design e produção, como computer-aided design (CAD) 
e computer-aided manufacturing (CAM), sistemas para a área 
científica e médica, sistemas de informação geográfica e bases de 
dados com informações multimídia. Tais aplicações possuem 
características como dados altamente estruturados, transações 
longas, dados em multimídia e operações fora do padrão, que as 
tornam diferentes das aplicações tradicionais (CHAUDRI; ZICARI, 
2001, p. 3). 
 
Segurança em banco de dados 
De maneira geral, a segurança do banco de dados é muito 
importante, tanto no aspecto físico e geográfico de suas 
instalações como no controle de acesso, seja in loco ou 
remotamente. 
32 
 
 
Um sistema gerenciador de banco de dados deve prover 
mecanismos que viabilizem ações de segurança a fim de garantir a 
integridade, a disponibilidade e a confidencialidade dos dados. 
 Veremos então alguns recursos que podem ser utilizados na 
preservação dos dados custodiados em um sistema gerenciador de 
banco de dados. 
 
DEFINIÇÃO DE PERFIS DE USUÁRIO (ROLES) 
Pode-se limitar o acesso de usuários a uma determinada base de 
dados, tabela ou campos, como também controlar o acesso de 
acordo com a workstation ou host do usuário, ou seja, a partir de 
onde foi realizada a conexão com o servidor do banco de dados. 
Pode-se conceder privilégios diferentes para cada host ou usuários 
que se conectam ao banco de dados. Dessa forma, é possível 
determinar, inclusive, quais ações podem ser executadas por um 
usuário, dependendo de onde foi realizada a conexão. 
Para criar usuários, usamos o comando CREATE USER e depois 
concedemos os “privilégios” de acesso com o comando GRANT. 
Caso o usuário não exista, é possível criá-lo também com esse 
comando. 
 
 
33 
 
A sintaxe geral do comando para criar usuário é: 
 
 
Agora, para dar “privilégio” total de acesso ao usuário para uma 
base de dados específica: 
 
 
Para criar um usuário local e determinar qual tabela e quais 
campos poderá acessar: 
 
 
 
34 
 
Nesse caso, o usuário foi criado, mas só poderá consultar a tabela 
Curso e apenas os campos Nome e Valor. Qualquer outra operação 
será negada. Para liberar acesso a várias bases, tabelas ou campos, 
o asterisco (*) poderá ser utilizado. 
 Para revogar os acessos concedidos, utilize o comando REVOKE da 
seguinte forma: 
 
 
Para ver todos os usuários criados no banco de dados: 
 
 
Para ver “privilégios” dos usuários e o que eles podem acessar: 
 
 
ATAQUES TÍPICOS EM BANCOS DE DADOS (SQL INJECTION E 
OUTROS) 
 
35 
 
Os ataques típicos em bancos de dados podem ser do tipo SQL 
injection (injeção de SQL) com alvo nos sistemas de bancos de 
dados tradicionais e também nos bancos de dados NoSQL das 
plataformas de Big Datas. Os ataques SQL injection consistem na 
inserção de instruções SQL não autorizadas ou mal-intencionadas 
em campos de entrada, normalmente de aplicações web, com 
preenchimento de dados em formulários para coleta de dados que 
serão enviados ao banco de dados. Já os ataques de injeção NoSQL 
consistem em inserir instruções maliciosas em componentes que 
interagem com Big Datas. 
Nos dois casos, um ataque desse tipo, sendo bem-sucedido, 
poderá conceder acesso sem restrições aos bancos de dados. 
Porém, tecnicamente, as soluções de Big Data não podem sofrer 
injeção de SQL, já que não usam tecnologia baseada em SQL, mas 
são suscetíveis ao mesmo tipo de ataque, ou seja, injeção de 
códigos maliciosos na entrada de dados. 
No caso de SQL injection, a vulnerabilidade pode ocorrer, por 
exemplo, quando a aplicação que recebe um dado de entrada para 
ser enviada e processada no servidor do banco de dados, 
concatena os dados coletados com os códigos de consultas SQL 
sem realizar o devido tratamento do dado passado pelo usuário ou 
pela aplicação, ocasionando a possibilidade de alteração de 
instruções SQL, diferentemente do previsto pela aplicação. 
 
SOLUÇÕES DE SEGURANÇA PARA BANCOS DE DADOS 
Uma solução ideal e definitiva, que garanta a segurança dos 
bancos de dados, simplesmente não existe. Há sempre 
possibilidades e vulnerabilidades que devem ser controladas e 
vigiadas constantemente. Aspectos internos, externos, humanos e 
cibernéticos estão em constantes transformações e propensas a 
riscos. Logo, a vigilância e a busca pela solução ideal devem ser 
incansáveis e permanentes. 
As ameaças são várias, e algumas boas práticas podem e devem 
ser adotadas. Entre elas, pode-se destacar: 
 
36 
 
1. Implantar políticas de segurança em TI; 
2. Evitar concessão de privilégios de acesso excessivos para 
posteriormente ficarem desatualizados e cair no 
esquecimento dos administradores; 
3. Prevenir abusos de privilégios e uso inconsequente por maus 
profissionais; 
4. Realizar testes manuais, por intermédio de ferramentas 
específicas diretamente nas aplicações do usuário para 
atestar a vulnerabilidade, como SQLMap, jSQL Injection, entre 
outras; 
5. Manter o banco de dados em um servidor exclusivo, com 
acesso físico e lógico protegido de intrusão; 
6. Prevenir o ambiente contra malwares; 
7. Realizar auditorias com frequência; 
8. Implantar política de backups eficientes; 
9. Evitar exposição desnecessária de mídias de storage de 
backups. 
 
Essas e outras atitudes combinadas poderão elevar o nível de 
segurança e nenhuma delas deverá ser subestimada nem 
valorizada a ponto de se classificar como absoluta e definitiva. 
Quando o assunto é segurança de dados, todo cuidado é pouco. 
 
SINTETIZANDO 
Caro aluno, nesse capítulo completamos os estudos sobre a 
LinguagemSQL. Vários comandos importantes e essenciais foram 
exemplificados e praticados de forma intensa. Abordamos 
comandos de criação, inserção, atualização, consulta e exclusão de 
dados em uma base de dados MySQL. 
Manipulamos bases de dados diretamente do sistema gerenciador 
de banco de dados MariaDB. Criamos e manipulamos a base 
Controle_de_Vendas e suas 
tabelas Clientes, Produtos, Fornecedor e Vendas, com variedades 
37 
 
de tipos de campos, onde se pôde gerenciar dados de diferentes 
formas, com grande variedade de comandos SQL. 
Além dos comandos elementares e essenciais, foi possível abordar 
questões mais sofisticadas ao avançar e estabelecer restrições 
maiores ao manuseio do banco de dados. Abordamos elementos 
importantes, como criação e manipulação de dados com views, 
criação de sequências e índices. 
No tópico sobre tecnologias emergentes para bancos de dados, 
apresentaram-se tendências e conceitos de banco de dados não 
relacionais e suas aplicações, assim como do banco de dados 
orientado a objetos e suas aplicações. 
Em segurança em banco de dados, foram abordados aspectos 
importantes, como definição de perfis de usuário e ataques típicos 
em bancos de dados através do SQL injection, apresentando-se 
sugestões de soluções de segurança. 
Podemos concluir que o capítulo trouxe uma abordagem em 
detalhes dos principais comandos SQL e aspectos relevantes no 
universo dos bancos de dados de uma forma geral. 
Esperamos que você tenha aproveitado cada conteúdo abordado, 
testado cada comando e adquirido maior familiaridade com a 
Linguagem SQL.