E-Book Completo - Banco de Dados - DIGITAL PAGES - COMPLETO (Versão Digital) 2

BANCO DE BANCO DE
Banco de Dados
DADOS DADOS
Renato Alves Ferreira Renato Alves Ferreira
Prezado aluno, seja bem-vindo a mais uma etapa do nosso curso! A disciplina de banco
de dados foi cuidadosamente elaborada para tratar de conhecimentos importantes e
relevantes à sua formação. Os bancos de dados impactam nossas vidas e trazem faci-
lidades em praticamente todas as áreas do conhecimento. Ter a possibilidade de obter
informação de forma rápida e confiável é fundamental para o mundo em que vivemos
e os bancos de dados permitem controlar e disponibilizar tais informações, o que os
tornam elementos indispensáveis em uma sociedade moderna.
Em nossa unidade, serão abordados conceitos fundamentais sobre o tema, como: os
tipos de bancos de dados, modelagem de dados e suas estruturas, sistemas gerencia-
dores de banco de dados, ferramentas CASE para modelagem de banco de dados, en-
tre outros. Esperamos que os assuntos e temas abordados nesta disciplina contribuam
enormemente em seu processo de formação e permitam alicerçar o seu crescimento
com uma aprendizagem geradora de resultados e realizações. Vamos ao trabalho?
GRUPO SER EDUCACIONAL
gente criando o futuro
Capa_Banco de dados_A5.indd 1,3 09/09/19 09:52

Presidente do Conselho de Administração Janguiê Diniz
Diretor-presidente Jânyo Diniz
Diretoria Executiva de Ensino Adriano Azevedo
Diretoria Executiva de Serviços Corporativos Joaldo Diniz
Diretoria de Ensino a Distância Enzo Moreira
Autoria Prof. Renato Alves Ferreira
Projeto Gráfico e Capa DP Content
DADOS DO FORNECEDOR
Análise de Qualidade, Edição de Texto, Design Instrucional,
Edição de Arte, Diagramação, Design Gráfico e Revisão.
© Ser Educacional 2019
Rua Treze de Maio, nº 254, Santo Amaro
Recife-PE – CEP 50100-160
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio
ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n. 9.610/98 e punido pelo
artigo 184 do Código Penal.
Imagens de ícones/capa: Shutterstock
Banco de dados - Unidade 1_A5.indd 2 09/09/19 09:53

Boxes
ASSISTA
Indicação de filmes, vídeos ou similares que trazem informações comple-
mentares ou aprofundadas sobre o conteúdo estudado.
CITANDO
Dados essenciais e pertinentes sobre a vida de uma determinada pessoa
relevante para o estudo do conteúdo abordado.
CONTEXTUALIZANDO
Dados que retratam onde e quando aconteceu determinado fato;
demonstra-se a situação histórica do assunto.
CURIOSIDADE
Informação que revela algo desconhecido e interessante sobre o assunto
tratado.
DICA
Um detalhe específico da informação, um breve conselho, um alerta, uma
informação privilegiada sobre o conteúdo trabalhado.
EXEMPLIFICANDO
Informação que retrata de forma objetiva determinado assunto.
EXPLICANDO
Explicação, elucidação sobre uma palavra ou expressão específica da
área de conhecimento trabalhada.

Sumário
Unidade 1 - Conceitos iniciais

Objetivos da unidade ........................................................................................................... 12
Introdução aos bancos de dados ...................................................................................... 13

Conceitos de sistemas de banco de dados .............................................................. 13
Introdução à modelagem de dados................................................................................... 17

Projeto conceitual de banco de dados...................................................................... 18
Modelo Entidade-relacionamento .................................................................................... 21

Conceitos básicos......................................................................................................... 21
Aspectos avançados .................................................................................................... 24
Diagrama Entidade-relacionamento.......................................................................... 27
Sintetizando........................................................................................................................... 39
Referências bibliográficas................................................................................................. 40

Sumário
Unidade 2 - Modelo relacional

Modelo relacional................................................................................................................ 43
Conceitos básicos ........................................................................................................ 43
Restrições de integridade............................................................................................ 47
Esquema relacional de um banco de dados ................................................................... 49

Projeto de implementação de banco de dados ...................................................... 50
Implementação de bancos de dados relacionais.................................................... 53
Sistemas de gerenciamento de banco de dados ........................................................... 59

Arquitetura de sistemas de banco de dados............................................................ 60
Sintetizando........................................................................................................................... 65

Sumário
Unidade 3 - Modelo físico do banco de dados – introdução à Linguagem SQL

Conceitos de Linguagem SQL ............................................................................................ 69

Consultas básicas em Linguagem SQL...................................................................... 76
Restringindo e ordenando dados ...................................................................................... 79

Uso de funções para transformar dados .................................................................. 81
Exibindo dados de várias tabelas............................................................................... 84
Agregando dados com funções de grupo ........................................................................ 89

Usando subconsultas de dados.................................................................................. 92
Sintetizando........................................................................................................................... 95

Sumário
Unidade 4 - Implantação de bancos de dados relacionais

Inserindo, eliminando e alterando dados........................................................................ 99

Criando e manipulando tabelas .................................................................................. 99
Criação das tabelas .................................................................................................... 104
Inserindo dados nas tabelas ..................................................................................... 105
Copiando dados e gerando nova tabela a partir de uma existente.................... 108
Alterando dados da tabela ........................................................................................ 109
Eliminando dados da tabela ...................................................................................... 110
Alterando a estrutura da tabela................................................................................ 111
Incluindo restrições de dados em tabelas .................................................................... 112

Criando visões de dados............................................................................................ 116
Criando sequências .................................................................................................... 117
Criando índices............................................................................................................ 117
Tecnologias emergentes para bancos de dados.......................................................... 119

Banco de dados não relacional e suas aplicações .............................................. 119
Banco de dados orientado a objetos e suas aplicações ..................................... 120
Segurança em banco de dados ....................................................................................... 121

Definição de perfis de usuário (roles) ..................................................................... 122
Ataques típicos em bancos de dados (SQL injection e outros)........................... 123
Soluções de segurança para bancos de dados .................................................... 124
Sintetizando......................................................................................................................... 125
Referências bibliográficas............................................................................................... 126

BANCO DE DADOS 8

Apresentação
Prezado aluno, seja bem-vindo a mais uma etapa do nosso curso! A dis-
ciplina de banco de dados foi cuidadosamente elaborada para tratar de co-
nhecimentos importantes e relevantes à sua formação. Os bancos de dados
impactam nossas vidas e trazem facilidades em praticamente todas as áreas
do conhecimento. Ter a possibilidade de obter informação de forma rápida e
confiável é fundamental para o mundo em que vivemos e os bancos de dados
permitem controlar e disponibilizar tais informações, o que os tornam elemen-
tos indispensáveis em uma sociedade moderna.
Em nossa unidade, serão abordados conceitos fundamentais sobre o tema,
como: os tipos de bancos de dados, modelagem de dados e suas estruturas,
sistemas gerenciadores de banco de dados, ferramentas CASE para modela-
gem de banco de dados, entre outros. Esperamos que os assuntos e temas
abordados nesta disciplina contribuam enormemente em seu processo de for-
mação e permitam alicerçar o seu crescimento com uma aprendizagem gera-
dora de resultados e realizações. Vamos ao trabalho?
BANCO DE DADOS 9

O autor
O professor Renato Alves Ferreira

é mestre em informática e gestão do
conhecimento pela Uninove (2017). É
especialista em sistema de informação
com ênfase em tecnologia da infor-
mação pelo Centro Universitário Eniac
(2005). Graduado em pedagogia plena
com habilitação em administração es-
colar pela Unoeste (1995), também é
técnico em processamento de dados
pelo Eniac (1988).
Currículo Lattes:
http://lattes.cnpq.br/4524836424246846
A Deus, que me capacita a cada dia, aos meus pais, meu porto seguro, aos
meus filhos, razão da minha existência.
BANCO DE DADOS 10

UNIDADE
1 CONCEITOS
INICIAIS

Objetivos da unidade
Apresentar as estruturas de banco de dados comerciais;
Modelar banco de dados relacionais.
Tópicos de estudo
Introdução aos bancos de
dados
Conceitos de sistemas de
banco de dados
Introdução à modelagem de
dados
Projeto conceitual de banco
de dados
Modelo Entidade-relaciona-
mento
Conceitos básicos
Aspectos avançados
Diagrama Entidade-relaciona-
mento
BANCO DE DADOS 12

Introdução aos bancos de dados
Abordaremos conteúdos básicos e elementos fundamentais no universo
dos bancos de dados. Serão apresentados conceitos, estruturas, aplicações,
tipos de sistemas gerenciadores de bancos de dados e modelagens de dados;
inclusive, iniciaremos os estudos sobre desenvolvimento de Diagramas Entida-
des-relacionamentos.
Conceitos de sistemas de banco de dados

Talvez você já tenha se pergunta-
do em algum momento o porquê do
nome banco de dados, sendo que
a tradução mais literal dos famosos
Data Base seria o equivale a bases de
dados – que também é utilizada, mas
não com a mesma predileção. A pa-
lavra “banco” é empregada em várias
áreas, como nos bancos de sangue ou
de órgãos na área da saúde, no banco
das agências financeiras ou banco de questões de uma disciplina.
Podemos então, a princípio, definir banco como o agrupamento de elemen-
tos de mesma natureza ou de um mesmo segmento, não é? Mas, com o foco
em nossa disciplina, podemos encontrar uma definição mais apropriada para
banco de dados.
O nome banco de dados é atribuído a um conjunto de dados agrupados
em uma estrutura regular que permite o acesso de maneira organizada e
normalmente mantido por um sistema computacional que o gerencie.
CITANDO
“Então, o que é exatamente um sistema de banco de dados? Basicamente
nada mais é do que um sistema de armazenamento de dados baseado em
computador, isto é, um sistema cujo objetivo global é registrar e manter
informação” (DATE, 2003, p. 26).
BANCO DE DADOS 13

Esses sistemas de gerenciamento de banco de dados são conhecidos pela
sigla SGBD e são os responsáveis por armazenar, manter e prover acesso de ma-
neira controlada e segura à sua base de dados. Para tanto antes, é necessário
que os bancos de dados sejam projetados segundo uma estrutura clara e bem
definida, em um modelo teórico, chamado modelo conceitual. Posteriormente,
por intermédio dos SGBD, conseguimos transformar todo esse modelo concei-
tual em um modelo físico e real com toda a estrutura anteriormente projetada.
A Fig. 1 ilustra o processo de modelagem de um modelo conceitual de banco
de dados.
Figura 1. Modelagem de banco de dados. Fonte: Shutterstock. Acesso em: 25 fev. 2019.
Os SGBDs, como já definido antes, são os responsáveis pelo gerenciamen-

to dos bancos de dados. São compostos de um conjunto de softwares que
realizam essa tarefa e muitas vezes são confundidos e chamados também de
bancos de dados.
Então, para não restar dúvidas, o banco de dados é a base de dados, o agru-
pamento de dados de mesma natureza que ficam armazenados e gerenciados
por intermédio dos sistemas gerenciadores de banco de dados.
Pode fazer uma analogia com a vida real: em um escritório, podem existir
várias gavetas e armários com documentos separados em pastas, fichas ou até
mesmo uma simples agenda. A organização dessas informações é que faz toda
a diferença quando pensamos em banco de dados. A Fig. 2 ilustra um banco de
dados no mundo real, com uma gaveta com pastas de documentos organizados.
BANCO DE DADOS 14

Enquanto isso, os SGBDs, em nossa analogia, seriam os profissionais res-
ponsáveis em manter e manipular os documentos dessa gaveta no mundo real.
Figura 2. Exemplo de banco de dados no mundo real. Fonte: Shutterstock. Acesso em: 24 fev. 2019.
A estrutura regular e simplificada de um banco de dados pode facilmente

ser comparada a uma simples tabela ou lista, que organiza as informações de
mesma natureza, como pode ser visto na Tabela 1.
QUADRO 1. COMPETÊNCIAS PARA O PROFISSIONAL
Produto
Código Nome Valor Quantidade
100020 KL-77 230,00 2
200030 SL-23 150,00 53
200035 SL-91 435,00 30
500040 JS-10 890,00 1
Analisando a Tabela 1, é perceptível que está dividida colunas. Essas colunas

são os as divisões ou campos que agruparão os dados separadamente. Em um
sistema de banco de dados computacional, essa tabela recebe o nome de en-
tidade, muito embora que o nome tabela também seja bem praticado. Já suas
colunas são os atributos da entidade, também conhecidos como campos.
Os dados propriamente ditos estão nas linhas, onde aparecem as caracte-
rísticas de cada produto. Essas linhas com dados sãs chamadas de instâncias
BANCO DE DADOS 15

da entidade, conhecidas também por tuplas ou registros, que é o nome mais
popularmente conhecido.
Existem dezenas de sistemas gerenciadores de banco de dados em todo o
mundo. Uma lista mais completa pode ser consultada no portal especializado
no portal Db-Engines. Alguns dos principais SGBDs utilizados no mundo são:
• Oracle, da empresa Oracle Corporation, de mesmo nome;
• MySQL, criado pela Sun Microsystem, e posteriormente adquirida pela
Oracle;
• MS SQL Server, da empresa Microsoft;
• PostgreSQ, software livre e não proprietário de código aberto;
• MongoDB, da empresa MongoDB Inc. e de código aberto;
• IBM DB2, criado pela IBM;
• SQLite, software livre e não proprietário de código aberto.
Dados x informação x conhecimento
Antes de avançarmos para o próximo tópico, é necessária uma reflexão so-
bre três elementos instigantes repercutidos no universo de qualquer banco de
dados: o dado, a informação e o conhecimento. Muitas vezes, em textos lite-
rais e no dia a dia, são tratados ou confundidos como sinônimos. Dependendo
do contexto, isso realmente pode ocorrer, mas cada um possui características
bem definidas quando fazemos uma análise mais crítica desses elementos.
E você, o que acha? Poderia facilmente identificar e conceituar cada um de-
les? Vamos tentar? Imagine a seguinte situação: seu professor pede para você
olhar o que está escrito no quadro negro. Ao ler, você repara que há apenas a
letra O. Você diria se tratar de um dado, uma informação ou um conhecimento?
Poderia ser qualquer um deles, não é mesmo? Nesse caso específico, para
ter certeza de qual elemento se trata, devemos realizar algumas ponderações.
A letra O vista no quadro negro representou algo a você? Trouxe alguma infor-
mação ou conhecimento por si só? Se a resposta é não, então a letra O nesse caso
é apenas um dado, sem contexto, mas é um dado. Podemos até classificá-lo como
um simples dado do tipo alfabético ou caractere.
Agora, imagine se seu professor tivesse dito que, ao ler o quadro negro,
você encontraria o nome de um grupo sanguíneo. Dessa vez, a letra O passou
a ser um elemento importante, que é o nome de um grupo sanguíneo. Isso é
uma informação suficiente e completa em si só.
BANCO DE DADOS 16

Mas e se o professor dissesse a você que no quadro negro estaria um grupo
sanguíneo que, juntamente com o grupo sanguíneo tipo A, quase 90% da população
brasileira é pertencente a esses dois grupos. Podemos dizer agora que a letra O,
junto com a quantidade de informações fornecidas anteriormente, produziu conhe-
cimento sobre um fato. Isso quer dizer que, sendo bem contextualizado ou relacio-
nado, um único dado poderá trazer consigo informação e conhecimentos.
O segredo está nesse vínculo de um dado com o seu contexto. O número
49 isoladamente escrito em uma lousa nada quer dizer, mas se acrescentar um
elemento rótulo, uma legenda ou uma descrição a esse número, poderá fazer
muito sentido. Exemplo:
- Ano de nascimento: 49
- Peso: 49
- Minutos para o fim da prova: 49
- Idade: 49
Em um banco de dados, esses elementos são chamados de atributos. Te-
mos, no último exemplo, os atributos ano, peso, minutos e idade, sendo que,
para todos os casos, o dado em si é o fator mais importante e que consome vo-
lume de armazenamento, ou seja, utiliza espaço no banco de dados. O nome dos
atributos são meras legendas, mas dão significância aos dados.
EXPLICANDO
O conhecimento é constituído por intermédio de informações que adqui-
rimos e toda informação é constituída por dados. Logo, temos uma hierar-
quia muito bem definida e estabelecida. Para que um sistema de banco de
dados se justifique e seja eficiente, não pode ser apenas um depósito de
dados. Precisa fornecer informações que gerem conhecimentos que satis-
façam as necessidades das organizações que os utilizam e os mantêm.
Introdução à modelagem de dados

Até este ponto, você já deve ter tido uma visão bem superficial sobre o que
são os bancos de dados. Mas como esses bancos de dados são criados? Quais
as primeiras etapas que devemos seguir para implementarmos um eficiente
e poderoso banco de dados? Qual SGBD devemos adotar? Será que todos são
iguais? Questões como essas só podem ser respondidas no momento em que
BANCO DE DADOS 17

nos aprofundamos mais nos assuntos que os cercam e é isso que faremos a
partir desse tópico. Vamos lá?
A primeira etapa de um projeto que envolva banco de dados é a modela-
gem de dados, tendo como principal objetivo o desenvolvimento de um mode-
lo que ajude a organizar a forma de raciocínio e conhecimento sobre os dados,
demonstrando o significado e a aplicação prática de cada elemento envolvido.
Na visão de Muller (2002), a modelagem de dados também estabelece o víncu-
lo entre as necessidades do usuário e a solução de software que as atende,
fazendo com que se tenha uma redução da complexidade do projeto a um pon-
to que o projetista possa compreender e manipular os dados.
Modelar os dados significa planejar e conceituar como será a estrutura e
a organização destes dados no banco que será criado, portanto, essa atividade
antecede a criação física do banco de dados.
É necessário ter conhecimento detalhado sobre o que se quer modelar;
para tanto, isso só deve ocorrer após a análise de requisitos prevista no pro-
cesso de engenharia de software. Logo, se faz necessário adquirir conheci-
mentos do negócio e estrutura da empresa ou organização que usufruirá do
banco de dados a ser implementado. A modelagem de dados é uma técnica
usada para especificar as regras de negócios e a estrutura de dados de um
banco de dados.
Modelagem de dados envolve ações teóricas e práticas, visando construir
um modelo de dados consistente, não redundante e podendo ser aplicado em
qualquer SGBD moderno.
Projeto conceitual de banco de dados

O projeto conceitual de um banco de dados é uma fase muito importante
no planejamento. As metodologias de projeto de bancos de dados estão forte-
mente relacionadas com as diretrizes da engenharia de software, no entan-
to, a modelagem conceitual está realizada no nível mais alto e elementar que
permite envolver o cliente, pois seu foco é discutir os aspectos do negócio do
cliente e não das tecnologias envolvidas. Os exemplos de modelagem de dados
vistos pelo modelo conceitual são mais fáceis de compreender, já que não há
limitações, especificação ou aplicação de tecnologia específica.
BANCO DE DADOS 18

Abstração
Há um conceito em modelagem de dados que diz respeito à possibilidade
de se criar uma visão abstrata de dados para aos usuários. Tal abstração de
dados diz respeito à ocultação de detalhes mais técnicos da estrutura e do ar-
mazenamento, dando destaque apenas aos recursos essenciais para melhor
entendimento desses dados, ou seja, é possível descrever um banco de dados
sem se preocupar com as especificidades e detalhes de software ou de hardware
que o suportarão.
Essa visão pode ser dividida em níveis de abstração: um nível mais elevado
para a visão do usuário, outro com uma visão intermediária mais voltada para
a implementação e outra com uma visão para o nível físico, com menor de
abstração.
Seguindo essa linha, um projeto de banco de dados pode ser estruturado
de uma forma hierárquica conhecida como modelos de dados. Para Elmasri
e Navathe (2011), modelos de dados podem ser usados para descrever a es-
trutura de um banco de dados, sendo classificados em três modelos distintos:
conceitual, lógico e físico, que serão apresentados a seguir.
Modelo conceitual
Modelo de dados de alto nível ou projeto conceitual. É o modelo mais pró-
ximo do cliente e usuário final. Os elementos entidades, atributos e relaciona-
mentos são alguns dos itens definidos nesta fase. Um exemplo deste modelo é
o chamado Modelo Entidade-relacionamento, conhecido como MER. Assim
sendo, o MER é apenas um modelo conceitual, mas possui um diagrama concei-
tual, uma ferramenta chamada DER (Diagrama Entidade-relacionamento),
que permite a representação gráfica do modelo conceitual.
Modelo lógico
Modelo de dados representativo, de implementação ou projeto lógico.
Os dados são mostrados usando estrutura de registro. Os modelos de dados
relacional, hierárquico e de rede são exemplos deste modelo. O modelo ló-
gico é implementado com detalhes mais técnicos, levando em conta algumas
limitações e utiliza recursos como nomenclaturas e adequação de padrão. Nes-
sa fase, há a preocupação com itens do tipo, atributos do tipo chave, normaliza-
ção, integridade referencial, entre outras. O modelo lógico é criado baseado na
modelagem de dados criada no processo anterior, ou seja, modelo conceitual.
BANCO DE DADOS 19

