banco_de_dados

Prévia do material em texto

Banco de Dados
1ª Edição
Brasília/DF - 2020
CLAUDIA ABREU PAES
Ficha catalográfica elaborada pela Bibliotecária Marjorie Gonçalves Andersen Trindade, CRB-1/2704
P126b
Paes, Claudia Abreu
Banco de dados / Claudia Abreu Paes. – Brasília : Alumnus, 2020.
103 p.
Recurso online: e-book
Modo de acesso: world wide web
ISBN 978-65-89227-00-7
1. Banco de dados. I. Tecnologias. 2. Modelo relacional. I. e-book. 
II. Título.
CDU 004.65
Autora
Claudia Abreu Paes
Produção
Equipe Técnica de Avaliação, Revisão Linguística e 
Editoração
Sumário
Organização do Livro Didático....................................................................................................................................... 4
Introdução ............................................................................................................................................................................. 6
Capítulo 1
Banco de Dados – Ambiente, Estrutura e Modelagem ..................................................................................... 7
Capítulo 2
Aspectos de consistência e manipulação dos dados .....................................................................................24
Capítulo 3
Sistema Gerenciador de Banco de Dados – SQL (Introdução, Definição e Movimentação 
dos dados) .....................................................................................................................................................................41
Capítulo 4
Linguagem de Definição de Dados (DML) - Consultas ...................................................................................58
Capítulo 5
Linguagem de Definição de Dados (DML) - Join, Subconsultas, Visão e Índices ...................................76
Capítulo 6
Concorrência, Segurança e Arquiteturas de BD ................................................................................................92
Referências Bibliográficas ........................................................................................................................................102
ANEXO ..............................................................................................................................................................................103
4
Organização do Livro Didático
Para facilitar seu estudo, os conteúdos são organizados em capítulos, de forma didática, objetiva e 
coerente. Eles serão abordados por meio de textos básicos, com questões para reflexão, entre outros 
recursos editoriais que visam tornar sua leitura mais agradável. Ao final, serão indicadas, também, 
fontes de consulta para aprofundar seus estudos com leituras e pesquisas complementares.
A seguir, apresentamos uma breve descrição dos ícones utilizados na organização do Livro Didático.
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
Cuidado
Importante para diferenciar ideias e/ou conceitos, assim como ressaltar para o 
aluno noções que usualmente são objeto de dúvida ou entendimento equivocado.
Importante
Indicado para ressaltar trechos importantes do texto.
Observe a Lei
Conjunto de normas que dispõem sobre determinada matéria, ou seja, ela é origem, 
a fonte primária sobre um determinado assunto.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa 
e reflita sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. 
É importante que ele verifique seus conhecimentos, suas experiências e seus 
sentimentos. As reflexões são o ponto de partida para a construção de suas 
conclusões.
5
ORGanIzaçãO DO LIVRO DIDátICO
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Posicionamento do autor
Importante para diferenciar ideias e/ou conceitos, assim como ressaltar para o 
aluno noções que usualmente são objeto de dúvida ou entendimento equivocado.
6
Introdução
Nos dias de hoje, é comum as empresas utilizarem-se de tecnologias para fomentar seus negócios, 
se manter na concorrência ou, até mesmo, sobreviver. O uso da tecnologia implica disponibilizar 
sistemas de informação adequados à natureza do negócio. Todo sistema de informação deverá 
processar informação e gerar resultados, mas a informação poderá ser nova, informada pelos 
usuários, ou estar guardada para ser reutilizada, não é mesmo? 
Dessa forma, é preciso que se tenha um recipiente para guardar esses dados pelo meio tecnológico. 
Denominamos esse recipiente de Banco de Dados. São muitos dados acumulados ao longo da 
existência da empresa! Esses dados representam o coração das empresas, por onde pulsarão 
operações, controles gerenciais, definições estratégicas e tomadas de decisão. 
Você consegue imaginar a importância atribuída a um Banco de Dados? Pois é. Por esse motivo, 
devemos estar atentos à definição, ao armazenamento e à segurança do Banco de Dados para 
gerarmos resultados consistentes, sem redundâncias, eficiente no uso (tempo de resposta) e, 
principalmente, coerente às necessidades do negócio. Este livro de Banco de Dados se propõe 
apresentar um conteúdo que traz técnicas e métodos para esse fim!
Esperamos que gostem e desfrutem de cada capítulo!
Objetivos
 » Apresentar a importância dos modelos de dados para a qualidade do Sistema de 
Informação.
 » Descrever os processos de construção do Modelo Conceitual, Modelo Lógico e Modelo 
físico no Projeto de Banco de Dados.
 » Mostrar o processo de normalização, base teórica na busca de um Banco de Dados 
consistente.
 » Fundamentar as operações realizadas em um Banco de Dados através da Álgebra 
Relacional.
 » Explicar os conceitos de execução das instruções de definição, manutenção e controle 
de um Banco de Dados.
 » Demonstrar exemplos do emprego de instruções de definição, manutenção e controle 
de um Banco de Dados.
 » Mostrar procedimento de concorrência e segurança no uso dos Bancos de Dados.
7
Introdução ao capítulo
É possível visualizar o uso de Banco de Dados na sociedade contemporânea em toda área de 
atuação, inclusive na organização pessoal. Para entendermos melhor a importância disso, 
precisamos, primeiro, entender o que é DADO e o que é Banco de Dados. 
Segundo Navathe e Ramez (2011), DADO é o registro do fato que possui um significado implícito. 
Por exemplo, quando desejamos marcar um compromisso na agenda, anotamos a data/hora e 
endereço do compromisso, seja em uma agenda eletrônica seja em uma agenda manual. Não é 
mesmo? Esses valores referentes a data/hora e endereço são considerados DADO. 
O conjunto de compromissos, por sua vez, é considerado Banco de Dados. De acordo com esses 
autores, Banco de Dados é o conjunto de dados relacionados. Para toda situação que contemple o 
uso de um Banco de Dados, precisamos definir um modelo adequado que represente a situação de 
negócio em questão, pois buscamos identificar as informações manipuladas e como relacionam-
se entre si. A partir dessa investigação, denominamos os processos de desenvolvimento de 
sistemas de levantamento de requisitos, construímos modelos que representam os dados e seus 
relacionamentos sobre três visões (conceitual, lógico e físico). Esse é o primeiro passo para o 
uso de um Banco de Dados.
O Modelo Conceitual representa a visão dos usuários, não 
considera aspectos da tecnologia. O Modelo Lógico representa 
como as relações se apresentam no ambiente tecnológico e, 
para isso, é preciso conhecer o modelo de armazenamentodo 
Banco de Dados, tais como Modelo Hierárquico, Modelo de 
Rede, Modelo Relacional, Modelo Orientado a Objetos, Modelo 
Objeto-Relacional e Modelo NoSQL. Cada qual propõe uma 
estrutura de armazenamento própria. 
O Modelo Físico consiste na forma física de representação dos dados, quando implementado 
em um Sistema Gerenciador de Banco de Dados. E o que é um Sistema Gerenciador de Banco de 
Dados (SGBD)? É o software responsável por prover recursos para definição, criação e manipulação 
1
CAPÍTULO
BANCO DE DADOS – aMBIEntE, 
EStRUtURa E MODELaGEM
Atenção
A representação de modelos é muito 
importante para:
 » compor uma documentação;
 » facilitar a interação com o usuário;
 » dar suporte à equipe de 
desenvolvimento, unificando 
informações para consulta.
8
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
dos dados. Proverá um ambiente para armazenar os dados e disponibilizá-los aos usuários, de 
acordo com o modelo de armazenamento de dados que se propõe. Todo Banco de Dados deve 
ser gerido por um Sistema Gerenciador de Banco de Dados.
O SGBD protege os dados, e os programas somente conseguem obter informações dos Bancos 
de Dados a partir do SGBD. Portanto, para que um usuário possa ter acesso ao Banco de Dados, 
é preciso ter um programa se comunicando com o SGBD, que, por sua vez, buscará o dado no 
Banco de Dados para disponibilizá-lo. A esse esquema de utilização e movimentação dos dados 
damos o nome de Sistema de Banco de Dados (Figura 1).
Figura 1 - Sistema de Banco de Dados
USUÁRIOS 
APLICAÇÕES 
SGBD 
BANCO DE 
DADOS 
METADADOS 
Fonte: Elaboração própria da autora.
Em momento apropriado, detalharemos as propriedades de um Sistema Gerenciador de Banco 
de Dados.
Vamos, então, explorar todo esse conteúdo! 
Objetivos do capítulo 
 » Conhecer os modelos de armazenamento de Banco de Dados.
 » Aprender o método de construção dos Modelos Conceitual, Lógico e Físico.
9
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
Modelos de Armazenamento de Banco de Dados
Muitos são os modelos para armazenamento do Banco de Dados, tais como: Modelo Hierárquico, 
Modelo de Rede, Modelo Relacional, Modelo Orientado a Objetos, Modelo Objeto-Relacional 
e Modelo NoSQL. Cada modelo apresenta uma série de premissas que definem a estrutura do 
Banco de Dados. Vamos conhecê-las? 
Modelo Hierárquico
O Modelo Hierárquico disponibiliza os dados a partir de uma estrutura em árvore, ou seja, cada 
ramo da árvore é denominado de nó e representa cada elemento; em cada nó, temos um conjunto 
de campos (atributos) que identifica os elementos do registro.
A disposição dos registros atende à hierarquia de níveis, em que os de níveis mais baixos dependem 
dos níveis superiores. O acesso aos dados passa sempre pela raiz da estrutura.
Alguns problemas de redundância e anomalias de inserção, eliminação e atualização de dados são 
percebidos nesse modelo, pois a árvore deve ser reconstruída como um todo, na parte afetada, 
a cada operação.
Figura 2 - Modelo Hierárquico
CLIENTES 
1012 JOSE M 10/03/2000 1420 MARIA F 15/01/1999 ... 
251-1 500,00 352-4 300,00 
Fonte: Elaboração própria da autora.
Note que, nesse modelo, em um relacionamento 1N, o funcionamento não apresenta problemas, 
mas, em relacionamentos N  N, redundâncias são necessárias e, por isso, podem ocasionar 
inconsistência dos dados nas operações de alteração e, principalmente, de exclusão e inserção.
Como exemplo, temos o SGBD IMS (Information Management System) e o System 2000/MRI. 
Modelo de Rede
O Modelo de Rede representa uma extensão do Modelo Hierárquico, em que as associações 
entre entidades-tipo funcionam nos dois sentidos. Cada entidade (registro) pertence a uma 
determinada entidade-tipo, que pode estar associada a outras entidades com várias ligações, 
sem repetir a representação, evitando a redundância. O acesso à informação é realizado por meio 
do uso de referências (endereços).
10
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
A estrutura de um Modelo de Rede (Figura 3) apresenta-se em forma de grafos, possibilitando 
acesso a qualquer nó da rede sem passar pela raiz.
Figura 3 - Modelo de rede
1012 M 10/3/1980 JOSE 
1013 F 20/6/1976 MARIA 
1014 F 14/2/1970 JÚLIA 
CLIENTES 
1 1.500.00 10/2/2000 
VENDAS 
2 1.800.00 15/12/2000 
3 3.500.00 05/9/2001 
4 200.00 6/6/2002 
5 500.00 25/5/2003 
Fonte: Elaboração própria da autora.
Nesse modelo, consideram-se questões de concorrência e segurança, de modo que a área de 
pesquisa concorrente é bloqueada para evitar o acesso simultâneo e gerar inconsistências, esse 
modelo, ainda, disponibiliza o uso de senha.
Há algumas considerações a respeito do uso de referência para acesso, são elas:
 » deve-se conhecer cada ponto da base de dados que esteja sendo utilizado, fornecido a 
