Apostila Projeto Banco de Dados Relacional - IFSUL

Prévia do material em texto

INSTITUTO FEDERAL SUL-RIO-GRANDENSE
UNIVERSIDADE ABERTA DO BRASIL
MÓDULO 2
Michele de Almeida Schimidt
PROJETO DE BANCO DE
DADOS RELACIONAL
Ministério da
Educação
CURSO DE TECNOLOGIA EM SISTEMAS PARA INTERNET
Modalidade a Distância
 
UNIVERSIDADE ABERTA DO BRASIL
INSTITUTO FEDERAL SUL-RIO-GRANDENSE - CAMPUS PELOTAS
CURSO DE TECNOLOGIA EM SISTEMAS PARA INTERNET
Modalidade a Distância
PRESIDÊNCIA DA REPÚBLICA
Dilma Rousseff
PRESIDENTE DA REPÚBLICA FEDERATIVA DO BRASIL
MINISTÉRIO DA EDUCAÇÃO
Fernando Haddad
MINISTRO DO ESTADO DA EDUCAÇÃO
Luiz Cláudio Costa 
SECRETÁRIO DE EDUCAÇÃO SUPERIOR - SESU
Eliezer Moreira Pacheco
SECRETÁRIO DA EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA
Luís Fernando Massonetto 
SECRETÁRIO DA EDUCAÇÃO A DISTÂNCIA – SEED
Jorge Almeida Guimarães
PRESIDENTE DA COORDENAÇÃO DE APERFEIÇOAMENTO DE PESSOAL DE 
NÍVEL SUPERIOR - CAPES 
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E 
TECNOLOGIA SUL-RIO-GRANDENSE [IFSUL]
Antônio Carlos Barum Brod
REITOR
Daniel Espírito Santo Garcia
PRÓ-REITOR DE ADMINISTRAÇÃO E DE PLANEJAMENTO
Janete Otte
PRÓ-REITORA DE DESENVOLVIMENTO INSTITUCIONAL
Odeli Zanchet
PRÓ-REITOR DE ENSINO
Lúcio Almeida Hecktheuer
PRÓ-REITOR DE PESQUISA, INOVAÇÃO E PÓS-GRADUAÇÃO
Renato Louzada Meireles
PRÓ-REITOR DE EXTENSÃO
IF SUL-RIO-GRANDENSE
CAMPUS PELOTAS
José Carlos Pereira Nogueira
DIRETOR-GERAL DO CAMPUS PELOTAS
Clóris Maria Freire Dorow 
DIRETORA DE ENSINO
João Róger de Souza Sastre 
DIRETOR DE ADMINISTRAÇÃO E PLANEJAMENTO
Rafael Blank Leitzke 
DIRETOR DE PESQUISA E EXTENSÃO
Roger Luiz Albernaz de Araújo 
CHEFE DO DEPARTAMENTO DE ENSINO SUPERIOR
IF SUL-RIO-GRANDENSE
DEPARTAMENTO DE EDUCAÇÃO A DISTÂNCIA
Luis Otoni Meireles Ribeiro
CHEFE DO DEPARTAMENTO DE EDUCAÇÃO A DISTÂNCIA
Daniel Grill Lacerda
COORDENADOR DA UNIVERSIDADE ABERTA DO BRASIL – UAB/IFSUL
Marla Cristina da Silva Sopeña
COORDENADORA ADJUNTA DA UNIVERSIDADE ABERTA DO BRASIL – UAB/IFSUL
Cinara Ourique do Nascimento
COORDENADORA DA ESCOLA TÉCNICA ABERTA DO BRASIL – E-TEC/IFSUL
Ricardo Lemos Sainz
COORDENADOR ADJUNTO DA ESCOLA TÉCNICA ABERTA DO BRASIL – E-TEC/IFSUL
IF SUL-RIO-GRANDENSE
UNIVERSIDADE ABERTA DO BRASIL
Daniel Grill Lacerda
COORDENADOR DA UNIVERSIDADE ABERTA DO BRASIL – UAB/IFSUL
Marla Cristina da Silva Sopeña
COORDENADORA ADJUNTA DA UNIVERSIDADE ABERTA DO BRASIL – UAB/ IFSUL
Mauro Hallal dos Anjos
GESTOR DE PRODUÇÃO DE MATERIAL DIDÁTICO
CURSO DE TECNOLOGIA EM SISTEMAS PARA INTERNET 
Modalidade a Distância
Daniel Grill Lacerda
COORDENADOR DO CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS PARA INTERNET – 
TSIAD
Beatriz Helena Zanotta Nunes
SUPERVISORA PEDAGÓGICA
Suzana Grala Tust
REVISORA LINGUÍSTICA
Vera Maria Machado Damé
COORDENADORA DE TUTORIA DO TSIAD
UNIVERSIDADE ABERTA DO BRASIL
INSTITUTO FEDERAL SUL-RIO-GRANDENSE - CAMPUS PELOTAS
CURSO DE TECNOLOGIA EM SISTEMAS PARA INTERNET
Modalidade a Distância
 
EQUIPE DE PRODUÇÃO DE MATERIAL DIDÁTICO – UAB/IFSUL
Lisiane Corrêa Gomes Silveira
GESTORA DA EQUIPE DE DESIGN 
Alessandro Cruz Wrague
Aline de Almeida Tessmer
Andressa Silva Nasiloski
Denise Zarnottz Knaback
Felipe Rommel
Helena Guimarães de Faria
Helena Rodrigues dos Santos
Igor da Silva Amaral
Lucas Quaresma Lopes
Luisa Mendes Machado
Marco Lucas dos Anjos
Morgana Ávila dos Santos
Taís Lopes Barbosa
Talita Mesquita Barbosa
EQUIPE DE DESIGN
Catiúcia Klug Schneider
GESTORA DE PRODUÇÃO DE VÍDEO
Gladimir Pinto da Silva 
PRODUTOR DE ÁUDIO E VÍDEO
Jeferson de Oliveira Oliveira
AUXILIAR DE EDIÇÃO DE VÍDEO E PROGRAMADOR EM FLASH
João Eliézer Ribeiro Schaun
GESTOR DO AMBIENTE VIRTUAL DE APRENDIZAGEM
Giovani Portelinha Maia
GESTOR DE MANUTENÇÃO E SISTEMA DA INFORMAÇÃO
Acauan Merseburger Picanço
Anderson Weige Dias
Bruna Gonçalves Ribeiro
Carlo Camani Schneider
Diego Barcellos Rocha
Efrain Becker Bartz
Francine Neuschrank
Gabriel Duarte
Mateus Lorenzato Braga
Neimar Mendes Lima
Paula Cruz Guttier
Piter Oliveira Vergara
Vinícius Maciel
EQUIPE DE PROGRAMAÇÃO PARA WEB
1
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Prezado(a) aluno (a),
Bem-vindo (a) ao espaço de estudo da Disciplina de Projeto de Banco de Dados Relacional. 
Nosso objetivo nesta disciplina é proporcionar condições para que você seja capaz de projetar Bancos de 
Dados Relacionais. Desta maneira, disponibilizamos um material didático, composto por conteúdos, nos quais, a 
partir de exemplos, você possa compreender melhor como projetar um Banco de Dados Relacional. Será muito 
importante que você busque informações em outras fontes confiáveis, para tanto, no material há sugestões de 
Links e autores para que você possa aprimorar os conhecimentos nesta área. Além disso, você terá o apoio de 
sua equipe.
Busque ajuda sempre que precisar e participe intensivamente das atividades propostas, só assim será pos-
sível que você construa conhecimentos sólidos para prosseguir nesta caminhada.
Objetivos
Objetivo geral
Projetar Bancos de Dados Relacionais.
Objetivos específicos
Identificar os objetivos, as vantagens e as desvantagens do uso de Sistemas de Gerência de Banco de Dados (SGBD).• 
Reconhecer os componentes funcionais de um SGBD.• 
Identificar a Hierarquia de Abstrações de Dados.• 
Identificar os tipos de usuários de um SGBD.• 
Identificar as funções do administrador de um Banco de Dados.• 
Identificar Restrições de Integridade.• 
Compreender o Paradigma da Transação como Garantia de Correção do BD.• 
Compreender a garantia de Atomicidade e de Durabilididade.• 
Compreender o controle de Concorrência e a Serializabilidade.• 
Produzir um modelo conceitual de um sistema através da utilização do modelo de• 
Criar Diagrama Entidade-Relacionamento (DER).• 
Produzir um modelo lógico de um sistema pela efetivação de relacionamentos, identificando cardinalidade e normal-• 
izações necessárias.
Criar a estrutura de tabelas e relacionamentos em um Sistema Gerenciador de Banco de Da+ dos.• 
Garantir a Integridade de domínio e referencial necessária.• 
Compreender a Linguagem de Consulta Padrão para SGBD´s Relacionais.• 
Criar os grupos de usuários necessários, fornecendo direitos de acesso conforme sua função dentro de um sistema de • 
informação.
Criar usuários vinculando-os a um determinado grupo.• 
Automatizar procedimentos em nível de SGBD que garantam a segurança e a confiabilidade dos dados.• 
Efetuar testes de funcionamento do SGDB alocado.• 
Desenvolver Consultas SQL para SGBD´s Relacionais de forma otimizada.• 
Realizar procedimentos de cópia de segurança e restauração de cópias, garantindo a confiabilidade da estrutura dos • 
dados de um banco.
Guia DiDático GD
Análise e Projeto de Sistemas de informação Estruturados | Guia Didático
2
Análise e Projeto de Sistemas de informação Estruturados | Guia Didático
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Metodologia
Para o desenvolvimento da disciplina, utilizaremos o ambiente virtual de aprendizagem, Moodle, no qual 
serão disponibilizados conteúdos e atividades para compreensão a fim de que você seja capaz de alcançar os 
objetivos propostos. Ao concluir cada unidade, você deverá elaborar uma atividade que fará parte da proposta 
já iniciada na disciplina anterior - “Portal Informatizado para o Pólo”. Lembramos que cada atividade será feita 
pelos grupos já formados.
 Durante cada semana, serão disponibilizadas situações para interação entre os alunos e o professor no 
