Banco de Dados

Prévia do material em texto

Fundamentos de Bases de Dados 
 
 
 
Manuel Soares de Menezes 
(Notas de Aula) 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses i 
 
 
 
 
Prefácio 
 
 
“A motivação mais importante para o trabalho de pesquisa que resultou no modelo relacional, foi o 
objectivo de fornecer um limite nítido e claro entre os aspectos lógicos e os físicos na Gestão de Bases de 
Dados” 
 
- Frank Codd - 
 
 
Estas notas de aula são o resultado da compilação de apontamentos 
manuscritos elaborados pelo autor, quando este ministrou a disciplina de Base 
de Dados I, no curso de Engenharia Informática da Universidade Católica de 
Angola. 
 
O objectivo era elaborar uns apontamentos para os estudantes tivesse uma visão 
geral sobre a modelagem de Bases de Dados, o Projecto de Bases de Dados, e 
uma introdução a implementação do projecto de Base de Dados com SQL. 
 
 
Mas para elaborar esses apontamentos o autor consultou inúmeros livros e 
artigos espalhados pela Internet, mas as obras de Elmasri[2011], Heuser[2009], 
Ramakrishnan[2008], Rob[2010] e Setzer[2001], foram as que tiveram uma 
maior influência na concepsão dessas notas. 
 
É importante salientar que estas notas estão em fase de concepsão, logo elas 
possuem erros ortográficos, e provávelmente alguns erros de conteudo. 
 
Mas como pretendenmos utiliza-las em sala de aula, acredito que teremos a 
oportunidade para medir a sua receptividade, colher os subsídios necessáros 
para efectuar alguns melhoramentos, e eliminar os prováveis erros. 
 
Tenho plena consciencia que essa fase de teste levará alguns anos, e só depois 
de ter a absoluta certeza que o texto atingiu os objectivos, e não possui nenhum 
erro ortográfico nem conceitual, pensarei em publica-lo. 
 
Para terminar, devo salientar que essas notas não poderiam ser apresentadas 
com a qualidade que possuem, sem a ajuda de algumas pessoas, em especial 
os meus alunos: 
 
- Cristina Manuel dos Santos; 
- Emiliana Neide Nanjepele Adelino; 
- Jeovany Garcia Sassinda Afonso; 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses ii 
 
que sem qualquer remuneração, passaram horas afio a desenhar as figuras que 
têm uma qualidade que me enche de orgulhoso, 
 
e ao meu aluno: 
 
- Hoctair Pepe de Carlos Bernardino 
 
que tem-se mostrado incansável com o trabalho de formatação e a junção dos 
vários ficheiros enviados por mim. 
 
Como espero que no futuro posso acrecentar os nome de mais estudantes, e o 
nome colegas meus, convido-os a participar no enrequicimento do texto. 
 
Estas notas de aula contêm os seguintes temas: 
 
- Introdução às Bases de Dados; 
 
- Modelo de Entidade e Relacionamento; 
 
- Modelo de Entidade e Relacionamento Estendido 
 
- Modelo Relacional 
 
- Conversão do Modelo Entidade e Relacionamento para o Modelo Relacional 
 
- Normalização 
 
- Calculo e Álgebra Relacional (por escrever) 
 
- SQL- Criação de Tabelas 
 
- SQL – Manipulação de Tabelas 
 
- SQL- Consultas Simples 
 
- Bibliografia 
 
 
Luanda aos 15 de março de 2023. 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 1 
 
 
1 
Capítulo 
Introdução às Bases de Dados 
 
“Reparou que todas as letras da palavra database (base de dados, em inglês) são digitadas com a mão esquerda? 
Sabemos que a disposição do teclado da máquina de escrever (QWERTY) foi projectada, para facilitar o uso 
uniforme de ambas as mãos. Conclui-se, que escrever sobre bases de dados, além de ser algo não natural, é bem 
mais difícil do que parece.” 
 - Anônimo - 
 
1.1 Dados e Informação 
 
Todos nós já ouvimos falar em dados e informação. Mas o que é de facto dado 
e o que é informação? Qual a diferença entre eles? 
 
Vamos clarificar esses conceitos com um exemplo. Suponhamos que temos a 
seguinte letra: A. 
 
Qual é o significado de “A”? Por si só, o valor “A” não tem qualquer significado. 
É como se tivéssemos uma letra dentro de um saco com diversas letras. Embora 
um conjunto de letras possam constituir uma palavra, se elas forem analisadas 
de forma separada, e se não estiverem integradas num determinado contexto, 
não têm nenhum significado, e não são uteis há sociedade. Então, estamos em 
condições de efectuar a seguinte definição: 
 
Dados são elementos ou valores discretos, que não têm qualquer significado 
para há sociedade. 
 
Por outro lado, as informações são sequencias de dados que são uteis e têm 
algum significado para há sociedade. Nesse contexto podemos efectuar a 
seguinte definição: 
 
Informação é o resultado do processamento ou da interpretação de dados, que 
tem algum significado para há sociedade. 
 
O leitor interessado em aprofundar esses conceitos, consulte o artigo de 
Valdemar Setzer [2015]. 
 
Contudo, a informação é muito poderosa e vital para as organizações 
(empresas), por esse facto ela deve possuir as seguintes propriedades: 
 
Actualidade: a informação deve ser o mais actual possível para facilitar o 
processo de tomada de decisão. 
 
Correcta: as organizações têm de ter a capacidade para verificar se as 
informações que possuem estão correctas, para que possam ser processadas, 
e para que as tomadas de decisões sejam assertivas. 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 2 
 
 
Relevância: a informação ao dispor de uma organização (empresas), deve ser 
selecionada e filtrada para que a tomada de decisão seja feita sobre o que se 
considerado relevante, e não em informações fúteis. 
 
Disponibilidade: a informação deve estar disponível e acessível. Se a informação 
não estiver disponível no momento exato que é necessária, as tomadas de 
decisões podem ser errôneas, e causar enormes prejuízos financeiros e 
estruturais às empresas e à sociedade. 
 
Legibilidade: a informação deve ser fornecida de tal modo que seja facilmente 
interpretada pelos seus destinatários. 
 
1.2 Conceito de Base de Dados 
 
Para garantir o funcionamento de um supermercado, o Director de informática 
decidiu adquirir quatro sistemas informáticos independentes para tratar das 
seguintes operações (funcionalidades): 
 
Produção: Sistema para controlar a fabricação de alguns artigos, como por 
exemplo o pão. Para a produção do pão, necessitamos de uma receita que 
envolve os seguintes artigos: farinha, sal e fermento. Logo, para realizar essa 
operação, esse sistema necessita dos seguintes dados: código do artigo, nome 
do artigo, quantidade existente e preço de venda. 
 
Stock: Sistema para controlar por artigo a quantidade existente. Logo, para 
realizar essa operação, esse sistema necessita dos seguintes dados: Código do 
artigo, nome do arquivo, quantidade existente, preço de compra e preço de 
venda. 
 
Inventário: Sistema para contar a quantidade de artigos existente num 
determinado momento. Logo para realizar essa operação, esse sistema 
necessita dos seguintes dados: Código do artigo, nome do artigo e quantidade 
inventariada, preço de compra e preço de venda. 
 
Vendas: Sistemas para controlar as vendas dos artigos ao público. Para realizar 
essa operação, esse sistema necessita dos seguintes dados: código do artigo, 
nome do artigo, quantidade existente, e o preço de venda; 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 3 
 
É evidente que estes sistemas não são suficientes para garantir o funcionamento 
do supermercado. Para que isso aconteça, é necessário adquirir os seguintes 
sistemas: 
 
Encomendas: Sistema para controlar as encomendas feitas aos fornecedores.Logo, para realizar essa operação, esse sistema necessita dos seguintes dados: 
código do fornecedor, nome do fornecedor, código da encomenda, e por cada 
encomenda, o código dos artigos encomendados, nome desses artigos, 
quantidades encomendadas e preço de compra. 
 
Contabilidade: Sistema para controlar a situação financeira da empresa, ou seja, 
um sistema para apurar a quantidade de dinheiro que sai da empresa para pagar 
os fornecedores, a água, a luz e outras despesas, e quantidade de dinheiro que 
entra na empresa pelas vendas dos artigos. Logo, para realizar essa operação, 
esse sistema necessita dos seguintes dados: por cada encomenda, o código do 
fornecedor, nome do fornecedor, código da encomenda, valor a pagar, e por 
cada dia, o valor das vendas realizadas nesse dia. 
 
Como esses sistemas foram desenvolvidas separadamente, temos o problema 
de redundância de Dados. A redundância de Dados ocorre quando uma 
informação está representada no sistema mais do que uma vês. Para este caso, 
são redundantes as informações referentes aos artigos, porque são repetidas 
nos ficheiros que compõem cada um dos sistemas adquiridos. 
 
Este tipo de solução tecnológica, que denominamos por arquitectura de 
software, provoca os seguintes problemas: 
 
Entrada repetida da mesma informação: a mesma informação tem de ser 
inserida no sistema várias vezes. Para o exemplo anterior, os dados de um artigo 
têm de ser inseridos no sistema que controla as compras, no sistema de 
produção de artigos e no sistema de venda ao publico. Além de exigir trabalho 
desnecessário, a entrada repetida da mesma informação pode resultar em erros 
de transcrição de dados. 
 
Inconsistência de dados: cabe ao utilizador a responsabilidade de garantir a 
sincronia dos sistemas. Essa dependência humana, é muito susceptível a erros, 
porque podem ocorrer por um lado, erros de digitação, e por outro, operações 
de remoção de elementos que podem ser feitos num sistema e não ser feito nos 
restantes. 
 
Para suprir esses problemas, devemos utilizar um único arquivo que deve ser 
compartilhado por todas as operações que a empresa pretende informatizar. A 
essa propriedade dá-se o nome de compartilhamento de dados. 
 
Definição: o compartilhamento de dados é uma arquitectura de software que 
possui a seguinte propriedade: cada dado é armazenado uma e apenas uma vez 
e acedido por todos os utilizadores de uma empresa. 
 
Definição: uma base de dados é um conjunto de dados compartilhados, 
armazenados num único arquivo, denominado por repositório. 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 4 
 
 
 
 
Contudo os dados armazenados nesse repositório, possuem a seguinte 
propriedade: satisfazem as necessidades de informação de um conjunto de 
utilizadores, e possuem um conjunto de relacionamento entre esses dados. 
 
Definição: uma Base de Dados é um conjunto de dados, denominado por 
entidades, armazenado num repositório que descreve o funcionamento de uma 
organização. Esse repositório possui os dados que satisfazem as necessidades 
de informação de todos os utilizadores desse organização, e as relações entre 
esses dados. 
 
Por exemplo: uma base de dados para uma Universidade poderia ser conter as 
seguintes informações: 
- Entidades: alunos, professores, disciplinas, cursos e turmas. 
- Relacionamentos: alunos por professores, alunos por disciplinas, alunos por 
cursos, alunos por turmas, professores por disciplinas, professores por cursos, 
professores por turmas, etc. 
 
1.3 Sistema de Gestão de Base de Dados 
 
Um Sistema de Gestão de Base de Dados (SGBD) é uma coleção de programas 
que permite aos utilizadores criar e manipular uma base de dados. Esse Sistema 
é um software que permite a definição, recuperação, manipulação e 
compartilhamento de acesso à uma base de dados. 
 
Entendemos por: 
 
Definição, a especificação dos tipos, das estruturas, e das restrições para os 
dados que possam ser armazenados na Base de Dados; 
 
Recuperação, a operação de gravação de dados em algum dispositivo 
magnético que possa ser controlado pelo SGBD; 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 5 
 
Manipulação, a execução de funções como consulta a Base de Dados, para 
recuperar dados específicos, e actualizar a Base de Dados para que está reflicta 
as mudanças existentes no mundo real; 
 
Compartilhamento, a possibilidade de vários utilizadores ou aplicações, 
acederem ao mesmo tempo aos dados armazenados na Base de Dados. 
 
Apresentamos a seguir, uma figura que ilustra em termos gerais, a estrutura 
típica de um SGBD com base no modelo relacional. 
 
 
 
Mas para realizar essas operações, o SGBD relacional, possui uma linguagem 
de programação, denominada por SQL (Structured Query Language) que é 
composta pelos seguintes subconjuntos: 
 
DDL- Data Definition Language: Instruções para definir as tabelas que compõem 
à Base de Dados; 
 
DML- Data Manipulation Language: Instruções para manipular o conteúdo das 
tabelas da Base de Dados; 
 
TCL- Transaction Control Language: Instruções que efectuam o registro 
permamente das alterações feitas nas linhas das tabelas da Base de dados; 
 
DQL- Data Query Language: Instruções que efectuam a extração de 
informações na Base de Dados; 
 
DCL- Data Control Language: Instruções para o controle de acesso aos dados e 
a gestão de permissões dos utilizadores; 
 
Na figura a seguir, mostramos os comandos associadas a cada subconjunto da 
linguagem SQL. Contudo, devemos salientar que nem todos os autores utilizam 
essa classificação. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 6 
 
 
Fonte: EduRev: Computer Science Engineering (CSE): DataBase Management System (DBMS) 
 
Em função dessa linguagem, o SGBD apresenta os seguintes recursos: 
 
1º- Grande capacidade de gestão de informação: qualquer SGBD tem a 
capacidade de armazenar informações para sistemas simples, como uma 
agenda telefônica, e para sistemas complexos, como um sistema de reserva de 
passagens aéreas. Em ambos os casos, o SGBD tem a capacidade de garantir 
estabilidade, segurança e confiança, independente da quantidade de 
informações que estão armazenadas; 
 
2º- Redundância de Dados: qualquer SGBD tem a capacidade de reduzir ao 
máximo, ou mesmo eliminar a redundância de informações que são 
responsáveis pelas inconsistências de dados; 
 
3º- Facilidade de acesso: qualquer SGBD tem a capacidade de permitir o acesso 
concorrente a informação, ou seja, que a mesma informação possa ser 
partilhada por vários utilizadores; 
 
4º- Segurança de Dados: qualquer SGBD tem a capacidade de garantir 
segurança ao acesso aos dados através do controlo de senhas, e limitar as 
movimentações dos utilizadores na Base de Dados através gestão de 
permissões; 
 
5º- Garantia de Integridade: qualquer SGBD tem a capacidade de garantir que 
os valores dos dados que serão armazenados na Base de Dados, satisfaçam 
certas restrições que garantem a coerência e consistência da informação; 
 
6º- Facilidade de Migração: qualquer SGBD tem a capacidade de permitir a 
transferência de dados entre as Bases de Dados. Ao acto de transferir as 
informações de uma Base de Dados para outra, dá-se o nome de Migração. 
 
Os SGBD podem ser classificados em duas categorias: 
 
Os proprietários, que são desenvolvidos por grandes empresas de software 
multinacionais como por exemplo a ORACLE, IBM, Microsoft, cuja utilização é 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 7 
 
feita com base em licença, que são extremamente caras. Fazemparte desses 
SGBD, o Oracle, o DB2, e o SQLSERVER. 
 
Os de código aberto “open source”, que normalmente são desenvolvidos por 
universidades, e podem ser utilizados sem a necessidade de pagar licenças. 
Fazem parte desses SGBD, o mySQL, FireBird, e o PostgreeSQL. 
 
1.4 Sistema de Base de Dados 
 
Entendemos por Sistema de Base de Dados, a união entre a Base de Dados e 
o SGBD, cuja estrutura genérica pode ser descrita pela seguinte figura: 
 
 
Fonte: Elsmari-Sistemas de Banco de dados 
 
O Sistema de Base de dados, possui as seguintes propriedades: 
 
Abstracção de dados: num sistema tradicional de ficheiros, a estrutura dos 
ficheiros com os dados está inserida nos programas que manipulam esses 
ficheiros. Com este tipo de estrutura, a alteração os dados em um ficheiro, obriga 
à alteração de todos os programas que manipulam esse ficheiro. Num sistema 
de Base de Dados, a estrutura dos ficheiros está no catálogo do SGBD e, 
portanto, separada dos programas que os manipulam. 
 
Independência dos dados: O catálogo do SGBD guarda para cada ficheiro uma 
série de informações denominadas por meta-dados. Essas informações tornam 
o SGDB independente da Base de Dados, e permite que o SGBD funcione com 
Base de Dados diferentes. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 8 
 
Suporte de múltiplas visões dos dados: Fornecer diferentes perspectivas (visões) 
dos dados para diferentes utilizadores. Uma visão pode ser um subconjunto de 
dados da Base de Dados, ou um subconjunto de dados virtuais obtidos a partir 
de dados da Base de Dados. 
 
Partilha de dados e acesso multi-utilizador: O SGBD garante que cada 
transacção ou é executada correctamente ou é abortada por completo, ou seja, 
quando ocorrer alguma falha na execução de uma transação, o SGBD restaura 
o estado da Base de Dados para o estado que está tinha antes dessa ocorrência. 
 
1.5 Utilizadores de um SGBD 
 
Os utilizadores de uma Base de Dados podem ser classificados em diversas 
categorias de acordo com as suas necessidades de acesso as funcionalidades 
do SGDB, e podem ser: 
 
Administradores de Base de Dados “DataBase Administrator”, são profissionais 
de informática que são responsáveis por autorizar acesso ás Bases de Dados, 
coordenar e monitorar a sua utilização. O DBA é responsável por resolver 
problemas como quebra de segurança ou baixo desempenho das Bases de 
Dados. 
 
Projectistas de Base de Dados são profissionais de informática que têm a 
responsabilidade de identificar os dados a serem armazenados nas Bases de 
Dados, e escolher estruturas de dados apropriadas para representar e 
armazenar tais dados. Os projectistas de Base de Dados, interagem com os 
utilizadores e definem visões das Bases de Dados para adequar as 
necessidades de informação de cada grupo de utilizadores. 
 
Analistas de sistemas são profissionais de informática que determinam os 
requisitos dos utilizadores finais, especialmente dos utilizadores comuns, e 
desenvolvem as funcionalidades que esses utilizadores necessitam para atender 
aos seus requisitos; 
 
Programadores de aplicações são profissionais de informática que implementam 
as funcionalidades projectadas pelos analistas de sistemas, através de 
programas de computador. 
 
Utilizadores finais são profissionais de várias áreas do conhecimento humano, 
que necessitam de aceder as Bases de Dados para consultar, modificar e 
imprimir relatórios. 
 
1.6 Modelos de Dados 
 
Modelo Hierárquico 
 
Criado na década de 1960 pela IBM, o modelo Hierárquico foi considerado o 
primeiro modelo de Base de Dados. Nesse modelo, os dados estavam 
organizados em estrutura de dados do tipo árvore, onde cada átomo continha 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 9 
 
um registro, e cada registro era composto por um conjunto de campos (atributos). 
As ligações entre os registros caracterizavam-se por serem relacionamentos 
com uma cardinalidade de um-para-muitos. Por esse facto, o modelo Hierarquico 
ficou conhecido com uma base de dados um-para-muitos. Mas com o 
lançamento da base de dados relacional, este modelo perdeu a sua 
popularidade, apesar de ainda ser utilizado para algumas aplicações. 
Modelo em Rede 
 
O modelo em Rede surgiu como uma extensão do modelo Hierárquico, com a 
substituição da estrutura de dados do tipo árvore, pela estrutura de dados do tipo 
grafo. Este modelo foi desenvolvido por um grupo de trabalho, que tinha por 
objectivo terminar um padrão para as estruturas e as linguagens dos SGDB. 
Esse grupo, denominado por CODASYI (Conference On Data Systems 
Language) estabeleceu um padrão que foi aceite pela comunicade científica da 
altura, e surgiram muitos produtos comerciais, que evoluiram, introduzindo 
linguagens e caracteristias completamente independents. Uma dessas 
extensões deu origem ao Modelo Relacional. 
 
Modelo Relacional 
 
O modelo relacional apareceu no início dos anos 70 do século passado, e tem 
como base a teoria dos conjuntos e a álgebra a relacional. Este modelo mostrou-
se ser mais flexível e mais adequado do que os modelos Hierárquico e em Rede, 
para resolver os problemas que se colocavam na altura a nível da concepção e 
implementação de Bases de Dados. A sua estrutura fundamental baseia-se na 
tabela ou relação. Uma tabela é constituída por um ou mais campos, 
denominados por atributos, que contêm o tipo de dados que a Base de Dados 
irá armazenar. Para este modelo, uma Base de Dados é um conjunto de tabelas 
que se relacionam, e que possuem algumas restrições para garantir a sua 
integridade e coerência. 
 
Modelo Orientado a Objetos 
 
O modelo Orientado por Objectos começou a tornar-se comercialmente viável 
nos meados dos anos 80 do século passado. O seu aparecimento deveu-se as 
limitações de armazenamento de informação do modelo Relacional, que não 
permitia que se desenvolvesse sistemas complexos como os sistemas de 
informações geográficas (SIG), sistemas de desenho assistido por computador 
(CAD-CAM), que necessitam de tipos de dados mais complexos. Mas quando 
essas Bases de Dados foram introduzidas algumas das falhas do modelo 
Relacional tornam-se perceptíveis e foram solucionadas, tornando desse modo, 
as Bases de Dados orientados por objetos mais viradas para aplicações 
especializadas, e as Bases de Dados Relacionais viradas para resolver os 
problemas de negócios das empresas. 
 
Modelo Objeto-Relacional 
 
Embora alguns SGBD possuem a capacidade de manipular objetos complexos, 
como imagem, som e vídeo, bem como alguns recursos de orientação por 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 10 
 
objetos, isso não impediu que os sistemas puramente orientados por objetos 
fossem desenvolvidos com um outro modelo de dados. Este modelo contêm a 
implementação de uma camada de abstração de dados em cima dos métodos 
relacionais, o que torna possível a manipulação de dados mais complexos. 
 
Modelo NoSQL 
 
Um dos grandes desafios actuais da área de informática é a manipulação e 
processamento de grandes quantidades de dados no contexto do Big Data. 
NoSQL (Not only SQL) é um termo utilizado para definir um tipo de Base de 
Dados que não segue normas das tabelas presentes nas Bases de Dados 
Relacionais. A quantidade de dados gerada diariamente em vários domínios 
como a web, as redes sociais, e as redes de sensores, estão na ordem de 
algumas dezenas ou centenas de Terabytes. Uma das tendências para 
solucionar os diversos problemas e desafios gerados pelo contexto Big Data é o 
movimento denominado NoSQL. 
 
1.7 Fases do Projecto de uma Base de Dados 
 
A figura a seguir, ilustra o esquema geral onde são descritas as diferentes fasespara o desenho de uma Base de Dados. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 11 
 
 
Fonte: Elsmari-Sistemas de Banco de dados 
 
1º-Levantamento e Análise de Requisitos: é a primeira etapa do projeto de Bases 
de Dados e tem por objectivos: 
 
a) identificar os possíveis utilizadores para definir o objectivo do projecto; 
 
b) identificar as deficiências do sistema informático actual, se existir; 
 
c) estabelecer as metas e os objectivos para o novo sistema; 
 
d) verificar se é possível informatizar o problema (viabilidade); 
 
d) estimar os custos da implementação e analisar os seus benefícios; 
 
e) preparar um cronograma para a implementação do projecto. Nesta fase é 
necessário que a equipe de desenvolvimento do projecto, os analistas de 
sistemas, tenham um completo domínio das regras de negócio da organização 
(empresa). Para realizar este estudo pode-se utilizar várias ferramentas, tais 
como: entrevistas, análise dos procedimentos, análise dos documentos 
utilizados na empresa, questionários etc. 
 
O objetivo dessa fase é identificar os factos do mundo real, que são relevantes 
para desenvolver o novo software. Esta fase de pré-modelagem é uma das mais 
importantes do projecto de Bases de Dados, porque ela é responsável pela 
qualidade da solução que se pretende desenvolver. Esse levantamento pode ser 
feito por várias técnicas de especificação de requisitos. Para aprofundar esse 
assunto, recomendamos que o leitor consulte o Capitulo 8 - Pressman [2016] ou 
o Capítulo 4 - Sommerville [2011]. O processo de levantamento de requisitos 
termina com a elaboração de um dossier que possui a especificação formal dos 
dados no formato texto, que é denominado por minimundo. 
 
2º-Projecto Conceitual: está fase consiste em especificar os requisitos criados 
na fase anterior para um modelo de dados. O modelo de dados mais utilizados 
para especificar esses requisitos são o Modelo de Entidade e Relacionamento 
(MER) que será objecto de estudo nos próximos capítulos, e a Unifield Modeling 
Language (UML) que não abordaremos nestas notas. Contudo é importante 
frisar que esses modelos descrevem o conteúdo da informação, e não as 
estruturas onde essa informação será armazenada, e são independentes 
do SGBD que será utilizado. 
 
3º-Projecto Lógico: está fase consiste em transformar o modelo de dados 
desenvolvido na fase anterior para o modelo interno. O modelo interno consiste 
no detalhe das tabelas, dos relacionamentos, dos tipos de dados das colunas, 
das restrições de integridade, das visões, etc. Os modelos internos mais 
utilizados são o Modelo Relacional que estudaremos nestas notas e o modelo 
Objecto-Relacional que não abordaremos. Esta fase continua a ser 
independente do SGBD, e termina com a produção de um esquema de uma base 
de dados, muito parecida com o modelo conceitual, mas com os detalhes dos 
http://www.dicasdeprogramacao.com.br/o-que-e-um-sgbd/
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 12 
 
dados. O refinamento do Projecto Lógico é uma etapa opcional, que consiste em 
identificar os potenciais problemas, e aplicar as técnicas de normalização para 
melhorar o desempenho do futuro sistema. 
 
4º-Projecto Físico: está é a fase final de um projeto de uma Base de Dados. 
Nesta fase vai-se definir os detalhes técnicos da implementação como por 
exemplo, a forma como os dados serão armazenados, os scripts para a criação 
dos objectos na base de dados (tabelas, visões, colunas, funções, ...), as 
permissões dos utilizadores, etc. Esta etapa está muito ligada a tecnologia 
do SGBD que será utilizado. 
 
Para aprofundar as fases de um projecto de uma Base de dados, que muitos 
autores denominam por Ciclo de Vida de uma Base de Dados, recomendamos 
que o leitor consulte o Capítulo1 - Teorey [2006]. 
 
Uma Base de Dados bem projectada é a base para o sucesso do sistema que 
se pretende desenvolver. As primeiras etapas desse projeto são de extrema 
importância, porque dela depende a criação de Base de Dados que satisfaça as 
reias necessidades dos clientes, enquanto que a última etapa está mais ligada à 
tecnologia do SGBD que iremos utilizar. 
 
1.8 Ferramentas CASE 
 
Ferramentas CASE (Computer-Aided Software Engineering) são instrumentos 
computadorizados que servem para auxiliar o desenho de sistemas no processo 
de Engenharia de Software. Em outras palavras, são softwares que têm por 
finalidade ajudar a desenvolver outros softwares. 
 
Nestas notas estamos interessados em ferramentas CASE específicas para 
auxiliar a modelagem da Bases de Dados. Mas como existem no mercado muitas 
ferramentas disponíveis, vamos escolher uma que se adeque ao nosso processo 
de aprendizagem, mas que seja disponibilizada de forma gratuita. 
 
Como exemplo de ferramentas para modelagem temos: DBDesigner, MySQL 
Workbench Design, PowerArchitect, Oracle’s Designer, Draw.io, ERWin e o 
brModelo. 
 
Nestas notas, utilizaremos o Draw.io, para desenhar o Modelo de Entidade e 
Relacionamento, porque para além de ser uma ferramenta gratuita (freeware), 
ela está voltada para ensino. 
 
1.9 Leituras Recomendadas 
 
Para aprofundar os assuntos abordados neste capítulo, recomendados que o 
leitor consulte o artigo: 
 
 Setzer W.;- Dado, Informação, Conhecimento e Competência, 
Departamento de Ciências de Computação, Instituto de Matemática 
http://www.dicasdeprogramacao.com.br/o-que-e-um-sgbd/
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 13 
 
