1 MA banco_de_dados

Prévia do material em texto

Banco de Dados 
 
 
 
 
 
 
Olinda Nogueira Paes Rizzo 
 
 
 
 
 
2 
 
 
SUMÁRIO 
BLOCO 1. INTRODUÇÃO À TECNOLOGIA DE BANCOS DE DADOS ................................................. 3 
BLOCO 2. MODELAGEM CONCEITUAL DE DADOS ........................................................................ 12 
BLOCO 3. MODELO RELACIONAL .................................................................................................. 30 
BLOCO 4 LINGUAGEM SQL ............................................................................................................ 49 
BLOCO 5. SISTEMA GERENCIADOR DE BANCO DE DADOS .......................................................... 68 
BLOCO 6. SISTEMAS AVANÇADOS EM BANCOS DE DADOS ......................................................... 84 
 
 
 
 
3 
 
BLOCO 1. INTRODUÇÃO À TECNOLOGIA DE BANCOS DE DADOS 
Olá! Estamos dando início à disciplina de Bancos de Dados. Neste primeiro bloco, você será apresentado 
aos principais conceitos relacionados a essa tecnologia. Posteriormente, discutiremos a importância dos 
dados e dos sistemas de bancos de dados (BD) para as organizações nos dias atuais, o que justificará a 
relevância deste conteúdo para a área de Tecnologia da Informação. Também estudaremos o ambiente de 
um sistema de BD e faremos uma breve descrição das tarefas desempenhadas pelas pessoas envolvidas 
nele. Bons estudos! 
 
1.1. Conceitos básicos em bancos de dados 
Desde que surgiu o conceito de banco de dados na ciência da computação, bem como toda a tecnologia 
que vem sendo desenvolvida associada a ele, essa área de dados tornou-se muito relevante para o 
crescimento do uso de computadores nas organizações, pois é uma das mais aplicadas dessa ciência. Por 
ser bastante aplicada, é uma área que fica em contato direto com os usuários finais dos sistemas e, 
portanto, é popular, diferentemente de outras áreas menos acessíveis da computação. Praticamente, 
todos os sistemas desenvolvidos para as mais diferentes aplicações utilizam algum tipo de banco de dados. 
Por ser popular, muitas vezes as pessoas empregam o termo “banco de dados” de maneira equivocada, 
pois ele é comumente utilizado para definir três diferentes conceitos relacionados a essa tecnologia. A 
seguir, esses conceitos serão apresentados com a intenção de esclarecer alguns pontos e evitar que sejam 
confundidos: 
1. Banco de Dados (BD): este primeiro conceito é o mais simples de todos e representa um conjunto de 
dados relacionados e acessíveis. Dados são fatos do mundo real, que podem ser registrados e organizados. 
Considere, por exemplo, nomes, telefones e e-mails de pessoas que você conhece e que estão 
armazenados em sua agenda do celular. Esses dados estão relacionados entre si, afinal você só gravará 
dados de pessoas que conhece ou que de alguma forma lhe interessam ou possuem algum significado para 
você. Esses dados de pessoas estão armazenados em algum dispositivo de onde você pode acessar a 
qualquer momento que desejar. A agenda é um banco de dados. 
 
2. Sistema Gerenciador de BD (SGBD ou Database Management System – DBMS): este segundo conceito 
representa um tipo de sistema composto por uma série de ferramentas criadas especificamente para 
gerenciar os bancos de dados, e que apresentam linguagens utilizadas para manter os bancos de dados. 
 
 
 
4 
 
3. Sistema de BD: já este terceiro conceito representa todo sistema desenvolvido com funções ou 
aplicações específicas, que utilizam bancos de dados e, por sua vez, foram desenvolvidos em algum SGBD. 
É sinônimo de sistema de informação. 
 
Segundo Elmasri e Navathe (2018), um banco de dados possui algumas propriedades implícitas: 
 representa aspectos de uma parte do mundo real, chamada de Mini-Mundo (ou Universo de 
Discurso); 
 é uma coleção lógica e coerente com algum significado inerente; e 
 é projetado, construído e povoado por dados, atendendo a uma finalidade específica, para ser usado 
por pessoas específicas e por aplicações específicas. 
 
A Figura 1.1 representa o processo de modelagem do Mini-Mundo, que é algo irregular, num banco de 
dados que deve ser algo bastante estruturado. A tarefa de modelar um banco de dados a partir de uma 
parte do mundo real é apenas a primeira de muitas tarefas que compõem o processo de construção de um 
banco de dados. 
 
Figura 1.1: Ilustração da modelagem de dados entre o mundo real e o BD. 
Fonte: Elaborada pela autora. 
 
De forma bastante simplificada, o processo de criação de um BD poderia ser explicado da seguinte 
maneira: a partir da descrição detalhada dos requisitos de dados do sistema, feito pelo analista de 
sistemas, é construído o primeiro modelo conceitual de dados. Posteriormente, o projetista de dados faz a 
construção do projeto físico de dados, para somente depois o banco de dados ser de fato implementado 
pela equipe de programadores num SGBD. Todo esse processo será devidamente explicado ao longo da 
disciplina. 
 
 
 
 
 
5 
 
1.2. A importância dos bancos de dados nas organizações 
Os dados estão presentes na vida dos seres humanos desde que surgiu a linguagem e começamos a nos 
comunicar e registrar os fatos. Desde que começamos a nomear objetos e diferenciar as pessoas por seus 
nomes, começamos a atribuir diferentes dados ou diferentes valores a esses objetos e pessoas. Essa 
diferenciação feita aos objetos e pessoas do mundo precisa de alguma forma estar organizada para ser 
compreendida. 
Por muitos anos, a organização dos dados foi feita pelos seres humanos e registrada de forma manual. 
Inicialmente por desenhos nas paredes das cavernas, posteriormente em papel, até finalmente chegar ao 
registro automatizado dos dados nos computadores, como é feito hoje. Mas desde que surgiu algum tipo 
de registro e organização dos dados, e que estes estiveram ao acesso de outras pessoas, podemos dizer 
que surgiu um arquivo ou um banco de dados. 
O fato é que o imenso volume de dados com o qual atualmente as pessoas e as empresas precisam lidar é 
imensamente maior do que há alguns anos. 
Segundo Elmasri e Navathe (2018), os bancos de dados são um componente essencial na sociedade 
moderna, pois a maioria das pessoas encontra diariamente diversas atividades que envolvam alguma 
interação com algum banco de dados, por exemplo, quando vamos sacar dinheiro no caixa eletrônico, ou 
fazer uma compra no supermercado, ou até quando vamos fazer uma consulta online sobre um 
determinado assunto. 
Já nas organizações, de uma maneira geral, praticamente todos os processos passam por algum tipo de 
sistema de informação computacional, que por sua vez interage com um banco de dados. Segundo 
Medeiros (2013), os sistemas de informação estão na atualidade profundamente arraigados nas empresas. 
Como estamos na era da informação, portanto, não poderia ser diferente. 
É muito difícil nos dias atuais encontrarmos uma empresa que ainda contenha algum tipo de processo ou 
procedimento que possa ser realizado de maneira independente de um sistema computacional, mesmo 
porque há a necessidade de um controle de todas as ações dos funcionários e isso se dá através do 
monitoramento dos sistemas. Isso faz com que uma imensa quantidade de dados seja gerada 
instantaneamente e diariamente no mundo e esse movimento ininterrupto vai acumulando um volume 
gigantesco de dados. 
Além disso, todas as informações geradas nas últimas décadas das organizações ficaram armazenadas nos 
sistemas das empresas para fins de dados históricos, para construção de Data Warehouses, dentre outras 
aplicações. Isso ampliou ainda mais o enorme volume de dados armazenados. Diante desse cenário, 
podemos então perceber que atualmente temos uma quantidade de dados armazenados como nunca 
 
 
 
6 
 
houve na história da humanidade e muito provavelmente essa quantidade tende a continuar aumentando 
nos próximos anos. 
A tecnologia que apoia e mantém essa gigantesca quantidade de dadosé a tecnologia de bancos de dados, 
que evoluiu desde seu surgimento, mas que se manteve em sua estrutura inicial de forma a simplificar ao 
máximo o trabalho das pessoas envolvidas na área de gerenciar e manipular os dados. 
Diante desse cenário, onde percebemos nitidamente a importância que as informações (e 
consequentemente os dados) têm nas nossas vidas, faz-se necessário conceituar claramente o que é um 
banco de dados. Nas próximas seções, entenderemos os principais conceitos dessa tecnologia e quem são 
as pessoas diretamente envolvidas nessa área. 
 
1.3. O ambiente de um sistema de BD 
Para melhor compreendermos os conceitos básicos associados à tecnologia de Banco de Dados (BD), vale 
observarmos a Figura 1.2, que representa de forma resumida o ambiente de um sistema de banco de 
dados. 
 
Figura 1.2: Diagrama simplificado de um ambiente de sistema de banco de dados. 
Fonte: Elmasri e Navathe (2018). 
 
 
 
7 
 
 
Interpretando a Figura 1.2, podemos observar que as pessoas (programadores e usuários) interagem com 
os sistemas de bancos de dados através de programas de aplicação. Esses programas de aplicação podem 
ser construídos pelos programadores em diferentes tipos de linguagem de programação, para serem 
usados pelos usuários em diferentes tipos de dispositivos, para diferentes ambientes da empresa. Por 
exemplo, pode acessar o mesmo sistema de banco de dados uma aplicação voltada para os funcionários 
que é acessada somente na intranet da empresa, outra aplicação voltada para os clientes pode ser 
acessada através da internet pelo site da empresa, dentre outras. 
Os programas de aplicação realizam consultas (do inglês, queries) no BD. Uma query executada no BD irá 
realizar alguma ação de manipulação nos dados, por exemplo: ler (recuperar) os dados que estão 
cadastrados no banco, ou alterar (inserir, remover ou modificar) os dados. 
Podemos também observar que há uma camada intermediária entre as aplicações e os BD propriamente 
ditos, que é o Sistema Gerenciador de BD (SGBD). O SGBD recebe as consultas feitas pelos usuários, 
enviadas pelas aplicações e as processa, repassando a programas específicos a função de buscar os dados 
desejados nos bancos de dados. 
De maneira simplificada, podemos separar os arquivos que armazenam os dados em dois grandes grupos: 
num primeiro estão os dados armazenados, ou os dados propriamente ditos, ou seja, os valores relativos 
aos fatos do mundo real que foram cadastrados; num segundo grupo ficam contidas as definições dos 
dados ou os metadados, que são informações sobre a estrutura do BD, tais como qual é o tipo de valor que 
aquele dado pode conter (numérico ou alfabético). Essa separação é feita porque a estrutura dos dados, 
uma vez definida na fase de projeto do BD, pouco irá mudar ao longo da utilização desse sistema de banco 
de dados, enquanto os dados armazenados são alterados constantemente no dia a dia das organizações. 
Por esse motivo, o SGBD gerencia e mantém esses dois grupos de arquivo de maneira diferente. 
O mais importante de fixar dessa imagem que representa o ambiente de um sistema de banco de dados é 
a importância que os SGBD têm para facilitar o desenvolvimento de aplicações que acessam os BDs, uma 
vez que fazem todo o processamento intermediário entre as consultas enviadas nas diversas linguagens de 
programação e os BDs armazenados. 
 