chat, nos fóruns . Esses espaços deverão ser utilizados para trocas de experiências, dúvidas entre outras situa-
ções que ocorrerem durante a execução das atividades.
Avaliação
A avaliação será realizada através de:
Participação nos fóruns de discussão (individual);• 
Realização das atividades propostas nas unidades (individual);• 
Atividade Final – Portal para o Pólo (em grupo).• 
Programação
A disciplina será desenvolvida no decorrer das semanas. 
Primeira semana: 
Na primeira semana, as atividades a serem desenvolvidassão:
Aula Presencial.1. 
Leitura e estudo do Conteúdo: Introdução a Banco de Dados. 2. 
Realização da atividade: Unidade A - Introdução a Banco de Dados.3. 
Participe do Fórum de discussão proposto pelo professor.4. 
Segunda semana: 
Na segunda semana, as atividades a serem desenvolvidas são:
Leitura e estudo do Conteúdo: Modelo Conceitual.5. 
Realização da atividade: Unidade B - Modelo Conceitual6. 
Realização da atividade: Unidade B - Atividade Final - 1º Parte7. 
Chat: Participar do chat no horário marcado pelo professor formador para discutir questões relativas ao modelo con-8. 
ceitual do projeto final.
Terceira semana: 
Na terceira semana, as atividades a serem desenvolvidas são:
Aula Presencial.9. 
Leitura e estudo do Conteúdo: Modelo Lógico10. 
Realização da atividade: Unidade C - Modelo Lógico11. 
Participe do Fórum de discussão proposto pelo professor.12. 
Realização da atividade: Unidade C - Atividade Final - 2º Parte13. 
3
Análise e Projeto de Sistemas de informação Estruturados | Guia Didático
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Quarta semana: 
Na quarta semana, as atividades a serem desenvolvidas são:
Aula Presencial.14. 
Leitura e estudo do Conteúdo: Linguagem de Consulta Estruturada SQL15. 
Realização da atividade: Unidade D - SQL16. 
Realização da atividade: Unidade D- Atividade Final - 3º Parte17. 
Chat: Participar do chat no horário marcado pelo professor formador para discutir questões relativas a linguagem de 18. 
consulta estruturada - SQL.
Quinta semana: 
Na quinta semana, as atividades a serem desenvolvidas são:
Aula Presencial.19. 
Leitura e estudo do Conteúdo: Sistema Gerenciador de Banco de Dados - PostgreSQL20. 
Realização da atividade: Unidade E - PostrgeSQL21. 
Sexta semana: 
Na sexta semana, as atividades a serem desenvolvidas são:
Leitura e estudo do Conteúdo: Transações em Banco de Dados.22. 
Realização da atividade: Unidade F - Transações em Banco de Dados.23. 
Chat: Participar do chat no horário marcado pelo professor formador para discutir questões relativas a atividade final.24. 
Realização da atividade: Atividade Final25. 
Sétima semana: 
Na sétima semana, as atividades a serem desenvolvidas são:
Aula Presencial26. 
Referências
HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4ª ed., Porto Alegre: Sagra Luzzatto, 2001.
NETO, Álvaro Pereira. PostgreSQL: Técnicas Avançadas – Versões OpenSource 7.X. 1ª ed., Érica, 2003.
OLIVEIRA, Celso Henrique Poderoso de. SQL: Curso Prático. São Paulo: Novatec, 2002.
ELMASRI, Rames; NAVATHE, Shamkant B. Sistema de Banco de Dados. Rio de Janeiro, 4ed.: LTC, 2000.
Projeto de Banco de Dados Relacional| Unidade A
1
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
1. O que é um Banco de Dados?
http://pt.wikipedia.org/wiki/Banco_de_dados
Como o Banco de dados é um conjunto de informações que possuem um significado implícito, podemos dizer 
então que uma planilha que armazena informações sobre alunos de uma escola é um Banco de dados.
ESCOLA “XYX”
Aluno Endereço Telefone
Ana Maria Av. xxxx 909002099
João Carlos Rua vvvvv 923082193
Jorge Fernandes Rua tttttt 329731872
Carla Antunes Av. wewqe 213123123
A escola “XYX” relaciona os dados dos alunos com informações sobre os mesmos, com isso essas informações 
associadas compõem um banco de dados. 
Autores descrevem o conceito de Banco de dados de diversas maneiras, no livro de NAVATHE, ELMASRI, 
Banco de dados é uma coleção de dados relacionados, onde os dados são fatos que podem ser gravados e que 
possuem um significado implícito. Mas estas definições são muito genéricas, pois, por exemplo, podemos con-
siderar um conjunto de palavras que formam esta página como um Banco de dados.
No entanto, o mesmo autor define algumas propriedades para o termo Banco de dados, considerando que o 
conceito anterior é muito genérico e pode com isso distorcer a idéia principal do que é um Banco de dados. As 
características definidas pelo autor são:
Um banco de dados representa alguns aspectos do mundo real, sendo chamado, às vezes, de minimundo ou de uni-• 
verso de discurso. As mudanças no minimundo são refletidas em um Banco de dados;
Um Banco de dados é uma coleção lógica e coerente de dados com algum significado inerente. Uma organização de • 
dados ao acaso não pode ser corretamente interpretada como um Banco de Dados;
Um Banco de dados é projetado, construído e povoado por dados, atendendo a uma proposta específica. Possui um • 
grupo de usuários definido e algumas aplicações pré-concebidas, de acordo com o interesse desse grupo de usuários.
uniDADEA
Conjunto de dados integrados que tem por objetivo 
atender a uma comunidade de usuários. [HEUSER, 1999]
intrODuçãO A BAnCO DE DADOS
Projeto de Banco de Dados Relacional| Unidade A
2
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Um Banco de dados pode ser gerado e mantido tanto manualmente como computadorizado, através de 
Sistemas de gerenciamento de banco de dados. O nosso objetivo, nesta disciplina, é estudar o Banco de dados 
computadorizado.
2. O que é um Sistema Gerenciador de Banco de dados?
Um Sistema gerenciador de banco de dados (SGBD) é uma coleção de programas que permite aos usuários 
criar e manter um Banco de dados. A construção de um banco de dados é o processo de armazenar os dados em 
alguma mídia apropriada e controlada pelo SGBD 
O SGBD é composto por quatro componentes: Usuários, Software/Hardware e os dados. A Figura 2 exempli-
fica o SGBD.
Segundo as características pro-
postas acima, podemos identi-
ficar no Banco de Dados Folha, 
algumas delas: é um banco 
de dados povoado por dados 
que atendem a uma proposta 
específica ,que é a de colecio-
nar todos os jornais publica-
dos para uma futura consulta 
de pesquisadores, estudantes, 
entre outras características.
Os objetivos de um sistema de 
banco de dados são o de isolar 
o usuário dos detalhes inter-
nos do banco de dados (pro-
mover a abstração de dados) 
e promover a independência 
dos dados em relação às apli-
cações, ou seja, tornar inde-
pendente da aplicação, a es-
tratégia de acesso e a forma 
de armazenamento.
Projeto de Banco de Dados Relacional| Unidade A
3
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Existem vantagens e desvantagens na utilização de um sistema de gerenciamento de banco de dados:
Vantagens:
Controle de Redundância• 
 No sistema gerenciador de banco de dados, conseguimos controlar para que os mesmos dados não sejam repeti-
dos várias vezes no mesmo banco.
Compartilhamento de Dados• 
 No compartilhamento, conseguimos controlar a redundância de dados, pois os dados são armazenados uma única 
vez e acessados por todos que necessitarem do dado.
Restrição a Acesso não Autorizado.• 
 Quando muitos usuários acessam um banco de dados é normal que alguns acessem informações que outros não 
tenham acesso. No SGBD, teremos vários usuários, em que alguns poderão acessar módulos de compras, outras de vendas, 
assim como alguns não poderão acessar o módulo financeiro, por exemplo.
Representação de Relacionamentos complexos entre Dados.• 
 Um SGBD tem como vantagem mostrar o relacionamento existente em um banco de dados assim como recuperar, 