Estatística, Universidade de São Paulo, 2015 
(http://www.ime.usp.br/~vwsetzer/dado-info-Folha.html) 
 
 
e os seguintes livros: 
 
 Date C. J;- Introdução a Sistemas de Banco de Dados, Parte1- Conceitos 
Básicos, Capitulo 1- Visão Geral do Gerenciamento de banco de Dados e 
Capitulo 2-Arquitectura de Sistemas de Banco de Dados, tradução da 8ª 
edição americana, LTC, 2004 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 1- Banco de Dados e usuários de Banco de Dados 
e Capitulo 2- Conceitos de Arquitetura do Sistema de Banco de Dados, 
tradução da 6ª edição americana, São Paulo, Pearson Addison Wesley, 
2011. 
 
 Heuser C. A.;- Projeto de Banco de Dados, 6ª Edição, Instituto de 
Informática da UFRGS, Capítulo 1- Introdução, Porto Alegre, Bookman, 
2009 
 
 Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, Capítulo 1- Sistemas de Banco de Dados e Capítulo 2- 
Modelo de Dados, tradução da 8ª edição americana Edição, Cengage 
Learning, 2010. 
 
 Silberschatz A., Korth F. K, Sudarshan S.; - Sistema de Banco de Dados, 
Rio de Janeiro, Elsevier, 2012 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 14 
 
 
2 
Capítulo 
Modelo de Entidade e Relacionamento 
 
“Uma base de dados é uma coleção de dados operacionais armazenados, utilizados pelos sistemas de 
aplicação de uma determinada organização.” 
 
 - Date - 
 
2.1 Introdução 
 
Em março de 1976, o cientista da computação chinês, Peter Pin-Shan Chen pu-
blicou um trabalho com o título: "The Entity-Relationship Model: Toward the uni-
fied view of data", Chen [1], no qual definia uma possível abordagem para o pro-
cesso de modelagem dos dados. 
 
Esse trabalho foi amplamente aceite pela comunidade científica, e apesar de ter 
quase 50 anos, continua muito actualizado,e é a principal referencia para a mo-
delagem de Projectos de Bases de Dados. 
 
2.2 Entidades 
 
Uma entidade é um ente, um objecto do mundo real que é distinto de todos os 
outros objectos. Por exemplo, um livro de uma biblioteca é uma entidade con-
creta, enquanto que, um financiamento de um banco é uma entidade abstracta. 
 
Definição: entendemos por conjunto de entidades, o conjunto de todos os ob-
jectos que possuem as mesmas características. 
 
Por exemplo, o conjunto de todas os empregados de uma empresa, pode ser 
definido como o conjunto entidade EMPREGADO. De igual modo, o conjunto de 
todos os empréstimos de um banco comercial, pode ser definido como o conjunto 
de entidade EMPRÉSTIMO. 
 
No Diagrama de Entidade e Relacionamento (DER), os conjuntos de entidades 
são representada por um retângulo (notação original de Peter Chen), e contêm 
no seu interior o seu nome em letras maiúsculas. Por exemplo: 
 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 15 
 
Contudo, os conjuntos de entidades que descrevem um determinado problema, 
podem não ser disjuntos. 
 
Por exemplo, a entidade CLIENTE representa todos os clientes de um banco, 
enquanto que a entidade EMPREGADO representa todos os empregados do 
mesmo banco. Mas nesse universo podemos ter pessoas que podem pertencer 
a entidade CLIENTE, ou a entidade EMPREGADO, ou a ambos, ou a nenhuma. 
 
O conceito de conjunto de entidades é imprescindível para modelar as regras de 
negócio de qualquer organização. Vamos clarificar essa afirmação: 
 
Problema: uma clínica necessita de controlar as consultas médicas que realiza, 
acompanhar os pacientes que atende, e manter actualizado o seu estado clínico. 
Para cada médico a clínica possui uma ficha com o número, nome, endereço, 
especialidade, etc., e para cada paciente, a clínica possui uma outra ficha com 
o nome, endereço, data de nascimento, sexo. Todas as consultas são registra-
das numa terceira ficha com as seguintes informações: médico, paciente e o 
diagnóstico. 
 
Quais são os conjuntos de entidades que estão descritas neste problema. Ob-
serve que nessa descrição existem médicos, pacientes, exames e consulta. Es-
ses objectos são entes que participam nas actividades desse problema, têm um 
significado próprio, logo entidades. 
 
Boas Prácticas: as entidades devem ser escritas no singular em letras maiús-
culas. 
 
Observação: devemos considerar como fortes candidatos para o conjunto de 
entidades, as palavras escritas num texto que gramaticalmente são substantivos. 
 
Porém, a existência de entidades não permite que as informações que ela con-
tém possa relacionar-se com outras entidades. Para permitir a relação entre elas, 
temos de estudar um novo conceito. 
 
2.3 Relacionamentos 
 
2.3.1 Conceitos 
 
Um relacionamento é uma associação entre uma ou várias entidades. Por exem-
plo, num banco temos um relacionamento entre clientes e contas correntes. 
 
No Diagrama de Entidade e Relacionamento (DER), os relacionamentos são re-
presentados por losângulos (notação original de Peter Chen). 
 
Por exemplo, no relacionamento, 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 16 
 
 
 
 
temos um conjunto de objectos chamado por EMPREGADO, um conjunto de 
objectos chamado por FABRICA, e um conjunto de associações que relacionam 
os empregados as fábricas, denominadas por trabalham. 
 
Em termos matemáticos, um relacionamento R é formada por um conjunto de 
pares não ordenados (ei, mi) tal que, ei pertence a entidade E, e mi pertence a 
entidade M, e podem ser representados por um diagrama de ocorrência: 
 
 
 
 
 
O grau do relacionamento é determinado pelo número de conjuntos de entidades 
envolvidas nesse relacionamento. Um relacionamento é binário se envolve duas 
entidades, ternário se envolve três entidades, e assim por diante. 
 
Boas Prácticas: os relacionamentos devem ser escritos como verbos com letras 
minúsculas 
 
2.3.2 Auto Relacionamentos 
 
Um auto relacionamento, caracteriza-se por uma entidade relacionar-se consigo 
mesma. No exemplo a seguir 
 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 17 
 
temos um conjunto de objectos que fazem o papel de marido, um conjunto de 
objectos que fazem o papel de esposa, e um conjunto de associações que rela-
cionam os maridos com as esposas, denominado por casamento. Observe que 
agora temos o conceito do papel de um conjunto de entidades num relaciona-
mento. 
 
Notação: os papeis de um relacionamento são anotados nos campos superiores 
do losângulo. 
 
2.3.3 Cardinalidade dos Relacionamentos 
 
A cardinalidade de um relacionamento mostra o número de vezes que um con-
junto de entidade A se relaciona com um conjunto de entidade B. Essa cardina-
lidade pode ser do tipo 1:1 (um-para-um), 1:N ( um-para-muitos), N:1 (muitos-
para um) e N:N ( muito para muitos). 
 
Em estudaremos em seguida os vários tipos de cardinalidade para relaciona-
mentos binários. 
 
UM-para-UM (1:1): Este relacionamento caracteriza-se por um elemento do con-
junto de entidade em A relacionar-se com um e apenas um elemento do conjunto 
de entidade B, e um elemento do conjunto de entidade B relacionar-se com um 
e apenas um elemento do conjunto de entidade A. Em termos de teoria dos con-
juntos: 
 
Exemplo: 
 
 
 
 
Este relacionamento mostra que um departamento é coordenado por um e ape-
nas um funcionário, e que um funcionário coordena um e apenas um departa-
mento; 
 
que em termos de conjuntos é representado por 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 18 
 
Exemplo: 
 
 
 
 
Este auto relacionamento mostra que no casamento cristão, um homem se casa 
com apenas uma mulher, e que uma mulher se casa com apenas um homem. 
Nessa relação, um faz o papel de marido e outro faz o papel de esposa. 
 
que em termos de conjuntos é representado por: 
 
 
 
 
 
UM-para-MUITOS (1:N): Este relacionamento caracteriza-se por um elemento 
do conjunto de entidades A relacionar-se com vários elementos do conjunto de 
entidade B, mas um elemento do conjunto de entidades B relaciona-se com um 
apenas um elemento do conjunto de entidades A. Em termos de teoria dos con-
juntos: 
 
 
Exemplo: 
 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 19 
 
Este relacionamento mostra que uma divisão de uma empresa possui mais do 
que um departamento, mas que um departamento está contido em uma e apenas 
uma divisão. 
 
que em termos de conjuntos é representado por: 
 
 
 
 
Exemplo: 
 
 
 
 
Este auto relacionamento retrata a sociedade árabe. Nesta sociedade, um ho-
mem pode casa-se com mais do que uma mulher, mas mulher só pode casa-se 
com apenas um homem. Um faz o papel de marido e outro faz o papel de esposa. 
 
 
MUITOS-para-UM (N:1): Este relacionamento caracteriza-se por um elemento 
do conjunto de entidades A relacionar-se com um elemento do conjunto de enti-
dades B, e que um elemento do conjunto de entidades B relacionar-se com mais 
do que elemento do conjunto de entidades A. 
 
Exemplo: 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 20 
 
Este relacionamento mostra que um estudante numa universidade só pode estar 
inscrito em apenasum curso, mas que num curso podem estar inscritos vários 
estudantes. 
 
que em termos de conjuntos é representado por: 
 
 
 
 
 
Exemplo: 
 
 
 
 
Este auto relacionamento mostra a sociedade poliândrica. Nesta sociedade um 
homem pode casa-se com apenas uma mulher, mas uma mulher pode casa-se 
com mais do que um homem. Um faz o papel de “manso” e outra faz o papel de 
“safada”. 
 
 
MUITOS-para-MUITOS(N:N): Este relacionamento caracteriza-se por um ele-
mento do conjunto de entidade A relacionar-se com mais do que um elemento 
do conjunto de entidade B, e que um elemento do conjunto de entidade B relaci-
onar-se com mais do que um elemento do conjunto de entidade A. Em termos 
de teoria dos conjuntos: 
 
 
Exemplo: 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 21 
 
 
 
 
Este relacionamento mostra que um médico pode consultar vários pacientes, e 
que um paciente pode ser consultado por vários médicos. 
 
que em termos de conjuntos é representado por: 
 
 
 
 
 
Exemplo: 
 
 
 
 
Este auto relacionamento mostra uma sociedade sem moral, onde um homem 
pode relaciona-se com mais do que uma mulher, e uma mulher pode relaciona-
se com mais do que um homem. Em Angola, este relacionamento é denominado 
por “kit”, um faz o papel de “safado” e a outra o papel de “safada”, mas no meu 
tempo, esse relacionamento era chamado de “amizade colorida”. 
 
Contudo, devemos ter muito cuidado com a análise e a interpretação que faze-
mos com os relacionamentos um-para-muitos e muitos-para-muitos. Este tipo de 
cardinalidade, depende ambiente onde a relação está inserida. Para que o leitor 
tenha uma noção mais precisa dessa ambiguidade, vamos analisar o seguinte 
problema: que tipo de relação existe entre as prateleiras e produtos? 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 22 
 
Se estivermos num supermercado, os artigos expostos nas prateleiras estão or-
ganizados por tipo de artigo. Logo um artigo está exposto numa única prateleira, 
mas numa prateleira podemos ter expostos vários artigos. Logo, temos um rela-
cionamento com uma cardinalidade de um-para-muitos. 
 
Mas se estivermos em nossa casa, onde a necessidade de organização não é 
tão exigente, guardamos os artigos nos espaços livres de uma estante. Para 
essa realidade um artigo pode ser armazenado em várias prateiras, e uma pra-
teleira armazena vários artigos. Para este caso temos um relacionamento com 
uma cardinalidade de muitos-para-muitos. 
 
Boas prácticas: se num projecto tivermos auto relacionamentos sem papeis de-
finidos, devemos ter muito cuidado porque estamos em presença de um projecto 
com falhas. 
 
2.4 Atributos 
 
Os atributos representam as características de uma entidade ou de um relacio-
namento. Cada atributo está associado a um conjunto de valores que recebe o 
nome do domínio. 
 
No Diagrama de Entidade e Relacionamento (DER) a representação dos atribu-
tes não é padronizada. Nestas notas utilizaremos a notação original de El-
masri[2011] que consiste em utilizar elipses. Por exemplo, o conjunto de enti-
dade CLIENTE que mostramos a seguir, possui seguintes atributos: o código 
(que na terminologia das bases de dados denomina-se por Id), nome (nome pró-
prio e nome de família), endereço (que é composto cidade, bairro, rua, casa e 
caixa postal), telefone, data de nascimento, e idade. 
 
 
 
 
Boas Prácticas: para escrever o nome dos atributos, vamos adoptar o padrão 
Camel Case. Nesse Padrão, o primeiro caracter de cada palavra deve ser escrito 
com uma letra maiúscula enquanto que os restantes com letras minúsculas. 
 
2.4.1 Cardinalidade dos Atributos 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 23 
 
Os atributos podem ser monovalorados ou multivalorados. Os atributos monova-
lorados são aqueles que possuem um único valor para cada elemento de um 
conjunto de entidade. Estes atributos são representados por uma elipse. Por 
exemplo, no conjunto de entidade CLIENTE, são atributos monovalorados o Id 
(código) do cliente e a data de nascimento. 
 
Em contrapartida, os atributos multivalorados, são aqueles que possuem mais 
do que um valor para cada elemento de um conjunto de entidade. Esses atributos 
são representados por uma elipse dupla. Por exemplo, no conjunto de entidade 
CLIENTE, são atributos multivalorados o número do telefone. 
 
2.4.2 Classificação dos Atributos 
 
Os atributos podem ser classificados como simples, compostos ou derivados. 
 
Os atributos simples ou atómicos são aqueles que não podem ser decompostos 
em atributos mais simples. Estes atributos são representados por uma elipse. 
Por exemplo, no conjunto de entidade CLIENTE, são atributos simples o Id (có-
digo) do cliente e a data de nascimento. 
 
Os atributos compostos, são aqueles que podem ser decompostos em atributos 
mais simples. Por exemplo, no conjunto de entidade CLIENTE, são atributos 
compostos o nome de um cliente. 
 
Os atributos derivados são aqueles cujos valores podem ser calculados a partir 
dos valores de outros atributos. Estes atributos são representados por uma eli-
pse a tracejado. Por exemplo, no conjunto de entidade CLIENTE, são atributos 
derivados a idade do cliente. 
 
Atenção: os atributos derivados não devem ser descritos no Diagrama de Enti-
dade e Relacionamento. 
 
O atributo chave é um conjunto de um ou mais atributos que permite identificar 
de forma inequívoca uma ocorrência de um elemento num determinado conjunto 
de entidade. Estes atributos são representados por um traço nome do atributo. 
Por exemplo, no conjunto de entidade CLIENTE são atributos chave, o Id (có-
digo) do cliente. 
 
Mas existem algumas entidades do mundo real, como por exemplo, um municí-
pio, que o atributo chave só pode ser identificado pela concatenação do código 
da província com o código do município. 
 
Vamos clarificar este conceito com um exemplo. Suponhamos que a província 
de Luanda, está classificada com o código 02, e possui os seguintes municípios: 
01- Luanda, 02- Viana, 03- Cacuaco, …, etc, e que a província de Benguela está 
classifica com o código 07, e possui os seguintes municípios: 01- Benguela; 02-
Catumbela; 03- Lobito, 04-Baia Farta,…, etc. Como identificar o município de 
Viana? Se utilizarmos apenas o código 02, teremos os municípios de Viana e de 
Catumbela. Logo, para identificar um município de forma unívoca, temos de fazer 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 24 
 
a concatenação do código na província que contém esse município com o código 
do município, ou seja, identificá-lo com o código 0202. 
 
Para modelarmos está realidade temos de utilizar o conceito de entidade fraça 
que será estudado no próximo capítulo. 
 
2.4.3 Atributos de Relacionamentos 
 
Os atributos também podem estar contidos nos relacionamentos. Mas vamos 
consolidar esse conceito com um exemplo muito simples. 
 
Vamos considerar um relacionamento entre o conjunto de entidade EMPRE-
GADO e o conjunto entidade DEPARTAMENTO. Por uma simples inspecção, 
verificamos que estamos em presença de um relacionamento com a cardinali-
dade Muitos-para-Um, ou seja, N:1. 
 
Suponhamos que pretendemos acrescentar a esse relacionamento a data que o 
empregado começou a trabalhar num departamento. Se colocássemos essa 
data como atributo da entidade EMPREGADO, não estaríamos a modelar o pro-
blema de forma correcta, uma vez que não relacionamos essa data com um de-
partamento. Mas se colocássemos essa data na entidade DEPARTAMENTO, 
também não estaríamos a relacionar esse atributocom um empregado. Isso quer 
dizer que só poderemos modelar essa “acção” se envolvermos as duas entida-
des, ou seja, a data de inicio de funções de um empregado, é um atributo do 
relacionamento entre a entidade EMPREGADO e a entidade DEPARTAMENTO. 
 
 
 
2.4.4 Esquemas 
 
Podemos representar uma entidade ou um relacionamento, através de uma 
forma textual, cuja sintaxe descrevemos a seguir. 
 
R (a1,a2,…,an) 
 
onde 
 
 R é o nome de uma entidade ou de um relacionamento 
 
e 
 a1,a2,…,an os seus atributos. 
 
A essa forma de representação damos o nome de esquema de uma Base de 
Dados. 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 25 
 
 
2.5 Entidade Fraca 
 
Até agora vimos que todas os elementos que pertencem a um conjunto de enti-
dades possuem um atributo chave. Mas não é bem assim. Existem alguns con-
juntos de entidades no mundo real, cujos elementos não possuem essa proprie-
dade. Esses conjuntos de entidades são chamadas de entidades fracas e estão 
subordinadas a um conjunto de entidade chamada por entidade forte. 
 
As entidades fracas caracterizam-se por herdar os atributos da entidade domi-
nante, mas possuem os seus próprios atributos. 
 
Como essas entidades não têm um atributo chave, para podermos identificar de 
forma inequívoca qualquer elemento, temos de utilizar o atributo chave da enti-
dade forte mais um conjunto mínimo de atributos da entidade fraca. 
 
Vamos consolidar este conceito com dois exemplos muito simples. No primeiro 
pretendemos armazenar os dependentes de todos os funcionários de uma em-
presa para efeitos de pagamento de salários. 
 
Sabemos que o conjunto de entidade FUNCIONÁRIO está relacionado com o 
conjunto de entidade DEPENDENTE com uma cardinalidade 1:N, ou seja, para 
efeito de pagamento de salários, um funcionário pode estar associado à vários 
dependentes, mas cada dependentes só pode estar associado a um funcionário. 
Mas os atributos do conjunto da entidade DEPENDENTE são: nome do depen-
dente, sexo e data de nascimento. Mas numa empresa podemos ter dois funci-
onários cujos filhos possuem o mesmo nome e a mesma idade. Como identifica-
los? 
 
Cada funcionário é identificado pelo seu Bilhete de Identidade. Então para po-
demos identificar cada dependente no conjunto dos todos os funcionários de 
uma empresa, devemos relacionar os dados do dependente ao bilhete de iden-
tidade do seu progenitor. 
 
No Diagrama de Entidade e Relacionamento (DER) o conjunto de entidades fra-
cas, são representadas (notação de Peter Chen) por duplo retângulo e o relaci-
onamento com o conjunto da respectiva entidade forte por um duplo triangulo. 
Em termos gráficos: 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 26 
 
 
O segundo exemplo, já foi discutido neste capitulo, quando estudamos o conceito 
de chave para modelar a estrutura administrativa de uma província. 
 
Mas um conjunto de entidades fracas pode subordinar-se a um outro conjunto 
de entidades fracas. 
 
Vamos clarificar esse conceito com um exemplo. A classificação mercadológica 
é uma forma de organizar as mercadorias nos supermercados. Essa estrutura 
de mercadorias está normalmente organizada em três grandes grupos: Depar-
tamentos, Secções e Famílias. Por exemplo, todo o supermercado tem o depar-
tamento de bebidas, e nesse departamento temos a secção de vinhos, e nessa 
secção temos as famílias de vinhos verdes, rosé e tintos. 
 
Então, essa estrutura mercadológica pode ser modelada por um conjunto de en-
tidade forte denominada por DEPARTAMENTO, que possui um conjunto de en-
tidade fraca denominada por SECÇÃO. Mas esse conjunto de entidade fraca 
também possui um conjunto de entidade fraca denominada por FAMÍLIA que lhe 
está subordinado. Essa estrutura é modelada pelo seguinte diagrama. 
 
 
 
 
Observe que o atributo chave do conjunto de entidade DEPARTAMENTO é seu 
código. Mas o atributo chave do conjunto de entidade SECÇÃO é a concatena-
ção do código do departamento com código da secção, e por fim, o atributo 
chave do conjunto de entidade FAMÍLIA é a concatenação dos atributos chave 
dos conjuntos de entidades DEPARTAMENTO, SECÇÃO e FAMÍLIA. 
 
Notação o atributo de um conjunto de entidade fraca, é representado por uma 
elipse com o nome do atributo com uma linha tracejada 
 
Antes de efectuarmos alguns exercícios para consolidar a matéria, vamos apre-
sentar um resumo da notação do Diagrama de Entidade e Relacionamento. 
 
2.6 Exercícios Resolvidos 
 
Para consolidar os conhecimentos vamos começar por modelar problemas muito 
simples, e aproveitar a oportunidade para mostrar uma metodologia do desen-
volvimento do projecto de bases de dados. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 27 
 
2.6.1-Pretende-se criar uma pequena base de dados, para organizar cd’s. Sa-
bemos que, cada cd possui um título e diversas músicas; toda a música possui 
um título e uma duração; uma música pode ter sido composta por um ou mais 
compositores. Uma música pode ter sido interpretada por um ou mais cantores, 
e existem cantores que também são compositores. 
 
Resolução: vamos mostrar em primeiro lugar uma metodologia para o desenvol-
vimento do projecto de bases de dados. 
 
O primeiro passo consiste na extracção dos elementos que são fortes candidatos 
a serem entidades. Por definição, as entidades são objectos que se caracterizam 
por ter actividade própria, logo são identificados por substantivo comuns. Pela 
análise gramatical ao texto temos: 
 
CD; 
MÚSICA; 
COMPOSITOR; 
INTERPRETADOR. 
 
Mas os compositores e os interpretadores têm as mesmas características, são 
seres humanos. Então temos os seguintes conjuntos de entidades: 
 
CD; 
MÚSICA; 
ARTISTA. 
 
O segundo passo consiste na extracção dos atributos dessas entidades, ou seja, 
extrair no texto, as propriedades que caracterizam essas entidades. Por uma 
simples leitura, temos: 
 
CD (CodCd, Titulo) 
MÚSICA (CodMusica, Titulo, Duração) 
ARTISTA (CodArtista, Nome) 
 
O terceiro passo consiste na extracção dos relacionamentos entre os conjuntos 
de entidades. Vimos que a presença de um verbo é uma forte indicação de um 
relacionamento, então: 
 
Na frase “um CD possui um título e diversas músicas”, temos o verbo possuir, 
que nos permite modelar o relacionamento: 
 
possuir (CD, MÚSICA) 
 
Na frase “uma música pode ter sido composta por um ou mais compositores”, 
temos o verbo compor, que nos permite modelar o relacionamento: 
 
compor (MÚSICA, ARTISTA) 
 
e na frase “uma música pode ter sido interpretada por um ou mais interpretado-
res”, temos o verbo interpretar, que nos permite modelar o relacionamento: 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 28 
 
 
interpretar (MÚSICA, ARTISTA) 
 
O quarto passo consiste na extracção das cardinalidades entre os relacionamen-
tos. Pelo modelo descritivo, temos: 
 
possuir (CD, MÚSICA) 
compor (MÚSICA, ARTISTA) 1:N 
interpretar (MÚSICA, ARTISTA) 1:N 
 
logo estamos em condições de desenhar o correspondente Diagrama de Enti-
dade e Relacionamento. 
 
 
Mas, neste diagrama não está clara a modelagem dos compositores que são ao 
mesmo tempo interpretadores. Sabemos que a composição e a interpretação 
são actividades humanas. Logo essa actividade não é um atributo do conjunto 
de entidade MUSICA, nem um atributo do conjunto de entidade ARTISTA. É um 
atributo do relacionamento entre o conjunto de entidade MÚSICA e o conjunto 
de entidade ARTISTA. Então, faz todo o sentidofundir os relacionamentos com-
posição e interpretação num único, que denominaremos por produzir, e que pos-
sui o atributo tipo de actividade. 
 
produzir (MÚSICA, ARTISTA) TipoActividade 
 
Esse atributo pode receber os seguintes valores: 01 para compositor, 02 para 
interpretador e 03 para ambos. 
 
Agora, estamos em condições de redesenhar o Diagrama de Entidade e Relaci-
onamento, que satisfaz aos requisitos no modelo descritivo que analisamos. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 29 
 
 
 
2.6.2-Para identificar qualquer empresa o ministério das finanças disponibiliza 
um código que se denomina por Número de Identificação Fiscal (NIF), que per-
mite identificar essa empresa de forma única. Mas para além disso, toda a em-
presa possui um nome, um ramo de actividade, uma sede e eventualmente al-
gumas filais. A sede e as filiais possuem um endereço, e vários telefones de 
contacto. Os funcionários dessa empresa, possuem um código de identificação, 
um nome, um endereço e uma data de nascimento. Cada funcionário trabalha 
apenas na sede ou numa filial, e para contactá-los, cada funcionário possui um 
telefone directo. 
 
Resolução: vamos mais uma vez, mostrar a metodologia para o desenvolvimento 
do projecto de bases de dados. 
 
O primeiro passo consiste na extracção dos conjuntos de entidades. Pela análise 
gramatical, temos apenas três substantivos comuns que reúnem essas condi-
ções: 
 
EMPRESA; 
FILIAL; 
FUNCIONÁRIO. 
 
O segundo passo consiste na extracção dos atributos desses conjuntos de enti-
dades. Por uma simples leitura ao texto, temos: 
 
EMPRESA (NIF, Nome, Endereço (Rua, Casa, Bairro, Cidade), {Telefones}) 
FILIAL (CodFil, Nome, Endereço (Rua, Casa, Bairro, Cidade), {Telefones}) 
FUNCIONARIO (IdFunc, Nome, Endereço (Rua, Casa, Bairro, Cidade), Dat-
Nasc) 
 
Mas as entidades EMPRESA e FILIAL têm os mesmos atributos. Não é possível 
agrupa-los numa única entidade? 
 
Para eliminar essa redundância, podemos acrescentar no conjunto de entidade 
EMPRESA um atributo, denominado por tipo-de-empresa, que terá o valor ‘sede’ 
quando estivermos perante a Sede e ‘filial’ caso contrário, e anular a entidade 
FILIAL. 
 
Embora está solução simplifica o nosso modelo, ela não nos permite saber quem 
é a filial de quem, como veremos a seguir. 
 
O terceiro passo, consiste na extração dos relacionamentos entre os conjuntos 
de entidades. São fortes candidatos para relacionamentos todos os objectos que 
são expressos por verbos. Por uma análise gramatical ao texto temos: 
 
Na frase “cada empresa possui zero os mais filiais”, temos um verbo possuir, 
que nos mostra que existe o relacionamento: 
 
possui (EMPRESA, FILIAL) 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 30 
 
 
Mas esse relacionamento colide com a estratégia de termos adicionado no con-
junto de entidade EMPRESA o atributo tipo_de_empresa, e anulado o conjunto 
de entidade FILIAL. 
 
Para modelar essa realidade, e saber quem é filial de quem, devemos utilizar o 
auto relacionamento 
 
possui (EMPRESA, EMPRESA) 
 
onde temos um conjunto de objectos que fazem o papel de sede, e um conjunto 
de objectos que fazem o papel de filial. Com essa solução passamos a ter ape-
nas os seguintes conjuntos de entidades: 
 
EMPRESA (NIF, Nome, Endereço(Rua, Casa, Bairro, Cidade), {Telefones}); 
FUNCIONARIO (IdFunc, Nome, Endereço, DatNas). 
 
Vamos continuar a analisar o texto. Agora temos a frase “Cada funcionário tra-
balha na sede ou numa filial”. Como nesta frase temos o verbo trabalhar, que 
nos permite modelar o relacionamento: 
 
trabalha (EMPRESA, FUNCIONÁRIO) 
 
Mas na frase “cada funcionário possui um telefone directo”. Apesar de termos o 
verbo possuir, não estamos em presença de um relacionamento, porque o tele-
fone não é uma entidade. O facto de o trabalhador ter direito à um telefone di-
recto, faz com que o número do telefone varie de empregado para empregado, 
logo o telefone de serviço é um atributo do funcionário. 
 
FUNCIONARIO (CodFunc, Nome, Endereço (Rua, Casa, Bairro, Cidade), Dat-
Nasc, TelServico) 
 
O quarto passo consiste na extracção das cardinalidades dos relacionamentos. 
Pelo modelo descritivo temos: 
 
possui (EMPRESA, EMPRESA) 1:N 
trabalha (EMPRESA, FUNCIONÁRIO)1:N 
 
Logo estamos em condições de desenhar o Diagrama de Entidade e Relaciona-
mento. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 31 
 
 
 
2.6.3-Para efectuar um parto na maternidade Lucrécia Paim, temos os 
procedimentos: Quando uma senhora (parturiente) entra em período de parto, 
recebe uma etiqueta com um número; Quando um bebé nasce, são 
armazenadas as seguintes informações: nome, data de nascimento, peso, 
altura, código da mãe, número do bebé a nascer nesse dia; e o número da 
carteira profissional do médico; Quando uma parturiente chega a maternidade, 
são retiradas as seguintes informações: nome, endereço, telefones, data de 
nascimento e o médico que fará o parto; Para os médicos é importante saber o 
número da carteira profissional, nome, telefone e a especialidade. 
 
Resolução: como já temos alguma experiencia na aplicação da metodologia do 
projecto de bases de dados, vamos automatizar alguns passos, para que a 
implementação se torne mais rápido. 
 
Primeiro passo: extracção do conjunto de Entidades 
 
MÉDICO; 
BEBÉ; 
PARTURIENTE; 
 
Segundo Passo: Extração dos Atributos 
 
MÉDICO (CodMédico, Nome, {Telefone}, Especialidade); 
BEBÉ (CodBebé, Nome, dtNasc, Peso, Altura, CodMãe, NumBebé, 
CodMédico); 
PARTURIENTE (CodMãe, Nome, Endereço, {Telefones}, DatNac, CodMédico); 
 
Observe que o CodMãe não é um atributo da entidade BEBÉ, e que o CodMédico 
não é um atributo da entidade PARTURIENTE nem da entidade BEBÉ. Logo 
estamos em condições de refazer os atributos das entudades que fazem parte 
deste problema. 
 
MÉDICO (CodMédico, Nome, {Telefone}, Especialidade); 
BEBÉ (CodBebé, Nome, dataNasc, Peso, Altura, Numero); 
PARTURIENTE (CodMãe, Nome, Endereço, {Telefones}, DataNac); 
 
Terceiro passo: extracção dos Relacionamentos 
 
Atende (MÉDICO, PARTURIENTE) 
Éfilho (PARTURIENTE, BEBÉ) 
 Assiste (MÉDICO, BEBÉ) 
 
Quarto passo: Cardinalidade dos Relacionamentos 
 
Atende (MÉDICO, PARTURIENTE) 1:N 
Éfilho (PARTURIENTE, BEBÉ) 1:N 
Assiste (MÉDICO, BEBÉ) 1:N 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 32 
 
Logo, estamos em condições de desenhar o Diagrama de Entidade e Relaciona-
mento. 
 
 
 
2.6.4-Uma empresa está organizada por departamentos. A cada departamento 
está associado à um único nome, um número único, um empregado que é o 
gerente e a data em que este começou a gerir o departamento. Um departa-
mento pode ter várias localizações. Cada departamento controla um determi-
nado número de projectos. Cada projecto tem um nome único, um número único 
e uma localização única. Para os empregados é necessário guardar o nome (pró-
prio e de família), número do BI, endereço, salário, sexo, data de nascimento e 
o correspondente supervisor. Cada empregado pertence a um único departa-
mento, mas pode trabalhar em vários projectos, que não são necessariamente 
controlados pelo mesmo departamento. Para cada projecto é necessário tomar 
nota do número de horas por semana que cada empregado nele trabalha. Para 
efeitos de seguro é necessário conhecer os dependentes de cada empregado, 
ou seja, o nome, sexo, data de nascimento e grau de parentesco. 
 
Resolução: como já temos um pleno conhecimento sobre a metodologia do pro-
jectode bases de dados, vamos mais uma vez, compactar o processo de imple-
mentação. 
 
Primeiro passo: extracção do conjunto de Entidades e seus atributos 
 
DEPARTAMENTO (CodDepart, Nome, Gerente, Localização (Rua, Prédio, An-
dar, Porta)); 
PROJECTO (CodProj, Nome, Localização (Rua, Prédio, Andar, Porta), Depar-
tamento); 
EMPREGADO (NumBI, Nome, Endereço, Salário, Sexo, DataNasc, Supervisor, 
Departamento); 
 
Segundo Passo: extração do conjunto de Entidades Fortes, Fracas e seus atri-
butos 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 33 
 
 
Entidades Fortes 
EMPREGADO (NumBI, Nome, Endereço, Salário, Sexo, DataNasc, Supervisor, 
Departamento); 
 
Entidades Fracas 
 
DEPENDENTE (Empregado, Nome, Sexo, DataNasc, GrauParentesco); 
 
Mas, no esquema anterior existem alguns relacionamentos implícitos, porque 
temos atributos de uma entidade que se referem a outra entidade. 
 
Gerente na entidade DEPARTAMENTO; 
Departamento na entidade PROJECTO; 
Supervisor e Departamento na entidade EMPREGADO; 
Empregado na entidade DEPENDENTE. 
 
No modelo de Entidade e Relacionamento estas referências não devem ser re-
presentadas por atributos, mas sim por relacionamentos. 
 
Terceiro Passo: extracção dos Relacionamentos, respectivos atributos e sua car-
dinalidade. 
 
Dirige (EMPREGADO, DEPARTAMENTO, GerenteData) 1:1; 
Controla (DEPARTAMENTO, PROJECTO) 1:N; 
Supervisiona (EMPREGADO, EMPREGADO) 1:N; 
Trabalha_Para (EMPREGADO, DEPARTAMENTO) N:1; 
Trabalha_Em (EMPREGADO, PROJECTO, Horas) N:N; 
Dependente_De (DEPENDENTE, EMPREGADO) N:1. 
 
Logo, estamos em condições de apresentar o Diagrama de Entidade e Relacio-
namento 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 34 
 
 
2.7 Exercícios Propostos 
 
2.7.1- Desenvolva uma pequena base de dados para informatizar uma delegacia 
de polícia, que pretende obter as seguintes informações: 
 
Cadastrar as informações pessoais das pessoas que cometeram crimes, as suas 
armas e a suas vítimas. Para além disso, o sistema deve fornecer as informa-
ções: 
 
Quais os crimes que um determinado criminoso cometeu, sabendo que um crime 
pode ser cometido por mais de um criminoso; 
 
Quais crimes que uma determinada vítima sofreu, sabendo que várias vítimas 
podem ter sofrido um mesmo crime; 
 
2.7.2-Uma biblioteca de uma Universidade pretende que se desenvolva uma 
base de dados para controlar os empréstimos do seu acervo de livros. 
 
Para cada livro devem ser armazenadas as seguintes informações: ISBN (código 
internacional único de livros), título, autor(es), edição, ano de publicação e edi-
tora (nome, endereço, site e e-mail). 
 
Para cada autor livro devem ser armazenadas as seguintes informações: código, 
nome, sexo, e-mail, e telefones de contato. 
 
A biblioteca possui vários exemplares de cada livro para empréstimo. Cada 
exemplar possui um número de identificação, que é único para cada livro. Dois 
exemplares de livros diferentes podem ter o mesmo número de identificação. 
 
Para cada exemplar que a biblioteca emprestar devem ser armazenadas as se-
guintes informações: dados do exemplar, dados do utilizador que levou o livro 
(número de matrícula, nome, endereço e telefones), data do empréstimo, data 
limite para devolução e a data real da devolução. 
 
2.7.3-Pretende-se desenvolver uma base de dados para uma empresa que aluga 
automóveis que possui os seguintes requisitos: 
 
Essa empresa, possui automóveis e camionetas de carga para alugar. Para cada 
veículo alugado deve ser armazenado, o número da placa, o número do chassis, 
cor, modelo e marca. Para além disso, existe na empresa, uma tabela para 
classificar os veículos. Por exemplo, o tipo A3 corresponde a automóveis 
pequenos, de quatro portas e com ar-condicionado, enquanto que o tipo C4 
corresponde a camionetas com capacidade de carga ate 1 tonelada. 
 
O tipo de automóvel define o tamanho (pequeno, medio ou grande), o numero 
de portas e os acessórios disponíveis, como ar-condicionado, radio, GPS e 
cambio automático. Mas para as camionetas o tipo de automóvel define a 
capacidade de carga da camioneta e a dimensão (largura e altura) da sua 
carroceria. 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 35 
 
 
Para alugar um veículo, um cliente faz uma reserva por telefone ou pelo Site da 
Empresa, onde define as datas de inicio e término do aluguel, o tipo de veiculo 
que deseja alugar, a filial de retirada e a filial de entrega do veículo. Somente se 
relaciona o veículo ao cliente quando este for retirado. 
 
A empresa possui uma grande rede de lojas, e para cada loja pretende-se 
armazenar o nome, o código da loja, o endereço e os telefones de contacto. 
 
Para os clientes que desejam alugar veículos, deve-se armazenar, o nome, o 
sobrenome, data de nascimento, endereço, número do telemóvel, e número de 
Bilhete de Identidade. 
 
2.7.4-Pretende-se desenvolver uma base de dados para uma Universidade com 
os seguintes requisitos: 
 
Para cada professor deve-se armazenar as seguintes informações: número do 
professor, nome, idade, grau académico, e especialidade de pesquisa. 
 
Para cada projecto deve-se armazenar: número do projecto, nome do financia-
dor, data inicial, data final e orçamento; 
 
Para cada estudante de pós-graduação deve-se armazenar: número do estu-
dante, nome, idade, e o programa de pós-graduação (por exemplo, mestrado ou 
doutoramento). 
 
Cada projecto é gerido por um professor (conhecido como pesquisador principal 
do projecto). 
 
Cada projecto é orientado por um ou mais professores (conhecidos como coori-
entadores). 
 
Os professores podem gerir e/ou orientar múltiplos projectos. Cada projecto é 
também pode ser orientado por um ou mais estudantes de pós-graduação (co-
nhecidos como os assistentes de pesquisa do projecto). 
 
Quando os alunos de pós-graduação conduzem um projecto, um professor deve 
supervisionar seu trabalho no projecto. Os alunos de pós-graduação podem tra-
balhar em múltiplos projectos, e neste caso, eles terão um supervisor (potencial-
mente diferente) para cada projecto; 
 
Para cada departamento deve-se armazenar: um número do departamento, 
nome de departamento e endereço. 
 
Os departamentos possuem um professor (conhecido como chefe do departa-
mento) que coordena o departamento. 
 
Os professores podem trabalhar em mais do que departamento. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 36 
 
Os alunos de pós-graduação têm um departamento principal no qual estão a 
fazer o seu programa de pós-graduação. 
 
Cada aluno de pós-graduação tem um outro aluno de pós-graduação mais ex-
periente (conhecido como conselheiro do aluno) que o aconselha nos cursos a 
que deve assistir. 
 
2.7.5-Uma empresa de transportes rodoviários, pretende informatizar o percurso 
dos seus autocarros, que fazem o serviço de atendimento au publico numa pe-
quena cidade. 
 
Para cada autocarro deve-se armazenar as seguintes informações: matrícula, 
data de entrada em serviço, número de quilómetros, data da próxima revisão e 
o tipo de autocarro. 
 
Por tipo de autocarro deve-se armazenar marca, modelo, número de lugares 
sentados e um número de lugares de pé. 
Por cada percurso dos autocarros deve-se armazenar as seguintes informações: 
número do percurso (1,2,3…) e total de quilómetros percorridos. 
 
Ao longo do percurso temos várias paragens e por cada paragem deve-se arma-
zenar: número, nome, localização que é composta por rua e bairro. Mas quando 
um cliente aluga um autocarro e o seu motorista, esse percurso nãopercorre as 
paragens e recebe um número especial (zero). 
 
Para cada motorista deve-se armazenar as seguintes informações: número de 
BI, nome, endereço, números de telefones, data de entrada em serviço e os per-
cursos que os percursos que está habilitado a fazer. 
 
Na base de dados deve-se armazenar as informações das saídas dos autocarros 
da base, que são feitos em três turnos: 6 horas da manhã, 14 horas e a última 
saída é feita as 22 horas. 
 
Para cada saída de um autocarro, que podem ser muitas num único dia, deve-
se armazenar a seguinte informação: data, turno, condutor, número do auto-
carro, percurso atribuído, quilómetros do autocarro. 
 
Quando o autocarro regressa a base, recolhe-se as seguintes informações: data, 
turno, condutor, número do autocarro, quilómetros do autocarro. 
 
2.8 Leituras Recomendadas 
 
Para aprofundar os assuntos abordados neste capítulo, recomendados que o 
leitor consulte os seguintes livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 7- Modelagem de Dados usando o Modelo Enti-
dade-Relacionamento (ER), tradução da 6º edição americana São Paulo, 
Pearson Addison Wesley, 2011. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 37 
 
 Guimarães C. C.,- Fundamentos de Banco de Dados: Modelagem, Projeto 
e Linguagem SQL, Capítulo 2 – Modelagem de Dados, 1ª Edição, Editora 
da UNICAMP, 2003 
 
 Heuser C. A.;- Projeto de Banco de Dados, 6ª Edição, Instituto de Infor-
mática da UFRGS, Capítulo 2- Abordagem Entidade-Relacionamento e 
Capitulo 3- Construindo Modelo ER, Porto Alegre, Bookman, 2009. 
 
 Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, Capítulo 4- Modelagem de Entidade e Relacionamento, 
tradução da 8ª edição americana Edição, Cengage Learning, 2010. 
 
 Setzer W., Silva F. S. C.;- Banco de Dados: Aprenda o que são, Melhore 
seu Conhecimento, Construa os seus, Capítulo 2- O modelo conceitual de 
entidades e relacionamentos, 1ª edição, São Paulo, Edgar Blucher, 2001 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 38 
 
 
3 
Capítulo 
Modelo de Entidade e Relacionamento 
Estendido 
 
“um projectista de Bases de Dados necessita de ter um bom conhecimento do minimundo que está a ser 
modelado para que possa tomar as decisões corretas!” 
 
 - Ciferri Cristina- 
 
3.1 Introdução 
 
O Modelo de Entidade e Relacionamento (ER) estudado no capítulo anterior 
possui os recursos suficientes para modelar um projecto de bases de dados para 
aplicações tradicionais, que envolvem o processamento de dados no comércio 
e na indústria. 
 
Contudo, este modelo de dados sofreu muitas evoluções para responder a 
modelagem de aplicações que envolvem as novas tecnologias de informação, 
que necessitam de requisitos mais complexos. 
 
Para modelar esses requisitos, foram desenvolvidos conceitos adicionais, que 
estão incorporados no Modelo de Entidade e Relacionamento Estendido (EER –
Extended Entity Relation), que estudaremos a seguir. 
 
3.2 Relacionamentos Ternário 
 
No capítulo anterior estudamos os relacionamentos binários. Vimos que um re-
lacionamento R entre os conjuntos de entidades A e B, a cardinalidade de A em 
R mostra quantas ocorrências de B podem estar associadas a cada ocorrência 
de A, e a cardinalidade de B com R, mostra quantas ocorrências de A podem 
estar associadas a cada ocorrência de B. 
 
Para os relacionamentos ternários o conceito de cardinalidade de um relaciona-
mento não é uma extensão trivial do conceito de cardinalidade nos relaciona-
mentos binários. 
 
Nos relacionamentos ternários, a cardinalidade refere-se a pares de entidades, 
ou seja, um relacionamento R entre os conjuntos de entidades A, B e C, a cardi-
nalidade A e B dentro do relacionamento R mostra quantas ocorrências de C 
podem estar associadas a um par de ocorrências de A e B. 
 
Vamos clarificar este conceito com um exemplo, proposto por Carlos Heuser 
[2009]. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 39 
 
 
 
Este relacionamento mostra que: 
 
A cardinalidade “1” na linha que liga o retângulo que representa o conjunto de 
entidades DISTRIBUIDOR ao losângulo distribuição, mostra que cada par de 
ocorrências (cidade, produto) está associado a no máximo um distribuidor. Isso 
quer dizer que é concedido a exclusividade a um distribuidor em distribuir vários 
produtos em várias cidades. 
 
A cardinalidade n na linha que liga o retângulo que representa o conjunto de 
entidades CIDADE ao losângulo distribuição, mostra que cada par de 
ocorrências (produto, distribuidor) está associado a mais do uma cidade. Isso 
quer dizer que numa determinada cidade, um distribuidor pode distribuir mais do 
que um produto. 
 
Para terminar, na cardinalidade n na linha que liga o retângulo que representa o 
conjunto de entidades PRODUTO ao losângulo distribuição, mostre que cada 
par de ocorrências (cidade, distribuidor) está associado a mais do que um 
produto. Isso quer dizer que um produto pode ser distribuído por apenas um 
distribuidor em várias cidades. 
 
Esta interpretação, nos permite concluir que um relacionamento ternário não é 
equivalente a três relacionamentos binários. 
 
3.2.1 Cardinalidade dos Relacionamentos 
 
UM-para-UM-para-UM (1:1:1) 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 40 
 
 
Este relacionamento modela uma relação entre os conjuntos de entidades TÉC-
NICO, PROJECTO e NOTEBOOK, e possui a seguinte interpretação: um técnico 
utiliza apenas um notebook para cada projecto. Cada NoteBook é utilizado por 
um técnico num determinado projecto. Observe que um técnico pode trabalhar 
em mais do que um projecto, mas em cada projecto tem de necessariamente 
utilizar diferentes NoteBooks. 
 
UM-para-MUITOS-para-UM (1:N:1) 
 
 
 
Este relacionamento modela uma relação entre os conjuntos de entidades 
PROJECTO, FUNCIONÁRIO e LOCAL, e possui a seguinte interpretação: cada 
funcionário atribuído a um projecto trabalha em apenas um lugar para esse 
projecto. Em um determinado local um funcionário trabalha em apenas um 
projecto. Num determinado projecto que está a ser desenvolvido num local, 
trabalham vários funcionários. 
 
UM-para-MUITOS-para-MUITOS (1:N:N) 
 
 
 
Este relacionamento modela uma relação entre os conjuntos de entidades 
GERENTE, ENGENHEIRO e PROJECTO, e possui a seguinte interpretação: 
cada engenheiro que trabalha num determinado projecto tem apenas um 
gerente. Cada gerente de um projecto pode gerir mais do que um engenheiro. 
Em cada projecto podemos ter mais do que um engenheiro que é gerido por 
apenas um gerente. 
 
MUITOS-para-MUITOS-para-MUITOS (N:N:N) 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 41 
 
 
 
Este relacionamento modela uma relação entre os conjuntos de entidades 
FUNCIONÁRIO, PROJECTO E HABILIDADE, e possui a seguinte interpretação: 
cada funcionário de uma empresa, utilizam muitas habilidades para qualquer 
projecto que desenvolvem. Num determinado projecto participam muitos 
funcionários que utilizam muitas habilidades. 
 
3.3 Especialização e Generalização 
 
No mundo real, existem alguns conjuntos de entidades que para além de possuir 
algumas propriedades comuns a outras entidades, possuem propriedades 
específicas que os caracterizam. 
 
Vejamos um exemplo: considere o conjunto de entidade FUNCIONÁRIO. Todo 
o funcionário tem os seguintesatributos: código do funcionário, nome, endereço 
e telefones. 
 
Mas um funcionário pode ser um gerente, um engenheiro, um técnico ou um 
secretário, e todos esses funcionários, para além de possuírem os atributos 
descritos anteriormente, possuem os atributos específicos que caracterizam a 
sua profissão, como por exemplo: os engenheiros possuem certificações e os 
secretários falam diversas línguas. 
 
Para modelar problemas com essas características utiliza-se uma técnica de 
modelagem, denominada por especialização. 
 
A especialização é um relacionamento que permite relacionar uma entidade 
genérica, chamada de superclasse, que possui os atributos comuns a todos os 
elementos dessa classe, e um conjunto de entidades especializadas, chamadas 
de entidade subclasse, que possuem atributos específicos. 
 
No exemplo anterior o conjunto de entidade FUNCIONÁRIO é uma entidade 
superclasse, enquanto que os conjuntos de entidades, GERENTE, 
ENGENHEIRO, TÉCNICO e SECRETÁRIO, são as entidades subclasse. 
 
No Diagrama de Entidade e Relacionamento (DER), a especialização pode ser 
representada por uma circunferência com uma letra no interior, notação utilizada 
por Elmasri [2011] que adoptamos nestas notas, mas existem outras notações, 
como um triangulo investido, utilizada por Silberschatz [2012]. Essa letra mostra 
o tipo de relacionamento entre os conjuntos de entidades subclasse, e pode ser 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 42 
 
“d” se as entidades subclasse forem mutuamente exclusivas, ou “o” se elas se 
sobrepõem. 
 
Por exemplo, no diagrama 
 
 
 
O conjunto de elementos das entidades subclasse são mutuamente exclusivas, 
pelo facto de não existir numa universidade um estudante que está matriculado 
ao mesmo tempo num curso de graduação (licenciatura) e num curso de pós-
graduação (mestrado ou doutoramento), enquanto que no diagrama: 
 
 
 
O conjunto de elementos das entidades subclasse se sobrepõem, porque 
podemos ter uma pessoa que pratica ao mesmo tempo, mais do que um 
desporto. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 43 
 
Associado ao conceito de especialização está a ideia da herança de 
propriedades. Herdar as propriedades significa que cada ocorrência da entidade 
subclasse para além dos atributos específico, possui os atributos da entidade 
superclasse. Desse modo cada elemento do conjunto de entidades FUTEBOL 
possui os atributos: nome, sexo, numero do BI e posição. 
 
Para além disso, a especialização pode ser classificada como total ou parcial. 
Esta classificação está relacionada com a obrigatoriedade de cada ocorrência 
da entidade superclasse ocorrer nas entidades subclasse. 
 
Na especialização total, denotada por t, cada elemento do conjunto de entidade 
superclasse ocorre em pelo mesmos um elemento do conjunto de entidades 
subclasse. Como exemplo temos a classificação de clientes para pagar 
impostos. Segundo o ministério das finanças qualquer cliente é uma pessoa 
física (singulares) ou uma pessoa jurídica (empresas). 
 
Na especialização parcial, denotada por p, cada elemento do conjunto de 
entidade superclasse, pode não correr em pelo menos um elemento do conjunto 
das entidades subclasse. 
 
A Generalização é funcionalmente interpretada como o processo inverso a es-
pecialização, no qual se identificam as características comuns que passarão a 
caracterizar uma nova entidade superclasse com base nas características das 
entidades subclasse originais. 
 
Enquanto a especialização define os conjuntos das entidades subclasse a partir 
do conjunto de entidade superclasse, ou seja, um processo de cima para baixo 
(top_down), a generalização define o conjunto de entidade, superclasse a partir 
dos conjuntos de entidades subclasse, ou seja num processo inverso (Botton-
Up). 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 44 
 
 
Vamos analisar este conceito com um exemplo proposto por Elmasri [2011]. Os 
conjuntos de entidades CARRO e CAMIÃO podem ser descritas pelos seguintes 
diagramas: 
 
 
Como essas entidades possuem muitos atributos comuns, podemos criar uma 
entidade genérica, que possui todos os atributos comuns, e especificar os 
conjuntos de CARRO e CAMIÃO com apenas os atributos específicos, ou seja: 
 
 
 
3.4 Herança 
 
No mundo real existem problemas em que a especialização ou a generalização 
são aplicadas de forma sucessiva. Esse conceito recebe o nome de nome de 
Herança, e vamos analisa-lo com dois exemplos. 
 
 
O primeiro, proposto por Silberschat [ 2021]. No diagrama: 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 45 
 
 
 
Temos a entidade ESPECIAL que retrata os clientes que têm uma conta bancaria 
com um certo valor, e por esse facto, têm alguns privilégios. Um dos privilégios 
é que apenas esses clientes possuem um cartão de crédito desde que o seu 
saldo seja superior a um determinado valor mínimo. Para além disso, esses 
clientes herdam todas as propriedades dos clientes que possuem uma conta 
corrente, logo têm direito a um cartão multicaixa. 
 
Os clientes que possuem uma conta corrente herdam os atributos dos clientes 
que possuem uma conta bancária, então possuem um número de conta e um 
saldo. 
 
Como os clientes que possuem uma conta especial herdam os atributos dos 
clientes que possuem uma conta corrente, e os clientes que possum uma conta 
corrente herdam os atributos dos clientes que possuem uma conta bancária, 
então por transitividade os clientes que possuem uma conta especial herdam 
todos os atributos dos clientes que têm uma conta bancária. 
 
Isso nos permite concluir que os clientes que possuem uma conta especial 
possuem os seguintes atributos: número de conta, valor do saldo, número do 
cartão multicaixa, número do cartão de credito, e um valor limite para o saldo 
que lhe permite gozar dos privilégios clientes deste ranking. 
 
O segundo, proposto por por Elmasri [2011]. No diagrama: 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 46 
 
 
 
 
Temos uma Universidade, onde uma pessoa pode ser um funcionário, um ex-
estudante ou um estudante. Mas, podemos ter pessoas que são ao mesmo 
tempo funcionários, ex-estudantes ou estudantes, logo estamos em presença de 
um conjunto de entidades subclasse que se sobrepõem. 
 
Contudo, podemos temos alguns estudantes, normalmente os bons estudantes, 
que são requisitados para monitores. Esses estudantes fazem parte da entidade 
subclasse ALUNOCOLABORADOR que se relaciona com as entidades 
superclasse FUNCIONÁRIO e ESTUDANTE. 
 
Observe que este diagrama possui uma hierarquia de especialização. Com 
excepção da entidade ALUNOCOLABORADOR que se relaciona com duas 
entidades superclasse. 
 
Conclusão: a aplicação sucessiva deste tipo de modelagem, um conjunto de 
entidade subclasse pode ser especializado em vários conjuntos de entidades 
subclasses, que ao mesmo tempo, tornam-se conjuntos de entidades 
superclasses e uma entidade subclasse. 
 
Observação: na especialização e na generalização, as entidades subclasse não 
possuem um atributo chave, esse atributo é herdado da entidade superclasse. 
Para além disso, neste tipo de relacionamento temos uma cardinalidade de um-
para-um. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 47 
 
 
 
3.5 União 
 
Mas existem algunsproblemas no mundo real que é possível modelar um único 
relacionamento superclasse/subclasse com mais do que uma entidade 
superclasse, em que a entidade superclasse representa uma coleção de 
elementos que são um subconjunto da união de tipos de entidades diferentes, 
denominadas por subclasse de tipo União. 
 
Vamos clarificar este conceito com mais um exemplo também proposto por 
Elmasri [2011]. 
 
Suponhamos que temos três tipos de entidades: PESSOA, BANCO e 
EMPRESA. 
 
Para registrar qualquer automóvel, o proprietário automóvel pode ser uma 
pessoa, um banco (se o automóvel tiver sido adquirido por crédito e o cliente 
ainda não saldou a dívida), ou uma empresa. Logo, para modelar essa realidade 
é necessário criar uma entidade que vai herdar as propriedades das três 
entidades anteriores. 
 
A forma mais correcta de modelar essa realidade consiste em criar uma entidade 
PROPRIETÁRIO que é a união das entidades: PESSOA, BANCO e EMPRESA. 
 
No modelo de Entidade e Relacionamento Estendido essa entidade é ligada as 
entidades superclasse com uma circunferência com a letra U no seu interior. 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 48 
 
 
3.6 Agregação 
 
Um relacionamento é uma associação entre entidades. Pelos conceitos que 
estudamos, o Modelo de Entidade e Relacionamento não é capaz de associar 
dois relacionamentos entre si. 
 
Mas existem alguns problemas reais, que um relacionamento se associa a outros 
relacionamentos. 
 
Vamos clarificar este conceito com um exemplo foi proposto por Ramakrishnan 
[2008]. Suponhamos que temos um conjunto de projectos e que cada projecto 
pode ser financiado por um ou vários departamentos. Mas todo o departamento 
que financia um projecto pode nomear um funcionário para acompanhar a forma 
como o financiamento está a ser utilizado. 
 
Por uma simples interpretação do texto, vemos que temos três conjuntos de 
entidades: DEPARTAMENTO, PROJECTO e FUNCIONÁRIO. Como no texto 
não existem substantivos que caracterizam essas entidades, não temos como 
extrair os seus atributos. Mas vamos supor que cada entidade possui apenas 
dois atributos: o código e o nome. Agora vamos extrair os relacionamentos 
existentes neste problema. O verbo financiar mostra que existe um 
relacionamento entre os conjuntos de entidades DEPARTAMENTO e 
PROJECTO, com uma cardinalidade de muitos-para-muitos. Mas como modelar 
o verbo controlar? Só temos duas hipóteses. 
 
A primeira consiste em associar o conjunto de entidade FUNCIONÁRIO ao 
conjunto de entidade DEPARTAMENTO. Com esse relacionamento obtemos 
apenas as informações dos funcionários que foram nomeados para cada 
departamento. 
 
A segunda consiste em associar conjunto de entidade FUNCIONÁRIO ao 
conjunto de entidade FINANCIAMENTO. Com esse relacionamento obtemos 
apenas as informações dos funcionários que vão controlar os financiamentos. 
 
Então para obter as informações dos funcionários que foram nomeados para 
controlar cada projecto que os departamentos financiam, devemos relacionar o 
conjunto de entidade FUNCIONÁRIO aos conjuntos de entidades 
DEPARTAMENTO e PROJECTO, ou seja, a relação financiar. 
 
Logo, para modelarmos esse problema, necessitamos de um novo recurso 
denominado por agregação, ou entidade associativa, cujo diagrama 
descrevemos em seguida. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 49 
 
 
 
Definição: uma agregação é um relacionamento que está identificado com um 
retângulo tracejado que permite relacionar-se com um outro relacionamento. 
 
3.7 Exercícios Resolvidos 
 
3.5.1- Uma empresa de aluguer de viaturas, possui automóveis e camionetas de 
carga para alugar. Para cada veículo alugado deve ser armazenado, o número 
da placa, o número do chassis, cor, modelo e marca do autocarro. 
 
Para além disso, existe na empresa uma tabela para classificar os veículos. Por 
exemplo: 
 
Um veículo do tipo A3, corresponde a automóveis pequenos, de quatro portas, 
com ar-condicionado 
 
Um veículo do tipo C4 corresponde a camionetas com capacidade de carga até1 
tonelada. 
 
O tipo de veículo define o tamanho (pequeno, medio ou grande), o número de 
portas e os acessórios disponíveis, como ar-condicionado, radio, GPS e cambio 
automático. 
 
Mas para as camionetas o tipo de veículo define a capacidade de carga da 
camioneta, e a dimensão (largura e altura) da sua carroceria. 
 
Para alugar um veículo, um cliente faz uma reserva por telefone ou pelo Site da 
Empresa, onde define as datas de inicio e término do aluguel, o tipo de veiculo 
que deseja alugar, a filial onde vai retirar o veículo, e a filial onde o vai entregar. 
Somente se deve relacionar o veículo ao cliente quando este for levantado. 
 
Esta empresa possui uma grande rede de lojas, e para cada loja pretende-se 
armazenar o nome, o código da loja, o endereço e os telefones de contacto. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 50 
 
 
Para os clientes que desejam alugar os veículos, deve-se armazenar, o nome, o 
sobrenome, data de nascimento, endereço, número do telemóvel, e número de 
imposto predial (NIF). 
 
Resolução: uma possível solução, para este problema consiste nos seguintes 
passos: 
 
Primeiro Passo: extracção das entidades e dos seus atributos 
 
FILIAL (Numero, Nome, {Telefone}, Endereço (Casa, Rua, Bairro, Cidade)) 
VEÍCULO (Placa, Chassi, Marca, Cor, Modelo) 
CLIENTE (NIF, Nome, Data de nascimento, {Telefone}) 
RESERVA (DataInicio, DataFim) 
 
Segundo Passo: extracção das especializações\generalizações 
 
Entidade Superclasse 
 
TIPO_VEICULO (TipoCodigo) 
 
Entidade Subclasse 
 
CAMIONETA (Dimensão (Largura, Altura), Tipo-de-carga) 
AUTOMOVEL (Tamanho, NumPortas, Ar-condicionado, Radio, gps, Cambio) 
 
Terceiro Passo: extracção dos Relacionamentos, respectivos atributos e cardi-
nalidade. 
 
contém (FILIAL, VEICULO, DataInicio, Datafim) N:N 
entregou (FILIAL, RESERVA) 1 :N 
retirou (FILIAL, RESERVA) 1:N 
alugou(VEICULO, RESERVA, DatRetirada, DatEntregaPrevista,DatEntrega) 1:N 
Faz (CLIENTE, RESERVA)1:N 
tem (RESERVA, TIPO_VEICULO) 1:N 
Possui (VEÍCULO, TIPO_VEICULO) 1:N 
 
Logo, estamos em condições de desenhar o diagrama de Entidade e Relacio-
namento estendido. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 51 
 
 
3.5.2-Pretende-se desenvolver uma base de dados para a polícia de transito, e 
para o efeito, foi feito um levantamento de requisitos que apurou o seguinte mi-
nimundo. 
 
A Brigada de Trânsito situada junto ao Hipermercado Jumbo, pretende construir 
uma base de dados para melhorar a sua operacionalidade no processamento de 
infracções ao código de estrada. Está base de dados deve armazenar informa-
ções relativas aos veículos, como seja: a matrícula, a marca, o modelo, o propri-
etário actual e a respectiva data de aquisição. 
 
Para os proprietários devem ser armazenados as seguintes informações: o nú-
mero do Bilhete de Identidade, o nome, a morada, e o número de contribuinte. 
 
Também pretende-se que a base de dados deva armazenar informações relati-
vas aos condutores, como seja: o número do Bilhete de Identidade, o nome, a 
endereço, o número da carta de condução, as infracções ao código de estrada 
por si cometidas, assim como uma pontuação que deve ser agravada à medida 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 52 
 
que o condutor comete novas infracções. As infracções são catalogadas por ti-
pos: ligeira, grave emuito grave, e a cada categoria de infracção, está associada 
uma pontuação de 1, 2 e 5 pontos. 
 
Uma infracção é cometida por um condutor. Associado a cada infracção devem 
ficar registados a data, o local, um breve resumo da ocorrência, e o agente que 
registou a infracção. Para os agentes devem ser guardadas as seguintes infor-
mações: número do Bilhete de Identidade, o nome, o endereço e o número de 
agente da polícia. 
 
Resolução: uma possível solução, para este problema consiste nos seguintes 
passos: 
 
Primeiro Passo: extracção dos conjuntos de entidades e seus atributos 
 
TIPO_INFRACÇÃO (Categoria, Pontuação) 
 
Segundo Passo: extracção dos conjuntos de Entidades fortes e fracas e 
respectivos atributos 
 
Entidades Fortes: 
 
VEICULO (Matricula, Marca, Modelo) 
TIPO_INFRACÇÃO (Categoria, Pontuação) 
 
Entidades Fracas: 
 
INFRACÇÃO (Data, Local, Descrição) 
 
Terceiro Passo: extracção das Especializações e respectivos atributos 
 
Entidade Superclasse 
PESSOA (BI, Nome, Endereço (Rua, Casa, Bairro)) 
 
Entidade Subclasse 
 
PROPRIETÁRIO(NumContribuinte) 
CONDUTOR(NumCarta) 
POLICIA(NumAgente) 
 
Quarto Passo: extracção dos Relacionamentos, respectivos atributos e cardina-
lidade. 
 
Possuir (PROPRIETÁRIO, VEÍCULO) 1:N 
Cometeu (CONDUTOR, VEICULO,INFRACÇÃO) N:1:N 
Registou (POLÍCIA, INFRACÇÃO) 1:N 
É_Do_Tipo (TIPO_INFRACÇÃO, INFRACÇÃO) 1:N 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 53 
 
Logo, estamos em condições de apresentar o diagrama de Entidade e Relacio-
namento 
 
 
3.5.3- Um banco comercial pretende criar uma base de dados para informatizar 
o seu funcionamento. Para esse efeito foi feito um levantamento de requisitos, 
que apurou o seguinte minimundo. 
 
O banco comercial está organizado em agencias. Cada agencia está localizada 
em uma determinada cidade, e é identificada pelo seu código, nome e endereço. 
O banco controla os movimentos das suas agencias. 
 
Os clientes do banco são identificados pelos seus códigos internos. Para cada 
cliente, o banco pretende armazenar: nome, número do bilhete de identidade, 
sexo, endereço, data de nascimento, e números de telefone. Os clientes que 
possuem contas no banco podem pedir empréstimos. Um cliente pode ter um 
gestor de conta, ou um trabalhador do banco pode fazer a função do seu gestor. 
Isso quer dizer que se um cliente trabalhar no banco ele pode ser o seu gestor. 
 
Os trabalhadores do banco podem ser identificados por seus números de 
funcionários. Para além disso, a administração do banco pretende armazenar o 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 54 
 
nome, o número do telefone, o nome dos descendentes, o grau de parentesco, 
as datas de aniversário, o número do funcionário que é o seu gerente. 
 
A administração do banco também pretende controlar a data de admissão do 
funcionário, e com isso saber o seu tempo de serviço. 
 
O banco possui dois tipos de conta. A conta de poupança e conta corrente. As 
contas podem ter mais do que um cliente (conta conjunta), e um cliente pode ter 
mais do que uma conta. Cada conta de poupança possui uma taxa de juros 
mensais e o banco pretende controlar os juros que os clientes têm direito. Para 
além disso, o banco pretende controlar a movimentação (depósitos, retiradas, 
transferências) feitos pelos clientes nas suas contas correntes. 
 
Um empréstimo pode ser feito por uma agencia bancária específica e pode ser 
solicitada por um ou por mais clientes. Um empréstimo é identificado por um 
único número, um valor, o número de prestações e o valor de cada prestação. 
Mas para cada empréstimo o banco pretende controlar os pagamentos das 
prestações. 
 
Resolução: uma possível solução, para este probela, pode ser descrito pelos 
seguintes passos 
 
Primeiro Passo: extracção das Entidades e seus atributos 
 
BANCO (CodBanco, Nome) 
CLIENTE(CodCliente, Nome, BI, Endereço (Rua, Bairro, Cidade), {Telefone}, 
 DataNascimento) 
 
Segundo Passo: extracção das Entidades Fortes e Fracas e seus atributos 
 
Entidades Fortes 
 
AGENDA (NomeAgencia, Endereço (Rua, Bairro, Cidade), {Telefone})) 
FUNCIONARIO (CodFunc, Nome, {Telefone}} 
 