Modelo físico
Modelo de dados de baixo nível ou projeto físico. Descreve os dados do
modelo anterior para armazenamento no computador, abrangendo o formato
dos registros e os caminhos de acesso aos dados. No modelo físico, realizamos
a modelagem física do modelo de banco de dados, sendo assim, levamos em
conta as limitações impostas pelo SGBD escolhido. Usamos uma sequência de
comandos executados em linguagem SQL (Structured Query Language), para a
criação dos artefatos do banco de dados, por exemplo, criarmos tabelas, es-
truturas, ligações e finalmente a criação do banco de dados. O modelo físico
é criado baseado na modelagem de dados criada no processo anterior, ou seja,
modelo lógico.
O Diagrama 1 ilustra a hierarquia desses modelos para a modelagem de dados.
Perceba que a modelagem é realizada após a análise de requisitos, que é uma im-
portante fase que faz parte do processo de desenvolvimento, previsto na engenha-
ria de software. Assim sendo, todas as informações necessárias referentes às regras
de negócio e necessidades do cliente ou usuário já foram devidamente colhidas e
assimiladas, então o processo de modelagem está pronto para ser iniciado.
Caro aluno, no tópico a seguir e durante toda nossa disciplina, esses assuntos
serão detalhados, exemplificados e exercitados. Abordaremos também outros
conceitos necessários para iniciarmos uma trajetória geradora de resultados po-
sitivos no universo dos bancos de dados. Anime-se: o melhor vai começar!
DIAGRAMA 1. COMPETÊNCIAS INDIVIDUAIS BÁSICAS
Projeto Projeto
Análise de conceitual físico Base de
requisitos dados
Projeto
lógico
BANCO DE DADOS 20

Modelo Entidade-relacionamento
O Modelo Entidade-relacionamento, conhecido como MER ou ER, é um mo-
delo de dados conceitual de alto nível. Conforme já abordado anteriormente,
seus conceitos foram definidos para serem os mais compreensíveis possível ao
usuário comum. Essa é uma fase muito importante no desenvolvimento de um
projeto de banco de dados. Foi idealizado por Peter Chen em 1976 e ainda é
muito utilizado, tendo sofrido ajustes bem sutis, mas permanecendo ainda a sua
essência. Peter Pin-Shan Chen é professor americano de ciência da computação,
conhecido como criador do Modelo Entidade-relacionamento (CHEN, 1990).
As vantagens da utilização do MER são muitas:
• Possui uma sintaxe robusta, permitindo a criação da documentação das
informações do cliente de maneira precisa e clara;
• Facilita a comunicação, permitindo que o cliente e o usuário entendam o modelo;
• Facilidade para criar e manter o modelo;
• Pode ser integrado com várias aplicações e projetos diferentes;
• Oferece independência de implementação, pois sua utilização é universal
e não está vinculada a um tipo de banco de dados.
Conceitos básicos
Os conceitos fundamentais do Modelo Entidade-relacionamento estão cal-
cados nos preceitos de entidades, relacionamentos e atributos. A seguir, ve-
jamos separadamente cada um deles.
Entidades
Em um de banco de dados, podemos ter uma ou várias entidades. As en-
tidades são artefatos ou objetos que organizam as informações que serão
armazenadas e manipuladas em um banco de dados. Elas devem possuir ca-
racterísticas muito bem estabelecidas e definidas.
Para Silberschatz, Korth e Sudarshan (1999) uma entidade é uma “coisa” ou um
“objeto” do mundo real que pode ser identificada de forma unívoca em relação a to-
dos os outros objetos. Deve possuir identificação distinta e com um significado pró-
prio. Também são descritas como objetos da realidade na qual se deseja manter infor-
mações. Normalmente é representado por um substantivo na descrição do negócio.
BANCO DE DADOS 21

Normalmente, uma entidade é também entendida como uma lista ou tabe-
la que receberá registros sobre um determinado assunto. Como uma tabela
de jogos de um campeonato ou uma lista de clientes com seus dados pessoais
e dos produtos comprados. O Diagrama 2 ilustra como as entidades podem ser
representadas para compor a documentação e a estrutura de um projeto de
banco de dados. Basicamente, cada entidade deverá ocupar um retângulo com
um nome que a descreve ao centro.
DIAGRAMA 2. EXEMPLO DE REPRESENTAÇÃO DE ENTIDADES
Produto Animal Cliente Pagamento Aluno Compra
Perceba que a nomenclatura usada para cada entidade normalmente é um

substantivo. A entidade com o nome COMPRA é um substantivo, não um ver-
bo: “você realiza a compra e eu a venda”. Aqui, no caso, não é a flexão do verbo
comprar na terceira pessoa do singular e, sim, um substantivo feminino.
Atributos
As entidades são formadas por atributos. Os atributos definem as caracte-
rísticas das entidades, ou seja, os atributos não apenas caracterizam as enti-
dades, mas as constituem em sua essência. Existem diferentes tipos de atri-
butos dependendo da natureza do campo e da necessidade planejada para a
entidade. O Diagrama 3 ilustra a representação gráfica da entidade ALUNOS
com seus atributos RA, nome, sexo, curso e endereço, que por sua vez é com-
posto pelos atributos rua, número e cidade.
DIAGRAMA 3. EXEMPLO DE REPRESENTAÇÃO DE ATRIBUTOS
Nome Sexo Endereço

Rua Número
Aluno Curso
RA Cidade
BANCO DE DADOS 22

Outra forma de representação visual das entidades e seus atributos pode
ser vista no Diagrama 4. Nesse formato, deve-se colocar o nome da entidade
na parte superior do retângulo, seguido de uma linha para separar os nomes
dos atributos que devem ser descritos em seguida.
DIAGRAMA 4. REPRESENTAÇÃO ALTERNATIVA DE ENTIDADES E ATRIBUTOS
Cliente Produto
Razão Código Descrição

social CNPJ Atributo
Entidade Telefone Valor Entidade

Endereço
cliente unitário produto Unidade
Última Cd. Fornecedor

compra
Agora que você já sabe o que são entidades e atributos, o que acha de rea-
lizar uma atividade simples a respeito desses dois elementos da modelagem
de banco de dados? Em uma folha de papel, idealize quais entidade seriam
necessárias para uma biblioteca de uma escola e quais atributos mínimos cada
entidade precisaria. Ok? Vamos lá!
Relacionamento
Quando a entidade possui elos com uma ou várias entidades, chamamos
esses elos de relacionamento. Esse relacionamento é realizado entre atributos
coirmãos das diferentes entidades, desde que tais atributos sejam de mesma
natureza e contexto; dessa forma, criamos uma relação entre as entidades.
Esse é o conceito de relacionamento.
Há também a possibilidade de um auto-relacionamento, quando uma en-
tidade está associada a um ou mais elemento da mesma entidade. Outro item
importante no relacionamento são as cardinalidades envolvidas nessa relação.
O Diagrama 5 ilustra a relação de uma entidade Médico com a entidade Pa-
cientes, sendo que o nome da relação é consulta. O assunto relacionamento
será tratado com mais detalhes no tópico Diagrama Entidade-relacionamento.
BANCO DE DADOS 23

DIAGRAMA 5. EXEMPLO DE RELACIONAMENTO
(1, 1) (0, n)
Consulta
Médico Paciente
Perceba que a nomenclatura usada para definir o relacionamento normal-

mente é um verbo. Aqui, no caso, flexão do verbo consultar na terceira pessoa
do singular, não como um substantivo feminino. Ele “consulta” o médico e eu
consulto o médico.
Aspectos avançados
Em modelagem de banco de dados, existem muitos detalhes e recursos que
precisam ser descritos aos poucos. Não se deve tentar em um único diagrama
resolver todos os problemas. Devemos criar diagramas mais genéricos sem
tantos detalhes inicialmente e aumentar o nível de detalhe na medida em que
a necessidade exige.
As entidades, os atributos e relacionamentos possuem recursos mais téc-
nicos e avançados que também introduziremos aos poucos. No momento em
que esses recursos se façam necessários e indispensáveis, serão abordados e
exemplificados para serem aplicados. As variações dos atributos e as cardinali-
dades dos relacionamentos serão descritos a seguir.
Tipos de atributos
Existem vários tipos de atributos com características diferentes que podem
formar uma entidade. Vejamos cada um deles.
• Atributos simples: atributos não divisíveis são chamados simples ou atô-
micos. Exemplos: nome, sexo, preço, CPF;
• Atributos compostos: podem ser divididos em partes com significados
independentes, como um endereço, que poderá ser composto pelos atributos
rua, cidade, Estado e CEP. Atributos compostos podem formar uma hierarquia;
BANCO DE DADOS 24

• Atributos univalorados ou monovalorados: quando o atributo pode re-
ceber apenas um único valor. Tais atributos são chamados atributos simples
ou univalorados. Exemplos: data de nascimento, tipo sanguíneo, cor da pele;
• Atributos multivalorados: podem receber um conjunto de valores, ou seja,
pode haver mais de um dado a armazenar. Exemplos: telefone, e-mail, nomes dos
dependentes, opção de cursos;
• Atributos determinantes: recebem valores exclusivos que possibilitam a
identificação inequívoca de um registro da entidade. Exemplo: RA, número de
matrícula, código do produto, CNPJ, RG, CPF. Alguns desses atributos podem
ser definidos como um atributo chave da entidade, que será explicado mais
adiante, mas saiba que nem todo atributo determinante necessariamente será
um atributo chave;
• Atributos derivados e armazenados: o valor pode ser encontrado ou
calculado relacionando dois ou mais valores de atributos ou de referên-
cia. Exemplo: a idade de uma pessoa pode ser determinada pela data de
nascimento registrada em outro atributo, um atributo armazenado, com a
data atual que não precisa estar armazenada no banco de dados. O atribu-
to que armazenará a idade da pessoa é um atributo derivado. Isso quer
dizer que não necessariamente um atributo derivado precise ficar alojado
no banco de dados ocupando espaço, sendo que, quando necessário, pode
ser encontrado ou calculado.
Outra situação para sua reflexão: como proceder para descobrir o número de
dias que um cliente está em atraso com seus vencimentos? Quais seriam os atribu-
tos ou de referência envolvidos?
• Atributos chave ou identificador: um tipo especial, também chamado
de identificador, pois garante a unicidade dos dados em uma entidade. Isso
quer dizer que, se determinado valor foi inserido em um campo do tipo chave,
o mesmo valor não poderá ser aceito novamente em outro registro. Exemplo:
sendo o CPF um atributo chave, não haverá outro registro sendo inserido na
entidade com o mesmo CPF.
EXPLICANDO
Todo campo chave é também um atributo determinante, mas nem todo
atributo determinante precisará ser um atributo chave.
BANCO DE DADOS 25

Existem vários tipos de chaves para as entidades. Veja:
• Chave primária: seu valor identifica cada registro de forma única;
• Chave composta: é formada por mais de um atributo;
• Chave candidata: é o atributo com possibilidade de vir a se tornar uma
chave primária;
• Chave estrangeira: quando o atributo de uma entidade é a chave primá-
ria de outra entidade com a qual ela se relaciona.
Cardinalidade
Em um relacionamento, a cardinalidade se refere ao grau do vínculo que uma
entidade mantém com outra entidade, também chamado de domínio. Vejamos
o Diagrama 6. Perceba que a relação entre as entidades são as seguintes:
• A entidade médico poderá ter no mínimo 0 e no máximo n pacientes em
consulta. Já a entidade paciente poderá passar em consulta com no mínimo 1
médico e no máximo 1;
• A leitura da cardinalidade é feita de maneira cruzada, ou seja, a cardinali-
dade próxima à entidade da esquerda é referente à relação com a entidade da
direita e vice-versa;
• Essa notação poderia ser simplificada para 1 do lado do médico e n do lado
do paciente, ou seja, o paciente passa por consulta com apenas 1 médico, já o
médico pode ter n pacientes (inclusive nenhum).
• Vejam que essa relação é conhecida na definição das regras do negócio,
durante a análise de requisitos, conforme já exposto anteriormente, aqui na
modelagem apenas se aplica àquilo que já foi levantado.
DIAGRAMA 6. EXEMPLO DE CARDINALIDADE
Cardinalidade
(1, 1) (0, n)
Médico Consulta Paciente
BANCO DE DADOS 26

A aplicação prática dos relacionamentos, cardinalidade e outros detalhes
serão abordados no tópico a seguir.
Diagrama Entidade-relacionamento
Como definido anteriormente, o
Diagrama Entidade-relacionamento,
conhecido como DER, é uma repre-
sentação gráfica de um modelo con-
ceitual. Muitas vezes é tratado como
sinônimo do modelo conceitual, já que
o modelo pode se tornar abstrato de-
mais e dificultaria muito o processo
de desenvolvimento geral do sistema.
Dessa forma, quando se está definin-
do o modelo conceitual, o mais prático, muitas vezes, é já ir criando a repre-
sentação gráfica do modelo, ou seja, o DER. O diagrama facilita muito a comu-
nicação entre os envolvidos na equipe de desenvolvimento, pois oferece uma
linguagem comum utilizada tanto pelo analista, responsável por levantar os
requisitos e regras de negócio, os desenvolvedores, responsáveis por imple-
mentar aquilo que foi modelado e até mesmo o cliente e usuário final.
No DER, originalmente, no modelo proposto por Chen (1990), as entidades
são representadas por retângulos, seus atributos por elipses e os relaciona-
mentos por losangos, ligados por linhas e contendo também uma marcação de
cardinalidade (Diagrama 7).
Um formato mais moderno e usual propôs a troca das elipses que repre-
sentam os atributos e passaram a utilizar o formato utilizado na UML (Unified
Modeling Language, “linguagem unificada de modelagem”), em que os atributos
são descritos dentro da própria entidade, fazendo com que o diagrama seja
mais legível e fácil de ser entendido (Diagrama 8). Esse formato também se
aproxima mais do modelo lógico, que será visto posteriormente.
Vale ressaltar que nem sempre será necessário construir Diagramas de En-
tidades-relacionamentos com todos os atributos. Muitas vezes bastam apenas
as entidades e a indicação de relacionamentos sem nenhum atributo.
BANCO DE DADOS 27

DIAGRAMA 7. EXEMPLO DO DER PROPOSTO POR CHEN
Modelo Nome
Marca CPF Fone
Veículos Aluga Cliente
Chassi
DIAGRAMA 8. EXEMPLO ALTERNATIVO DO DER
Veículos Aluga Cliente
Marca CPF
Modelo Nome
Chassi Telefone
Cor Endereço
Ano Data
Última
Km locação
Tais diagramas foram idealizados com simbologias simples com objetivo de

serem criados inclusive à mão ou com o mínimo de recursos de softwares, mas
existem ferramentas CASE (Computer-Aided Software Engineering, “engenharia
de software assistida por computador”), que, entre outras coisas, permitem-
-nos criar o DER e outros diagramas sem muito esforço. É possível, inclusive,
gerar o modelo lógico a partir do modelo conceitual do DER e até mesmo o
modelo físico.
BANCO DE DADOS 28

Segue uma lista de algumas dessas ferramentas. Existem ferramentas on-
line que não necessitam de instalação, como é caso da Draw.io e o Lucidchart:
• brModelo: versão gratuita de código livre;
• Astah: a versão completa é paga;
• MySQL Workbench: solução completa e gratuita;
• DBDesigner 4: solução paga. Requer registro on-line;
• Draw.io: solução on-line e gratuita;
• MS Visio: solução paga. Versão acadêmica gratuita;
• Lucidchart: solução on-line e gratuita.
Na produção dos diagramas aqui em nossos exemplos, vamos optar pela
ferramenta brModelo (2019) para confeccionarmos o DER, por ser muito sim-
ples de usar e instalar. É uma ferramenta gratuita de código aberto, além de
ser uma solução brasileira. Para fazer as atividades previstas da disciplina, você
poderá escolher essa ou alguma outra se desejar. No site do desenvolvedor, já
mencionado, você terá instruções sobre a instalação e utilização, mas também
existem vários vídeos postados na internet mostrando a instalação e uso da
ferramenta. No entanto, faremos um passo a passo para sua instalação e utili-
zação inicial. É muito simples.
Passos para instalação da ferramenta brModelo
• Primeiro: baixe o brModelo direto do site do desenvolvedor. A Fig. 3 mos-
tra onde acessar o link para iniciar o processo de download;
Figura 3. Print de tela da ferramenta CASE para modelagem.
BANCO DE DADOS 29

• Segundo: escolha um lugar em seu computador para armazenar o arquivo
brModelo.jar. Ele é um arquivo executável e não necessita de descompactação
ou instalação;
• Terceiro: abra o arquivo brModelo.jar simplesmente dando um clique
duplo. Se necessário, será solicitado a você uma atualização do ambiente
Java, mas isso é uma tarefa comum e provavelmente seu computador já
esteja atualizado;
• Quarto: a tela do brModelo será aberta em poucos segundos (Fig. 4). Re-
pare que aproveitamos a imagem para adicionarmos algumas legendas para
explicações sobre a ferramenta. O processo todo não foi bem simples?
Ferramentas e menu
Barra de artefatos
Janelas de propriedades
e outros
Painel de criação
Figura 4. Print de tela da ferramenta brModelo.
Detalhando um pouco a ferramenta

Agora que temos nossa ferramenta CASE brModelo de modelagem de da-
dos instalada, vamos conhecer um pouco sobre seus recursos para podermos
criar nossos diagramas, ok?
Vejamos então as principais partes do editor de modelagem brModelo.
Ferramentas e menu: nessa área, entre outras coisas, você poderá salvar e abrir
seus modelos criados ou gerar o modelo lógico a partir do seu DER criado (Fig. 5);
BANCO DE DADOS 30

Figura 5. Print de tela da barra de ferramentas do brModelo.
Painel de criação: é área livre onde você poderá trazer seus objetos para
construção do diagrama;
Barra de artefatos: nessa barra, você encontra todos os objetos para cons-
trução do seu diagrama. Basta clicar sobre eles e em seguida clicar em alguma
área do painel de construção (Fig. 6). Perceba que a figura está na horizontal
apenas para melhor apresentação e explicação.
Figura 6. Print de tela da barra de artefatos do brModelo.
Cada um desses objetos da barra de artefatos será usado para a composi-

ção dos diagramas. Para adicioná-los ao painel de criação, basta selecioná-los
com um clique e depois clicar no local desejado para inseri-lo. Não clique e
arraste, ou seja, não é drag-and-drop. Para mudar seus atributos, como nome e
outros, use a janela de propriedades.
Janela de propriedade e outros: chamada de barra Inspector, é o local que
sempre trará informação a respeito do objeto selecionado, em foco, que você está
manipulando (Fig. 7). Dependendo do objeto, você poderá atribuir nomes aos ob-
jetos, cor, tipos e tamanhos de letras. No momento que você muda o foco, ou seja,
clica em outro objeto, a janela traz as propriedades deste objeto.
O brModelo é um editor gráfico de modelagem, portanto, sempre que um
objeto é inserido para a área de diagramação, ele já sugere o tamanho ideal
para cada objeto. Para uma manter uma melhor organização e leitura, é acon-
selhável evitar que objetos fiquem de tamanho diferentes desnecessariamen-
te. Alguns símbolos podem variar um pouco na sua aparência de outras ferra-
mentas, mas não compromete a modelagem geral.
BANCO DE DADOS 31

Dica: Para inserir o rótulo ao
objeto (nome do objeto), utilize
essa propriedade ou a pr priedade.
Texto, quando o objeto for de
outro tipo.
Figura 7. Print de tela da janela de propriedades do brModelo.
Simbologia original utilizada na construção do DER

Os símbolos para construção do DER são os mais simples possíveis e podem
ser criados manualmente, conforme proposto por Chen. Na construção dos
diagramas, podem ocorrer pequenas variações de aparência, dependendo da
ferramenta gráfica utilizada.
Seguem os símbolos padrões e suas aplicações:
Entidade primária. Usado para definir as entidades

fortes. São entidades que não dependem de nenhu-
ma outra para existir.
Entidade fraca. Entidades fracas são dependentes de

outras entidades para existir. Não possuem chave pri-
mária.
Entidade associativa. Associam as instâncias de vá-

rios tipos de entidades. Elas contêm atributos volta-
dos especificamente ao relacionamento entre essas
instâncias.
BANCO DE DADOS 32

Relacionamento. Símbolo utilizado que representa o re-
lacionamento associações entre entidades.
Relacionamento fraco. Também chamado de relaciona-

mento de identificação, são relacionamentos entre um
tipo de entidade fraca e seu proprietário, ou seja, uma en-
tidade primária.
Atributo. Atributos definem as características das enti-

dades. Em algumas ferramentas CASE ele é uma elipse
ou um círculo pequeno, com o nome do atributo escrito
ao lado, como o caso do brModelo (Fig. 8).
Atributo multivalorado. São atributos capazes de rece-

ber vários valores. Exemplo: um atributo para represen-
tar vários telefones.
Atributo derivado. São atributos onde o valor pode ser