1.4. Características básicas dos SGBD 
Antes de serem criados os primeiros SGBD, pelo menos até a metade da década de 1970, os sistemas 
computacionais existentes utilizavam, de forma muito restrita, as estruturas de arquivos disponíveis nos 
Sistemas Operacionais (SO) da época para gerenciar os seus dados. Essa era uma tarefa muito complexa e 
 
 
 
8 
 
restrita, pois se tinha que conhecer muito bem o sistema de gerenciamento de arquivos e de memória do 
SO, e para cada nova aplicação que surgisse, toda a lógica de manipulação dos dados tinha que ser refeita. 
Então, quando os primeiros SGBD foram implementados, eles tinham de cumprir o objetivo de solucionar 
os principais problemas enfrentados pelos programadores da época. 
Assim, segundo Elmasri e Navathe (2018), os SGBD foram criados contendo as seguintes principais 
características, que são mantidas até os dias atuais: 
- Natureza autodescritiva de um sistema de BD: visava solucionar o problema da dependência dos 
sistemas de BD desenvolvidos em linguagens de programação da época de outros sistemas, tais como o 
Sistema Operacional. Desejava-se um sistema que fosse independente dos demais e, portanto, ele 
precisava conter nele mesmo todas as informações necessárias para seu funcionamento. A tecnologia de 
BD para solucionar esse problema implementou o chamado catálogo do banco de dados, que armazena o 
esquema do banco e todas as informações necessárias para funcionamento do SGBD, sem dependência de 
outros tipos de programas. A informação armazenada no catálogo do BD é chamada de metadados 
(informações sobre os dados). Com todas as informações necessárias para seu funcionamento contidas no 
próprio SGBD, ressaltando a sua natureza autodescritiva, esse sistema tornou-se independente dos 
demais. 
- Isolamento entre programas e dados, e abstração de dados: antes dos SGBD, no processamento 
tradicional que utilizava os arquivos, a estrutura do arquivo, sua localização física e outros detalhes de 
armazenamento estavam embutidos nos programas de aplicação. Assim, qualquer mudança na estrutura 
dos dados refletia mudanças em todos os programas de aplicação. Essa era uma tarefa muito complexa e 
exigia muito esforço da equipe de desenvolvimento de software. Já os SGBD oferecem uma abstração dos 
dados, armazenando as estruturas (ou definição) dos dados no seu catálogo, enquanto os dados 
propriamente ditos ficam armazenados separadamente. Quando a estrutura dos dados muda, apenas uma 
parte do SGBD é acionada para ser modificada. Já todos os programas de aplicação que utilizam os bancos 
de dados não são alterados. Isso facilita muito o trabalho da equipe de desenvolvimento de software e cria 
um isolamento entre os programas e os dados propriamente ditos. 
- Conceito de abstração dos dados: um modelo de dados é usado para esconder detalhes de 
armazenamento, com uma visão conceitual do BD (ELMASRI e NAVATHE, 2018). 
- Suporte a múltiplas visões dos dados: um banco de dados típico tem muitos usuários e cada qual possui 
interesses diferentes, que podem solicitar diferentes perspectivas ou visões dos dados no BD. O SGBD é 
capaz de suportar diferentes visões dos dados, a depender do usuário, somente as que interessam. Isso é 
importante tanto para simplificar para o usuário quanto por motivos de segurança, uma vez que certos dados 
 
 
 
9 
 
não serão disponibilizados a usuários não autorizados. Uma visão (ou do inglês, view) pode ser um 
subconjunto dos dados do BD ou conter dados virtuais, temporários e derivados de arquivos físicos do BD, 
mas que não estão armazenados explicitamente. 
- Compartilhamento de dados e processamento de transação multiusuário: um SGBD multiusuário é aquele 
que permite o acesso ao BD, feito por diversos usuários diferentes, ao mesmo tempo (concorrentemente), 
ou seja, os usuários irão concorrer pelos recursos daquele BD. Para que esse compartilhamento de dados 
entre os usuários funcione sem problemas, o SGBD deverá realizar um controle dessa concorrência, 
enquanto realiza o processamento das várias transações que são enviadas ao mesmo tempo. Então, todo 
SGBD multiusuário possui um módulo de controle de concorrência para garantir que as transações sejam 
executadas da maneira correta e eficiente. 
 
1.5. Pessoas envolvidas com BD 
Como já discutimos, os BDs estão em toda parte, sendo utilizados por praticamente todas as pessoas de 
alguma forma. Nesta seção, entretanto, estudaremos as pessoas que estão mais diretamente envolvidas 
com o processo de criação, manipulação e gerenciamento dosbancos de dados nas organizações. 
Para um pequeno BD individual, como no exemplo da agenda de contatos do seu celular, em geral apenas 
uma pessoa constrói e manipula os dados, não havendo o seu compartilhamento com outras pessoas. 
Porém nas organizações, onde centenas ou milhares de usuários irão acessar o BD, geralmente existe um 
grupo grande de pessoas envolvidas com essa tecnologia e que trabalham em seu dia a dia com os bancos 
de dados. 
Segundo Elmasri e Navathe (2018), as pessoas mais diretamente ligadas ao trabalho de projetar, criar, 
implementar, gerenciar e manipular os dados são apresentadas a seguir. 
Os usuários finais são pessoas cujas profissões requerem o acesso constante a um sistema de BD para 
consulta, atualização e emissão de relatórios. Esse acesso se dá através do uso de sistemas de aplicação, 
que são construídos sobre os SGBD, ou seja, os usuários finais não irão acessar os bancos de dados 
diretamente pelo SGBD, mas sim por sistemas construídos para eles. A aplicação e o BD existem 
prioritariamente para os seus usuários, por isso eles são muito importantes e considerados os verdadeiros 
“donos” do BD. Quando os projetistas e analistas de BD estão realizando o seu trabalho, eles interagem 
com esses usuários finais para conhecê-los e devem levar em consideração o fato de que, muitas vezes, os 
usuários são pessoas com pouca familiaridade com a tecnologia de BD. O diálogo entre o analista de 
sistemas e os usuários finais deve ser feito da maneira mais clara e facilitada possível, para que as 
 
 
 
10 
 
necessidades informacionais dos usuários sejam traduzidas corretamente como os requisitos de dados do 
sistema. 
Os analistas de sistemas e os programadores de aplicações (engenheiros de software) são as pessoas que 
determinam e implementam as especificações das transações customizadas para atender às necessidades 
dos usuários. O trabalho de análise do sistema tem início no diálogo entre os usuários e o analista, que 
resulta numa lista de requisitos de dados do sistema. Esses requisitos serão utilizados para a construção do 
primeiro modelo abstrato dos dados, o modelo conceitual, que é a primeira etapa no processo de criação 
de um BD. Em paralelo a esse trabalho, também são projetadas as transações que serão programadas e, 
posteriormente, testadas e documentadas, até serem colocadas em ação no sistema, quando se inicia a 
fase de utilização e manutenção. Uma vez que o sistema esteja sendo utilizado, enquanto ele existir, 
sempre terá que ser mantido pela equipe de engenharia de software. 
Os projetistas do banco de dados são responsáveis pela identificação dos dados que serão armazenados 
no BD e também por escolher as estruturas apropriadas para representar esses dados (modelo físico). Eles 
recebem o modelo conceitual criado pelos analistas de sistemas que o transformam num modelo físico, 
geralmente utilizando tabelas, já pensando em como esse BD será implementado num SGBD. Os 
projetistas também interagem com os potenciais usuários dos sistemas de BD e criam as visões que 
atendem aos requisitos desses usuários. O projeto final do BD, que é o resultado final do trabalho dos 
projetistas, deve ser capaz de suportar todos os requisitos de todos os grupos de usuários dos sistemas. 
Até esse momento, o BD ainda não foi de fato criado no SGBD, ele ainda está em fase de projeto. 
O administrador de bancos de dados, ou como é mais conhecido por sua sigla DBA (do inglês, DataBase 
Administrator), é o administrador-chefe de todos os recursos que envolvem o banco de dados, os SGBD e 
outros sistemas relacionados. O DBA é responsável pela autorização para o acesso ao BD, por questões de 
segurança e desempenho do SGBD, pela coordenação e monitoração do uso do BD, por adquirir recursos 
de software e hardware conforme necessidade, e por mais uma longa série de tarefas. Por ser a pessoa 
mais importante na área de BD nas organizações, o DBA será estudado com mais detalhes a seguir. 
Nós vimos aqui uma lista de pessoas que interagem diretamente com a tecnologia de bancos de dados e 
que realizam tarefas distintas, porém é muito comum encontrar em empresas, principalmente de pequeno 
e médio porte, uma única pessoa desempenhando os papéis de todas essas diferentes funções. Nesse 
caso, é muito importante que essa pessoa saiba diferenciar cada uma das tarefas que estiver 
desempenhando no momento adequado, seguindo as etapas do processo de criação do BD corretamente, 
sem pular ou eliminar nenhuma etapa, para garantir a qualidade final do BD criado. 
 
 
 