alterar os dados de forma fácil e eficiente.
Desvantagens:
Em algumas situações, a utilização do SGBD pode gerar altos custos desnecessários. Que podem ser devido à utilização • 
de novos hardwares, softwares, treinamentos, além dos custos com a segurança do sistema entre outras característi-
cas necessárias para o bom funcionamento do SGBD.
Alguns exemplos de SGBDs são: Oracle,SQL Server, DB2, PostgreSQL, MySQL, entre outros. 
Conheça mais sobre estes SGBDs acessando os seus respectivos sites:
Oracle: http://www.oracle.com/global/br/index.html
SQL Server: http://www.microsoft.com/brasil/servidores/sql/default.mspx
DB2: http://www-306.ibm.com/software/br/db2/data/db2imstools/index.shtml
PostgreSQL: http://www.postgresql.org.br/
MySQL: http://www.mysqlbrasil.com.br/
Firebird: http://www.firebirdsql.org/
3. níveis de Abstração de dados
NAVATHE define uma arquitetura para o sistema de banco de dados, chamada de arquitetura de três-esque-
mas, proposta para auxiliar a realização e visualização das características do banco de dados. O objetivo desta 
arquitetura é separar o usuário da aplicação do banco de dados físico. Nessa arquitetura, o autor define três 
níveis: 
3.1 Nível interno ou esquema interno;
3.2 Nível conceitual ou esquema conceitual;
3.3 Nível externo ou visão.
Projeto de Banco de Dados Relacional| Unidade A
4
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
3.1 Nível interno ou esquema interno;
O nível interno descreve a estrutura de armazenamento físico do banco de dados, este esquema utiliza um modelo • 
que descreve os detalhes completos de armazenamento de dados e os caminhos de acesso ao banco de dados.
3.2 Nível conceitual ou esquema conceitual;
O nível conceitual define quais dados estão armazenados no banco de dados e o relacionamento entre estes dados. • 
3.3 Nível externo ou visão.
O nível externo abrange esquemas externos onde cada esquema descreve a parte do banco de dados que um dado • 
grupo de usuário tem interesse e oculta o restante do banco de dados deste grupo.
4. usuários de um sistema de BD
O • Administrador do BD (DBA) é responsável por:
Autorizar o acesso ao BD;
Coordenar e monitorar o uso;
Adquirir recursos de software e hardware necessários.
Projetista do BD tem a função de:• 
Identificar os dados a serem armazenados no Banco de dados;
Escolher as estruturas apropriadas para representar e armazenar esses dados;
Comunicar-se com todos os prováveis usuários de banco de dados para conhecer suas necessidades.
Programador de aplicações• 
Implementar as especificações como programas, testar, documentar e manter as transações customizadas.
Usuário final• 
Utilizar as aplicações feitas pelo programador de aplicações.
Projeto de Banco de Dados Relacional| Unidade B
6
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Agora que já estudamos o que é um Banco de Dados e outros fatores importantes para este estudo, vamos 
pensar nos bancos de dados que daqui a algumas aulas já serão implementados em um Sistema de Gerencia-
mento de Banco de Dados - SGBD. Nesta unidade, começaremos o projeto conceitual, é uma fase que vem após 
o levantamento de requisitos do sistema, para isso, é necessário que, ao começar o projeto de banco de dados, 
já exista o levantamento de tudo que será necessário no sistema.
5 . Modelo conceitual
A modelagem conceitual é uma fase muito importante no planejamento de uma aplicação de um banco de 
dados bem-sucedido, este modelo descreve a estrutura de um banco de dados de forma independente de um 
SGBD particular. É a primeira fase do projeto de um novo Banco de Dados, em que o modelo conceitual é obtido 
através de um Diagrama de Entidade-Relacionamento(ER).
No livro Sistema de Banco de Dados , os autores mostram uma descrição simplificada do processo de projeto 
de banco de dados visualizada na figura abaixo. 
ELMASRI, Rames; NAVATHE, Shamkant B. Sistema de Banco de Dados. Rio de Janeiro, 4ed.: LTC, 2000.
unidade b
Modelo ConCeitual
Projeto de Banco de Dados Relacional| Unidade B
7
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Na figura, a fase do projeto conceitual vem após o Levantamento e análise de requisitos, pois será a partir dos 
dados coletados que poderemos elaborar o modelo conceitual usado nesta fase. 
O objetivo desta primeira fase do projeto é elaborar uma descrição de quais dados serão armazenados no 
banco de dados independentemente de como serão implementados no banco de dados. A fase em que defini-
mos como o banco de dados será implementado no SGBD vem após a modelagem conceitual e chamamos de 
projeto lógico que é obtido a partir da transformação do Diagrama Entidade-Relacionamento em um modelo 
lógico, que implementa, a nível de SGBD relacional, os dados representados abstratamente no modelo ER.
5.1 Modelo Entidade-Relacionamento
O Modelo ER foi definido por Peter Chen em 1976, sendo representado através de um diagrama de entidade-
relacionamento (DER). Vamos estudar alguns conceitos centrais da abordagem entidade-relacionamento e em 
seguida poderemos elaborar os diagramas.
A seguir apresentamos os requisitos que foram adquiridos a partir da fase de levantamento e análise de 
requisitos. A partir dos requisitos será apresentado um exemplo de modelo ER, para que a partir deste exemplo 
possamos ir conhecendo conceitos para elaboração de um modelo ER.
Os requisitos foram elaborados a partir de uma empresa fictícia chamada “Sorriso”
A empresa está organizada em departamentos. Cada departamento tem um nome e um número único e um empr-• 
egado que gerencia o departamento. Temos a data em que o empregado começou a gerenciar o departamento.
Um departamento controla um numero qualquer de projetos, cada qual com um único nome, um único número e uma • 
única localização.
Armazenamos o nome de cada empregado, o número do cpf, endereço, salário. Um empregado está alocado a um • 
departamento, mas pode trabalhar em diversos projetos que não são controlados, necessariamente, pelo mesmo 
departamento. Controlamos o número de horas semanais que um empregado trabalha em cada projeto. Também 
controlamos o supervisor direto de cada empregado.
Queremos ter o controle dos dependentes de cada empregado para fins de seguro. Guardamos o primeiro nome, data • 
de nascimento de cada dependente e o parentesco dele com o empregado.
A figura, a seguir, é um exemplo de DER.
Projeto de Banco de Dados Relacional| Unidade B
8
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Para elaborar os diagramas de ER, precisamos em um primeiro momento conhecer alguns conceitos básicos 
desta abordagem. Os dados no modelo ER são descritos a partir de entidades, relacionamentos e atributos.
ENTIDADES:
A entidade é considerada o objeto básico representado no modelo ER. Pode ser um objeto do mundo real, 
por exemplo, uma pessoa ou um objeto com uma existência conceitual como, por exemplo, um curso.
A entidade é representada através de um retângulo contendo o nome da entidade. Cada entidade representa 
um conjunto de informações sobre o objeto representado, porém quando precisamos nos referir a apenas um 
objeto, denominamos de ocorrência de entidade.
Exemplo:
No exemplo acima o DEPARTAMENTO representa o conjunto de todos os departamentos que se deseja man-
ter informações.
Seguindo o exemplo de levantamento de requisitos e do modelo ER mostrado anteriormente, podemos 
identificar várias entidades como:
DEPARTAMENTO• 
PROJETO• 
EMPREGADO• 
DEPENDENTE• 
ATRIBUTO:
Cada entidade é representada por Atributos, que são características das entidades representadas. Por exem-
plo, a entidade DEPARTAMENTO, tem como atributos, o nome e o número.
Na prática, os atributos são representados textualmente para não sobrecarregar os diagramas, mas na figura 
abaixo, podemos ver como os atributos podem ser representados
Para Heuser entidade é um conjunto de obje-
tos da realidade modelada sobre as quais se 
deseja manter informações no banco de dados.
Projeto de Banco de Dados Relacional| Unidade B
9
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S A figura acima mostra que cada ocorrência de departamentopode ser representada por um número e nome. 
Por exemplo, vamos armazenar no nosso banco de dados um departamento que terá como numero ‘01’e nome 
‘Financeiro’.
No livro Sistema de Banco de Dados os autores identificam vários tipos de atributos:
Atributos compostos x Atributos simples: Os atributos compostos podem ser divididos em subpartes 
menores, que representam a maioria dos atributos básicos com significados independentes. Por ex-
emplo, o atributo endereço da entidade empregado por ser dividido em EnderecoRua, Cidade, Es-
tado, CEP. Os atributos que não são divisíveis são chamados de atributos simples. 
Atributos Monovalorados x Multivalorados: A maioria dos atributos tem um valor único para uma 
dada entidade; esses atributos são chamados monovalorados. Por exemplo, Idade é um atributo 
monovalorado de uma pessoa. Em alguns casos, um atributo pode ter um conjunto de valores para 
a mesma entidade - por exemplo, um atributo Cor para um carro ou um atributo Titulação para uma 
pessoa. Os carros com uma cor têm um valor único, enquanto aqueles com dois tons contêm dois va-
lores para a cor. Da mesma forma, uma pessoa pode não ter um título acadêmico, outra pessoa pode 
ter um, e uma terceira pessoa, dois ou mais títulos, portanto pessoas diferentes podem ter números 
de valores diferentes para o atributo Titulação. Esses atributos são chamados multivalorados. 
Atributos Armazenados x Derivados: Em alguns casos, dois (ou mais) valores de atributos estão rela-
cionados - por exemplo, os atributos Idade e DataNascimento de uma pessoa. Para uma entidade 
pessoa em particular, o valor de Idade pode ser determinado pela data corrente(hoje) e o valor de 
DataNascimento da pessoa. Portanto, o atributo Idade é chamado atributo derivado e é dito derivado 
do atributo DataNascimento, que por sua vez, é chamado atributo armazenado. Alguns atributos 
podem ser derivados de entidades relacionadas; por exemplo, um atributo NumerodeEmpregados, 
de uma entidade departamento, pode ser derivado da contagem do numero de empregados relacio-
nados nesse departamento.
Valores nulls (nulos): Em alguns casos, determinada a entidade pode não ter um valor aplicável a um 
atributo. Por exemplo, o atributo Apartamento de um endereço se aplica apenas a endereços que 
estão em edifícios de apartamentos, e não a outros tipos de residências, como as casas. Por analogia, 
um atributo titulação só se aplica a pessoas com titulação acadêmica. Para estas situações é criada um 
valor especial chamado null (nulo). 
Atributos Complexos: Observa-se que os atributos compostos e multivalorados podem ser aninhados 
de uma maneira arbitrária. Podemos representar essa organização agrupando os componentes de um 
atributo composto entre parênteses (), separando os componentes por meio de vírgulas e mostrando 
os atributos multivalorados entre chaves {}. Esses atributos são chamados de atributos complexos.
Considerando o exemplo da empresa e com as entidades já definidas podemos especificar os atributos de 
cada uma delas.
DEPARTAMENTO: nome e numero
PROJETO: codigo e nome
EMPREGADO: nome, cpf, endereço e salario
DEPENDENTE: nome, dt_nascimento e parentesco
Projeto de Banco de Dados Relacional| Unidade B
10
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Atributo identificador da entidade
Uma restrição importante das entidades de um tipo de entidade é a chave ou restrição de unicidade em atrib-
utos. Um tipo de entidade tem geralmente, um atributo cujos valores são distintos para cada uma das entidades 
do conjunto de entidade. Cada entidade deve possuir pelo menos um atributo identificador, este é representado 
pelo circulo preenchido.
Significa então que o atributo que identifica a entidade serve para que as ocorrências de entidade tenham 
uma forma de serem distinguidas uma das outras.
A entidade EMPREGADO pode ter como atributos:
cpf• 
endereco• 
salario• 
nome• 
EMPREGADO
CPF nome Endereço salário
12345566 Maria Av. Santos Camargo 860
34567789 Maria Av. Julio Matheus 980
A entidade Empregado guardará informações sobre o cpf, nome, endereço e saláriocde várias ocorrências de 
entidade. A partir do exemplo, podemos notar que podem existir pessoas que tenham o mesmo nome.
O atributo identificador tem a finalidade de especificar que o atributo que estiver como identificador será 
único, ou seja, não poderá repetir em nenhuma ocorrência de entidade. Como atributo identificador no exemplo 
acima, temos o CPF que não poderá se repetir
Os atributos identificadores também podem ser compostos, quando, por exemplo, as ocorrências de enti-
dades necessitem de atributos identificadores diferentes.
A chave é um tipo de restrição de inte-
gridade que representa regras de negó-
cio que visam garantir que não possam 
existir duas ou mais entidades com os 
mesmos valores de identificadores.
Projeto de Banco de Dados Relacional| Unidade B
11
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Relacionamento identificador da entidade 
Existem casos em que o identificador de uma entidade é composto de atributo e por relacionamentos em que 
a entidade participa.
Cada dependente é identificado pelo funcionário em que está relacionado e pelo nome e parentesco. Para 
identificar um relacionamento identificador usamos uma linha mais densa, conforme a figura acima. Alguns 
autores definem como a entidade DEPENDENTE sendo uma entidade fraca, pois esta depende da entidade FUN-
CIONÁRIO para existir.
RELACIONAMENTO
O relacionamento acontece entre as entidades quando existe algum tipo de associação entre estas. Um rela-
cionamento é representado através de um losango ligado por linhas as entidades.
No exemplo acima, temos a entidade Departamento e a entidade projeto, que estão relacionadas, pois os 
projetos são controlados por um departamento. 
Projeto de Banco de Dados Relacional| Unidade B
12
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Assim como nós referenciamos as ocorrências de entidades, podemos fazer o mesmo nos relacionamento. 
Com isso, quando quisermos nos referir a associações particulares dentro de um conjunto, vamos nos referir a 
ocorrências de relacionamentos.
Um tipo de relacionamento define um conjunto de associações – ou um conjunto de relacionamentos – entre 
as entidades.
Exemplo:
Consideramos um relacionamento Controla, entre dois tipos de entidade, Departamento e Projeto, que as-
socia cada controla a uma entidade de Departamento e Projeto. Pela figura acima, identificamos que um depar-
tamento pode controlar um projeto assim como pode controlar mais de um projeto
Auto-Relacionamento
Existe ainda um conceito em Relacionamento que é do auto-relacionamento. Neste tipo de relacionamento 
a relação ocorre com apenas uma entidade, ou seja, entre ocorrências da mesma entidade. Neste caso surge o 
conceito de papel da entidade, em que definimos qual é o papel da entidade em um relacionamento.
Exemplo:
Projeto de Banco de Dados Relacional| Unidade B
13
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S No exemplo acima, a relação que existe entre duas ocorrências de entidades podem ter papéis diferentes. O 
funcionário poder ser gerenciado por um funcionário gerente, assim como um funcionário pode gerenciar os 
funcionários subordinados.
Relacionamento Binários e Ternários (ou de grau superior)
Os relacionamentos vistos até o momento são identificados como Binários, por se tratar da relação entre 
duas entidades. Quando temos relação entre três entidades, chamamos de relacionamentos ternários.
Exemplo:
No exemplo acima, temos uma relação de controle, onde cada ocorrência da relação de controle associa três 
ocorrências de entidades: um projeto a ser controlado, um departamento onde será feito um controle e um 
funcionário.Identificando Relacionamentos.
Os relacionamentos também podem possuir atributos. Que serão características especificas que ocorrem 
durante o relacionamento não fazendo parte de nenhuma entidade em específico. 
No exemplo acima, podemos armazenar a data em que o departamento começou a controlar o projeto. 
Cardinalidade de Relacionamentos
Cardinalidade de Relacionamento é um conceito utilizado no modelo ER que melhora o conhecimento sobre 
as políticas e regras dos negócios, consistindo de números colocados ao lado do relacionamento.
Um exemplo para as cardinalidades seria a de um departamento que controla um projeto. As dúvidas que 
podem aparecer nesta relação seriam: 
Projeto de Banco de Dados Relacional| Unidade B
14
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Quantos projetos um departamento pode controlar?• 
O projeto deve ser controlado por apenas um departamento ou pode ser por mais de um?• 
Para projetarmos o nosso modelo de dados é essencial que conheçamos este tipo de questão e que estas 
sejam refletidas no nosso modelo.
Podemos acrescentar algumas dimensões nos nossos relacionamentos para tornar mais claras algumas 
questões:
DEPARTAMENTO controla “um ou mais projetos”
PROJETO é controlado por apenas um DEPARTAMENTO
Este modelo, agora, indica que um DEPARTAMENTO pode possuir muitos projetos. Porem cada PROJETO só 
poderá ser controlado por apenas um DEPARTAMENTO.
Para identificar estas características colocamos ao lado do relacionamento dados que representem as mes-
mas. Chamamos estes dados de cardinalidade do relacionamento.
 A cardinalidade define, portanto, o número de ocorrências de uma entidade que pode estar associada em 