calculado a partir de valores de outros atributos ou va-
lores de referência.
Atributo chave. Seu valor identifica cada registro de

forma única. São atributos ou combinações de atributos
que identificam de modo único apenas uma instância de
uma entidade. Em algumas ferramentas CASE ele é uma
elipse ou um pequeno círculo pintado de preto. Veja a Fig. 8.
Atributo composto. São atributos provenientes de

outro atributo. São divididos em partes com signifi-
cados independentes.
BANCO DE DADOS 33

A Fig. 8 ilustra um exemplo de disposição de um DER simples, porém, com-
pleto, criado na ferramenta brModelo, também para mostrar que a diagrama-
ção por ferramenta CASE pode diferenciar um pouco da simbologia original,
mas a própria ferramenta se encarrega de dar nomes aos objetos quando es-
tão em foco.
Analisando a figura, tente levantar os seguintes elementos presentes no
diagrama:
Quantas entidades estão envolvidas? Quais os atributos de cada entidade?
Há relacionamento? Se houver, qual o nome do relacionamento? Há algum atri-
buto chave ou composto? Perceba que os nomes dos elementos pouco impor-
tam, o que interessa é saber se você consegue diferenciar cada elemento.
Figura 8. Print de tela da disposição do der no brModelo.
Criando nosso primeiro Diagrama Entidade-relacionamento (DER)

Conforme já mencionado anteriormente, modelagem de banco de dados
depende dos requisitos de softwares e necessidades do cliente com as regras
de negócio devidamente levantados. Então vamos propor uma situação para
você montar seu primeiro Diagrama Entidade-relacionamento, ok? Vamos lá.
Você terá que idealizar um DER respeitando as regras de negócio estipula-
das abaixo. Idealize quais seriam as entidades para cada, seus atributos essen-
ciais e relacionamentos. Crie uma primeira versão simplificada e posteriormen-
te uma mais completa.
BANCO DE DADOS 34

Regras de negócio
Primeira situação: há uma relação nos procedimentos de consulta em um
consultório médico que um paciente só possa ser atendido por um médico por
consulta. Já o médico poderá ter diversos pacientes, inclusive nenhum. Faça
um diagrama mais simplificado. Não é necessário detalhar os atributos das en-
tidades.
Segunda situação: em outra situação de relação entre entidades, o pacien-
te poderá se consultar com um ou vários médicos. O médico só será alocado
se for para atender no mínimo um paciente. Apesar de não ser necessário para
representar essa relação, tente criar o DER com atributos de exemplos para
cada entidade, inclusive com atributos simples, chaves e compostos.
Sugestões de soluções
Solução para a primeira situação: o Diagrama 9 ilustra uma possível
solução de diagramação para a primeira situação proposta, apenas com as
entidades e relacionamento com cardinalidade de acordo com a primeira
situação.
Observe que a cardinalidade adotada para a entidade paciente é de 1 para
1, que significa que o paciente poderá ser atendido por apenas um médico,
nem mais nem menos. Já a cardinalidade para a entidade médico, é de 0 para n,
sugerindo que o médico poderá atender desde nenhum até n pacientes. Lem-
brando que a leitura da cardinalidade, para um entendimento mais fácil, é sem-
pre cruzada, ou seja, a cardinalidade ao lado da entidade médico diz respeito à
entidade paciente e vice-versa.
DIAGRAMA 9. POSSÍVEL SOLUÇÃO PARA A SITUAÇÃO 1
(1, n) (1, n)
BANCO DE DADOS 35

Solução para a segunda situação: o Diagrama 10 ilustra uma possível so-
lução de para a segunda situação proposta. Nesse caso, além das entidades,
estão os atributos de cada uma e relacionamento com cardinalidade de acordo
com a segunda situação.
Perceba que os atributos chaves são destacados com uma marcação pin-
tada de preto. Esse é o formato do que seria a elipse na simbologia original. O
atributo convênio é do tipo composto. Os demais são atributos simples.
Observe que para esse caso, a cardinalidade adotada para a entidade pa-
ciente é de 1 para n, significando que o paciente poderá ser atendido por um
médico ou mais médicos. Já a cardinalidade para a entidade médico, é de 1 para
n, sugerindo que o médico poderá atender de um até n pacientes. Lembran-
do que a leitura da cardinalidade, para um entendimento mais fácil, é sempre
cruzada, ou seja, a cardinalidade ao lado da entidade médico diz respeito a
entidade paciente e vice-versa.
DIAGRAMA 10. POSSÍVEL SOLUÇÃO PARA A SITUAÇÃO 2
(1, n) (1, n)
CRM Código
Telefone
Especialidade
Nome Convênios
Nome
Convênio 1 Convênio 2
Vejamos agora outro exemplo de DER.

O exemplo a seguir, Diagrama 11, demonstra de forma simplificada o pro-
cesso de devolução de livros a uma biblioteca.
Analise o diagrama, faça anotações a respeito e depois verifique as explica-
ções são exatamente o que você entendeu, correto?
BANCO DE DADOS 36

DIAGRAMA 11. EXEMPLO DE DEVOLUÇÃO DE LIVROS PARA BIBLIOTECA
Aluno Requisição Livro Sessão
(1, 1) (1, 1) (1, 1) (1, n) (1, n) (1, 1)
Devolve Contém Pertence
Explicando o diagrama: perceba que temos três relacionamentos. Sendo

assim, dividimos a explicação em três itens, a seguir:
1 - Inicialmente vemos a entidade aluno se relacionando com a entidade requi-
sição com a seguinte cardinalidade 1 para 1, ou seja, o aluno só poderá ter uma
única requisição de livros por vez. O nome desse relacionamento é “devolve”.
2- A entidade requisição está relacionada tanto com aluno quanto com a
entidade livro.
A relação dela com a entidade aluno também é de 1 para 1, ou seja, toda
requisição só poderá ter um único aluno a ela vinculada. É isso mesmo que
ocorre no mundo real, não é mesmo? Em seguida, pode-se ver que a entidade
requisição está também relacionada com a entidade livro, em uma cardinali-
dade 1 para n, ou seja, uma requisição poderá ter um ou mais livros. o nome
desse relacionamento é “contém”.
3- A entidade livro está relacionada tanto com a entidade requisição quanto
com a entidade sessão.
A relação dela com a entidade requisição é de 1 para 1, ou seja, um exem-
plar de um livro específico só pode estar em uma requisição e não em várias.
Correto? Exemplo: “esse livro está contido em sua requisição e não em outra”.
Em seguida, vemos que a entidade livro possui uma relação “pertence” com a en-
tidade sessão com uma cardinalidade 1 para 1, ou seja, o livro só pode ficar alojado
em uma única sessão específica.
BANCO DE DADOS 37

Olhando do lado da entidade sessão, analisamos que a cardinalidade é de 1
para n, ou seja, uma sessão, vários livros serão pertencentes a ela. Ok?
Lembrando que a análise da cardinalidade é mais fácil quando observa-
da de maneira cruzada.
BANCO DE DADOS 38

Sintetizando
Caro aluno, neste capítulo, iniciamos os estudos sobre banco de dados.
Foram abordados conceitos básicos sobre o tema de forma geral, que serão
destacados aqui.
Na apresentação do conceito de bancos de dados, vimos tratar-se de uma
organização eficiente dos dados armazenados e suportados por sistemas com-
putacionais, que são os SGBDs, Gerenciadores de Bancos de Dados. Bancos de
dados são como grandes tabelas de dados muito bem projetadas e implemen-
tadas para atender as necessidades do projeto de desenvolvimento de banco
de dados.
Na abordagem sobre modelagem de dados, ficou claro que modelar signi-
fica planejar e conceituar como ficará a estrutura e a organização dos dados
e que essa fase só poderá ocorrer após a finalização da análise de requisitos,
prevista no processo de desenvolvimento da engenharia de software.
Em abstração, vimos os benefícios de tratar a modelagem em níveis diferentes
durante os processos, o nível conceitual, lógico e físico, com a ocultação de deta-
lhes desnecessários para cada nível, para melhor entendimento desses dados por
todos os envolvidos, durante toda a modelagem.
Neste capítulo, foi dado um destaque ao nível conceito do processo de mo-
delagem de banco de dados, abordando o Modelo Entidade-relacionamento, co-
nhecido como MER, e seu Diagrama Entidade-Relacionamento, chamado de DER.
Conclui-se, então, que o capítulo trouxe uma visão geral dos bancos de da-
dos e do processo de modelagem, especificamente na fase do modelo concei-
tual, logo, você já é capaz de iniciar a primeira fase do processo de modelagem
desenvolvendo o projeto conceitual da modelagem de dados.
Esperamos que tenha aproveitado cada conteúdo. Bons estudos!
BANCO DE DADOS 39

Referências bibliográficas
BRMODELO. Modelagem ER. Disponível em: <http://www.sis4.com/brMode-
lo/>. Acesso em: 1 mar. 2019.
CHEN, Peter. Gerenciando banco de dados. A abordagem entidade-relaciona-
mento para projeto lógico. São Paulo: McGraw-Hill, 1990.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Elsevier, 2003.
DB-ENGINES. Knowledge base of relational and nosql database manage-
ment systems. Disponível em: <https://db-engines.com/en/ranking>. Acesso
em: 1 de mar. 2019.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo:
Addison Wesley, 2011.
MULLER, J. R. Projeto de banco de dados - usando uml para modelagem de
dados. São Paulo: Berkeley, 2002.
BANCO DE DADOS 40

UNIDADE
2 MODELO RELACIONAL

Introdução ao modelo relacional;
Projeto de banco de dados até o modelo lógico;
Apresentar a arquitetura de sistemas de bancos de dados.
Tópicos de estudo
Modelo relacional Sistemas de gerenciamento de
Conceitos básicos banco de dados
Restrições de integridade Arquitetura de sistemas de
banco de dados
Esquema relacional de um
banco de dados
Projeto de implementação de
banco de dados
Implementação de bancos de
dados relacionais
BANCO DE DADOS 42

Modelo relacional
Olá alunos! Nesta unidade iremos nos aprofundar em alguns conceitos que
envolvem os bancos de dados relacionais, assim como abordar outros assun-
tos bem relevantes. Preparados? Então, vamos lá!
O modelo relacional é fundamentado na teoria dos conjuntos e lógica
de predicado, que são conceitos matemáticos. Alguns dos primeiros sistemas
comerciais de banco de dados baseados em modelo relacional dos anos 80
foram o Oracle, MySql, Access, entre vários outros (ELMASRI; NAVATHE, 2011).
Enquanto o modelo entidade-relacionamento é voltado para o projeto
conceitual do banco de dados, o modelo relacional está diretamente ligado
ao projeto lógico; assim sendo, essa fase é dependente da conclusão do pro-
jeto conceitual.
Enfatizando, portanto, o modelo ou projeto conceitual é um modelo abs-
trato que descreve a estrutura de um banco de dados independente de um
SGBD. Já o modelo lógico ou projeto lógico é aquele com dados que repre-
sentam a estrutura com foco em um SGBD específico, apesar de ainda não
ser necessária a sua utilização durante essa fase do projeto, mas, sim, na fase
seguinte, no projeto físico.
CITANDO
“A abordagem entidade-relacionamento é voltada à modelagem de dados
de forma independente do SGBD considerado. É adequada para constru-
ção do modelo conceitual. Já a abordagem relacional modela os dados em
nível de SGBD relacional. Um modelo neste nível de abstração é chamado
de modelo lógico.” (HEUSER, 2009, p. 6).
Conceitos básicos
O modelo relacional foi proposto por Edgar Frank Codd, matemático bri-
tânico e pesquisador da IBM, em um artigo acadêmico em 1970. Entre outros
aspectos, Codd propôs representar os dados como uma coleção de relações,
sendo que cada relação fosse representada em formato de tabelas, com colu-
nas e linhas. Ele é considerado o pai do modelo relacional, já que vários siste-
mas gerenciadores de bancos de dados nasceram dessa ideia.
BANCO DE DADOS 43

DICA
Edgard Frank Codd publicou, em 1970, o artigo A relational
model of data for large shared data banks na ACM Ma-
gazine. A partir dessa publicação, o modelo relacional,
inicialmente testado nos laboratórios na IBM, passou a ter
mais credibilidade. O autor, por sua vez, continuou suas
pesquisas sobre o modelo relacional, escrevendo diversos
artigos sobre o tema.
O modelo relacional refere-se a três aspectos principais: aspecto estrutu-

ral, de integridade e de manipulação de dados (DATE, 2003). No aspecto
estrutural, o banco de dados é representado como um conjunto de relações,
similar a uma tabela, com linhas e colunas associadas. As linhas são denomi-
nadas tuplas e em cada coluna são distribuídos os atributos, como se fossem
títulos para as colunas (ELMASRI; NAVATHE, 2011).
Essa associação de linhas e colunas forma então uma relação. Observando
a Tabela 1, nota-se a relação de Matriculados, composta por suas tuplas e seus
atributos distribuídos em colunas. Lembrando que tupla refere-se aos valores
de uma linha inteira da tabela ou um registro da tabela. Pela definição matemá-
tica, tupla é uma se u ncia ordenada e finita de elementos, em que cada um
desses elementos possui um nome identificador e um valor. Diferentemente
do relacionamento exposto no Quadro 1, a Tabela 1 ilustra uma tabela única,
mas poderia ser também o produto resultante entre outras tabelas.
TABELA 1. ATRIBUTOS E TUPLAS DA RELAÇÃO MATRICULADOS
MATRICULADOS
RA Aluno Cod_Curso Nome_Curso
123450001 Bartolomeu Silva 100034 Enfermagem
123450005 Ana Soares 100040 Informática
123450009 Julia dos Santos 100034 Enfermagem
123450033 Beatriz Gomes 100050 Nutrição
Engenharia
123450042 Karoline Sevla 100020
Elétrica
123450043 Lucas Arierref 100040 Informática
123450050 Margaria Alves 100034 Enfermagem
BANCO DE DADOS 44

O conjunto de valores em cada coluna, ou seja, o que cada atributo é capaz
de assumir é chamado de domínio (SILBERSCHATZ; KORTH; SUDARSHAN, 1999).
Assim sendo, pode-se representar o domínio de um atributo por Dn , onde D é
o domínio de um determinado atributo e n a posição do atributo na relação, ou
seja, o número da coluna em que o atributo está alojado. Exemplificando:
Na Tabela 1, pode-se ver o domínio do atributo RA na coluna 1 da relação, por-
tanto, na teoria dos conjuntos, pode ser denotado como D1, já o domínio D2 repre-
senta o atributo Aluno, D3 representa o Cod_Curso e D4 o atributo Nome_Curso. O
Quadro 1 destaca apenas o domínio D1 com a relação de RAs cadastrados.
QUADRO 1. DOMÍNIO DO ATRIBUTO RA REPRESENTADO POR D1 DA TABELA 1
D1
123450001
123450005
123450009
123450033
123450042
123450043
123450050
Ainda na visão dos referidos autores (SILBERSCHATZ; KORTH; SUDARSHAN,

1999), a relação em questão pode ser definida como um subconjunto do pro-
duto cartesiano de uma lista de domínios. Sendo assim, a relação de matri-
culados pode ser denotada por D1 x D2 x D3 x D4, ou seja, matriculados é um
subconjunto do conjunto de todas as combinações possíveis de valores.
Matriculados também pode ser denotado por relação r.
Podemos também denotar tn para representar as tuplas, onde n é o núme-
ro da tupla em evidência, ou seja, t1 para os valores da primeira tupla, t 2 para
a segunda, t 3 para a terceira e assim por diante. Já que uma relação é um con-
junto de tuplas, podemos usar a notação matemática t r para denotar que a
tupla t pertence à relação r.
BANCO DE DADOS 45

De igual modo, as linhas com dados de alunos que formam as tuplas podem
ser denotadas por vn , sendo, v1 para o RA do aluno, v2 para o seu nome, v3 o códi-
go do curso e v4 o nome do curso e um determinado momento ou posição na Ta-
bela 1, como pode ser visto em destaque no Quadro 2, em que o RA 123450042
ocupa a quinta posição da tabela, ou seja, é o quinto registro.
QUADRO 2. VALORES DE UMA TUPLA ESPECÍFICA
V1 V2 V3 V4
T5 123450042 Karoline Sevla 100020 Engenharia Elétrica
O Quadro 3 ilustra uma visão de um relacionamento entre tabelas no mo-

delo lógico. Como um produto desse relacionamento, e dependendo da cardina-
lidade aplicada, pode-se obter uma entidade associativa ou resultante chamada
Matrícula, que pode ser física, formando efetivamente uma nova tabela ou ape-
nas para efeito de visualização, como em um relatório. Outras formas de repre-
sentação do modelo lógico serão apresentadas mais adiante.
É possível verificar que a aluna Ana Soares e o aluno Lucas Arierref estão ma-
triculados no curso de Informática, graças ao relacionamento entre um atributo
em comum nas duas tabelas.
A tabela Aluno possui o atributo Cod_Curso que serve como chave-estran-
geira para relacionar-se com tabela Curso, que, por sua vez, possui um atributo
correspondente, mas implementado como chave-primária.
No caso apresentado, não é necessário que tenham o mesmo nome, mas
devem ser idênticos em tipo e em conteúdo, para que o relacionamento permita
o cruzamento das informações em ambas as tabelas. Perceba que o nome do
aluno é proveniente da tabela Aluno e nome do curso da tabela Curso. É comum
acrescentarmos o nome da tabela, ou parte do nome, à chave-estrangeira.
Exemplo:
Um atributo chamado código de uma tabela Cliente, ao ser referenciado por ou-
tra tabela como chave-estrangeira, tem como nome ideal algo como codigo_Cliente
ou codigo_Cli. Lembrando que as acentuações e alguns caracteres especiais não são
permitidos – e mesmo quando são, devem ser evitados na definição dos nomes de
atributos, na maioria dos bancos de dados e linguagens de programação.
BANCO DE DADOS 46

QUADRO 3. ILUSTRAÇÃO DE RELACIONAMENTOS NO MODELO LÓGICO
ALUNO CURSO
RA Aluno Cod_Curso Cod_Curso Nome_Curso Valor
123450005 Ana Soares 100040 100034 Enfermagem 2500,00
123450033 Beatriz Gomes 100050 100040 Informática 2500,00
123450042 Karoline Sevla 100020 100050 Nutrição 2500,00
123450043 Lucas Arierref 100040 100020 Engenharia 2500,00
123450050 Margaria Alves 100034
RA Cod_Curso Aluno Nome_Curso
123450005 100040 Ana Soares Informática
123450033 100050 Beatriz Gomes Nutrição
123450042 100020 Karoline Sevla Engenharia
123450043 100040 Lucas Arierref Informática
123450050 100034 Margaria Alves Enfermagem
Restrições de integridade
As restrições de integridade servem para garantir a exatidão dos dados em
um banco de dados relacional. Segundo Heuser (2009), as restrições de integri-
dade equivalem a dizer que os dados de um banco estão íntegros, significando
que eles refletem corretamente a realidade representada pelo banco de dados
e que são consistentes entre si.
Há uma variação de tipos de restrições de integridade. Como exemplo, a in-
tegridade de domínio de um atributo que verifica se os dados são do tipo espe-
rado e permitido, como alfanumérico, numérico, data, limites para o tamanho
do campo, se pode ter conteúdo nulo ou não.
Tipos de restrições de integridade
Restrição de chave
Impede que uma chave-primária tenha repetições, garantindo assim a uni-
cidade dos dados no banco de dados.
BANCO DE DADOS 47

Restrição de domínio
Definir o conjunto de valores permitidos ou possíveis que um atributo pode
ter. Também pode haver a integridade de vazios, que verifica se um campo pode
receber um valor nulo (null) ou não.
Integridade referencial
Uma chave-estrangeira de uma relação tem que coincidir com uma chave-
-primária da entidade principal. Nesse caso, o atributo deve ser do mesmo tipo
e existir em ambas as tabelas, assim como o conteúdo idêntico. Por exemplo:
em um relacionamento entre uma entidade Funcionário e Departamento, o
código do departamento em que o funcionário trabalha deverá existir tanto na
tabela de funcionário como na tabela de departamento.
Poderá haver a chamada violação da integridade referencial, quando a cha-
ve-estrangeira não coincide com a chave-primária da entidade principal. O Dia-
grama 1 exemplifica a integridade referencial.
ntegridade definida pelo usuário
A integridade definida pelo usuário permite definir regras próprias e espe-
cíficas voltadas ao negócio e que não se encaixam em outras categorias de
integridade. Pode-se exemplificar restrições como:
• Todo aluno deve estar matriculado obrigatoriamente em um curso.
• Todo dependente deve estar atrelado a um funcionário.
• Todo produto vendido precisa estar associado a um número de pedido.
• Toda nota-fiscal precisa ter no mínimo um item de venda associado a ela.
Por intermédio do relacionamento e da aplicação dos tipos de cardinalidades
envolvidas, conseguimos determinar várias restrições de integridades. É impor-
tante notar que a forma de representar as cardinalidades pode variar de autor
para autor, entre ferramentas CASE ou mesmo por convenção dos envolvidos na
documentação do projeto de banco de dados, como: (1,1), (1,N), (0,1), (0,N), (N,N)
ou (N,M). O M nem sempre é adotado e representa vários, assim como o N.
Há também a possibilidade, em algumas ferramentas CASE, de informar
o número mínimo e o má imo entre os relacionamentos, exemplo: (1,3), que
informa que há um relacionamento de no mínimo e máximo, no caso, mínimo
de 1 e máximo de 3. A vírgula ou o ponto e vírgula indicam a cardinalidade mí-
nima e máxima para uma entidade participante do relacionamento e o ponto e
vírgula separam a cardinalidade de cada entidade relacionada.
BANCO DE DADOS 48