11 
 
Resumidamente, a função de administrar um BD comporta as tarefas de: instalar, configurar, monitorar e 
solucionar problemas que possam surgir com a utilização de um SGBD específico. Geralmente, para ser 
considerado um DBA de um SGBD específico, o mercado de trabalho exige uma certificação específica 
concedida pela empresa fabricante do SGBD. 
Detalhando um pouco mais as funções desempenhadas no cotidiano de um DBA, temos: a criação, ou pelo 
menos, o conhecimento do esquema lógico do BD; a definição de checagem de segurança e integridade 
dos dados; a tomada de decisões de como os dados são representados na base de dados armazenados; a 
definição, ou pelo menos, o conhecimento do projeto físico do BD; a definição de procedimentos de 
recuperação dos dados em caso da ocorrência de falhas; o monitoramento diário das ações dos usuários e 
o monitoramento diário do desempenho do SGBD; o contato com usuários para averiguação de 
disponibilidade dos dados por eles requisitados e ajuda na determinação e resolução de problemas; e os 
ajustes apropriados à medida que ocorram mudanças de requisitos. 
 
Considerações Finais 
Ao longo deste bloco, você aprendeu que o conceito de Banco de Dados (BD), de maneira bastante 
simplificada poderia ser conjunto de dados relacionados e acessíveis, que representa a qualquer momento 
os dados de uma parte do mundo real, de forma abstrata. Também conhecemos o conceito de Sistema 
Gerenciador de Banco de Dados (SGBD), que como o seu próprio nome já indica, é um sistema construído 
com a intenção de facilitar o gerenciamento dos BD e auxiliar as tarefas das pessoas que trabalham nessa 
área. Todo sistema desenvolvido para alguma aplicação específica e que utiliza um banco de dados é 
chamado de Sistema de BD e é utilizado no dia a dia pelos usuários finais. 
Nós observamos a grande importância que os dados e os sistemas de bancos de dados possuem para as 
organizações nos dias atuais, o que torna essa uma das áreas mais populares na ciência da computação. 
Nesse cenário, para quem trabalha na área de Tecnologia da Informação, é muito importante entender em 
vias gerais como é o ambiente de um sistema de banco de dados. 
Por fim, foram apresentadas as pessoas envolvidas diretamente com a tecnologia de BD, dando um maior 
destaque à figura do DBA que é o maior responsável por realizar as principais tarefas no SGBD e por 
garantir a integridade dos dados no BD. 
 
Referências 
AMADEU, Claudia V. Banco de Dados. São Paulo: Pearson, 2015. 
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de bancos de dados. 7. ed. São Paulo: Pearson, 2018. 
 
 
 
12 
 
MEDEIROS, Luciano F. Banco de Dados, princípios e prática. Curitiba: InterSaberes, 2013. 
 
 
BLOCO 2. MODELAGEM CONCEITUAL DE DADOS 
Olá! Continuando o nosso estudo na área de banco de dados, agora chegou o momento de 
compreendermos como é o processo de criação de um modelo de dados, a partir da demanda por 
informações em um sistema. 
O bloco atual apresentará as principais etapas do processo de construção de um Banco de Dados (BD), 
dando uma maior ênfase à etapa inicial de modelagem conceitual, introduzindo o modelo Entidade-
Relacionamento. Também será apresentada a ferramenta CASE DBDesigner, que é de código aberto e 
pode ser livremente utilizada para auxiliar nessa tarefa de projeto de BD. Por fim, discutiremos como o 
modelo ERpode ser estendido para um modelo mais atual e flexível, o modelo EER. Bons estudos! 
 
2.1. Projeto de banco de dados 
É muito importante compreender como ocorre todo o processo de construção de um banco de dados, 
iniciando-se com o trabalho do analista de sistema em conjunto com os usuários finais e dando como 
resultado o primeiro modelo conceitual de dados, até as etapas seguintes, que gradativamente vão 
passando pelo projeto, até a implementação do banco de dados num SGBD. 
Uma das principais características da tecnologia de banco de dados é a possibilidade de abstração dos 
dados, onde um modelo que esconde detalhes de como os dados estão fisicamente armazenados pode ser 
criado, facilitando assim a tarefa de programar aplicações para manipular esses dados. 
Formalmente, podemos definir um modelo de dados como um conjunto de conceitos usados para 
descrever a estrutura do BD e certas restrições, que o sistema deve garantir (ELMASRI e NABATHE, 2018, 
p.11). Em outras palavras, uma notação gráfica é criada para representar dados do mundo real, de forma a 
desenhar ou projetar uma estrutura para o banco de dados. A estrutura do banco de dados é definida 
durante o trabalho de projeto do BD. Além das estruturas dos dados, nesse projeto também podem ser 
colocadas informações referentes a algumas restrições impostas ao BD, que são extraídas dos usuários 
finais, a partir do trabalho de análise do sistema. 
Por exemplo, imagine um sistema de banco de dados que será desenvolvido para uma empresa que 
pretende armazenar os dados relativos aos seus funcionários e aos departamentos onde estes atuam. Após 
o trabalho de projeto, poderíamos chegar à definição da seguinte estrutura para os dados dos 
funcionários: 
 
 
 
13 
 
 
FUNCIONARIOS CPF_Func Nome_Func Endereco_Func ... mais algumas colunas ... Codigo_Dep_Func 
 
 
Para esse exemplo, poderíamos ter a seguinte restrição: todo funcionário dessa empresa obrigatoriamente 
tem que estar vinculado a um departamento. Ou seja, quando os dados dos funcionários forem inseridos 
no BD, o campo “Codigo_Dep_Func”, que determina qual é o departamento ao qual o funcionário está 
vinculado, não poderá estar em branco (esse é um campo obrigatório). 
Tanto as estruturas dos dados quanto as restrições impostas a esses dados são definidas num modelo de 
dados. Existem diferentes categorias de modelos de dados. São elas: 
 Modelo Conceitual (resultado da etapa de projeto conceitual): esse modelo é construído com 
base em conceitos tais como entidades ou objetos. É a primeira etapa do processo de 
modelagem de bancos de dados. Descreve a estrutura dos dados de maneira abstrata sem se 
preocupar em como será a sua futura implementação física. 
 Modelo Lógico (resultado da etapa de projeto lógico ou mapeamento do modelo de dados): é 
um modelo gerado a partir do modelo conceitual, numa etapa intermediária do processo, 
quando o primeiro modelo é mapeado para o modelo físico (ou de implementação). Nessa etapa, 
um SGBD específico a ser utilizado já deve ser definido para determinar qual será a linguagem de 
programação utilizada na próxima etapa. Vale ressaltarmos que se houver algum tipo de erro 
cometido na etapa anterior de modelagem conceitual, o modelo lógico também terá esse erro 
refletido. 
 Modelo Físico (resultado da etapa de projeto físico): esse modelo descreve os aspectos físicos 
de implementação. É a criação propriamente dita do banco de dados, utilizando uma linguagem 
específica de um SGBD. 
 
A Figura 2.1 ilustra de maneira simplificada as principais fases do projeto de um banco de dados. Nela, 
podemos observar todo o processo que se inicia com a definição do Mini-Mundo, que é a parte do mundo 
real que será modelado, até o último passo que é a criação dos programas de aplicação que serão voltados 
aos usuários finais e irão utilizar os dados gerenciados pelo SGBD. 
Ao longo do processo, cada etapa vai evoluindo para passos mais avançados, desde aquele mais próximo 
das pessoas, como o levantamento e a análise de requisitos feita pelos analistas, projetistas e usuários, até 
 
 
 
14 
 
a construção dos modelos: conceitual, lógico e físico gradativamente. Algumas dessas etapas iniciais são 
realizadas independentemente do modelo de implementação e do SGBD, e outras, as finais, dependem da 
escolha por um SGBD específico. 
Na Figura 2.1, também surgem alguns conceitos, como o de esquema de um BD, que é a descrição da 
estrutura de um BD e pode ser textual, por exemplo, através da definição de comandos em uma linguagem 
de programação, ou gráfico, por exemplo, através do desenho de símbolos que representam tabelas ou 
conjuntos de dados. 
Os modelos conceituais descrevem o esquema conceitual do BD usando, por exemplo, o modelo Entidade-
Relacionamento (ER). Os modelos lógicos ou de implementação descrevem os esquemas externos, que 
usam, por exemplo, o modelo Relacional. Nesses modelos, um SGBD já deve estar sendo definido para ser 
utilizado posteriormente, pois a depender dessa escolha, o projeto será diferente. Por exemplo, se o SGBD 
escolhido for o SQLServer da Microsoft, que é originalmente relacional, o projeto lógico do BD será criado 
baseando-se na estrutura de relações ou tabelas; mas se por outro lado o SGBD escolhido for o 
PostgreSQL, que tem como teoria a Orientação a Objetos, o projeto lógico do BD será criado baseando-se 
na estrutura de objetos, classes etc. 
Outro conceito da área de modelagem em banco de dados é o de instância de um banco de dados, que se 
refere aos dados atuais armazenados num determinado momento, também chamado estado do BD. Ou 
seja, o estado do BD num determinado momento é como se fosse tirada uma foto dos dados contidos no 
BD naquele momento específico. Todos os dados que estão cadastrados num banco de dados num 
determinado instante, ou as suas instâncias, determinam o seu estado naquele momento. 
 
 
 
 
15 
 
 
Figura 2.1: Um diagrama simplificado para ilustrar as principais fases do projeto de um banco de dados 
(ELMASRI e NAVATHE, 2018, p. 57). 
 
Então, podemos refletir que o processo de construção de um banco de dados é gradativo, que se inicia 
com a intervenção dos analistas de sistemas e os usuários finais do sistema, que juntos definem os 
requisitos de dados. A partir dessa definição inicial, o primeiro modelo conceitual é construído e, 
posteriormente, é utilizado como base na construção dos modelos posteriores (projetos lógico e físico). Se 
ocorrer um erro de modelagem na etapa inicial desse processo, muito provavelmente todo o processo 
estará comprometido. Por esse motivo, considera-se a etapa inicial de modelagem conceitual de dados tão 
importante. 
Vale também ressaltarmos a importância de que nesse processo nenhuma etapa seja ignorada, ou seja, 
não se deve pular nenhuma etapa, por mais experiente que seja a equipe de desenvolvimento de BD. 
Todas as etapas são importantes. Uma dessas etapas é a de mapeamento do modelo de dados, que traduz 
o modelo conceitual, num modelo lógico. 
 
 
 