Entidades Fracas 
 
EMPRESTIMO (NumEmprestimo, Valor, TotPrestações, ValPrestacao) 
DEPENDENTE (Nome, GrauPatentesco, DataAniversario) 
 
Terceiro passo: extração das generalizações, especializações e seus atributos 
 
Entidade Superclasse 
 
CONTA (NumConta) 
 
Entidades Subclasses 
 
CONTA_POUPANÇA (TaxJuros, Saldo) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 55 
 
CONTA_CORRENTE (Saldo, ValorDescoberto) 
 
Quarto passo: extracção dos Relacionamentos, respectivos atributos e sua car-
dinalidade. 
 
Controla (BANCO, AGENCIA, DataAbertura) 1:N 
possui (AGENCIA, CLIENTE), 1:N 
Chefia (FUNCIONARIO, FUNCIONARIO, papel (Gerente, Funcionário)), 1:N; 
Contém (AGENCIA, CONTA) 1:N 
abre (CLIENTE, CONTA, DatAbertura), N:1 
Pode-Ser (FUNCIONARIO, CLIENTE), 1:1 
Trabalha (AGENCIA, FUNCIONARIO), 1:N 
solicita (CLIENTE, EMPRESTIMO, DataPedido) 1:N 
Paga (CLIENTE, EMPRESTIMO, DataPagamento, NumeroPrestação) N:N 
movimenta (CLIENTE, CONTA CORRENTE, DataMovimento, valor) N:N 
juros (CLIENTE, CONTA POUPANÇA, DataJuro, valor), N:N 
depende_de (FUNCIONARIO, DEPENDENTES),1:N 
 