um relacionamento, sendo útil para extrair as regras de consistência e integridade dos dados. Assim como define 
também se um relacionamento é obrigatório ou opcional.
Com isso, há duas cardinalidades a considerar: Cardinalidade Máxima e Cardinalidade Mínima.
Cardinalidade Máxima: Representa o numero de ocorrências que podem existir em um relacionamento sen-
do representado por “’1” ou “N”, ou seja, uma único relacionamento (1) ou muitos relacionamentos (N)
Cardinalidade Mínima: Representa a obrigatoriedade ou não do relacionamento sendo representado por “0” 
ou “1”, ou seja, o relacionamento é opcional (0) ou o relacionamento é obrigatório (1).
CARDINALIDADE (MÍNIMA MÁXIMA)
Exemplo:
No exemplo, podemos ler da seguinte forma: 
DEPARTAMENTO (1,1) CONTROLA (0,N) PROJETO
Um DEPARTAMENTO pode controlar nenhum (0) PROJETO. (cardinalidade mínima)
Um DEPARTAMENTO pode controlar muitos(N) PROJETOS. (cardinalidade máxima)
Projeto de Banco de Dados Relacional| Unidade B
15
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
OBS:
O “0” da cardinalidade mínima representa que é opcional o departamento controlar ou não um projeto e o “N” da cardinalidade máxima 
representa que um departamento pode controlar vários projetos.
Um PROJETO deve ser controlado por um(1) DEPARTAMENTO. (cardinalidade mínima)
Um PROJETO deve ser controlado por apenas um(1) DEPARTAMENTO. (cardinalidade máxima)
OBS:
O “1” da cardinalidade mínima representa que é obrigatório o projeto ser controlado por um departamento e o “1” da cardinalidade máxima 
representa que o projeto só pode ser controlado por um departamento.
ESPECIALIZAÇÃO e GENERALIZAÇÃO
Além dos atributos outras caracteristicas podemos associar as entidades. 
Especialização: 
É um processo de transformar uma entidade que podemos chamar de superclasse em outras subclasses. Por 
exemplo, as subclasses podem ser {motorista E engenheiro} e a superclasse seria FUNCIONÁRIO. É uma especial-
ização que distingue o FUNCIONÁRIO pelo tipo de trabalho
A figura acima é um exemplo do diagrama para uma especialização. Um relacionamento de superclasse com 
subclasse é freqüentemente chamado de IS-A (É UM), ou seja, O MOTORISTA é um FUNCIONÁRIO e o ENGEN-
HEIRO é um FUNCIONÁRIO. 
Em relação aos atributos, nos teremos os atributos na superclasse e na subclasse. Os atributos na super-
classe serão herdados na subclasse. Por exemplo, os atributos da entidade motorista são: código, nome, número 
carteira.
Quais seriam os principais motivos de fazer a especialização? Para Navathe, existem duas razões para se in-
cluir as especializações em um modelo de dados.
Projeto de Banco de Dados Relacional| Unidade B
16
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S A primeira é que certos atributos podem ser usados em algumas, mas não em todas as entidades da super-
classe. Uma subclasse é definida de forma a agrupar as entidades para as quais estes atributos se aplicam. Os 
membros de uma subclasse podem ainda, compartilhar a maioria de seus atributos com outros membros da 
superclasse. A segunda razão para usar as subclasses é que apenas as entidades que sejam membros de alguma 
subclasse possam participar de algum tipo de relacionamento.
Em resumo, o processo de especialização nos permite fazer o seguinte:
Definir um conjunto de subclasses de um tipo de entidade.• 
Estabelecer atributos específicos adicionais para cada subclasse.• 
Estabelecer tipos de relacionamentos adicionais específicos entre cada subclasse e outros tipos de entidade, ou outras • 
subclasses.
Generalização: 
É um processo contrário ao da especialização, que ocorre quando temos mais de uma entidade com atributos 
comuns entre elas e então neste caso podemos criar uma superclasse com os atributos em comum, utilizando 
assim o conceito da generalização.
Exemplo:
Entidade Carro: número passageiros, velocidade máxima, preço, número placa.
Entidade Caminhão: preço, número placa, numero eixos, capacidade.
Com a Generalização, podemos criar uma entidade VEICULO que terá como atributos, os em comum das 
entidades carro e caminhão.
ENTIDADE ASSOCIATIVA
Uma entidade associativa é utilizada quando entre o relacionamento de duas entidades 
verificamos a necessidade de relacionar com outra relação. Na modelagem er não foi 
prevista a possibilidade de associar dois relacionamentos entre si, porem na prática 
quando isso é necessário na modelagem devemos então transformar o relacionamento 
em uma entidade associativa.
Projeto de Banco de Dados Relacional| Unidade B
17
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Exemplo:
No exemplo acima, o FUNCIONÁRIO tem uma relação com o cliente de ATENDER. Mas vamos aumentar nosso 
exemplo, imaginando que o cliente FUNCIONÁRIO ALUGUE Fitas de DVD para o cliente a partir do atendimento. 
Para isso teremos que criar uma entidade FITAS. Mas o problema é em que entidade vamos relacionar as fitas, 
se relacionamentos com cliente ficará faltando a informação de que funcionário locou a fita para o cliente e se 
relacionarmos com o funcionário fica faltando a informação de que cliente locou a fita. Para resolver este prob-
lema devemos relacionar as Fitas à relação ATENDE. 
Para isso, podemos transformar o relacionamento ATENDE em uma entidade e esta entidade relacionar com 
FITA.
Projeto de Banco de Dados Relacional| Unidade B
18
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S CONSTRUÇÃO DE MODELO ER
Segundo Heuser, o Modelo ER tem algumas propriedades que são relevantes para se modelar.
UM MODELO ER DEVE SER FORMAL
ABORDAGEM ER TEM PODER DE EXPRESSÃO LIMITADO
DIFERENTES MODELOS PODEM SER EQUIVALENTES
Construção do modelo ER:
O modelo ER lista e define a estrutura requerida para construir um modelo de dados, mas não há um pro-
cesso padrão para fazê-lo. O importante é saber que o modelo ER não é construído de uma única vez, é um 
processo incremental, onde o modelo é construído em pequenos passos e pequenas transformações até chegar 
ao modelo completo.
Existem várias estratégias de modelagens sugeridaspelos autores, mas podemos dentro destas estratégias 
fazer uma combinação, o que é normalmente aplicado.
Antes de definir qual a estratégia de modelagem devemos identificar todas as descrições e conhecimentos 
possíveis sobre o processo o que normalmente é coletado na fase de análise de requisitos do sistema.
Um modelo ER é um modelo formal, preciso, não am-
bíguo. Isso significa que diferentes leitores de um mesmo 
modelo ER devem entender exatamente o mesmo. Tanto 
é assim, que um modelo ER pode ser usado como en-
trada em uma ferramenta CASE na geração de um banco 
de dados relacional. Por isso, é de fundamental importân-
cia que todos os envolvidos na confecção e uso de dia-
gramas estejam treinados na sua perfeita compreensão.
Em um modelo ER, são apresentadas apenas algumas 
propriedades de um banco de dados. Em realidade, a lin-
guagem nos modelos ER é uma linguagem muito pouco 
poderosa e muitas propriedades desejáveis do banco de 
dados necessitam ser anotados adicionalmente ao DER.
Na prática, muitas vezes, observa-se analistas em acirradas 
discussões a fim de decidir como um determinado objeto 
da realidade modelada deve aparecer no modelo. Às vezes, 
tais discussões são absolutamente supérfluas, pois os difer-
entes modelos ER, em qualquer das opções defendidas pe-
los diferentes analistas, geram o mesmo banco de dados
Projeto de Banco de Dados Relacional| Unidade B
19
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Sugestões de estratégias de modelagem:
HEUSER:
Estratégia “ TOP-DOWN”
Nesta estratégia, é sugerido que os conceitos possam ser refinados em conceitos mais detalhados. Partindo 
assim dos conceitos de entidades genéricas após os seus atributos e na seqüência os relacionamentos entre as 
entidades após os atributos de relacionamentos e por fim as especializações de entidades.
Modelo Superficial: Nesta primeira etapa, é construído um DER pouco detalhado (faltando domínios dos atributos e 1. 
cardinalidades mínimas de relacionamentos) na seguinte etapa:
a) enumeração das entidades;
b) identificação dos relacionamentos e hierarquias de generalização/especialização entre as entidades. Para cada rela-
cionamento identificam-se as cardinalidades máximas.
c) determinação de atributos de entidades e relacionamentos
d) determinação dos identificadores de entidades e relacionamentos
e) o banco de dados é verificado quanto ao aspecto temporal
modelagem detalhada2. 
a) adicionam-se os domínios dos atributos;
b) definem-se as cardinalidades mínimas dos relacionamentos
c) definem-se as demais restrições de integridade que não podem ser representadas pelo DER
Validação do modelo3. 
a) Procuram-se construções redundantes ou deriváveis a partir de outras no modelo
b) Valida-se o modelo com o usuário.
Dicas:
Sites com passos para construir um modelo de dados
http://www.sinfic.pt/SinficNewsletter/sinfic/Newsletter41/Dossier2.html
Projeto de Banco de Dados Relacional| Unidade C
20
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
6 . Modelo Lógico
Na unidade 5, trabalhamos com o modelo ER, no qual podemos, através dele, identificar as tabelas e relacio-
namentos entre outros itens que serão importantes no planejamento do nosso Banco de Dados. Esse modelo 
será identificado segundo a ilustração abaixo (fig. 1), retirada do livro Sistemas de Banco de Dados , logo após a 
análise de requisitos. Em seguida, vamos trabalhar com o PROJETO LÓGICO de um Banco de Dados Relacional e 
veremos a relação existente entre o modelo ER e um modelo lógico.
 6.1 Modelo relacional