16 
 
A Figura 2.2 mostra um exemplo ilustrativo do mapeamento de modelos de dados: do modelo conceitual 
(ER) e seu equivalente no modelo lógico (Relacional). 
 
Figura 2.2: Exemplos de modelos conceitual e lógico. 
Fonte: Elaborada pela autora. 
 
 
2.2. Principais conceitos do modelo ER 
Segundo Ramakrishnan e Gehrke , o modelo de dados n dade- elacionamento é u lizado para 
descrever os dados envolvidos no co diano de uma empresa do mundo real em termos de objetos ou 
en dades e seus relacionamentos. sse modelo é amplamente u lizado para desenvolver um projeto inicial 
de BD e fornece conceitos úteis que nos possibilitam mover de uma descrição informal do que os usuários 
desejam de seu BD, para uma descrição mais detalhada e precisa do que pode ser implementado num SGBD. 
Como vimos, o processo de construção de um BD é gradativo e a modelagem conceitual de dadosé uma das 
etapas iniciais. Do resultado dessa modelagem depende o sucesso ou não de todo o restante do processo, 
fazendo com que a modelagem conceitual seja então uma das principais tarefas a serem desenvolvidas por 
pessoas dessa área. 
A partir da modelagem, faz-se o projeto que é a base para a posterior implementação. Sem essa tarefa, é 
impossível o trabalho do administrador de BD. A seguir, serão apresentados conceitos sobre modelagem e 
projetos de BD, utilizando o modelo conceitual Entidade-Relacionamento (ER). 
 
 
 
17 
 
Tanto o projeto conceitual quanto posteriormente o projeto físico, para serem desenvolvidos, precisam de 
informações sobre as especificações das operações básicas feitas pelos usuários. Os projetistas e analistas de 
BD trabalham em conjunto com os usuários no levantamento dos requisitos de dados. 
O modelo conceitual Entidade-Relacionamento (ER) é formado por desenhos gráficos, que possuem algum 
significado e representam elementos do mundo real a serem modelados. Os dois principais conceitos desse 
modelo, como pode ser observado por seu nome, são os conceitos de Entidade e de Relacionamento. 
A Figura 2.3 apresenta a principal simbologia utilizada no modelo ER e seu significado. 
 
Figura 2.3: Notação do modelo ER (parte 1) 
Fonte: Adaptada de Elmasri e Navathe (2018, p. 76). 
 
Entidade ou Tipo de entidade: é representado graficamente por um retângulo, é o conjunto formado por 
instâncias de dados, ou seja, é um conjunto de dados relacionados a um conceito único, que serão gravados 
no BD. 
Entidade fraca é representada graficamente por um retângulo de traço duplo. É um tipo de entidade, mas 
com a característica de que os dados de suas instâncias são dependentes de dados de outra entidade, ou 
seja, os dados dessa entidade só existem se existirem dados numa outra entidade. 
Relacionamento ou Tipo de relacionamento: é representado graficamente por um losango. Refere-se a ações 
que interagem com os elementos das entidades. 
Relacionamento de identificação: representado graficamente por um losango de traço duplo, é um 
relacionamento que liga algum tipo de entidade fraca, que é identificada por outra entidade. 
 
 
 
18 
 
Atributos: representados graficamente por uma circunferência, são características comuns às instâncias que 
formam entidades. 
 m outras palavras, as entidades são elementos ou objetos ou “coisas” do mundo real que possuem uma 
existência independente e são de interesse para uma determinada aplicação. As entidades são, por exemplo, 
os clientes de uma loja, os produtos que ela comercializa, os funcionários que nela trabalham etc., ou seja, 
todos os elementos da loja no mundo real, que para a aplicação que será desenvolvida possuem algum tipo 
de importância e seus dados precisam ser cadastrados no banco de dados. 
Os atributos são propriedades usadas para descrever cada uma das entidades. Por exemplo, na entidade dos 
Funcionários: 
 
Os atributos podem ser dos seguintes tipos: simples, o que chamamos somente de atributos e geralmente 
são formados por um só conjunto de caracteres ou números; ou podem ser atributos compostos, que são 
formados por vários atributos simples, por exemplo: Endereco = rua + numero + bairro + cidade + UF + CEP. 
Os atributos também podem ser monovalorados, que é o tipo mais comum, quando cada atributo possui 
uma instância, ou pode ser do tipo multivalorado, quando um atributo pode possuir várias instâncias, por 
exemplo, um departamento de uma empresa localizado em diversas cidades é representado pelo uso de 
traço duplo no atributo. 
A Figura 2.4 apresenta de forma gráfica como esses diferentes tipos de atributos são representados no 
modelo ER. 
 
 
 
19 
 
 
Figura 2.4: Notação do modelo ER (parte 2) 
Fonte: adaptada de Elmasri e Navathe (2018, p. 76). 
 
A Figura 2.4 também apresenta o conceito de atributo derivado (representado com tracejado), que se refere 
aos atributos cujos valores não ficam armazenados no BD, mas sim esses dados são calculados durante a 
execução da aplicação, ou sempre que necessário. No caso do exemplo, seria a quantidade de Funcionários 
de um determinado departamento, que é uma conta que seria feita num momento. 
Outro conceito é o de atributo-chave. As chaves são identificadores de um tipo de entidade, ou, em outras 
palavras, um atributo de um tipo de entidade que possui um valor único para cada entidade é chamado de 
chave. Por exemplo, o número de CPF de um funcionário, por ser um valor que não pode se repetir para mais 
de uma pessoa, quando dado, conseguimos identificar o funcionário. A chave é representada pelo nome do 
atributo sublinhado. 
Uma chave pode ser um atributo simples, ou um atributo composta. Se for composto, temos o conceito de 
chave composta, que é formada pela combinação de vários atributos. Um tipo de entidade pode possuir uma 
chave simples, ou uma chave composta, ou várias chaves simples (distintas), ou várias chaves compostas. 
O conceito de chave foi introduzido em 1976 por Peter Chen, para identificar uma instância, porém a chave 
deve ser vista de uma forma mais ampla, como uma restrição de integridade. Para o conceito de chave, 
devemos entender que a instância é única. A restrição de integridade nesse caso é a garantia de que se um 
atributo é chave, não pode haver no BD mais de um atributo com o mesmo valor para aquele atributo. Por 
exemplo, se numa escola temos que a matrícula dos alunos é um valor único, este é chave. Se ocorrer no BD 
 
 
 
20 
 
dois alunos com o mesmo número de matrícula, esse valor estaria repetido. Sendo assim, estaria ferindo a 
restrição de integridade do BD. 
Além desses conceitos apresentados na Figura 2.4, há o conceito de domínio de um atributo, que se refere 
ao conjunto de valores que cada atributo de um tipo de entidade possui, ou seja, o domínio define os valores 
que podem ser assumidos por esse atributo, para cada entidade individualmente. Por exemplo, suponha que 
o atributo “nome” possua o domínio definido para um conjunto de caracteres alfabéticos de no máximo . 
Isso significa que só poderão ser colocados no banco de dados nomes formados por no máximo 200 letras. 
Outro exemplo é o atributo CPF formado por um conjunto de caracteres numéricos de tamanho fixo 11. 
Nesse caso, só poderemos cadastrar CPFs com tamanho exato de 11 números. 
Dois atributos podem ter o mesmo domínio, mais amplo, como por exemplo: na entidade FUNCIONARIOS, os 
atributos TelefoneResidencial e TelefoneComercial podem possuir o mesmo domínio amplo dos números de 
telefone; e DataNascimento e DataAdmissao possuem o mesmo domínio amplo das datas. 
Já estudamos aspectos e características referentes aos conceitos de entidades e de atributos. Falemos agora 
dos relacionamentos. 
Relacionamentos ou tipos de relacionamentos são associações entre duas ou mais entidades distintas (ou 
instâncias da entidade), com um determinado significado. Graficamente representados por losangos ligando 
as entidades e seus nomes, geralmente são verbos, já que significam uma ação entre elementos de uma 
entidade e seu relacionamento com elementos da outra entidade. 
Por exemplo: FUNCIONARIO João TRABALHA_EM DEPARTAMENTO Pesquisa 
 
Figura 2.5: Exemplo simplificado de relacionamento. 
Fonte: Elaborada pela autora. 
 
As entidades participantes de um relacionamento atuam com um determinado papel nesse relacionamento. 
O significado desse papel é dado por um nome a ele atribuído. Um relacionamento é dito recursivo, também 
conhecido como autorrelacionamento, quando este relaciona uma única entidade, através de dois papéis 
distintos. Por exemplo: 
 
 
 
21 
 
 
Figura 2.6: Exemplo de autorrelacionamento ou relacionamento recursivo. 
Fonte: Elaborada pela autora. 
 
Além das estruturas básicas já explicadas do modelo ER, existem algumas restrições impostas sobre tipos de 
relacionamento. As restrições mais importantes são a relação de cardinalidadee a relação de participação. 
Juntas, as restrições de cardinalidade e de participação formam as restrições estruturais do modelo ER, que 
determinam a quantidade mínima e máxima de elementos das entidades que participam do relacionamento. 
A relação de cardinalidade especifica o número de instâncias de um tipo de entidade que pode participar do 
relacionamento. Um relacionamento pode ser: 1 para 1 (1:1), 1 para N (1:N), N para 1 (N:1) ou N para N 
(N:N). 
A Figura 2.7 apresenta a forma gráfica de representação dos conceitos de participação, cardinalidade e 
restrição estrutural. 
 
Figura 2.7: Notação do modelo ER (parte 3) 
Fonte: adaptada de Elmasri e Navathe (2018, p. 76). 
 
 
 
 
22 
 