No Diagrama 1, pode-se dizer que o relacionamento entre as entidades A e B
se dá por (1,1 : 0,N), em que A pode se relacionar com B, com nenhuma ou até
N instâncias, e B pode se relacionar com A obrigatoriamente com apenas uma
instância de A. Nesse caso, A é uma entidade independente de B, já B é depen-
dente de ao menos uma instância de A.
Exemplo: veja o Diagrama 1. Sendo A uma entidade Professor e B, uma
entidade Disciplina. Segundo alguma regra de negócio estabelecida, não pode
existir uma disciplina sem professor e só pode ser um (nesse exemplo hipoté-
tico), mas pode haver um professor sem nenhuma ou com muitas disciplinas.
Mas isso deve ser muito bem definido e convencionado entre as esquipes de
desenvolvimento durante as regras de negócio, a fim de não existir dúvidas na
interpretação correta dos relacionamentos.
DIAGRAMA 1. EXEMPLO DE RESTRIÇÃO DE INTEGRIDADE PROPORCIONADA POR

NOTAÇÕES DE CARDINALIDADE – MODELO CONCEITUAL
A (1,1) Relação (0,n) B
Esquema relacional de um banco de dados

O esquema relacional é a especificação de um banco de dados relacional de
maneira textual e deve ser utilizado para descrever as relações. Deve conter, no
mínimo, a definição dos seguintes elementos, já apresentados anteriormente:
• Tabelas necessárias que irão compor o banco de dados;
• Atributos (colunas ou campos) de cada tabela;
• Relacionamentos entre tabelas;
• Restrições de integridade.
Na definição do esquema relacional, são usadas diversas notações, que po-
dem variar de um SGBD para outro. O SGBD assegura que as instâncias do ban-
co de dados estejam em conformidade com as restrições impostas no esque-
ma de banco de dados definido. Um esquema de banco de dados não contém
dados, ele é apenas um esboço das tabelas do banco de dados.
BANCO DE DADOS 49

Um esquema relacional pode ser indicado por R(A1, A 2 ,A 3 ,...A n), em que
R é o nome da relação e A são os atributos (ELMASRI; NAVATHE, 2011, p.
40). No caso do Quadro 3, o esquema relacional das relações Aluno, Curso e
Matricula fi caria assim:
Aluno (RA, Nome, Cod_Curso)
Curso (Cord_Curso, Nome_Curso, Valor)
Matricula (RA,Cod_Curso)
EXPLICANDO
possível definir o esquema relacional, tanto do modelo lógico em tabelas
(veja o Quadro 3) ou direto do modelo conceitual (diagrama Entidade-Rela-
cionamento), desde que os atributos tenham sido especificados. Observe
que no modelo lógico, não se especificam os tipos e características de
cada campo. Isso é uma tarefa desenvolvida no modelo físico, muito em-
bora, algumas ferramentas CASE já tragam o modelo lógico também com
tais informações sobre os campos, mas não é necessário que seja assim
na definição do projeto lógico.
Projeto de implementação de banco de dados

Agora chegou a hora de colocarmos a mão na massa. Preparados? Iremos
apresentar um projeto conceitual completo e no tópico seguinte, a implemen-
tação do projeto de banco de dados relacional.
Para produção dos diagramas do projeto de banco de dados, usaremos a
ferramenta CASE brMODELO (2019), mas lembre-se que os modelos produzidos,
tanto o conceitual como o lógico, não necessitam de ferramentas e podem ser
feitos manualmente apenas com um lápis e papel.
Vale também relembrar que a idealização do modelo conceitual é baseada
na análise de requisitos que, obviamente, já tenha sido devidamente concluída.
Apresentação e análise do modelo conceitual
O Diagrama 2 ilustra o modelo conceitual representado pelo Diagrama Enti-
dade-Relacionamento – DER de um projeto de banco de dados para o controle
de uma biblioteca acadêmica.
O modelo conceitual apresenta as entidades, seus atributos, relacionamen-
tos com as devidas cardinalidades e a movimentação necessária para a rotina
empréstimo e devolução de livros.
BANCO DE DADOS 50

Baseado no modelo conceitual, será criado o modelo lógico na sequência.
DIAGRAMA 2. DER PARA REPRESENTAR O PROJETO CONCEITUAL DO BANCO

DE DADOS PARA CONTROLE DE BIBLIOTECA
RA
Nome
Cord_Curso Data_devolução
Turma Multa_atraso
(1,1) (1,1)
Solicita Aluno Devolve
Data_empréstimo
(0,n) (1,n)
Requisição
Num_requisição RA_Aluno
(0,1)
Contém
(1,n)
Cod_Livro
Livro Autor
Título
Entendendo o modelo conceitual apresentado

A entidade Aluno possui quatro atributos, sendo RA seu atributo-chave.
A entidade Requisição possui inicialmente dois atributos, sendo Num_re-
quisição a chave-primária e RA_Aluno, a chave-estrangeira. Esses dois atribu-
tos são elos com as entidades Aluno e Livro. A entidade Requisição poderá re-
ceber outros atributos referentes aos relacionamentos em que está envolvida
ou uma nova entidade do relacionamento poderá ser produzida. Essa é uma
definição que poderá ser definida no modelo lógico.
BANCO DE DADOS 51

A entidade Livro possui três atribu-
tos, sendo Cod_livro seu atributo-chave.
A entidade Aluno possui um rela-
cionamento solicita com a entidade
Requisição com cardinalidade (1,1 :
0,N), que significa que um aluno pode-
rá ter nenhuma ou várias requisições
para retirada de livros, ou seja, cardi-
nalidade 0,N, e toda requisição só po-
derá ter um aluno como requerente
(1,1). O relacionamento solicita possui
um atributo de relacionamento chamado Data_empréstimo que armazenará a
data da requisição de empréstimo.
Esse atributo deverá ser acrescentado em alguma entidade envolvida no
relacionamento ou ainda a criação de uma entidade exclusiva para essa fina-
lidade. Essa definição se dará no modelo lógico, mas poderia ter sido defini-
da também nesse modelo. Isso mostra que, em alguns casos, podem ocorrer
adaptações entre o modelo conceitual e lógico, desde que não comprometa a
coerência entre os dois modelos e principalmente que venha a comprometer o
projeto de banco de dados como um todo.
A entidade Aluno também possui um relacionamento devolve com a en-
tidade Requisição com cardinalidade (1,1 : 1,N), que significa que um aluno
poderá ter uma ou várias devoluções de livros, ou seja, cardinalidade 1,N, e
toda requisição devolvida só poderá ter um aluno como responsável (1,1). O re-
lacionamento devolve possui dois atributos de relacionamento, um chamado
Data_devolução e o outro Multa_atraso, que armazenam a data da devolução
e, se for o caso, o valor da multa cobrada pelo atraso na entrega do emprés-
timo. Esses atributos deverão ser acrescentados em alguma entidade relacio-
nada ou ainda deverá ser criada uma entidade exclusiva para tal, conforme já
explicado no parágrafo anterior.
A entidade Livro possui um relacionamento contém com a entidade Requi-
sição com cardinalidade (1,N : 0,1), que significa que um livro poderá não estar
em nenhuma ou em apenas uma requisição por vez, ou seja, cardinalidade 0,1,
e toda requisição poderá ter um ou vários livros (1,N).
BANCO DE DADOS 52

Implementação de bancos de dados relacionais
Depois de criado o modelo conceitual, Diagrama 2, o próximo passo é a cria-
ção do modelo lógico, que envolve um diagrama com Modelo Lógico de Da-
dos, por alguns chamado de MLD, ou ainda representado na forma de tabelas
simples com colunas e tuplas relacionadas e o esquema relacional, conforme já
apresentado anteriormente.
Independentemente da forma que o modelo lógico será apresentado, é neces-
sário se familiarizar com algumas nomenclaturas e passos adaptados ou mapeados
do modelo conceitual para o modelo lógico. A Tabela 2 resume esse mapeamento.
Durante a fase de implementação do banco de dados, pode ser necessário
realizar ajustes no modelo lógico ou até mesmo no modelo conceitual. Algu-
mas implementações do projeto lógico se preocupam com detalhes provenien-
tes do sistema gerenciador de banco de dados, que, apesar de não ser utilizado
nessa fase, é desenvolvido com o foco no SGBD escolhido.
TABELA 2. MAPEAMENTO E ADAPTAÇÃO DO MODELO CONCEITUAL PARA O LÓGICO
MODELO CONCEITUAL MODELO LÓGICO
Entidade Tabela
Relacionamento 1:1 ou 1:N Chave-estrangeira ou nova tabela
Relacionamento N:N Nova tabela e duas chaves-estrangeiras
Relacionamento n-ário (ternário, quaternário etc.) Nova tabela
Atributo simples Atributo simples ou campos
Atributo composto Conjunto de atributos simples
Atributo multivalorado Tabela e chave-estrangeira ou N colunas
Conjunto de valores Chamado de Domínio
Atributo-chave Chave-primária
Detalhando um pouco mais a Tabela 2, pode-se notar que:

• As Entidades devem ser representadas em forma de Tabelas (relação).
• Atributo identificador deve ser representado como chave-primária.
BANCO DE DADOS 53

• Atributos simples se tornam nomes de colunas das tabelas ou atributos.
• Atributos compostos devem se tornar em vários atributos simples, com
uma coluna para cada atributo.
• Atributos multivalorados podem ser mapeados de duas formas:
• Como N colunas, sendo N o número máximo de valores do atributo.
• Criando uma nova relação com os valores possíveis e uma chave-es-
trangeira.
Formas de representação do modelo lógico
A seguir serão apresentadas várias formas de representação do modelo lógi-
co. Em uma implementação real, um ou todos os modelos poderão ser adotados.
Na Figura 1 vemos a representação do esquema relacional do modelo concei-
tual do Diagrama 2, descrevendo-o de maneira mais textual baseado na teoria de
conjuntos. Perceba que cada relação possui seus atributos descritos e diferencia-
dos de acordo com suas características de chave-primária ou chave-estrangeira.
Os campos sublinhados são campos-chave, atributos que iniciam com fk
são chaves-estrangeiras (FK - Foreign Key). Não é necessária uma notação como
a apresentada, mas algumas ferramentas CASE as especificam dessa forma.
Assim como as chaves-estrangeiras, também as chaves-primárias podem re-
ceber a notação pk (PK - Primary Key) ao invés do sublinhado. Apesar de ambas
serem opcionais, é muito importante essa diferenciação, pois como a represen-
tação é feita de maneira textual, vale a pena adotá-las para dar destaque aos
campos importantes como chave-primárias e estrangeiras. No caso das chaves-
-estrangeiras, também é comum acrescentar o nome da tabela a qual ela refe-
rencia mesmo que seja de forma abreviada e com a primeira letra em maiúsculo.
Exemplo: fk_Aluno_RA, indica uma chave-estrangeira apontando para um
atributo chave RA de uma entidade Aluno.
Aluno (RA, Nome, Turma, Cod_Curso)
Requisição (Num requisição, fk_Aluno_RA, fk_Cod_Livro, Data_empréstimo,

Data_devolução, Multa_atraso)
Livro (Cod_Livro, Autor, Título)

Figura 1. Representação do esquema relacional – Modelo lógico.
BANCO DE DADOS 54

A Figura 2 apresenta todas as tabelas relacionadas. Perceba que os campos-
-chave das tabelas Aluno e Livros aparecem como chave-estrangeira na tabela
Requisição, que também possui sua própria chave-primária. As chaves são elos
dos relacionamentos, como podemos ver na figura apresentada. Os campos
demarcados por uma elipse são os atributos agregados provenientes das rela-
ções solicita, devolve e contém do modelo lógico.
Figura 2. Representação das tabelas relacionadas – Modelo lógico.
A solução apresentada na Figura 3 é uma alternativa ao modelo da Figura

2, com implementação de quatro tabelas ao invés das três apresentadas ante-
riormente. Nesse caso, a tabela Movimento não possui uma chave-estrangeira
RA do aluno por ser desnecessário, já que a tabela Requisição já possui essa
informação e estão relacionadas. O modelo conceitual poderia ser ajustado
para demonstrar essa implementação se for julgado como a melhor opção.
BANCO DE DADOS 55

Figura 3. Representação das tabelas relacionadas – Modelo lógico.
Apenas para título de curiosidade, lembre-se que o aluno poderia ter rea-
lizado uma requisição de empréstimo com vários livros e poderia devolvê-los
separadamente e em datas diferentes. Dependendo do modelo de negócio e
do volume estimado, a opção por três ou quatro tabelas poderia ter um im-
pacto diferente em cada caso, logo, o modelo conceitual talvez necessite de
um ajuste para entrar em conformidade com o modelo lógico para que toda a
documentação fique mais alinhada.
Na sequência são apresentados os diagramas criados automaticamente
pela ferramenta CASE brModelo a partir do modelo conceitual já apresentado
anteriormente. É importante destacar que, mesmo tendo a opção automática
de criação do modelo lógico, é possível criá-lo do zero ou mesmo alterá-lo, in-
dependentemente do modelo conceitual ser ajustado na ferramenta.
BANCO DE DADOS 56

O Diagrama 3 ilustra a criação do modelo lógico a partir do modelo concei-
tual apresentado no Diagrama 2, na forma de visualização de modelo lógico da
ferramenta brModelo.
O Diagrama 4 é uma forma opcional e mais simplificada, que pode ser uma
alternativa e já inclui um esquema relacional no topo das tabelas.
DIAGRAMA 3. PROJETO LÓGICO DO BANCO DE DADOS PARA CONTROLE

DE BIBLIOTECA – MODELO LÓGICO
(1,1) (1,1)
Solicita Devolve
(0,n) (1,n)
(0,1)
Contém
(1,n)
BANCO DE DADOS 57

DIAGRAMA 4. PROJETO LÓGICO DO BANCO DE DADOS PARA CONTROLE DE
BIBLIOTECA – FORMA SIMPLIFICADA E ALTERNATIVA – MODELO LÓGICO
(1,1) (1,1)
Solicita Devolve
(0,n) (1,n)
(0,1)
Contém
(1,n)
Observe que nos Diagramas 3 e 4 existem ícones em forma de chave ape-

nas para destacar que há campos-chave na tabela. Isso é um recurso da ferra-
menta CASE e não uma notação obrigatória na representação do diagrama do
projeto lógico.
BANCO DE DADOS 58

Sistemas de gerenciamento de banco de dados
Um sistema gerenciador de banco de dados – SGBD ou DBMS (DataBase
Management System em inglês) – é um conjunto de programas interligados
que permite criar, manipular e manter bancos de dados, garantindo a in-
tegridade e segurança dos dados. É um software que permite gerenciar os
processos de definição, construção, manipulação e compartilhamento de
dados entre várias aplicações de usuários. Definir um banco de dados im-
plica em especifi car a estrutura, os tipos de dados e as restrições para os
dados armazenados em um banco de dados.
CITANDO
“A maioria desses sistemas de banco de dados foi implementada em com-
putadores grandes (mainframes) e caros, começando em meados de 1960
indo até os anos 70 e 80. Os principais tipos desses sistemas iniciais foram
baseados em três paradigmas principais: os sistemas hierárquicos, aqueles
baseados em modelo de rede, e os de arquivos invertidos.”, “Os primeiros
sistemas relacionais experimentais desenvolveram-se no fim dos anos 0
e os SGBDRs (sistemas de gerenciamento de banco de dados relacional)
introduzidos no início dos anos 80 eram muito lentos, pois não usavam pon-
teiros para o armazenamento físico ou registros de localização para acessar
os registros de dados relacionados” (ELMASRI; NAVATHE, 2011, p. 15).
Os primeiros sistemas de bancos de dados comerciais utilizavam sis-

temas de arquivos primitivos e limitados da época que não permitiam o
acesso concorrente entre usuários e processos. Com a evolução desses sis-
temas, passaram a utilizar diferentes modelos de dados ou representação
para descrever sua estrutura, como o modelo hierár uico, modelo em
redes, modelo relacional – que ainda é o mais utilizado atualmente – e o
modelo orientado a objetos.
No modelo hierár uico, os dados são estruturados em hierarquias ou ár-
vores, nas quais os registros de dados estão contidos em elos ou nós dessas
hierarquias. Os registros possuem sub-registros, formando uma ramificação,
em que um registro é o ascendente e o outro, descendente. A raiz é o úni-
co registro que não possui ascendente (SILBERSCHATZ; KORTH; SUDARSHAN,
1999). O sistema comercial mais divulgado no modelo hierárquico foi o IMS -
BANCO DE DADOS 59

Information Management System criado pela IBM. A maior parte das restrições e
consistências de dados deveria ser definida dentro dos programas e aplicações
criadas, o que dificulta muito o processo de desenvolvimento, a padronização,
controle de redundâncias, retrabalhos, entre outros.
O modelo em rede surgiu como uma evolução e extensão do modelo hie-
rárquico, mas eliminando o conceito de hierarquia e permitindo que um mes-
mo registro estivesse envolvido em várias associações. Diferentemente do
modelo hierárquico, em que qualquer acesso aos dados passava pela raiz hie-
rárquica, o modelo em rede possibilita acesso direto a qualquer nó sem passar
pela raiz. No modelo em rede, o sistema comercial mais divulgado é o CA-IDMS
da Computer Associates.
O modelo relacional, foco dos nossos estudos, foi originalmente projetado
com o objetivo de separar o armazenamento físico da representação concei-
tual. Foi esse modelo que introduziu a linguagem de consulta de alto nível, que
se mostrou como uma alternativa de interface entre aplicações e linguagens de
programação para acesso aos dados.
O modelo orientado a objetos veio a se tornar comercial em meados de
1980. A motivação para seu surgimento foi em função dos limites de armazena-
mento e da forma de representação semântica impostas no modelo relacional.
Alguns sistemas de informações mais específicos necessitam de tipos comple-
xos de dados e são mais bem manipulados em modelos orientados a objetos.
A facilidade em criar tipos de dados necessários para seguimentos específi-
cos é uma característica das linguagens de programação orientadas a objetos.
A estrutura padrão para os bancos de dados orientados a objetos foi idealizada
pelo ODMG - Object Database Management Group. Esse grupo é formado por re-
presentantes dos principais fabricantes de banco de dados orientados a objetos.
Arquitetura de sistemas de banco de dados

A arquitetura ANSI-SPARC - American National Standards Institute
- Standards Planning and Requirements Committee (Instituto Nacional
Americano de Padrões – Comitê de Planejamento e Requisitos) é um pa-
drão americano de projeto abstrato para um sistema de gerenciamento de
banco de dados. Também conhecida como arquitetura Three-Schema (três
BANCO DE DADOS 60

esquemas), é a mais conhecida e referenciada no âmbito dos bancos de
dados e foi proposta em 1978 (ELMASRI; NAVATHE, 2011).
O objetivo dessa arquitetura foi separar aplicações do usuário final do ban-
co de dados (Figura 4). Nessa arquitetura, ocorre a divisão em três níveis, cha-
mados de esquemas:
• Esquema externo ou nível externo - visão do usuário;
• Esquema conceitual ou nível conceitual - visão global;
• Esquema interno ou nível interno – visão interna.
Visão do usuário
Aplicação 1 Aplicação N
NÍVEL EXTERNO Visão externa Visão externa
MAPEAMENTO
EXTERNO/CONCEITUAL
NÍVEL CONCEITUAL Esquema conceitual
MAPEAMENTO
CONCEITUAL/INTERNO
NÍVEL INTERNO Esquema interno
BANCO DE DADOS ARMAZENADO
Figura 4. Arquitetura Three-Schema. Fonte: ELMASRI; NAVATHE, 2011. (Adaptado).
Na visão de Elmasri e Navathe (2011), os três esquemas são explicados da

seguinte forma:
O nível externo abrange o esquema externo ou visões de usuários. Cada
esquema externo descreve a parte do banco de dados que um grupo de usuá-
rios tem interesse e oculta o restante e outros detalhes do banco de dados.
BANCO DE DADOS 61

O nível conceitual possui um esquema conceitual, que descreve a estru-
tura de todo o banco de dados. O esquema conceitual oculta os detalhes das
estruturas de armazenamento físico e se concentra na descrição de entidades,
tipos de dados, conexões, operações de usuários e restrições. O modelo de
dados representacional é usado para descrever o esquema conceitual quando
o sistema de banco de dados for implementado. Esse esquema de implementa-
ção conceitual é normalmente baseado em um projeto de esquema conceitual
em um modelo de dados de alto nível.
O nível interno ou esquema interno descreve a estrutura de armazena-
mento físico do banco de dados. Esse esquema utiliza um modelo de dado físi-
co e descreve os detalhes complexos do armazenamento de dados e caminhos
de acesso ao banco de dados.
A Figura 5 ilustra uma aplicação prática na visão dos três esquemas, sendo
explicados na sequência.
EXTERNO (Excel) EXTERNO (Java)