o modelo de dados relacional usa o conceito de uma relação matemática, como se fosse uma tabela com 
valores. Os modelos que antecederam o modelo relacional são os modelos hierárquicos e modelos de rede.
unidade C
ModeLo LógiCo
Projeto de Banco de Dados Relacional| Unidade C
21
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Quando uma relação é usada como uma tabela de valores, cada linha desta relação representa uma coleção 
de valores de dados relacionados.
exemplo: 
PeSSoa
Codigo Nome Telefone Endereço
1 Maria 232323 Av. JK
2 José 242424 Av. JB
3 Carla 252525 Av.JX
No exemplo acima, a linha com o código 1 representa os dados relacionados de uma pessoa que mora na Av. 
JK, com telefone de número 232323 cujo nome é Maria.
Associando com a unidade 5 (modelo conceitual), onde cada entidade e relacionamento modelava um objeto 
do mundo real. Na abordagem relacional, cada linha representa dados de uma ocorrência de entidade. No caso 
acima a entidade PESSOA do modelo conceitual representa a relação no modelo relacional.
O modelo relacional formal chama cada linha de uma tabela de tupla, o cabeçalho da coluna é chamado de 
atributo e o conjunto ordenado das linhas é denominado de tabela ou relação. E ainda podemos definir o tipo 
de dado que descreve os valores que podem aparecer nas tabelas como domínios.
nome da Tabela (Relação) atributos
PeSSoa
Nome Telefone Endereço
Maria 232323 Av. JK
José 242424 Av. JB
 Linhas (Tuplas)
Para identificar cada tupla e estabelecer relações entre estas o conceito básico é o da chave.
Vamos considerar o que o autor Heuser descreve sobre chave no seu livro Projeto de Banco de Dados . Neste 
ele considera três tipos de chaves: chave primária, chave alternativa e chave estrangeira. 
CHaVe PRiMÁRia:
Como exposto anteriormente, uma tabela é constituída por uma lista ordenada de valores, ou seja, por tup-
las. Como forma de garantir que não aconteça a duplicidade dessas tuplas, utiliza-se o procedimento de inserir 
nessa tabela uma chave. 
A chave funciona como identificadora de uma tupla, garantindo, assim, a regra da unicidade. 
Uma tabela é um conjunto de tuplas, 
onde cada tupla é uma lista ordenada de valores.
Projeto de Banco de Dados Relacional| Unidade C
22
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S A chave que identifica uma tabela é denominada de chave primária, podendo ser composta por um ou mais 
campos da tabela em questão. A especificação de uma chave define uma restrição de integridade, ou seja, uma 
regra que garante que a unicidade será obedecida em todos os estados do Banco de Dados.
exemplo: 
aLuno
Codigo Nome Endereco
1 Maria Av. JK
2 José Av. JB
3 Pedro Av. JC
aLuno
Nome Endereco
Maria Av. JK
José Av. JB
José Av. JC
não será inserido, pois a chave não permite a duplicidade, no caso da chave primária ser o nome.
Na tabela acima, o valor de um atributo chave é usado para identificar, unicamente, cada tupla, pois, o atribu-
to “nome de aluno” pode receber um valor igual, ou seja, ter mais de um aluno com o mesmo nome. Se o campo 
“nome do aluno” for indicado como chave, será garantida a regra da unicidade, contudo, quando há a ocorrência 
de nomes iguais, apenas um é inserido, no caso o primeiro. Nesse caso, procede-se a criação de um campo, pref-
erencialmente numérico, que fará a identificação da tupla, podendo assim, serem gravados nomes iguais que, 
entretanto, constituem tuplas diferentes.
exemplo: 
aLuno
Codigo Nome Endereco
1 Maria Av. JK
2 José Av. JB
3 José Av. JC
o campo código permite a inclusão de homônimos, sem desrespeitar a regra da unicidade
CHaVe eSTRangeiRa:
Uma chave estrangeira é um atributo ou uma combinação de atributos que aparecem necessariamente como 
chave primária em outra tabela.
aLuno
Cd_Aluno Nome_Aluno End_Aluno Cd_Curso
1 Maria Av. JK 3
2 José Av. JB 2
3 Pedro Av. JC 3
Projeto de Banco de Dados Relacional| Unidade C
23
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S CuRSo
Cd_Curso Nome_Curso Sigla_Curso
1 Informatica INF
2 Quimica QUI
3 Biologia BIO
Nas tabelas acima podemos identificarque o Cd_Curso da relação CuRSo é uma chave estrangeira em rela-
ção a chave primária da tabela aLuno. Com esta relação podemos identificar que todo aluno esta relacionado a 
um curso através de um atributo Cd_Curso.
Exemplo:
O aluno José está vinculado ao curso de Química• 
O aluno Pedro está vinculado ao curso de Biologia• 
A aluna Maria está vinculada ao curso de Biologia• 
CHaVe aLTeRnaTiVa:
Quando podemos identificar mais de uma chave em uma tabela, escolhemos uma como chave primária e as 
demais são consideradas chaves alternativas. 
PeSSoa
Codigo Nome Telefone CPF
1 Maria 232323 90909090990
2 José 242424 808080808080
No exemplo acima, podemos usar tanto o código como o CPF para identificar a unicidade da linha.
6.2 Restrições do modelo relacional
Até aqui vimos características de uma única tabela em um banco de dados, normalmente haverá muitas 
relações e as tuplas se relacionamento de diversas maneiras. Há muitas restrições em um Banco de dados para 
seus valores reais.
Vamos ver algumas restrições no Banco de dados Relacional:
Restrição de domínio:
Como já foi apresentado no item anterior, cada coluna de uma tabela é representada por um atributo. Quan-
do uma tabela é definida, em cada coluna serão atribuídos valores para os campos. Ao conjunto de valores 
atribuídos chamamos de domínio do campo. 
Para especificação de domínio, podemos:
Definir o tipo de dado aceito pelos valores incluídos. • 
Podemos usar como referência os tipos de dados oferecidos pelo padrão SQL-99• 
Projeto de Banco de Dados Relacional| Unidade C
24
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Tipo de Dado Descrição
INTEGER ou INT Número positivo ou negativo inteiro. O número de 
bytes que pode ser utilizado varia em função do banco 
de dados utilizado.
SMALLINT Mesma função do INTEGER, mas ocupa cerca da 
metade do espaço.
NUMERIC Número positivo ou negativo de ponto flutuante. 
Normalmente, deve¬ se informar o tamanho total do 
campo e definir quantas casas decimais devem ser ar-
mazenadas após a vírgula.
DECIMAL Semelhante ao NUMERIC, mas, em alguns bancos 
de dados, poderá ter uma maior precisão após a vír-
gula.
REAL Número de ponto flutuante de simples precisão. A 
diferença básica é que os valores serão armazenados 
em representação exponencial, portanto serão arre-
dondados para o nível mais próximo de precisão.
DOUBLE PRECISION Número de ponto flutuante de dupla precisão. 
Comporta-se como o REAL, mas permite maior aproxi-
mação de resultados.
FLOAT Número de ponto flutuante em que você define o 
nível de precisão (número de dígitos significativos).
BIT Armazenamento de um número fixo de bits. O 
número de bits deve ser indicado, do contrário o 
padrão será 1.
BIT VARYING Igual ao BIT, permitindo armazenar valores maiores. 
Normalmente, utiliza-se para armazenamento de ima-
gens.
DATE Permite armazenar datas.
TIME Permite armazenar horários.
TIMESTAMP Permite armazenar uma combinação de data e 
hora.
CHARACTER ou CHAR Permite armazenar cadeias de caracteres (letras, 
símbolos e números). 0 tamanho deve ser informado 
e será fixo, ou seja, mesmo que não utilizado total-
mente, será ocupado o espaço fisicamente. O valor 
definido será o tamanho máximo da cadeia armazena-
da.
CHARACTER VARYING ou VARCHAR Permite armazenar cadeias de caracteres, mas com 
tamanho variável. Nesse caso, especifica-se o taman-
ho máximo da coluna. Se for utilizado menos espaço 
que o máximo definido, o espaço restante não será 
ocupado.
INTERVAL Intervalo de data ou hora.
Tabela extraída do livro: OLIVEIRA, Celso Henrique Poderoso. SQL Curso Prático. São Paulo: Novatec, 2002
Projeto de Banco de Dados Relacional| Unidade C
25
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Restrição de Chave e Valores null
Restrição de Chave
No item 5, apresentamos as chaves primárias, estrangeira e candidata. Estas chaves especificam uma re-
strição de unicidade, na qual duas linhas diferentes serão distinguidas pela chave atribuída. 
Valores nulos
Outro exemplo de restrição é a especificação de valores nulos. Podemos especificar, com isso que um cam-
po não poderá ser nulo.
Integridade da Entidade
Uma entidade integra estabelece os valores de chave primária não podem ser nulos, caso isso ocorra não 
poderemos distinguir as linhas através da chave primária. 
6.3 Transformar um Modelo Conceitual em Modelo Relacional (modelo lógico)
O esquema de um Banco de dados relacional (modelo lógico) deve ter no mínimo as relações que formam o 
Banco, os atributos que as relações possuem e as restrições do modelo.
1º RegRa - TRanSFoRMaR enTidade ReguLaR eM uM ReLaÇÃo
Em relação ao exemplo acima vamos fazer o primeiro regra para transformação, que é transformar toda 
entidade regular em uma relação que inclua todos os atributos simples, trata-se de uma tradução inicial que na 
seqüência poderá ser fundida com outra entidade.
Para representar o modelo lógico vamos utilizar as mesmas notações utilizadas na bibliografia do HEUSER que 
será explicado neste primeiro exemplo:
Com isso a entidade PESSOA é transformada em uma tabela PESSOA e cada atributo da entidade é transfor-
mado em uma coluna da tabela sendo que o atributo chave primária será identificado com um sublinhado.
Para cada tipo de entidade regular 
transformar em uma relação que 
inclua todos os atributos simples
Pessoa(Codigo, Sexo, Nome)
Projeto de Banco de Dados Relacional| Unidade C
26
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S 2º RegRa – TRanSFoRMaR uMa enTidade FRaCa
 Dependente(Numero, Codigo, Data_Nascimento, Nome)