No relacionamento 1:1 apenas um elemento da entidade pode se relacionar com apenas 1 elemento da 
outra entidade envolvida no relacionamento. Por exemplo, supondo que exista um relacionamento chamado 
“chefia” entre a entidade FUNCIONA IOS e a entidade D PA TAM NTOS, onde apenas um funcionário pode 
gerenciar um único departamento e um departamento pode ter apenas um único chefe. O relacionamento 
“chefia” é do tipo 1:1. 
No relacionamento 1:N ou N:1, ou um para muitos, um elemento da entidade pode se relacionar com vários 
elementos da outra entidade envolvida no relacionamento, por exemplo, supondo que exista um 
relacionamento chamado “trabalha_em” entre a entidade FUNCIONARIOS e a entidade DEPARTAMENTOS, 
onde um funcionário pode trabalhar em apenas 1 departamento, porém um departamento possui vários (N) 
funcionários trabalhando nele. O relacionamento “trabalha_em” é do tipo :N. 
No relacionamento N:N, ou muitos para muitos, vários elementos da entidade podem se relacionar com 
vários elementos da outra entidade envolvida no relacionamento. Por exemplo, supondo que exista um 
relacionamento chamado “realizam” entre a entidade FUNCIONA IOS e a entidade P OJ TOS, onde um 
funcionário pode realizar vários (N) projetos e cada projeto pode ser realizado por vários (N) funcionários. O 
relacionamento “realizam” é do tipo N:N. 
A relação de participação especifica se a existência das instâncias nas entidades depende de elas estarem 
associadas ou não à outra entidade. Pode ser chamada de obrigatória (total) ou opcional (parcial). 
Quando todos os elementos da entidade são obrigados a participarem de um relacionamento, este é 
chamado de total ou obrigatório. Por exemplo, se dizemos que obrigatoriamente todos os funcionários da 
empresa têm que estar relacionados trabalhando em um departamento, nesse caso não pode haver sequer 
um funcionário cadastrado no banco de dados, sem a informação de qual departamento este trabalha. 
Por outro lado, se uma entidade pode ter elementos que não participam de determinado relacionamento, 
este é dito opcional ou parcial. Por exemplo, se dizemos que nem todos os funcionários são obrigados a 
estarem envolvidos num projeto, nesse caso teremos funcionários que realizam projetos e outros que não 
realizam, então esse relacionamento é parcial. 
Agora que os principais conceitos do modelo ER foram apresentados, é hora de colocar a mão na massa e ver 
como esse modelo é utilizado na prática. 
 
2.3. Construindo um modelo ER 
Para o desenvolvimento da competência e da habilidade de criar um projeto conceitual de dados, usando o 
modelo ER, é necessário que os conceitos apresentados sejam utilizados e é exigida uma prática nessa área. 
 
 
 
23 
 
Sendo assim, apresentaremos a seguir um minicaso fictício da Empresa X, que servirá de exemplo, sobre o 
qual faremos a construção de um modelo ER. 
Seja uma Empresa X, que possui um sistema de banco de dados a ser desenvolvido, na primeira etapa de 
criação do modelo conceitual desse banco de dados, os gestores da Empresa X fizeram as seguintes 
observações sobre os dados que precisam ser gerenciados: 
Devem ser gravados os dados dos departamentos da empresa, que possuem como características o seu 
nome, seu código que é único para cada departamento e as localizações do departamento. O mesmo 
departamento pode estar localizado em diferentes cidades, que possuem sedes da Empresa X. 
Devem ser gravados os dados dos funcionários, que possuem como características o seu nome, o seu CPF 
(documento oficial para identificar o funcionário), valor do salário, sexo do funcionário e o seu endereço, que 
é formado pelo nome da rua e número, bairro e CEP. 
Devem ser gravados os projetos desenvolvidos na Empresa X, que possuem as características: descrição, 
código (um por projeto) e total da verba envolvida no projeto. 
 
Além dessas observações, os gestores também falaram um pouco sobre o funcionamento e as regras 
seguidas na Empresa X. Eles acrescentaram que: 
todo funcionário obrigatoriamente tem que estar ligado ao departamento onde trabalha; 
existem alguns funcionários que possuem cargo de coordenação sobre outros funcionários; 
todo departamento possui um gerente, que é um funcionário específico. Não pode haver departamento sem 
um gerente indicado; 
os departamentos controlam os projetos que são desenvolvidos na Empresa X. Um projeto só pode ser 
controlado por no máximo um departamento, mas um departamento pode controlar mais de um projeto; 
os funcionários realizam projetos e as horas trabalhadas nesses projetos devem ser armazenadas para fins de 
pagamento. 
 
Depois dessa conversa inicial entre os projetistas do banco de dados e os gestores da Empresa X, um 
primeiro esboço do modelo conceitual foi apresentado. A Figura 2.8 ilustra o esboço do modelo ER para a 
Empresa X, seguindo as características apresentadas até o momento. 
 
 
 
24 
 
 
Figura 2.8: Modelo ER da Empresa X. 
Fonte: Elaborada pela autora. 
 
Ao observarmos esse modelo, podemos destacar os conceitos apresentados nessa unidade: as entidades 
desse modelo são: DEPARTAMENTOS, FUNCIONARIOS e PROJETOS. 
Os atributos da entidade DEPARTAMENTOS são: código (que está sublinhado porque é a chave da entidade, 
pois é único para cada departamento), nome e localizações (que possui traço duplo, pois é multivalorado, 
uma vez que um departamento pode ser localizado em vários locais). 
Os atributos da entidade FUNCIONARIOS são: nome, CPF (que está sublinhado porque é a chave da entidade, 
pois é único para cada funcionário), endereço (que é composto por rua, número, bairro e CEP), salário e sexo. 
Os atributos da entidade PROJETOS são: código (que está sublinhado porque é a chave da entidade, pois é 
único para cada projeto), descrição e verba. 
 xiste um relacionamento : chamado “gerencia” entre as entidades D PA TAM NTOS e FUNCIONARIOS, 
que representa o fato de que cada departamento possui um gerente. O traço duplo do lado do 
departamento nesse relacionamento representa a totalidade, que nesse caso é a regra de que todo 
departamento obrigatoriamente tem que ter um gerente. 
Existe um relacionamento :N chamado “trabalha_em” entre as entidades D PA TAM NTOS e 
FUNCIONARIOS, que representa a relação de trabalho dos funcionários num departamento. Cada funcionário 
 
 
 
25 
 
obrigatoriamente (traço duplo do lado do funcionário) trabalha num único departamento, mas um 
departamento pode ter N funcionários trabalhando nele. 
 xiste um autorrelacionamento ou relacionamento recursivo :N chamado “coordena”, envolvendo 
diferentes instâncias da entidade FUNCIONARIOS. De um lado desse autorrelacionamento, temos o papel do 
coordenador, que é um funcionário que coordena vários outros funcionários. 
 xiste um relacionamento N:N chamado “realizam” envolvendo as entidades FUNCIONA IOS e P OJ TOS. 
Ou seja, um funcionário pode realizar vários projetos e cada projeto pode possuir vários funcionários 
trabalhando nele. Do lado dos projetos, há um traço duplo indicando a totalidade, pois todo projeto 
obrigatoriamente tem que possuir funcionários. Nesse relacionamento, há um atributo, que caracteriza o 
número de horas que um funcionário trabalhou num projeto. 
Por fim,existe um relacionamento :N chamado “controle” entre as entidades D PA TAM NTOS e 
PROJETOS, que representa a relação de controle dos departamentos sobre seus projetos. Um departamento 
controla vários projetos, mas um projeto só pode ser controlado por um departamento. 
Vimos até o momento o modelo ER em teoria, com todos os seus principais conceitos, e sua aplicação prática 
num exemplo. É importante a compreensão de que desde que esse modelo surgiu ele vem sendo 
amplamente utilizado, mas também vem sofrendo evoluções. Atualmente, o modelo ER não se restringe 
apenas aos conceitos e representação gráfica tradicionais, conforme foram apresentadas até o momento. 
Uma das formas de observarmos a evolução desse modelo é sua utilização em ferramentas computacionais 
de auxílio ao projeto, as ferramentas CASE, e outra forma é conhecendo o modelo ER estendido. 
 
2.4. A ferramenta DB Designer 
Existe disponível para os projetistas de bancos de dados uma série de ferramentas CASE (de Computer-Aided 
Software Engineering, ou programas auxiliares nas tarefas de engenharia de software), que auxiliam na 
tarefa de projeto dos sistemas, incluindo a modelagem conceitual de dados. 
Uma dessas ferramentas CASE mais conhecidas e difundidas é o programa DB Designer, desenvolvida pela 
empresa Fabulous Force Database Tools, que pelo fato de ser um software livre, pode ser baixado, instalado 
e utilizado gratuitamente. 
Essa ferramenta é compatível com diversos SGBDs conhecidos e amplamente utilizados no mercado, tais 
como: Oracle, SQLServer, MySQL, PostGreSQL e SQLite. 
Além de auxiliar na criação do modelo conceitual de dados, utilizando uma notação muito próxima da 
modelagem ER, após concluída a etapa de projeto conceitual, nessa ferramenta é possível gerar o código 
referente à criação do modelo físico e implementá-lo diretamente num SGBD. 
 
 
 
26 
 
O DB Designer possui uma interface gráfica de fácil compreensão para o usuário, tem diferentes 
possibilidades de visualização dos dados, possui opções de importar e exportar dados diretamente para os 
BD instalados, dentre outras facilidades para os projetistas. 
O objetivo aqui, entretanto, não é de ensinar a utilizar a ferramenta, mas sim de apresentá-la de forma 
sucinta, para que os interessados em sua utilização possam por conta própria aprender seu uso. Sendo assim, 
para obter mais informações e buscar por sites para baixar o DB Designer, consulte o site oficial disponível 
em: https://dbdesigner.net/. 
A Figura 2.9 ilustra como aparenta a principal interface do DB Designer 4. 
 
Figura 2.9: Interface do DB Designer 4. 
Fonte: Elaborada pela autora. 
 