Logo, estamos em condições de desenhar o diagrama de entidade e relaciona-
mento. Mas, a para absorção de conhecimentos, deixamos essa actividade 
como exercício. 
 
3.6 Exercícios Propostos 
 
3.6.1-Para abrir o futuro aeroporto internacional Agostinho Neto, a IATA 
(Associação Internacional de Transportes Aéreos), necessita que seja concebida 
uma base de dados para organizar a informação dos aviões que irão utilizar as 
estruturas desse aeroporto. 
 
Cada avião tem um número de matricula, um modelo específico e uma bandeira 
(angolana, portuguesa, espanhola, etc). 
 
O aeroporto pode acolher um certo número de modelos de aviões, e cada 
modelo tem um código de modelo (ex. B-777, A320), o número de lugares, e o 
peso. 
 
Para os técnicos que trabalham no aeroporto pretende-se armazenar: o número 
do Bilhete de Identidade, nome, endereço, números dos telefones, certificado 
internacional, data de emissão. 
 
Cada técnico é perito num ou mais modelos de aviões, vários técnicos podem 
ser peritos em modelos iguais, e supervisionados por um técnico que é o chefe 
da equipa. 
 
Os controladores aéreos necessitam de fazer um exame médico por ano. Para 
cada controlador pretende-se armazenar: o numero do BI, nome, números de 
telefone, e a data do seu exame mais recente. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 56 
 
Todos os empregados do aeroporto (incluindo os técnicos) pertencem a um 
sindicato e pagam mensalmente as suas quotas. Para eles é necessário 
armazenar: o número do Bilhete de Identidade, número de membro do sindicato, 
a data de ingresso no sindicado e data do pagamento da última quota. 
 
Para o sindicato, é necessário armazenar: nome e a data de fundação. 
 
O Departamento de manutenção de aeronaves, realiza periodicamente, um certo 
número de testes para verificar o estado dos aviões. Cada teste tem um número 
atribuído pela Associação Nacional de Aeroportos (ANA), o nome do teste e 
pontuação recebida. A IATA exige que o aeroporto mantenha informação sobre 
cada vez que um avião é sujeito a um determinado teste. Para cada teste é 
necessário armazenar: data de manutenção, número de horas gastas pelo 
técnico, pontuação obtida pelo avião, e o técnico que realizou a manutenção. 
 
3.6.2- A Faculdade de Engenhariaficou com a responsabilidade de desenvolver 
uma base de dados para automatizar as matriculas dos estudantes na UCAN. 
 
Cada estudante é identificado por um número. Para além disso, ele possui um 
BI, um nome, uma data de nascimento, vários números de telefones e está 
matriculado num único curso. 
 
Cada disciplina é identificada por um código, um nome, um ano, um semestre, 
uma carga horária semestral, e está inserida numa grelha curricular de um curso. 
 
Um estudante pode matricular-se a várias disciplinas desde que tenham pré-
requisito para fazê-las (ex: para matricular-se a fundamentos de Programação II 
é necessário que tenha feito fundamentos de programação I). Se a matricula de 
um estudante for aceite pelo sistema deve ser armazenar a data que o estudante 
efectou essa matricula. 
 
Uma disciplina pode ser ministrada em mais do que um curso (ex: fundamentos 
de programação I é ministrada no curso de Informática e no curso de 
Telecomunicações). 
 
Cada curso pertence a uma faculdade (ex: Informática é da Faculdade de 
Engenharia) e é identificada por: código, nome, regime (diurno ou pós-laboral), 
número de semestres. Cada Faculdade é identificada por um código e um nome. 
Mas, também se pretende armazenar a data que o curso começou a funcionar. 
 
Todas as disciplinas dos cursos são semestrais. Quando se oferece uma 
disciplina é necessário que existe um docente disponível para ministra-la. Para 
os docentes, pretendemos armazenar: código interno, BI, nome, telefones, grau 
académico (licenciado, mestre ou doutor) e uma categoria (professor e 
assistente). Mas, ao ser oferecido uma disciplina podemos ter outros docentes a 
ministra-la. A Faculdade possui dois tipos de docentes: os professores e os 
assistentes. Os primeiros são os regentes das disciplinas enquanto os segundos 
dão apenas as aulas de laboratório. Quando o estudante efectua uma matricula 
o sistema deve mostrar o nome do regente e o(s) nome(s) dos assistentes. Mas 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 57 
 
a faculdade pode oferecer a mesma disciplina em várias turmas (ex: turma A, B, 
C…), e nessa altura o sistema deve mostrar os professores que irão ministrar as 
disciplinas em cada turma. 
 
3.6.3- Uma pequena empresa de táxis aéreos pretende informatizar o seu sis-
tema de reservas de passagem. Este sistema funcionará com uma base de da-
dos centralizada que poderá ser acedida pelos funcionários no interior da em-
presa ou no exterior. 
 
Para cada funcionário, o sistema deve armazenar as seguintes informações: có-
digo interno, número do BI, primeiro nome, último nome, endereço, números de 
telefones, emails e data de admissão na empresa. 
 
Para cada passageiro, o sistema deve armazenar as seguintes informações: nú-
mero do BI, primeiro nome, último nome, endereço, números de telefones e 
emails. 
 
Para cada reserva o sistema deve armazenar as seguintes informações: código 
da reserva que é gerado automaticamente, número do BI do passageiro, código 
do voo, data e hora da viagem. 
 
Para cada aeronave o sistema deve armazenar as seguintes informações: ma-
tricula, marca, modelo, total de lugares. 
 
Um voo é identificado por um código, possui uma origem, um destino do voo e 
escalas se houver. Por exemplo, o voo DT594 sai de Luanda com destino a Ben-
guela e tem uma escala no Sumbe. 
 
Muitas vezes ao fazer uma reserva, os clientes querem saber qual é o tipo de 
aeronave que será utilizado. 
 
Para garantir a operacionalidade da companhia, está possui um horário mensal 
onde para cada voo estão programadas: dia, hora de partida, hora de chegada, 
destino, escalas se houver, tipo de avião, estado do voo que pode ser aberto, 
encerrado ou cancelado. 
 
Se o voo estiver no estado aberto, os clientes podem fazer as suas reservas e 
estas têm um prazo de validade se o cliente não feito o pagamento. Durante esse 
prazo de validade essas reservas não podem ser canceladas. Se o cliente fizer 
o pagamento a reserva é confirmada e o sistema reserva um lugar no avião. 
 
A base de dados deve garantir que o voo será encerrado, ou que o cliente não 
poderá fazer mais reserva, quando o número de reservas confirmadas for igual 
ao número de lugares do avião. 
 
A base de dados também deve notificar aos clientes, através dos seus emails se 
um determinado voo foi cancelado 
 
3.7 Leituras Recomendadas 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
 Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 58 
 
 
Para aprofundar os temas tratados neste capítulo, recomendados que o leitor 
consulte um dos seguintes livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 8- O modelo de Entidade Relacionamento Esten-
dido (EER), Tradução da 6ª edição americana, São Paulo, Pearson Addi-
son Wesley, 2011. 
 
 Heuser C. A.;- Projeto de Banco de Dados, 6ª Edição, Instituto de Infor-
mática da UFRGS, capítulo 2: Abordagem Entidade-Relacionamento e 
capitulo 3- Construindo Modelo ER, Porto Alegre, Bookman, 2009. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Tradução da 3ª edição americana, Capítulo 2- Introdução ao Pro-
jeto de Banco de Dados, McGraw-Hill, 2008. 
 
 Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, Capítulo 6- Modelagem Avançada, tradução da 8ª edi-
ção americana Edição, Cengage Learning, 2010. 
 
 Silberschatz A., Korth F. K, Sudarshan S.;- Sistema de Banco de Dados, 
tradução da 5ª edição Parte2 Projeto de Banco de Dados, Capítulo 6 – 
Projeto de Banco de Dados e o Modelo E-R, Rio de Janeiro, Elsevier, 
2012 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 59 
 
 
4 
Capítulo 
Modelo Relacional 
 
“O objectivo elementar de um projecto de bases de dados é possibilitar ao utilizador obter informações 
exactas em um limite de tempo aceitável, de forma a executar a sua tarefa dentro de uma organização” 
 
- Teorey & Fry - 
 
4.1 Introdução 
 
O modelo relacional foi proposto pelo matemático e cientista da computação bri-
tânico, Edgar Frank Codd, pesquisador da IBM, que em 1970 publicou um artigo 
com o título “A Relational Model of Data for Large Shared Data Banks", na re-
vista ACM (Association for Computing Machinery), Vol. 13, no. 6, pp. 377-387. 
 
Este modelo é muito simples, e sua construção baseia-se no conceito de relação 
matemática, enquanto que a sua base teórica, baseia-se na teoria dos conjuntos 
e na lógica matemática de primeira ordem. 
 
Neste capítulo iremos abordar as características elementares desse modelo e 
de suas restrições. 
 
4.2 Conceitos 
 
O modelo relacional representa uma base de dados como um conjunto de tabe-
las relacionadas entre si. O termo tabela, é a denominação mais utilizado para 
os produtos comerciais, mas no mundo académico utiliza-se o termo relação. 
 
Definição: uma tabela é um conjunto bidimensional, onde cada linha (tupla) re-
presenta uma entidade ou um relacionamento, e cada coluna representa um atri-
buto. Cada linha é composta por uma série de campos (que na terminologia aca-
démica é valor do atributo) 
 
No exemplo a seguir, a tabela armazena os dados dos empregados de uma em-
presa. 
 
Cod Empregado Nome Endereço Data Nascimento 
100101 Manuel Silva Avenida da liberdade, prédio 32, prenda 21- 06-1970 
200724 Carlos Alberto Av. Combatentes, casa 1600, São Paulo 12-02-2010 
700231 Katia Rafael Rua de massangano, casa 125, cruzeiro 21-05-2002 
170912 Quissua Dias Avenida 1 de janeiro, casa 75, cassequel 27-04-2009 
 
http://www.acm.org/
https://pt.wikipedia.org/wiki/Association_for_Computing_Machinery
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para usoexclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 60 
 
No cabeçalho dessa tabela temos os nomes dos atributos, nas colunas os valo-
res que esses atributos podem receber (domínio) nas linhas (tuplas) os dados 
de cada empregado (em termos académicos, os atributos de cada tupla). 
 
Propriedades das tabelas: as linhas de uma tabela possuem as seguintes pro-
priedades: 
- Não estão ordenadas; 
- Não podemos ter duas ou mais linhas com os mesmos conteúdos; 
 
enquanto que as colunas de uma tabela: 
 - todas as colunas têm um nome; 
- Os seus valores são atômicos, ou seja, não podem ser compostos; 
- Os seus valores são monovalorados, logo só possuem um único valor; 
 
A tabela anterior não está em conformidade com as essas propriedades, porque 
na coluna endereço representa um atributo composto. Para normaliza-la, ou 
seja, adequa-la ao modelo relacional temos de decompô-la em várias colunas, 
uma para cada atributo simples. 
 
Cod Empregado Nome Rua casa bairro Data Nascimento 
100101 Manuel Silva Avenida da Liberdade 32 Prenda 21- 06-1970 
200724 Carlos Alberto Avenida Combatentes 85 São Paulo 12-02-1992 
700231 Katia Rafael Rua Massangano 125 Cruzeiro 21-05-1985 
170912 Quissua Dias Avenida 21 janeiro 75 Gamek 27-04-2009 
 
Vejamos mais um exemplo, a tabela a seguir, mostra os endereços dos empre-
gados de uma empresa. 
 
Cod Empregado Nome Telefone 
100101 Manuel Silva 932-223-756 / 912- 212-767 
200724 Carlos Alberto 912- 732-457 
700231 Katia Rafael 923- 567- 621 / 912- 723-912 
170912 Quissua Dias 921-20-27-72 
 
Está tabela não está em conformidade com as propriedades do modelo relacio-
nal, porque na coluna telefone representa um atributo multivariado. Para ade-
qua-la ao modelo relacional temos de fragmenta-lo em vários colunas, uma para 
cada telefone. 
 
Cod Empregado Nome Telefone Unitel Telefone Movicel 
100101 Manuel Silva 932-223-756 912- 212-767 
200724 Carlos Alberto 912- 732-457 
700231 Katia Rafael 923-567-621 912- 723-912 
170912 Quissua Dias 921-20-27-72 
 
4.3 Chave Primária 
 
Definição: uma chave primária (PK) é representada por uma coluna ou uma 
combinação de colunas cujos valores são únicos em toda a tabela. Em outros 
termos, uma coluna ou uma combinação de colunas, cujos valores distinguem 
uma linha das restantes linhas da tabela. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 61 
 
Por exemplo, na tabela de empregados 
 
 
Cod Empregado Nome Rua casa bairro Data Nascimento 
100101 Manuel Silva Avenida da Liberdade 32 Prenda 21- 06-1970 
200724 Carlos Alberto Avenida Combatentes 85 São paulo 12-02-1992 
700231 Katia Rafael Rua massangano 125 Cruzeiro 21-05-1985 
 Chave primária 
 
Enquanto que na tabela de dependentes 
 
Cod Empregado Nome dependente Grau parentesco Data Nascimento 
100101 Osvaldo Silva filho 01- 01-2005 
100101 Hernami Silva sobrinha 16-07-2010 
100101 Karine santos enteada 14-08-2012 
700231 Djamila Carina filho 21-12-2015 
 Chave primária 
 
A chave primária é a concatenação do código de empregado pelo nome do de-
pendente. 
 
Definição: uma chave primária (PK) pode ser uma concatenação de várias co-
lunas de uma tabela, desde que essa concatenação ocorra uma e apenas uma 
vez na tabela e seja mínima. 
 
4.4 Chave Estrangeira 
 
Definição: uma chave estrangeira (FK) pode ser representada por uma coluna 
ou uma coleção de várias colunas de uma tabela, cujos valores aparecem como 
chave primária de uma outra coluna. 
 
Por exemplo, suponhamos que temos a uma tabela com os departamentos de 
uma empresa de distribuição alimentar: 
 
 
Cod Departamento Nome Departamento Telefone serviço Email institucional 
01 compras 923 724 028 compras@ve.co.ao 
02 vendas 923 724 029 vendas@ve.co.ao 
03 contabilidade 923 724 022 contab@ve.co.ao 
04 Pessoal 923 724 027 pessoa@ve.co.ao 
05 Informática 923 724 011 Info@ve.co.ao 
 Chave primária 
 
A tabela de empregados dessa empresa possui os seguintes atributos 
 
Cod empregado Nome empregado Telefone 
Empregado 
Cod. Departa-
mento 
Categoria profis-
sional 
100720 Wilson Carlos Monteiro 912 721 072 01 Assistente 
170001 Rebeca da Graça Martins 923 031 712 02 caixa 
1800042 Luana Soares Castro 921 514 222 02 caixa 
170320 Edmilson André Alfredo 912 720 072 03 Contabilista 
140923 Cristina dos santos 923 025 021 05 Programador 
170912 Quissua Dias 923 777 228 05 Help-desk 
 Chave primária Chave estrangeira 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 62 
 
 
Na tabela anterior, a coluna código de empregado, representa a chave primária, 
enquanto que a coluna código do departamento representa a chave estrangeira. 
 
Mas uma base de dados está bem projectada, quando não possui informação 
redundante, e o seu armazenamento ocupa a menor quantidade de bytes possí-
vel. Observe que na tabela anterior, a coluna categoria profissional é uma cadeia 
de caracteres que ocupa uma determinada quantidade de bytes. Se nessa base 
de dados, estiverem contidos os dados dos trabalhadores de uma empresa mul-
tinacional, ela certamente irá ter muita informação redundante e com isso irá 
gastar muitos recursos de memória desnecessários. Como podemos evitar essa 
redundância de informação e optimizar os recursos de memória para armazenar 
a tabela. 
 
A solução mais correcta, e que satisfaz as boas prácticas de desenho de bases 
de dados, consiste em declarar uma tabela com as categorias profissionais. 
 
Cod categoria Nome categoria 
01 Assistente 
02 Contabilista 
03 Caixa 
04 Eletricista 
05 Gerente 
06 Programador 
07 Help-desk 
 Chave primária 
 
Substituir na tabela de empregados, o nome da categoria profissional pelo res-
pectivo código. 
 
Desse modo, essa tabela possui duas chaves estrangeiras: o código do depar-
tamento e o código da categoria profissional. 
 
Cod empre-
gado 
Nome empregado Telefone 
empregado 
Cod. Departa-
mento 
Cod. Categoria 
profissional 
100720 Wilson Carlos Monteiro 912 721 072 
170001 Rebeca da Graça Martins 923 031 712 02 03 
1800042 Luana Soares Castro 921 514 222 02 03 
170320 Edmilson André Alfredo 912 720 072 03 02 
140923 Cristina dos Santos 923 025 021 01 01 
170912 Quissua Dias 923 777 228 05 07 
 Chave primária chave estrangeira chave estrangeira 
 
Observação: Não se pode ter numa tabela um valor de uma chave estrangeira 
que não esteja contida numa outra tabela como chave primária. 
 
Para garantir a consistência de uma base de dados, a existência de uma chave 
estrangeira, deve satisfazer as seguintes regras: 
 
1ª- Para incluir uma linha(tupla) de uma tabela com uma chave estrangeira(FK) 
é necessário garantir que essa chave já tenha sido incluída como chave primária 
(PK) de uma outra tabela; 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 63 
 
2ª- Para alterar o conteúdo de uma chave estrangeira (FK), é necessário garantir 
que esse valor esteja contido numa outra tabela como chave primária; 
 
3º- Para excluir uma chave primária (PK) de uma tabela, é necessário garantir 
que todas as ocorrências dessa chave nas restantes tabelas, onde ela é referen-
ciada como chave estrangeira(FK) tenham sido excluídas. 
 
A existência de uma chave estrangeira pode levarmos a crer que ela sempre faz 
referencia a uma chave primária de uma outra tabela. Mas na verdade uma 
chave estrangeira pode fazer referencia a uma chave primária que está contidana mesma tabela. 
 
Por exemplo a tabela a seguir mostra que os empregados Wilson, Rebeca e 
Edmilson são subordinados da funcionária Cristina, e que a funcionária Cristina 
é subordinada da funcionária Quissua. 
 
Cod empre-
gado 
Nome empregado Telefone 
Empregado 
Cod. Departa-
mento 
Cod. Gerente 
100720 Wilson Carlos Monteiro 912 721 072 01 140923 
170001 Rebeca Martins 923 031 712 02 140923 
1800042 Luana Soares Castro 921 514 222 02 170912 
170320 Edmilson André Alfredo 912 720 072 03 140923 
140923 Cristina dos santos 923 025 021 05 170912 
170912 Quissua Dias 923 777 228 05 - 
 Chave primária Chave estrangeira Chave estrangeira 
 
4.5 Chave Candidata 
 
Uma chave candidata é uma coluna ou uma concatenação de colunas que po-
dem ser utilizadas como chave para aceder à uma linha (tupla) da tabela. Por 
exemplo, na tabela de empregados 
 
Cod empre-
gado 
Nome empregado Telefone 
Empregado 
Cod. INSS Cod. Ca-
tegoria 
Telefone 
Pessoal 
100720 Wilson Carlos Monteiro 912 721 072 272470 01 912327627 
170001 Rebeca Martins 923 031 712 697271 03 933561297 
1800042 Luana Soares Castro 921 514 222 192824 03 912728420 
170320 Edmilson André Alfredo 912 720 072 574529 02 923745777 
140923 Cristina dos santos 923 025 021 439727 06 933456819 
170912 Quissua Dias 923 777 228 319746 07 912345867 
 chave primária chave candidata chave candidata 
 
as colunas número de telefone pessoal e número do INSS são chaves 
candidatos. 
 
4.6 Domínio de um Atributo 
 
Quando uma tabela é definida, para cada atributo deve ser declarado o conjunto 
de valores que esse atributo poderá receber. Esse conjunto de valores é deno-
minado por domínio de um atributo. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 64 
 
Por exemplo, na tabela de empregados, o nome do empregado deve ser decla-
rado como cadeia com 20 caracteres, enquanto que o número de telefone um 
conjunto com 9 dígitos. 
 
O domínio de um atributo é um tipo de dados elementar. No modelo relacional 
temos os seguintes tipos de dados elementares: inteiro, real, caracter, data, hora, 
etc. Para além desses tipos de dados elementos, alguns atributos podem rece-
ber valores nulos (NULL em Inglês). 
 
Observação: nos SGBD todas as colunas que compõem uma chave primária 
devem ter um valor obrigatório. 
 
4.7 Restrições de Integridade 
 
Uma restrição de integridade é uma regra que serve para garantir a consistência 
de uma base de dados, e é fornecida pelo SGBD. As restrições de integridade 
possuem as seguintes classificações: 
 
1º- Integridade de domínio: através dessa restrição, define-se os valores que 
uma coluna (atributo) deve receber; 
 
2º- Integridade Vazio: através deste tipo de restrição, define-se se os campos de 
uma coluna (atributo) podem receber um valor nulo; 
 
3º- Integridade Chave: através deste tipo de restrição, define-se se os valores de 
uma chave primária e uma chave estrangeira devem ser únicos; 
 
4º- Integridade Referencial: através deste tipo de restrição, define-se que os va-
lores dos campos que aparecem numa chave estrangeira devem estar contidos 
numa chave primária. 
 
4.8 Esquema de uma Base de Dados 
 
Um Esquema da Base de Dados é uma representação gráfica ou textual de um 
modelo de dados. Embora a representação gráfica apresenta inúmeras vanta-
gens, nestas notas iremos resolver os nossos problemas com uma notação tex-
tual, que é uma variante da notação utilizada proposta por Heuser[2009]. 
 
Recomendação: para desenhar-se projectos de modelagem de Bases de Dados 
em ambientes profissionais, deve-se utilizar uma ferramenta gráfica. 
 
Embora existam no mercado muitas ferramentas gráficas (ferramentas CASE), 
aconselhamos que utilize a ferramenta draw.io porque ser gratuita e muito fácil 
de ser utilizada. 
 
Agora vamos nos concentrar, através de um exemplo, na apresentação de um 
esquema de base de dados relacional, com a notação que iremos utilizar nestas 
notas. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 65 
 
A tabela DEPARTAMENTO 
 
Cod Departamento Nome Departamento Telefone Serviço Email institucional 
01 compras 923 724 028 compras@ve.co.ao 
02 vendas 923 724 029 vendas@ve.co.ao 
03 contabilidade 923 724 022 contab@ve.co.ao 
04 Pessoal 923 724 027 pessoa@ve.co.ao 
05 Informática 923 724 011 Info@ve.co.ao 
 Chave primaria 
 
é representada pelo seguinte esquema relacional 
 
DEPARTAMENTO (CodDepto, NomeDepto, TelDepto, EmailDepto) 
PK (CodDepto) 
 
e corresponde ao seguinte diagrama de Entidade e Relacionamento 
 
 
 
 
enquanto que tabela DEPARTAMENTO 
 
Cod Departamento Nome Departamento Telefone serviço Email institucional 
01 compras 923 724 028 compras@ve.co.ao 
02 vendas 923 724 029 vendas@ve.co.ao 
03 contabilidade 923 724 022 contab@ve.co.ao 
04 Pessoal 923 724 027 pessoa@ve.co.ao 
05 Informática 923 724 011 Info@ve.co.ao 
 Chave primária 
 
e a tabela EMPREGADO 
 
Cod empregado Nome empregado Telefone 
empregado 
Cod. Departa-
mento 
Categoria profis-
sional 
100720 Wilson Carlos Monteiro 923 724 028 01 Assistente 
170001 Rebeca da Graça Martins 923 724 029 02 caixa 
1800042 Luana Soares Castro 923 724 022 02 caixa 
170320 Edmilson André Alfredo 923 724 028 03 Contabilista 
140923 Cristina dos santos 923 724 022 05 Programador 
170912 Quissua Dias 923 724 028 05 Help-desk 
 Chave primária Chave estrangeira 
 
são representadas pelo esquema relacional 
 
DEPARTAMENTO (CodDepto,NomeDepto,TelDepto,EmailDepto) 
PK (CodDepto) 
 
EMPREGADO (CodEmp, NomeEmp, TelEmp, CodDepto,Categoria) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 66 
 
PK (CodEmp) 
FK (CodDep) REFERENTE DEPARTAMENTO(CodDepto) 
 
e correspondem ao seguinte Diagrama de Entidade e Relacionamento 
 
 
 
Mas existem alguns casos reias, quando utilizamos entidades fracas, que a 
chave estrangeira é obtida através da concatenação de vários campos. 
 
Por exemplo: A tabela EMPREGADO 
 
Cod Empregado Nome Rua casa bairro Data Nascimento 
100101 Manuel Silva Avenida da Liberdade 32 Prenda 21- 06-1970 
200724 Carlos Alberto Avenida Combatentes 85 São paulo 12-02-1992 
700231 Katia Rafael Rua massangano 125 Cruzeiro 21-05-1985 
 Chave primária 
 
e a tabela DEPENDENTE 
 
Cod Empregado Nome dependente Grau parentesco Data Nascimento 
100101 Osvaldo Silva filho 01- 01-2005 
100101 Hernami Silva sobrinha 16-07-2010 
100101 Karine santos enteada 14-08-2012 
700231 Djamila Carina filho 21-12-2015 
 Chave primária 
 
são representadas pelo esquema relacional 
 
EMPREGADO (CodEmp, NomeEmp, Rua, Casa, Bairro, DataNasc) 
PK (CodEmp) 
 
DEPENDENTE (CodEmp, NomeDepend, GrauParente, DataNasc) 
PK (CodEmp,NomeDepend) 
FK (CodEmp) REFERENTE EMPREGADO(CodEmp) 
 
e correspondem ao seguinte diagrama de Entidade e Relacionamento 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 67 
 
 
 
4.9 Leituras Recomendadas 
 
Para aprofundar os temas tratados neste capítulo, recomendados que o leitor 
consulte um dos seguintes livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 3 - O Modelo Relacional e as restrições em Banco 
de Dados Relacionais, Tradução da 6ª edição americana, São Paulo, 
Pearson Addison Wesley, 2011. 
 
 Heuser C. A.;- Projeto de Bancode Dados, 6ª Edição, Instituto de Infor-