3º RegRa – TRanSFoRMaR ReLaCionaMenToS BinÁRioS 1:1
Quando temos este tipo de relação, há algumas opções para a transformação:
1º opção: Escolher uma das tabelas e inserir nela como chave estrangeira a chave primária do outra tabela. 
No nosso exemplo acima, temos a relação entre uma entidade pessoa e departamento. 
O próximo passo é analisar a relação existente. Como o relacionamento é binário 1:1 vamos usar a 1º opção e 
inserir em uma das entidades a chave primária da outra. É melhor escolher, entre as duas entidades, aquela com 
participação total, ou seja, a entidade de departamento que preve a obrigatoriedade de ter um gerente. Ainda 
na entidade escolhida para receber a chave estrangeria também inserimos os atributos do relacionamento.
Para cada tipo de entidade fraca trans-
formar em uma relação que inclua to-
dos os atributos simples e mais a chave 
primária da entidade dependente. 
Ambas passam a ser a chave primária 
composta da relação dependente.
Desta forma estamos apenas transformando as entidade regulares em tabelas:
Pessoa(Codigo, Nome, Sexo)
Departamento(Numero, Nome)
Projeto de Banco de Dados Relacional| Unidade C
27
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
observação da notação
�Para�representar�a�chave�estrangeira,�após�a�definição�da�relação�que�contém�chave�estrangeira�descrevemos:
<nome�da�coluna�ch.�Estrangeira>�referencia�<nome�da�relação>
2º opção: Nesta opção, pode-se fazer uma fusão entre as entidades participantes. Normalmente ocorre 
quando as duas entidades têm participação total, ou seja, a cardinalidade mínima nas duas entidades é 1.
Congressoequipe(Codigo, nome, nomeequipe, data)
Neste exemplo, fizemos a fusão das duas entidades em uma única relação incluindo os atributos das duas entidades 
e do relacionamento. No exemplo acima tivemos que alterar o nome da equipe para NomeEquipe já que o atributo de 
congresso também estava identificado por Nome.
diCaS:
Nos�exemplos�estamos�colocando�como�nome�de�coluna�os�nomes�dos�atributos.�Para�os�exercícios�é�importante�que�criemos�uma�no-
menclatura para esta conversão. Por exemplo:
Codigo = Cod
Numero = No
A�recomendação�é�que�se�use�sempre�a�mesma�abreviatura�em�todas�as�relações�do�Banco�de�Dados.Tabela�Proposta�por:�HEUSER,�Carlos�Alberto.�Projeto�de�Banco�de�Dados.�Porto�Alegre:�Sagra�Luzato,�1999.
Pessoa(Codigo, Nome, Sexo)
Departamento(Numero, Codigo, Nome, Data_Inicio)
Codigo referencia Pessoa
Projeto de Banco de Dados Relacional| Unidade C
28
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S 4º RegRa – TRanSFoRMaR ReLaCionaMenToS BinÁRioS 1:n
 Para cada tipo de relacionamento Binário 1:N identificar a entidade participante do lado N e inserir como 
chave estrangeira a chave primária do outra entidade. Isso é feito porque cada instância de entidade do lado N 
está relacionada a no máximo uma instância do lado 1.
Pessoa (Codigo,Nome, Sexo, Numero)
Numero referencia Departamento
Departamento(Numero, Nome)
No exemplo acima, inserimos a chave primária de departamento como chave estrangeira na relação Pessoa.
Tabela�Proposta�por:�HEUSER,�Carlos�Alberto.�Projeto�de�Banco�de�Dados.�Porto�Alegre:�Sagra�Luzato,�1999.
5º RegRa – TRanSFoRMaR ReLaCionaMenToS BinÁRioS n:M
Neste caso, para cada tipo de relacionamento cria-se uma tabela nova. Inserir como chave estrangeira as 
chaves primárias das duas tabelas que fazem parte e as duas chaves irão representar a chave primária da nova 
tabela.
Também devemos incluir todo tipo de atributo que tiver na relação entre as entidades. 
Projeto de Banco de Dados Relacional| Unidade C
29
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
Pessoa(Codigo, Nome, Sexo)
Projeto(Numero, Nome)
Trabalha(Codigo, Numero, horas)
Código referencia Pessoa
Numero referencia Projeto
O Diagrama acima gerou 3 relações, uma para entidade pessoa outra para entidade projeto e outra para a 
relação trabalha.
A relação trabalha ficou composta de duas chaves primárias, código da entidade Pessoa e Numero da enti-
dade Projeto. E ainda faz parte desta relação o atributo horas do relacionamento trabalha.
Tabela�Proposta�por:�HEUSER,�Carlos�Alberto.�Projeto�de�Banco�de�Dados.�Porto�Alegre:�Sagra�Luzato,�1999.
6º RegRa – TRanSFoRMaR ReLaCionaMenToS n-ário:
Para transformar relacionamentos n-ários deve seguir os seguir os seguintes passos:
Transformar o relacionamento em uma entidade e esta entidade fica ligado através de um relacionamento binário com 1. 
as outras entidades.
Aplicar as regras para os relacionamentos binários.2. 
Projeto de Banco de Dados Relacional| Unidade C
30
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Exemplo:
 
Seguindo os passos para a transformação acima, temos o seguinte modelo relacional:
Produto(• CodProd, Nome)
Cidade(• CodCid, Nome)
Distribuidor(• CodDistr, Nome)
Distribuição(• CodProd, CodCid,CodDistr, DataInicio)
CodProd referencia Produto•	
CodCid Referencia Cidade•	
CodDistr Referencia Distribuidor•	
Projeto de Banco de Dados Relacional| Unidade C
31
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S 7º RegRa – TRanSFoRMaR geneRaLiÇÕeS / eSPeCiaLiZaÇÕeS
Existem duas opções no caso de Generalização / Especialização:
1º) Utilizar uma tabela para cada entidade
2º) Utilizar uma tabela para toda Generalização / Especialização
 