partir do conceito de ponto corrente, em que se guarda a chave do registro correspondente 
à última posição;
 » torna o modelo próximo da representação física, dificultando a independência dos dados;
 » devem-se conhecer as ligações que existem para organização das rotinas.
Como exemplos mais importantes, temos SGBDs: TOTAL, IDMS, ADABAS.
Modelo Relacional (SGBDR)
Modelo revolucionário proposto, em 1970, por Edgar Frank Codd, matemático e cientista da 
computação, baseado na teoria dos conjuntos matemáticos aplicada a dados armazenados em 
tabelas de referências cruzadas.
Em 1985, preocupado com a comercialização de produtos que apresentassem características 
divergentes às suas definições, Edgar estabeleceu 13 regras de referência para classificação de 
sistemas gerenciadores de Bancos de Dados como relacional. 
11
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
São elas:
tabela 1 - Regras Modelo Relacional
Regra Foco Características
0 Fundamental Deve gerir dados usando apenas capacidades relacionais.
1 Informação toda informação é representada como dado de uma tabela, de forma única.
2 Garantia de acesso
todo dado (valor atômico) pode ser inserido no conjunto de dados a partir do nome da 
tabela, valor da chave primária da linha e nome da coluna.
3
tratamento 
sistemático de 
valores nulos
Valores nulos representam dados não informados de forma sistemática e independente 
do tipo de dado.
4
Catálogo 
dinâmico on-line 
baseado no 
modelo relacional
Os metadados devem ser armazenados e gerenciados como dados comuns, ou seja, em 
tabelas no interior do BD. Esses dados devem estar disponíveis aos usuários autorizados, 
utilizando a linguagem relacional padrão do BD.
5 Sublinguagem abrangente
Um sistema relacional pode suportar várias linguagens e formas de uso, porém deve 
possuir ao menos uma linguagem com sintaxe bem definida e expressa por cadeia 
de caracteres e com habilidade de apoiar a definição de dados, a definição de visões, 
a manipulação de dados, as restrições de integridade, a autorização e a fronteira de 
transações.
6 Atualização de visões toda visão que for teoricamente atualizável será também atualizável pelo sistema.
7
Inserção, 
atualização e 
eliminação de 
alto nível
Qualquer conjunto de dados que pode ser manipulado com um único comando para 
retornar informações também deve ser manipulado com um único comando para 
operações de inserção, atualização e exclusão. Simplificando, significa dizer que as 
operações de manipulação de dados devem poder ser aplicadas a várias linhas de uma 
vez, ao invés de apenas uma por vez.
8
Independência 
dos dados 
físicos
Programas de aplicação ou atividades de terminal permanecem logicamente inalterados 
quaisquer que sejam as modificações na representação de armazenagem ou métodos de 
acesso internos.
9 Independência lógica de dados
Programas de aplicação ou atividades de terminal permanecem logicamente inalterados 
quaisquer que sejam as mudanças de informação que permitam teoricamente a não 
alteração das tabelas-base.
10 Independência de integridade
as relações de integridade específicas de um Banco de Dados relacional devem ser 
definidasem uma sublinguagem de dados e armazenadas no catálogo (e não em 
programas).
11 Independência de distribuição
a linguagem de manipulação de dados deve possibilitar que as aplicações permaneçam 
inalteradas, estejam os dados centralizados ou distribuídos fisicamente.
12
Não 
transposição 
das regras 
Se o sistema relacional possui uma linguagem de baixo nível (um registro por vez), não 
deve ser possível subverter ou ignorar as regras de integridade e restrições definidas no 
alto nível (muitos registros por vez).
Fonte: Yoorhis, 2015.
O Modelo Relacional, o mais simples em termos de concepção, é também o mais usado. Sua 
aplicação eficiente foi possibilitada pelos avanços tecnológicos da década de 1970. A norma 
estabelecida foi designada ao padrão ANSI/SPARC. 
A estrutura do Modelo Relacional caracteriza-se por representar o Banco de Dados em formato 
de tabelas/relação, em que as linhas, também chamadas de tuplas, representam cada elemento, 
e as colunas, os atributos (Quadro 1). Cada entidade será uma tabela/relação no Banco de Dados.
12
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
Quadro 1 - Veículos
PLACA COR MODELO CPF CLIENTE (FK) 
Colunas = 
atributos 
Linhas/Tuplas 
= elemento 
do conjunto 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 AZUL VOLKSWAGEN 22222222 
Fonte: Elaboração própria da autora.
Existem vários SGBDs baseados em abordagens diferentes desse modelo: RendezVous, Oracle, 
ISBL, QUEL, QBE (query by example), INGRESS, SQL/DS, INFORMIX, DB2, DBASE IV, UNIFY, 
Paradox, PostgreSQL, MySQL, SQLServer, Access.
Modelo Orientado a Objetos (SGBDOO)
O Modelo Object Modeling Tecnhique (OMT) representa a Análise e o Projeto Orientados a 
Objetos, denominado de Modelo OO. Esse modelo pressupõe o conceito de objeto, ou seja, 
todo elemento de representação do negócio incorpora sua estrutura de dados e os comportamentos. 
Quando se fala em Modelos Orientados a Objetos, entendemos que é preciso desenvolver processos 
de abstração do mundo real, pensar que, para cada objeto, teremos comportamentos próprios, 
denominados de métodos, e que os dados só estarão disponíveis por meio desses métodos, os 
quais chamamos de encapsulamento.
Os Bancos de Dados relacionais não trabalham com dados complexos e, se utilizada linguagem 
de programação OO, o uso de Bancos de Dados relacionais requer uma adaptação na persistência 
dos dados, pois a estrutura proposta no método OO difere da estrutura dos modelos relacionais 
e, por isso, a necessidade de adaptação. Segundo Elmasri (2005), essa tarefa é conhecida como 
“perda por resistência”. 
Em meados de 2004, os Bancos de Dados livres 
impulsionaram o uso dos Bancos de Dados 
orientados a objetos. A Object Data Management 
Group (ODMG) e a Object Query Language 
(OQL), juntas, padronizaram uma linguagem 
de consulta para objetos. 
Algumas características podem ser destacadas:
Posicionamento do autor
O Modelo OO ainda não apresenta influência 
na área comercial. Percebo que o bom e estável 
funcionamento do Modelo Relacional faz com 
que as empresas não busquem a mudança, mas, 
em se tratando de Bancos de Dados espaciais, 
telecomunicações e áreas científicas, como física de 
alta energia e biologia molecular, sua presença já é 
notável, pois oferece maior produtividade, segurança 
e facilidade de manutenção. Como objetos são 
modulares, mudanças podem ser feitas internamente, 
sem afetar outras partes do programa.
13
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
 » o acesso a dados apresenta-se mais rápido, pois, além de não serem necessárias junções, 
esse acesso é feito a partir de ponteiros;
 » suporte a versões, ou seja, um objeto pode ser visto de todas e várias versões;
 » o uso do encapsulamento pode ser dificultado, na medida em que não é possível ver 
os atributos.
Existem vários SGBDs Orientados a Objetos, como: CACHÉ, VERSANT, DB4Objects, GEMSTONE, 
JASMINE, MATISSE, Objectivity/DB, Ozone.
Modelo Objeto-Relacional (SGBDOR)
Com a chegada dos Modelos OO no mercado, sentiu-se a necessidade de incorporar aos Modelos 
Relacionais já consagrados alguns conceitos da Orientação a Objetos e, assim, usufruir de um 
Banco de Dados que pudesse usar dos dois modelos. Dessa forma, o Modelo Objeto-Relacional 
consiste na junção do Modelo Relacional com o Modelo OO, ele possui as seguintes características:
 » padrão SQL 1999;
 » SQL estendida para incorporar suporte ao modelo de dados relacional-objeto, com 
disponibilidade de construtores de tipos para especificar objetos complexos, tuplas e 
array; 
 » inserção de identidade de objeto (reference type), encapsulamento de operações, 
herança e polimorfismo. 
 » implementação física por meio de tabelas (linhas e colunas), seguindo o Modelo 
Relacional;
Alguns SGBDs relacionais utilizados hoje no mercado, tais como Oracle, SQLServer, PostgreSql, 
entre outros, implementaram em suas versões mais recentes os conceitos adotados nos Modelos 
Orientado a Objetos, o que os fazem Objeto-Relacional.
Modelo NoSql
Com o volume crescente de informações disponibilizadas para compartilhamento e a diversificação 
de mídias para apresentação da informação, os modelos relacionais passam a não suportar essa 
demanda e torna-se necessária a busca por uma solução de Banco de Dados que proveja mais 
agilidade e escalabilidade nas aplicações que utilizam esses dados. Dessa forma diferenciada, 
redes sociais, redes de compartilhamento de imagens e vídeos, messengers caracterizam-se 
como Banco de Dados não relacional.
Os Modelos NoSQL propõem algumas estruturas diferentes para uso: Orientado a Documentos, 
Orientado a grafos, Banco chave-valor ou tupla (Key-Value), Banco Wide Column.
14
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
Orientado a Documentos
Aplicado a uso geral, foca seu emprego no armazenamento e na manipulação de documentos.
Como características principais, podemos destacar:
 » documentos armazenados como JSON;
 » documentos amigáveis à programação orientada a objetos, visto que cada documento 