2.5. O modelo EER 
O modelo Entidade-Relacionamento estendido, também conhecido por sua sigla EER (do inglês, Extended 
Entity Relation), surgiu para suprir uma necessidade de representação dos dados mais complexos, que são 
utilizados em sistemas avançados de informação, como sistemas multimídia, sistemas geográficos, 
sistemas específicos da área de engenharia, dentre outros. Todos esses sistemas para serem 
implementados utilizam como solução a programação Orientada a Objetos (OO) e seus principais 
conceitos, tais como os de objeto, classe, subclasse, herança etc. 
Os projetistas de bancos de dados precisavam de mais elementos, que aqueles presentes no modelo ER, 
para uma representação semântica dos dados mais complexos. Precisava ser representado exatamente o 
que o dado significa no sistema, geralmente objetos. 
https://dbdesigner.net/
 
 
 
27 
 
O modelo ER tradicional continua sendo o mais utilizado, mas o ER Estendido (EER) apresenta mais 
possibilidades com a inclusão dos conceitos de subclasses, superclasses, herança, especialização e 
generalização, que estudaremos a seguir. 
Um tipo de entidade no modelo EER é usado para representar um conjunto de entidades de um mesmo 
tipo existente no banco de dados. Por exemplo, o tipo de entidade EMPREGADO de um banco de dados de 
empresa, que representa todos os empregados de um mesmo tipo, que contém as mesmas características 
representadas em seus atributos. 
Agora, imagine que nessa empresa os empregados podem ser agrupados em subgrupos, que possuem 
características próprias que são importantes para a aplicação do banco de dados. Por exemplo, para a 
entidade EMPREGADO, poderíamos ter os subgrupos dos TECNICO, SECRETARIA, ENGENHEIRO e GERENTE. 
Chamamos cada um desses subgrupos de subclasses do tipo de entidade EMPREGADOS. 
EMPREGADO, por sua vez, é a superclasse das demais subclasses. A Figura 2.10 ilustra esses conceitos. 
 
Figura 2.10: Ilustração dos conceitos de superclasse e subclasse. 
Fonte: Elaborada pela autora. 
 
As entidades que são subclasses herdam todas as características da superclasse. Ou seja, nesse exemplo, 
técnicos, secretárias, engenheiros e gerentes possuem todos os atributos da superclasse EMPREGADO. 
Observe a Figura 2.11, que ilustra a herança. 
 
 
 
28 
 
 
Figura 2.11: Ilustração do conceito de herança. 
Fonte: Elaborada pela autora. 
 
Outros dois conceitos importantes no modelo EER são os de especialização e generalização, pois com eles 
podem ser representadas características interessantes dos dados. 
A especialização é o processo de definir um conjunto de subclasses de um tipo de entidade, com base em 
algumas características de distinção das entidades da superclasse. Por exemplo, um EMPREGADO pode ser 
especializado pelo tipo de trabalho que realiza entre SECRETARIA, ENGENHEIRO ou TECNICO. Nesse caso, 
um empregado pertence a um dos três subgrupos, não podendo pertencer a mais de um. 
 
Figura 2.12: Ilustração do conceito de especialização sobreposta no exemplo. 
Fonte: Elaborada pela autora. 
 
 
 
29 
 
 
Uma especialização não disjunta ou sobreposta, representada pela letra “o” de overlap) no círculo, 
ocorre quando uma instância poderia pertencer ao mesmo tempo de mais de uma subclasse, ou seja, 
nesse exemplo, uma mesma peça poderia ser fabricada ou fornecida. Quando for fabricada, receberá as 
características da subclasse PECA_FABRICADA, e quando for fornecida, terá as características da entidade 
PECA_FORNECIDA. 
A generalização ocorre quase que num processo inverso da especialização, quando pensamos não nas 
características particulares de cada entidade, mas sim em características comuns ou generalizadas. Por 
exemplo, imagine uma aplicação que possui dois tipos distintos de entidades CARRO e CAMINHAO, 
representados na parte (a) da Figura 2.13. 
 
 
Figura 2.13: Ilustração do conceito de generalização. 
Fonte: adaptada de Elmasri e Navathe (2018, p. 102). 
 
O processo de generalização vai extrair características comuns dessas entidades, tais como ID do Veículo, 
Preço e Número da placa, para criar uma superclasse de VEÍCULOS, representado na parte (b) da Figura 
2.13. 
Observe que a notação é a mesma utilizada para especialização e generalização. 
 
 
 
30 
 
O traço duplo nesse diagrama representa a restrição de totalidade, onde todo VEICULO obrigatoriamente 
tem que pertencer a um dos dois grupos: CARRO ou CAMINHAO. 
Além dessas características apresentadas para o modelo EER, existem outras representações e restrições, 
porém não são necessárias para conhecimento específico desta disciplina. 
 
Considerações Finais 
Ao longo deste bloco, você aprendeu que o processo de projeto em bancos de dados se inicia com a 
criação de um modelo conceitual de dados, que pode ser realizado através da modelagem Entidade-
Relacionamento (ER). O modelo ER é gráfico e possui diversas definições, tais como: entidade, 
relacionamento, atributo, chave, cardinalidade e totalidade, dentre outros. Posteriormente, esse modelo 
será mapeado para um modelo lógico e de implementação, que pode ser o relacional. Existem ferramentas 
CASE que podem ser usadas para o projeto de bancos de dados e uma delas é o DB Designer, que além de 
ser uma ferramenta bastante utilizada e com muitos recursos interessantes,possui a vantagem de ser um 
software livre. Vimos também que o modelo ER evoluiu ao longo dos anos e acrescentou alguns conceitos, 
se estendendo e se transformando no chamado modelo ER Estendido ou EER. 
 
Referência Bibliográfica 
RAMAKRISHNAN, Raghu; GEHRKE, Johannes. Sistemas de gerenciamento de banco de dados. 3. ed. São 
Paulo: McGraw Hill, 2011. 
 
 
BLOCO 3. MODELO RELACIONAL 
Olá! Vamos dar andamento ao processo de criação de BD, avançando na etapa de modelagem lógica e 
física de dados. Este bloco está concentrado na descrição dos princípios básicos do modelo relacional de 
dados, iniciando pela definição dos conceitos de modelagem e notação do modelo relacional, passando à 
discussão das restrições relacionais, chegando às operações de atualização de dados no modelo relacional. 
Depois veremos como esse modelo evoluiu com a incorporação da Orientação a Objetos, chegando ao 
conceito de BD Objeto-Relacional (OR). Vamos lá? 
 
3.1. Principais Conceitos do Modelo Relacional 
O modelo relacional foi introduzido por Ted Codd, da IBM Research, em 1970, a partir da publicação de um 
artigo científico, fruto de sua pesquisa. Esse modelo chamou a atenção devido à sua simplicidade e base 
 
 
 
31 
 
matemática. O modelo usa o conceito de relação matemática, que representa uma tabela de valores. Os 
modelos de dados que antecederam o modelo relacional compreendem os modelos hierárquico e de rede. 
Ambos são mais complexos e menos eficientes. 
As primeiras implementações comerciais do modelo relacional tornaram-se disponíveis no início dos anos 
1980 e desde essa época o modelo vem sendo utilizado em um grande número de sistemas comerciais. 
Segundo Elmasri e Navathe (2018), um banco de dados estruturado de acordo com o modelo relacional 
corresponde a uma coleção de relações. Informalmente, uma relação é uma tabela na qual cada linha 
expressa uma coleção de valores de dados relacionados. Fazendo uma analogia com o modelo ER, os 
valores na linha da tabela podem ser interpretados como um fato que descreve a instância de uma 
entidade ou um relacionamento, e as colunas da tabela correspondem aos atributos de uma entidade ou 
de um relacionamento. 
Segundo Amadeu (2015), de maneira simplificada, em um modelo relacional, as estruturas básicas são 
tabelas (relações), as restrições de integridade são chaves, restrições de domínio, de entidade e 
referencial, e as operações são álgebra relacional. 
Como o modelo relacional é todo baseado em teorias matemáticas, existe uma notação formal utilizada 
para definir cada um dos conceitos desse modelo. 
Formalmente, as linhas de uma relação, ou tabela, são chamadas de tuplas e o cabeçalho das colunas é 
chamado de atributos. O conjunto de valores que podem aparecer em cada coluna é chamado de domínio. 
A Figura 3.1 ilustra esses conceitos. 
Figura 3.1: Os atributos e as tuplas de uma relação chamada ALUNOS. 
Fonte: elaborada pela autora. 
 
Usando como exemplo os dados da Figura 3.1, a primeira linha (tupla 1) representa os dados de uma aluna 
chamada “Carla Martins de Souza”, e além desse atributo Nome , ela possui outros dados relacionados a 
ela que são: matrícula “ 546”, endereço “ ua X, 5” e assim por diante. Cada valor desses dados possui 
 
 
 
32 
 
um tipo permitido de valores que podem ser usados para preencher essas colunas (atributos) da tabela. 
Esses valores possíveis constituem o domínio do atributo, como a idade dos alunos que é do tipo número 
inteiro, o CPF que é um conjunto de caracteres numéricos com 11 algarismos etc. 
Um esquema de relação R é uma expressão matemática da forma: R (A1,A2,...,An) onde: 
R – é o nome de uma relação; 
Ai – é o nome de um atributo que representa um papel de um domínio D em R – dom (Ai); 
n – é o grau da relação. 
 
Um exemplo de esquema de relação pode ser extraído da Figura 3.1, onde a relação ALUNOS será assim 
representada: 
ALUNOS (Nome, Matricula, Endereco, Email, Celular, Idade, CPF) 
Esse é um esquema de relação de grau 7 (quantidade de atributos). 
Uma relação (também chamada de estado de uma relação ou instância de uma relação) r(R) é um 
conjunto de n-tuplas: r = {t1, t2,..., tn}, onde: 
cada n-tupla t é uma lista ordenada de n valores t=v1, v2,...,vn, 
sendo cada vi um elemento do dom(Ai) ou 
um valor especial nulo. 
 
Em outras palavras, usando o exemplo apresentado na Figura 3.1, a relação ALUNOS é um conjunto de 5 
tuplas, cada uma contendo os valores associados a cada domínio de cada atributo, que representam fatos 
do mundo real. 
A definição anterior implica certas características que fazem uma relação ser diferente de um arquivo 
simplesmente. Algumas dessas características são: 
 As tuplas de uma relação não são ordenadas. Uma relação é definida como um conjunto de tuplas, 