1º caso – Uma relação para cada entidade
Acrescentar à chave primária da tabela correspondente a entidade genérica, em cada tabela correspondente a uma • 
entidade especializada.
Carro (Placa, Ano, Modelo, Marca)
Placa referencia Veiculo
Caminhao(Placa, Capacidade, Marca)
Placa referencia Veiculo
2º caso – Fusão em um única relação
Veiculo (Placa, Ano, Modelo, MarcaCarro, Capacidade, MarcaCaminhao)
No exemplo de modelo relacional acima temos a chave primária Placa que foi derivada da entidade General-
izada e todos os atributos das entidades especializadas se tornaram colunas na tabela.
6.4 Normalização de dados
Uma categoria importante de restrições são as dependências de dados, que incluem as dependências funcio-
nais e as multivaloradas. Estas restrições são usadas para certificar o projeto de banco de dados relacional e são 
utilizadas em um processo chamado Normalização.
Este processo faz com que uma relação passe por diversos testes para que satisfaça uma forma normal.
A normalização de dados é uma seqüência de processos executados nas tabelas em função das suas de-
pendências funcionais e chaves primárias para alcançar algumas propriedades como:
Minimização de redundâncias;• 
Minimização de anomalias de inserção, exclusão e atualização.• 
Há cinco regras que se aplicam a Banco de dados:
Primeira Forma Normal (1FN)• 
Segunda Forma Normal (2FN)• 
Terceira Forma Normal (3FN)• 
Projeto de Banco de Dados Relacional| Unidade C
32
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Quarta Forma Normal (4FN)• 
Quinta Forma Normal (5FN)• 
oBS:
Pode-se�ter�um�modelo�estável�atingindo�a�terceira�forma�normal�sendo�a�quarta�e�a�quinta�utilizada�em�casos�específicos�apenas�quando�
for necessário.
Exemplo de uma tabela Não Normalizada:
cd_Aluno nome_aluno dt_nascimento nome_disciplina
1 Vera 2/6/1982 Português, matemática
2 Tânia 9/12/1981 História, matemática
3 Matias 12/11/1980 Português, história
4 Carlos 7/4/1979 História, matemática
5 Sérgio 25/2/1982 Português, matemática
6.4.1 Primeira Forma normal (1Fn)
Para uma tabela estar na 1FN não poderá conter atributos multivalorados, compostos e combinação entre 
eles, com isso os atributos devem possuir valores atômicos (indivisíveis). 
Vamos utilizar o exemplo da tabela não normalizada acima.
Problema: A coluna disciplina possui atributos multivalorados, que não pode haver na 1FN.
Solução: Para cada disciplina fazer um cadastro novo de Aluno
cd_aluno cd_disciplina nome_aluno dt_nascimento nome_disciplina
1 1 Vera 2/6/1982 Português
2 2 Vera 2/6/1982 Matemática
3 3 Tânia 9/12/1981 História
4 2 Tânia 9/12/1981 Matemática
5 1 Matias 12/11/1980 Português
6 3 Matias 12/11/1980 História
7 3 Carlos 7/4/1979 História
8 2 Carlos 7/4/1979 Matemática
9 1 Sérgio 25/2/1982 Português
10 2 Sérgio 25/2/1982 Matemática
Problema: Com isso, estamos ocasionando o problema de redundância de dados, pois os atributos de alunos 
estão sendo repetidos para a inclusão de novas disciplinas.
A primeira forma normal não permite também atributos multivalorados que 
sejam compostos. São chamados de relações aninhadas, pois contém uma 
relação em cada tupla.
Projeto de Banco de Dados Relacional| Unidade C
33
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
6.4.2 Segunda Forma normal (2Fn)
Para resolver o problema da redundância de dados, passamos esta tabela para segunda forma normal. Para 
isso é preciso: A tabela estar na primeira forma normal e todos os atributos da tabela deve ser dependentes 
funcionais da chave completa e não de parte da chave. Uma tabela com uma chave primária formada por apenas 
um atributo esta automaticamente na 2FN.
Exemplo transformando a tabela que esta na 1FN acima
cd_aluno nome_aluno dt_nascimento
1 Vera 2/6/1982
2 Tânia 9/12/1981
3 Matias 12/11/1980
4 Carlos 7/4/1979
5 Sérgio 25/2/1982
cd_disciplina nome_disciplina
1 Português
2 Matemática
3 História
6.4.3 Terceira Forma normal (3Fn)
Para a transformação na 3FN, eliminamos um outro tipo de redundância de dados. Para transformação pre-
cisamos analisar se os atributos não-chave dependem diretamente da chave primária ou se dependem de outros 
atributos não chave.
Chamamos de dependência transitiva quando uma coluna, além de depender da chave primária da tabela, 
depende também de outra coluna ou conjunto de colunas da tabela.
Referências:
�ELMASRI,�R.�NAVATHE,�Sistemas�de�Banco�de�Dados.�4ª�Edição:�Addison-Wesley,�2008.�
�HEUSER,�Carlos�Alberto.�Projeto�de�Banco�de�Dados.�Porto�Alegre:�Sagra�Luzzatto,�1998
Projeto de Banco de Dados Relacional| Unidade C
3
S
is
te
m
a 
U
ni
ve
rsid
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
ATIVIDADE 01
Utilize as regras de transformação de modelos ER para modelo lógico relacional, projete um Banco de dados 
relacional para os Diagramas a seguir:
A)
B)
unIDADE C
Projeto de Banco de Dados Relacional| Unidade C
4
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
C)
D)
Projeto de Banco de Dados Relacional| Unidade D
39
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
unidaded
LinGuaGeM de 
COnSuLTa eSTRuTuRada
7. Linguagem de Consulta estruturada - SQL
SQL (Structured Query Language – Linguagem de Consulta Estruturada) É uma linguagem Estruturada padrão 
para acessar dados em um SGBD(Sistema Gerenciador de Banco de Dados) Relacional. Em resumo SQL é uma 
linguagem de consulta a banco de dados, em que informamos o que queremos e o SGBD escolhe adequada-
mente 
 7.1 COMPOnenTeS da LinGuaGeM SQL
DDL (Data Definition Language) = Linguagem de Definição de Dados
Permite aos usuários a criação de novos componentes como tabelas e índices.
exemplo:
CREATE TABLE
ALTER TABLE Referente a tabelas
DROP TABLE
CREATE INDEX
ALTER INDEX Referente a índices 
DROP INDEX
DML (Data Manipulation Language) = Linguagem de Manipulação de Dados
Permite aos usuários manipular os dados armazenados no Banco de Dados
INSERT
DELETE
UPDATE
DCL (Data Control Language) = Linguagem de Controle de Dados
Permite controlar autorizações de dados e licenças a usuários para o controle do Banco de Dados
CREATE USER
ALTER USER
GRANT 
REVOKE
DQL (Data Query Language) = Linguagem de Consulta de Dados
Permite elaborar consultas ao Banco de Dados.
SELECT
Projeto de Banco de Dados Relacional| Unidade D
40
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S 7.1.1 TABELAS / DDL (Data Definition Language)
CRIAR TABELAS•	
EXCLUIR TABELAS•	
ALTERAR TABELAS•	
INCLUIR LINHAS EM TABELAS•	
ATUALIZAR LINHAS EM TABELAS•	
EXCLUIR LINHAS EM TABELAS•	
 A) CRIAÇÃO DE TABELAS:
Sintaxe para criação de tabelas:
nome_da_tabela	=	nome	da	tabela	gerada	a	partir	do	modelo	lógico	(deve	ser	único)
nome_da_coluna = nome	da	coluna	referente	a	tabela	que	também	deverá	ser	único	na	tabela.
tipo_coluna =	tipo	de	dado	da	coluna	(ver tabela 1)
DICAS:
Para os nossos exemplos, serão usados como referência os tipos de dados utilizados no SGBD PostrgreSQL.
http://pgdocptbr.sourceforge.net/pg80/datatype.html 
Dependendo do SGBD que você for utilizar, deverá verificar os tipos de dados em específico para o mesmo.
coluna constraint =• regras das colunas
constraint_da_tabela =• regras das tabelas
Constraints	são	regras	que	podemos	definir	tanto	para	colunas	como	para	tabelas	,veremos	algumas	con-
straints	de	forma	geral,	mas	ao	utilizar	o	SGBD	deverá	ser	analisado	as	constraints	em	específico.
Chave primária =• 	É	coluna	ou	um	conjunto	de	colunas	que	identifica	um	registro	único	na	tabela
Sintaxe: 
PRIMARY KEY (nome_da_coluna)
Exemplo: 
PRIMARY KEY (Codigo_Funcionario)
Chave estrangeira =• É uma coluna ou conjunto de colunas que referencia a chave primária de outra tabela
Sintaxe: 
FOREIGN KEY nome_da_chave_estrangeira (lista_de_colunas)
REFERENCES nome_tabela
ON UPDATE ação
ON DELETE ação
CREATE TABLE nome_da_tabela
(nome_da_colunax	tipo_colunax	colunax	constraint,
nome_da_colunay	tipo_colunay	colunay	constraint,
constraint_da_tabela)
Projeto de Banco de Dados Relacional| Unidade D
41
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Exemplo: 
FOREIGN	KEY	codigo_Funcionario_fk	(codigo_funcionario)•	
REFERENCES funcionario•	
ON UPDATE CASCADE•	
ON DELETE RESTRICT •	
Significado:• 
nome_da_chave_estrangeira • = nome opcional para a chave estrangeira
lista_de_colunas = • colunas que fazem referencia a outras tabelas
nome_tabela =• nome da tabela onde esta a chave primária
ação = • quando alteramos (UPDATE) ou excluímos (DELETE) uma linha da tabela que contém como referência esta 
chave podemos determinar algumas ações:
CASCADE: exclui ou altera todos os registros que estão relacionados a coluna.
RESTRICT: não permite excluir ou alterar a chave primária referenciada
NO ACTION:em caso de alteração, não modifica os valores que se relacionam a eles.
SET NULL: altera o valor da coluna para nulo
SET DEFAULT: altera o valor da coluna para o valor especificado na cláusula DEFAULT se houver)
DEFAULT =• 	atribuir	conteúdo	padrão
Sintaxe: nome_da_coluna Tipo_de_dado DEFAULT valor
Exemplo:			quantidade	INTEGER	DEFAULT	1
NOT NULL =• 	quando	especificar	esta	constraint	significa	que	o	valor	da	coluna	não	poderá	ser	nulo,	caso	
não seja digitado nenhum valor para o campo, o banco de dados retornará um erro.
Exemplo:	quantidade	INTEGER	NOT	NULL
Significa	que	nunca	poderemos	deixar	a	coluna	quantidade	sem	valor.
UNIQUE =• 		indica	que	em	uma	coluna	não	poderá	haver	repetições	mas	poderá	ter	valores	nulos,	no	caso	da	
chave	primária	que	não	pode	haver	repetições	também	não	pode	haver	valores	nulos.
Exemplo:			quantidade	INTEGER	UNIQUE
Significa	que	para	cada	quantidade	especificada	deve	haver	um	valor	para	coluna	diferente.
CHECK	=	quando	especificamos	a	constraint	CHECK	podemos	definir	domínios	para	as	colunas,	com	isso		•	
especificamos	valores	possíveis	para	a	coluna.
SEXO CHAR(1) CHECK (UPPER(SEXO) = ‘M’ OR UPPER(SEXO) = ‘F’)
Significa que a coluna sexo deverá ter os valores F ou M
No	exemplo	acima	 temos	a	adição	de	alguns	 conceitos	novos	que	 iremos	 trabalhar	antes	de	 continuar	a	
demonstração de comandos:
 B) ALTERAÇÃO DE TABELAS
Para	alterar	tabelas	utilizamos	o	comando	ALTER	TABLE,	a	seguir	mostraremos	exemplos	de	alterações	que	
poderemos	fazer	dependendo	do	SGBD	utilizado.		
Acrescentar nova coluna na tabela existente•	
ALTER TABLE livro
 add	quantidade	INTEGER
Acrescentar Constraints em tabelas•	
Projeto de Banco de Dados Relacional| Unidade D
42
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S ALTER TABLE livro
 add PRIMARY KEY (issn)
Acrescentar	modificações	em	Colunas•	
ALTER TABLE livro
 MOdiFY	quantidade	INTEGER	NOT	NULL
Excluir colunas ou Constraints•	
ALTER TABLE livro
 deLeTe	quantidade	// excluir a coluna quantidade da tabela livro
ALTER TABLE livro
 deLeTe primary key // excluir uma constraints
CURIOSIDADES
No POSTGRESQL para exclusão de colunas se usa o comando DROP e não DELETE.
Alterar nomes de Tabelas ou Colunas•	
ALTER TABLE livro
 RenaMe Liv // alterar nome de tabela
ALTER TABLE livro
 RenaMe	quantidade	TO quant_livros // alterar nome de coluna
 C) EXCLUSÃO DE TABELAS
dROP TaBLe livro
 
 7.1.2 DML (Data Manipulation Language) = Linguagem de Manipulação de Dados