é um objeto que contém vários atributos (campos) com seus respectivos tipos;
 » eliminação de junções, pois armazena os dados correlacionados em um só documento;
 » campos podem mudar de um documento para outro, permitindo flexibilidade na 
estrutura do banco;
 » querys são relativamente menores do que em um banco relacional.
Alguns exemplos: MongoDB, CouchDB.
Banco orientado a grafos
Aplicado a necessidades de manter a ligação entre muitos objetos, como redes sociais, árvores 
genealógicas, controle de acesso e georreferenciamento. Foca no armazenamento dos dados 
representando uma rede de elementos interconectados, utilizando a teoria dos grafos, em que 
cada nó representa uma entidade/elemento/objeto (como uma pessoa, produto, venda etc.), 
que contém suas respectivas propriedades.
Como características principais, podemos destacar:
 » não requer operações de join;
 » flexibilidade na estrutura dos nós;
Alguns exemplos: Neo4j, HyperGraphDB.
Banco chave-valor ou tupla (Key-Value)
Aplicado a uso geral e, principalmente, a aplicações mobile, representa o mais simples banco 
NoSQL. Essa estrutura de banco NoSQL representa os dados em uma única tabela com duas 
colunas: uma chave primária e um valor, como um hashmap. Dessa forma, os dados são acessados 
somente pela chave (os valores são transparentes ao sistema).
Como características principais, podemos destacar:
 » flexibilidade na estrutura dos dados;
 » agilidade;
15
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
 » suporte a quantidades numerosas de dados;
Alguns exemplos: Riak, Redis, DynamoDB.
Banco Wide Column
Conhecido como Banco de Dados de famílias de colunas, caracteriza-se pelo armazenamento de 
valor-chave bidimensional, pois cada tupla pode conter tuplas encadeadas, e as colunas podem 
ser agrupadas por famílias de colunas. Dentro de uma determinada família de colunas, todos os 
dados são armazenados em uma linha por linha, de formaque as colunas de uma determinada 
linha são armazenadas juntas, em vez de cada coluna ser armazenada separadamente. Além 
disso, os nomes e o formato das colunas podem variar de linha para linha na mesma tabela. O 
acesso aos dados é realizado por meio da chave da coluna.
Alguns exemplos: HBase, Cassandra (criado pelo Facebook).
No escopo desta disciplina, utilizaremos o Modelo Relacional.
Modelos de Dados
O Modelo de Dados é um conjunto de ferramentas conceituais usadas para a descrição de dados, 
relacionamento entre dados, semântica de dados e regras de consistência (SILBERSCHATZ; 
KORTH; SUDERSHAN, 2006). No escopo deste material, abordaremos a representação do modelo 
de dados em Modelo Conceitual, Modelo Lógico e Modelo Físico.
Para representação dos Modelos Conceitual, Lógico e Físico, vamos utilizar o Modelo 
Entidade-Relacionamento.
O modelo entidade-relacionamento baseia-se na percepção do mundo real como um conjunto 
de elementos que representam o contexto do negócio, chamado de ENTIDADE de DADOS, e as 
ligações entre os elementos das entidades, chamadas de RELACIONAMENTO.
Em todo modelo, para sua representação, são utilizadas simbologias na apresentação dos 
conceitos. Assim, segue a simbologia que iremos utilizar na representação do Modelo Conceitual 
e do Modelo Lógico.
Simbologia:
Entidade de Dados: representa o conjunto de elementos constantes 
no ambiente de negócio. No centro do retângulo, deve constar o nome 
atribuído ao conjunto de elementos representado. Como exemplo, 
podemos representar o PRODUTO, em uma loja, a entidade produto 
representa o conjunto de produtos disponíveis para venda.
PRODUTOS
16
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
Cada elemento da entidade é identificado por ATRIBUTOS. O Atributo pode ser classificado 
em SIMPLES, COMPOSTO, MULTIVALORADO. O Atributo SIMPLES identifica o elemento com 
um único conteúdo, por exemplo, IDADE. Somente um valor representa a idade do cliente. 
O Atributo COMPOSTO identifica o elemento com a composição de mais de um valor, por 
exemplo, ENDEREÇO, que, para ser completo, necessita de várias informações: Rua + Número 
+ Complemento + Bairro + Cidade + Estado. O Atributo MULTIVALORADO identifica o elemento 
com várias informações do mesmo tipo, por exemplo, telefone *(0-N). Nesse caso, o elemento 
poderá ter vários telefones. 
Temos, ainda, o ATRIBUTO DO RELACIONAMENTO utilizado para identificar juntos os elementos 
que compõem o relacionamento.
O atributo é representado por:
nome
atributo
Relacionamento: representa a ligação entre os elementos de duas 
entidades ou mais. Em nossa loja-exemplo, podemos considerar 
que temos outra entidade chamada CLIENTES e que teremos uma 
ligação entre CLIENTES e PRODUTOS para poder identificar, no 
âmbito do negócio, quais clientes compraram quais produtos, e, no 
outro sentido, quais produtos foram comprados por um determinado 
cliente. Atentemos para o fato de que o relacionamento atende nos 
dois sentidos.
 
Papel do relacionamento: identifica o relacionamento.
Direção do relacionamento: define o sentido de leitura do relacionamento.
17
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
Cardinalidade: representa o número de vezes que um elemento da 
entidade participa do relacionamento. A cardinalidade é formada por:
(LI (limite inferior) – LS (limite superior))
O Limite Inferior representa o número mínimo de vezes que o elemento 
pode participar do relacionamento, e o Limite Superior, o número 
máximo de vezes que o elemento pode participar do relacionamento. 
Os valores para o Limite Inferior (LI) devem ser representados por 
números inteiros e superiores ou iguais a 0 e sempre inferiores ou iguais 
ao Limite Superior (LS).
Os valores para o Limite Superior (LS) devem ser representados por N, 
indicando muitos/infinito ou números inteiros e superiores ou iguais 
ao Limite Inferior (LI).
A representação do Limite Inferior (LI) = 0 significa que o elemento 
pode existir na entidade sem participar do relacionamento, ou seja, 
suponha que temos uma entidade chamada de PRODUTOS. Dessa 
forma, um produto na entidade pode estar cadastrado (existir) sem que 
tenha sido vendido (participado do relacionamento compra). Por isso, 
a cardinalidade no Limite Inferior (LI) é 0.
A leitura do relacionamento nesse exemplo seria: PRODUTOS são 
comprados por nenhum (0) ou muitos (N) CLIENTES, e um CLIENTES 
compra, no mínimo, 1 e, no máximo, (N) PRODUTOS. Isso significa que 
PRODUTOS pode existir sem participar do relacionamento e CLIENTES 
só existirá se participar pelo menos uma vez do relacionamento. Não 
temos CLIENTES que não tenha participado de compras.
Entidade Fraca: representa elementos que são dependentes do relacionamento, ou seja, sua 
definição depende dos elementos da entidade relacionada. Suponha uma entidade CLIENTES que 
possui DEPENDENTES. Perceba que o relacionamento de DEPENDENTES tem o limite inferior 
igual a 1, o que significa que ele SEMPRE vai estar relacionado a, pelo menos, um CLIENTE!
possui 
CLIENTES DEPENDENTES0-N 1-1
Fonte: Elaboração própria da autora.
18
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
Generalização/Especialização: representa a classificação de elementos de uma entidade de 
dados. A generalização é a entidade comum, e a especialização representa os diversos tipos 
de elementos. 
Por exemplo:
PRODUTOS 
PERECÍVEL 
NÃO 
PERECÍVEL 
código 
descrição 
data 
Validade 
Fonte: Elaboração própria da autora.
Na entidade PRODUTO, temos dois atributos: código e descrição; na entidade PERECÍVEL, temos 
o atributo dataValidade; e, na entidade NÃO PERECÌVEL, não temos atributo. Na generalização/
especialização, os atributos da entidade que representa a generalização são também atributos 
das entidades especializadas, mas os atributos das entidades especializadas pertencem somente 
à entidade especializada que a define. Por conseguinte, os atributos de PRODUTO são: código 
e descrição. Os atributos de PERECÍVEL são: código, descrição e dataValidade. Os atributos de 
NÃO PERECÍVEL são: código e descrição.
Entidade Associativa: representa o relacionamento entre duas entidades com cardinalidade 
N  N. 
Por exemplo:
0-NCLIENTES PRODUTOS1-N 
compra 
Fonte: Elaboração própria da autora.
Na entidade associativa em destaque, temos a representação da lista de clientes + produtos e, 
como atributo do relacionamento, a quantidade, que identifica a quantidade de produtos que 
o cliente comprou de um determinado produto.
Autorrelacionamento: representa o relacionamento entre elementos da mesma entidade. 
Por exemplo: 
19
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
CURSOS 
0-1 pré-
requisitos 
Fonte: Elaboração própria da autora.
A leitura do autorrelacionamento é: um curso é pré-requisito de nenhum (0) ou vários (N) cursos, 
e, por outro lado, um curso pode possuir nenhum (0) ou vários (N) pré-requisitos.
Terminamos, assim, a definição da simbologia a ser utilizada no modelo entidade-relacionamento.
O Modelo Conceitual representa a visão do usuário, ou seja, devemos apresentar os dados e 
seus relacionamentos que atendam à necessidade do negócio, não tendo a preocupação de qual 
SGBD deve ser usado ou qual será o tipo e tamanho do dado que deseja armazenar. No Modelo 
Conceitual, não são levados em consideração aspectos do uso da tecnologia.
Para exemplificar o Modelo Conceitual, vamos analisar a seguinte situação:
Estacionamento “Bom Serviço”
Diariamente o estacionamento Bom Serviço recebe vários clientes para aluguel de suas vagas 
e possui uma rotina destinada ao bom atendimento. O gerente é o responsável por manter as 
informações de vaga (com informações de localização e situação). 
Quando o cliente chega ao estacionamento, o veículo é identificado (placa, cor e modelo) e 
registrado pelo atendente, que emite um comprovante e cadastra o cliente (CPF, nome, endereço, 
telefone *(0-N)) e o veículo, se for recebido pela 1ª vez. As vagas sãodistribuídas automaticamente 
a cada cliente.
As vagas são bloqueadas no recebimento do carro e liberadas na saída. Aquelas com algum 
impedimento (obra, vazamento etc.) são interditadas para uso.
A locação da vaga registra data e hora de entrada e identifica o manobrista e o atendente, além 
dos funcionários do estacionamento, identificados por CPF, nome e matrícula.
A liberação é efetivada a partir da solicitação do cliente, que entrega o seu comprovante de 
locação, realiza o pagamento e recebe uma autorização de saída. O atendente encerra a locação 
registrando a data e a hora de saída. O manobrista retira o veículo da vaga e entrega-o ao cliente.
O primeiro passo é identificar as entidades, e o segundo, o relacionamento entre elas. Podemos 
constatar na situação apresentada que temos como entidades CLIENTES, VEÍCULOS, VAGA, 
LOCAÇÃO e FUNCIONÁRIOS (atendente e manobrista). Concorda?
20
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
E como ficam os relacionamentos? São definidos pela necessidade de se ter informações de 
entidades diferentes. Por exemplo, ligar CLIENTES e VEÍCULOS significa que vamos conhecer 
todos os veículos de um cliente. E assim por diante. Ficamos assim (Figura 4):
Figura 4 - Modelo Conceitual - Estacionamento Bom Serviço
Fonte: Elaboração própria da autora.
Veja que não comentei nenhuma questão tecnológica!
Construído o Modelo Conceitual, devemos elaborar o Modelo Lógico, que depende do modelo 
de armazenamento do Banco de Dados a ser utilizado, aqui utilizaremos o Modelo Relacional.
O Modelo Lógico é criado a partir do Modelo Conceitual, apresenta os fatores de representação do 
relacionamento entre os elementos do negócio no meio tecnológico. A esses fatores relacionamos 
dois conceitos básicos: Chave Primária e Chave Estrangeira. Na língua inglesa, tais fatores são 
chamados, respectivamente, de primary key (PK) e foreign key (FK). Refiro-me aos termos em 
inglês porque são linguajar comum nas equipes de desenvolvimento.
Para construção do Modelo Lógico, devemos primeiro identificar as Chaves Primárias (PK), mas 
o que seria Chave Primária? 
CHAVE PRIMÁRIA é o atributo que representa o conjunto de elementos de forma única. A escolha 
da Chave Primária deve respeitar as seguintes premissas:
 » o atributo não poderá ter conteúdo duplicado;
 » preferencialmente o atributo deve ser inteiro e não alfanumérico, em função do 