mática da UFRGS, capítulo 4- Abordagem Relacional, Porto Alegre, Book-
man, 2009. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Capítulo 3: O Modelo Relacional, Tradução da 3ª edição ameri-
cana, São Paulo, McGraw-Hill, 2008. 
 
 Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, Capítulo 3 – Modelo de Banco de Dados Relacional, tra-
dução da 8ª edição americana Edição, Cengage Learning, 2010. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 68 
 
 
5 
Capítulo 
Conversão de Modelos 
 
“Uma base de dados representa algum aspecto do mundo real, às vezes chamado de minimundo ou 
de universo de discurso (UoD – Universe of Discourse).” 
 - Elmasri & Navathe - 
 
5.1 Introdução 
 
Neste capítulo veremos como se converte um Diagrama de Entidade e Relacio-
namento para um esquema de um Base de Bados Relacional, que na literatura 
da Ciência de Computação denomina-se por projecto lógico. 
 
Para efectuar essa conversão, veremos um conjunto de regras, baseadas nas 
experiencias acumuladas de muitos autores, que mostram como se deve imple-
mentar esse projecto lógico, para que se possa obter uma base de dados relaci-
onal eficiente. 
 
Para efectuar essa conversão, utilizaremos a seguinte notação: a chave primária 
(PK) será assinalado um traço, enquanto que a chave estrangeira (FK) com a 
letra em bold. 
 
5.2 Entidade Forte 
 
Dado uma entidade forte E com atributos a1, a2, …, an. Para converter esta 
entidade para o modelo relacional, necessitamos de uma tabela, com mesmo 
nome da entidade forte, que possui n colunas distintas que irão armazenar os 
valores dos n atributos dessa entidade. O atributo chave passa a ser a chave 
primária dessa tabela. 
 
Por exemplo: 
 
 
que corresponde ao esquema relacional 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 69 
 
EMPREGADO (CodEmpregado, NomeEmpregado) 
PK (CodEmpregado) 
 
 
5.3 Entidade com Atributos Compostos 
 
Dado um conjunto de entidade E com n atributos a1, a2, a3, …,an, e seja aj um 
atributo composto, para 1≤ j ≤ n. Para converter está entidade para o modelo 
relacional, necessitamos de apenas uma tabela, com o mesmo nome da 
entidade E, e o seu número de colunas deve ser igual ao número de atributos 
simples do conjunto de entidade E. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
ESTUDANTE (CodEstudante, NomeEstudante, Rua, Casa, Bairro) 
PK (CodEstudante) 
 
5.4 Entidades com Atributos Multivalorados 
 
Dado um conjunto de entidade E com atributos a1, a2, a3, …, an, e seja aj um 
atributo multivalorado, para 1≤ j≤ n. Para converter está entidade para o modelo 
relacional, necessitamos de duas tabelas. A primeira denominada por E, possui 
n-1 colunas distintas para armazenar os valores atributos a1, a2, a3, …, aj-1, 
aj+1,…,an; A segunda denominada por F, possui apenas duas colunas, uma para 
armazenar o atributo chave do conjunto de entidade E, e outra para armazenar 
cada o valor de uma ocorrência do atributo multivalorado cj. 
 
Por exemplo: 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 70 
 
 
 
 
que corresponde ao esquema relacional 
 
EMPREGADO (CodEmpregado, NomeEmpregado) 
PK (CodEmpregado) 
 
TELEFONE (CodEmpregado, Telefone) 
FK (CodEmpregado) REFERENTE EMPREGADO(CodEmpregado) 
 
5.5 Entidade Fraca 
 
Dado um conjunto de entidade forte E1 com chaves a1, a2,…., an, que se relaci-
ona com um conjunto de entidade fraca E2 com atributos b1,b2,…,bk. Para con-
verter a entidade fraca para o modelo relacional, independentemente da cardi-
nalidade dessa relação, necessitamos de uma tabela com n+k colunas distintas, 
que irão armazenar os valores das n chaves da entidade forte E1, e os valores 
dos k atributos da entidade fraca E2. 
 
Por exemplo: 
 
 
 
 
que corresponde ao esquema relacional 
 
EMPREGADO (CodEmpregado, NomeEmpregado) 
PK (CodEmpregado) 
 
DEPENDENTE (CodEmpregado, NomeDependente, Sexo) 
PK (CodEmpregado, NomeDependente) 
FK (CodEmpregado) REFERENTE EMPREGADO (CodEmpregado) 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 71 
 
Observação: a chave primária da entidade fraca será composta pela chave local 
e a chave primária da entidade forte que a subordina. 
 
Vamos aprofundar esse assunto com um exemplo onde se aplica o conceito de 
entidade fraca de forma sucessiva. 
 
 
 
que corresponde ao esquema relacional 
 
PROVINCIA (CodProvincia, NomeProvincia) 
PK (CodProv) 
 
MUNICIPIO (CodProvincia, CodMunicipio, NomeMunicipio) 
PK (CodProvincia,CodMunicipio) 
FK (CodProvincia) REFERENTE PROVINCIA (CodProvincia) 
 
COMUNA (CodProvincia, CodMunicipio,CodComuna, NomeComuna) 
PK (CodProvincia,CodMunicipio, CodComuna) 
FK (CodProvincia, CodMunicipio) REFERENTE MUNICIPIO(CodProvincia, 
CodMunipio) 
 
 
5.6 Relacionamentos 1:1 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que se relaciona 
com conjunto de entidade E2 com atributos b1,b2,b3,…,bk, com cardinalidade 
Um-para-Um. Para converter este relacionamento necessitamos de duas 
tabelas. A primeira denotada por E1, possui n colunas distintas para conter os 
valores dos n atributos da entidade E1; a segunda denominada por E2, possui 
k+1 colunas distintas, para conter os valores dos k atributos da entidade E2 mais 
o valor do atributo chave da entidade E1. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 72 
 
EMPREGADO (CodEmpregado, NomeEmpregado) 
PK (CodEmpregado) 
 
DEPARTAMENTO (CodDepto, NomeDepto, CodEmpregado) 
PK (CodDepto) 
FK (CodEmpregado) REFERENTE EMPREGADO(CodEmpregado) 
 
5.7 Relacionamentos 1:1 com atributo 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que se relaciona 
com conjunto de entidade E2 com atributos b1,b2,b3,…,bk, com cardinalidade 
Um-para-Um, e supomos que nesse relacionamento temos um atributo r. Para 
converter este relacionamento para o modelo relacional, necessitamos de duas 
tabelas. A primeira denotada por E1, possui n colunas distintas para conter os 
valores dos n atributos da entidade E1; a segunda denominada por E2, possui 
k+2 colunas distintas, para conter os valores dos k atributos da entidade E2, o 
valor do atributo chave da entidade E1, e o valor do atributo r desse 
relacionamento. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
PESSOA (NumBI, Nome) 
PK (NumBI) 
 
CARTA (NumCarta, DataEmissao, Validade, Categoria, NumBI, DataEntrega) 
PK (NumCarta) 
FK (NumBI) REFERENTE PESSOA (NumBI) 
 
 
5.8 Relacionamentos 1:n 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que se relaciona 
com conjunto de entidade E2 com atributos b1,b2,b3,…,bk, com cardinalidade 
Um-para-Muitos. Para converter este relacionamento necessitamos de duas 
tabelas. A primeira denotada por E1, possui n colunas distintas para conter os 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 73 
 
valores dos n atributos da entidade E1; a segunda denominada por E2, possui 
k+1 colunas distintas, para conter os valoresdos k atributos da entidade E2 mais 
o valor do atributo chave da entidade E1. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
FACULDADE (CodFaculdade, NomeFaculdade) 
PK (CodFaculdade) 
 
CURSO (CodCurso, NomeCurso, CodFaculdade) 
PK (CodCurso) 
FK (CodFaculdade) REFERENTE FACULDADE (CodFaculdade) 
 
5.9 Relacionamentos 1:N com atributo 
 
Dado um conjunto de entidade E1 com n atributos a1, a2, a3, …, an que se 
relaciona com um conjunto de entidade E2 com k atributos b1,b2, b3,..,bk, com 
cardinalidade Um-para-Muitos, e supomos que nesse relacionamento temos um 
atributo r. Para converter esse relacionamento para o modelo relacional, 
necessitamos de duas tabelas. A primeira denotada por E1, possui n colunas 
distintas para armazenar os valores dos n atributos da entidade E1; a segunda 
denotada por E2, possui k+2 colunas distintas, para armazenar os valores dos k 
atributos da entidade E2, mais o valor do atributo chave da entidade E1, e o valor 
do atributo r desse relacionamento. 
 
 
Por exemplo: 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 74 
 
que corresponde ao esquema relacional 
 
DEPARTAMENTO (CodDepartamento, NomeDepartamento) 
PK (CodDepartamento) 
 
EMPREGADO (CodEmpregado, NomeEmpregado, CodDepartamento, DataInicio) 
PK (CodEmpregado) 
FK (CodDepartamento) REFERENTE DEPARTAMENTO (CodDepartamento) 
 
5.10 Relacionamentos N:N 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3, ... ,an, que se relaciona 
com um conjunto de entidade E2 com atributos b1,b2, b3,…,bk, com cardinalidade 
Muitos-para-Muitos. Para converter este relacionamento para o modelo 
relacional, necessitamos de três tabelas. A primeira denotada por E1, possui n 
colunas distintas para armazenar os valores dos n atributos da entidade E1; a 
segunda denotada por E2, possui k colunas distintas para armazenar os valores 
dos k atributos da entidade E2, a terceira denotada por denotada por E3, possui 
apenas duas colunas, uma para armazenar os valores do atributo chave da 
entidade E1 e outra para armazenar os valores do atributo chave da E2. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
MEDICO (CodMedico, NomeMedico) 
PK (CodMedico) 
 
PACIENTE (CodPaciente, NomePaciente) 
PK (CodPaciente) 
 
CONSULTA (CodMedico, CodPaciente) 
FK (CodPaciente) REFERENTE PACIENTE (CodPaciente) 
FK (CodMedico) REFERENTE MEDICO (CodMedico) 
 
5.11 Relacionamentos N:N com Atributo 
 
Dado um conjunto de entidade E1 com n atributos a1, a2, a3, …, an que se 
relaciona com um conjunto de entidade E2 com k atributos b1,b2, b3,...,bk, com 
cardinalidade Muitos-para-Muitos, e suponhamos que nesse relacionamento 
temos um atributo r. Para converter esse relacionamento para o modelo 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 75 
 
relacional, necessitamos de três tabelas. A primeira denotada por E1, possui n 
colunas distintas para armazenar os valores dos n atributos da entidade E1; a 
segunda denotada por E2, possui k colunas distintas para armazenar os k 
atributos da entidade E2; a terceira denotada por E3, possui apenas três colunas 
distintas. Uma para armazenar os valores do atributo chave da entidade E1, 
outra para armazenar os valores do atributo chave da entidade E2, e uma 
terceira para armazenar os valores do atributo desse relacionamento. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
EMPREGADO (CodEmpregado, NomeEmpregado) 
PK (CodEmpregado) 
 
PROJECTO (CodProjecto, NomeProjecto) 
PK (CodProjecto) 
 
DESENVOLVE (CodProjecto, CodEmpregado, TotalHoras) 
FK (CodProjecto) REFERENTE PROJECTO (CodProjecto) 
FK (CodEmpregado) REFERENTE EMPREGADO (CodEmpregado) 
 
 
5.12 Auto- Relacionamentos 1:1 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que relaciona-
se com ele mesmo, com cardinalidade Um-para-Um. Para converter este 
relacionamento para o modelo relacional, necessitamos de uma tabela 
denominada por E1 com n+1 colunas distintas para armazenar os n valores dos 
atributos da entidade E1, mais o valor do atributo chave que faz o outro papel. 
 
Por exemplo: 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 76 
 
 
 
que corresponde ao esquema relacional 
 
PESSOA (CodPessoa, NomePessoa, CodConjuge) 
PK (CodPessoa) 
FK (CodConjuge) REFERENTE PESSOA(CodPessoa) 
 
5.13 Auto- Relacionamentos 1:N 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que relaciona-
se com ele mesmo, com cardinalidade Um-para-Muitos. Para converter este 
relacionamento para o modelo relacional, necessitamos de uma tabela 
denominada por E1 com n+1 colunas distintas para armazenar os n valores dos 
atributos da entidade E1, mais o valor do atributo chave que faz o outro papel. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
EMPREGADO (CodEmpregado, NomeEmpregado, CodSupervidor) 
PK (CodEmpregado) 
FK (CodSupervidor) REFERENTE EMPREGADO(CodEmpregado) 
 
5.14 Auto- Relacionamentos N:N 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3,…,an, que relaciona-
se com ele mesmo, com cardinalidade Muitos-para-Muitos. Para converter este 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 77 
 
relacionamento para o modelo relacional, necessitamos de duas tabelas. A 
primeira denotada por E1, possui n colunas distintas para armazenar os valores 
dos n atributos da entidade E1; a segunda denotada por E2, possui duas colunas 
distintas para armazenar os valores do atributo chave da entidade E1 e os 
valores do atributo chave da entidade E2. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
PRODUTO (CodProduto, NomeProduto) 
PK (CodProduto) 
 
COMPOSICAO (CodProduto, CodComposicao) 
FK (CodProduto) REFERENTE PRODUTO (CodProduto) 
FK (CodComposicao) REFERENTE PRODUTO (CodProduto) 
 
Observação: é sempre possível, mas não recomendável, converter os relacio-
namentos do tipo 1:1 ou 1:N com a mesma regra de conversão dos relaciona-
mentos do tipo M:M, ou seja, criar uma nova uma tabela para representar o re-
lacionamento. No entanto, essa opção só deve ser utilizada quando se sabe que 
a cardinalidade do relacionamento pode ser alterada no futuro. 
 
5.15 Relacionamentos com grau maior de que dois 
 
Dado um conjunto de entidade E1 com atributos a1, a2, a3, …, an, que se 
relaciona com um conjunto de entidade E2 com atributos b1,b2, b3,…,bk, que por 
sua vez se relaciona com um conjunto de entidade E3 com atributos 
c1,c2,c3,…,cm. Para converter este relacionamento para o modelo relacional, 
independentemente da cardinalidade, necessitamos de quatro tabelas. A 
primeira, denotada por E1 possui n colunas distintas para armazenar os valores 
dos n atributos da entidade E1; a segunda denotada por E2, possui k colunas 
distintas para armazenar os valores dos k atributos da entidade E2; a terceira 
denotada por E3, possui m colunas distintas para armazenar os valores dos m 
atributos da entidade E3; e a quarta denotada por E4, possui apenas três 
colunas, uma para armazenar os valores do atributo chave da entidade E1, outra 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 78 
 
para armazenar os valores do atributo chave da E2, e uma última para 
armazenar os valores do atributo chave da E3. 
 
Por exemplo: 
 
 
 
que corresponde ao esquema relacional 
 
PACIENTE (CodPaciente, NomePaciente) 
PK (CodPaciente) 
 
MEDICAMENTO (CodMedicamento, NomeMedicamento)PK (CodMedicamento) 
 
MEDICO (CodMedico, NomeMedico) 
PK (CodMedico) 
 
CONSULTA (CodPaciente, CodMedico, CodMedicamento) 
FK (CodPaciente) REFERENTE PACIENTE (CodPaciente) 
FK (CodMedicamento) REFERENTE MEDICAMENTO (CodMedicamento) 
FK (CodMedico) REFERENTE MEDICO(CodMedico) 
 
5.16 Especialização e Generalização 
 
Dada um conjunto de entidade genérica (supertipo) E com atributos a1, a2, a3, 
…,an, que está relacionado com n-1 entidades especializadas (subtipo) E2, , E3; 
…, En com um determinado número de atributos. Para converter esse relaciona-
mento para o modelo relacional, necessitamos de uma tabela E1 com n colunas 
distintas para armazenar os valores dos n atributos do conjunto de entidade ge-
nérica. Para cada conjunto de entidade especializada, necessitamos de uma ta-
bela, com um número de linhas igual ao número de colunas dessa entidade es-
pecializada. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 79 
 
Por exemplo: 
 
 
 
 
que corresponde ao seguinte esquema relacional 
 
CONTA (NumConta, Saldo) 
PK (NumConta) 
 
PRAZO (NumConta, TaxaJuro) 
FK (NumConta) REFERENTE CONTA (NumConta) 
 
CORRENTE (NumConta, CartaoMulticaixa) 
FK (NumConta) REFERENTE CONTA (NumConta) 
 
 
Observação: este esquema pode ser utilizado para qualquer tipo de especiali-
zação (total, parcial, disjunta, sobreposta). 
 
 
5.17 Exercícios Resolvidos 
 
Exemplo1: O modelo de entidade e relacionamento: 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 80 
 
 
corresponde ao seguinte esquema relacional. 
 
EMPREGADO (NumBI, Proprio, Familia, DataNasc, Rua, Casa, bairro, Sexo, Salario, 
DataInicio, CodSup, CodDep) 
PK (NumBI) 
FK (CodSup) REFERENTE FUNCIONARIO (CodFunc) 
Fk (CodDep) REFERENTE DEPARTAMENTO (CodDep) 
 
DEPARTAMENTO(CodDep, NomDep, Rua, Porta, Andar,Predio) 
PK (CodDep) 
 
PROJETO(CodProj, Nome, Rua, Casa, Bairro, CodDep) 
PK (CodProj) 
FK (CodDep) REFERENTE DEPARTAMENTO(CodDep) 
 
CONTROLA (NumBI, CodProj, Horas) 
FK (NumBI) REFERENTE FUNCIONARIO (NumBI) 
FK (CodProj) REFERENTE PROJETO (CodProj) 
 
DEPENDENTE (NumBI, NomeDependente, sexo, DataNasc, Parentesco) 
PK (NumBI, NomeDependente) 
FK (NumBI) REFERENTE FUNCIONARIO (NumBI) 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 81 
 
 
5.18 Exercícios Propostos 
 
5.18.1- Dado o Diagrama de Entidade e Relacionamento 
 
 
 
Escreva o correspondente esquema relacional 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 82 
 
5.18.2- Dado o Diagrama de Entidade e Relacionamento 
 
 
 
 
escreva o correspondente esquema relacional 
 
 
 
 
 
 
 
 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 83 
 
5.19.3-Dado o Diagrama de entidade e relacionamento 
 
 
 
 
Escreva o correspondente esquema relacional 
 
 
 
 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 84 
 
5.19.4-Dado o Diagrama de entidade e relacionamento 
 
 
 
Escreva o correspondente esquema relacional 
 
5.20 Leituras Recomendadas 
 
Para aprofundar os assuntos abordados neste capítulo, recomendados que o 
leitor consulte os seguintes livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 9: Projecto de um banco de dados Relacional, por 
mapeamento ER e EER para Relacional, tradução da 6ª edição ameri-
cana, São Paulo, Pearson Addison Wesley, 2011. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 85 
 
 
 Heuser C. A.;- Projeto de Banco de Dados, 6ª Edição, Instituto de Infor-
mática da UFRGS, capítulo 2: Abordagem Entidade-Relacionamento e 
capitulo 3- Construindo Modelo ER, Porto Alegre, Bookman, 2009. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Tradução da 3ª edição americana, Capítulo 2- Introdução ao Pro-
jeto de Banco de Dados, McGraw-Hill, 2008. 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 86 
 
 
6 
Capítulo 
Normalização 
 
“O objectivo do projecto de uma base de dados relacional é gerar um conjunto de esquemas relacionais 
é gerar um conjunto de esquemas relacionais, que nos permita guardar informações sem as 
redundâncias desnecessária, apesar de nos permitir recuperar a informação facilmente.” 
 
- Korth & Silberschatz - 
 
6.1 Introdução 
 
Para que uma base de dados reflita de forma eficiente à realidade do mundo 
exterior, é necessário corrigir alguns erros que foram geradas nas fases do de-
senvolvimento do projecto conceitual e/ou do projecto lógico. Essas depurações 
devem ser feitas para que as operações de inserção, remoção, alteração, modi-
ficação e consulta possam ser realizadas de forma eficiente. 
 
O processo de normalização foi criado em 1972, por E.F. Codd, e caracteriza-se 
pela aplicação de uma série de testes a um esquema relacional para verificar se 
ele satisfaz a uma determinada formal normal. Inicialmente Codd propôs três 
formas normais: 1FN, 2FN e 3FN, que serão objecto de estudo nestas notas. 
Mais tarde, Boyce e Codd definiram uma 3FN mais forte, que é denotada na 
literatura da ciência de computação por FNBC. Essas formas baseiam-se na 
análise das dependências funcionais. As restantes formas normais, a 4FN e 5FN, 
baseiam-se na análise de dependências multivaloradas e dependências de jun-
ção que não se enquadram no escopo destas notas. 
 
6.2 Critérios de Qualidade 
 
Para aferirmos a qualidade de um modelo relacional, devemos considerar os se-
guintes pontos: 
 
Lógico ou conceptual: como é que os utilizadores interpretam o significado das 
tabelas e dos seus atributos. Do ponto de vista lógico, um bom modelo deve 
permitir que os utilizadores compreendam claramente o significado dos dados e 
que os possam manipular correctamente. 
 
Implementação: como é que as tuplas (linhas) das tabelas são armazenadas e 
manipulados fisicamente na Base de Dados. Do ponto de vista da implementa-
ção, um bom modelo deve garantir uma maior eficiência nas operações de 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 87 
 
acesso aos dados, minimizar o espaço necessário para guardar as tuplas das 
tabelas, e evitar a informação redundante e supérflua 
 
6.3 Regras para uma boa Base de Dados 
 
Regra 1: Não misture atributos de tipos de entidades diferentes no esquema de 
uma base relacional. 
 
Por exemplo, o esquema relacional 
 
EMPDEP (NumBI, NomeEmp, Endereco, DataNasc, NumeDep, NomDep) 
PK (NumBI) 
 
viola essa regra por misturar atributos de entidades diferentes. A solução 
consiste em criar duas tabelas. Uma para os atributos dos empregados, outra 
para os atributos dos departamentos, e liga-las através da chave primária e da 
chave estrangeira. 
 
EMPREGADO (NUmBI, NomeEmp, Endereço, DataNasc) 
PK (NumBI) 
 
DEPARTAMENTO (NumDep, NomeDep, NumBI) 
PK (NumDep) 
FK (NumBI) REFERENTE EMPREGADO(NumBI) 
 
Regra 2: os esquemas de bases de dados relacionais devem ser projectados de 
forma a evitar as anomaliasnas operações de inserção, exclusão ou modifica-
ção. 
 
Por exemplo: no esquema relacional EMPDEP, que mostramos na regra ante-
rior, apresenta as seguintes anomalias: 
 
Inserção: não se pode inserir um novo departamento, a não ser que se insira um 
empregado que trabalha nesse departamento. 
 
Inserção: ao inserir um empregado é necessário garantir que os valores dos atri-
butos NomeDep e GerenteBI estejam em conformidade com os restantes em-
pregados desse departamento. 
 
Remoção: se removermos um departamento, teremos de remover todas as tu-
plas que contêm os empregados desse departamento. 
 
Alteração: se alterarmos o nome de um departamento, teremos de alterar o nome 
desse departamento para todas as tuplas dos empregados que nele trabalham. 
 
Observação: Não é uma boa práctica de desenho de Bases de Dados, mistu-
rar atributos que pertencem a diferentes entidades do mundo real, na mesma 
tabela. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 88 
 
Regra 3: num esquema relacional, evitar colocar atributos que podem ter valores 
nulos (NULL) numa grande parte das tuplas de uma tabela. 
 
Por exemplo, se apenas 5% dos empregados de um departamento tiverem um 
gabinete pessoal, não faz sentido incluir um atributo na tabela EMPREGADO 
para armazenar esses gabinetes. A solução correcta seria criar uma nova tabela, 
com a chave primária da tabela EMPREGADO e o atributo número do gabinete. 
 
GABINETE (NumBI, NumGabinete) 
FK (NumBI) REFERENTE EMPREGADO(NumBI) 
 
Regra 4: evitar relacionamentos entre trabelas que não sejam feitas pela chave 
primária e a chave estrangeira. 
 
6.4 Dependências Funcionais 
 
O processo de normalização para a primeira, a segunda, a terceira forma normal, 
e para a forma normal de Boyce-Codd, baseiam-se nos conceitos de 
dependência funcional entre os atributos de uma tabela. 
 
A dependência funcional é um dos conceitos mais importantes na teoria do 
projecto de esquemas de bases de dados relacionais, porque é um método 
formal que analisa a qualidade das tabelas que uma base de dados possui. 
 
Definição: Dada uma tabela R, e dois sub-conjuntos X e Y não vazios de atribu-
tos de R, dizemos que Y depende funcionalmente de X, ou que, X determina Y, 
se: 
X → Y ≡ ∀r1,r2 ∈ R, r1[X] = r2[X] ⟹ r1[Y] = r2[Y] 
 
Por exemplo, dado o esquema relacional. 
 
FUNCIONARIO (NumBI, Nome, Avaliação, SalarioHora, HorasTrabalhadas) 
PK(NumBI) 
 
e seja 
 
NBI Nome Avaliação SalarioHora Horasrabalhadas 
00123LA01 Manuel Correia 8 1500,00 8 
00154MA99 Célia Cruz 6 1000,00 7 
00751LA04 Margarida Soares 5 800,00 10 
00425LU01 Katia dos Santos 8 1500,00 6 
00976MA05 Steve Dias 4 500,00 6 
00412KK01 Luisa António 7 1200,00 8 
00723MO00 Quissua Tamo 3 200,00 5 
 
Uma instância de dados associada a esse esquema relacional. 
 
Por uma simples inspecção aos dados, facilmente se observa que o salário hora 
é determinado pela avaliação do trabalhador. Queremos com isso dizer, que tra-
balhadores que têm a mesma avaliação têm o mesmo salário hora. Por exemplo, 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 89 
 
os trabalhadores Manuel Correia e Katia dos Santos têm uma avaliação de 8 
pontos, logo têm uma salário hora de 1500,00 Kwanzas. Isso nos permite con-
cluir que o atributo salarioHora é dependente funcional do atributo Avaliação, e 
denotamos esse facto por: 
 
 Avaliação → SalarioHora 
 
Definição: Dada uma tabela R, e seja K uma chave primária, então os restantes 
atributos de R são funcionalmente dependentes de K, porque nunca teremos 
duas tuplas distintas com r1[K] = r2[K] 
 
Definição: Dada uma tabela R. Dizemos que temos uma Dependência Funcional 
Completa, se essa tabela possuir uma chave primária com mais de um atributo, 
e os restantes atributos têm de ser identificados pela totalidade da chave e não 
apenas por uma parte dela. 
 
6.5 Processo de Normalização 
 
O processo de normalização analisa os esquemas relacionais com base nas de-
pendências funcionais e nas chaves primárias, com o objectivo de minimizar por 
um lado as redundâncias, e por outro, as anomalias nas operações de inserção, 
exclusão e modificação. 
 
6.5.1 Primeira Forma Normal 1FN 
 
Definição: um esquema relacional está na primeira forma normal, quando todos 
os seus atributos forem atômicos, em outros termos, um esquema relacional está 
na 1FN se não possui atributos multivalorados nem atributos compostos. 
 
Vamos mostrar através de um exemplo, como se realiza a conversão de um es-
quema relacional para a 1FN. Dado o esquema relacional: 
 
FATURA (NumFat, TFatura, NIF, Nomcliente, Endereco, {Telefone}) 
PK (NumFat) 
 
Para converter este esquema relacional para a 1FN, temos de eliminar os atri-
butos multivalorados, e proceder a decomposição dos atributos compostos. Para 
decompor os atributos compostos basta: 
 
FACTURA (NumFat, TFatura, NIF, NomCliente, Rua, Casa, Bairro, Cidade, {Te-
lefone}) 
PK (NumFat) 
 
Para eliminar os atributos multivalorados, temos de fragmentar a tabela FAC-
TURA em duas. Uma que contêm os atributos da factura e outra que contêm os 
atributos dos números dos telefones dos clientes. Essas tabelas estão ligadas 
pelo número de contribuinte (NIF). 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 90 
 
FACTURA (NumFat, TFatura, NIF, NomCliente, Rua, Casa, Bairro, Cidade, NIF) 
PK (NumFat) 
FK (NIF) REFERENTE TELEFONE (NIF) 
 
TELEFONE (NIF, NumTelefone) 
PK (NIF) 
 
Observação: durante o processo de normalização para a Primeira Forma Nor-
mal, as tabelas são normalmente fragmentadas em várias tabelas. 
 
6.5.2 Segunda Forma Normal 2FN 
 
Definição: um esquema relacional está na segunda forma normal, quando está 
na 1FN, e todos os seus atributos não chave dependem funcionalmente da tota-
lidade da chave primária. 
 
Com essa definição queremos dizer que para verificar se um esquema relacional 
está na 2FN, basta verificar se ele não possui atributos compostos, atributos 
multivalorados, e para além disso, não temos nenhum atributo não chave que 
depende funcionalmente de uma parte da chave primária. 
 
Logo, o teste de verificação da 2FN só se aplica a esquemas relacionais que 
possuem uma chave primária com mais do que um atributo (superchave). 
 
A conversão desse esquema relacional para a 2FN consiste em eliminar os atri-
butos compostos, eliminar os atributos multivalorados e eliminar os atributos que 
têm uma dependência funcional com uma parte da chave primária; 
 
Vamos clarificar este conceito com um exemplo. Dado o esquema relacional. 
 
 
FACTURA (NumFat, TFatura, NIF, NomCliente, Rua, Casa, Bairro, Cidade, NIF) 
PK (NumFat) 
FK (NIF) REFERENTE TELEFONE (NIF) 
 
TELEFONE (NIF, NumTelefone) 
PK (NIF) 
 
ITENSFAT (NumFat, CodProd, NomProd, Qtd, Preço, imposto, total) 
PK ( NumFat, CodProd) 
FK (NumFat) REFERENTE FACTURA(NumFat) 
 
Como as tabelas FATURA e TELEFONE não têm atributos multivalorados, nem 
atributos compostos, e não possuem uma superchave, já se encontram na 2FN. 
A nossa análise deve restringir-se a tabela ITENSFAT. 
 
A tabela ITENSFAT não possui atributos compostos nem atributos multivalora-
dos, logo encontra-se na 1FN. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 91 
 
 
Mas o atributo NomProd varia em função do atributo CodProd. Queremos com 
isso dizer, que se tivermos duas linhas (tuplas) com o mesmo código do produto 
nessas linhas teremos o mesmo nome do produto. Logo, o atributo NomProd 
depende funcionalmente de uma parte da chave primária. Isso nos permite con-cluir que essa tabela não satisfaz a definição de dependência funcional total, e 
como consequência, não está na 2FN. 
 