(A3) - Numero_do_empregado String num_empr;
(B3) - Salário String num_dpto;
CONCEITUAL
NÚMERO_EMPREGADO CARACTER(5)
NÚMERO_DEPARTAMENTO CARACTER(4)
SALÁRIO DECIMAL(5)
INTERNO
EMP ARMAZENADO BYTES=20
PREFIXO BYTES=6, OFFSET=0
EMP# BYTES=6, OFFSET=6, INDEX=EMPX
DEPTO# BYTES=4, OFFSET=12
PAGTO BYTES=4, ALIGN=FULLWORD, OFFSET=16
Figura 5. Exemplo dos três esquemas. Fonte: DATE, 1999. (Adaptado).
No nível externo, existem duas visões: usuário do cel e usuário de apli-

cações em Java. Em ambas as visões, a entidade Empregado é representada
por meio de um registro contendo dois campos, mas não exatamente iguais
nas duas visões, pois depende da necessidade de cada aplicação ou usuário. O
primeiro usuário enxerga o Número do empregado e Salário. Já o segundo vê
BANCO DE DADOS 62

apenas o Número do empregado e o Número do Departamento. Em cada uma
das visões, o registro é definido conforme características de cada aplicação,
mas o banco de dados é único.
No nível conceitual, o banco de dados armazena informações relativas à
entidade Empregado, com seus atributos Número do empregado, Número do
Departamento e Salário, incluindo seus respectivos tipos e tamanhos.
No nível interno, a representação é feita por meio de um registro de ar-
mazenado, com detalhes mais técnicos, chamado EMP_ARMAZENADO, com 20
bytes de tamanho. Esse registro possui, entre outras características, uma inde-
xação por uma chave através do atributo EMP#.
Uma questão importante da arquitetura de três esquemas são os chamados
mapeamentos. Segundo Elmasri e Navathe (2011), o mapeamento é o procedi-
mento de conversão de uma solicitação ou resultado entre os três níveis.
Um exemplo: uma aplicação poderá fazer uma consulta no respectivo es-
quema externo e então será transformada numa solicitação para o esquema
conceitual. Esse é chamado de mapeamento externo para conceitual. Por
sua vez, haverá um correspondente no esquema interno, ou seja, um mapea-
mento conceitual para interno.
A resposta a tal solicitação seguirá o caminho inverso, passando novamen-
te por mapeamentos, mas do esquema interno para conceitual e conceitual
para externo. Veja a ilustração desse mapeamento na Figura 6.
Mapeamento de fora para dentro
Visão Externa Visão Conceitual Visão Interna
Mapeamento de dentro para fora
Figura 6. Mapeamento entre os três esquemas.
BANCO DE DADOS 63

As primeiras arquiteturas de banco de dados eram implementadas em am-
bientes que utilizavam grandes computadores, que posteriormente foram cha-
mados de mainframes. Todos os processos eram executados remotamente em
um sistema centralizado e somente as informações de exibição e controles
eram enviadas aos terminais conectados ao computador central. Eram termi-
nais sem poder de processamento.
Posteriormente, com o advento dos computadores pessoais e o aumento da
capacidade dos mesmos em memória e processamento, gradualmente os SGBD
começaram a explorar o poder de processamento disponível do lado do usuá-
rio, o que culminou em uma arquitetura chamada SGBD cliente-servidor, com
alguns componentes do sistema sendo realizados do lado do usuário, ou seja, no
computador cliente, e outros permanecendo do lado do SGBD, ou seja, servidor.
As funcionalidades transferidas para o lado do cliente foram a interfa-
ce com o usuário e os programas de aplicação. Através da linguagem SQL
- Structured Query Language (Linguagem de Consulta Estruturada), que é uma
linguagem padrão de gerenciamento de dados utilizada pelos principais siste-
mas gerenciadores de bancos de dados relacionais, criou-se uma divisão lógica
entre o cliente e o servidor. Mas as consultas e o processamento de transação
permaneceram do lado do servidor.
Nessa arquitetura, o servidor geralmente é chamado Servidor de Consulta
ou Servidor de Transação, porque fornece essas duas funcionalidades. Um
SGBDR (relacional) também é normalmente chamado de Servidor SQL, pois
a maioria dos servidores SGBDR é baseado na linguagem e padrões SQL (SIL-
BERSCHATZ; KORTH; SUDARSHAN, 1999). Observe que o R adicionado ao final
da sigla SGBD diz respeito a sistemas relacionais, muito embora não seja neces-
sário devido ao fato de que os sistemas gerenciadores de banco de dados mais
utilizados atualmente são exatamente os relacionais.
BANCO DE DADOS 64

Sintetizando
Caro aluno, neste capítulo completamos os estudos básicos sobre banco de
dados e os sistemas gerenciadores de banco de dados, dos modelos conceitual
e lógico. Foram abordados vários conceitos sobre o tema de forma geral, que
serão destacados aqui.
Na apresentação do conceito do modelo relacional, vimos que este é fundamen-
tado na teoria dos conjuntos e lógica de predicado, que são conceitos da mate-
mática. Vimos que enquanto o modelo entidade-relacionamento é um artefato
de criação do projeto conceitual do banco de dados, o modelo relacional faz parte
do projeto lógico, que é uma fase dependente da conclusão do projeto conceitual.
No projeto lógico, o nível de abstração é diminuído e possui uma visão um
pouco mais distante do usuário, pois envolve alguns detalhes já orientados ao
sistema gerenciador de banco de dados que será adotado. Algumas nomencla-
turas também são ajustadas, como entidade, que é mais comumente tratada
como tabela ou relação, atributos como campos, conjunto de valores de
um atributo como domínio, entre outros.
Na abordagem sobre o esquema relacional do banco de dados, vimos que
ele deve conter a definição de elementos, como tabelas, atributos, relaciona-
mentos, restrições de integridade e a representação textual dos elementos en-
volvidos. As restrições de integridade abordadas foram: restrição de chaves,
de domínio, integridade referencial e integridade definida pelo usuário.
Em projeto de implementação de banco de dados, vimos uma apresentação
e análise de um modelo conceitual para, na sequência, estudarmos um modelo
lógico e, em seguida, abordar a implementação de um banco de dados rela-
cional com vários diagramas apresentados para a definição do modelo lógico.
E, finalmente, o capítulo trouxe uma abordagem sobre detalhes da arqui-
tetura dos sistemas gerenciadores de banco de dados com destaque para a
arquitetura Three-Schema.
Conclui-se, então, que o capítulo trouxe uma visão geral do modelo rela-
cional e do processo de criação do modelo lógico, baseando-se nos modelos
de dados criados no projeto conceitual. Uma vez concluído o modelo lógico, o
projeto de banco de dados está pronto para entrar em sua fase final, de cons-
trução do modelo físico.
BANCO DE DADOS 65

BRMODELO. Projeto brModelo 3.2. Disponível em: <http://www.sis4.com/br-
Modelo/>. Acesso em: 11 abr. 2019.
CODD, E. F. A relational model of data for large shared data banks. Communi-
cations of the ACM, v. 13, n. 6, 1970. Disponível em: <https://www.seas.upenn.
edu/~zives/03f/cis550/codd.pdf>. Acesso em: 11 abr. 2019.
Elsevier, 2003.
Addison Wesley, 2011.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009,
v. 4.
SILBERSCHATZ, A.; KORTH, H.F.; SUDARSHAN, S. Sistema de banco de dados.
3. ed. São Paulo: Makron Books, 1999.
BANCO DE DADOS 66

UNIDADE
3 MODELO FÍSICO DO
BANCO DE DADOS
INTRODUÇÃO À
LINGUAGEM SQL

Apresentação da linguagem SQL;
Restringir e ordenar dados;
Manipular funções de grupo e subconsultas.
Tópicos de estudo
Conceitos de Linguagem SQL Agregando dados com funções
Consultas básicas em Lingua- de grupo
gem SQL Usando subconsultas de
dados
Restringindo e ordenando
dados
Uso de funções para transfor-
mar dados
Exibindo dados de várias
tabelas
BANCO DE DADOS 68

Conceitos de Linguagem SQL
Olá, aluno! Nesta unidade iremos abordar o modelo físico da modelagem
de banco de dados. Esse modelo é criado após o modelo lógico, muito embora
alguns utilitários ou algumas ferramentas CASE incorporadas ou conectadas
aos SGBDs sejam capazes, de maneira automática e imediata, de gerar o mo-
delo físico a partir do modelo lógico. Para tanto, iniciaremos os estudos sobre
os códigos da Linguagem SQL, que é a principal responsável por essa fase. Pre-
parados? Então vamos lá.
SQL (structured query language), que em tradução livre quer dizer “lingua-
gem estruturada de consulta” ou “linguagem estruturada de pesquisa”, com
a palavra query trazendo um melhor significado no contexto dos bancos de
dados quando traduzida por “inquirição”. Ou seja, é o ato de requisitar, inda-
gar, averiguar ou perguntar, conforme define os dicionários. Quando lançamos
mão de um comando SQL, uma requisição é enviada ao sistema gerenciador
do banco de dados, que irá atender ou não os vários tipos de requisições pos-
síveis. Logo, a linguagem permite muito mais do que simples consultas do seu
relacionamento com o banco de dados.
Alguns autores, como Elmasri e Navathe (2011), apontam a Linguagem SQL
como uma das maiores razões para o sucesso dos bancos de dados relacionais
utilizados no mundo. É um padrão para os bancos relacionais, permitindo que
usuários possam escrever declarações padronizadas em SQL (códigos em SQL)
em uma aplicação de usuário para ter acesso a dados armazenados e controla-
dos por vários sistemas gerenciadores de banco de dados diferentes.
A Linguagem SQL foi projetada pelo centro de pesquisa da IBM nos anos 1970,
como um protótipo de sistema experimental de banco de dados chamado System
R (DATE, 2003). Por ser um protótipo na época, surgiram vários outros produtores
da linguagem, o que levou à sua rápida expansão e necessidade de padroniza-
ção. Coube então a tarefa de padronizar essa linguagem com a American Natio-
nal Standards Institute (Instituto Americano de Padrões – ANSI) e a International
Organization for Standardization (Organização Internacional de Padrões – ISO), as
quais chegaram a uma versão padronizada nos anos 1980, surgindo então a SQL
ANSI de 1986, chamada SQL-86 ou SQL1. Posteriormente foram produzidas outras
versões atualizadas, como a SQL2 (ou SQL-92), SQL3, SQL-99, entre várias outras.
BANCO DE DADOS 69

Essas atualizações permanecem
frequentes. Em 2017, uma nova atua-
lização da documentação sobre a
padronização da linguagem foi dispo-
nibilizada pela ISO, a ISO/IEC TR 19075-
6:2017, que abrange o suporte do SQL
para notação de objetos JavaScript
(ISO/IEC, 2019).
É importante enfatizar que, no de-
senvolvimento de um projeto de ban-
co de dados, este é dividido em três
níveis distintos: o conceitual, lógico e
físico. É importante não confundir com
os níveis de visualização ou esquemas
que os SGBDs de arquitetura Three-Schema apresentam, que são uma estru-
tura apresentada também em três níveis, chamadas de esquemas ou visões:
visão ou esquema externo, esquema conceitual e esquema interno. Lembre-se
que, falando do projeto de banco de dados como um todo, os SGBDs são utili-
zados efetivamente do nível lógico para o físico do projeto de banco de dados.
A confusão pode se dar porque as palavras “nível” e “conceitual” aparecem nos
dois casos, mas são contextos distintos.
CITANDO
“Em muitos S BDs, não existe uma separação específica dos três níveis
(Three-Schema) Nos S BDs, em que uma clara separação é mantida
entre os níveis conceitual e interno, uma linguagem de definição de dados
é usada para especificar somente o esquema conceitual. Outra linguagem,
a linguagem de definição de armazenamento, é utilizada para especificar
o esquema interno. Os mapeamentos entre os dois esquemas podem ser
estabelecidos em qualquer uma dessas linguagens. Para uma verdadeira
arquitetura de três esquemas, necessitaríamos de uma terceira lingua-
gem, a linguagem de definição de visões, para especificar as visões dos
usuários (aplicações) e os seus mapeamentos para o esquema conceitual,
mas na maioria dos S BDs a linguagem de definição de dados é usada
para definir ambos os esquemas, o conceitual e o externo” (EL ASRI e
NA AT E, p.23, 20 ).
BANCO DE DADOS 70

A estrutura da Linguagem SQL
A Linguagem SQL está organizada e separada por categorias de comandos
ou componentes, também chamadas de tipos de linguagens, oferecendo re-
cursos para definição, manipulação e controle dos dados dos bancos de dados.
São elas:
DDL – ata definition language – linguagem de definição de dados.
DML – ata manipulation language – linguagem de manipulação de dados.
DCL – ata control language – linguagem de controle de dados.
Outras classificações mais específicas também podem ser tratadas separa-
damente, como restrições de integridade e controle de transações.
A seguir, é apresentada uma relação de ações SQL agrupadas conforme sua
classificação e tipo. Posteriormente, cada uma será detalhada e exemplificada
com todas as variação possíveis. Vejamos alguns exemplos:
DDL
Os comandos desse grupo são referentes à linguagem de definição de da-
dos, sendo possível realizar operações como:
• CREATE – Criação de novas estruturas, como banco de dados e tabelas.
• ALTER – Alteração de estruturas já existentes.
• DROP – Remoção/exclusão de estruturas criadas.
DML
No grupo da linguagem de manipulação de dados é possível realizar:
• INSERT – Inserção de registros em tabelas.
• SELECT – Selecionar (consultar, retornar) registros das tabelas.
• UPDATE – Atualização (alteração) de registros.
• DELETE – Exclusão de registros.
DCL
Muito embora seja classificada por alguns como subclasse DML pela sua
natureza também de manipulação, iremos tratá-la separadamente, em concor-
dância com a maioria dos autores. A linguagem de controle de dados permite:
• GRANT – Concessão de privilégios em tabelas e visões.
• REVOKE – Revogação de privilégios em tabelas e visões.
Restrições de integridade
É possível realizar ações que contribuam para a integridade dos dados
como:
BANCO DE DADOS 71

• STORED PROCEDURES – Um conjunto de comandos em SQL que podem
ser executados de uma só vez.
• TRIGGERS – Gatilho que é ativado quando um evento especial acontece
numa tabela, algumas vezes devendo afetar outras tabelas.
Controle de transações
Permite garantir a efetividade de ações realizadas no banco de dados, como:
• COMMIT – Efetiva alterações pendentes em um banco de dados.
• ROLLBACK – Desfaz uma alteração antes de ser efetivada no banco de dados.
• SAVEPOINT – Permite uma subdivisão lógica de uma transação longa.
De forma geral, essa é toda a estrutura da Linguagem SQL, devidamente
organizada conforme as ações necessárias. Contudo, esses comandos pos-
suem uma grande variação, a qual será apresentada na sequência. Para tanto,
é aconselhável você instalar algum SGBD para realizar testes sobre tudo o que
for ensinado.
Existe uma grande variação de SGBDs gratuitos. Faça uma pesquisa para
saber qual SGBD se adéqua melhor à sua versão de sistema operacional. Pode
ser a versão mais simples possível, pois será usada apenas para testes de co-
mandos SQL, sendo necessário um banco de dados rodando.
Para criação e teste desse material, foi adotada uma solução MySQL gratui-
ta chamada de MariaDB, versão 10.4.3, de código livre (MARIADB, 2019), que,
além de uma interface gráfica, instala o MySQL em sua pasta para podermos
utilizá-lo via prompt de comandos. Você pode localizar o link para baixar o Ma-
riaDB nas referências bibliográficas dessa Unidade.
Procure nos sites dos desenvolvedores a melhor versão para o seu siste-
ma. Se você tiver um equipamento com disponibilidade de espaço, pode fa-
zer experimentos além do MySQL, como o Oracle, MS SQL Server, PostgreSQL,
entre outros, que também oferecem essa possibilidade com poucas variações
no código. Muitos dos SGBDs possuem ferramentas gráficas que permitem a
criação e manipulação dos bancos de dados de maneira intuitiva, porém, para
um domínio da Linguagem SQL, faremos a partir de comandos.
onfigurando o M para ser acessado de ual uer diretório
Após baixar o MariaDB ou outro SGBD e instalá-lo, na maioria dos casos não
é necessário fazer nenhum ajuste. Para testar, basta abrir o prompt de coman-
do (às vezes chamado de “tela preta do DOS”) e digitar:
BANCO DE DADOS 72

m s l version
Se a resposta do comando for a versão instalada do MySQL (ou SGBD) esco-
lhido, é porque está tudo certo. Se o erro avisa “mysql não é reconhecido como
um comando interno”, você deverá entrar em sua pasta de instalação com o
comando “cd” do DOS, por exemplo CD C:\Program Files\MariaDB 10.4\bin e,
em seguida, digitar o comando “mysql –version” (Figura 1) ou adicionar o “cami-
nho” da instalação do MySQL na variável de ambiente “path” do sistema, e você
poderá acessá-lo de qualquer outra pasta. Depois, siga os passos seguintes:
• Entre na opção para “editar as variáveis de ambiente do sistema” em “Pro-
priedades do sistema do Windows”. Você pode chegar a essa opção de várias
formas. Pesquise como fazer isso na versão do seu sistema.
• Assim que encontrar a variável path, adicione o caminho da instalação do
executor do MySQL nessa variável, por exemplo C:\Program Files\MariaDB
10.4\bin. Se você seguiu a orientação-padrão de instalação do produto, ele
deve ter sido instalado em C:\Program Files\MariaDB 10.4\bin. Caso esteja em
outro lugar, não há problemas apenas copie e cole quando tiver que informar
o caminho correto.
• Após a configuração da variável path, apenas feche a tela do prompt de
comando e abra outra novamente. Em algumas versões mais antigas do siste-
ma é necessário reiniciar o computador. Para testar se está tudo bem, basta
digitar mysql –version e verificar a resposta.
Para entrar no prompt do comando SQL, é necessário se autenticar no My-
SQL. Para tanto, utilize um dos comandos a seguir:
• m s l -u root -p
Em seguida, será solicitada a senha do usuário root que você cadastrou
durante a instalação do SGBD, MariaDB ou outro qualquer.
Como alternativa a esse comando, podem ser usados também:
• m s l --user root --pass ord sua-senha
ou
• m s l -h - m s l- -uroot -p
A Figura 1 apresenta todo o processo e, em
destaque, o prompt de comandos do SQL.
Esse modo é chamado de terminal ou shell de
comandos.
BANCO DE DADOS 73

Prompt de comando
do MySQL
Figura 1. Tela do prompt de comando do sistema e como acessar o prompt do MySQL.
Agora está tudo pronto para colocar a mão na massa. Aprenderemos inicial-
mente comandos que permitem fazer vários tipos de consulta no banco de da-
dos, que são as ações mais executadas dentro dele, tanto é que o próprio nome
da Linguagem SQL remete a esse procedimento.
A criação e inserção de bancos de dados não serão abordadas profunda-
mente nesse momento; isso ficará para o próximo capítulo.
Testando o banco de dados instalado
Para familiarizar-se com o banco de dados instalado, vamos testar alguns
comandos básicos para avaliar as bases de dados que já acompanham o pro-
duto com a instalação de fábrica. Os comandos podem ser digitados em minús-
culo ou maiúsculo, porém, pode haver algum SGBD ou sistema operacional que
exija uma ou outra forma. Argumentos que complementam o comando, como
lista de atributos, nomes de tabelas, condições etc. também podem variar de
acordo com o que foi criado no banco de dados ou no SGBD adotado. Logo,
procure fazer testes para avaliar as limitações nesse sentido. Não é, portanto,
uma limitação da Linguagem SQL.
BANCO DE DADOS 74

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, mas o ponto-e-vírgula ao final de cada comando é obriga-
tório para a maioria dos casos. Nomes do banco de dados e tabelas ficarão em
minúsculas. Os atributos, não sendo sigla, sempre iniciam com maiúscula, e o
restante em minúscula.
Comando para mostrar as bases de dados:
SHOW s;
igura . Resposta ao comando SHOW databases.
A resposta ao comando foi a exibição de quatro bases de dados (Figura 2):

n ormation schema m s l per ormance schema e test. Essas bases per-
tencem ao próprio MySQL para execução de funcionalidades de controle e ge-
renciamento. Algumas são apenas de leitura, ou seja, você não poderá alterar.
Para acessar (usar) uma dessas bases de dados, experimente o comando
USE <nome da ase de dados> e em seguida o comando SHOW tables. Exemplo:
m s l
SHOW tables;
BANCO DE DADOS 75

igura . Resposta ao comando SHOW tables.
A Figura 3 mostra que a base de dados chamada pelo comando m s l está