desempenho.
Definindo as chaves primárias, devemos derivar o Modelo Conceitual. A derivação acontece no 
transporte das chaves primárias entre os relacionamentos para a representação física da ligação. 
21
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
O transporte acontece com a criação de um atributo na entidade destino, segundo regras definidas 
a seguir. Esse atributo é denominado Chave Estrangeira (FK). Desse modo, a Chave Estrangeira 
é o atributo que representa o relacionamento físico entre os elementos das entidades e a Chave 
Primária na entidade relacionada.
As regras de derivação são definidas em relação à cardinalidade superior dos relacionamentos:
Relacionamento 1 – 1  é possível transportar o atributo para qualquer uma das entidades 
que pertence ao relacionamento. Tecnicamente é indiferente. Devemos analisar as condições 
do negócio e do ambiente. Frequência de utilização, volume de dados são fatores importantes 
para análise.
Relacionamento 1 – N  a Chave Primária da entidade que participa N vezes no relacionamento 
vai ser um atributo (Chave Estrangeira) na entidade que representa 1 no relacionamento.
Relacionamento N – N  nesse caso, é preciso criar uma nova entidade, interligada com as 
entidades relacionadas em um relacionamento 1 – N. Em seguida, deve-se repetir a regra 1 – N.
Generalização/Especialização: essa representação não estará incluída no Modelo Lógico. 
Devemos escolher a forma de junção das entidades participantes da generalização/especialização. 
Devem-se agrupar as entidades da forma que melhor atenda ao negócio.
Por exemplo, no exemplo apresentado na simbologia de Generalização/Especialização, é 
possível juntar os tipos na entidade PRODUTOS. Isso implicará ficar sem conteúdo o atributo 
dataValidade para o produto não perecível. Seria possível também fazermos duas entidades, 
uma de PRODUTO PERECÍVEL e outra de PRODUTO NÃO PERECÍVEL. Essa escolha acarretará 
mais recursos para gerenciar o modelo, o que pode onerar o processamento. 
Para as demais representações, a derivação é realizada em função das cardinalidades exposta 
anteriormente.
Feita a derivação e definidas as Chaves Estrangeiras, é preciso definir a Chave Primária em cada 
entidade. Toda entidade deve ter Chave Primária (PK)!
Algumas observações:
 » nas entidades criadas a partir de uma entidade associativa, as Chaves Estrangeiras (FK) 
advindas das entidades participantes da entidade associativa são candidatas para serem 
Chave Primária (PK);
 » nas entidades fracas, a Chave Primária deve ser composta do atributo derivado da 
entidade relacionada com um atributo da entidade fraca à escolha;
22
CAPÍTULO 1 • BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM
 » é possível também criar um atributo para ser a Chave Primária, pois, com um conteúdo 
sequencial, não teremos duplicidade. A desvantagem é que, logicamente, esse atributo 
não terá significado;
 » para os atributos multivalorados, é necessário criar uma nova entidade de dados.
Assim, a partir do Modelo Conceitual (Figura 4), podemos conferir o Modelo Lógico (Figura 5).
Figura 5 - Modelo Lógico - Estacionamento “Bom Serviço”
Fonte: Elaboração própria da autora.
Alguns pontos importantes:
 » O atributo NumVaga foi criado para ser a Chave Primária. 
 » Para o atributo multivalorado TELEFONE, foi criada a entidade de dados TELEFONES.
 » FUNCIONÁRIO tem dois relacionamentos, pois um representa a ligação com o atendente 
e outro com o manobrista.
 » A entidade associativa LOCAÇÃO recebe as chaves primárias das entidades relacionadas 
VEÍCULOS e LOCAÇÃO, que ficam também como Chave Primária.
O Modelo Físico representa os aspectos estruturais das entidades, ou seja, para cada atributo, é 
preciso definir o tipo e o tamanho. O tipo representa o conteúdo válido a ser armazenado para o 
atributo. Podemos considerar data, inteiro, alfanumérico e decimal (total de inteiros e decimal, 
total de decimais), por exemplo: representar um número decimal que tenha 5 inteiras e 2 decimais. 
A representação seria decimal (7,2). O tamanho deve ser definido a partir da necessidade do 
negócio. O Modelo Físico tem como origem o Modelo Lógico.
Por exemplo, vamos verificar a definição parcial do nosso exemplo (Quadro 2, Quadro 3, Quadro 
4): Estacionamento “Bom Serviço”:
Quadro 2 - Modelo Físico - VaGaS
23
BanCO DE DaDOS – aMBIEntE, EStRUtURa E MODELaGEM • CAPÍTULO 1
Atributo Tipo Tamanho Chave Primária (PK) Chave Estrangeira (FK)
numVaga Inteiro 6 X 
Localização alfanumérico 20
Situação alfanumérico 15
Fonte: Elaboração própria da autora.
Quadro 3 - Modelo Físico - LOCaçÃO
Atributo Tipo Tamanho Chave Primária (PK) Chave Estrangeira (FK)
Placa alfanumérico 7 X X
numVaga Inteiro 6 X X
DataEntrada data 8
DataSaída data 8
CpfAtendente Inteiro 11 X
CpfManobrista Inteiro 11 X
Fonte: Elaboração própria da autora.
Quadro 4 - Modelo Físico - VEÍCULOS
Atributo Tipo Tamanho Chave Primária (PK) Chave Estrangeira (FK)
Placa alfanumérico 7 X
Cor alfanumérico 10
Modelo alfanumérico 15
CPF Inteiro 11 X
Fonte: Elaboração própria da autora.
Com o modelo físico, é possível criar os Bancos de Dados. 
Sintetizando
Vimos até agora:
 » Que os Bancos de Dados representam um conjunto de dados inter-relacionados.
 » Que os Bancos de Dados necessitam de um Sistema Gerenciador de Banco de Dados (SGDBs) para sua manutenção e 
utilização.
 » Que os SGDBs são desenvolvidos para atender a Modelos de Armazenamento de Dados.
 » Que os Modelos de Armazenamento de Dados propõem estruturas diferentes para disposição dos dados.
 » Que os ModelosHierárquico, em Rede, Relacional, Orientado a Objetos, Objeto-Relacional e NoSQL são Modelos de 
Armazenamento que, em função da evolução, foram sendo definidos para atender a critérios de agilidade, consistência, 
segurança e volume de dados.
 » Que o Modelo Conceitual deve ser representado a partir da visão do usuário, sem envolvimento da tecnologia, pois seu 
foco principal é a representação dos dados que darão suporte aos requisitos de sistema.
 » Que o Modelo Lógico é criado a partir do Modelo Conceitual e representa, no meio tecnológico, a ligação entre os 
elementos da entidade, por meio das Chaves Primárias e Estrangeiras.
 » Que o Modelo Físico é a representação física das entidades, criado a partir do Modelo Lógico.