Para converter essa tabela para a 2FN teremos de fragmenta-la em duas. Uma 
que contêm os atributos referentes a tabela ITENSFAT e outra que contêm os 
atributos referente a tabela PRODUTO. 
 
FACTURA (NumFat, TFatura, NIF, NomCliente, Rua, Casa, Bairro, Cidade, NIF) 
PK (NumFat) 
FK (NIF) REFERENTE TELEFONE (NIF) 
 
TELEFONE (NIF, NumTelefone) 
PK (NIF) 
 
PRODUTO (CodPro, NomPro, …..) 
PK (CodPro) 
 
ITENSFAT ( NumFat, CodProd, Qtd, Preço, imposto, total) 
PK ( NumFat, CodProd) 
FK (NumFat) REFERENTE FACTURA(NumFat) 
 
6.5.3 Terceira Forma Normal 3FN 
 
Definição: um esquema relacional está na terceira forma normal, quando está 
na 2FN, nenhum atributo não-chave depende por transitividade da chave primá-
ria 
 
 
Antes de examinarmos o processo de normalização para a 3FN, vamos estudar 
as propriedades. 
 
Regras de inferência de Armstrong (1974): 
Regra Reflexiva: Se X ⊇ Y então X → Y (ou X → X). 
Regra Aditiva: Se X → Y então XZ → YZ (ou se X → Y então XZ → Y). 
Regra Transitiva: Se X → Y e Y → Z então X → Z. 
 
Agora vamos analisar a situação do esquema relacional que estamos a imple-
mentar. 
 
Na tabela FATURA é possível obter a partir dos valores do número da factura os 
valores dos números dos contribuintes (NIF), e a partir dos valores dos números 
dos contribuintes (NIF) podemos obter os valores dos nomes dos clientes e seus 
endereços. Então pela 3ª regra de Armstrong, podemos obter a partir dos valores 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 92 
 
das facturas os valores dos nomes dos clientes e seus endereços. Essa regra 
nos permite concluir que tabela FATURA possui uma dependência transitiva, e 
não está na 3FN. 
 
Para convertê-la para a 3FN temos de fragmenta-la em duas tabelas. Uma com 
os atributos da tabela FACTURA e outra com os atributos da tabela CLIENTE. 
Essas tabelas devem ser ligadas pelo número de contribuinte(NIF). Mas ao criar 
a tabela CLIENTE vamos associa-la a tabela TELEFONE através do número de 
contribuinte, de tal forma que um cliente possa ter mais do que um telefone. 
 
FACTURA (NumFat, TFatura, NIF) 
PK (NumFat) 
FK (NIF) REFENTE CLIENTE(NIF) 
 
CLIENTE (NIF, NomCliente, Rua, Casa, Bairro, Cidade) 
PK (NIF) 
 
TELEFONE (NIF, NumTelefone) 
FK (NIF) REFENTE CLIENTE(NIF) 
 
PRODUTO (CodPro, NomPro, …..) 
PK (CodPro) 
 
ITENSFAT (NumFat, CodProd, Qtd, Preço, imposto, total) 
PK ( NumFat, CodProd) 
FK (NumFat) REFERENTE FACTURA(NumFat) 
 
Agora vamos analisar a tabela ITENSFAT. Nesta tabela, o atributo total é calcu-
lado com base na expressão: 
 
 Total = Preço * Quantidade - (Preço * Quantidade) * Imposto; 
 
Logo, estamos em presença de um atributo que depende de outros atributos da 
mesma tabela que não são atributos chave. Logo essa tabela tem uma depen-
dência transitiva e não está na 3FN. Para converter para a 3FN temos de eliminar 
esses atributos, obtendo o esquema relacional. 
 
FACTURA (NumFat, TFatura, NIF) 
PK (NumFat) 
FK (NIF) REFENTE CLIENTE(NIF) 
 
CLIENTE (NIF, NomCliente, Rua, Casa, Bairro, Cidade) 
PK (NIF) 
 
TELEFONE (NIF, NumTelefone) 
FK (NIF) REFERENTE CLIENTE(NIF) 
 
PRODUTO (CodPro, NomPro, …..) 
PK (CodPro) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 93 
 
 
ITENSFAT ( NumFat, CodProd, Qtd, Preço, imposto) 
PK (NumFat, CodProd) 
FK (NumFat) REFERENTE FACTURA(NumFat) 
 
6.6 Exercícios Propostos 
 
6.6.1- Dado um esquema relacional de um plano de voo de uma companhia de 
aviação. Normalize esse esquema. 
 
PLANOVOO (CodAviao, Modelo, Companhia, Datapartida, Aeroportopartida, 
dataChegada, AeroportoChegada, AeroportoAlternante, Duracao, {Tripula-
cao (CodTripulante, Nome, {Telefone}, cargo, Endereco (Rua, Casa, Bairro, Ci-
dade)}) 
 
6.6.2- Dado um esquema relacional de um Departamento Académica de uma 
Universidade. Normalize esse esquema. 
 
ALUNO (CodAluno, CodDepto, NomeDepto, NomeAluno, SiglaDepto, CodOri-
entador, NomeOrientador, {FoneOrientador}, CodCurso, NomeCurso, data-
Matricula, GrauDoCurso, NomeGrauCurso) 
 
6.6.3- Dado um esquema relacional para uma firma do sector Comercial, que 
possui alguns vendedores. Normalize esse esquema. 
 
VENDEDOR (CodVendedor, NomeVendedor, SexoVendedor, {Cliente (Nome 
Cliente, {Tefefone}, endereço (Rua, Casa, Bairro, Cidade)}) 
 
6.6.4- Dado um esquema relacional de uma empresa de gestão de projectos. 
Normalize essa tabela. 
 
PROJECTO (NumProj, NomeProj, TipoProj, LocalProj (rua, casa, bairro, 
cidade), {Empregados ( CodEmp, NomeEmp, Funcao, salarioBase, Subsídio, 
Horasextras, desconto, salarioliquido)}, {Supervidor (CodSupervisor, 
NomeSupervisor)}) 
 
6.6.5- Dado um esquema relacional de uma matricula de um estudante. 
Normalize esse esquema. 
 
MATRICULA (CodAluno, CodTurma, CodDisciplina, CargaHoraria, Semestre, 
Ano, NomeDisciplina, NomeAluno, NomeTurma, TipoDisciplina, DataNasc, 
LocalNasc, Numsala, NotaFrequencia, NotaExame, DataFrequencia, 
dataExame, Numfaltas, Capacidade, Media) 
 
6.7 Leituras Recomendadas 
 
Para aprofundar os temas tratados neste capítulo, recomendados que o leitor 
consulte um dos seguintes livros: 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 94 
 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 15- Fundamentos de dependências funcionais e 
normalização para bancos de dados relacionais, Tradução da 6ª edição 
americana, São Paulo, Pearson Addison Wesley, 2011 
 
 Heuser C. A.;- Projeto de Banco de Dados, Capítulo 6- Engenharia re-
versa de arquivos e normalização, 6ª Edição, Instituto de Informática da 
UFRGS, Porto Alegre, Bookman, 2009. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Capítulo 19- Refinamento, Sintonização e formas normais, Tradu-
ção da 3ª edição americana, McGraw-Hill, 2008. 
 
 Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, Capítulo 5- Normalização das Tabelas do Banco de Da-
dos, tradução da 8ª edição americana Edição, Cengage Learning, 2010. 
 
 
 
Introdução as Técnicas de Desenvolvimento de Algoritmos 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 95 
 
 
7 
Capítulo 
Álgebra e Calculo Relacional 
 
“A redundância é a raiz de todos os males que estão associados aos esquemas das bases de dados 
relacionais” 
 
- Ramakishnan & Gehrke - 
 
7.1 Introdução 
 
 
7.3 Álgebra Relacional 
 
 
7.3 Calculo Relacional 
 
 
 
7.4 Leituras Recomendadas 
 
Para aprofundar os temas tratados neste capítulo, recomendados que o leitor 
consulte um dos seguintes livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Capítulo 6: Álgebra e Calculo Relacional, tradução da 6ª 
edição americana, São Paulo, Pearson Addison Wesley, 2011. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Capítulo 4- Álgebra e Calculo Relacional, Tradução da 3ª edição 
americana, São Paulo, McGraw-Hill, 2008. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 96 
 
 
8 
Capítulo 
SQL- Criação de Tabelas 
 
“A linguagem SQL pode ser considerada como um dos principais motivos para o sucesso das bases de 
dados comerciais. Como ela tornou-se um padrão para esse tipo de bases de dados, os programadores 
não precisam de preocupar-se com a migração das suas aplicaçõespara outros sistemas de bases de 
dados.” 
 
- Elmasi & Navathe - 
 
8.1 Introdução 
 
A linguagem SQL (Structured Query Language) foi desenvolvida com base no 
trabalho de E. F. Codd[2]. A sua primeira versão, denominada por SEQUEL 
(Structured English Query Language), foi desenvolvida pela IBM no início da dé-
cada de 70 para um projecto de pesquisa denominado por System-R. 
 
Em 1979, a empresa Relational Software Inc, hoje Oracle Coorporation, lançou 
a primeira versão comercial dessa linguagem, com o nome SQL (Structured 
Query Language), que se estabeleceu como a linguagem padrão utilizada para 
as bases de dados relacionais. 
 
Em 1986, a ANSI (American National Standards Institute) e a ISO (International 
Organization for Standardization) publicaram o primeiro padrão dessa lingua-
gem, e posteriormente foram lançadas algumas versões, para aperfeiçoar esse 
padrão. 
 
SQL-86; (ANSI) 
SQL-89: publicação de um padrão estendido para linguagem em 1989; 
SQL-92; 
SQL-99; 
SQL-2003 (XML); 
SQL-2008; 
SQL-2011 ISO/IEC 9075:2011 (16/12/2011). 
 
Apesar da linguagem SQL ser a linguagem mais comum entre as várias lingua-
gens de consulta, ela não deve ser vista com uma simples linguagem de con-
sulta, mas como uma linguagem de manipulação de Bases de Dados. 
 
Dentre das várias versões publicadas, as mais difundidas são a SQL ANSI de 
1986, SQL-92 e o SQL99 que incorpora mais recursos como triggers, procedu-
res, objetos e recursividade. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 97 
 
Embora cada fabricante possui o seu SGBD (Sistema Gerador de Base de Da-
dos) que contém uma linguagem nativa SQL, a verdade é que essas linguagens 
mantêm o mesmo padrão. Isso permite a portabilidade das aplicações, ou seja, 
a migração de uma aplicação que roda num SGBD para outro, efectuando pe-
quenos ajustes. 
 
Observação: Os Sistemas Geradores de Bases de Dados Relacionais, geral-
mente implementam a linguagem ANSI SQL e partes da SQL-92 e SQL-99. 
 
 
8.2 Linguagem de Definição de Dados (DDL) 
 
Na linguagem SQL, a criação de uma Base de Dados é feita pelo subconjunto 
DDL- Data Defini Language, que possui os seguintes comandos: CREATE, 
DROP, ALTER e TRUNCATE. 
 
8.2.1 Criação de uma Base de Dados 
 
Embora a maior parte dos Sistemas de Gestão de Bases de Dados Relacionais 
(SGBDR), disponibilizem utilitários que permitem criar as Bases de Dados, como 
por exemplo o PgAdmin no Postgres, é possível criar uma Base de Dados, a 
partir de um comando muito simples, cuja sintaxe resumida descrevemos a 
seguir: 
 
CREATE DATABASE nome_da_Base_Dados 
 
Embora os ambientes de administração da Base de Dados serem muito 
amigáveis, existem algumas situações que é necessário efectuar a criação de 
uma Base de Dados, a partir de um arquivo de comandos em SQL, que na 
literatura da Ciência de Computação dá-se o nome e Script. 
 
8.2.2 Eliminação de uma Base de Dados 
 
Para removermos uma Base de Dados devemos utilizar o comando DROP 
DATABASE, que elimina todas as tabelas, e as estruturas associadas a essa 
Base de Dados, cuja sintaxe resumida descrevemos em seguida. 
 
DROP DATABASE nome_da_Base_Dados 
 
É importante salientar que nem todos os Sistemas de Gestão de Bases de Dados 
disponibilizam este comando. Contudo, o leitor deverá prestar a atenção que se 
executar este comando, a Base de Dados será eliminada de forma permanente. 
 
8.2.3 Criação de uma Tabela 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 98 
 
Para criarmos uma tabela numa Base de Dados, devemos utilizar o comando 
CREATE TABLE, cuja sintaxe resumida descrevemos em seguida. 
 
CREATE TABLE nome_da_tabela 
( 
 nome_coluna1 tipo1, 
 nome_coluna2 tipo2, 
 …. 
 nome_colunan tipon, 
); 
 
onde 
 tipoi é o tipo é dados que a coluna ou o atributo irá armazenar. 
 
Em qualquer linguagem de programação os nomes criados pelos programadores 
são chamados de identificadores. 
 
Definição: na linguagem SQL, os identificadores estão sujeitos as seguintes 
regras: 
1º- Começam por uma letra; 
2º- Os restantes caracteres são letras ou números; 
3º- O carácter de separação (underscore) é permitido; 
4º- as letras que compõem um identificador não possuem acentos; 
5º- Um identificador não pode ter mais do que 30 caracteres; 
6º- Um identificador não pode ser uma palavra reservada. 
 
Definição: também podemos definir uma tabela como um conjunto de registros, 
em que cada registro é formado por um conjunto de campos. 
 
Na linguagem SQL, os dados podem ser classificados como: numéricos, 
temporais, lógicos e Texto. 
 
Valores Numéricos 
TINYINT 
SMALLINT 
INT 
 
BIGINT 
 
 
FLOAT 
 
DOUBLE 
 
DECIMAL(N, D) 
1 byte (Um número inteiro de -128 até 127) 
2 bytes (Um número inteiro de -32.768 até -32.767) 
4 bytes (Um número inteiro de -2.147.483.648 até -
2.147.483.647) 
8 bytes (Um número inteiro de -9.223372037×10¹⁸ até -
9.223372036×10¹⁸) 
4 bytes (Um número de ponto decimal de 1.2E-38 até 
3.4E+38 com 6 casas decimais) 
8 bytes (Um número de ponto decimal de 1.2E-38 até 
3.4E+38 com 15 casas decimais) 
N dígitos com D dígitos depois do ponto decimal 
 
Valores Temporais 
DATE 
TIME 
formato ‘AAAA-MM-DD’ 
formato ‘HH:MM: SS’ 8 bytes 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 99 
 
DATETIME 
TIMESTAMP 
formato ‘AAAA-MM-DD HH:MM: SS’ 8 bytes 
formato AAAAMMDDHHMMSS 
 
Valores Lógicos 
BOOLEAN TRUE e FALSE 
 
Sequencia de Texto 
CHAR(N) 
VARCHAR(N) 
TEXT 
string de comprimento fixo de N caracteres 
string de comprimento variável até N caracteres 
string de comprimento variável até 65 Kbytes 
 
Observação: nos SGBD temos o tipo de dados VARCHAR (N) para uma cadeia 
de caracteres de comprimento variável limitada. Mas no PostGreSQL não existe 
uma diferença de desempenho entre este tipo de dados e o tipo TEXT. Por esse 
facto, aconselha-se a utilizar o tipo de dados TEXT. 
 
Observação: nestas notas de aulas iremos utilizar a notação Camel Case, que 
possui a seguinte caracterização: 
1º- O primeiro carácter de cada palavra deve ser uma letra maiúscula os 
restantes são letras ou números em minúsculo; 
2º- Se o identificador for constituído por duas ou mais palavras, deve-se efectuar 
a junção das palavras e aplica-se a 1ª regra. 
 
Observação: na linguagem SQL as palavras reservadas são escritas com letras 
maiúsculas. 
 
Vamos consolidar estes conceitos com um exemplo muito simples: Dada a tabela 
de ESTUDANTE 
 
Coluna Tipo de dado tamanho 
CodAluno 
Nome 
Sobrenome 
Número do BI 
Sexo 
Data Nascimento 
Numérico inteiro 
Caracter 
Caracter 
Caracter 
Caracter 
data 
10 
8 
8 
12 
1 
padrão 
 
 
 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 Nome TEXT, 
 Sobrenome TEXT, 
 NumBI INT, 
 Endereco TEXT, 
 Sexo CHAR, 
 DatNasc DATE 
 ); 
 
Depois de criar uma tabela, o SGBDR emite a mensagem table create, se a 
tabela foi criada com sucesso, no caso contrário será apresentada uma 
mensagem de erro e a tabela não será criada. 
 
8.2.4 Mostrar a estrutura de uma Tabela 
 
Para mostrar na tela a estrutura de uma tabela, devemos utilizar o comando 
DESCRIBE, que possui a seguinte sintaxe: 
 
DESCRIBE nome_da_tabela 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 100 
 
 
Por exemplo: 
 
 DESCRIBE ESTUDANTE 
 
Veremos na tela a seguinte informação: 
 
Name Null ? Type 
-------------------------------------------------------------------------------------------------CodAluno INT 
Nome TEXT 
Sobrenome TEXT 
NumBI INT 
Endereco TEXT 
Sexo CHAR 
DatNasc DATE 
 
Como se pode observar todas as colunas da tabela são do tipo NULL, isso quer 
dizer, que quando o utilizador estiver a carregar dados nessa tabela, se 
porventura esquecer-se de digitar algum valor, o sistema configura 
automaticamente esse valor como NULL. 
 
8.2.5 Restrições 
 
As restrições são instruções que impõem algumas regras à manutenção dos 
dados. Essas regras determinam os valores que uma ou mais colunas podem 
receber. 
 
As restrições são chamadas de constraints e ficam armazenadas na Base de 
Dados. 
 
8.2.5.1 Valores nulos e não nulos 
 
Se na criação de uma coluna não for definida qualquer restrição (constraints) a 
indicar que essa coluna não pode receber valores nulos, então essa coluna irá 
receber por defeito o valor NULL. 
 
Para definirmos que uma coluna não pode receber valores nulos, devemos 
utilizar com sufixo do tipo de dados dessa coluna a restrição (constraints) NOT 
NULL. 
 
Por exemplo, para a tabela de ESTUDANTE devemos definir a restrição NOT 
NULL para os campos: 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT NOT NULL, 
 Nome TEXT NOT NULL, 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 101 
 
 Sobrenome TEXT NOT NULL, 
 NumBI INT NOT NULL, 
 Endereco TEXT, 
 Sexo CHAR NOT NULL, 
 DatNasc DATE NOT NULL 
 ); 
 
8.2.5.2 Chave Primária 
 
Toda a coluna que contêm a chave primária não deve conter a restrição 
(constraints) NOT NULL. A restrição PRIMARY KEY garante que essa coluna 
não pode receber valores nulos, e como boas prácticas de programação, ela 
deverá ser declarada na ultima linha da tabela. 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 Nome TEXT (8) NOT NULL, 
 Sobrenome TEXT(8) NOT NULL, 
 NumBI INT NOT NULL, 
 Endereco TEXT(50), 
 Sexo CHAR NOT NULL, 
 DatNasc DATE NOT NULL, 
 PRIMARY KEY (codAluno) 
 ); 
 
Se a chave primária possui mais do que um campo (atributo), ela deve ser 
declarada com a seguinte notação: 
 
 CREATE TABLE MUNICIPIO 
( 
 CodProvincia TINYINT, 
 CodMunicipio TINYINT, 
 PRIMARY KEY (codProvincia, CodMunicipio) 
 ); 
 
8.2.5.3 Valores limitados 
 
Para armazenar um determinado um conjunto de valores numa coluna, devemos 
utilizar a restrição (constraints) CHECK. Mas essa restrição, exige que seja 
omitida a declaração NOT NULL. 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 Nome TEXT NOT NULL, 
 Sobrenome TEXT NOT NULL, 
 NumBI INT NOT NULL, 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 102 
 
 Endereco TEXT, 
 Sexo CHAR CHECK ( sexo = ‘F’ OR sexo = ‘M’), 
 DatNasc DATE CHECK (datNac > 0), 
 PRIMARY KEY (codAluno) 
 ); 
 
8.2.5.4 Valores Únicos 
 
Para garantir que um determinado valor de uma coluna não possa repetir-se, ou 
seja, que ele ocorra uma e apenas uma vez, devemos utilizar a restrição 
(constraints) UNIQUE. Mas essa restrição só deve ser utilizada para os campos 
que indicam a presença de uma chave candidata, e para o efeito, a restrição 
NOT NULL deve ser omitida. 
 
CREATE TABLE Estudante 
( 
 CodAluno INT, 
 Nome TEXT NOT NULL, 
 Sobrenome TEXT NOT NULL, 
 NumBI INT UNIQUE, 
 Endereco TEXT, 
 Sexo CHAR CHECK ( sexo = ‘F’ OR sexo = ‘M’), 
 DatNasc DATE CHECK (DatNasc > 0) 
 PRIMARY KEY (codAluno) 
 ); 
 
Observação: todas as colunas que contém a constraints UNIQUE, são fortes 
candidatos de serem utilizados como chave de busca. 
 
8.2.5.5 Chave Estrangeira 
 
Acreditamos que o leitor já tenha conhecimento que as tabelas de uma base de 
dados ligam-se umas as outras através das chaves estrangeiras. 
 
A integridade referencial é utilizada para garantir a consistência de dados entre 
tabelas. Esta restrição permite a validação das chaves estrangeiras. Queremos 
com isso dizer que com base nessa restrição, não é permitido inserir valores 
numa chave estrangeira que não estejam definidos na tabela que contém a 
correspondente chave primária. Na linguagem SQL essa propriedade é 
garantida pela (constriant) REFERENCES 
 
Como boa práctica de programação, devemos fazer referencia a chave 
estrangeira, utilizando para o efeito a restrição (constraints) FOREIGN KEY, que 
deverá ser colocada na última linha da tabela. 
 
Por exemplo, dado o esquema relacional 
 
Curso (CodCurso, NomeCurso) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 103 
 
PK (CodCurso) 
 
Estudante (codAluno, CodCurso, Nome, Sobrenome, NumBI, Endereco, Sexo, 
DatNasc) 
PK (CodAluno) 
FK (CodCurso) REFERENTE Curso (CodCurso) 
 
que é criado pelo seguinte script 
 
CREATE TABLE CURSO 
 ( 
 CodCurso CHAR (10), 
 NomeCurso TEXT NOT NULL, 
 PRIMARY KEY (codCurso) 
 ); 
 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 CodCurso INT, 
 Nome TEXT NOT NULL, 
 Sobrenome TEXT NOT NULL, 
 NumBI INT UNIQUE, 
 Endereco TEXT, 
 Sexo CHAR CHECK (sexo = ‘F’ OR sexo = ‘M’), 
 DatNasc DATE CHECK (DATNASC > 0), 
 PRIMARY KEY (codAluno), 
 FOREIGN KEY (CodCurso) REFERENCES CURSO(CodCurso) 
 ); 
 
No entanto, muitas vezes temos a necessidade de alterar ou de remover um 
valor de uma chave primária de uma tabela, e queremos que esse valor seja 
alterado ou removido em todas as tuplas das correspondentes chaves 
estrangeiras. 
 
Para realizar essa operação, devemos acrescentar à restrição (constraints) 
REFERENCES, à restrição ON UPDATE CASCADE, para o caso da alteração, 
ou a restrição ON DELETE CASCADE, para o caso da remoção, como 
mostrados a seguir: 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 CodCurso INT, 
 Nome TEXT NOT NULL, 
 Sobrenome TEXT NOT NULL, 
 NumBI INT UNIQUE, 
 Endereco TEXT, 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 104 
 
 Cexo CHAR CHECK ( sexo = ‘F’ OR sexo = ‘M’), 
 DatNasc DATE CHECK (DatNasc > 0), 
 PRIMARY KEY (codAluno, CodCurso), 
 FOREIGN KEY (CodCurso) REFERENCES CURSO(CodCurso) 
 ON DELETE CASCADE ON UPDATE CASCADE 
 ); 
 
Se pretendermos visualizar a estrutura desta tabela, basta digitar o comando: 
 
 DESCRIBE ESTUDANTE 
 
que veremos a tela a seguinte informação: 
 
NameNull ? Type 
------------------------------------------------------------------------------------------------- 
CodAluno NOT NULL INT 
CodCurso NOT NULL INT 
Nome NOT NULL TEXT 
Sobrenome NOT NULL TEXT 
NumBI NOT NULL INT 
Endereco TEXT 
Sexo NOT NULL CHAR 
DatNasc NOT NULL DATE 
 
Como se pode observar as colunas CodAluno, CodCurso, Nome, Sobrenome, 
NumBI, Sexo e DatNasc, são do tipo NOT NULL, isso quer dizer que, quando o 
utilizador estiver a carregar dados nessa tabela, ele é obrigado a inserir algum 
valor para essas colunas. 
 
8.2.5.6 Sinónimos de Restrições 
 
Para tornar o código mais fácil de ler e de compreender, a linguagem SQL, 
permite criar palavras sinónimos (Aliás) para fazer referencia as chaves 
primárias e secundárias. Essas palavras são utilizadas com a restrição 
CONTRAINT. 
 
CREATE TABLE ESTUDANTE 
( 
 CodAluno INT, 
 CodCurso INT, 
 Nome TEXT NOT NULL, 
 Sobrenome TEXT NOT NULL, 
 NumBI INT UNIQUE, 
 Endereco TEXT, 
 Sexo CHAR CHECK ( sexo = ‘F’ OR sexo = ‘M’), 
 DatNasc DATE CHECK (DATNASC > 0), 
 CONSTRAINT KeyP_Est PRIMARY KEY (codAluno, CodCurso), 
 CONSTRAINT Key_Cur FOREIGN KEY (CodCurso) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 105 
 
 REFERENCES CURSO(CodCurso) 
 ON DELETE CASCADE ON UPDATE CASCADE 
 ); 
 
8.2.5.7 Campos com Auto Incremento 
 
Os Sistemas de Gestão de Bases de Dados (SGBD), possuem um tipo especial 
de dados, cujo valor é do tipo numérico, e tem a propriedade de auto 
incrementar-se. Esse tipo de dados é muito utilizado para a chave primária. No 
Posgres esse tipo de dados é definido pela palavra reservada SERIAL. Por 
exemplo, na tabela de cursos, a chave primária deveria ser sido declarada com 
esse tipo de dados. 
 
CREATE TABLE CURSO 
 ( 
 CodCurso SERIAL, 
 NomeCurso TEXT NOT NULL, 
 PRIMARY KEY (codCurso) 
 ); 
 
8.2.5.8 Valores por Defeito 
 
Para garantir que o valor de uma coluna seja o mesmo para todas as linhas da 
tabela, e que esse valor a partida seja conhecido, devemos utilizar a constraints 
DEFAULT, seguida do valor que pretendemos utilizar. 
 
Por exemplo, suponhamos que na tabela de cursos temos uma coluna com o 
grau do curso (no mundo real isto não é possível), e que nessa instituição de 
ensino só se ministra cursos de mestrado, 
 
CREATE TABLE CURSO 
 ( 
 CodCurso SERIAL, 
 NomeCurso TEXT NOT NULL, 
 Grau CHAR(3) DEFAULT ‘Msc’, 
 PRIMARY KEY (codCurso) 
 ); 
 
8.2.6 Alteração de Colunas nas Tabelas 
 
Para incluir uma nova coluna numa tabela, alterar o nome de uma coluna, e a 
alterar o tipo de dados de uma coluna, devemos utilizar o comando ALTER 
TABLE, que possui a seguinte sintaxe: 
 
 ALTER TABLE NomeDaTabela ADD NomeDaColuna tipoDeDados 
 
 ALTER TABLE NomeDaTabela MODIFY NomeDaColuna tipoDeDados 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 106 
 
 
 ALTER TABLE NomeDaTabela DROP NomeDaColuna 
 
Por exemplo, para adicionar na tabela de estudantes uma coluna para 
armazenar o número do email, e suponhamos que o estudante só queira declarar 
o email da escola, devemos executar o comando: 
 
ALTER TABLE ESTUDANTE ADD Email TEXT (30) 
 
Mas se quisermos alterar a coluna nome da tabela Curso, de tal forma que, essa 
coluna não possa armazenar valores nulos, devemos executar o comando: 
 
 ALTER TABLE CURSO MODIFY Nome NOT NULL 
 
Observação: essa alteração só será bem-sucedida, se nenhuma ocorrência 
dessa coluna tiver o valor NULL 
 
8.2.7 Apagar uma Tabela 
 
Para apagar (deletar) uma tabela de uma Base de Dados, devemos utilizar o 
comando DROP TABLE que possui a seguinte sintaxe: 
 
 DROP TABLE NomeDaTabela 
 
Observação: depois de executar-se o comando DROP TABLE, toda a estrutura 
da tabela e os respectivos dados, serão apagados e não podem ser recuperados 
 
8.2.8 Apagar os Dados de uma Tabela 
 
Para apagar (deletar) todos os dados de uma tabela devemos utilizar o comando 
TRUNCATE TABLE que possui a seguinte sintaxe: 
 
TRUNCATE TABLE NomeDaTabela 
 
O TRUNCATE TABLE remove todos os dados de uma tabela, mas não destrói 
a tabela, ao passo que, o comando DROP TABLE remove todos os dados de 
uma tabela, mas destrói a tabela. 
 
8.3 Exercícos Propostos 
 
8.3.1- Dado o seguinte esquema de uma Base de Dados. Escreva em Script em 
SQL para criar as tabelas desse esquema 
 
ACTOR (CodActor, Nome, DatNasc) 
PK (CodActor) 
 
DIRECTOR (CodDirector, Nome, DatNac) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 107 
 
PK ( CodDirector) 
 
PRODUTOR (CodProdutor) 
PK (CodProdutor) 
 
FILME (CodFilme, Titulo, Ano, CodDirector) 
PK (CodFilme) 
FK (CodDirector) REFERENTE DIRECTOR (CodDirector) 
 
ACTUA ( CodActor, CodFilme, ano) 
FK (CodActor) REFERENTE ACTOR (CodActor) 
FK (CodFilme) REFERENTE FILME (CodFilme) 
 
PRODUZ (CodFilme, CodProdutor, valor) 
FK (CodFilme) REFERENTE FILME (CodFilme) 
FK (CodProdutor) REFERENTE PRODUTOR (CodProdutor) 
 
8.3.2- Dado o seguinte esquema relacional de uma Base de Dados. Escreva em 
Script em SQL para criar as tabelas desse esquema. 
 
TRIPULANTE (CodTripolante, Nome, Telefones, cargo) 
PK (CodTripo) 
 
TRIPULANTEVOO ( CodFolhaVoo, CodTripolante) 
PK (CodFolhaVoo, CodTripolante) 
FK (CodTripolante) REFERENCE TRIPULANTE (CodTripolante) 
 