sendo usada, pois o prompt m s l informa isso. O comando SHOW tables
apresenta todas as 31 tabelas da base de dados, mostradas apenas parcial-
mente pela imagem. Para acessar outra base de dados, basta utilizar o coman-
do USE novamente seguido do nome da base desejada.
Consultas básicas em Linguagem SQL

Veremos então nosso primeiro comando SQL, o SELECT. Como foi visto, ele
faz parte do grupo de comandos de manipulação de dados – DML.
O comando SELECT é usado para consultar o banco de dados, retornando
dados recuperados de tabelas para satisfazer determinadas condições expres-
sas no comando. Sua sintaxe genérica e mais simplificada é:
SELECT <lista de atri uto> FROM <nome da ta ela>;
Suponha que exista uma tabela com o nome Aluno. O comando ficaria des-
sa forma:
SELECT * FROM aluno;
BANCO DE DADOS 76

Figura 4. Resposta ao comando SELECT * FROM aluno.
A Figura 4 ilustra o retorno do comando SELECT. Perceba que os atributos

“RM”, “Nome” e “Cod_Curso” ocupam as colunas da tabela, e a organização está
por ordem de RM, por ser o campo declarado como chave dessa relação. Mais
adiante veremos variações desse comando.
Talvez você tenha sentido falta de um comando para criar e inserir dados.
Conforme orientação da ementa da disciplina, esses e outros comandos serão
abordados em detalhes no próximo capítulo. No entanto, você poderá opcional-
mente utilizar os Scripts SQL a seguir; basta copiar e colar ou digitar para reali-
zar esse ou outros experimentos. A seguir teremos três Scripts SQL: um criará a
base de dados biblioteca; dentro dessa base de dados, temos outro script para
criar a tabela aluno, e um terceiro script irá popular a tabela aluno, ou seja, inse-
rir dados nela. Apesar de não ser o foco desta Unidade, para um bom entendi-
mento, é conveniente copiar linha por linha e entre cada comando, como poderia
ser dado o comando SELECT * FROM Aluno, principalmente entre os comandos
INSERT, para ver a evolução da base de dados recebendo novos registros.
Scripts SQL
PRIMEIRO script: cria a base de dados biblioteca e abre a base de dados:
CREATE DATABASE biblioteca;
USE biblioteca;
SEGUNDO script: cria a tabela aluno e mostra as tabelas existentes.
CREATE TABLE aluno(RM Integer(10) unsigned not null, Nome varchar(50)
not null, Cod_Curso Integer(10), Primary key(RM));
BANCO DE DADOS 77

SHOW TABLES;
TERCEIRO Script: insere oito registros na tabela aluno e mostra todos ao
final.
INSERT INTO aluno(RM, Nome, Cod_Curso) VALUE (10,”Fulano de Tal”,
204020);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (05,”Adriana Gomes”,
204050);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (01,”Lucas Skywalker”,
204030);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (90,”Zilda Melo”, 204030);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (34,”Karoline Singer”,
204050);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (12,”Renato Alves”,
204030);
INSERT INTO aluno (RM, Nome, Cod_Curso) VALUE (14,”Marcos dos Santos”,
204020);
INSERT INTO Aluno(RM, Nome, Cod_Curso) VALUE (03,”Ana Beatriz”,
204050);
SELECT * FROM aluno;
Após todos esses procedimentos, sua tela deverá estar idêntica à Figura 4.
Para exercitar um pouco mais o comando SELECT, podemos aprovei-
tar esses esforços e rapidamente criar também uma segunda tabela para
nossa base de dados biblioteca, de forma bem prática. Aproveite o código
mostrado e crie outra tabela com o nome Curso. Essa tabela deverá ter os
atributos Cod_Curso, Nome_Curso e Valor, sendo Cod_Curso o campo-
-chave. O esquema relacional dessa tabela pode ser representado por Cur-
so(Cod_Curso, Nome_Curso, Valor). Insira registros nessa tabela e utilize
os códigos do curso já adotados na tabela aluno para o campo Cod_Curso
para que, posteriormente, possam ser criados relacionamentos entre elas.
Lembrando que os comandos CREATE e INSERT serão abordados com de-
talhes no próximo capítulo.
Voltemos então aos estudos sobre o comando SELECT, pois existe uma
gama de variações importantes sobre esse comando que serão tratadas nos
tópicos a seguir.
BANCO DE DADOS 78

Restringindo e ordenando dados
Inicialmente abordaremos a questão da restrição dos dados. Podemos en-
tão restringir e limitar os dados trazidos pelo comando SELECT nas consultas
realizadas. Isso é muito útil quando manipulamos tabelas muito grandes ou
com muitos atributos. Nem sempre desejamos ver todas as colunas de uma
tabela ou mesmo o número de linhas trazidas, que podem ser milhares.
Tomando como base o comando aplicado, SELECT * FROM Aluno, podemos
substituir o asterisco e determinar uma lista de campos que desejamos visuali-
zar. Veja o comando a seguir e o resultado apresentado na Figura 5:
SELECT Nome, Cod_Curso FROM aluno;
Figura 5. Resposta ao comando para limitar colunas da tabela.
Dessa forma, é possível escolher qual ou quais campos desejamos trazer da

tabela em questão.
Uma segunda questão sobre restrição dos dados nas consultas realizadas é
com relação ao número de registros retornados com o comando SELECT, pois
algumas vezes precisamos limitar a quantidade de registros. O comando a se-
guir permite determinar o número máximo de registros (no caso, quatro), con-
forme pode ser visto na Figura 6.
SELECT * FROM aluno LIMIT 4
BANCO DE DADOS 79

igura . Resposta ao comando para limitação dos dados.
Obviamente, é possível combinar as restrições limitando colunas e linhas

em um único comando. Exemplo:
SELECT RM, Cod_Curso FROM aluno LIMIT 7;
Nesse caso, apenas duas colunas, RM e Cod_Curso, seriam exibidas, e ape-
nas sete registros seriam listados.
Ordenação
Observe que, em todos os casos apresentados, os registros aparecem sem-
pre em ordem de RM, ou seja, ordem numérica crescente, porque RM é o cam-
po-chave da tabela Aluno, mesmo quando é suprimido em uma das consultas.
É possível, no entanto, determinar a ordem de exibição dos dados independen-
temente do campo-chave da tabela. Os parâmetros ORDER BY ASC ou ORDER
BY DESC, seguidos no atributo de referência, aplicarão ordenação ascendente
ou descendente, respectivamente. Vejamos cada um dos comandos separada-
mente. As Figuras 7 e 8 ilustram as duas ordenações:
SELECT * FROM aluno ORDER BY nome ASC;
ou
SELECT * FROM aluno ORDER BY nome DESC;
BANCO DE DADOS 80

igura . Ordenação ascendente por ordem de nome do aluno.
Figura 8. Ordenação descendente por ordem de nome do aluno.
Uso de funções para transformar dados

Vejamos agora uma série de variações do comando SELECT que serão úteis
na manipulação dos dados provenientes do banco de dados. Também veremos
que esse comando é útil para manipular outras informações, como de sistema
ou de variáveis de memória. Existem funções, que são comandos especiais
que realizam operações e nos devolvem ações esperadas. Vejamos algumas
destas funções utilizadas em conjunto com o somando SELECT.
BANCO DE DADOS 81

Manipulação de data e hora
Função Current_Date() ou Curdate() e Current_Time ou Curtime() para
retornarem a data e hora atual.
SELECT CURRENT_DATE();
ou
SELECT CURDATE();
Retornará à data atual. Por exemplo: - - (no formato ano-mês-dia).
SELECT CURRENT_TIME();
ou
SELECT CURTIME();
Retornará à hora atual. Por exemplo: : : .
Função Date_Format() e Time_Format() para alterar o formato da data e
hora. É possível combinar funções:
SELECT DATE_FORMAT(‘2001/02/18’,’%d/%m/%Y’);
Retornará: 18-2-2001.
SELECT DATE_FORMAT(CURDATE(),’%d/%m/%y’);
Retornará à data atual. Por exemplo: 21-3-2019.
SELECT DATE_FORMAT(CURDATE(),’%D/%M/%Y’);
Retornará: 21st/março/2019 (por exemplo).
SELECT DATE_FORMAT(CURDATE(),’%W - %D /%M /%Y’);
Retornará: uinta st março (por exemplo).
SELECT DATE_FORMAT(CURDATE(),’%W - %D /%M /%Y - %j dias corridos’);
Retornará: uinta - st março - dias corridos.
SELECT DATE_FORMAT(CURTIME(),’%h: %i: %s ‘);
ou
SELECT TIME_FORMAT(CURTIME(),’%h: %i: %s ‘);
Retornará: 12:26:40 (exemplo de hora atual).
Os parâmetros %d, %m e retornam a data em formato mais simples e com-
pacto, com dia, mês e ano em formato de dois dígitos, diferentemente de W, D, M,
Y e j, que são mais completos. Uma combinação e ordem entre eles pode ser usa-
da. Perceba que %W e %j mostram o dia da semana e o número de dias passados
no ano. Se os meses do ano estiverem em inglês, pode-se usar o comando SET
lc time names pt para visualizar as datas no formato português brasilei-
ro. Um resumo de alguns desses parâmetros pode ser visto na Tabela 1
BANCO DE DADOS 82

QUADRO 1. COMPETÊNCIAS PARA O PROFISSIONAL
Parâmetros
%d Dia do mês numérico (00 a 31)
%D Dia do mês com sufixo em inglês
%m Mês numérico (00 a 12)
%M Nome do mês
%y Ano numérico em dois dígitos
%Y Ano com quatro dígitos
%W Nome do dia da semana
%j Dias corridos no ano
%h Horas
%i Minutos
%s Segundos
Vejamos outras funções úteis para manipulação de dados e horas.

O comando a seguir acrescentará n dias, meses ou anos na data atual ou ou-
tra qualquer e mostrará a data encontrada. Se você desejar, poderá acrescentar
a função Date_format para trabalhar no formato dia-mês-ano.
SELECT DATE_ADD(CURDATE(), INTERVAL 30 DAY);
ou
SELECT DATE_ADD(‘2019-03-21’, INTERVAL 30 DAY);
Retornará: uma data 30 dias à frente da atual. Exemplo: 20-4-2019.
SELECT DATE_ADD(CURDATE(), INTERVAL 2 MONTH);
Retornará: uma data dois meses à frente da atual. Exemplo: 21-5-2019.
SELECT DATE_ADD(CURDATE(), INTERVAL 2 YEAR);
Retornará: uma data 3 anos à frente da atual. Exemplo: 21-3-2022.
O comando a seguir mostra a diferença entre duas datas, ou seja, quantos
dias passaram entre elas.
SELECT DATEDIFF(‘2019-03-21’, ‘2019-02-21’);
Retornará: dias corridos entre as duas datas.
SELECT DAYOFYEAR(‘2019-03-21’);
Retornará: 80 dias corridos desde o início do ano de 2019 até 21-3.
SELECT PERIOD_DIFF(‘201910’, ‘201708’);
Retornará: meses entre agosto de 2017 e outubro de 2019.
BANCO DE DADOS 83

Manipulação de dados alfanuméricos
A Linguagem SQL possui uma série de comandos para manipular dados alfa-
numéricos. Vamos destacar apenas dois, que podem ser adotados em combina-
ção com várias consultas realizadas no banco de dados onde os dados possam
não estar padronizados. A manipulação de dados numéricos será abordada
mais adiante, no tópico sobre funções de grupo. Os comandos a seguir conver-
tem letras maiúsculas em minúsculas e vice-versa.
SELECT LCASE (‘BANCO DE DADOS’);
Retornará: banco de dados.
SELECT UPPER(‘banco de dados’);
Retornará: BANCO DE DADOS.
Exibindo dados de várias tabelas

Para exibir dados de várias tabelas em um só comando, precisamos tomar
alguns cuidados, caso contrário poderão aparecer vários registros múltiplos ou
em duplicidades. Vejamos cada tabela separadamente, depois juntas e, poste-
riormente, com uma união regular, com os dados filtrados e sem repetições.
A Figura 9 apresenta as duas tabelas separadamente. Perceba que foi dado
um comando SELECT para cada tabela. A tabela aluno possui oito registros, e
a tabela curso, quatro.
igura . Dados separados em cada tabela.
BANCO DE DADOS 84

Já a Figura 10 demonstra o uso equivocado do comando SELECT, adicionan-
do as duas tabelas no mesmo comando, ou seja, SELECT * FROM aluno, curso;.
Figura 10. Uso equivocado do comando SELECT com duas tabelas.
O impacto desse comando equivocado é a exibição de uma relação de 32

registros, conforme a Figura 10, pois houve a replicação dos registros de ambas
as tabelas na proporção de 8 para 4, ou seja, para cada aluno encontrado na
tabela aluno, foram mostrados 4 cursos da tabela curso repetidos e vice-versa,
totalizando 32 registros.
Mas qual a forma correta para representar os dados de ambas as tabelas?
Para responder essa pergunta, devemos antes observar se tais tabelas pos-
suem campos em comum. Do contrário haverá sempre essa replicação em n
vezes os registros das tabelas envolvidas.
Ambas as tabelas possuem um campo com o código do curso, logo, estão
relacionadas. Devemos então aplicar essa informação ao comando SELECT
para que a consulta seja produtiva e só traga, por exemplo, cursos que tenham
alunos ou alunos que estejam em algum curso. Para isso, acrescentaremos os
parâmetros WHERE ou JOIN ou, ainda, uma combinação dos dois. Exemplo:
BANCO DE DADOS 85

SELECT * FROM aluno, curso WHERE aluno.Cod_Curso=curso.cod_curso;
O retorno desse comando pode ser visto na Figura 11. Perceba que agora
não houve repetições e que o curso Engenharia não foi mostrado, pois ne-
nhum aluno possui o código desse curso cadastrado. O parâmetro WHERE
significa “onde”, ou seja, mostra apenas dados “onde” os códigos dos cursos
coincidem em ambas as tabelas.
Figura 11. Retorno dos dados das duas tabelas combinadas, relacionadas por Cod_curso.
Para refinar ainda mais essa consulta, é possível escolher apenas os campos
que desejamos, sem inserir campos desnecessários ou repetidos como Cod_
Curso, que aparece duas vezes, pois está em ambas as tabelas. Podemos ainda
renomear uma coluna para um melhor entendimento dos dados. Na Figura
12, que aparecerá nos parágrafos a seguir, perceba que aparecem apenas os
campos desejados e uma coluna renomeada para AREA_do_Curso. O coman-
do responsável é:
SELECT RM, aluno.Nome, aluno.Cod_curso, curso.Nome AS AREA_do_Curso
FROM aluno, curso WHERE aluno.Cod_Curso = curso.cod_curso;
Perceba que após o SELECT é possível selecionar os atributos que deseja-
mos listar. Contudo, atributos com nomes ambíguos devem ser precedidos do
nome da tabela seguidos de um ponto, como aluno.Nome, para diferenciá-los,
já que existe o campo “nome” em ambas as tabelas e, nesse caso, o “nome” na
tabela de alunos não tem nada a ver com o “nome” da tabela de cursos; um é
do aluno, o outro é do curso. No entanto, o atributo Cod_Curso da tabela de
alunos e Cod_curso da tabela de cursos possuem nomes semelhantes, mas os
conteúdos precisam refletir o mesmo interesse para que haja um relaciona-
mento entre as tabelas. A letra “C” de curso está diferente em cada tabela, mas
BANCO DE DADOS 86

aqui elas são tratadas como iguais. Em alguns SGBDs ou sistemas operacionais,
como o Linux, podem ser entendidos como nomes diferentes, sendo desneces-
sário ser precedido pelo nome da tabela, mas em todos os casos o que importa
são os conteúdos de cada campo relacionado, que devem ser compatíveis.
Note que o parâmetro AS (que significa “como” em inglês) substituiu o nome
da coluna curso.Nome por ÁREA_do_Curso (Figura 12). Isso é opcional e pode-
ria ter sido feito para todas as colunas. É apenas um procedimento visual, não
impactando na estrutura das tabelas.
igura . Consulta com seleção de colunas e mudança visual do nome de coluna.
Vejamos agora como melhorar a forma de consultar e visualizar múltiplas ta-

belas com os parâmetros JOIN e suas variações: JOIN ou INNER JOIN, LEFT JOIN e
RIGHT JOIN. Com esses parâmetros, podemos decidir se desejamos ver todos os
dados das duas tabelas, ou de uma sim e da outra não, baseados sempre na coin-
cidência entre atributos pares ou entre chaves primárias e estrangeiras de cada
tabela que se relaciona. Na sequência, um exemplo de comando para cada tipo:
SELECT * FROM aluno INNER JOIN curso ON aluno.cod_curso=curso.cod_
curso;
INNER JOIN. O SELECT mostrará os dados apenas se

I os campos relacionados de ambas as tabelas coincidi-
rem, conforme ilustra a Figura 13.
BANCO DE DADOS 87

igura . Consulta com INNER JOIN entre tabelas relacionadas.
SELECT * FROM aluno LEFT JOIN curso ON aluno.cod_curso=curso.cod_

curso;
LEFT JOIN. O SELECT mostrará todos os dados da tabela

L
à esquerda do comando e só os dados da tabela da direita
que coincidirem com ela, conforme ilustra a Figura 14.
Figura 14. Consulta com LEFT JOIN entre tabelas relacionadas.
SELECT * FROM aluno RIGHT JOIN curso ON aluno.cod_curso=curso.cod_

curso;
RIGHT JOIN. O SELECT mostrará todos os dados da tabe-

R
la à direita do comando e só os dados da tabela da esquerda
que coincidirem com ela, conforme ilustra a Figura 15.
BANCO DE DADOS 88

Figura 15. Consulta com RIGHT JOIN entre tabelas relacionadas.
Perceba que, no LEFT JOIN e RIGHT JOIN, quando não há dados da tabela
preterida pelos comandos, aparece o NULL nas colunas, informando que não
há dados para serem exibidos. Veja que os dois comandos possibilitaram ver
que a aluna Rafaela Silva, RM 90, não está matriculada em nenhum curso loca-
lizado na tabela de cursos, e o curso engenharia não possui nenhum aluno re-
gistrado. Pode-se combinar os parâmetros JOIN e WHERE para criar consultas
mais elaboradas. Veja os exemplos a seguir.
No comando seguinte, apenas cursos com valor superior a 2.700 serão mos-
trados nas tabelas relacionadas:
SELECT * FROM aluno INNER JOIN curso on aluno.cod_curso=curso.cod_
curso WHERE valor > 2700;
Já no comando a seguir, apenas cursos começados com as letras E ou I serão
mostrados:
SELECT * FROM aluno INNER JOIN curso on aluno.cod_curso=curso.cod_
curso WHERE curso.nome LIKE ( ) OR curso.nome LIKE ( );
A função do parâmetro LIKE e do % é justamente permitir comparações
entre uma sequência de strings, ou seja, valores alfanuméricos. Use apóstrofe,
não acento agudo.
Agregando dados com funções de grupo

Função de agregação processa um conjunto de valores contidos nas co-
lunas de uma tabela e retorna um valor como resultado. Podemos também
criar consultas agrupando os registros segundo alguma categoria determi-
nada no próprio comando SELECT. Vejamos alguns exemplos.
BANCO DE DADOS 89

Tendo uma tabela com um campo de valores numéricos, podemos pesqui-
sar qual o valor menor, o maior, a média, soma ou ainda a contagem de valores
contidos nesta coluna. Para esse último, não apenas para valores numéricos.
Essas e outras operações são possíveis através de funções matemáticas. Veja-
mos então operações com as funções MIN(), MAX(), AVG(), COUNT() e SUM()
na sequência.
Considere a tabela curso pertencente à base de dados biblioteca, que foi
devidamente acessada, conforme ilustra a Figura 16, onde são mostrados to-
dos os cursos cadastrados com o comando SELECT.
igura . Tabela curso com uma coluna de valores.
Note que a coluna valor possui valores diferentes. Vamos utilizar os coman-
dos citados para recuperar os dados conforme a designação de cada um.
[destacar na diagramação]
SELECT MIN(Valor) FROM curso;
Retornará: , pois corresponde ao menor valor encontrado na tabela.
SELECT MAX(Valor) FROM curso;
Retornará: , pois corresponde ao maior valor encontrado na tabela.
SELECT AVG(Valor) FROM curso;
Retornará: , pois corresponde à média de valores encontrados na
tabela.
SELECT COUNT(Valor) FROM curso;
Retornará: 4 valores encontrados, que correspondem a 4 registros cadastrados.
BANCO DE DADOS 90