24
Introdução ao capítulo
Antes do surgimento do conceito de Banco de Dados, utilizavam-se arquivos sequenciais para 
o armazenamento, em que cada registro (linha) representava um elemento, mas os atributos 
eram mapeados nos programas, e fisicamente as linhas eram organizadas no formato sequencial, 
como um documento de editores de texto que conhecemos. 
Podemos imaginar como era trabalhoso e lento manipular esses dados, não é mesmo? Pense como 
seria para incluir/alterar ou apagar um elemento! A procura por sistemas computacionais 
aumentou e, naturalmente, a evolução apresentou os arquivos sequenciais-indexados, pois 
assim agilizariam as operações sob os dados. Melhorou muito, mas a necessidade de manter 
redundância de dados ainda era eminente, o que levava à frequente inconsistência, ameaçando 
o verdadeiro valor do dado armazenado. 
Os estudos da época chegaram à Teoria da Normalização, pela qual se estabeleceram regras que, 
aplicadas às relações de dados, fariam com que os dados ficassem organizados e estruturados de 
tal maneira que fosse possível evitar a redundância e, assim, garantir a qualidade da informação 
que iria gerar. Assim sendo, a Normalização antecedeu à proposta de construção dos Modelos 
Conceituais de dados. 
Como dito anteriormente, os SGBDs protegem os dados assegurando o acesso de pessoas 
autorizadas, mas, mais do que segurança, eles preocupam-se também com a consistência desses 
dados. Não podemos nos esquecer que, nos dias atuais, os dados representam o coração das 
empresas e dos negócios. Dessa forma, a consistência dos dados trará o verdadeiro valor ao dado, 
gerando confiabilidade em nossos sistemas.
Nesse caminho, a consistência é exercida pelos SGBDs mediante o emprego das restrições de 
integridade, que representam regras nos atributos. As regras são definidas em tempo de criação 
das estruturas dos dados e validadas na execução das operações de atualização dos Modelos 
Relacionais, que mantêm o conteúdo dos dados nos Bancos de Dados por meio das funções 
de inclusão, alteração e exclusão. No entanto, os dados precisam também ser consultados! 
Pelas consultas, o dado é disponibilizado ao usuário final em forma de informação, apresentando 
2
CAPÍTULO
aSPECtOS DE COnSIStÊnCIa E 
ManIPULaçãO DOS DaDOS
25
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
os resultados de processamentos operacionais, gerenciais e estratégicos. Para realização das 
consultas e manipulação dos dados em Banco de Dados Relacional, utilizaram-se os conceitos 
teóricos definidos na Álgebra Relacional na utilização de tabelas, mesma estrutura dos Bancos 
de Dados Relacionais. 
A Álgebra Relacional, segundo Silberschatz, Korth e Sudershan (2006), é uma linguagem de 
consultas procedural que disponibiliza um conjunto de operações nas relações, gerando como 
resultado uma nova relação. As principais operações da Álgebra Relacional são as de seleção, 
projeção, produto cartesiano, junção, interseção, união e diferença. Essas operações sistematizam 
os procedimentos necessários para realizar movimentações em Bancos de Dados relacionais.
Objetivos do capítulo
 » Conhecer a Teoria da Normalização e suas regras.
 » Entender as operações da Álgebra Relacional para movimentação dos dados no Modelo 
Relacional.
 » Compreender as restrições de integridade, utilizadas nas operações de atualização do 
Banco de Dados para manter a consistência dos dados.
 » Aprender as instruções de consultas a dados, propostas na Álgebra Relacional, lógica 
aplicada ao Modelo Relacional.
26
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
Normalização
É um processo definido para evitar redundância de dados e organizar tabelas por assunto, 
buscando maior confiabilidade. O processo de normalização se dá por meio da aplicação de 
um conjunto de regras nas relações, decompondo-as em outras relações, melhor estruturadas. 
O conjunto de regras, denominadas de formas normais, consiste, principalmente, na verificação 
de elementos repetitivos, remoção das dependências parciais de chave e dependências transitivas. 
Uma relação de dados não normalizada gera:
 » inconsistência de dados;
 » redundância, que gera excessivo trabalho na manutenção dos dados;
 » dificuldade para suporte ao Banco de Dados;
 » desperdício na utilização de espaço no armazenamento.
Existem seis regras de normalização: boyce-codd, 1ª regra normal, 2ª regra normal, 3ª regra normal, 
4ª regra normal, 5ª regra normal. Cada qual com suas características e procedimentos de aplicação. 
Apesar das seis regras de normalização, normalmente aplicam-se as 1ª, 2ª e 3ª forma, pois se 
considera a terceira forma normal o nível mínimo necessário para grande parte das aplicações.
Vamos conhecer as regras de normalização?
As Formas Normais
As formas normais consistem em definir uma regra que a relação deve cumprir. Assim, caso a 
relação não esteja adequada à regra, procedimentos devem ser realizados para atender à regra 
em questão.
Vamos às regras!
1ª Forma Normal (1FN)
A relação está na primeira forma normal se, somente se, possui somente atributos atômicos, 
não repetitivos.
Procedimentos para normalização 1FN:
1. Criar uma nova relação para conter a Chave Primária da relação origem e os atributos 
que podem se repetir. 
2. Definir a Chave Primária da relação: entre os atributos não chave, escolha um que, 
junto com a Chave Primária trazida da relação de origem, componha a Chave Primária 
composta da nova relação.
27
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
3. Na relação de origem, retirar os atributos que se repetem da relação origem, permanecendo 
somente os atributos restantes na formação da relação.
Por exemplo: 
CLIENTE = {CPF, NOME, telefone *(0-N)}, não está normalizada na 1FN, porquanto o atributo 
telefone pode ser representado por vários valores.
Para normalizar, seguindo os procedimentos:
 CLIENTETELEFONE = {CPF, TELEFONE}
 CLIENTE = {CPF, NOME}