VOO ( CodVoo, Destino, NumTripolantes, Duracao) 
PK (CodVoo) 
 
DATAVOO (CodVoo, DatPrev) 
PK (CodVoo, DatPrev) 
FK (CodVoo) REFERENTE VOO (CodVoo) 
 
8.3.3- Dado o seguinte esquema de uma Base de Dados. Escreva em Script em 
SQL para criar as tabelas desse esquema. 
 
FUNCIONARIO (CodFunc, Nome, SobreNome, DatNasc, Sexo, Salario, 
CodSupervisor, CodDepto) 
PK (CodFunc) 
FK (CodSupervisor) REFERENTE FUNCIONARIO (CodFunc) 
FK (CodDepto) REFERENTE DEPARTAMENTO (CodDepto) 
 
DEPARTAMENTO (CodDepto, Nome, CodGerente, DatFuncoes) 
PK (CodDepto) 
FK (CodGerente) REFRENTE FUNCIONARIO (CodFunc) 
 
LOCALIZACAO (CodDepto, Endereco) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 108 
 
FK (CodDepto) REFERENCE DEPARTAMENTO (CodDepto) 
 
PROJECTO (CodProj, CodDepto, Nome, Endereco) 
PK (CodProj) 
FK (CodDepto) REFERENTE DEPARTAMENTO (CodDepto) 
 
TRABALHA (CodFunc, CodProj, NumHoras) 
PK (CodFunc, CodProj) 
FK (CodFunc) REFERENTE FUNCIONARIO (CodFunc) 
FK (CodProj) REFERENTE PROJECTO (CodProj) 
 
DEPENDENTE (CodFunc, Nome, Sexo, DatNasc, Parentesco) 
PK (CodFunc, Nome) 
FK (CodFunc) REFERENTE FUNCIONARIO (CodFunc)8.3.4- Dado o seguinte esquema de uma Base de Dados. Escreva em Script em 
SQL para criar as tabelas desse esquema. 
 
DISCIPLINA (CodDis, Nome) 
PK (CodDis) 
 
CURSO (CodCur, Nome) 
PK (CodCur) 
 
PREDIO (CodPred, rua bairro, cidade) 
PK (CodPred) 
 
CURRICULUM ( CodCur, CodDis, TipoDisc) 
FK (CodCur) REFERENTE CURSO (CodCur) 
FK (CodDis) REFERENTE DISCIPLINA (CodDis) 
 
SALA (CodPred, CodSal, capacidade, andar) 
PK (CodPred, CodSal) 
FK (CodPred) REFERENTE PREDIO(CodPred) 
FK (CodSal) REFERENTE SALA (CodSal) 
 
8.3.5- Dado o seguinte esquema relacional de uma Base de Dados. Escreva um 
Script em SQL para criar as tabelas desse esquema 
 
AUTOMOVEL (Matricula, Marca, Ano, CodComissao, CodLoja) 
PK (Matricula) 
FK (Marca) REFERENTE MARCA (CodMarca) 
FK (CodComissao) REFERENTE COMISSAO (CodComissao) 
 
AUTOMOVEISOCORRENCIA (Matricula, Numero, Data, Hora, Tipo, Descricao) 
PK (Matricula, Numero) 
FK (Matricula) 
 
PROPRIETARIO (CodDono, Nome, Rua, Bairro, Cidade) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 109 
 
PK (CodDono) 
 
TELEFONEDONO (CodDono, NumTelefone) 
FK (CodDono) REFERENTE PROPRIETARIO (CodDono) 
 
EMAILDONO (CodDono, NumEmail) 
FK (CodDono) REFERENTE PROPRIETARIO (CodDono) 
 
LOJA (CodLoja, Nome, Rua, Bairro, Cidade) 
PK ( CodeLoja) 
 
TELEFONELOJA (CodLoja, NumTelefone) 
FK (CodLoja) REFERENTE PROPRIETARIO (CodLoja) 
 
EMAILLOJA (CodLoja, NumEmail) 
FK (CodLoja) REFERENTE PROPRIETARIO (CodLoja) 
 
COMISSAO (CodComissao, Descricao, valor) 
PK (CodComissao) 
 
8.4 Leituras Recomendadas 
 
Para aprofundar os temas abordados neste capítulo, recomendados que o leitor 
consulte os livros: 
 
 Luís D.;- SQL, Capítulo 12- Criação e Manutenção de Tabelas, 14ª Edi-
ção Actualizada, FCA, 2017 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Parte2: Modelo de Dados Relacional e SQL, Capítulo 4- 
SQL Básica, tradução da 6º edição americana São Paulo, Pearson Addi-
son Wesley, 2011. 
 
 Garcia-Molina, Ullman, Widom: Database Systems – The Complete Book, 
Part II Relational DataBase Programming, Chaper 6- The DataBase Lan-
guage SQL, Prentice-Hall, 2009. 
 
 Groff J. R., Wienberg P. N., Oppel A.;- The Complete Reference SQL, Part 
IV, DataBase Structure, 3th Edition, McGraw-Hill, 2010. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Capítulo 3- O Modelo Relacional, Tradução da 3ª edição ameri-
cana, São Paulo, McGraw-Hill, 2008. 
MAC0426 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 110 
 
 
9 
Capítulo 
SQL- Manipulação de Dados 
 
“a base da moderna tecnologia de bases de dados é, sem dúvida, o modelo relacional: essa é a base que 
faz da área uma ciência”. 
 
- Date - 
 
9.1 Introdução 
 
No capítulo anterior estudamos com bastante profundidade o módulo DDL da 
Linguagem SQL. 
 
Agora, vamos concentrar o nosso estudo no módulo DML dessa linguagem, e 
estudar de forma detalhada os comandos para inserir, alterar e remover os dados 
em uma tabela. 
 
9.2 Linguagem de Manipulação de Dados (DML) 
 
 
Na linguagem SQL, a manipulação de Dados é feita pelo subconjunto DML- Data 
Manipulation Language, que possui os seguintes comandos: INSERT, UPDATE 
e DELETE. 
 
 
9.3.1 Estudo de Caso 
 
Suponhamos que pretendemos criar uma Base de Dados para controlar as 
vendas de produtos de uma pequena papelaria. Essa Base de Dados deve 
controlar o cadastro dos clientes, a classificação dos produtos por família, o 
cadastro dos produtos, e o histórico das compras efectuadas pelos clientes. 
Também vamos supor que esse minimundo já foi descrito num modelo de dados, 
esse modelo de dados já foi convertido para o seguinte esquema relacional: 
 
CLIENTE (CodCli, Nome, Sobrenome, Sexo, DatNasc,Telefone) 
PK (CoCli) 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 111 
 
FAMILIA (CodFam, Descricao) 
PK (CodFam) 
 
PRODUTO (CodPro, Autor, Titulo, CodFam, PrCusto, PrVenda, QtdStock) 
PK (CodPro) 
FK (CodFam) REFERENTE FAMILIA (CodFam) 
 
HISTORICO (CodPro, CodCli, QtdVendida, DatVenda, PrCusto, PrVenda) 
FK(CodPro) REFERENTE PRODUTO (CodPro) 
FK (CodFam) REFERENTE FAMILIA(CodFam) 
 
Embora esse esquema relacional não está normalizado, ele serve para introduzir 
os conhecimentos que pretendemos abordar neste capítulo. Mas, para que 
possa visualizar as operações que vamos estudar, faça como exercício um Script 
para criar as tabelas da Base de dados. 
 
9.3.2 Inserção de Dados 
 
Para que a Base de Dados seja útil, é necessário carregar as suas tabelas com 
dados. Os dados são inseridos por linhas, uma linha de cada vez. Contudo é 
possível inserir mais do que uma linha, mas essa técnica foge ao escopo destas 
notas. 
 
Para inserir os dados numa uma nova linha, devemos utilizar o comando INSERT 
que possui a seguinte sintaxe: 
 
INSERT INTO NomeDaTabela VALUES (Valor1, Valor2 , …., Valorn); 
 
Por exemplo: Dado a tabela de Clientes 
 
Cocli Nome Sobrenome Sexo Data Nascimento Telefone 
1 Alberto Mogas M 2000-07-21 912303240 
2 Carlos Amaral M 1993-01-01 931414270 
3 Antónia Gurgel F 2002-05-31 921723425 
4 Stefano Catumbela M 1991-02-10 932721097 
5 Brigite Santos F 2002-05-31 933712934 
6 Sérgio Couto M 2000-07-01 933657143 
7 Eliane Caseiro F 2002-07-30 912717777 
8 Herlander Chalana M 1981-05-31 933924868 
9 Josemar da Silva M 1981-03-12 942712999 
 
Para inserir esses dados devemos executar os seguintes comandos: 
 
INSERT INTO CLIENTE 
 VALUES (1, ‘Alberto’,’Mogas’, ‘M’, ‘2000-07-21’,912300240); 
INSERT INTO CLIENTE 
 VALUES (2,’Carlos’,’Amaral’,’M’, ‘1993-01-01’,931414270); 
INSERT INTO CLIENTE 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 112 
 
 VALUES (3,’Antónia’,’Gurgel’, F’,’2002-05-31’, 921723425); 
 
Observe que os valores dos dados devem ser colocados na mesma ordem que 
as colunas da tabela foram definidas e separados por uma vírgula. 
 
Esta sintaxe apresenta como principal desvantagem o facto de ser necessário 
conhecer a ordem das colunas da tabela. Para evitar este problema podemos 
relacionar as colunas as suas variáveis, utilizando para o efeito, o comando IN-
SERT com a seguinte sintaxe: 
 
 
INSERT INTO NomeDaTabela (campo1, … , Campon) 
VALUES (valor1, … , valorn); 
 
Agora, vamos inserir mais alguns dados nessa tabela. 
 
INSERT INTO 
CLIENTE (CodCli, Nome, SobreNome, Sexo, DatNasc, Telefone) 
VALUES (4, ‘Stefano’, ‘Catumbela,’ M’, ‘1991-02-10’, 932721097); 
 
Muitos utilizadores consideram como uma boa práctica inserir os dados de uma 
tabela com esta versão do comando INSERT. Mas se não forem conhecidos os 
valores de todas as colunas, as colunas com valores desconhecidos podem ser 
omitidas, e, neste caso, essas colunas recebem um valor por defeito ou o valor 
nulo. 
 
Como os conceitos que iremos abordar nestas notas têm como base o esquema 
relacional desta pequena papelaria, solicitamos que efectua a inserção dos da-
dos das seguintes tabelas. 
 
Tabela de Família 
 
CodFamília Descrição 
1 Livros 
2 Vídeos 
3 Cd 
4 Revistas 
5 Canetas 
 
Tabela de Produto 
 
CodPro Autor Título codFa
m 
PrCusto Prvenda qtdStock 
1 Damas Luis Linguagem C 1 1500.00 2500.00 10 
2 Rangel José Estrutura de Dados em C 1 2750.00 4250.00 4 
3 Paulo Flores Coisas da Terra 3 150,00 200,00 25 
4 Tito Paris Dança ma mi Criola 3 200,00 270,00 7 
5 Damas Luis SQL 5 1750,00 3550,00 10 
6 Deitel e Deitel Como Programar em Java 1 5720,00 9640,00 0 
 
Fundamentos deBases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 113 
 
7 Bic 5 20,00 30,00 1000 
8 Teta Lando Eu vou Voltar 3 1500,00 2100,0 12 
9 Tito Paris Um Cria Ser Poeta 3 2000,00 2700,00 25 
10 Pepetela A geração da Utopia 1 1750,00 2560,00 12 
11 Pepetela O cão e o Caluandas 1 1750,00 2600,00 2 
12 Bonga Kaxexe 3 200,00 270,00 4 
 
Tabela do Histórico 
 
CodPro CodCli QtdVendida DatVenda PrCusto PrVenda 
1 1 1 2018-06-21 1500,00 2500,00 
1 2 2 2018-06-22 1500,00 2500,00 
1 5 1 2018-06-22 1500,00 2500,00 
2 3 1 2018-07-26 2750,00 4250,00 
2 4 1 2018-06-21 2750,00 4250,00 
3 1 2 2018-12-31 150,00 200,00 
3 5 1 2019-05-05 150,00 200,00 
3 7 4 2018-06-21 150,00 200,00 
4 7 1 2018-08-19 200,00 270,00 
4 2 3 2018-07-20 200,00 270,00 
5 6 2 2018-12-24 1750,00 3550,00 
7 3 3 2018-04-12 20,00 30,00 
7 5 4 2018-06-22 20,00 30,00 
7 7 2 2018-08-19 20,00 30,00 
10 2 1 2018-07-21 1760,00 2560,00 
10 1 2 2018-05-21 1760,00 2560,00 
11 7 1 2018-08-24 200,00 270,00 
 
Observação: para inserir um grande volume de dados, utilize o comando COPY. 
Este comando não é tão flexível quanto o comando INSERT, mas é mais efici-
ente. 
 
9.3.3 Actualização de Dados 
 
Na literatura da Ciência da Computação, a alteração dos dados armazenados 
nas tabelas é chamada de actualização. 
 
Para actualizar os dados de uma tabela devemos utilizar o comando UPDATE 
que possui a seguinte sintaxe: 
 
UPDATE NomeDaTabela 
SET NomeDaColuna1 = valor1, 
 . . . 
 NomeDaColunan = valorn, 
WHERE Condição; 
 
Exemplo: suponhamos o livro do autor Luís Damas, com o título SQL, sofreu a 
uma alteração de preço. O custo passou para 1500,00 Kwanzas, enquanto que 
a venda está cifrada em 2500,00 kwanzas. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 114 
 
UPDATE PRODUTO 
SET PrCusto = 1500.00, 
 PrVenda = 2500.00 
WHERE autor = ‘Damas Luis’ AND Titulo = ‘SQL’; 
 
Toda tabela possui uma chave primária, que permite identificar um produto de 
forma inequívoca. Na tabela de PRODUTO, o CodPro é a chave primária, então 
podemos utilizar essa chave para fazer essa actualização. 
 
UPDATE PRODUTO 
SET PrCusto = 1500.00, 
 PrVenda = 2500.00 
WHERE CodPro = 5’; 
 
Já sabemos utilizar o comando UPDATE para actualizar os dados de uma única 
linha, mas é possível utilizar o mesmo comando para actualizar os dados de 
várias linhas. 
 
Exemplo: alterar em 25% o preço de venda de todos os artigos da família de 
livros. 
 
UPDATE PRODUTO 
SET PrVenda = Prvenda * 1.25 
WHERE CodFam = 1; 
 
Observação: se não for colocada a cláusula WHERE, essa actualização será 
efectuada para todas as linhas da tabela. 
 
9.3.4 Remoção de várias linhas 
 
Acreditamos que o leitor já sabe inserir dados numa numa tabela e modifica-los. 
Agora necessitamos de mostrar como podemos remover várias linhas de uma 
tabela que não são mais necessárias. 
 
Para remover as linhas de uma tabela devemos utilizar o comando DELETE, que 
possui a seguinte sintaxe: 
 
 DELETE FROM NomeDaTabela 
 WHERE Condição; 
 
De forma análoga ao comando UPDATE, o comando DELETE possui a cláusula 
WHERE que serve para restringir o conjunto de linhas que serão removidas. 
 
Exemplo: remover todos os produtos da tabela PRODUTO que pertencem a fa-
mília revista. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 115 
 
Sabemos que o código do produto que identifica as revistas é o número 4. Logo, 
podemos remover todos os artigos que pertence a essa família se executarmos 
o seguinte código: 
 
DELETE FROM PRODUTO 
 WHERE CodFam = 4; 
 
Mas a linguagem SQL, também permite que se remova uma única linha de uma 
tabela. 
 
Exemplo: remover da tabela HISTORICO, a compra do CD do Teta Lando que a 
cliente Brigite Santos fez no dia 24 de dezembro de 2018. 
 
Pela tabela de CLIENTE, a cliente Brigite Santos é identificada com o número 5, 
e pela tabela de PRODUTO, o CD do Teta Lando é identificado com o número 
8, então a remoção dessa linha na tabela HISTORICO pode ser feito com o se-
guinte código. 
 
 DELETE FROM HISTORICO 
 WHERE CodPro = 8 AND CodCli = 5 AND DatVenda = ‘2018-12-24’; 
 
9.4 Exercícios Propostos 
 
 
9.5 Leituras Recomendadas 
 
Para aprofundar os temas abordados neste capítulo, recomendados que o leitor 
consulte os livros: 
 
 Luís D.;- SQL, Capítulo 12- Criação e Manutenção de Tabelas, 14ª Edi-
ção Actualizada, FCA, 2017 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Parte2: Modelo de Dados Relacional e SQL, Capítulo 4- 
SQL Básica, tradução da 6º edição americana São Paulo, Pearson Addi-
son Wesley, 2011. 
 
 Garcia-Molina, Ullman, Widom: Database Systems – The Complete Book, 
Chaper 6- The DataBase Language SQL, Prentice-Hall, 2009. 
 
 Guimarães C. C.,- Fundamentos de Banco de Dados: Modelagem, Projeto 
e Linguagem SQL, 1ª Edição, Editora da UNICAMP, 2003 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 116 
 
 Groff J. R., Wienberg P. N., Oppel A.;- The Complete Reference SQL, Part 
III, Chaper 10- DataBase Update, 3th Edition, McGraw-Hill, 2010. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Capítulo 3: O Modelo Relacional, Tradução da 3ª edição ameri-
cana, São Paulo, McGraw-Hill, 2008. 
MAC0426 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 117 
 
 
10 
Capítulo 
SQL- Consultas Simples 
 
“A SAP e a Associação Alemã de Futebol (DFB) utilizaram o Big Data para tomar decisões inteligentes 
sobre táticas, condição física dos jogadores, prospecção, bem como gestão dos jogos na copa de mundo 
do Brasil” 
 
-SAP Blogs- 
 
 
10.1 Introdução 
 
Nos capítulos anteriores estudamos com alguma profundidade os módulos DDL 
e o DML da Linguagem SQL. Agora, vamos concentrar o nosso estudo no mó-
dulo DQL dessa linguagem. O nosso objectivo é estudar como se pode extrair 
informações úteis à sociedade a partir dos dados armazenados nas tabelas. 
 
Neste capítulo iremos estudar de forma muito superficial o comando para extrair 
informação em ou mais tabelas. 
 
10.2 Linguagem Consulta de Informação (DQL) 
 
Na linguagem SQL, a extração de informação das tabelas é feita pelo 
subconjunto DQL- Data Query Language, que possui o comando SELECT, 
embora, muito autores consideram que esse comando faz parte da DML - Data 
Manipulation Language. 
 
10.2.1 Extracção de informação numa Tabela 
 
Vamos dar continuidade ao nosso estudo com a extração da informação da Base 
de dados que criamos no capítulo anterior. Mas, para que o leitor posso conso-
lidar os seus conhecimentos, aconselhamos a inserir todos os dados das tabelas 
que descrevemos anteriormente. 
 
Para extrair a informação de uma tabela devemos utilizar o comando SELECT 
que possui a seguinte sintaxe: 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela; 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 118 
 
 
Exemplo: visualizar toda a informação da tabela de clientes. 
 
Para visualizarmos o conteúdo de todas as linhas da tabela de clientes, basta 
executar a seguinte consulta: 
 
SELECT * 
FROM CLIENTE; 
 
O operador * seleciona automaticamente todas as colunas dessa tabela. 
 
Mas a maior parte das vezes, estamos interessados em visualizara informação 
de apenas algumas colunas de uma tabela. 
 
Exemplo: mostrar o nome, o sobrenome e a data de nascimento dos clientes que 
foram carregados na tabela de clientes. 
 
Esta consulta é chamada de Projeção, e pode ser feita pela seguinte consulta: 
 
SELECT Nome, Sobrenome, datNasc 
FROM CLIENTE; 
 
10.2.2 Restrições 
 
Para visualizar um conjunto de linhas que satisfazem uma determinada 
condição, devemos utilizar a cláusula WHERE no comando SELECT. 
 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela 
 WHERE Condição; 
 
Mas para utilizar essa condição, temos de recorrer aos seguintes operadores. 
 
10.2.3 Operadores Aritméticos 
 
Os operadores aritméticos servem para realizar cálculos com campos do tipo 
numérico. 
Operador Descrição 
+ 
- 
* 
/ 
% 
adição 
subtração 
multiplicação 
divisão inteira 
Resto da divisão 
 
Exemplo: extrair da tabela de produtos, o preço de venda de todos os artigos 
com um aumento de 5%. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 119 
 
 
Para visualizarmos essa informação basta executar a seguinte consulta. 
 
SELECT CodPro, Autor, Titulo, PrVenda * 1.05 
FROM PRODUTO; 
 
 
10.2.4 Operadores Relacionais 
 
Os operadores relacionais servem para realizar comparações com os valores 
dos campos da tabela. 
 
Operador Descrição 
= 
> 
< 
>= 
<= 
<> 
igual a 
maior do que 
menor do que 
maior ou igual a 
menor ou igual a 
diferente de 
 
Exemplo: extrair da tabela de produtos os artigos que pertencem a família de 
livros. 
 
Sabemos que o código que identifica a família dos livros possui o valor 1. Então, 
para visualizar todos os artigos que pertence a essa família, basta executar a 
seguinte consulta: 
 
SELECT CodPro, Autor, Titulo, PrCusto, PrVenda, QtdStock 
FROM PRODUTO 
 WHERE CodFam = 1; 
 
Exemplo: extrair da tabela de produtos os artigos que não têm stock. 
 
Sabemos que qualquer artigo não possui stock quando a quantidade existente é 
igual a zeros. Então, para visualizar na tela esses artigos, basta executar a se-
guinte consulta: 
 
SELECT CodPro, Autor, Titulo, PrCusto, PrVenda 
FROM PRODUTO 
 WHERE Stock = 0; 
 
10.2.5 Operadores Lógicos 
 
Os operadores lógicos servem para realizar operações booleanas com campos 
da tabela. 
 
 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 120 
 
Operador Descrição 
AND 
OR 
NOT 
e 
ou 
não 
 
Exemplo: extrair da tabela de produtos os cd’s que têm um preço de custo 
superior a 570.00 Kz 
 
Sabemos pela tabela de produtos que o código da família dos Cd’s é igual a 3. 
Então, para visualizamos todos os cd’s cujo preço de custo é superior a 570,00 
Kz, basta executar a seguinte consulta: 
 
SELECT CodPro, Autor, Titulo, PrCusto, PrVenda, QtdStock 
FROM PRODUTO 
 WHERE CodFam = 3 AND PrCusto > 570,00; 
 
Exemplo: extrair da tabela de produtos os artigos que pertencem a família de 
CD’s ou a família das revistas. 
 
Sabemos pela tabela de produtos que o código da família dos Cd’s é igual a 3, 
e que o código da família das revistas é igual a 4. Então, para visualizamos tela 
todos os cd’s que pertencem a essas famílias, basta executar a seguinte con-
sulta: 
 
SELECT CodPro, Autor, Titulo, PrCusto, PrVenda, QtdStock 
FROM PRODUTO 
 WHERE CodFam = 3 OR CodFam = 4; 
 
10.2.6 Operador BETWEEN 
 
O operador BETWEEN permite especificar intervalos de valores. Apresentamos 
a seguir, a sintaxe desse operador no comando SELECT. 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela 
 WHERE valor [NOT] BETWEEN limiteInferio AND limiteSuperior; 
 
Para que o leitor tenha uma melhor interpretação deste operador, vamos 
compará-lo aos operadores relacionais. 
 
A expressão: 
 
 valor BETWEEN limiteInferio AND limiteSuperior 
 
é equivalente a expressão 
 
 valor >= limiteInferio 1 AND valor <= limiteSuperior 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 121 
 
enquanto que a expressão: 
 
valor NOT BETWEEN limiteInferio AND limiteSuperior 
 
é equivalente a expressão 
 
valor < limiteInferio OR valor > limiteSuperior 
 
Exemplo: extrair os artigos cujo preço de custo está entre 750,00 Kz e 1500,00 
Kz kwanzas. 
 
Para visualizar essa informação basta executar a seguinte consulta: 
 
SELECT CodPro, Autor, Titulo 
FROM PRODUTO 
 WHERE PrCusto BETWEEN 750,00 AND 1500,00; 
 
que é equivalente à 
 
SELECT CodPro, Autor, Titulo 
FROM PRODUTO 
WHERE PrCusto >= 750,00 AND PrCusto <= 1500,00; 
 
10.2.7 Operador IN 
 
O operador IN permite que se verifique se um determinado campo c, está contido 
num determinado conjunto de elementos T, e retorna TRUE se o valor c for igual 
a algum elemento de T. Apresentamos a seguir, a sintaxe desse operador no 
comando SELECT. 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela 
 WHERE valor [NOT] IN (valor1, valor2, … , valorn); 
 
Exemplo: extrair da tabela de produtos os artigos que possuem o código de 
família igual a 3 (CD) ou igual a 4 (revistas). 
 
Para visualizarmos essa informação, basta executar a seguinte consulta. 
 
SELECT CodPro, Autor, Título, PrCusto, PrVenda 
FROM PRODUTO 
 WHERE CodFam IN (3,4); 
 
que é equivalente a: 
 
SELECT CodPro, Autor, Titulo, PrCusto, PrVenda, QtdStock 
FROM PRODUTO 
 WHERE CodFam = 3 OR CodFam = 4; 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 122 
 
 
Exemplo: extrair da tabela de produtos os títulos dos CD’s do Tito Paris e do Teta 
Lando. 
 
Para visualizarmos essa informação, basta executar a seguinte consulta 
SELECT Titulo 
FROM PRODUTO 
 WHERE autor IN (‘Tito Paris’, ‘Teta Lando’); 
 
que é equivalente à: 
 
SELECT Titulo 
FROM PRODUTO 
 WHERE autor = ‘Tito Paris’ OR autor = ‘Teta Lando’; 
 
Observação: A Linguagem SQL distingue as letras maiúsculas das letras 
minúsculas. 
 
10.2.8 Operador LIKE 
 
A linguagem SQL disponibiliza recursos para efectuar a comparação de cadeias 
de caracteres strings. Para esse caso, as string’s são comparadas elemento por 
elemento em ordem alfabética ou lexicográfica, do inicio para o fim. 
 
O operador LIKE, realiza essa comparação desde que sejam utilizados os 
seguintes wildcards. 
 
Wildcards Significado 
% 
? 
- 
qualquer cadeia de caracteres com zero ou mais caracteres 
qualquer cadeia de caracteres 
qualquer cadeia de caracteres com zero ou um caracter 
 
Exemplo: extrair da tabela de clientes, todos os clientes cujo nome começa com 
a palavra Carlos. 
 
SELECT * 
FROM CLIENTE 
 WHERE Nome = ‘Carlos%a’; 
 
Exemplo: extrair da tabela CLIENTE, o autor, o título e a quantidade de artigos 
em stock, dos artigos que possuem um título que contém a posição ama. 
 
SELECT Autor, Titulo, QtdStock 
FROM PRODUTO 
 WHERE Titulo = ‘%ama%’; 
 
10.2.9 Eliminação das Repetições 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 123 
 
 
Ao executarmos um comando SELECT, muitas vezes aparecem linhas 
repetidas. Para eliminar essas linhas devemos utilizar como sufixo desse a 
palavra reservada DISTINCT, ou seja: 
 
 SELECT DISTINCT campo1, campo2, … , campon 
 FROM …. 
 
10.2.10 Realização de Cálculos 
 
Com a linguagem SQL permite que se crie campos que não pertencem à tabela 
e que possam conter valores que sejam obtidos por cálculos de alguns campos 
da tabela. 
 
Exemplo:mostre como ficariam os preços de venda de todos os cd’s se 
quiséssemos fazer um aumento de 20%. 
 
SELECT Titulo, Prvenda, (PrVenda * 1.2) NovoPreco 
FROM PRODUTO 
 WHERE CodFam = 2; 
 
10.2.10 Ordenação 
 
A ordenação das colunas de uma tabela pode ser feita pela cláusula ORDER 
BY. Esta cláusula, se existir, deve ser colocada na última linha do comando 
SELECT. 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela 
 WHERE valor [NOT] IN ( valor1, valor2, … , valorn) 
 ORDER BY campo1 [ASC| DESC], … , campo1 [ASC| DESC]; 
 
onde 
 ASC indica que a ordenação será feita em ordem crescente; 
e 
 DESC que a ordenação será feita em ordem decrescente; 
 
Exemplo: extrair na tabela de clientes, o nome, sobrenome e o sexo de todos os 
clientes da papelaria, ordenados em ordem crescente por data de nascimento. 
 
Como por defeito a ordenação é feita em ordem crescente, então, para visualizar 
essa informação, basta executar a seguinte consulta: 
 
SELECT DISTINCT Nome, Sobrenome, Sexo 
FROM CLIENTE 
 ORDER BY datNasc; 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 124 
 
Exemplo: extrair os artigos que têm stock, cujo preço de venda está entre 150,00 
há 1000,00 kwanzas, ordenados em ordem decrescente pela quantidade de 
stock. 
 
Para visualizar essa informação, basta executar a seguinte consulta: 
 
SELECT DISTINCT Titulo, QtdStock 
FROM PRODUTO 
 WHERE QtdStock > 0 AND PrVenda BETWEEN 150,00 AND 1000,00 
 ORDER BY DESC QtdStock; 
 
Exemplo: extrair os artigos, cuja quantidade em stock é maior do que 500 
unidades, e cuja margem de lucro é superior a 10%. 
 
Para visualizar essa informação, basta executar a seguinte consulta. 
 
SELECT DISTINCT Titulo, QtdStock 
FROM PRODUTO 
 WHERE QtdStock > 500 AND (PrVenda – Prcusto) * 2 > 10 
 ORDER BY DESC QtdStock; 
 
Mas, muitas vezes temos de limitar o número de linhas que pretendemos 
visualizar, para esse efeito, devemos utilizar a palavra reservada 
 
LIMIT N; 
 
Esse limite é normalmente utilizado depois da Cláusula ORDER BY de forma a 
selecionar as n primeiras linhas que satisfazem um determinado critério de 
ordenação. 
 
Exemplo: mostrar os títulos dos 5 primeiros artigos diferentes, em ordem 
decrescente, com stock na papelaria. 
 
Para visualizar essa informação, basta executar a consulta. 
 
SELECT DISTINCT Titulo, QtdStock 
FROM PRODUTO 
 WHERE QtdStock > 0 
 ORDER BY DESC QtdStock LIMIT 5; 
 
10.2.11 Operações com Conjuntos 
 
O SQL incorpora algumas das operações com conjuntos, em que o resultado é 
um conjunto de linhas não duplicadas. 
 