Executando o comando COUNT, os outros só poderão ser usados em atri-
butos numéricos. Se quiséssemos saber quantos alunos estão matriculados no
curso de produção (código do curso – 204030), poderíamos aplicar o seguinte
comando:
SELECT COUNT(nome) FROM aluno WHERE cod_curso=204030;
Retornará: , que é o número de alunos matriculados no curso.
No lugar do nome, podemos colocar qualquer campo da tabela ou um *, ou
seja, COUNT(*). Já uma função que some todos os valores dos cursos cadas-
trados pode ser:
SELECT SUM(Valor) FROM curso;
Retornará: , de acordo com os valores da Figura 16.
Vejamos agora um exemplo com agrupamento de dados. Pode-se criar gru-
pos para melhor representar os dados, realizando inclusive operações mate-
máticas separadamente, de acordo com sua categoria.
SELECT cod_curso, COUNT(*) FROM aluno GROUP BY cod_curso;
A resposta para essa consulta será apresentar todos os códigos de cursos
em que haja aluno matriculado, seguido do total de aluno em cada curso, con-
forme pode ser visto na Figura 17. O parâmetro GROUP BY é muito útil quando
se deseja contabilizar ou simplesmente agrupar ocorrências em comum em
uma determinada tabela, como vendas do mesmo vendedor, por região ou por
produtos, funcionários do mesmo departamento, entre outras situações.
igura . Tabela agrupada e totalizada de acordo com o curso.
BANCO DE DADOS 91

Como uma variação a esse comando, pode-se ainda controlar o que será
exibido e determinar, por exemplo, que sejam apresentados apenas totais aci-
ma de um certo valor, o que pode ser feito com o parâmetro HAVING; por
exemplo, visualizar apenas cursos com mais de dois alunos matriculados. Veja
o comando a seguir:
SELECT cod_curso, COUNT(*) FROM aluno GROUP BY cod_curso HAVING
COUNT(*) ;
Como resposta a esse comando, o total de alunos no curso 204020 apresen-
tado na Figura 17 não será mais exibido, pois sua quantidade é inferior ao deter-
minado pelo parâmetro HAVING.
Usando subconsultas de dados

Quando necessitamos de referência para uma consulta que dependa de
outra consulta, adotamos o recurso da subconsulta. No exemplo a seguir, se-
lecionaremos apenas cursos e valores maiores que a média geral de preços de
todos os cursos. Nesse caso, a consulta e a subconsulta são realizadas apenas
com a própria tabela curso.
SELECT Nome, valor FROM curso WHERE valor > (SELECT AVG(valor) FROM
curso);
Perceba que o segundo SELECT retornará à média de valores de todos os
cursos e o primeiro, então, só trará cursos quando seu valor for maior que a
média encontrada no segundo SELECT, como pode ser visto na Figura 18.
Figura 18. Exemplo de uso de subconsulta para auxiliar na consulta principal.
BANCO DE DADOS 92

No exemplo a seguir, o parâmetro UNION permite a união de dois ou mais SE-
LECTs, possibilitando várias consultas com filtros diferentes, que se transformam
em uma só consulta,usando a mesma tabela ou várias tabelas semelhantes com
as mesmas estruturas e características que se completam. O resultado retornado
com o comando seguinte é semelhante a uma consulta simples (Figura 18).
SELECT * FROM aluno WHERE cod_curso=204050 UNION (SELECT * FROM
aluno WHERE cod_curso=204030);
Observe que, em vez de usar UNION e o segundo SELECT, como se trata
da mesma tabela, poderia ser usado OR cod_curso=204030, mas isso não se-
ria uma subconsulta. Para ficar mais claro, no exemplo a seguir faremos um
UNION com duas tabelas distintas.
No exemplo que se segue, os códigos dos cursos iniciados com o número
3 pertencem à tabela curso livre; os demais, à tabela curso (Figura 19). Veja a
consulta resultante (Figura 20), obtida com o seguinte comando:
SELECT * FROM curso WHERE valor >= 2700 UNION (SELECT * FROM curso-
livre WHERE preco > 3500);
Nesse exemplo, foram exibidos apenas os cursos com valor maior ou igual
a 2.700 da tabela curso e cursos com preço superior a 3500 da tabela curso
livre. Note que os atributos e dados de ambas as tabelas são semelhantes, mas
obviamente apenas os dados diferentes, que satisfaçam as condições impos-
tas nas consultas, são mostrados. Dados iguais não são repetidos.
igura . Demonstração de duas tabelas semelhantes.
BANCO DE DADOS 93

Perceba que nem todos os dados de ambas as tabelas foram listados, pois
não faziam parte das condições impostas.
igura . Consulta resultante da união entre as duas tabelas.
BANCO DE DADOS 94

Sintetizando
Caro aluno, nesse capítulo iniciamos os estudos sobre a Linguagem SQL e a
operação de um sistema gerenciador de banco de dados. Abordamos o histó-
rico da linguagem, sua estrutura, suas versões, diferentes desenvolvedores e a
utilização do SGBD MariaDB, baseado no MySQL.
Foi possível constatar o que é produzido do projeto lógico para o físico. Ma-
nipulamos bases de dados diretamente do SGBD, acessamos a base biblioteca
e as tabelas aluno, curso e curso livre, onde se pôde consultar dados de dife-
rentes formas com grande variedade de comandos SQL para consultas.
Além das consultas mais simples, foi possível avançar para consultas mais
sofisticadas, ao se estabelecer restrições e ordenação dos dados com o uso de
diferentes tabelas, sem contar o emprego das funções para transformar dados
e grupos, como também exemplificar e experimentar o recurso de subconsul-
tas para tratar melhor os dados pesquisados.
Podemos concluir que o capítulo trouxe uma abordagem em detalhes dos
tipos de consultas que podemos realizar em bases de dados mantidas por
SGBD por intermédio da Linguagem SQL. Esperamos que você tenha aproveita-
do cada conteúdo abordado, testado cada comando e adquirido familiaridade
com a Linguagem SQL.
Bons estudos e até a próxima!
BANCO DE DADOS 95

Elsevier, 2003.
Addison-Wesley, 2011.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
v. 4
INTERNATIONAL ORGANIZATION FOR STANDARDIZATON –
- : . Geneva: ISO, 2019. Disponível em:
<https://www.iso.org/standard/67367.html>. Acesso em: 17 mar. 2019.
MARIADB FOUNDATION. MariaDB 10.4.3 RC. Espoo: MariaDB Foundation,
2019. Disponível em:
<https://downloads.mariadb.org/mariadb/10.4.3/>. Acesso em: 18 mar. 2019.
BANCO DE DADOS 96

UNIDADE
4 IMPLANTAÇÃO DE
BANCOS DE DADOS
RELACIONAIS

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 alte- Criando sequências
rando dados Criando índices
Criando e manipulando Tecnologias emergentes para
nções tabelas bancos de dados
Criação das tabelas Banco de dados não relacional
e Inserindo dados nas tabelas e suas aplicações
Copiando dados e gerando Banco de dados orientado a
nova tabela a partir de uma objetos e suas aplicações
existente
Alterando dados da tabela Segurança em banco de dados
Eliminando dados da tabela Definição de perfis de usuário
Alterando a estrutura da (roles)
tabela Ataques típicos em bancos de
dados (SQL injection e outros)
Incluindo restrições de dados Soluções de segurança para
em tabelas bancos de dados
Criando visões de dados
BANCO DE DADOS 98

Inserindo, eliminando e alterando dados
Olá, aluno! Nesta unidade iremos continuar com os estudos sobre a Lingua-
gem 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, con-
sulta 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 coman-
dos. Caso você ainda não o tenha, acesse o link disponível nas referências bi-
bliográ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 du-
rante 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
A Figura 1 apresenta todo o processo de autenticação no SGBD.
Figura 1. Autenticação para acessar o MySQL.
BANCO DE DADOS 99

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â-
uma melhor leitura e entendimento do comando. Os nomes das bases de da-
dos 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;
Lembre-se que sempre nos finais de comandos devemos colocar um pon-
to-e-vírgula: “;”.
Figura 2. Resposta ao comando SHOW DATABASES;
BANCO DE DADOS 100

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 funcio-
nalidades 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 referen-
ciarmos 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_Ven-
das, mas, como o MySQL normalmente converterá o nome das bases de dados
para minúsculo, vamos então 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;
Após esse comando, se você der outro comando SHOW DATABASES, verá
que sua base de dados foi adicionada. Assim que essa base de dados já tiver
algumas tabelas criadas, você poderia usar o comando SHOW TABLES para
visualizá-las. Vamos aproveitar e ver algumas das facilidades que o comando
SHOW pode nos trazer:
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 dados, basta apenas dar
um comando USE e o nome da outra base.
BANCO DE DADOS 101

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 atribu-
tos, com suas características entre parênteses. Exemplo:
CREATE TABLE nome da tabela (lista de atributos que compõem a tabela);
DIAGRAMA 1. MODELO LÓGICO DO BANCO DE DADOS

QUE SERÁ IMPLANTADO
(1,1)
Clientes
Cod_oli: INTEGER
Nome: VARCHAR
Endereço: VARCHAR
Telefone: VARCHAR
Vendas
Produto
(1,1)
(0,n) NF: INTEGER
Cod_pro: INTEGER
Cod_Cli: INTEGER
Descrição: VARCHAR
Cod_Pro: INTEGER
Valor_unitário: DOUBLE (1,n)
Data_venda: DATA
Cod_Fornecedor: INTEGER (0,1) Valor_venda: DOUBLE
Data_cadastro: DATE
Vendedor: VARCHAR
Região: VARCHAR
(1,n)
Fornecedor
Cod_for: INTEGER
Contato: VARCHAR
Endereço: VARCHAR
Telefone: VARCHAR
BANCO DE DADOS 102

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, é reco-
mendá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 per-
mite que você copie e cole tudo de uma vez, mas isso é um recurso de produtivida-
de 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.
Figura 3. Exemplo de scripts criados a partir do modelo lógico por ferramenta CASE.
BANCO DE DADOS 103

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ó exe-
cutará 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 ire-
mos 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),
);
/* Tabela Produto */
CREATE TABLE Produto (
Cod_pro INTEGER PRIMARY KEY,
Descricao VARCHAR (50),
Valor_unitario DOUBLE (6,2),
Cod_Fornecedor INTEGER,
Data_cadastro DATE
);
CREATE TABLE Vendas (
NF INTEGER PRIMARY KEY,
Cod_Cli INTEGER,
Cod_Pro INTEGER,
BANCO DE DADOS 104

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-cha-
ve. 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 DES-
CRIBE 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 */
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
BANCO DE DADOS 105

(10, “João Santos”, “Al. Gomes, 50 – Bom Retiro/SP”,”11-3456-7899”);
Podemos ainda, em um único comando, adicionar vários registros da se-
guinte forma:
(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 inserindo cada regis-
tro e alternar com o comando SELECT * from cliente para observar a tabela,
sendo populada gradativamente, como pode ser visto na Figura 4.
Figura 4. Dados inseridos na tabela Cliente.
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”);
BANCO DE DADOS 106

Figura 5. Dados inseridos na tabela Fornecedor.
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.
Figura 6. Dados inseridos na tabela Produto.
BANCO DE DADOS 107

Inserindo dados na tabela Vendas:
INSERT INTO Vendas(NF, Cod_Cli, Cod_Pro, Data_venda, Valor_venda, Vende-
dor, 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.
Figura 7. Dados inseridos na tabela de vendas.
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 VendasCo-
pia, com todos os atributos e dados da tabela de origem. Mas muitas vezes dese-
jamos 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 Figura 8,
onde apenas três atributos foram escolhidos para compor a tabela VendasRegiao:
BANCO DE DADOS 108

CREATE TABLE VendasRegiao SELECT NF, Regiao, Data_venda FROM Vendas;
Perceba que será criada uma tabela idêntica à Vendas, com o nome Vendas-
Copia, com todos os atributos e dados da tabela de origem. Mas muitas vezes
desejamos escolher apenas alguns campos que queremos para uma nova ta-
bela e em ordem diferente das colunas. Veja o exemplo a seguir e seu resultado
na Figura 8, onde apenas três atributos foram escolhidos para compor a tabela
VendasRegiao:
CREATE TABLE VendasRegiao SELECT NF,Regiao, Data_venda FROM Vendas;
Figura 8. Dados inseridos na tabela de Vendas.
A partir desse ponto, como veremos comandos que alterarão dados e es-
truturas 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

É possível alterar dados da tabela com o comando UPDATE. Muito cuida-
do com esse comando! Se você esquecer de estabelecer uma condição com
o parâmetro WHERE, ele poderá trocar TODOS os dados de um determinado
campo que você tenha informado. Seu formato genérico é:
UPDATE nome da tabela SET campo a alterar = novo conteúdo WHERE cam-
po-chave ou outro = dado existente;
BANCO DE DADOS 109

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 dese-
jamos 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;
Obviamente, é aconselhável você alternar esses comandos com o SELECT
para visualizar as mudanças na tabela. Na Figura 8, é possível ver como ficou a
tabela Vendas depois desses últimos comandos.
Figura 9. Dados inseridos na tabela Vendas.
Eliminando dados da tabela

Podemos excluir um ou um grupo de registros permanentemente da tabela
com o comando DELETE. De igual modo, devemos tomar o máximo de cuidado
com esse comando para não excluir dados importantes por desatenção. Nunca
se esqueça de estabelecer uma condição com o parâmetro WHERE para ter
certeza do que será excluído; caso contrário, TODOS os dados da tabela serão
descartados permanentemente. Seu formato genérico é:
BANCO DE DADOS 110

DELETE from nome da tabela WHERE campo-chave = condição;
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 le-
tras 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;
O exemplo a seguir trocará o tipo do campo para INTEGER, se este for com-
patí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, tro-
cando 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;
BANCO DE DADOS 111

INSERT INTO Vendas(NF, Cod_Cli, Cod_Pro, Data_venda, Valor_venda, Ven-
dedor, 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 Fornecedor e Cliente. Conceitualmente falando,
Produto e Vendas são entidades “fracas”, pois dependem das entidades Forne-
cedor 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 cadastra-
dos 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 tabe-
las “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 For-
necedor. 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 ta-
bela 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.
BANCO DE DADOS 112

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).
Produto (Cod_pro, Descricao, Valor_unitario, fk_Cod_Fornecedor,
Data_cadastro).
Vendas (NF, fk_Cod_Cli, fk_Cod_Pro, Data_venda, Valor_venda, Vende-
dor, 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 des-
tacar 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 For-
necedor. 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 ne-
cessá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 pro-
duto 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, apli-
car restrição. Segue o formato genérico 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);
BANCO DE DADOS 113

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 re-
ferê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 per-
mitirã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 fornece-
dor, 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 FO-
REIGN KEY (Cod_Fornecedor) REFERENCES Fornecedor (Cod_for);
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, de-
pendendo dos parâmetros, acaba afetando também a
entidade_forte (ou pai) Fornecedor.
BANCO DE DADOS 114

DICA
Tente cadastrar um produto sem um fornecedor válido para ver a restrição
atuando. Tente também excluir um fornecedor que esteja se relacionando
com algum produto e verá que não será possível. Agora, se excluir primei-
ro um produto, então conseguirá também excluir o referido fornecedor.
Faça os testes antes de prosseguir.
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 compor-
tamento 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 fornece-
dor for excluído da tabela, todos os produtos com esse fornecedor serão tam-
bém automaticamente excluídos. Isso é uma restrição parcial, já que permite
alguns ajustes. Vejamos:
Fornecedor) REFERENCES Fornecedor (Cod_for) ON DELETE CASCADE ON UP-
DATE 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âme-
tros NO ACTION e CASCADE podem ser combinados. Exemplo:
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 deixan-
do as tabelas novamente independen-
tes, basta informar o nome da restrição
(nome do índice) com o comando:
ALTER TABLE Produto DROP
CONSTRAINT fk_Pro_For;
BANCO DE DADOS 115

Visão de 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 otimi-
zada dos dados, sem ter que reescrever comandos complexos de consultas.
Isso simplifica a interação entre usuário e banco de dados, pois ele pode reali-
zar 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 restrin-
gir 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 = produ-
to.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;
BANCO DE DADOS 116

Criando sequências
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 ex-
terno à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.
CREATE SEQUENCE objeto_sequencial START WITH valor inicial INCRE-
MENT 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;
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 volumo-
sos 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.
BANCO DE DADOS 117

dor, 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”);

existente
BANCO DE DADOS 108

VendasRegiao:

BANCO DE DADOS 109

Exemplo:

BANCO DE DADOS 110

tabela Cliente2.

serão perdidas.
BANCO DE DADOS 111

(500080,88,8888,“2019-02-20”, 340.25,”Pedro”,”Zona Norte”);

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 cadas-
trados livremente, sem a necessidade de verificação com outras tabelas.
BANCO DE DADOS 112

Data_cadastro).
dor, Regiao).
tabela Produto.
BANCO DE DADOS 113

Onde:
FK_Nome: é o nome da restrição criada. Para o SQL é um índice para faci-
litar 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.
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.
ou
UPDATE NO ACTION;
por padrão. Em outros SGBDs pode ser diferente. Tais parâmetros in-
formam o que será feito quando um registro for excluído ou alterado
na tabela-pai, ou seja, a tabela de referência no relaciona-
mento. 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 fi-
lha) Produto, mas, dependendo dos parâmetros, acaba
BANCO DE DADOS 114

DICA
afetando também a entidade_forte (ou pai) Fornecedor.

DATE CASCADE;
UPDATE CASCADE;
(CASCADE), ou seja, se mudar o código
do fornecedor na tabela Fornecedor, o
mesmo ocorre na tabela Produto e vi-
ce-versa.
BANCO DE DADOS 115

como:
NORTE”);
ou
BANCO DE DADOS 116

Criando sequências
MENT BY incremento;
Criando índices
mais facilidade.
BANCO DE DADOS 117

Ao executarmos uma consulta com o comando SE-
LECT, onde são filtrados por um ou vários campos, o ge-
renciador 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 des-
considerados. 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 é ex-
plicitado, 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 índi-
ces para colunas que realmente são frequentemente acessadas para filtrar as
pesquisas nas consultas, pois podem causar um esforço maior e sobrecarga
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)
);
BANCO DE DADOS 118

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 rapida-
mente 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 ne-
cessidades 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 de-
sestruturadas, em várias áreas do conhecimento, sempre apareceram barrei-
ras nos modelos engessados dos bancos de dados relacionais, mas agora po-
dem se beneficiar da potencialidade dos não relacionais.
No segmento dos bancos de dados, vimos que ao longo da história, vários ti-
pos de bancos de dados surgiram, no entanto, ainda hoje o banco de dados rela-
cional é 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 estru-
turaçã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 disponibili-
zados de forma distribuída, provendo várias soluções e aplicações, principal-
mente no universo da internet. Elmasri e Navathe (2011) nominam esse tipo
BANCO DE DADOS 119

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 ban-
cos 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 manipu-
laçã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:
CURIOSIDADE
A capacidade de consulta distribuída do SQL Server permite consultas e
atualizações transacionais em várias fontes relacionais e não relacionais
de provedores de dados OLE-DB, sendo executado em um ou mais compu-
tadores (SILBERSC AT ; ORT ; SUDARS AN, ).
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 semiestru-
turado, 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 exem-
plo típico é um documento de texto e comando de marcação que contém infor-
maçã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 limi-
taçõ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-re-
lacionamento (ELMASRI; NAVATHE, 2011).
BANCO DE DADOS 120

Para Silberschatz, Korth e Sudarshan (1999), os principais fornecedo-
res de banco de dados suportam o modelo de dados 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, pre-
senç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 ma-
nufacturing (CAM), sistemas para a área científica e médica, sistemas de infor-
maçã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 dife-
rentes 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, tan-
to no aspecto físico e geográfico de suas instalações como no controle de aces-
so, seja in loco ou remotamente.
Dados armazenados em bancos de dados estão além da preser-
vação e proteção física dos dados em si, mas principalmente da
manutenção constante do sigilo da informação que eles
trazem consigo. Dados como contas bancárias, senhas,
endereços, telefones de clientes e informações fi-
nanceiras merecem um cuidado especial, e seus
acessos precisam ser controlados e até ocultados
da maioria dos usuários do banco de dados.
BANCO DE DADOS 121

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 worksta-
tion 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, de-
pendendo 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.
A sintaxe geral do comando para criar usuário é:
CREATE USER nome_do_usuário@host_do_usuário IDENTIFIED BY senha_
do_usuário;
Exemplo:
CREATE USER renatoaf IDENTIFIED BY ‘sen0701’;
ou
CREATE USER renatoaf@localhost
IDENTIFIED BY ‘sen0701’;
Agora, para dar “privilégio” total de
acesso ao usuário para uma base de
dados específica:
GRANT ALL PRIVILEGES ON Con-
trole_de_vendas.* TO renatoaf;
Para criar um usuário local e deter-
minar qual tabela e quais campos po-
derá acessar:
BANCO DE DADOS 122

GRANT SELECT (Nome,Valor) ON biblioteca.Curso TO lukinhas@localhost
IDENTIFIED BY “lucas”;
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:
REVOKE SELECT (Nome, Valor) ON biblioteca.Curso FROM lukinhas@loca-
lhost;
ou
REVOKE SELECT ON biblioteca.Curso FROM lukinhas@localhost;
Para ver todos os usuários criados no banco de dados:
SELECT HOST,USER FROM MYSQL.USER;
Para ver “privilégios” dos usuários e o que eles podem acessar:
SHOW GRANTS FOR renatoaf@localhost;
Ataques típicos em bancos de dados (SQL injection e

outros)
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 autori-
zadas ou mal-intencionadas em campos de entrada, normalmente de apli-
caçõ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á con-
ceder 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 tecno-
logia 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.
BANCO DE DADOS 123