Relações normalizadas na 1FN!
2ª Forma Normal (2FN)
A relação está na segunda forma normal se, somente se, está na primeira forma normal e os 
atributos não chave representam as informações da chave completa.
Procedimentos para normalização 2FN:
1. Criar uma nova relação para conter a chave primária da relação de origem e os atributos 
que a representa. 
2. Na relação de origem, retirar os atributos que representam parte da chave, utilizados no 
item 1, permanecendo somente os atributos restantes na formação da relação.
Por exemplo: 
ITENSPRODUTO = {NUMPEDIDO, CÓDIGOPRODUTO, DATAPEDIDO, NOMEPRODUTO, 
QUANTIDADEPEDIDO}, não está normalizada na 2FN, pois o atributo NOMEPRODUTO 
representa apenas CODIGOPRODUTO, independente do NUMPEDIDO, o nome do produto 
será o mesmo.
Para normalizar, seguindo os procedimentos:
PRODUTO = {CÓDIGOPRODUTO, NOMEPRODUTO}
ITENSPRODUTO = {NUMPEDIDO, CÓDIGOPRODUTO, DATAPEDIDO, QUANTIDADEPEDIDO} 
Relações normalizadas na 2FN!
3ª Forma Normal (3FN)
A relação está na terceira forma normal se, somente se, está na segunda forma normal e os 
atributos não chave possuem dependência transitiva. Entende-se por dependência transitiva 
quando os atributos definem um mesmo conceito.
28
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
Procedimentospara normalização 3FN:
1. Criar uma nova relação com todos os atributos que possuem a dependência transitiva.
2. Definir a chave primária da relação: entre os atributos não chave, escolha um que possa 
representar a chave primária dessa nova relação.
3. Na relação de origem, retirar os atributos que possuem dependência transitiva, deixando 
permanecer somente o atributo escolhido como Chave Primária da nova relação, que 
agora permanecerá como Chave Estrangeira na relação de origem.
Por exemplo: 
ITENSPRODUTO = {NUMPEDIDO, CÓDIGOPRODUTO, DATAPEDIDO, QUANTIDADEPEDIDO, 
CNPJFORNECEDOR, RAZÃOSOCIALFORNECEDOR}, não está normalizada na 3FN, porque os 
atributos CNPJFORNECEDOR e RAZÃOSOCIALFORNECEDOR se referem a um mesmo conceito, 
que seria identificar um fornecedor.
Para normalizar, seguindo os procedimentos:
FORNECEDOR = {CNPJFORNECEDOR, RAZÃOSOCIALFORNECEDOR}
ITENSPRODUTO = {NUMPEDIDO, CÓDIGOPRODUTO, DATAPEDIDO, QUANTIDADEPEDIDO, 
CNPJFORNECEDOR}
Relações normalizadas na 3FN!
4ª Forma Normal (4FN)
A relação está na quarta forma normal se, somente se, está na terceira forma normal e os atributos 
possuem dependência multivalorada em relação à chave primária. 
Procedimentos para normalização 4FN:
1. Criar uma nova relação para cada atributo com dependência multivalorada contendo 
como atributo a Chave Primária da relação de origem e o atributo que representa a 
dependência multivalorada.
2. Definir a Chave Primária da relação: considerar o atributo não chave junto com a Chave 
Primária trazida da relação de origem para compor a Chave Primária composta da nova 
relação.
3. Na relação de origem, retirar os atributos que possuem dependência multivalorada.
Por exemplo: 
COMPONENTES = {CNPJFORNECEDOR, CODIGOPEÇA, CODIGOEQUIPAMENTO}
29
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
Não está normalizado na 4FN, visto que o CODIGOPEÇA poderá ser de vários fornecedores e 
estar em vários equipamentos, representado por CODIGOEQUIPAMENTO. Nesse caso, teremos 
uma redundância em alguns casos.
Para normalizar, seguindo os procedimentos:
COMPONENTES = {CNPJFORNECEDOR, CODIGOPEÇA}
COMPONENTES = {CODIGOPEÇA, CODIGOEQUIPAMENTO}
Relações normalizadas na 4FN!
5ª Forma Normal (5FN)
A relação está na quinta forma normal se, somente se, está na quarta forma normal e os 
relacionamentos são múltiplos (ternários, quarternários, n-ários). Nesses relacionamentos é 
possível considerar que, frequentemente, temos perda de informação, e isso aponta não estar 
normalizado na 5FN.
Boyce-codd
Uma relação está na Forma Normal Boyce-Codd se, e somente se, está na 3FN e toda Chave 
Primária é Chave Candidata. Quando uma relação tem mais de uma Chave Candidata, podemos 
ter imperfeições.
O fato é que a 4FN, 5FN e Boyce Codd são exceções. É considerado imprescindível a normalização 
estar na 3FN. Para as demais, as condições do ambiente estarão influenciando.
Restrição de Integridade
É definida nos Bancos de Dados para manter a consistência. São regras atribuídas a atributos com 
o objetivo de manter a consistência dos dados em operações de inclusão, alteração e exclusão, 
a saber: CHAVE, ENTIDADE, DOMÍNIO, REFERENCIAL, SEMÂNTICA.
CHAVE  A restrição de integridade de CHAVE indica que a Chave Primária de uma relação não 
pode conter valor duplicado, ou seja, duas linhas na relação não podem ter o mesmo valor na 
coluna referente à Chave Primária. Por exemplo:
Quadro 5 - Restrição de Integridade de Chave – Exemplo
VEÍCULOS 
PLACA 
(PK) COR MODELO 
CPFCLIENTE 
(FK) 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 AZUL VOLKSWAGEN 22222222 
ABC1234 VERDE VOLKSWAGEN 33333333 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
de CHAVE! 
Fonte: Elaboração própria da autora.
30
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
ENTIDADE  A restrição de integridade de ENTIDADE indica que a Chave Primária de uma 
relação não pode conter valor nulo, ou seja, o conteúdo do atributo Chave Primária não pode 
ficar sem valor. Deve sempre ter valores válidos. Entende-se por valores nulos, conteúdos sem 
valor. Não é branco nem lixo, é um valor vazio. Por exemplo:
Quadro 6 - Restrição de Integridade de Entidade - Exemplo
VEÍCULOS 
PLACA 
(PK) COR MODELO 
CPFCLIENTE 
(FK) 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 AZUL VOLKSWAGEN 22222222 
VERDE VOLKSWAGEN 33333333 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
de ENTIDADE! 
Fonte: Elaboração própria da autora.
DOMÍNIO  A restrição de integridade de DOMÍNIO indica que o conteúdo do atributo deve 
estar no intervalo definido como válido para o atributo em questão. O domínio pode ser contínuo, 
quando define um intervalo de valores, seja numérico ou alfanumérico, e discreto, quando define 
significado ao valor. Por exemplo:
DOMÍNIO CONTÍNUO  Suponha que o atributo IDADE tenha uma regra que define que a 
coluna idade não poderá ser inferior a 18 anos. A restrição de integridade deverá ser implantada no 
atributo para não permitir a inclusão de linha ou alteração da coluna com valores inferiores a 18.
Quadro 7 - Restrição de Integridade de Domínio Contínuo - Exemplo
VEÍCULOS 
CPF (PK) NOME IDADE SEXO 
11111111 MARIA 25 F 
22222222 JOÃO 19 M 
33333333 JOSÉ 15 M 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
de DOMÍNIO! 
Fonte: Elaboração própria da autora.
DOMÍNIO DISCRETO  suponha que o atributo SEXO tenha uma regra que define que a coluna 
sexo não poderá ser diferente de F (Feminino) e M (Masculino). A restrição de integridade deverá 
ser implantada no atributo para não permitir a inclusão de linha ou alteração da coluna com 
valores diferentes de “F” e “M”.
Quadro 8 - Restrição de Integridade de Domínio Discreto - Exemplo
CLIENTES 
CPF (PK) NOME IDADE SEXO 
11111111 MARIA 25 F 
22222222 JOÃO 19 M 
33333333 JOSÉ 15 C 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
de DOMÍNIO! 
Fonte: Elaboração própria da autora.
31
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
REFERENCIAL  A restrição de integridade REFERENCIAL indica que o conteúdo do atributo 
que representa a Chave Estrangeira deve ter valor correspondente no atributo que representa a 
Chave Primária. Por exemplo:
Quadro 9 - Restrição de Integridade Referencial - Exemplo
CLIENTES 
CPF (PK) NOME IDADE SEXO 
11111111 MARIA 25 F 
22222222 JOÃO 19 M 
33333333 JOSÉ 15 M 
VEÍCULOS 
PLACA 
(PK) COR MODELO 
CPFCLIENTE 
(FK) 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 AZUL VOLKSWAGEN 22222222 
XYZ5678 VERDE VOLKSWAGEN 33333333 
KLM1568 VERDE VOLKSWAGEN 444444444 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
REFERENCIAL! 
CLIENTES 
CPF (PK) NOME IDADE SEXO 
11111111 MARIA 25 F 
22222222 JOÃO 19 M 
33333333 JOSÉ 15 M 
VEÍCULOS 
PLACA 
(PK) COR MODELO 
CPFCLIENTE 
(FK) 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 AZUL VOLKSWAGEN 22222222 
XYZ5678 VERDE VOLKSWAGEN 33333333 
KLM1568 VERDE VOLKSWAGEN 444444444 
Essa linha não será 
inserida, pois viola a 
restrição de integridade 
REFERENCIAL! 
Fonte: Elaboração própria da autora.
SEMÂNTICA  A restrição de integridade de SEMÂNTICA indica que o conteúdo do atributo 
possui uma regra implantada que deve ser cumprida. Por exemplo:
Suponha que, na coluna VALOR, em PEDIDOS, tenha uma regra definida que o conteúdo desse 
atributo deve corresponder à soma de valores de ITEM_PEDIDOS. 
Quadro 10 - Restrição de Integridade de Semântica – Exemplo
PEDIDOS 
NUMPED 
(PK) DATA VALOR 
CPFCLIENTE 
(FK) 
10 10/03/2018 23,50 11111111 
20 25/03/2018 500,00 22222222 
ITEM_PEDIDOS 
NUMPED 
(PK) NUMITEM CODPROD QUANTIDADE 
VALOR 
UNITÁRIO 
10 1 100 1 5,50 
10 2 101 2 4,00 
10 3 102 1 10,00 
20 1 100 3 5,50 
Essa linha não será 
incluída, pois o valor 
deve corresponder ao 
total de valor dos itens 
do pedido 20, que seria 
16,50. 
Fonte: Elaboração própria da autora.
Atenção
O uso das restrições de integridade instaladas nos Bancos de Dados deve ser avaliado,pois, se muitas restrições forem 
definidas, poderá onerar o desempenho do uso do Banco de Dados.
32
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
Modelo Relacional – Operações de atualização
A atualização em Banco de Dados relacional é efetivada por três operações: INCLUSÃO, 
ALTERAÇÃO e EXCLUSÃO.
A operação de INCLUSÃO é executada para inserir linhas em uma relação/tabela. Nessa operação, 
deve ser indicado o conjunto de valores para os atributos da nova tupla/linha a ser criada. 
A operação de ALTERAÇÃO é executada para alterar valores de colunas/atributos em uma ou 
mais linhas/tuplas de uma relação/tabela, em função de uma condição ou todas as linhas serão 
alteradas. 
A operação de EXCLUSÃO é executada para eliminar linhas/tuplas em uma relação, que satisfaçam 
a uma determinada condição. Sem o que todas as linhas serão eliminadas.
Toda operação, antes de finalizada, deve verificar a existência de restrição de integridade no 
modelo relacional para identificar violação. Caso a violação aconteça, a operação não será 
executada, mas, para alteração e exclusão, podemos utilizar de dois tratamentos:
I. Realizar a operação em cascata, ou seja, refletir a operação nas tuplas/linhas referenciadas 
pela Chave Estrangeira (FK). Esse tratamento pode ser considerado para as operações 
de alteração e exclusão.
II. Utilizar a abordagem de nulificação, ou seja, modificar o valor dos atributos referenciados 
pela Chave Estrangeira (FK) para valores nulos. Esse tratamento somente é possível 
para a exclusão.
Exemplificando!
Vamos fazer as modificações nas tabelas abaixo e verificar os resultados. A tabela/relação 
VEÍCULOS possui os atributos Placa, Cor, Modelo, Código do cliente, representando o dono do 
veículo. A tabela/relação CLIENTE possui os atributos CPF, NOME, IDADE, SEXO.
Na inclusão, cria-se mais uma tupla/linha com os conteúdos referentes a cada atributo. 
Por exemplo, vamos realizar as seguintes operações:
a. incluir linha na relação/tabela VEÍCULOS: VEÍCULO = {PQR4567, ‘PRETO’, ‘FORD’, 22222222} 
b. incluir linha na relação/tabela VEÍCULOS: VEÍCULO = {XYZ4361, ‘MARROM, ‘FORD’, 
44444444} - a linha NÃO será incluída, pois viola restrição de integridade REFERENCIAL. 
Não existe na tabela/relação CLIENTES o CPF 44444444.
c. Alterar a informação COR do veículo PQR4567 para ‘BRANCO’. 
d. Alterar a Placa ‘ABC1234’ de VEÍCULOS para ‘AFG5332’.
33
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
e. Alterar o CPF do cliente 22222222 para 55555555 – NÃO será alterado, pois viola a restrição 
de integridade REFERENCIAL.
f. Alterar em CASCATA o CPF do cliente 22222222 para 55555555. 
g. Excluir em CASCATA o CPF do cliente 11111111 
h. Excluir em NULIFICAÇÃO o CPF do cliente 33333333.
Quadro 11- Inclusão de Linhas/tuplas
 VEÍCULOS 
PLACA 
(PK) COR MODELO
CPFCLIENTE 
(FK) 
JKL8050 VERMELHO FIAT 11111111 
ABC1234 
AFG5332 
AZUL WOLKSVAGEM
22222222 
55555555 
XYZ5678 VERDE WOLKSVAGEM 
33333333 
Null 
PQR4567 PRETO 
BRANCO FORD 
22222222 
55555555 
CLIENTES 
CPF (PK) NOME IDADE SEXO 
11111111 MARIA 25 F 
22222222 
55555555 
JOÃO 19 M
33333333 JOSÉ 15 M 
c. Conteúdo alterado.
d. Conteúdo alterado.
Mesmo sendo chave
primária não tem
referência em outra
f. Conteúdo alterado.
Mesmo sendo chave
primária, a referência
também foi alterada.
Efeito cascata.
a. Essa linha será incluída
com sucesso. Não viola
restrição de integridade.
g. Linhas excluídas: tabela
original CLIENTES e na
referenciada VEICULOS.
g. Linhas excluídas: Tabela
original CLIENTES e na
referenciada VEÌCULOS
h. Linha em CLIENTES excluída
e atributo CPFCLIENte,
referente a chave estrangeira
em VEÌCULOS igual a Null.
Fonte: Elaboração própria da autora.
Após as operações de atualização, ficamos com o seguinte conteúdo:
Quadro 12 - Resultado das operações de atualização - Exemplo
VEÍCULOS
PLACA (PK) COR MODELO CPFCLIENTE (FK)
AFG5332 AZUL VOLKSWAGEN 55555555
XYZ5678 VERDE VOLKSWAGEN Null
PQR4567 BRANCO FORD 55555555
CLIENTES
CPF (PK) NOME IDADE SEXO
55555555 JOÃO 19 M
33333333 JOSÉ 15 M
Fonte: Elaboração própria da autora.
34
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
álgebra Relacional – Operações de busca e recuperação
A Álgebra Relacional apresenta operações básicas de busca e recuperação de dados no modelo 
relacional. As operações são aplicadas nas relações/tabelas, tendo como resultado uma nova 
relação, que pode sofrer aplicações de novas operações. São elas: Projeção, Seleção, Produto 
Cartesiano, Junção, Diferença, União, Interseção.
PROJEÇÃO  representada pela letra grega pi (π), apresenta a lista de atributos/colunas desejados 
de uma tabela/relação. Na relação resultante, as linhas com conteúdo duplicado são eliminadas. 
Devemos considerar como duplicidade o conteúdo de todos os atributos juntos.
Expressão: plista de atributos (nome relação) 
 *** os atributos devem estar separados por vírgula.