INSERIR LINHAS EM TABELAS•	
APAGAR LINHAS EM TABELAS•	
ATUALIZAR LINHAS EM TABELAS•	
No	postgreSQL	pode	ser	especificado	após	o	nome	da	tabela:
CASCADE=Remove	automaticamente	os	objetos	que	dependem	da	tabela	(como	as	visões).
RESTRICT=Recusa	remover	a	tabela	se	existirem	objetos	que	dependem	da	mesma.	Este	é	o	padrão.
Exemplo: DROP TABLE livro CASCATE
Projeto de Banco de Dados Relacional| Unidade D
43
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S A) INCLUIR LINHAS EM TABELAS
Utilizando	o	exemplo	abaixo,	vamos	incluir	informações	na	tabela	a	partir	do	comando	inSeRT inTO.
inSeRT inTO Livro // quando não forem especificadas as colunas subtende-se que serão incluídos valores 
em todas as colunas
VALUES (1, 2, ‘Introdução à Programação’)
OU 
inSeRT inTO Livro (codigo_livro, codigo_editora, nome) //especificando o nome das colunas
VALUES (1, 2, ‘Introdução à Programação’)
B) EXCLUIR LINHAS EM TABELAS
Podemos através do comando DELETE, excluir uma ou mais linhas em uma tabela.
DELETE FROM livro
Podemos	definir	um	limite	para	exclusão	através	da	cláusula	WHeReDELETE FROM livro
 WHERE codigo_livro=3;
Com	isso,	o	registro	da	tabela	livro	que	tiver	como	código	3	será	excluída
C) ATUALIZAR TABELAS
Utilizamos	o	comando	uPdaTe	para	atualizar	o	conteúdo	de	uma	ou	mais	colunas.	
UPDATE livro
SET nome = ‘INTRODUÇÃO À PROGRAMAÇÃO’
WHERE codigo_livro = 2;
No exemplo acima, alteramos (SET) a coluna nome da tabela livro. Em que o nome passou a ser INTRODUÇÃO 
A	PROGRAMAÇÃO.	Esta	alteração	ocorreu	na	linha	em	que	a	coluna	codigo_livro	possuía	valor	2,	para	isso	uti-
lizamos a cláusula WHERE.
CREATE TABLE livro (
codigo_livro INTEGER NOT NULL
codigo_editora INTEGER NOT NULL
nome VARCHAR(60)
PRIMARY KEY (codigo_livro)
FOREIGN KEY (codigo_editora)
REFERENCES gravadora (codigo_editora)
Projeto de Banco de Dados Relacional| Unidade D
44
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S 7.1.3 DQL (Data Query Language) = Linguagem de Consulta de Dados
SELECT =	é	um	comando	utilizado	para	relacionar	atributos	desejados	em	uma	consulta.	Após	o	SeLeCT rela-
cione	os	atributos,	se	desejar	que	todos	os	atributos	apareçam	no	resultado	utilize	um	“*”	(asterisco).
select	[coluna_1,	...	,	coluna_n]
FROM =	é	o	comando	utilizado	para	referenciar	as	relações	utilizadas
from	[tabela_1,	...	,	tabela_n]
WHERE =	Após	a	cláusula	where,	segue	uma	condição	ou	um	conjunto	de	condições	que	tem	a	função	de	
limitar	o	numero	de	linhas	mostradas	na	relação	de	saída.	A	cláusula	where	é	optativa.
where	[condição_1	...
exemplo:
BANCO
CodBanco NmBanco
01 Atual
02 SulReal
03 Poupar
04 DinMaster
DICAS:
Todas as operações realizadas com sql são feitas em tabelas e geram uma nova tabela.
AGENCIA
CodAgencia EndAgencia NrAgencia CodBanco
01 Av. Julio de Cássio 2665 01
02 Rua Felipe Almarante 2666 01
03 Rua Cássio Jair 5869 03
04 Av. Sergio Afonso 5868 03
05 Rua Carla Maria 9632 02
Quando	utilizar	mais	de	uma	relação	após	o	FROM		e	se	houver	um	mes-
mo nome de coluna em mais de uma relação. Informe:
nome_da_tabela.nome_da_coluna (nome da tabela seguido de um pon-
to e nome da coluna)
Modelo Lógico
Banco(CodBanco, NmBanco)
Agencia (CodAgencia, EndAgencia, NrAgencia, CodBanco)
CodBanco referencia Banco
Projeto de Banco de Dados Relacional| Unidade D
45
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S EXEMPLO DE CONSULTA 01
SeLeCT *
FROM agencia
WHeRe end_agencia = ‘Av. Julio de Cássio’;
No exemplo ao lado, selecionamos todas as colunas 
da	tabela	agencia.	Nestas	colunas,	o	where	colocou	como	
condição	que	a	coluna	End_Agencia	tivesse	como	conteúdo	
Av. Julio de Cássio.
Resultado da Consulta:
CodAgencia EndAgencia NrAgencia CodBanco
01 Av. Julio de Cássio 2665 01
EXEMPLO DE CONSULTA 02
SELECT *
FROM agencia
WHERE cod_banco = 03
ORDER BY nr_agencia DESC;
ORDER	BY	=	após	a	palavra	order	by,	devem	ser	especificadas	as	colunas	que	se	deseja	classificar	em	ordem	
crescente ou decrescente.
Crescente	-	após	o	nome	da	coluna,	deve-se	inserir	a	palavra	asc.	
Decrescente	-	após	o	nome	da	coluna,	deve-se	inserir	a	palavra	desc.
USANDO DISTINCT OU ALL
DISTINCT = não mostra valores repetidos das colunas
ALL = mostra todos os valores das colunas
SELECT DISTINCT *
FROM agencia
Após	o	final	do	código	da	pesquisa,	deve-se	acrescen-
tar	 um	 sinal	 de	ponto-e-vírgula	 (	 ;	 )	 que	 indica	o	 fim	do	
comando
Projeto de Banco de Dados Relacional| Unidade D
46
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S PESQUISANDO EM MULTIPLAS TABELAS
Para	utilizar	mais	de	uma	tabela	nas	consultas,	devemos	colocar	estas	depois	da	cláusula	from	e	ainda	colo-
car	na	cláusula	where	a	condição	de	união	das	tabelas,	unindo	a	chave	primária	com	a	chave	estrangeira.	Veja	
no exemplo abaixo:
SELECT *
FROM banco, agencia
WHERE banco. codBanco = agencia.codBanco // tabela1.chave primária=tabela 2.Chave estrangeira
CodAgencia EndAgencia NrAgencia CodBanco NmBanco
01 Av. Julio de Cássio 2665 01 Atual
02 Rua Felipe Almarante 2666 01 Atual
03 Rua Cássio Jair 5869 03 Poupar
04 Av. Sergio Afonso 5868 03 Poupar
05 Rua Carla Maria 9632 02 SulReal
Nas	tabelas	abaixo,	mais	alguns	exemplos	de	operadores	utilizados	em	SQL:
Operadores relacionais ou de comparação
Operador Descrição
< Menor que
> Maior que
<> Diferente de
<= Menor ou Igual que
>= Maior ou Igual que
= Igual que
Operadores Lógicos
Operador Descrição
AND E lógico Devolve um valor verdadeiro 
caso as das condições estejam cor-
retas
OR OU lógico Devolve um valor verdadeiro se 
uma das condições estejam corre-
tas
NOT Negação lógica Devolve valor contrário da ex-
pressão
Projeto de Banco de Dados Relacional| Unidade D
47
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S Operadores Especiais
Operador Descrição
IS NULL Utilizado para verificar se o conteúdo da coluna foi 
inicializado ou não
IS NOT NULL Somente os campos que tiverem valores inicializa-
dos serão mostrados
BETWEEN Determina um intervalo de busca
LIKE Comparar cadeia de caracteres
IN Comparar o valor de uma coluna com um conjunto 
de valores
 7.1.4 DCL (Data Control Language) = Linguagem de Controle de Dados
Neste	estudo,	utilizando	a	linguagem	padrão	SQL,	vamos	ver	como	criar	usuários	e	grupos	para	acessar	um	
banco de dados e ainda estabelecer critérios de segurança para que estes possam acessar as informações.
create user aluno; //comando para criação de usuário aluno no banco de dados.
drop user aluno; //comando para excluir o usuário aluno do banco de dados
alter group escola add user aluno; //inserir usuário aluno no grupo escola.
Em	relação	aos	critérios	de	segurança,	podemos	utilizar	um	comando	para	atribuir	direitos	e	outro	para	re-
tirar.
Exemplos de direitos, podendo haver outros dependendo do SGBD:
SELECT = direito de extrair dados da tabela
INSERT = direito de incluir dados na tabela
UPDATE = direito a modificar linhas da tabela
DELETE = direito a excluir linhas da tabela
REFERENCES = direito a criar CONSTRAINT de chave estrangeira
ALL PRIVILEGES = direito a todos os privilégios
Os	comandos	utilizados	para	atribuir	ou	retirar	estes	direitos	são:
GRANT = atribuir direitos
REVOKE = retirar os direitos
Sintaxe:
GRANT direito
ON tabela
TO usuário
Exemplos:
GRANT select
ON banco
TO aluno
Projeto de Banco de Dados Relacional| Unidade D
48
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S // Neste exemplo foi dado o direito de extrair dados da tabela banco para o usuário aluno.
GRANT select , update(endAgencia)
ON agencia
TO aluno
// Neste exemplo foi dado ao aluno o direito de extrair dados da tabela agencia e alterar somente a coluna 
endAgencia.
Projeto de Banco de Dados Relacional| Unidade E
51
S
is
te
m
a 
U
ni
ve
rs
id
ad
e 
A
be
rta
 d
o 
B
ra
si
l -
 U
A
B
 |
 C
E
FE
T-
R
S
8. Utilizando um SGBD (Sistema Gerenciador de Banco de dados)
A partir desta unidade, vamos começar a utilizar um Sistema Gerenciador de Banco de dados. A nossa escolha 
será o PostgreSQL, mas será importante que você pesquise outros Sistemas de Banco de dados utilizados como, 
por exemplo, o MySQL, Oracle, entre outros.
O PostgreSQL é um SGBDR (Sistema Gerenciador de Base de Dados Relacional) que está baseado em Padrões 
SQL ANSI-92, 96 e 99. É um SGBDR de alta performance, fácil administração e utilização em projetos.
8.1 Utilizando o SQL
Para a utilização do PostgreSQL vamos utilizar a linguagem SQL que verificamos no capitulo anterior. A lingua-
gem SQL utilizada na unidade 7 é uma linguagem SQL padrão podendo sofrer alterações dependendo do SGBD 
utilizado, por isso para utilização do PostgreSQL é importante utilizarmos um referencial.
Para a nossa pesquisa podemos utilizar o link com a documentação do PostgreSQL traduzida para o portu-
guês. Nesta documentação, além da sintaxe de todos os comandos, encontramos exemplos para cada comando, 
o que