No caso de SQL injection, a vulnerabilidade pode ocorrer, por exemplo, quan-
do 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 da-
dos, simplesmente não existe. Há sempre possibilidades e vulnerabilidades
que devem ser controladas e vigiadas constantemente. Aspectos internos, ex-
ternos, humanos e cibernéticos estão em constantes transformações e pro-
pensas a riscos. Logo, a vigilância e a busca pela solução ideal devem ser incan-
sáveis e permanentes.
As ameaças são várias, e algumas boas práticas podem e devem ser adota-
das. Entre elas, pode-se destacar:
• Implantar políticas de segurança em TI;
• Evitar concessão de privilégios de acesso excessivos para posteriormente
ficarem desatualizados e cair no esquecimento dos administradores;
• Prevenir abusos de privilégios e uso inconsequente por maus profissionais;
• Realizar testes manuais, por intermédio de ferramentas específicas direta-
mente nas aplicações do usuário para atestar a vulnerabilidade, como SQL-
Map, jSQL Injection, entre outras;
• Manter o banco de dados em um servidor exclusivo, com acesso físico e
lógico protegido de intrusão;
• Prevenir o ambiente contra malwares;
• Realizar auditorias com frequência;
• Implantar política de backups eficientes;
• 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 classifi-
car como absoluta e definitiva. Quando o assunto é segurança de dados, todo
cuidado é pouco.
BANCO DE DADOS 124

Sintetizando
Caro aluno nesse capítulo, completamos os estudos sobre a Linguagem
SQL. Vários comandos importantes e essenciais foram exemplificados e prati-
cados 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 ban-
co de dados MariaDB. Criamos e manipulamos a base Controle_de_Vendas e
suas tabelas Clientes, Produtos, Fornecedor e Vendas, com variedades de ti-
pos de campos, onde se pôde gerenciar dados de diferentes formas, com gran-
de variedade de comandos SQL.
Além dos comandos elementares e essenciais, foi possível abordar ques-
tões mais sofisticadas ao avançar e estabelecer restrições maiores ao manu-
seio 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, apresenta-
ram-se tendências e conceitos de banco de dados não relacionais e suas apli-
cações, assim como do banco de dados orientado a objetos e suas aplicações.
Em segurança em banco de dados, foram abordados aspectos importan-
tes, 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.
principais comandos SQL e aspectos relevantes no universo dos bancos de da-
dos de uma forma geral.
Esperamos que você tenha aproveitado cada conteúdo abordado, testado
cada comando e adquirido maior familiaridade com a Linguagem SQL.
BANCO DE DADOS 125

CHAUDRI, A. B.; ZICARI, R. Succeeding with object databases: a practical look
at today’s implementations with Java and XML. Hoboken: Wiley Computer Pu-
blishing, 2001.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro.
Elsevier, 2003.
DB-ENGINES. Knowledge base of relational and Nosql database manage-
ment. [S.l.]: [s.d.]. Disponível em: <https://Systemshttps://db-engines.com/en/
ranking>. Acesso em: 21 fev. 2019.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009. v. 4.
MARIADB FOUNDATION. MariaDB 10.4.3. RC. [S.l.]: 2019. Disponível em:
MULLER, J. R. Projeto de banco de dados: usando UML para modelagem de
dados. 1. ed. São Paulo: Berkeley, 2002.
PROJETO BRmodelo 3.2. Sis4, [S.l.], 2018. Disponível em: <http://www.sis4.
com/brModelo/>. Acesso em: 24 fev. 2019.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados.
BANCO DE DADOS 126

UNIDADE
4 IMPLANTAÇÃO DE
BANCOS DE DADOS
RELACIONAIS
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 alte- Criando sequências
rando dados Criando índices
Criando e manipulando Tecnologias emergentes para
s tabelas bancos de dados
Criação das tabelas Banco de dados não relacional
Inserindo dados nas tabelas e suas aplicações
Copiando dados e gerando Banco de dados orientado a
nova tabela a partir de uma objetos e suas aplicações
existente
Alterando dados da tabela Segurança em banco de dados
Eliminando dados da tabela Definição de perfis de usuário
Alterando a estrutura da (roles)
tabela Ataques típicos em bancos de
dados (SQL injection e outros)
Incluindo restrições de dados Soluções de segurança para
em tabelas bancos de dados
BANCO DE DADOS 98
Inserindo, eliminando e alterando dados
Olá, aluno! Nesta unidade iremos continuar com os estudos sobre a Lingua-
gem 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, con-
sulta 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 coman-
dos. Caso você ainda não o tenha, acesse o link disponível nas referências bi-
bliográ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 du-
rante 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
A Figura 1 apresenta todo o processo de autenticação no SGBD.
Figura 1. Autenticação para acessar o MySQL.
BANCO DE DADOS 99
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â-
uma melhor leitura e entendimento do comando. Os nomes das bases de da-
dos 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;
Lembre-se que sempre nos finais de comandos devemos colocar um pon-
to-e-vírgula: “;”.
Figura 2. Resposta ao comando SHOW DATABASES;
BANCO DE DADOS 100

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 funcio-
nalidades 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 referen-
ciarmos 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_Ven-
das, mas, como o MySQL normalmente converterá o nome das bases de dados
para minúsculo, vamos então 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;
Após esse comando, se você der outro comando SHOW DATABASES, verá
que sua base de dados foi adicionada. Assim que essa base de dados já tiver
algumas tabelas criadas, você poderia usar o comando SHOW TABLES para
visualizá-las. Vamos aproveitar e ver algumas das facilidades que o comando
SHOW pode nos trazer:
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 dados, basta apenas dar
um comando USE e o nome da outra base.
BANCO DE DADOS 101

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 atribu-
tos, com suas características entre parênteses. Exemplo:
CREATE TABLE nome da tabela (lista de atributos que compõem a tabela);
DIAGRAMA 1. MODELO LÓGICO DO BANCO DE DADOS

QUE SERÁ IMPLANTADO
(1,1)
Clientes
Cod_oli: INTEGER
Nome: VARCHAR
Endereço: VARCHAR
Telefone: VARCHAR
Vendas
Produto
(1,1)
(0,n) NF: INTEGER
Cod_pro: INTEGER
Cod_Cli: INTEGER
Descrição: VARCHAR
Cod_Pro: INTEGER
Valor_unitário: DOUBLE (1,n)
Data_venda: DATA
Cod_Fornecedor: INTEGER (0,1) Valor_venda: DOUBLE
Data_cadastro: DATE
Vendedor: VARCHAR
Região: VARCHAR
(1,n)
Fornecedor
Cod_for: INTEGER
Contato: VARCHAR
Endereço: VARCHAR
Telefone: VARCHAR
BANCO DE DADOS 102

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, é reco-
mendá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 per-
mite que você copie e cole tudo de uma vez, mas isso é um recurso de produtivida-
de 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.
Figura 3. Exemplo de scripts criados a partir do modelo lógico por ferramenta CASE.
BANCO DE DADOS 103

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ó exe-
cutará 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 ire-
mos 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),
);
/* Tabela Fornecedor */
CREATE TABLE Fornecedor (
Cod_for INTEGER PRIMARY KEY,
Contato 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
);
CREATE TABLE Vendas (
NF INTEGER PRIMARY KEY,
Cod_Cli INTEGER,
Cod_Pro INTEGER,
BANCO DE DADOS 104

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-cha-
ve. 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 DES-
CRIBE 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 */
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:
BANCO DE DADOS 105

(10, “João Santos”, “Al. Gomes, 50 – Bom Retiro/SP”,”11-3456-7899”);
Podemos ainda, em um único comando, adicionar vários registros da se-
guinte forma:
(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 inserindo cada regis-
tro e alternar com o comando SELECT * from cliente para observar a tabela,
sendo populada gradativamente, como pode ser visto na Figura 4.
Figura 4. Dados inseridos na tabela Cliente.
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”);
BANCO DE DADOS 106

Figura 5. Dados inseridos na tabela Fornecedor.
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.
Figura 6. Dados inseridos na tabela Produto.
BANCO DE DADOS 107

dor, 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”);

existente
BANCO DE DADOS 108

VendasRegiao:

BANCO DE DADOS 109

Exemplo:

BANCO DE DADOS 110

tabela Cliente2.

serão perdidas.
BANCO DE DADOS 111

(500080,88,8888,“2019-02-20”, 340.25,”Pedro”,”Zona Norte”);

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 cadas-
trados livremente, sem a necessidade de verificação com outras tabelas.
BANCO DE DADOS 112

Data_cadastro).
dor, Regiao).
tabela Produto.
BANCO DE DADOS 113

Onde:
FK_Nome: é o nome da restrição criada. Para o SQL é um índice para faci-
litar 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.
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.
ou
UPDATE NO ACTION;
por padrão. Em outros SGBDs pode ser diferente. Tais parâmetros in-
formam o que será feito quando um registro for excluído ou alterado
na tabela-pai, ou seja, a tabela de referência no relaciona-
mento. 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 fi-
lha) Produto, mas, dependendo dos parâmetros, acaba
BANCO DE DADOS 114

DICA
afetando também a entidade_forte (ou pai) Fornecedor.
DATE CASCADE;
UPDATE CASCADE;
(CASCADE), ou seja, se mudar o código do fornecedor na tabela Fornecedor,
o mesmo ocorre na tabela Produto e
vice-versa.
ALTER TABLE Produto DROP
CONSTRAINT fk_Pro_For;
BANCO DE DADOS 115

como:
NORTE”);
ou
BANCO DE DADOS 116

Criando sequências
MENT BY incremento;
Criando índices
mais facilidade.
BANCO DE DADOS 117

Ao executarmos uma consulta com o comando SE-
LECT, onde são filtrados por um ou vários campos, o ge-
renciador 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 des-
considerados. 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 é ex-
plicitado, 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 índi-
ces para colunas que realmente são frequentemente acessadas para filtrar as
pesquisas nas consultas, pois podem causar um esforço maior e sobrecarga
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)
);
BANCO DE DADOS 118

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 rapida-
mente 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 ne-
cessidades 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 de-
sestruturadas, em várias áreas do conhecimento, sempre apareceram barrei-
ras nos modelos engessados dos bancos de dados relacionais, mas agora po-
dem se beneficiar da potencialidade dos não relacionais.
No segmento dos bancos de dados, vimos que ao longo da história, vários ti-
pos de bancos de dados surgiram, no entanto, ainda hoje o banco de dados rela-
cional é 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 estru-
turaçã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 disponibili-
zados de forma distribuída, provendo várias soluções e aplicações, principal-
mente no universo da internet. Elmasri e Navathe (2011) nominam esse tipo
BANCO DE DADOS 119

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 ban-
cos 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 manipu-
laçã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:
CURIOSIDADE
A capacidade de consulta distribuída do SQL Server permite consultas e
atualizações transacionais em várias fontes relacionais e não relacionais
de provedores de dados OLE-DB, sendo executado em um ou mais compu-
tadores (SILBERSC AT ; ORT ; SUDARS AN, ).
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 semiestru-
turado, 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 exem-
plo típico é um documento de texto e comando de marcação que contém infor-
maçã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 limi-
taçõ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-re-
lacionamento (ELMASRI; NAVATHE, 2011).
BANCO DE DADOS 120

Para Silberschatz, Korth e Sudarshan (1999), os principais fornecedo-
res de banco de dados suportam o modelo de dados 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, pre-
senç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 ma-
nufacturing (CAM), sistemas para a área científica e médica, sistemas de infor-
maçã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 dife-
rentes 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, tan-
to no aspecto físico e geográfico de suas instalações como no controle de aces-
so, seja in loco ou remotamente.
Dados armazenados em bancos de dados estão além da preser-
vação e proteção física dos dados em si, mas principalmente da
manutenção constante do sigilo da informação que eles
trazem consigo. Dados como contas bancárias, senhas,
endereços, telefones de clientes e informações fi-
nanceiras merecem um cuidado especial, e seus
acessos precisam ser controlados e até ocultados
da maioria dos usuários do banco de dados.
BANCO DE DADOS 121

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 worksta-
tion 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, de-
pendendo 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.
A sintaxe geral do comando para criar usuário é:
CREATE USER nome_do_usuário@host_do_usuário IDENTIFIED BY senha_
do_usuário;
Exemplo:
CREATE USER renatoaf IDENTIFIED BY ‘sen0701’;
ou
CREATE USER renatoaf@localhost
IDENTIFIED BY ‘sen0701’;
Agora, para dar “privilégio” total de
acesso ao usuário para uma base de
dados específica:
GRANT ALL PRIVILEGES ON Con-
trole_de_vendas.* TO renatoaf;
Para criar um usuário local e deter-
minar qual tabela e quais campos po-
derá acessar:
BANCO DE DADOS 122

GRANT SELECT (Nome,Valor) ON biblioteca.Curso TO lukinhas@localhost
IDENTIFIED BY “lucas”;
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:
REVOKE SELECT (Nome, Valor) ON biblioteca.Curso FROM lukinhas@loca-
lhost;
ou
REVOKE SELECT ON biblioteca.Curso FROM lukinhas@localhost;
Para ver todos os usuários criados no banco de dados:
SELECT HOST,USER FROM MYSQL.USER;
Para ver “privilégios” dos usuários e o que eles podem acessar:
SHOW GRANTS FOR renatoaf@localhost;
Ataques típicos em bancos de dados (SQL injection e

outros)
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 autori-
zadas ou mal-intencionadas em campos de entrada, normalmente de apli-
caçõ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á con-
ceder 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 tecno-
logia 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.
BANCO DE DADOS 123

No caso de SQL injection, a vulnerabilidade pode ocorrer, por exemplo, quan-
do 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 da-
dos, simplesmente não existe. Há sempre possibilidades e vulnerabilidades
que devem ser controladas e vigiadas constantemente. Aspectos internos, ex-
ternos, humanos e cibernéticos estão em constantes transformações e pro-
pensas a riscos. Logo, a vigilância e a busca pela solução ideal devem ser incan-
sáveis e permanentes.
As ameaças são várias, e algumas boas práticas podem e devem ser adota-
das. Entre elas, pode-se destacar:
• Implantar políticas de segurança em TI;
• Evitar concessão de privilégios de acesso excessivos para posteriormente
ficarem desatualizados e cair no esquecimento dos administradores;
• Prevenir abusos de privilégios e uso inconsequente por maus profissionais;
• Realizar testes manuais, por intermédio de ferramentas específicas direta-
mente nas aplicações do usuário para atestar a vulnerabilidade, como SQL-
Map, jSQL Injection, entre outras;
• Manter o banco de dados em um servidor exclusivo, com acesso físico e
lógico protegido de intrusão;
• Prevenir o ambiente contra malwares;
• Realizar auditorias com frequência;
• Implantar política de backups eficientes;
• 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 classifi-
car como absoluta e definitiva. Quando o assunto é segurança de dados, todo
cuidado é pouco.
BANCO DE DADOS 124

Sintetizando
Caro aluno nesse capítulo, completamos os estudos sobre a Linguagem
SQL. Vários comandos importantes e essenciais foram exemplificados e prati-
cados 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 ban-
co de dados MariaDB. Criamos e manipulamos a base Controle_de_Vendas e
suas tabelas Clientes, Produtos, Fornecedor e Vendas, com variedades de ti-
pos de campos, onde se pôde gerenciar dados de diferentes formas, com gran-
de variedade de comandos SQL.
Além dos comandos elementares e essenciais, foi possível abordar ques-
tões mais sofisticadas ao avançar e estabelecer restrições maiores ao manu-
seio 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, apresenta-
ram-se tendências e conceitos de banco de dados não relacionais e suas apli-
cações, assim como do banco de dados orientado a objetos e suas aplicações.
Em segurança em banco de dados, foram abordados aspectos importan-
tes, 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.
principais comandos SQL e aspectos relevantes no universo dos bancos de da-
dos de uma forma geral.
Esperamos que você tenha aproveitado cada conteúdo abordado, testado
cada comando e adquirido maior familiaridade com a Linguagem SQL.
BANCO DE DADOS 125

CHAUDRI, A. B.; ZICARI, R. Succeeding with object databases: a practical look
at today’s implementations with Java and XML. Hoboken: Wiley Computer Pu-
blishing, 2001.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro.
Elsevier, 2003.
DB-ENGINES. Knowledge base of relational and Nosql database manage-
ment. [S.l.]: [s.d.]. Disponível em: <https://Systemshttps://db-engines.com/en/
ranking>. Acesso em: 21 fev. 2019.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009. v. 4.
MARIADB FOUNDATION. MariaDB 10.4.3. RC. [S.l.]: 2019. Disponível em:
MULLER, J. R. Projeto de banco de dados: usando UML para modelagem de
dados. 1. ed. São Paulo: Berkeley, 2002.
PROJETO BRmodelo 3.2. Sis4, [S.l.], 2018. Disponível em: <http://www.sis4.
com/brModelo/>. Acesso em: 24 fev. 2019.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados.
BANCO DE DADOS 126

E-Book Completo - Banco de Dados - DIGITAL PAGES - COMPLETO (Versão Digital) 2

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

E-Book Completo - Banco de Dados - DIGITAL PAGES - COMPLETO (Versão Digital) 2

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE BANCO DE

GRUPO SER EDUCACIONAL

gente criando o futuro

Capa_Banco de dados_A5.indd 1,3 09/09/19 09:52

Diretor-presidente Jânyo Diniz

Diretoria Executiva de Ensino Adriano Azevedo

Diretoria Executiva de Serviços Corporativos Joaldo Diniz

Diretoria de Ensino a Distância Enzo Moreira

Autoria Prof. Renato Alves Ferreira

Projeto Gráfico e Capa DP Content

Análise de Qualidade, Edição de Texto, Design Instrucional,

Edição de Arte, Diagramação, Design Gráfico e Revisão.

© Ser Educacional 2019

Rua Treze de Maio, nº 254, Santo Amaro

Recife-PE – CEP 50100-160

Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.

ou forma sem autorização.

artigo 184 do Código Penal.

Imagens de ícones/capa: Shutterstock

Banco de dados - Unidade 1_A5.indd 2 09/09/19 09:53

Banco de dados - Unidade 1_A5.indd 3 09/09/19 09:53

Unidade 1 - Conceitos iniciais

Introdução aos bancos de dados ...................................................................................... 13

Introdução à modelagem de dados................................................................................... 17

Modelo Entidade-relacionamento .................................................................................... 21

Banco de dados - Unidade 1_A5.indd 4 09/09/19 09:53

Unidade 2 - Modelo relacional

Esquema relacional de um banco de dados ................................................................... 49

Sistemas de gerenciamento de banco de dados ........................................................... 59

Banco de dados - Unidade 1_A5.indd 5 09/09/19 09:53

Unidade 3 - Modelo físico do banco de dados – introdução à Linguagem SQL

Conceitos de Linguagem SQL ............................................................................................ 69

Restringindo e ordenando dados ...................................................................................... 79

Agregando dados com funções de grupo ........................................................................ 89

Banco de dados - Unidade 1_A5.indd 6 09/09/19 09:53

Unidade 4 - Implantação de bancos de dados relacionais

Inserindo, eliminando e alterando dados........................................................................ 99

Incluindo restrições de dados em tabelas .................................................................... 112

Tecnologias emergentes para bancos de dados.......................................................... 119

Segurança em banco de dados ....................................................................................... 121

Banco de dados - Unidade 1_A5.indd 7 09/09/19 09:53

Banco de dados - Unidade 1_A5.indd 8 09/09/19 09:53

Banco de dados - Unidade 1_A5.indd 9 09/09/19 09:53

O professor Renato Alves Ferreira

Banco de dados - Unidade 1_A5.indd 10 09/09/19 09:53

Banco de dados - Unidade 1_A5.indd 11 09/09/19 09:54

Modelar banco de dados relacionais.

Banco de dados - Unidade 1_A5.indd 12 09/09/19 09:54

Conceitos de sistemas de banco de dados

Banco de dados - Unidade 1_A5.indd 13 09/09/19 09:54

Os SGBDs, como já definido antes, são os responsáveis pelo gerenciamen-

Banco de dados - Unidade 1_A5.indd 14 09/09/19 09:54

A estrutura regular e simplificada de um banco de dados pode facilmente

QUADRO 1. COMPETÊNCIAS PARA O PROFISSIONAL

Analisando a Tabela 1, é perceptível que está dividida colunas. Essas colunas

Banco de dados - Unidade 1_A5.indd 15 09/09/19 09:54

Banco de dados - Unidade 1_A5.indd 16 09/09/19 09:54

Introdução à modelagem de dados

Banco de dados - Unidade 1_A5.indd 17 09/09/19 09:54

Projeto conceitual de banco de dados

Banco de dados - Unidade 1_A5.indd 18 09/09/19 09:54

Banco de dados - Unidade 1_A5.indd 19 09/09/19 09:54