Exemplo: Suponha a necessidade de apresentar o nome e a idade de todos os CLIENTES (Quadro 
13). Como ficaria?
pnome, idade (CLIENTES)
E qual seria a relação resultante?
Quadro 13 – Relação resultante Projeção - Exemplo
NOME IDADE
MARIA 25
JOãO 19
JOSÉ 15
Fonte: Elaboração própria da autora.
SELEÇÃO  representada pela letra grega minúscula sigma (σ), apresenta as linhas/tuplas de 
uma relação que atendam à condição estabelecida. São considerados todos os atributos na 
relação resultante. Para definir o atributo a apresentar, devemos utilizar a operação de Projeção 
combinada com a seleção.
Expressão: scondição (nome relação)
Entende-se por condição: 
 (valor ou atributo operador relacional valor ou atributo) operador lógico
 (valor ou atributo operador relacional valor ou atributo), sendo:
 operador relacional  > (maior), < (menor)
 >= (maior ou igual), <= (menor ou igual) 
 = (igual), != (diferente)
35
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
operador lógico  ^ (and), V (or), ¬ (not)
Exemplo 1: suponha a necessidade de apresentar os CLIENTES (Quadro 14) que tenham mais 
de 15 anos e são do sexo feminino. Como ficaria?
sidade>15 ^ sexo = ‘F’ (CLIENTES))
E qual seria a relação resultante?
Quadro 14 - Relação resultante Seleção - Exemplo
NOME IDADE
MARIA 25
Fonte: Elaboração própria da autora.
Exemplo 2: suponha a necessidade de apresentar o nome e a idade de todos os CLIENTES (Quadro 
15) que tenham mais de 15 anos. Como ficaria?
pnome, idade (sidade>15 (CLIENTES))
E qual seria a relação resultante? (Nesse caso, estamos combinando projeção e seleção para 
poder selecionar atributos).
Quadro 15 - Relação resultante Seleção - Exemplo
NOME IDADE
MARIA 25
JOãO 19
Fonte: Elaboração própria da autora.
UNIÃO  representada pelo símbolo U, a operação é realizada entre duas ou mais 
relações. A relação resultante listará a união dos conjuntos das relações envolvidas. 
Expressão: (operação de busca) U (operação de busca)
Suponha as seguintes relações e a necessidade de apresentar a lista com o nome de todos 
os clientes e de todos os vendedores.
Quadro 16 - Relações CLIEntES e VEnDEDORES
CLIENTES
CPF (PK) NOME IDADE SEXO
11111111 MARIA 25 F
22222222 JOãO 19 M
33333333 JOSÉ 15 M
36
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
VENDEDORES
CPF (PK) NOME SALÁRIO
55555555 MARIA DO CARMO 1.500,00
77777777 JÚLIO Da SILVa 2.300,00
66666666 aMÉLIa RODRIGUES 850,00
Fonte: Elaboração própria da autora.
Como ficaria a expressão?
pnome (CLIENTES) U pnome (VENDEDORES)
E qual seria a relação resultante?
Quadro 17 - Relação resultante União - Exemplo
NOME
MARIA
JOãO
JOSÉ
MARIA DO CARMO
JÚLIO Da SILVa
aMÉLIa RODRIGUES
Fonte: Elaboração própria da autora.
DIFERENÇA  representada pelo símbolo -, a operação é realizada entre duas ou mais 
relações. A relação resultante listará o conteúdo que pertence ao conjunto resultante 
da operação-A, relação apresentada à esquerda do sinal de operação e não pertence ao 
conjunto resultante da operação-B,relação apresentada à direita do sinal da operação. 
Expressão: (operação-A de busca) - (operação-B de busca)
Suponha as seguintes relações e a necessidade de apresentar a lista com o nome de todos 
os clientes que não possuem VEÍCULOS, ou seja, pertence ao conjunto de clientes, mas 
não pertence ao conjunto de veículos.
Como ficaria a expressão?
Quadro 18 - Relações CLIEntES e VEÍCULOS
VEÍCULOS
PLACA (PK) COR MODELO CPFCLIENTE (FK)
AFG5332 azUL VOLKSWaGEn 55555555
XYZ5678 VERDE VOLKSWaGEn Null
PQR4567 BRANCO FORD 55555555
37
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
CLIENTES
CPF (PK) NOME IDADE SEXO
55555555 JOãO 19 M
33333333 JOSÉ 15 M
Fonte: Elaboração própria da autora.
pcpf (CLIENTES) - pcpfcliente (VEÍCULOS)
E qual seria a relação resultante?
Quadro 19 - Relação resultante Diferença - Exemplo
CPF
33333333
Fonte: Elaboração própria da autora.
INTERSEÇÃO  representada pelo símbolo , a operação é realizada entre duas ou mais 
relações. A relação resultante listará o conteúdo que pertence a todos os conjuntos 
resultantes das operações.
Expressão: (operação-A de busca) (operação-B de busca)
Suponha as relações apresentadas no Quadro 20 e a necessidade de apresentar o CPF do 
cliente que possui dados cadastrados e tem veículo. Desse modo, precisamos apresentar 
o CPF que conste no conjunto de CLIENTES e no conjunto de VEÍCULOS.
Como ficaria a expressão?
pcpf (CLIENTES) pcpfcliente (VEÍCULOS)
E qual seria a relação resultante?
Quadro 20 - Relação resultante Interseção - Exemplo
CPF
55555555
Fonte: Elaboração própria da autora.
PRODUTO CARTESIANO  representado pelo símbolo 
X, a operação apresenta o cruzamento entre as relações, 
resultando em uma relação com os atributos das relações e o 
número de linhas equivalente ao produto das quantidades de 
linhas de cada relação. Por exemplo, se uma relação tem três 
linhas e outra tem duas, a relação resultante terá seis linhas. 
Atenção
As relações envolvidas em 
operações de UNIÃO, DIFERENÇA 
e INTERSEÇÃO devem possuir o 
mesmo número de atributos e de 
mesmo tipo.
38
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
Expressão: (Relação-A x Relação-B)
Considerando as relações CLIENTES e VEÍCULOS apresentadas no Quadro 21, qual seria 
a expressão?
(CLIENTES x VEÍCULOS)
E qual seria a relação resultante?
Quadro 21 - Relação resultante Produto Cartesiano - Exemplo
PLACA (PK) COR MODELO CPFCLIENTE (FK) CPF (PK) NOME IDADE SEXO
AFG5332 azUL VOLKSWaGEn 55555555 55555555 JOãO 19 M
AFG5332 azUL VOLKSWaGEn 55555555 33333333 JOSÉ 15 M
XYZ5678 VERDE VOLKSWaGEn Null 55555555 JOãO 19 M
XYZ5678 VERDE VOLKSWaGEn Null 33333333 JOSÉ 15 M
PQR4567 BRANCO FORD 55555555 55555555 JOãO 19 M
PQR4567 BRANCO FORD 55555555 33333333 JOSÉ 15 M
Fonte: Elaboração própria da autora.
JUNÇÃO  a junção de relações implica dar 
significado aos dados a partir do relacionamento 
lógico representado pela Chave Primária (PK) e 
pela Chave Estrangeira (FK). Para obter as linhas 
correspondentes ao significado lógico das relações 
elencadas, devemos SEMPRE igualar a Chave 
Primária (PK) com a Chave Estrangeira (FK) no 
produto cartesiano. Assim, estaremos selecionando 
somente as linhas correspondentes. 
Expressão: (schavePrimaria = chaveEstrangeira (Relação-A X Relação-B))
Essa é a expressão básica. A partir daí, podemos acrescentar condições, projetar atributos e 
utilizar mais de duas relações, bastando, para isso, somente igualar as Chaves Primárias e as 
Chaves Estrangeiras. 
Suponha as relações apresentadas no Quadro 22 e a necessidade de apresentar o NOME do cliente 
e a PLACA de seus VEÍCULOS. A necessidade da junção ocorre sempre que precisamos utilizar 
atributos de várias relações/tabelas, como é o caso aqui. NOME pertence à relação CLIENTES e 
PLACA pertence à relação VEÍCULOS. Identificadas as relações/tabelas que vamos representar, 
buscamos os atributos que estão representando o relacionamento entre elas, a Chave Primária e 
Atenção
O uso do produto cartesiano deve ser analisado 
com muita atenção, pois, se avaliarmos as linhas, 
vamos constatar que as relações se juntam e não 
consideram o relacionamento lógico representado 
pela Chave Primária (PK) e pela Chave Estrangeira 
(FK). Assim, as partes não correspondem logicamente. 
Portanto, devemos utilizar o produto cartesiano caso 
tenha a necessidade de fato de unir as relações sem 
considerar a ligação lógica.
39
aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS • CAPÍTULO 2
a Chave Estrangeira. Caso haja dúvidas, deve-se recorrer ao Modelo Lógico dos dados. Identificadas 
as chaves, devemos igualá-las na operação de seleção.
Então, como ficaria a expressão?
pnome, placa (sclientes.cpf = veículos.cpf (CLIENTES X VEÍCULOS))
E qual seria a relação resultante?
Quadro 22 - Relação resultante Junção - Exemplo
NOME PLACA
MARIA JKL8050
JOãO ABC1234
JOSÉ XYZ5678
Fonte: Elaboração própria da autora.
SEQUÊnCIa DE OPERaçÕES E OPERaçãO REnOMEaR 
( SEtInHa)
Em algumas situações, uma única operação não é suficiente 
para resolver todos os tipos de consultas, gerando a necessidade 
de realizar outra operação na sequência. Isso se dá porque 
somente podemos utilizar o mesmo conjunto de atributos 
para as relações envolvidas nas operações e nem sempre os 
atributos comuns são os que desejamos apresentar.
Para isso, podemos:
 » escrever as operações de forma agrupada, em uma única expressão da Álgebra Relacional, 
o que pode ficar extenso e sem compreensão.
 » aplicar uma operação a cada vez, criando relações de resultado intermediário, e 
representando da seguinte forma:
nome nova relação  operação da Álgebra Relacional
Considerando o exemplo da interseção, suponha que desejamos apresentar o NOME do cliente 
e não o CPF. O NOME não é um atributo comum e, portanto, só conseguiremos atender à 
necessidade se fizermos duas operações. Dessa forma:
R1(cpf)  pcpf (CLIENTES) pcpfcliente (VEÍCULOS)
pnome (scliente.cpf = R1.cpf (CLIENTES X R1))
Atenção
Quando se trabalha com mais de uma 
relação, a convenção dita que o nome 
dos atributos deve ser distinto. 
Quando não ocorre, devemos nos 
referir ao nome da relação para 
diferenciar os nomes, assim: CLIENTE.
NOME ou VENDEDOR.NOME.
40
CAPÍTULO 2 • aSPECtOS DE COnSIStÊnCIa E ManIPULaçãO DOS DaDOS
E qual seria a relação resultante?
Quadro 23 - Relação resultante Sequência Operações - Exemplo
NOME
JOãO
Fonte: Elaboração própria da autora.
Sintetizando
Vimos até agora:
 » Que a Teoria da Normalização foi definida para tornar as relações de dados estruturadas com vistas a evitar redundância.
 » Que relações não normalizadas utilizam um espaço em disco desnecessário, dificultam a manutenção dos dados e suporte 