Reunião: (Consulta1) UNION (Consulta2); 
Intersecção: (Consulta1) INTERSECT (Consulta2); 
Diferença: (Consulta1) EXCEPT (Consulta2); 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 125 
 
Mas também existem as versões destes operadores que não removem as linhas 
duplicadas. 
 
Reunião: (Consulta1) UNION ALL (Consulta2); 
Intersecção: (Consulta1) INTERSECT ALL (Consulta2); 
Diferença: (Consulta1) EXCEPT ALL (Consulta2); 
 
A operação de união de conjuntos entre duas tabelas A e B, mostra os elementos 
comuns a essas tabelas, ou seja, A U B. 
 
Mas só pode ser utilizada se essas tabelas tiverem os mesmos campos e esses 
campos estiverem na mesma ordem. 
 
Exemplo: mostrar nome dos autores que possuem artigos na secção de família 
de livros ou artigos da família de revistas. 
 
Para visualizar essa informação, basta interrogar na tabela PRODUTO, todos 
aos autores que têm artigos que são da família cujo código é igual a 1 ou artigos 
que são da família cujo código é igual a 5, ou seja: 
 
(SELECT Autor 
FROM PRODUTO 
WHERE CodFam = 1) 
UNION 
(SELECT Autor 
FROM PRODUTO 
WHERE CodFam = 5) 
 
Para desenvolver essa consulta, necessitamos de dois comandos SQL que es-
tão ligados pela cláusula UNION. Se existirem registros repetidos, a operação 
de união irá automaticamente elimina-lo. Isso quer dizer que essa consulta é 
equivalente à: 
 
SELECT DISTINCT Autor 
FROM PRODUTO 
WHERE CodFam = 1 OR CodFam = 5; 
 
A operação de diferença entre duas tabelas A e B, apesar de não ser implemen-
tada em alguns SGBD, mostra os elementos que pertencem a tabela A e não 
pertencem a Tabela B, ou seja, A − B. 
 
Exemplo: mostrar nome dos autores que não venderam artigos. 
 
Para visualizar na tela os autores que não venderam artigos, basta interrogar 
nas tabelas PRODUTO e HISTORICO, os autores que estão na tabela de PRO-
DUTO, têm stock, mas não possuem nenhuma ocorrência na tabela de Histórico, 
ou seja: 
 
(SELECT Autor 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 126 
 
FROM PRODUTO 
WHERE qtdStock > 0) 
EXCEPT 
(SELECT Autor 
FROM HISTORICO) 
 
A operação de intersecção entre duas tabelas A e B, mostra os elementos que 
estão nas duas tabelas, ou seja, A ∩ B. 
 
Exemplo: mostrar nome dos autores que venderam artigos. 
 
Para visualizar na tela os autores que venderam artigos, basta interrogar nas 
tabelas PRODUTO e HISTORICO, os autores que estão na tabela de PRO-
DUTO, têm stock, e possuem alguma ocorrência na tabela de Histórico, ou seja: 
 
(SELECT Autor 
FROM PRODUTO 
WHERE qtdStock > 0) 
INTERSECT 
(SELECT Autor 
FROM HISTORICO) 
 
10.2.12 Inserção de um conjunto de linhas 
 
Para copiar os dados de uma tabela para outra, podemos associar o comando 
INSERT com o comando SELECT, utilizando a seguinte sintaxe: 
 
INSERT INTO NomeDaTabela [(Campo1, Campo2, …, Campon)] 
SELECT … 
FROM Tabela 
WHERE Condição; 
 
Exemplo: suponhamos que foi criada a tabela de livros que possui os mesmos 
campos da tabela de produtos. Para copiar todos os livros da tabela produtos 
para a tabela de livros. 
 
Para visualizar essa informação, basta executar a seguinte consulta. 
 
 INSERT INTO LIVRO 
SELECT * 
FROM PRODUTO 
 WHERE CodFam = 1; 
 
Ou 
 
INSERT INTO LIVRO(CodPro,Autor,Titulo, CodFam, Prcusto, PrVenda, Stock) 
SELECT * 
FROM PRODUTO 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 127 
 
 WHERE CodFam = 1; 
 
10.3 Extracção de Dados em Várias Tabelas 
 
10.3.1 Conceitos 
 
Nas secções anteriores, vimos como extrair os dados de uma tabela. Mas muitas 
vezes temos a necessidade de extrair dados que estão contidos em várias 
tabelas. A esse tipo de extração dá-se o nome de junção (join). Mas para efectuar 
essa extracção, necessitamos de um critério que estabeleça a comparação entre 
as tabelas, e esse critério baseia-se na comparação da chave primária de uma 
tabela com a chave estrangeira de outra. Na Ciência da Computação, este tipo 
de junção recebe o nome de junção idêntica (Equi-join), e nestas notas, à iremos 
estudar de uma forma muito superficial, com a sintaxe da SQL/86. 
 
Uma junção (join) permite extrair com único comando SELECT à informação que 
está contida em várias tabelas, e possui à seguinte sintaxe: 
 
SELECT Campo1, Campo2, … , Campon 
FROM Tabela1, Tabela2, … , Tabelan 
 WHERE Condição; 
 
onde às várias tabelas são descritas na cláusula FROM, e à relação entre elas 
é descrita pela cláusula WHERE. 
 
10.3.2 Produto Cartesiano 
 
Entendemos por Produto Cartesiano (Cross-Join) a junção de várias tabelas sem 
qualquer restrição. 
 
Exemplo: determinar o produto cartesiano entre a tabela de clientes e a tabela 
de produtos. 
 
Para visualizar essa informação, basta executar a seguinte consulta. 
 
SELECT * 
FROM CLIENTE, PRODUTO; 
 
Essaconsulta vai mostrar a associação entre cada linha da tabela de clientes 
com todas as linhas da tabela de produtos. Se por exemplo, a tabela de clientes 
tiver 9 linhas e a tabela produtos tiver 10 linhas, o produto cartesiano terá 90 
linhas. Mas se invertemos a ordem dessas tabelas, o produto cartesiano terá o 
mesmo número de linhas, mas a ordem das colunas será diferente. 
 
10.3.3 Junção Natural 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 128 
 
A Junção Natural (Natural-Join) consiste na aglutinação de duas ou mais tabelas, 
com alguma restrição. Essa restrição é feita na cláusula WHERE, com a 
comparação da chave primária de uma tabela com a chave estrangeira da outra. 
 
Em termos de teoria de conjuntos, a Natural-Join, representa a intersecção de 
conjuntos, e é descrito pelo seguinte diagrama de Venn Euler: 
 
Mas se não mencionarmos no comando SELECT os campos que pretendemos 
visualizar, serão mostrados todos os campos das tabelas envolvidas, e teremos 
para esse caso, informações repetidas. 
 
Exemplo: dado o código de um artigo, mostrar o seu nome, o seu título e quantos 
exemplares foram vendidos. 
 
Em termos mais concretos, suponhamos o código do produto é igual a dois, 
queremos saber o nome do autor, os títulos das obras desse autor, e quantos 
exemplares foram vendidos. 
 
Vamos estruturar em primeiro lugar essa informação. O nome do autor e o título 
da obra estão na tabela de produtos, enquanto que, a quantidade vendida está 
na tabela de Histórico dos produtos. A tabela de produtos tem como chave 
primária o Código de Produto, enquanto que a Tabela histórico das vendas dos 
produtos esse código é uma chave estrangeira. Vamos aproveitar essa ligação 
para extrair essa informação: 
 
SELECT PRODUTO.Autor, PRODUTO.Titulo, HISTORICO.QtdVendida 
FROM PRODUTO, HISTORICO 
 WHERE PRODUTO.Codpro =HISTORICO.Codpro AND PRODUTO.CodPro = 2; 
 
Observe que o acesso a qualquer campo da tabela é feito pela notação: 
 
 NomeDaTabela.NomeDoCampo 
 
Vamos tornar a informação que visualizamos mais fácil de interpretar com a sua 
ordenação em ordem crescente de data de compra. Como acreditamos que o 
leitor não deverá ter qualquer dificuldade em estruturar a informação, 
apresentaremos apenas uma consulta que mostra essa informação. 
 
 
 
 
SELECT PRODUTO.Autor, PRODUTO.Titulo, HISTORICO.QtdVendida, 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 129 
 
 HISTORICO.DatVenda 
FROM PRODUTO, HISTORICO 
 WHERE PRODUTO.Codpro =HISTORICO.Codpro AND PRODUTO.CodPro = 2 
 ORDER BY HISTORICO.DatVenda; 
 
Exemplo: mostrar o nome, o sobrenome, e o número do telefone de todos os 
clientes que compraram os CD’s do Tito Paris e do Tela Lando, ordem crescente 
por data de compra. 
 
Mas antes de escrevermos essa consulta, vamos mais uma vez, estruturar a 
informação que será visualizada. Na tabela de clientes temos o nome, o 
sobrenome e o número de telefone, enquanto que, na tabela de produtos temos 
o autor e o título, e na tabela Histórico das vendas dos artigos temos a 
quantidade vendida e a data de venda. Vamos ligar essas tabelas pelas suas 
chaves. 
 
SELECT CLIENTE.Nome, CLIENTE.Sobrenome, CLIENTE.Telefone, 
 PRODUTO.Autor, PRODUTO.Titulo, HISTORICO.QtdVendida, 
 HISTORICO.DatVenda 
FROM CLIENTE, PRODUTO, HISTORICO 
 WHERE PRODUTO.Codpro = HISTORICO.Codpro AND 
 CLIENTE.Codcli = HISTORICO.Codcli AND 
 PRODUTO.CodFam = 1 AND 
 PRODUTO.Autor = ‘Tito Paris’ OR ‘Teta Lando’ 
 ORDER BY HISTORICO.DatVenda; 
 
Mas essa consulta não está de acordo com as boas prácticas de programação. 
Para tornar a consulta mais genérica, e de acordo com as boas práticas de 
programação, devemos incluir a tabela de família dos produtos. 
 
SELECT CLIENTE.Nome, CLIENTE.Sobrenome, CLIENTE.Telefone, 
 PRODUTO.Autor, PRODUTO.Titulo, HISTORICO.QtdVendida, 
 HISTORICO.DatVenda 
FROM CLIENTE, PRODUTO, HISTORICO, FAMILIA 
 WHERE PRODUTO.Codpro =HISTORICO.Codpro AND 
 CLIENTE.Codcli = HISTORICO.Codcli AND 
 FAMILIA.Descricao = ‘CD’ AND 
 PRODUTO.CodFam = FAMILIA.CodFam AND 
 PRODUTO.Autor = ‘Tito Paris’ OR ‘Teta Lando’ 
 ORDER BY HISTORIO.DatVenda 
 
Podemos utilizar a junção natural, para implementar a operação de intersecção 
entre duas tabelas. Vamos clarificar esse conceito com o exemplo estudado an-
teriormente. 
 
Exemplo: mostrar nome dos autores, o titulo do produto e as quantidades vendi-
das, ordenadas por data de venda. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 130 
 
Vamos estruturar a informação que será visualizada. Na tabela de produtos 
temos o código do produto, o nome do autor, o título do produto, e na tabela 
Histórico das vendas, temos o código do produto, e a quantidade vendida. 
Vamos ligar essas tabelas pelas suas chaves. 
 
SELECT PRODUTO.Autor, PRODUTO.Titulo, HISTORICO.QtdVendida, 
 HISTORICO.DatVenda 
FROM PRODUTO, HISTORICO 
 WHERE PRODUTO.Codpro = HISTORICO.Codpro AND 
 HISTORICO.QtdVendida > 0 
 ORDER BY HISTORIO.DatVenda 
 
10.3.4 Apelidos 
 
Nas consultas anteriores, escrevemos várias vezes o nome das tabelas. Para 
evitar essa redundância de código, devemos utilizar apelidos (aliás). Por 
exemplo, para o exemplo anterior, teremos: 
 
SELECT CLI.Nome, CLI.Sobrenome, CLI.Telefone, PRO.Autor, PRO.Titulo, 
 HIS.QtdVendida, HIS.DatVenda 
FROM CLIENTE AS CLI, PRODUTO AS PRO, HISTORICO AS HIS, 
 FAMILIA AS FAM 
 WHERE PRO.Codpro =HIS.Codpro AND CLI.Codcli = HIS.Codcli AND 
 FAM.Descricao = ‘CD’ AND PRO.CodFam = FAM.CodFam AND 
 PRO.Autor = ‘Tito Paris’ OR ‘Teta Lando’ 
 ORDER BY HIS.DatVenda 
 
Os apelidos (Aláis) devem ser utilizados para evitar por um lado, a repetição do 
nome das tabelas, e por outro, para melhorar a compreensão e legibilidade do 
código. 
 
É muito usual encontrar-se num Projecto de Base de Dados, campos de tabelas 
diferentes com os mesmos nomes. Por exemplo: 
 
DEPARTAMENTO (Nome, NumDep, CodChefe) 
PK (NumDep) 
 
PROJECTO (Nome, NumProj, Localização, NumDep) 
PK (NumProj) 
FK (NumDep) 
 
Como distinguir numa consulta, o campo Nome da Tabela de DEPARTAMENTO 
do campo Nome da tabela de PROJECTO. 
 
A solução consiste em utilizar um apelido (Aliás), que vai relacionar o Nome a 
respectiva tabela. 
 
10.3.5 Auto Junção 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 131 
 
 
Entende-se por Auto Junção (Auto-Join), a junção feita na mesma tabela, que 
alguns autores denominam por junção com recursividade. 
 
Para realizar essa junção devemos utilizar um apelido (Aliás) para indicar os 
papeis dos actores que participam nessa relação (tabela). 
 
Vamos consolidar esse conceito, com um exemplo muito simples. 
 
Dado o esquema relacional 
 
EMPREGADOS (CodEmp, CodChefe, Nome, SobreNome, Função,Salario) 
PK (CodEmp) 
FK (CodChefe) REFERENTE EMPREGADO(codEmp) 
 
cujo Script deixamos como exercício, e também deixamos como exercício o 
carregamento dos seguintes dados: 
 
CodEmp Nome SobreNome Função SalarioCodChefe 
1 
2 
3 
4 
5 
João 
Rui 
Télcio 
Rita 
Cliana 
Castro 
da Costa 
Vieira 
Sardinha 
Barros 
Administrador 
Director 
Técnico 
Técnico 
Director 
850.000,00 
500.000,00 
250.000,00 
250.000,00 
500.000,00 
 
1 
2 
2 
1 
 
Observe que o funcionário João Castro não possui nenhum gerente, enquanto 
que o funcionário Rui da Costa e a Funcionária Cliane Barros são subordinadas 
do funcionário João Castro. 
 
Exemplo: extrair o nome, o sobrenome de cada empregado, e o nome e o 
sobrenome do respectivo supervisor. 
 
Vamos utilizar os apelidos EMP para empregado e SUP para supervisor. Para 
visualizar essa informação, devemos executar a seguinte consulta. 
 
SELECT EMP.Nome, EMP.SobreNome, SUP.Nome, SUP.Sobrenome 
FROM EMPREGADO AS EMP, EMPREGADO AS SUP 
WHERE EMP.CodEmp = SUP.CodEmp 
ORDEY BY EMP.Nome; 
 
10.3.5 Junção Interna 
 
A junção Interna (Inner–join) tem por finalidade aglutinar duas ou mais tabelas, 
com base nas chaves primárias e secundárias. 
 
Em termos de teoria de conjuntos, a Inner-join, representa a intersecção de 
conjuntos, e é descrito pelo seguinte diagrama de Venn Euler: 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 132 
 
 
Exemplo: mostrar nome dos autores, o titulo do produto e as quantidades vendi-
das, ordenadas por data de venda. 
 
SELECT PRO.Autor, PRO.Titulo, HIS.QtdVendida, HIS.DatVenda 
FROM PRODUTO AS PRO INNER JOIN HISTORICO AS HIS 
 ON PRO.Codpro = HIS.Codpro AND HIS.QtdVendida > 0 
 ORDER BY HIS.DatVenda 
 
Exemplo: mostrar o código, o nome, título e preço de custo e venda de todos os 
livros carregadas na base de dados. 
 
Vamos estruturar a informação que será visualizada. Na tabela de produtos 
temos o código do produto, o nome do produto, o preço de custo, o preço de 
venda e o código da família do artigo, enquanto que, na tabela de famílias, temos 
o código da família e sua descrição. 
 
SELECT PRO. Codigo, PRO.titulo, PRO.Prcusto, PRO. Prvenda 
FROM PRODUTO AS PRO INNER JOIN FAMILIA AS FAM 
 ON PROD.Codfam = FAM:CodFam AND Fam:codFam = 1 
 
10.3.5 Outros Tipos de Junção 
 
 
 
Com base na figura anterior, o leitor poderá ter uma nação precisa dos vários 
tipos de junção que a linguagem SQL disponibiliza. Para aprofundar esse 
assunto recomendamos a obra de Groff [2010] ou Garcia-Molina [2009]. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 133 
 
 
 
10.4 Exercícios Propostos 
 
10.4.1- Dado o esquema relacional 
 
MOTORISTA (CodMot, Nome, Avaliação, Idade) 
AUTOCARRO (Matricula, Marca, Cor) 
RESERVA (Matricula, CodAuto, data) 
 
Desenvolva as seguintes consultas em SQL: 
 
1-Mostre os nomes e as idades de todos os motoristas. 
 
2-Mostre os nomes dos motoristas que possuem uma avaliação superior a 15 
valores. 
 
3-Mostre os nomes de todos os motoristas que conduziram o autocarro com a 
matricula LD2286. 
 
4-Mostre os códigos, e o nome de todos os motoristas que conduziram autocar-
ros de marca volvo. 
 
5-Mostre as idades dos motoristas cujos nomes começam e termina com a letra 
B e têm no mínimo três caracteres. 
 
6-Mostre os nomes de todos os motoristas que conduziram autocarros de marca 
volvo e autocarros de marca Scania. 
 
7-Mostre o código e o nome dos motoristas que conduziram autocarros de marca 
Volvo e não conduziram autocarros de marca Scania. 
 
8-Mostre os códigos e os nomes de todos os motoristas que têm uma avaliação 
entre 12 a 17 que conduziram o autocarro que possui a matricula LD2453. 
 
9-Mostre os códigos e os nomes dos motoristas que não conduziram autocarros 
de marca volvo e nem conduziram autocarros de marca volvo. 
 
10-Mostre os códigos e os nomes dos motoristas cujas avaliações são melhores 
do que as avaliações do motorista Silva. 
 
11-Mostre os nomes dos motoristas em ordenados em ordem decrescente por 
avaliação. 
 
12-Mostre o nome dos motoristas que conduziram todos os autocarros. 
 
10.4.2- Dado o seguinte esquema relacional 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 134 
 
AGENCIA (CodAgencia, nome, rua, cidade) 
PK (CodAgencia) 
 
EMPRESTIMO (NumEmprestimo, CodAgencia, total) 
PK (NumEmprestimo) 
FK (CodAgencia) REFERENTE AGENCIA (CodAgencia) 
 
DEVEDOR (CodCliente, NumEmprestimo) 
PK (CodCliente) 
FK (NumEmprestimo) REFRENTE EMPRESTIMO (NumEmprestimo) 
 
CONTA (NumConta, CodAgencia, Saldo) 
PK (NumConta) 
FK (CodAgencia) REFERENTE AGENCIA (CodAgencia) 
 
CLIENTE (CodCliente, NumConta) 
PK (CodCliente) 
FK (NumConta) REFERENTE CONTA (NumConta) 
 
Desenvolva as seguintes consultas em SQL: 
 
1- Mostre o nome por agencia, o nome de todos os clientes que solicitaram um 
empréstimo maior do que 200.000,00 Kwanzas. 
 
2- Mostre o nome dos clientes que já pagaram os seus empréstimos, e também 
mostre o valor desse empréstimo. 
 
3- Mostre o nome dos clientes que têm um empréstimo a pagar na agencia dos 
combates, ordenado em ordem ascendente pelo valor a pagar. 
 
4- Mostre o nome dos clientes que solicitaram um empréstimo ou que abriram 
uma conta na agencia da Baixa ou ambos. 
 
5- Mostre o nome de todos os clientes que têm a sua conta bancária sem saldo, 
mas têm um empréstimo a pagar. 
 
6- Mostre o nome de todos os clientes que pediram um empréstimo ao banco, 
mas não possuem uma conta bancaria. 
 
7- Mostre o nome de todas as agencias, seu endereço que possuem clientes 
com empréstimos para saldar, ordenado por ´numero de agencia. 
 
10.4.4- Dado o esquema relacional 
 
EMPREGADO (NumBI, Nome, SobreNome, DataNasc, Rua, Casa, bairro, Sexo, 
Salario, CodSup, CodDep, CodProf) 
PK (NumBI) 
FK (CodSup) REFERENTE FUNCIONARIO (CodFunc) 
FK (CodDep) REFERENTE DEPARTAMENTO (CodDep) 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 135 
 
FK (CodProf) REFERENTE PROFISSAO (CodProf) 
 
DEPARTAMENTO(CodDep, Nome, Rua, Casa, Bairro, DataGerente) 
PK (CodDep) 
 
PROFISSAO (CodProf, Descricao) 
PK (CodPro) 
 
 
PROJETO(CodProj, Nome, Rua, Casa, Bairro, Cidade, CodDep) 
PK (CodProj) 
FK (CodDep) REFERENTE DEPARTAMENTO(CodDep) 
 
TRABALHA_EM (NumBI, CodProj, HorasSemana) 
FK (NumBI) REFERENTE FUNCIONARIO (NumBI) 
FK (CodProj) REFERENTE PROJETO (CodProj) 
 
DEPENDENTE (NumBI, Nome, sexo, Datanasc, Parentesco) 
PK (NumBI, Nome) 
FK (NumBI) REFERENTE FUNCIONARIO (NumBI) 
 
Desenvolva as seguintes consultas em SQL: 
 
1- Mostre o número do número do BI, o nome e o sobrenome nome de todos os 
empregados. 
 
2- Mostre o número do BI dos empregados que trabalham no departamento 4, e 
cujo salário é superior a 100.000,00 Kwanzas. 
 
3-Mostre o nome dos empregados que trabalham no departamento de 4 e no 
departamento 6. 
 
4-Mostre o número do BI, o nome e o sobrenome dos empregados que têm de-
pendentes. 
 
5- Mostre o número do BI, o nome e o sobrenome dos empregados que traba-
lham nos projectos 4, 5 ou 6, ordenados em ordem crescente por número de 
BI. 
 
6-Em todos os projectos localizados na Cidade de Luanda, mostre o nome do 
projecto, e o nome e o sobrenome do respectivo gerente. 
 
7-Em Todos os projectos localizados nas cidades de Luanda e Malange, mostre 
o nome e o sobrenome dos empregados, e os respectivos salários com um au-
mento de 5%. 
 
8- Para todos os projectos realizados na cidade de Benguela, mostre o número 
do projecto, o nome do departamento que o controla, o endereço, e a data de 
aniversário do chefe desse departamento. 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católicade Angola Prof. Manuel Meneses 136 
 
 
9- Para todos os empregados da empresa, mostre o nome, o sobrenome, a 
profissão dos empregados que não têm dependentes, ordenados em ordem 
alfabética por nome. 
 
10- Para todos os empregados da empresa, mostre o nome, o sobrenome, a 
profissão dos empregados cujos dependentes têm o mesmo nome. 
 
11-Mostre o número do BI, nome, e o sobrenome dos empregados que traba-
lham no departamento 4, cujo salário é superior 200.000,00 Kwanzas, mas infe-
rior e 500.000,00 Kwanzas. 
 
12-Mostre o nome de todos os projectos que possuem a letra ‘m’ que estão a ser 
realizados pelo departamento 6. 
 
13- Mostre o número e o nome dos projectos que possuem a letra ‘m’ e a letra 
‘a’ que estão a ser realizados pelo departamento 4 ou pelo departamento 4, or-
denados em ordem decrescente de nome do departamento. 
 
14-Mostre o nome de todos os empregados que não possuem supervisor. 
 
14-Mostre em ordem alfabética o nome dos empregados que trabalham no de-
partamento de informática, cujo salário é superior a 1500,00 euros. 
 
15- Mostre o valor do salário máximo dos empregados que trabalham no depar-
tamento de Informática e o nome e sobrenome desses empregados. 
 
16- Mostre o número do BI dos empregados que trabalham no departamento de 
Informática ou que supervisionam um empregado que trabalha nesse departa-
mento. 
 
17- Mostre o número do BI, o nome e o sobrenome, dos empregados que traba-
lham no mesmo departamento da empregada Katila Cunha, que possui o BI nº 
4875LA546, e que trabalham o mesmo número de horas. 
 
10.5 Leituras Recomendadas 
 
Para aprofundar os temas abordados neste capítulo, recomendados que o leitor 
consulte os livros: 
 
 Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos 
e aplicações, Parte2: Modelo de Dados Relacional e SQL, Capítulo 4- 
SQL Básica, tradução da 6º edição americana São Paulo, Pearson Addi-
son Wesley, 2011. 
 
 Garcia-Molina, Ullman, Widom: Database Systems – The Complete Book, 
Part II Relational DataBase Programming, Chaper 6- The DataBase Lan-
guage SQL, Prentice-Hall, 2009. 
 
 
Fundamentos de Bases de Dados: Notas de Aula 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Meneses 137 
 
 Guimarães C. C.,- Fundamentos de Banco de Dados: Modelagem, Projeto 
e Linguagem SQL, 1ª Edição, Editora da UNICAMP, 2003 
 
 Groff J. R., Wienberg P. N., Oppel A.;- The Complete Reference SQL, Part 
III Chaper 3- Simples Queries, 3 th Edition, McGraw-Hill, 2010. 
 
 Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Chaper 5: SQL: Consultas, Restrições, Gatilhos, Tradução da 3ª 
edição americana, São Paulo, McGraw-Hill, 2008. 
 
Introdução as Técnicas de Desenvolvimento de Algoritmos 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Menezes 138 
 
 
 
 
Referências Bibliográficas 
 
 
 
1. Chen P. P.;- The entity relationship model: toward a unified view of data, 
ACM Transactions on Database Systems, n. 1, p. 9-37, mar. 1976. 
 
2. Codd E. F.;-A relational model of data for large share data banks, 
Communications of the ACM, v. 13-16, p. 377-387, 1970. 
 
3. Damas L.;- SQL, 14ª Edição actualizada, Capítulo 4- Normalização, FCA, 
2017 
 
4. Date C. J;- Introdução a Sistemas de Banco de Dados, tradução da 8ª 
edição americana, LTC, 2004 
 
5. Elmasri R., Navathe S. B.;- Sistemas de Banco de Dados - Fundamentos e 
aplicações, tradução da 6ª edição americana, São Paulo, Pearson Addison 
Wesley, 2011. 
 
6. Filipe F. N. R.;- Projeto e implementação de Banco de Dados, 3ª edição, 
Érica, São Paulo, 2014. 
 
7. Garcia-Molina, Ullman J. D., Widom J.: Database Systems – The Complete 
Book, Department of Computer Science, Stanford University, Prentice-Hall, 
2009 
 
8. Guimarães C. C.,- Fundamentos de Banco de Dados: Modelagem, Projeto 
e Linguagem SQL, 1ª Edição, Editora da UNICAMP, 2003 
 
9. Groff J. R., Wienberg P. N., Oppel A.;- The Complete Reference SQL, 3 th 
Edition, McGraw-Hill, 2010. 
 
10. Heuser C. A.;- Projeto de Banco de Dados, 6ª Edição, Instituto de 
Informática da UFRGS, Porto Alegre, Bookman, 2009. 
 
11. Medeiros L. F.;- Banco de Dados princípios e prática, 1ª Edição, 
InterSaberes, Curitiba, Brasil, 2012. 
 
12. PostgreSQL global development group: Manuais do PostgreSQL, 
http://www.postgresql.org/docs, 
 
http://www.postgresql.org/docs
Introdução as Técnicas de Desenvolvimento de Algoritmos 
 
Para uso exclusivo dos alunos da Faculdade de Engenharia de Universidade Católica de Angola Prof. Manuel Menezes 139 
 
13. Pressman R. S., Maxim B. R.;- Engenharia de Software uma Abordagem 
Profissional, 8ª Edição, AMGH Editora, Porto Alegre, Brasil, 2016. 
 
14. Ramakrishnan R., Gehrke J.;- Sistema de Gerenciamento de Banco de 
Dados, Tradução da 3ª edição americana, São Paulo, McGraw-Hill, 2008. 
 
15. Rob P., Coronel C.;- Sistema de banco de Dados: Projeto, implementação 
e Administração, tradução da 8ª edição americana Edição, Cengage 
Learning, 2010. 
 
16. Setzer W., Silva F. S. C.;- Banco de Dados: Aprenda o que são, Melhore 
seu conhecimento, Construa os seus, 1ª edição, São Paulo, Edgar Blucher, 
2001 
 
17. Setzer W.;- Dado, Informação, Conhecimento e Competência, 
Departamento de Ciências de Computação, Instituto de Matemática 
Estatística, Universidade de São Paulo, 2015 ( 
www.ime.usp.br/~vwsetzer/dado-info.html) 
 
18. Silberschatz A., Korth F. K, Sudarshan S.;- Sistema de Banco de Dados, 
tradução de 5ª edição americana, Rio de Janeiro, Elsevier, 2012 
 
19. Sommerville I.;- Engenharia de Software, 9ª Edição, Pearson, São paulo, 
Brasil, 2011. 
 
20. Teorey T.; Lightstone S.; Nadeau T.; Jagadish H. V.;- Projeto e Modelagem 
de Banco de Dados, tradução da 4ª edição americana Elsevier, 2006 
http://www.ime.usp.br/~vwsetzer/dado-info.html
"O carácter de um homem não está na sua cara, altura, cor 
da pele, força ou posição social. Está rara qualidade só existe 
em homens justos, dignos, que honram as suas raízes, e acima 
de tudo, têm o seu valor. Nada nem ninguém pode comprar 
um homem íntegro e honesto” 
 
- Joaquim Bardosa - 
O que pode encontrar no livro: 
 
 Dado e Informação; 
 Sistema de Gestão de Base de Dados; 
 Fases para Desenho de uma Base de Dados 
 Modelo de Entidade e Relacionamento; 
 Modelo de Entidade e Relacionamento Estendido; 
 Modelo Relacional; 
 Conversão de Modelos; 
 Normalização; 
 Calculo e Álgebra Relacional; 
 Introdução à linguagem SQL; 
 
Manuel Soares de Menezes, é professor auxiliar do 
Departamento de Informática da Faculdade de Engenharia 
da Universidade Católica de Angola. Sua actividade de 
pesquisa tem sido dedicada a Análise e Síntese de Algoritmos. 
 
msoaresdemenezes@ucan.edu 
mailto:msoaresdemenezes@ucan.edu