porém não há uma ordenação matemática entre elas. Na verdade, a ordem em que as tuplas 
aparecem numa relação é a mesma ordem em que esses dados foram sendo inseridos no banco de 
dados. Por exemplo, na Figura 3. , a aluna “Carla Martins de Souza” foi inserida no banco de dados 
antes do aluno “Joaquim Barros de Lima”, e assim por diante. 
 Uma tupla é uma lista ordenada de valores, portanto, a ordem dos valores em uma tupla, e 
consequentemente, dos atributos na definição de um esquema de relação é importante. Ou seja, a 
ordem que cada coluna da tabela ocupa no banco de dados é fixa e os dados que são armazenados 
em cada coluna devem obedecer a essa ordem. Por exemplo, na Figura 3.1, só conseguimos incluir os 
 
 
 
33 
 
dados de cada linha na tabela com os valores corretos: primeiro o nome, depois a matrícula, depois o 
endereço, e assim sucessivamente até o CPF, que é o último valor. 
 O valor de cada atributo em uma tupla é atômico ou é um valor nulo. Ou seja, o valor que é inserido 
em cada célula da tabela é indivisível, não podendo ser composto e/ou multivalorado. Na ausência de 
valores para preencher um atributo, este receberá o valor nulo. Em outras palavras, usando mais uma 
vez o exemplo da Figura 3.1, seja um aluno definido na relação ALUNOS, não conseguimos no 
atributo “ mail”, conforme foi definido, inserir mais de um valor de e-mail. Para esse modelo, se 
precisarmos representar mais de um valor para um atributo, teremos que criar um novo atributo. Por 
exemplo, teríamos que fazer uma coluna atributo para “ mail_ ” e outra coluna para “ mail_ ”, no 
caso de querermos cadastrar 2 valores possíveis. Caso não queiramos cadastrar mais de um e-mail do 
aluno, poderemos deixar um dos atributos com o valor nulo (em inglês, null). 
 Nulo (null): o valor nulo é usado para representar o valor do atributo desconhecido ou quando não se 
aplica a uma tupla. Esse valor é diferente de atribuirmos o valor 0 (zero) a um atributo numérico, pois 
ele representa a ausência de valor. Por exemplo, se numa tupla de uma tabela das notas dos alunos, 
no atributo nota colocamos o valor 0 (zero), significa que o aluno fez a prova e tirou a nota 0 (zero). 
Por outro lado, se atribuirmos o valor nulo, significa que o aluno não tem nota, talvez porque não 
tenha feito a prova. 
 Vale ressaltarmos que nem todos os atributos podem receber valor nulo, pois podem ser de 
conteúdo obrigatório. Por exemplo, não faz sentido cadastrar um aluno no banco de dados sem 
colocar seu nome. Nesse caso, o atributo “Nome” é obrigatório e ao ser criado no BD deve-se colocar 
a expressão not null, representando que não serão aceitos valores nulos. 
Um banco de dados relacional é um conjunto formado por diversas relações (tabelas), que estão 
relacionadas entre si e que são definidas a partir de uma realidade. A Figura 3.2 apresenta um exemplo de 
um banco de dados relacional. 
 
 
 
34 
 
 
Figura 3.2: Exemplo de relações em um BD relacional de uma Escola. 
Fonte: Elaborada pela autora. 
 
Nesse exemplo, podemos observar que o banco de dados da Escola é composto por 7 relações: ALUNOS, 
PROFESSORES, PROF_DISC,DISCIPLINAS, CURSOS, CURSO_DISC e TURMAS. Cada uma das relações possui 
atributos definidos. Ao longo deste bloco, sempre que necessário, os conceitos apresentados farão 
referência a esse exemplo. 
Um esquema de BD relacional S define um conjunto de esquemas relação R = {R1, R2,...,Rn} e um conjunto 
de restrições de integridade I, portanto, S=(R,I). Em outras palavras, um esquema de banco de dados 
relacional é composto não só por todas as tabelas que o compõem, mas também por suas restrições de 
integridade. 
 
3.2. Restrições no Modelo Relacional 
As restrições de integridade do modelo relacional são basicamente de 4 tipos: restrições de domínio, 
restrições de chaves, restrições de integridade de entidade e restrições de integridade referencial. 
 
 
 
35 
 
As restrições de domínio especificam que o valor de cada atributo de uma relação deve ser um valor 
atômico do domínio do atributo. Em outras palavras, para cada atributo da tabela é definido um domínio 
(ou um tipo de dado específico) e o valor atribuído ao atributo no banco de dados tem que ser atômico e 
obedecer a esse domínio especificado, ou pode ser um valor nulo. 
As restrições de chaves são especificadas a partir dos conceitos de chave primária e de chave alternativa. 
No modelo relacional, o conceito de chave é semelhante ao do modelo entidade-relacionamento. Uma 
chave é um atributo que identifique uma tupla na relação. 
Formalmente, uma chave K (do inglês, Key) da relação R é qualquer subconjunto mínimo de atributos, que 
identificam unicamente uma tupla da relação, ou, em outras palavras, um atributo que assuma um valor 
único para cada linha da tabela. Sendo assim, dado um valor desse atributo, é possível saber de que linha 
se refere. A chave pode ser composta por apenas um atributo, ou por mais de um atributo. 
Por exemplo, no modelo apresentado na Figura 3.2, os atributos que aparecem sublinhados em cada 
esquema de relação, representam as suas chaves primárias. Na tabela de ALUNOS é a matrícula, na tabela 
de PROFESSORES é o CPF, e assim por diante. Já na tabela CURSO_DISC a chave é formada por dois 
atributos Cod_Curso e Cod_Disc. Isso ocorre porque apenas um desses atributos não identifica unicamente 
uma linha dessa tabela. Para identificar, são necessários dois atributos. 
Em geral, uma relação pode ter mais de uma chave. Cada uma dessas chaves é chamada de chave 
candidata. Dentre as chaves candidatas, uma delas é escolhida como chave primária (PK – do inglês, 
Primary Key), aquela que irá identificar unicamente uma tupla e deve ser sublinhada. As demais 
constituem as chaves alternadas ou alternativas (essas não devem ser sublinhadas). 
Por exemplo, na Figura 3.2 observamos que na tabela de ALUNOS a chave primária é o atributo que está 
sublinhado “Matricula”, porém sabemos que o valor do CPF de um aluno é único para ele. Isso significa que 
o CPF do aluno poderia ser uma chave primária, mas não é. Nesse caso, o atributo “CPF” é uma chave 
alternativa. 
As restrições de integridade de entidade definem que nenhum componente de uma chave primária pode 
ser um valor nulo (ou null). Em outras palavras, as chaves primárias são atributos de preenchimento 
obrigatório no banco de dados, uma vez que esses valores são utilizados para identificar uma instância da 
relação. 
As restrições de integridade referencial são especificadas a partir do conceito de chave estrangeira. Uma 
chave estrangeira é aquela que aparece numa tabela fazendo referência aos dados de uma outra tabela, 
na qual ela é chave primária. 
 
 
 
36 
 
A Figura 3.3 é novamente a imagem do BD Escola, porém dessa vez com representações das chaves 
estrangeiras existentes nesse exemplo. 
 
Figura 3.3: Modelo relacional do BD Escola com destaque para as chaves estrangeiras. 
Fonte: Elaborada pela autora. 
 
Nessa figura, as setas representam as referências de chaves estrangeiras. Com isso podemos observar, por 
exemplo, que o atributo “Cod_Turma” na tabela de ALUNOS é uma chave estrangeira que faz referência ao 
atributo “Codigo” da tabela TU MAS, onde esse atributo é chave primária. Na tabela de CU SOS há 
também um atributo “CPF_Coord” que é chave estrangeira que faz referência ao atributo “CPF” da tabela 
de PROFESSORES, onde este é chave primária, e assim sucessivamente. 
Formalmente, seja FK (do inglês, Foreing Key) um conjunto de atributos de um esquema de relação R1 
definido sobre os mesmos domínios dos atributos da chave primária PK de um outro esquema de relação 
R3. Então, para qualquer tupla t1 de R1 uma das seguintes situações ocorre: 
t1[FK] = t2[PK], onde t2 é alguma tupla de R2, ou 
t1[FK] é nulo. 
 
 
 
37 
 
Em outras palavras, essa definição significa que se um atributo é chave estrangeira da chave primária de 
outra tabela, os valores que este vai poder receber têm que ser os mesmos da sua tabela de origem. Por 
exemplo, na Figura 3.3 podemos observar que os valores referentes às turmas que os alunos frequentam 
 “Cod_Turma” na tabela de ALUNOS são os mesmos que estão cadastrados no atributo “Codigo” da tabela 
TU MAS. Não poderia ser colocado no atributo “Cod_Turma” um valor que não fosse uma turma já 
cadastrada no banco de dados, na tabela de TURMAS. Mas esse valor poderia ser nulo, ou seja, um aluno 
que não está cadastrado em nenhuma turma. 
A restrição de integridade referencial entre R1 e R2 pode ser expressa pela notação R1[FK]  R2[FK], onde 
PK é a chave primária de R2 e FK é a chave estrangeira de R1. 
De acordo com o modelo relacional, as operações de manipulação de dados sobre um banco de dados 
podem ser classificadas em: operações de recuperação ou consulta (comando SELECT) e operações de 
atualização, que se referem à inserção, alteração ou remoção dos dados no BD (comandos INSERT, 
UPDATE, DELETE). 
As restrições de integridade não podem ser violadas pelas operações de atualização. Ou seja, as 
atualizações podem ser bloqueadas (ou não ser executadas) ou ser propagadas automaticamente para 
manter restrições de integridade. Por exemplo, no caso da remoção de tuplas que violem a restrição de 
integridade referencial. 
Em outras palavras, quando ocorre em um banco de dados uma restrição de integridade referencial (RIR), 
que serve para garantir a integridade dos dados quando existem chaves estrangeiras envolvidas, é 
necessário pensar nas opções que surgirão no caso de remoção ou alteração dos dados envolvidos. 
Quando um dado envolvido numa RIR é alterado ou removido, se isso não for feito com um certo cuidado, 
poderia ferir essa restrição. 
Por exemplo, imagine que a turma “ 5B” deixará de ser ofertada na escola, representada pelo BD da Figura 
3.3, o que aconteceria com os alunos dessa turma se simplesmente removêssemos a sua tupla da tabela de 
TURMAS? As alunas Maria e Bruna, que são dessa turma ficariam com um valor inválido na coluna 
“Cod_Turma”, pois a sua turma 5B não existiria mais. Isso iria ferir a restrição de integridade referencial. 
Então, sempre que existe uma RIR: R1[x]  R2[y] é necessário definir uma opção de remoção de valores da 
chave primária, quando esta ocorrer. Ou seja, precisamos dizer ao banco de dados o que fazer com os 
valores que ainda permanecerão no BD e que se referem aos dados que serão removidos. São três as 
opções de remoção: 
 Tornar nulo o campo referente na chave estrangeira: se esse atributo que é chave 