ao Banco de Dados.
 » Que são apresentadas seis formas normais, mas que deixar a relação na 3ª forma normal já é um nível desejado para a 
maioria das relações.
 » Que estar normalizada em uma forma normal implica estar normalizada na forma normal anterior.
 » Que a manipulação dos dados nos modelos relacionais foi definida a partir dos conceitos estabelecidos na Álgebra 
Relacional.
 » Que as operações de alteração, realizadas nas relações, para movimentar os dados, somente são finalizadas se não violar as 
regras de integridade definidas.
 » Que a operação de alteração pode utilizar a forma de atualização em cascata para não violar restrição de integridade 
REFERENCIAL.
 » Que a operação de exclusão pode utilizar a forma de atualização em cascata ou nulificação para não violar restrição de 
integridade REFERENCIAL.
 » Que as operações de busca e recuperação apresentadas pela Álgebra Relacional são utilizadas para linhas/tuplas 
(elementos) ou seleção de algumas colunas/atributos, além de prover possibilidades de junção de duas ou mais relações/
tabelas.
 » Que as operações de conjuntos da Álgebra Relacional para várias relações devem considerar o mesmo argumento e tipo.
41
Introdução ao capítulo
Os Sistemas Gerenciadores de Banco de Dados(SGBDs) são construídos para funcionar como 
a ligação entre o Banco de Dados e os usuários. Devem atender à estrutura de um modelo de 
armazenamento de dados, mas, independentemente disso, para serem considerados um SGBD, 
devem possuir propriedades básicas como integridade, segurança, confiabilidade, concorrência, 
independência dos dados. Assim sendo, estarão de fato garantindo o atendimento às necessidades 
do usuário e do negócio que serão atendidos pelo Banco de Dados.
E quem são os profissionais responsáveis pelo Banco de Dados? Muito importante! Muitos 
profissionais são requeridos para construção, uso e manutenção dos Bancos de Dados. Cada um 
com sua função, não menos importante uma ou outra. De forma coordenada, encontra-se o 
sucesso. 
Mas os SGBDs não desempenham sua função sozinhos! O surgimento dos Bancos de Dados 
relacionais impulsionou a pesquisa no meio acadêmico e comercial para desenvolvimento de 
uma linguagem para manipulação dos dados. Foi quando surgiu a SEQUEL (Structured English 
Query Language), em 1974, mudando de nome entre 1976 e 1977 para SQL (Structured Query 
Language). 
A SQL é uma linguagem padronizada pela ANSI (American National Standarts Institute), o que faz 
com que todo fabricante de SGBD relacional a utilize. É uma linguagem que dispõe de diversos 
recursos para uso, como definição (Linguagem de Definição de Dados – DDL) e manipulação de 
dados (Linguagem de Manipulação de Dados – DML), tratamento de restrição de integridade, 
segurança (Linguagem de Controle de Dados – DCL) e concorrência (Linguagem de Controle de 
Transações – TCL). Os comandos são segmentados por tipo de ação. 
A Linguagem de Definição de Dados (DDL) representa o conjunto de comandos utilizados para 
criação das estruturas dos dados, como a criação do esquema e tabelas, definição dos atributos 
com seus respectivos tipos, tamanho e parâmetros de restrição de integridade, Chaves Primárias 
e Chaves Estrangeiras. A DDL contempla também a possibilidade de alteração das estruturas, 
pois a manutenção dos Bancos de Dados é uma constante, na medida em que sempre haverá 
uma nova necessidade a ser trabalhada, pois a empresa é dinâmica!
3
CAPÍTULO
SIStEMa GEREnCIaDOR DE BanCO 
DE DADOS – SQL (IntRODUçãO, 
DEFInIçãO E MOVIMEntaçãO 
DOS DADOS)
42
CAPÍTULO 3 • SIStEMa GEREnCIaDOR DE BanCO DE DaDOS – SQL (IntRODUçãO, DEFInIçãO E MOVIMEntaçãO DOS DaDOS)
A Linguagem de Movimentação de Dados (DML) representa o conjunto de comandos para 
movimentação dos dados, como inclusão, alteração, exclusão e consulta. No escopo deste capítulo, 
estaremos abordando a inclusão, a alteração e a exclusão, ficando a consulta para outro capítulo.
Vários são os SGBDs no mercado para uso nos modelos relacionais. Para este estudo, adotaremos 
o SGBDOR PostgreSQL. 
Segundo seu site oficial, o PostgreSQL é um Sistema Gerenciador de Banco de Dados 
objeto-relacional, criado a partir da Versão 4.2 do Postgres, desenvolvido pelo Departamento de 
Ciência da Computação da Universidade da Califórnia, em Berkeley. O PostgreSQL é disponibilizado 
com licença de código aberto liberal, que autoriza utilizar, modificar e distribuir, de forma 
particular, acadêmica ou particular sem qualquer ônus. 
O PostgreSQL suporta quase a totalidade do padrão SQL e as seguintes funcionalidades:
 » comandos complexos;
 » chaves estrangeiras;
 » trigger (gatilhos);
 » visões;
 » integridade transacional;
 » controle de concorrência multiversão.
Qualquer informação adicional, é possível encontrar neste site <https://www.postgresql.org/
docs/9.0/static/>.
Saiba mais
Para instalar o PostgreSQL, siga os passos:
 » entre no site <https://www.enterprisedb.com/thank-you-downloading-postgresql?anid=209628>;
 » escolha a versão 9.23 e o sistema operacional de sua máquina;
 » informe a password;
 » clique em next para prosseguir a instalação;
 » escolha as extensões que desejar.
Objetivos do capítulo 
 » Apreender conceitos de Banco de Dados, Sistema de Banco de Dados e Sistema 
Gerenciador de Banco de Dados (SGBD).
43
SIStEMa GEREnCIaDOR DE BanCO DE DaDOS – SQL (IntRODUçãO, DEFInIçãO E MOVIMEntaçãO DOS DaDOS) • CAPÍTULO 3
 » Conhecer as funções de profissionais que trabalham com Banco de Dados. 
 » Entender a história de criação da Linguagem de Consulta Estruturada.
 » Conhecer os grupos de comandos da SQL, segmentados por tipos de ações: DCL, DML, 
DCL, TCL. 
 » Aprender os comandos aplicados à Linguagem de Definição dos Dados (DCL).
 » Conhecer parâmetros para definição de restrição de integridade dos atributos. 
44
CAPÍTULO 3 • SIStEMa GEREnCIaDOR DE BanCO DE DaDOS – SQL (IntRODUçãO, DEFInIçãO E MOVIMEntaçãO DOS DaDOS)
Sistema Gerenciador de Banco de Dados (SGBD) 
Conceitos
O Sistema Gerenciador de Banco de Dados (SGBD) é o conjunto de programas que trabalham 
de forma ordenada e coordenada para administrar e manipular as estruturas de dados em um 
Banco de Dados. Todo modelo de Banco de Dados terá o seu SGBD, pois os dados somente 
são disponibilizados ao usuário por meio de SGBDs, você se recorda dessa premissa? Veja a 
representação do Sistema de Banco de Dados na Figura 1.
Os SGBDs utilizam-se da Arquitetura de 3 esquemas (Figura 6) para ser eficiente no emprego das 
informações dos Bancos de Dados, gerando, a cada nível, uma visão adequada. 
Figura 6 - arquitetura de 3 esquemas.
Fonte: Navathe; Ramez, 2011.
A arquitetura de 3 esquemas divide a visão em três níveis: externo, conceitual e interno. 
O nível externo não tem acesso à complexidade das estruturas definidas no Banco de Dados. 
Nesse nível, as informações são apresentadas de maneira simples e fácil de compreensão. 
Essas informações chegam aos usuários finais. O nível conceitual descreve os dados que estão 
armazenados e seus relacionamentos. Nesse nível, definem-se quais informações pertencem 
aos Bancos de Dados. Por fim, o nível interno, que é o mais baixo nível, representa como os 
dados efetivamente estão armazenados. No nível interno, serão armazenados os dados e os 
metadados (estrutura dos dados).
45
SIStEMa GEREnCIaDOR DE BanCO DE DaDOS – SQL (IntRODUçãO, DEFInIçãO E MOVIMEntaçãO DOS DaDOS) • CAPÍTULO 3
Características de um SGBD
Todo SGBD caracteriza-se por disponibilizar recursos que garantem a INTEGRIDADE, SEGURANÇA, 
CONCORRÊNCIA, INDEPENDÊNCIA DOS DADOS, CONTROLE DE REDUNDÂNCIA.
Mas o que significa cada característica?
INTEGRIDADE  significa garantir que dados estejam válidos e corretos. Somente dessa forma 
agregam valor ao negócio. Bases de dados inconsistentes não geram confiabilidade e representam 
um fator de insucesso do projeto. A integridade nos Bancos de Dados é garantida a partir das 
restrições de integridade, que são regras definidas para validação em tempo e inclusão, alteração 
e exclusão de informações no Banco de Dados. As restrições de integridade são criadas em 
tempo de definição das tabelas. 
SEGURANÇA  significa controlar acesso, remoção e alteração dos dados. O controle é exercido 
pela concessão de autoridade aos usuários do Banco de Dados. Essa autoridade pode ser em 
relação a colunas (atributos) ou a tabelas ou, ainda, ao esquema (Banco de Dados).
CONCORRÊNCIA  significa permitir que um mesmo recurso possa ser utilizado por mais de 
um usuário em um mesmo momento.
INDEPENDÊNCIA DE DADOS  significa manter os dados e suas estruturas de forma 
independente dos programas. Podemos classificar em: a) Independência de Dados Física 
– quando, diante da necessidade de alterar os dados, os programas de aplicação não serão 
afetados. Normalmente isso ocorre da necessidade de ajuste em desempenho; e b) Independência 
de Dados Lógica – quando é necessária uma alteração no esquema lógico, que também os 
programas de aplicação não serão afetados, a não ser os que estiverem relacionados com a 
nova necessidade implementada.
CONTROLE DE REDUNDÂNCIA  significa ter a mesma informação em várias relações. 
Quando se constrói um Banco de Dados a partir de modelos de dados, a redundância