estrangeira não for um atributo obrigatório, ou seja, se ele permitir valores nulos, podemos 
 
 
 
38 
 
definir que se a chave primária, a qual esse dado se refere for removida, esse atributo recebe 
valor nulo; ou 
 Propagar a remoção: se o valor da chave primária que deu origem aos dados da chave 
estrangeira for removido do BD, automaticamente todas as referências na tabela que contêm 
a chave estrangeira também são removidas. Essa é uma atitude bastante drástica, utilizada 
apenas em casos onde a dependência entre valores é muito forte. Esse tipo de remoçãoé 
conhecido como remoção em cascata (on delete cascade); ou 
 Bloqueio da remoção: essa é a opção mais utilizada por ser a mais segura. Nesse caso, não é 
permitido excluir itens da chave primária que contêm referências na tabela da chave 
estrangeira e a remoção é bloqueada. Geralmente, uma mensagem é enviada ao usuário 
informando que a remoção não foi realizada, pois existem dados referenciados numa chave 
estrangeira. O usuário primeiro precisaria alterar ou remover os valores da chave estrangeira, 
para depois remover os valores da chave primária. 
 
3.3. Álgebra Relacional 
O modelo relacional, como temos estudado, é formalmente baseado na matemática e como tal, deverá 
conter operadores formais para manipular seus dados. Segundo Elmasri e Navathe (2018), a álgebra 
relacional é um conjunto de operações básicas usadas para manipular dados nas relações em um BD 
relacional. 
As operações da álgebra relacional permitem ao usuário do BD relacional especificar as solicitações básicas 
de recuperação (ou consulta) dos dados. As operações podem ser usadas isoladamente (são as operações 
fundamentais) ou podem ser formadas por mais de uma operação fundamental (são as operações 
derivadas). 
Na prática, a álgebra relacional não será utilizada diretamente nas aplicações de bancos de dados. Essa 
matemática é apenas utilizada para formalizar as linguagens de programação em bancos de dados. Ou 
seja, a SQL, que é a linguagem de programação em bancos de dados relacionais, usa a teoria da álgebra 
relacional para especificar o comando de recuperação de dados SELECT. Os usuários e programadores 
utilizarão na prática o comando SELECT e não as operações relacionais, mas é importante ter um 
conhecimento básico dessa álgebra, para melhor compreensão da linguagem SQL, que será estudada mais 
adiante. 
 
 
 
39 
 
Uma característica importante é que toda operação da álgebra relacional tem como resultado uma 
relação. Ou seja, sempre que realizamos uma consulta numa ou mais tabelas do BD relacional, o resultado 
dessa consulta será dado também na forma de uma tabela. 
As operações da álgebra relacional são geralmente divididas em dois grupos: operações específicas 
(desenvolvidas apenas para a teoria de banco de dados relacional) ou de conjuntos (aplicada a qualquer 
tipo de conjunto e leva em conta que uma relação é um conjunto de tuplas). 
Operações específicas: SELEÇÃO, PROJEÇÃO, JUNÇÃO e DIVISÃO. 
Operações de conjuntos: UNIÃO, INSERÇÃO, DIFERENÇA e PRODUTO CARTESIANO. 
 
Cada uma dessas operações utiliza um símbolo ou uma letra grega para representá-la, conforme veremos a 
seguir: 
 
1. Operação de seleção (): seleciona um subconjunto de tuplas de uma relação (linhas de uma tabela), 
que satisfazem uma condição de seleção, expressa no predicado dessa operação. 
Notação da operação de seleção:  CONDIÇÃO (nome da relação) 
Exemplos usando o banco de dados Escola (Figura 3.2): 
Selecione as tuplas da relação de ALUNOS que fazem parte da turma “ 5B”. 
  Cod_Turma = “ 5B” ALUNOS 
Essa operação mostraria como resultado uma nova tabela contendo todos os dados dos alunos que 
pertencem à turma especificada. 
Selecione as disciplinas cuja carga horária é menor que 70 horas. 
 CargaHora <70 (DISCIPLINAS) 
Essa operação mostraria como resultado uma nova tabela contendo todos os dados das disciplinas 
que possuem carga horária inferior a 70 horas. 
 
2. Operação de projeção (): projeta as tuplas de uma relação sobre um determinado conjunto de 
atributos (seleciona colunas de uma tabela). 
Notação da operação de projeção:  ATRIBUTOS (nome da relação) 
Exemplo usando o banco de dados Escola (Figura 3.2): 
Selecione os dados: nome, e-mail e celular de todos os professores. 
 Nome, Email, Celular (PROFESSORES) 
 
 
 
40 
 
Essa operação mostraria como resultado uma nova tabela contendo apenas os três dados 
selecionados de todos os professores. 
 
Operações assim podem ser usadas isoladamente conforme os exemplo apresentados, mas o mais comum 
é combinar as duas operações para realizar consultas. Primeiro, especificamos as colunas a serem 
projetadas e depois especificamos a condição da seleção de tuplas. 
 ATRIBUTOS ( CONDIÇÃO (nome da relação)) 
 
Exemplo usando o banco de dados Escola (Figura 3.2): 
Mostre os nomes e e-mails dos alunos da turma “ 7C”. 
 Nome, Email ( Cod_Turma=“ 7C” ALUNOS 
 
3. Sequência de operações: várias operações podem ser combinadas para formar uma expressão da 
álgebra relacional, que constitui uma consulta. Alternativamente, podemos especificar relações 
temporárias para cada passo da consulta. 
Por exemplo: ALUNOS_17C   Cod_Turma= “ 7C” ALUNOS 
RESULT   Nome, Email (ALUNOS_17C) 
 
Essa sequência de operações apresenta exatamente o mesmo resultado da consulta exemplificada 
anteriormente, mostrando os nomes e e-mails dos alunos da turma “ 7C”. Porém, nesse segundo caso, 
temos a formação de uma tabela temporária chamada “ALUNOS_ 7C”, que é utilizada posteriormente na 
segunda operação da sequência para obtermos o resultado. 
 
4. Operação de Junção (): combina as tuplas de duas relações R e S que satisfazem uma determinada 
condição de junção. Nesse caso, todas as linhas das tabelas R e S serão combinadas uma a uma, dando 
como resultado uma nova tabela contendo as informações de ambas combinadas. 
Notação da operação de junção: (R  CONDIÇÃO S). 
 
Exemplo usando o banco de dados Escola (Figura 3.2): 
Mostrar os nomes dos alunos e os números das suas salas de aula. Observe que nesse caso os nomes 
dos alunos estão presentes na relação ALUNOS e que os números das salas de aula estão presentes 
na relação de TURMAS. É uma consulta que envolve mais de uma tabela, cuja ligação entre essas 
 
 
 
41 
 
tabelas aparece no atributo Cod_Turma da tabela ALUNOS, que é chave estrangeira de Código na 
tabela de TURMAS. 
ALUNOS_TURMA  (ALUNOS  Cod_Turma= Codigo TURMAS) 
RESULT   Nome, Sala (ALUNOS_TURMA) 
 
Primeiro, fazemos a junção das duas tabelas envolvidas, selecionando as linhas onde mantemos a 
igualdade entre os valores de Cod_Turma e Código. Posteriormente, selecionamos apenas os atributos 
Nome e Sala. 
Em uma expressão apenas, essa mesma operação ficaria: 
 Nome, Sala ((ALUNOS  Cod_Turma= Codigo TURMAS)) 
 
5. Operações de conjuntos: como as relações podem ser consideradas conjuntos de tuplas, todas as 
operações da teoria de conjuntos podem ser usadas na álgebra relacional. As operações de conjuntos são: 
UNIÃO – efetua a união de duas relações compatíveis (R  S) 
DIFERENÇA – efetua a diferença entre duas relações compatíveis (R – S) 
INTERSEÇÃO – efetua a interseção de duas relações compatíveis (R  S) 
Duas relações R (A1, A2,..., An) e S (B1, B2,..., Bn) são compatíveis se elas tiverem o mesmo grau n e se 
dom(Ai)=dom(Bi) para 1  i  n. Em outras palavras, duas tabelas são compatíveis se tiverem a mesma 
quantidade e os mesmos tipos de dados nos atributos. 
Por exemplo, se quisermos selecionar os nomes e e-mails de todos os alunos e professores da Escola: 
 
DADOS_ALUNOS   Nome, Email (ALUNOS) 
DADOS_PROFS   Nome, Email (PROFESSORES) 
RESULT  DADOS_ALUNOS  DADOS_PROFS 
 
Como na prática a álgebra relacional não é usada diretamente pelos usuários, não vale explorarmos ainda 
mais esses conceitos. Para os alunos que quiserem aprender mais sobre álgebra relacional, sugerimos a 
leitura do documento: Operações Relacionais e Álgebra Relacional, de Antônio Cesar de Barros Munari, 
disponível em: http://www.lyfreitas.com.br/ant/pdf/OpRelacional.pdf. (Acesso em: maio 2019). 
 
 
 
http://www.lyfreitas.com.br/ant/pdf/OpRelacional.pdf
 
 
 
42 
 
3.4. Construindo um BD Relacional 
A construção de um banco de dados é realizada por um processo que envolve a análise e projeto de dados 
conceitual, resultando num modelo conceitual de dados (por exemplo, modelo ER), para posterior fase de 
projeto físico