Banco de Dados I

Banco de Dados I

Sumrio

Introduo a Banco de Dados ....................................................... 4

Entendendo os Modelos de Base de Dados ...................................... 16
Modelagem Entidade Relacionamento ........................................... 28
Exemplos de Implementao do Modelo Conceitual ........................... 42
Modelagem Lgica .................................................................. 54
Modelagem Fsica, Normalizao de Dados e lgebra Relacional............ 68
Introduo a SQL .................................................................... 80
Operaes CRUD .................................................................... 92
Critrios de Seleo de Dados ................................................... 103
Consultas Envolvendo mais de uma Tabela .................................... 113

Banco de Dados I

Apresentao

Prezados(a) alunos(a)
Sejam vem vindos(as) a disciplina de Banco de Dados I . Nesta disciplina
vocs entendero a importncia da utilizao de banco de dados, alm dos
conceitos relacionados a este.
Tambm sero abordados modelos os quais so utilizados para
representar os dados, tendo como foco o modelo Relacional, onde sero
estudados conceitos sobre entidades, relacionamentos, atributos e chaves
primrias e estrangeiras.
Durante a disciplina, voc estar se capacitando a analisar e criar um
banco de dados, passando por todas as etapas do processo de banco de dados.
Tambm ter conhecimento necessrio para criar e manipular tabelas
atravs de instrues SQL de insero, alterao, remoo e seleo de
dados. Tendo em vista que a seleo de dados possui uma srie e
especificaes, este material foi elaborado com exemplos prticos da
utilizao de critrios existentes do comando de seleo como, junes,
produto cartesiano e subconsultas.
Assim, ao concluir a disciplina voc ter conhecimento necessrio para
criar um projeto de banco de dados e manipular as informaes nele
armazenado, podendo aplicar o conhecimento adquirido em diversos
segmentos da rea de computao, como programao, anlise e gerente de
infraestrutura.
Prof. Christiano Cadon

Banco de Dados I

Introduo a banco de Dados

Christiano Cadon1

Introduo
Este captulo tem por objetivo contextualizar o aluno quanto
importncia de banco de dados e os principais conceitos relacionados a este
tema.
Sero destacadas as vantagens e as desvantagens do uso de sistemas de
banco de dados, alem de entender o principal papel do administrador de
banco de dados.

Importncia da Informao no mundo moderno

O momento em que vivemos na histria definitivamente marcado pela
era digital. Tudo ou quase tudo que possumos, possui alguma funcionalidade
digital. E o que mais impressiona, que estamos to atrelados a esta
tecnologia, que no conseguimos mais nos separar desta relao, criando uma
dependncia de tecnologia. H muito que se debater, se isto bom ou ruim
para humanidade, contudo, uma coisa certa, no vivemos mais sem
comunicao, controles e funcionalidades automatizadas. Esta insero de
tecnologia trouxe uma srie de benefcios vida moderna. Muitos controles,
principalmente controles operacionais, proporcionaram s organizaes seu
crescimento e principalmente a possibilidade de conhecer melhor seu
negcio, produtos e seus clientes.
Estamos na era da informao, onde capital social fsico de uma
empresa no to valioso quanto qualidade das informaes geradas nos
sistemas de informao.
O Google e Facebook so bons exemplos de empresas muito valiosas, e
se analisadas possuem como maior ativo, os dados nelas armazenadas. Voc
j avaliou o quanto e quais informaes somente estas duas empresas
possuem relacionadas populao mundial? Somente o Brasil, possua no ano
de 2013 mais de 47 milhes de usurios do Facebook, e o Gmail (produto da
Google) possua em 2012 mais de 286 milhes de usurios no mundo todo.
Estas empresas sabem exatamente, onde cada usurio mora, o que mais
gostam que tipo de informao recebe, quais so os amigos que se
1

Especialista em Desenvolvimento de Software para Web. Professor coordenador de

atividades dos cursos superiores de tecnologia em Redes de Computadores e Anlise e
Desenvolvimento de Sistemas

Banco de Dados I

relacionam, o local onde esteve, entre outras informaes que cada usurio
autoriza estas empresas a coletar dados no momento em que se cadastram
para usufruir das funcionalidades oferecidas por estas. Neste momento se
torna simples imaginar o quanto destas informaes estrategicamente
importante para gestores de empresas. Sendo assim, justifica-se o valor que
cada uma possui no mercado de negcios.
Agregado a isto, o avano do uso de sistemas inteligentes (Sistemas de
recomendao, sistemas de apoio a deciso, minerao de dados, OLAP, etc.)
como mecanismo de diferencial competitivo de uma empresa, potencializa
ainda mais a necessidade de obteno de um nmero cada vez maior de dados
armazenados nas bases de dados.
Avaliando este contexto, possvel entender o porqu as empresas que
mais faturam do mundo possuem como fator estratgico ou principal insumo
de seus resultados o uso de sua base de dados. Bancos, empresas de energia,
empresas de Telecom, empresas de TI, entre outras se destacam das demais,
e se observar, ambas necessitam de seus dados armazenados para sobreviver.
O governo brasileiro, aps muitos anos, se deu conta da necessidade de
informatizar suas autarquias de forma a possuir maiores controles e por
consequncia melhorar o atendimento e principalmente a arrecadao.
Se avaliar os contextos at aqui apresentados, possvel concluir que
banco de dados est ligado diretamente com todas as aes do mundo
moderno. Desta forma, fica clara a dependncia existente da tecnologia em
todos os segmentos. No possvel imaginar o mundo em que vivemos sem os
processos automatizados sejam eles aplicados a qualquer tipo de segmento.
Vivemos cercados de informao e ficamos cada dia mais sedentos da
disponibilidade desta.
Agora imagine um colapso em um sistema, cujas informaes so
apresentadas de forma errada e ou simplesmente no so apresentas, devido
a problemas no armazenamento, o quanto impactante seria esta experincia,
tanto para o usurio final, quanto para a empresa e ou governo que o
detentor destes dados. Por exemplo, imagine, se por algum motivo, todos os
e-mails da conta do Gmail e ou todas as contas do Facebook simplesmente
sumissem. O impacto seria significativo. Agora imagine algo muito pior como,
por exemplo, erros nos registros de documentos de veculos e ou remoo de
todas as informaes cadastrais dos proprietrios de veculos? Qual seria o
tamanho do impacto? Realmente, no h como descrever o colapso causado
por algum evento desta magnitude. Falhas deste tipo, geralmente ocorrem no
repositrio de dados.
Tendo em vista todos os fatos apresentados, inevitvel entender
como, e porque, to necessrio o estudo dos repositrios de armazenamento

Banco de Dados I

destes sistemas. Entender os conceitos e melhores prticas de modelagem,

armazenamento e manipulao de dados so competncias indispensveis de
um profissional da rea de computao.

Banco de dados
Banco de dados uma coleo de dados inter-relacionados,
representando informaes sobre um domnio especfico. Tendo como
premissa esta definio, possvel concluir que no momento que existir um
grupo de informaes que caracterizam (representam) algo, como por
exemplo, uma planilha eletrnica contendo informaes estruturadas de
produtos estamos tratando de um banco de dados.
Em sua forma mais primitiva, o exemplo apresentado pode sim ser
considerado como um banco de dados. possvel ainda agregar que, os dados
contidos no banco de dados, devem ser armazenados de forma independente
dos programas que faam uso destes, possibilitando que estas informaes
possam ser acessadas por mltiplas solues computacionais. No caso de uma
planilha, possvel que suas informaes sejam acessadas por aplicativos
diferentes do Excel por exemplo, como uma soluo desenvolvida em
linguagem PHP, Java ou C#.
Sendo assim, podemos concluir que qualquer repositrio de informao,
que esteja organizado representando algo, e suas informaes possam ser
acessadas caracteriza a existncia de um banco de dados.
Esta definio pode ser um tanto quanto genrica, pois um texto
escrito em um jornal ou em um site, por exemplo, possui um conjunto de
palavras que esto organizadas, caracterizando um banco de dados. Contudo
o termo banco de dados mais restrito e tem as seguintes particularidades
(Elmasri, 2011):
Um banco de dados representa algum aspecto do
mundo real, s vezes chamado de minimundo ou
universo de discurso.
Um banco de dados uma coleo logicamente
coerente de dados com significado inerente. Uma
variedade aleatria de dados no pode ser
corretamente chamada de banco de dados
Um banco de dados projetado, construdo e populado
com dados para uma finalidade especfica. Ele possui
um grupo definido de usurios e algumas aplicaes

Banco de Dados I

previamente concebidas nas quais esses usurios esto

interessados.

Desta forma, somente ser chamado de banco de dados, um conjunto

de informaes que possuir relao com algo que represente a realidade, e
que possa sofrer alguma interao, como por exemplo, ser utilizado como
repositrio de informaes de um sistema comercial, ou contedo dinmico
de um site.

Sistema de Gerenciamento de Bancos de Dados (SGBD)

muito comum confundir os conceitos de banco de dados e Sistema de
Gerenciamento ou Gerenciador de Banco de Dados, porm so coisas muito
distintas. O SGBD um software ou conjunto de softwares (no o repositrio
de dados) com recursos especficos para facilitar a manipulao das
informaes dos bancos de dados e o desenvolvimento de programas
aplicativos.
" um sistema cujo objetivo principal gerenciar o acesso e a
correta manuteno dos dados armazenados em um banco de dados."

Por exemplo, o ORACLE, Mysql e SQLServer, so sistemas gerenciadores

de banco de dados, e possuem um conjunto de bancos de dados que so
gerenciados por estes.
O conceito de SGBD determina que os dados do banco de dados nunca
sero acessados por uma aplicao final e sim sempre sero acessados atravs
do seu SGBD.
A figura 1 apresenta um esquema que ilustra a forma tpica de acesso
realizada por aplicativos desenvolvidos por linguagens de programao atuais.

Banco de Dados I

Figura 1 Esquema tpico de conexo a dados utilizando SGBD

Perceba no exemplo apresentado na figura 1 que as linguagens de

programao (Java, .NET e PHP) no realizam acesso direto ao banco de
dados (Banco X, Y e Z), mas sim ao SGBD que por sua vez, realiza operaes
com os dados de cada banco.

Sistema Bancos de Dados

O sistema de banco de dados no pode ser confundido com SGBD. Um
sistema algo muito maior, que possui um SGBD como parte do sistema. Pode
ser definido como um sistema de manuteno de registros por
computador. Ele dividido em quatro componentes principais:

Dados: Representam a informao armazenada em cada banco

de dados. Estes dados, dependendo do porte da empresa, podem
ser armazenados fisicamente de forma centralizada (em
aplicaes de dispositivos mveis ou aplicaes comerciais de
pequeno porte) ou distribudas (como o caso de empresas como
Google e a Receita Federal). Para quem acessa as informaes
no percebe qualquer diviso de informaes. Estes dados
tambm podem ser compartilhados permitindo, por exemplo,
que de forma simultnea seja possvel visualizar dados
cadastrados de um cliente em um terminal e em outro terminal,
o cadastro de outro cliente no mesmo repositrio de informao
(banco de dados);

Hardware: Um SBGD necessita de recurso de hardware para

suportar suas funcionalidades. Geralmente os recursos de

Banco de Dados I

hardware esto relacionados capacidade de disco, memria

principal, processador e dispositivos de entrada e sada;

Software: So os conjuntos de arquivos existentes que realizam

todo o controle sobre os dados armazenados. neste conjunto
de aplicaes que o SGBD est inserido no sistema. O SGBD ,
de longe, o componente mais importante de todo o sistema, mas
no o nico. Existem outros componentes como ferramentas
de modelagem, ferramentas de monitoramento entre outras, que
fazem parte do conjunto de software do sistema de banco de
dados;

Usurios: so personagens que interagem diretamente com os

dados armazenados e ou com SGBD. Estes podem ser divididos
em trs grupos, sendo o primeiro o de programadores que so
responsveis por elaborar aplicaes utilizando o repositrio de
dados. O segundo formado por usurios finais, que em geral so
os clientes dos aplicativos desenvolvidos, e por fim, os
administradores de banco de dados (DBA), com responsabilidade
direta sobre os dados e o sistema de banco de dados.

Existe uma srie de objetivos de um sistema de banco de dados,

contudo dois deles resumem todo o conjunto. O primeiro o de isolar os
usurios dos detalhes mais internos do banco de dados (abstrao de dados).
Para os usurios do banco sejam eles programadores, usurios finais e ou
administradores, no necessrio saber qual a rotina que realiza a gravao
dos dados no disco fsico, ou como que ele recupera do banco de dados uma
informao armazena. O que importa, quando encaminhado uma solicitao
de armazenamento de um cadastro de cliente, por exemplo, o sistema realize
o procedimento, sem que ocorra inferncia do usurio.
J o segundo o de prover independncia de dados s aplicaes
(estrutura fsica de armazenamento e estratgia de acesso). O sistema deve
possibilitar que os dados possam ser armazenados de forma distribuda caso
necessrio, alm de proporcionar mecanismos de segurana no acesso a estes
dados, como o uso de permisso de acesso a um banco ou a um conjunto de
tabelas.
Vantagens de um sistema de banco de dados
Alm claro dos objetivos que um sistema de banco de dados
proporciona existe uma srie de vantagens em sua utilizao:

Rapidez na manipulao e no acesso informao: como em

geral os sistemas de banco de dados possuem uma linguagem de
manipulao de registros universal, no se torna necessrio criar

Banco de Dados I

rotinas que possibilitem a manipulao de registros, alm destes

possurem rotinas de otimizao de cdigo internas o que
melhora de forma significativa a busca por informaes;

Reduo do esforo humano (desenvolvimento e utilizao):

Como para o usurio no interessa a rotina que o sistema de
banco de dados utiliza para manipular as informaes, no
necessrio perder tempo construindo rotinas automatizadas, pois
estas j existem. Desta forma o desenvolvedor apenas deve
executar comandos de manipulao de dados, pois todos os
controles j esto previamente codificados no sistema de banco
de dados;

Disponibilizao da informao no tempo necessrio: como j

relatado no necessrio construir rotinas de acesso, basta
utilizar as j existentes possibilitando que em pouco tempo seja
possvel elaborar um relatrio apenas com comandos de busca a
dados, por exemplo. A grande parte dos sistemas de banco de
dados est configurada para apresentar o retorno de informaes
em tempo real.

Controle integrado de informaes distribudas fisicamente: O

sistema de banco de dados possui rotinas de integrao em bases
distribudas fisicamente, possibilitando ao usurio uma nica
fonte de informao. A distribuio realizada de forma
automtica. Imagine que, o Google, por exemplo, no possua
apenas um servidor de dados, e sim muitos e suas informaes
esto sim distribudas fisicamente, inclusive entre pases
diferentes, entretanto para quem realiza uma pesquisa no site, a
informao aparece para o usurio de forma nica.

Reduo de redundncia de informaes: redundncia faz

referencia a duplicidade de informaes armazenadas. Pode
ocorrer que existam aplicaes distintas onde cada uma cadastre
a mesma informao de forma separada. Imagine em uma escola
um sistema que cadastre alunos de uma chamada, e outro
sistema que cadastre as parcelas de pagamento dos alunos.
Ambos compartilham dados de alunos. Com o uso de sistemas de
banco de dados possvel elaborar a estrutura de forma que
ambos os sistemas cadastrem em apenas um local os alunos,
reduzindo a redundncia de informaes.

Reduo de inconsistncia de informaes: A inconsistncia pode

ser derivada da redundncia de informao, pois sem o controle
de redundncia, conforme o exemplo citado, os dois sistemas

10

Banco de Dados I

cadastrariam informaes distintas sobre alunos. Caso seja

alterada uma das informaes de um aluno em apenas um
sistema como sua data de nascimento, o outro sistema no teria
a informao atualizada. Neste caso, dizemos que o banco est
inconsistente, pois no sabemos qual das datas de nascimento de
aluno a correta. Existem outros tipos de inconsistncia a
inconsistncia de dados, chaves e relaes que sero abordadas
nos prximos captulos de forma mais detalhada. Mas em abas as
inconsistncias relacionadas, o sistema de banco de dados possui
mecanismos de controle automatizados;

Compartilhamento de dados: Um dos grandes fatores dos

sistemas de banco de dados terem evoludo, est associado ao
fato de compartilhar um nico repositrio de dados com vrias
aplicaes distintas;

Aplicao automtica de restries de segurana: O sistema de

banco de dados possibilita uma srie de mecanismos de
segurana ao acesso e manuteno dos dados armazenados. O
tipo de restrio mais comum de ser encontrado em sistema de
banco de dados o uso obrigatrio de usurios e senhas de
acesso base. Porm possvel impor, dependendo o banco de
dados, restries de acesso a tabelas e campos especficos. Isto
depender de cada sistema de banco de dados.

Reduo de problemas de integridade: A integridade assegura

que os dados armazenados esto corretos. Pode parecer estranho
imaginar que possvel armazenar informaes incorretas,
contudo mais comum do que se imagina. Por exemplo, existe
uma srie de modelagens de banco que permitem que seja
armazenado um valor de salrio ou idade negativa. Caso seja
armazenada uma informao em um destes campos negativa,
podemos concluir que os dados esto incorretos ou no ntegros.
Um sistema de banco de dados possui regras para impor
integridade em suas informaes armazenadas.

Desvantagens de um Sistema de banco de dados

A escolha e implantao de um sistema de banco de dados proporciona
uma srie de vantagens j apresentas. Porm existe algumas desvantagens
inerentes implantao do sistema. So elas:

Sem dispositivos de controle adequados, a segurana pode ficar

comprometida, como por exemplo, no caso de acesso no
autorizado a dados. Nunca esquea que na base de dados, esto

11

Banco de Dados I

as informaes mais importantes do negcio de uma empresa.

indispensvel mant-las em segurana;

A integridade das informaes pode ser comprometida se no

houver mecanismos de controle quando ocorrer manipulaes de
dados de forma concorrente. Imagine um sistema onde duas
pessoas acessam e alteram ao mesmo tempo dados de uma
mesma informao como o produto Abacaxi. Dependendo da
forma como for implementado o processo concorrente, um dos
usurios sobrescrever a informao que o outro acabou de
alterar, tornando os dados no ntegros;

A operao do sistema de banco de dados e o desenvolvimento

de aplicaes precisam ser feitos com muita preciso para evitar
que informaes no correspondam realidade;

A administrao do sistema de banco de dados pode se tornar

muito complexa em ambientes distribudos, com grande volume
de informaes manipuladas por uma grande quantidade de
usurios. Se no for planejada e documentada a estrutura de
controle do sistema de banco de dados, a administrao tende a
se tornar complexa mesmo em empresas de mdio porte.

Administrador de Banco de dados (DBA)

O Administrador de Banco de dados DBA (Database Administrator)
possui um papel importante no sistema de banco de dados. ele que toma as
decises estratgicas e de normas e geralmente quem as implementa no
SGBD. Segue algumas das atribuies de um DBA dentro do sistema de banco
de dados:

Definio e atualizao do esquema dos bancos de dados

(definem quais e como as informaes sero mapeadas para o
banco);

Definio da estrutura de armazenamento e da estratgia (ou

mtodo) de acesso;

Concesso de autorizao para acesso a dados;

Definio de controles de integridade;

Definio de estratgias de cpia de segurana e recuperao;

Monitorao de desempenho;

Execuo de rotinas de desempenho;

12

Banco de Dados I

Atualizao da organizao fsica.

Linguagem de definio de dados (DDL)

A linguagem de definio de dados DDL (data-definition language)
utilizada para definir a estrutura (esquema) de um banco de dados,
principalmente nos nveis conceitual e de vises de usurio. A DDL define, por
exemplo, quais sero os dados que so armazenados (tipo de dado: nmero,
texto, data) e os ndices de pesquisa. O conjunto de parmetros da DDL
armazenado no que chamados de dicionrio de dados. O dicionrio de dados
possui uma estrutura contendo todas as definies que o banco de dados
possui.

Linguagem de manipulao de dados (DML)

A linguagem de manipulao de dados DML (Data Manipulation
Language), permite aos usurios e aplicaes, acessar ou manipular as
informaes contidas num banco de dados. Manipular dados envolve incluir,
alterar, remover e consultar dados no banco de dados.
Em geral os bancos de dados relacionais (foco principal desta
disciplina), trabalham com a linguagem SQL (Structured Query Language), ou
Linguagem de Consulta Estruturada. O Sistema de banco dados interpreta
comandos emitidos em SQL e realiza o processamento da operao.
importante salientar, que o SQL no a nica linguagem existente
como DDL de um sistema de banco de dados. Geralmente cada SGBD, possui
comandos prprios que podem ser utilizados para operacionalizar rotinas com
os dados armazenados.

Recapitulando
Como foi percebido neste captulo, a informao armazenada nos
bancos de dados indispensvel em nosso contexto de mundo moderno. Tanto
usurios finais como as empresas, esto dependentes das informaes
armazenadas nestes repositrios. Da a importncia do estudo em banco de
dados.
Percebemos que banco de dados em sua essncia, nada mais , do que
um repositrio de dados organizados que representam algo de um domnio
especfico. J os SGBDs compem uma estrutura de aplicaes que
possibilitam o gerenciamento destes bancos de dados.
O sistema de banco de dados ento formado no apenas pelos dados e
aplicativos armazenados e sim, por um conjunto composto de dados,
hardware, software e usurios deste sistema. Entre os usurios de banco de

13

Banco de Dados I

dados, destaca-se o DBA que responsvel pela correta definio, criao e

manuteno do sistema de banco de dados.
Por fim, em um sistema de banco de dados existem duas linguagens
principais: a DDL que define o banco de dados e a DML que possibilita a
interao de aplicaes com os dados armazenados.

Atividades
1) Assinalar (V) para as assertivas Verdadeiras e (F) para as Falsas
a)
b)
c)

V
( )
( )
( )

F
( )
( )
( )

Assertiva
Um exemplo de banco de dados o Mysql
Arquivos texto estruturados so exemplos de banco de dados
Uma planilha do Excel com dados de clientes pode ser
considerada como banco de dados

2) Tendo como base o contedo apresentado no captulo 1, marque somente a

alternativa que est errada
a) ( )

Sistema gerenciador de banco de dados possui um conjunto de

aplicaes para gerenciamento do banco de dados
b) ( ) DDL, a linguagem de manipulao de registros
c) ( ) O sistema de banco de dados possibilita uma srie de mecanismos de
segurana ao acesso e manuteno dos dados armazenados

3) No uma vantagem dos sistemas de banco de dados

a) ( ) Reduo a inconsistncia de informaes
b) ( ) Compartilhar o mesmo banco de dados com mais de uma aplicao
c) ( ) Administrao do banco de dados se torna simples em ambientes de
distribudos

4) A partir dos estudos desenvolvidos nesse captulo, marque (X) somente nas
assertivas verdadeiras(mltipla escolha).
a) ( )

Um DBA responsvel por executar rotinas de gerenciamento no

sistema de banco de dados
b) ( ) O dicionrio de dados possui a concesso de autorizao para acesso
a dados
c) ( ) Um sistema de banco de dados pode ser dividido em 4 componentes
principais: Dados; Usurios; Hardware e Software

14

Banco de Dados I

5) uma desvantagem do uso de sistemas de banco de dados.

a) ( )

Sem dispositivos de controle adequados, a segurana pode ficar

comprometida
b) ( ) Monitorao de desempenho
c) ( ) A rapidez na manipulao e no acesso informao

Gabarito:
Questo 1 [ a)F, b) V, c) V ]
Questo 2 [ b ]
Questo 3 [ c ]
Questo 4 [ marcar alternativas A e C ]
Questo 5 [ A ]

15

Banco de Dados I

Entendendo os Modelos de Base de Dados

Christiano Cadon

Introduo
Este captulo tem por objetivo apresentar os principais modelos de
modelagem de banco de dados e trazer caractersticas mais especficas do
modelo de dados relacional que o foco de nosso estudo. Assim, o leitor ter
uma viso das principais modelagens e um aprofundamento na modelagem
relacional.

Modelo de Base de Dados

Um modelo de base de dados a forma na qual possvel estruturar os
dados. o instrumento que permite uma representao do mundo real a
partir de informaes. No decorrer da histria, foram definidos vrios modelos
de base de dados. A deciso de qual modelo o ideal, depende do objetivo,
da complexidade e do volume de dados esperados para um domnio desejado.
Os modelos de dados diferenciam-se principalmente pela forma com que os
dados so representados. Geralmente possuem uma representao simples,
normalmente grfica, sendo que os mais difundidos so o modelo hierrquico,
modelo em redes, modelo relacional e modelo orientado a objetos.
O modelo hierrquico foi desenvolvido na dcada de 1960, com o
objetivo de gerenciar grandes quantidades de dados. Foi a primeira grande
evoluo em relao ao formato de armazenamento. No modelo hierrquico,
as informaes so estruturadas no formato de rvores hierrquicas, onde
cada um dos ns (registros) contm uma coleo de atributos e cada atributo,
contm apenas uma informao (ELSMARI e NAVATHE, 2011). Neste modelo
cada n pai pode possuir vrios ns filhos e um n filho somente pode possuir
um nico n pai. Em banco de dados chamamos isto de uma relao 1:N (um
para muitos).
A Figura 2 demonstra um exemplo de modelagem hierrquica. Nela
percebemos que cada derivao de um n pai chamada de nvel ou
segmento. No exemplo o Componente C que est no nvel 1, pai nos ns
Montagem B e Montagem C, que esto no nvel 2. Por sua vez, o n
Componente C, filho do n Montagem Final.

16

Banco de Dados I

Figura 2 Modelo de dados Hierrquico (modificado de Peter Rob e Carlos Coronel,2011)

O acesso aos dados armazenados no modelo hierrquico feita atravs

de ponteiros, ou seja, ela iniciada atravs do topo da rvore (n raiz) e da
esquerda para a direita, at alcanar o n que contm a informao
pretendida.
O modelo hierrquico se tornou predominante na dcada de 1970, no
entanto este modelo possua suas limitaes como a complexidade nas
consultas, a limitao das ligaes entre os ns (um n filho pode ter apenas
um n pai) e possibilidade de se trabalhar apenas com dados primitivos. Estas
limitaes desencadearam anlises de alternativas para soluo dos
problemas por parte de profissionais de banco de dados, o que resultou em
modelos alternativos, sendo o mais promissor o Modelo de Rede.
O modelo de rede surgiu como uma alternativa aos problemas
apontados pelo modelo hierrquico. Sua principal mudana foi a eliminao
do conceito de hierarquia. Com isso, o modelo de redes permitiu que um n,
possusse vrias associaes (N:N muitos para muitos) caso necessrio. Outra
modificao a implementao do conceito de conjunto. Um conjunto
representa um relacionamento entre o seu proprietrio e um membro do
diagrama.
O exemplo apresentado por Peter Rob e Carlos Coronel (20011),
representado na figura 3, ilustra uma representao de uma organizao de
vendas comum. Neste modelo, CLIENTE, REPCOMERCIAL, FATURA, FAT_LINHA,
PRODUTO e PAGAMENTO representam os tipos de registro. Neste exemplo a
FATURA de propriedade tanto do REPCOMERCIAL, como do CLIENTE. Os
conjuntos so identificados no prprio diagrama, como o caso do conjunto
de vendas, formado pelos tipos CLIENTE e FATURA.

17

Banco de Dados I

Figura 3 Modelo de Rede (modificado de Peter Rob e Carlos Coronel, 2011)

Ao contrrio do modelo hierrquico, em que qualquer acesso a dados

passa pela raiz, no modelo em redes o acesso aos dados pode ser realizado
atravs de qualquer n da rede. De forma prtica, com este modelo possvel
acessar os dados de pagamento, sem que seja necessrio acessar os dados de
cliente, o que no modelo hierrquico era impossvel (ELSMARI e NAVATHE,
2011).
O modelo relacional surgiu como alternativa do modelo hierrquico e
de redes. Utilizada uma srie de conceitos destes, porm diferencia-se por
possuir um aumento de independncia de dados, alm de prover um conjunto
de funes apoiadas em lgebra relacional tanto para o armazenamento
quanto para a recuperao de dados. O modelo relacional foi concebido pelo
matemtico britnico Edgar Frank Codd enquanto pesquisador da IBM nos anos
70, como uma nova maneira de representao de dados atravs de uma viso
relacional dos dados, o que permite a descrio dos mesmos de uma forma
natural, sem a necessidade de estruturas adicionais, alm de prover uma
maior independncia dos dados em relao aos programas. Sua estrutura
simples de ser interpretada, e a forma de recuperao de dados, agradou
tanto que desencadeou uma adaptao deste modelo para o modelo entidade
relacionamento, o qual praticamente domina a grande parte das aplicaes
que atualmente conhecemos.
Sua estrutura formada por tabelas, e relaes entre colunas (campos)
destas tabelas. Cada linha com contedo chamada de registro ou tupla e
representa de forma nica uma informao. Da mesma forma que o modelo de
rede, o acesso s informaes no modelo relacional pode ser realizado por
qualquer tabela, diferentemente do modelo hierrquico.
A figura 4 apresenta um exemplo de contedo armazenado em uma
estrutura relacional contendo uma tabela de fornecedor e uma tabela de

18

Banco de Dados I

produtos. Observe como o conceito de tabela se torna mais simples de ser

assimilada, como tambm a implementao do conceito de relacionamento.

Figura 4 Modelo de relacional

Neste exemplo, o produto Uva, possui como fornecedor o fornecedor

de nome Central. Tambm possvel fazer outro tipo de leitura, como por
exemplo, dizer que o fornecedor Comrcio de alimentos, possui 2 produtos
associados a ele o Abacaxi e o Abacate. Observe que isto ocorre tendo em
vista que existe uma informao codFornecedor que gera uma relao entre
as duas tabelas. Sabendo que o modelo Entidade Relacionamento muito
utilizado no contexto atual pelas empresas desenvolvedoras e grandes
corporaes, no prximo tpico sero abordadas outras caractersticas
significativas deste modelo.
Por fim, o modelo orientado a objetos veio como alternativa ao uso do
modelo relacional. A finalidade de existir um banco de dados orientado a
objetos, implementar uma srie de benefcios que a programao
orientao a objetos possui em relao a programao estruturada, alm de
possibilitar o armazenamento e recuperao de dados da mesma forma como
ocorre a construo de um obejeto nestas linguagens, sem que ocorra o
processo de mapeamento objeto relacional. Neste modelo possvel, por
exemplo, lidar com construtores de tipo que permitem especificar objetos

19

Banco de Dados I

mais complexos contendo tuplas e arrays, encapsulamento de operaes e

mecanismos de herana e polimorfismo.
Mesmo com todas essas
caractersticas, os modelos de dados orientados ao objeto so implementados
fisicamente atravs de tabelas, ou seja, da mesma forma que no modelo
relacional, tendo a semntica da aplicao modelada e representada atravs
de objetos, enquanto sua implementao fsica feita de forma relacional
(GALANTE et all, 2007).
A figura 5 apresenta um exemplo de uma modelagem orientada a
objetos, contendo as classes cliente e conta. Perceba que o diagrama
utilizado para modelagem o mesmo que utilizado para representar classes
na UML (Unified Modeling Language). O que ocorrem em geral que na
modelagem, no se especifica os mtodos no diagrama.

Figura 5 Modelo de relacional

Por mais que o modelo orientado a objetos tenha sido constitudo

posterior ao modelo relacional, pesquisas apontam que o modelo relacional
ser utilizado por muito tempo, tendo em vista a confiana e autonomia que
este apresentou durante o decorrer dos tempos.
Outro fator que deve ser considerado que na prtica, observamos que
o paradigma de programao orientado a objetos utilizado de forma macia
no desenvolvimento de aplicaes, sejam elas para qualquer fim. Porm em
sua maioria, estas aplicaes armazenam os dados em banco de dados
relacionais e no em banco de dados orientados a objeto. A etapa de
armazenamento e busca de dados dentro de uma aplicao que utiliza banco
de dados relacional e desenvolvida com lingual de programao orientada a
objetos, chama-se mapeamento objeto relacional. Esta etapa ento
responsvel pela transformao dos dados armazenados em estrutura
relacional para objetos dentro da linguagem de programao.

Modelo Relacional
Como j mencionado o modelo relacional um modelo lgico de dados,
baseado em registros, que prov abstrao de dados nos nveis conceituais e
de vises do usurio. Neste modelo, tabelas representam dados e

20

Banco de Dados I

relacionamentos entre dados. A grande maioria dos SGBD que atualmente

conhecemos e so consagrados implementam este modelo como estrutura, por
exemplo, Oracle, SqlServer, Postgress, Mysql, Firebrid, entre outros.
As principais caractersticas do modelo relacional so:

Estrutura tabular: os dados so representados na forma de

tabelas, onde cada linha representa um registro (ou tupla), e as
colunas representam os atributos ou domnios;

lgebra Relacional: a manipulao destas tabelas feira atravs

de operadores que permitem qualquer tipo de acesso a uma
tabela ou a um conjunto de tabelas (seleo, unio, juno - join
etc). Nos prximos captulos falaremos especificadamente sobre
lgebra relacional;

Linguagem DDL: definindo, o esquema de dados do banco de

dados;

Linguagem DML: possibilidade de acesso e manipulao dos

dados armazenados em alto nvel atravs de uma linguagem de
manipulao;

Esquema Conceitual: representa o ponto de vista global da

empresa sobre a organizao dos dados. Neste esquema entra
em cena o papel do administrador de dados, que identifica
padro de entidades, atributos e relacionamentos, determinando
restries de integridade e segurana ao modelo de dados;

Esquema Fsico: O esquema fsico est associado ao

armazenamento de dados, acesso, local de armazenamento,
tipos de dados, entre outras especificaes;

Ao direta do DBA: No modelo relacional, o DBA possui um

papel indispensvel. Geralmente ele que realiza o
mapeamento do modelo lgico para o fsico, define as estruturas
de acesso, ndices, modo de transmisso de dados entre outras
atividades.

Como j estudados existem uma srie de sistemas gerenciadores de

bancos de dados disponveis no mercado. Em sua maioria, so modelados
utilizando o conceito de modelagem relacional. Como forma de garantir que
um sistema de banco de dados possua caractersticas de um banco de dados
relacional, este deve possuir as seguintes caractersticas:

O sistema de banco de dados deve gerenciar o banco de Dados

exclusivamente atravs de capacidades relacionais;

21

Banco de Dados I

Toda a informao apresentada sempre em nvel lgico por

valores em tabelas;

Todo o dado tem a garantia de ser logicamente acessvel. Se o

dado existir e estiver armazenado, deve ser possvel recuper-lo;

Os valores nulos so representados por ausncia de valores.

Caracteres especiais ou zero no representa ausncia de valor.
Geralmente neste caso, existe um smbolo chamado NULL que
pode ser utilizado para representar ausncia de valores no
respectivo campo do registro;

Deve haver pelo menos uma linguagem que permita a definio

dos dados, definio de viso, manipulao dos dados, restries
de integridade, autorizao de acesso, limites de transao. No
existe uma regra, mas a grande parte dos SGBDs existentes
possuem SQL como linguagem padro de manipulao;

Insero, atualizao e remoo de alto nvel. Isto significa que

no interessa como o SGBD ir manipular os dados de forma
fsica (como ele far para arquivar ou alterar um dado no
banco). Em um banco de dados relacional apenas devemos
informar um comando de alterao e este dever implementar
internamente a funcionalidade;

Independncia de dados fsicos onde, os programas devem

permanecer inalterados quando ocorre mudana nos mtodos de
acesso ou nas representaes de memria;

Independncia de dados lgicos onde programas devem

permanecem inalterados quando ocorre mudana no banco de
dados;

Independncia de integridade definida na linguagem DML e DDL;

Linguagem de acesso no pode ferir princpios de integridade.

O modelo relacional composto por tabelas ou relaes, chaves e

restries de integridade. A seguir sero apresentados de forma mais
detalhada as partes do modelo relacional.
Tabelas ou Relaes
Uma tabela um conjunto no ordenado de registros (linhas ou tuplas).
Cada linha composta por uma srie de valores de campo (valor de atributo),
identificados, cada um, por nome de coluna (nome de atributo domnio). A
figura 6 apresenta um exemplo de uma tabela com suas devidas partes.

22

Banco de Dados I

Figura 6 Tabela no modelo relacional

As tabelas e relaes possuem como principais caractersticas:

Cardinalidade de uma tabela: nmero de linhas que faz relao

com outra entidade. A cardinalidade somente ir existir se
houver relaes entre tabelas. Como o exemplo da figura 5
apresenta apenas uma tabela, no possvel representar
cardinalidade entre tabelas. A cardinalidade ser melhor
detalhada no prximo captulo;

Grau de uma tabela: nmero de colunas existente em uma

tabela. No caso do exemplo da figura 5, o grau da tabela 4,
pois a tabela formada por 4 colunas (cdigo, nome, valor e
fornecedor)

Linhas de uma tabela no esto ordenadas: As informaes de

uma tabela no so armazenadas de forma ordenada. Perceba o
exemplo da figura 5, que no existe ordem por nenhuma coluna.
Caso seja necessrio listar um conjunto de dados de forma
ordenada, o SGBD relacional poder disponibilizar algum
comando.

No possvel referenciar linhas de uma tabela por posio: da

mesma forma que o conceito de ordenao, o banco relacional
no possui acesso pelo nmero da linha armazenado. O SGBD
poder disponibilizar algum artifcio (em geral comando) que
realize uma consulta desta forma.

Valores de campo de uma tabela so atmicos, ou seja, no ser

possvel armazenar mais do que um tipo de informao em cada

23

Banco de Dados I

campo. Um campo de valor de um registro especfico, somente

conter um valor;

Dados podem ser recuperados por quaisquer critrios envolvendo

os campos de uma ou mais linhas. A linguagem DDL, deve
possibilitar que seja possvel acessar qualquer campo contendo
qualquer informao armazenada.

Chaves
So atributos utilizados para identificao de registros e ou relaes
entre entidades. Elas so classificadas em chaves primrias, candidatas ou
chaves alternativas e chaves estrangeiras.

Uma chave primria composta por uma ou mais colunas de uma

tabela cujos valores distinguem uma linha das demais dentro de
uma tabela. Desta forma, existem algumas propriedades
indispensveis para atender esta premissa, como o valor contido
em seu campo nunca se repetir, e este no permitir que seja
armazenado valores nulos. Uma chave primria pode ser simples
ou composta. Como definio toda entidade deve possuir uma
chave primria. A figura 7 apresenta um exemplo onde esto
sendo definidas as chaves primrias das tabelas de produto e
dependente. Na tabela de produto a chave primria simples est
sendo definida no atributo cdigo, que por sua vez nunca
poder se repetir. Na tabela de dependente ocorre a definio
de uma chave primria composta pelos atributos Cod_emp e
Num_dep.

Figura 7 Exemplo de chaves primrias simples e compostas

24

Banco de Dados I

Chamamos de chave alternativa ou candidata colunas ou uma

combinao de colunas que podem servir para distinguir uma
linha das demais. De certa forma toda chave primria uma
chave alternativa, porm no as definimos como tal, pois foram
definidas como sendo chaves primrias. Neste caso, no existe
necessidade que exista uma chave alternativa em uma entidade,
se a chave primria j foi definida. O exemplo apresentado na
figura 8 ilustra a entidade aluno, contendo como chave primria
cdigo e como chave alternativa o campo CPF. Isto se deve
pelo fato que o campo CPF representa de forma nica um
registro. Por exemplo, o CPF 8579 pertence ao aluno Carlos
e somente ao aluno Carlos.

Figura 8 Exemplo de chaves Alternativa ou Candidata (CPF)

A Chave Estrangeira uma coluna ou uma combinao de

colunas, cujos valores aparecem necessariamente na chave
primria de outra tabela ou da mesma tabela. um mecanismo
que permite a implementao de relacionamentos em um banco
de dados relacional. No exemplo apresentado na figura 9, a
chave estrangeira existente na tabela de produto chamada
Cdigo_Fornecedor, contm em seu contedo os valores
existentes na chave primria cdigo da tabela de fornecedor.
Para garantir o conceito de integridade em um banco de dados
relacional, necessariamente o valor contido nos atributos de
chave estrangeira devem ter elementos contidos em chaves
primrias associadas e ou serem nulos (NULL). Isto depender da
forma como for modelada a integridade das informaes.

25

Banco de Dados I

Figura 9 Exemplo de chaves estrangeira (Codigo_fornecedor)

Restries de Integridade
Restries de Integridade so regras de consistncia de dados que so
garantidas pelo prprio SGBD. Um dos objetivos primordiais de um SGBD a
integridade de dados. Dizer que os dados de uma base de dados esto ntegros
significa dizer que eles refletem corretamente a realidade e so consistentes
entre si. A restrio de integridade classificada em:

Integridade de Vazio: campos de uma coluna podem ou no ser

vazios (se a coluna obrigatria ou opcional). No esquea que
os campos que compem a chave primria devem ser sempre
diferentes de vazio;

Integridade Referencial: os valores dos campos que aparecem

em uma chave estrangeira devem aparecer na chave primria da
tabela referenciada ou devem ter valor igual NULL;

Integridade de Chave: os valores da chave primria e alternativa

devem ser nicos;

Integridade de Domnio: o valor de um campo deve obedecer

definio de valores admitidos para a coluna. Por exemplo, se
for definido que no campo de idade, somente dever ser
armazenado nmeros inteiros maiores ou iguais a zero, no
dever ser possvel, por exemplo, que seja armazenada uma
idade negativa.

26

Banco de Dados I

Recapitulando
Aps o trmino deste captulo possvel ter uma viso dos principais
modelos de dados (hierrquico, redes, relacional e objeto), assim como
entender algumas caractersticas de cada modelo.
Constatamos que o modelo relacional definido na dcada de 1970,
ainda muito utilizado e ter um bom espao por ser um modelo consagrado
por sua confiana e autonomia no decorrer do tempo.
Por fim, foram aprofundadas algumas caractersticas e a estrutura do
modelo relacional onde foi ilustrado exemplos dos conceitos de tabelas,
chaves e integridade.

Atividades
Tendo como base nas afirmaes abaixo relacionadas marque (V) para as
assertivas Verdadeiras e (F) para as Falsas
V

1)

( )

( )

2)

( )

( )

3)

( )

( )

4)

( )

( )

5)

( )

( )

Gabarito:
Questo 1 F
Questo 2 V
Questo 3 F
Questo 4 V
Questo 5 F

Assertiva
O modelo hierrquico uma evoluo do modelo em rede, pois
resolveu o problema de ordem de acesso a dados. No modelo
Hierrquico, os dados so acessados de sua raiz para os nveis
mais inferiores, utilizando o conceito de rvore.
O modelo orientado a objetos utiliza conceitos do paradigma de
orientao a objeto, porm em sua maioria, fisicamente
armazena em estrutura tabular.
O modelo relacional o modelo mais utilizado, tendo em vista
que ele aplica o conceito de todos os demais modelos.
No modelo relacional, os dados so armazenados em formato de
tabelas, as quais so constitudas por colunas e tuplas. Esta tabela
deve possuir uma coluna que identifique uma tupla de forma
nica. Para isto existe o conceito de chave primria
Toda entidade deve possuir pelo menos uma chave estrangeira

27

Banco de Dados I

Modelagem Entidade Relacionamento

Christiano Cadon

Introduo
Neste captulo ser apresentado os conceitos relevantes quanto a
modelagem Entidade Relacionamento (E-R), alem de apresentar o processo de
implementao desta modelagem, apresentando as suas partes e
componentes. Desta forma o aluno ter conhecimento necessrio para
modelar situaes prticas de contextos de armazenamentos, alm de
entender mais a fundo as caractersticas do modelo relacional j apresentado
anteriormente.

Modelo Entidade Relacionamento

O modelo Entidade Relacionamento (E-R) foi proposto por Peter Chen
em 1976 e teve como base a teoria relacional criada por Codd (1970). Ele
utiliza praticamente todos os conceitos do modelo relacional, alm de propor
uma viso mais conceitual do mundo real. O principal objetivo era levar aos
projetistas ou analistas a possibilidade de ter uma nica viso de uma
realidade sem redundncia e bem resumida. O modelo E-R prope que o
mundo real formado por um conjunto de objetos que so denominados de
entidades e relacionamentos entre estas entidades. O modelo E-R um dos
modelos com maior capacidade semntica (refere-se tentativa de
representar o significado dos dados). Seu autor enfatizava que:
O mundo est cheio de objetos (entidades), que
possuem caractersticas prprias (atributos) e que se
relacionam entre si (relacionamentos). (Peter Chen)

importante destacar que em geral modelamos utilizando o modelo

Entidade Relacionamento, porm criamos o banco e manipulamos as
informaes utilizando banco de dados relacional (Oracle, SqlServer,
Mysql,...). Esta distino deve ficar clara, para continuar o entendimento
sobre o modelo E-R. O que ocorre que em certa etapa do processo de
criao de um banco de dados, convertemos o modelo de forma que este seja
representado conforme o modelo relacional de cada banco de dados.

28

Banco de Dados I

Processo de Implementao de um Banco de dados E-R

O processo de elaborao de Banco de dados foi elaborado como forma
de definir etapas as quais podem ser seguidas que resultaro na criao de
forma fsica de toda estrutura de armazenamento. A figura 10 apresenta um
esquema que demonstra o processo de banco de dados, onde podem ser
destacadas as etapas de anlise de requisitos, modelagem conceitual,
mapeamento lgico e projeto fsico.

Figura 10 Exemplo de processo de implementao de banco E-R

O processo inicia a etapa de anlise de requisitos que faz parte do

processo de desenvolvimento de um sistema. A etapa de anlise consiste em
identificar os requisitos e funcionalidades que um sistema deva possuir. So
selecionadas todas as caractersticas e particularidades que esto
relacionadas modelagem de banco.
Somente aps conhecer as especificaes necessrias para o
desenvolvimento do sistema, ser possvel avanar de forma a no implicar
em futuras modificaes na estrutura de armazenamento e ou alteraes que
possam ser implementadas de forma simples com menos risco. Como j
apresentado na disciplina de engenharia de software, um dos custos que mais
impacta o desenvolvimento de um sistema, est atrelado em sua possvel
manuteno. Geralmente estas alteraes esto associadas a modificaes da
estrutura de armazenamento de dados, e isto pode resultar em possvel
inconsistncia de informao, o que segundo conceito de modelagem E-R,
viola regras de modelagem.

29

Banco de Dados I

A prxima etapa a modelagem conceitual que relata a descrio do

contedo da base de dados, e no das estruturas de dados usadas para
represent-lo. Seu enfoque a compreenso e descrio da realidade, das
propriedades relevantes da informao alm de desconsiderar todo e qualquer
aspecto de implementao. Esta sem dvida a maior contribuio de Peter
Chen para comunidade de banco de dados, pois atravs desta modelagem,
descrevemos a realidade sem se preocupar em qual banco de dados iremos
implantar, possibilitando uma viso macro da estrutura de armazenamento.
Como resultado da implementao do modelo conceitual, teremos um
digrama que representa o esquema conceitual da estrutura de
armazenamento. Este captulo tratar em mais detalhes desta modelagem no
prximo tpico.
Assim que o modelo conceitual estiver definido, este convertido para
o modelo lgico o qual descreve as estruturas que representam a base de
dados. Sua modelagem depender do tipo de SGBD alvo (relacional, rede,
hierrquico, OO). Nesta etapa possui como principal caracterstica a definio
no diagrama, das chaves primrias e estrangeiras, o que define de forma fsica
as relaes entre as entidades. Perceba que a partir desta etapa,
necessrio conhecer o SGDB que se pretende trabalhar. Como resultado desta
etapa, ser gerado um diagrama que representa a estrutura lgica do banco
de dados.
Por fim e no menos importante, o modelo lgico ser transformado no
modelo fsico, onde cada entidade, e seus atributos sero representados de
forma que o banco de dados possa ser construdo. Nesta modelagem ocorre a
escolha ou refinamento das estruturas de armazenamento e mtodos de
acesso. O modelo fsico leva em considerao o produto de SGBD especfico.
Como resultado, ser gerada uma descrio do esquema na DDL do SGBD.
comum nesta etapa que no modelo fsico j esteja implementado atravs de
uma DML, cdigos que executem a criao do banco de dados, como linhas de
comando em SQL que criam tabelas e estabeleam relaes entre estas.

Esquema Conceitual
Como j apresentado, o esquema conceitual tem como objetivo
desenvolver um diagrama que represente a realidade, sem se preocupar em
qual SGBD ser implementado. Seu enfoque est na compreenso e descrio
da informao, na seleo das propriedades relevantes da informao e na
descrio das restries sobre estes dados. Este esquema possui como
caracterstica o dilogo com usurios finais do sistema, de forma que possa
ser modificado para atender os requisitos, sem se preocupar com aspectos de
implementao.

30

Banco de Dados I

O seu formalismo grfico possui um padro que possibilita a sua

interpretao de forma universal. Assim, fica mais fcil de aprender,
compreender e associar com um requisito de sistema.
Seu formalismo grfico possui como primitivas bsicas:

Entidade
Relacionamento
Atributo
Cardinalidade

Entidade
Uma entidade descreve caractersticas comuns a todos os elementos
que deseja representar. Ela representa algo concreto como, por exemplo,
informaes de uma pessoa, dados de um veculo ou pode ser algo abstrato,
como departamento de uma empresa ou informaes de um curso. As
entidades so os primeiros elementos a serem identificados, principalmente
pelo fato destes estarem explcitos ou evidentes. Uma entidade possui um
nome (que define a entidade), atributo (caractersticas da entidade) e uma
identificao (atributo que identifica de forma nica uma informao
armazenada. Em geral este campo a chave primria da entidade). O
exemplo 1 apresenta uma especificao de uma entidade chamada produto.
Exemplo 1:
Entidade Produto: Descrevem caractersticas comuns a todos os
produtos que possam existir em um sistema de informao em um
dado momento, como Cdigo, nome do produto, seu estoque e valor
de venda.
Nome: Produto
Atributos: Cdigo, nome do produto, seu estoque e valor de venda.
Identificao: Cdigo

Sua representao grfica um retngulo contendo em seu centro o

nome da entidade que est representando. Por conveno o nome de uma
entidade deve ficar sempre no singular. A figura 11 apresenta um exemplo de
duas entidades Produto e Fabricante.

Figura 11 Exemplo de definio de entidades

31

Banco de Dados I

Atributo
Caracterstica, propriedade ou qualidade de uma ocorrncia de
entidade ou de relacionamento. Atributos so usados na definio de
conjuntos de entidades e de conjuntos de relacionamento. Atributos tambm
so conhecidos como propriedades, ou campos de uma entidade. No exemplo
1 j apresentado, os atributos da entidade produto so: cdigo, nome,
estoque e valor de venda.
A figura 12 apresenta sua representao grfica de acordo com o
modelo proposto por Peter Chen. Neste modelo, cada entidade possui um
conjunto de atributos. Como premissa, toda entidade necessita ter pelo
menos um atributo para existir. Observe que o atributo que identifica um
elemento especfico possui como representao um crculo fechado, enquanto
os demais atributos so representados por crculos abertos.

Figura 12 Exemplo de atributos em entidades

Um atributo pode ser simples (monovalorado) ou repetitivo

(multivalorado). No caso de ser simples, este possui um nico valor associado
a cada ocorrncia de uma entidade ou relacionamento. Por exemplo, o
atributo valor Venda, da entidade Produto da figura 12, possui apenas um
nico valor de venda para cada produto armazenado. J se este for repetitivo
ou multivalorado, um atributo poder possuir mais do que uma informao
armazenada no mesmo atributo, como o caso do atributo Fone da
entidade Fabricante, que poder armazenar mais do que um telefone para
um mesmo fabricante.
Outra caracterstica importante de um atributo se este obrigatrio
ou opcional. Dizemos que o atributo obrigatrio, quanto necessrio que
exista uma informao armazenada no atributo para que seja possvel
armazenar um registro. Por exemplo, se for definido que o campo nome da
entidade Produto obrigatrio, s ser possvel armazenar um registro na
tabela de Produto, se for informado algo no campo nome. Caso ocorra
uma tentativa de armazenamento sem que seja informada uma informao
neste campo, o SGBD no permitir o armazenamento e retornar um erro.
Porm se o campo for definido como opcional, o SGBD permitir o
armazenamento mesmo que no informada nada no atributo.

32

Banco de Dados I

Um valor de um atributo corresponde ao contedo existente em um

registro em um dado momento (dado armazenado na base de dado). Por
exemplo, o contedo armazenado no campo nome da tabela produto do
de um registro especfico Abacaxi.
Cada atributo possui um domnio, que caracteriza o que pode ser
armazenado na coluna especfica, como exemplo, tipo de informao (uma
data, uma hora, um nmero inteiro, um nmero real, um texto,...). Neste
domnio possvel especificar uma regra de armazenamento como permitir
somente nmeros inteiros no intervalo de 10 a 200.
Relacionamento
Segundo Peter Chen, 1976 um relacionamento uma associao entre
2 ou mais entidades. Desta forma, quanto existir uma associao entre
entidades distintas dizemos que existe um relacionamento entre estas
entidades. A figura 13 apresenta um exemplo da implementao de um
relacionamento. As entidades Professor e Curso possuem um conjunto de
elementos que esto associados na relao chamada Atuao Docente.

Figura 13 Exemplo de conjuntos de dados relacionados

Cada ocorrncia da entidade participante desempenha um papel no

relacionamento. Na figura 13 possvel atribuir um papel para o professor e
um papel para o curso. Exemplo:

Ana ministrou o curso de PHP, ou o curso de PHP foi

ministrado pela Ana
Carla professora de... ou Java possui como professor...

Desta forma, um conjunto de relacionamentos possui:

Nome: ATUAO-DOCENTE
Conjuntos de entidades participantes: PROFESSOR, CURSO
Para cada conjunto de entidades (ex: PROFESSOR)
- cardinalidade (mxima): N
- cardinalidade (mnima): 0

33

Banco de Dados I

- papel desempenhado (opcional): ministra

- atributos (opcional): ano/sem
Existe uma srie de notaes para modelagem de dados, contudo
utilizaremos neste documento o modelo proposto por Peter Chen. Assim a
figura 14 demonstra o modelo ER gerado de uma relao entre as entidades
Professor e Curso, denominada Atuacao_Docente.

Figura 14 Exemplo de relacionamento

A entidade professor possui como atributos o CPF, nome, endereo e

fone, sendo o atributo CPF, selecionado como sendo atributo que identifica os
registros, ou atributo que ser definido como sendo atributo de chave
primria. A entidade Curso possui dois atributos, o cdigo e nome. Da mesma
forma que o atributo CPF, o atributo cdigo, est definido como sendo
atributo de chave primria. O relacionamento Atuao_Docente, tambm
possui 2 atributos, o semestre e o ano. Observe que neste modelo, no existe
necessidade de especificar uma chave primria em um relacionamento, como
o caso dos atributos CPF e Cdigo das demais entidades. Tambm
importante destacar que no existe obrigatoriedade da existncia de atributos
no relacionamento como o caso da obrigatoriedade da existncia deste tipo
de atributo em entidades. Os atributos semestre e ano foram criados para
ilustrar a possibilidade da existncia de atributos em uma relao.
O exemplo, tambm aborda o conceito dos papis (ministra e
ministrado) os quais so exercidos por cada uma das entidades. Observe que
neste caso os papis so colocados no lado oposto da entidade que o origina.
Exemplo: o papel do professor ministra e est ao lado do curso,
possibilitando que seja possvel realizar uma leitura da relao da seguinte
forma. Um professor ministra Curso. J o papel de curso ( ministrado)
est ao lado da entidade professor. Neste caso l-se um curso ministrado
por professor. Os papis servem para realizar uma leitura da relao
existente entre as entidades e no so obrigados a serem apresentados no
diagrama. Contudo, sugere-se que seja colocado para melhor compreenso

34

Banco de Dados I

dos conceitos envolvido, principalmente quando o processo de conhecimento

de banco de dados est na etapa inicial.
Outra caracterstica importante no modelo apresentado a existncia
das cardinalidades de uma relao, representadas no exemplo 14 pelos
valores (1,n).
Cardinalidade
As cardinalidade identificam dentro de uma relao quantas
ocorrncias de uma entidade participam no mnimo e no mximo do
relacionamento. So divididas em:

Cardinalidade Mnima: define se o relacionamento entre duas

entidades obrigatrio ou no. Para isto o diagrama define os
valores 0 (zero) para no obrigatrio e 1 como sendo obrigatrio.
Cardinalidade mxima: Define a quantidade mxima de
ocorrncias da entidade que pode participar do relacionamento.
Neste caso a cardinalidade mxima sempre ser maior do que
zero.
A cardinalidade mxima define as restries de
integridade, adicionando semntica (significado) ao diagrama. O
modelo proposto por Peter Chen, define 1 como uma ocorrncia
mxima ou N para representar mais de uma ocorrncia de
relao.

A figura 15 demonstra de forma prtica a aplicao do relacionamento

emprego, gerado entre a relao professor e escola. A cardinalidade mnima
sempre informada primeiro, seguida da cardinalidade mxima. No exemplo
(0,n) definimos o elemento 0 (zero) como cardinalidade mnima e n como
cardinalidade mxima.

Figura 15 Exemplo de Cardinalidade Mnima e Mxima

Neste exemplo, um professor trabalha em pelo menos uma universidade

(cardinalidade mnima) e no mximo em uma escola (cardinalidade mxima),
j uma escola emprega nenhum (cardinalidade mnima) ou vrios professores
(cardinalidade mxima).

35

Banco de Dados I

Tipos de Cardinalidade de Acordo com o Relacionamento

Como j apresentado, as cardinalidades definem a quantidade de
ocorrncias de uma entidade que esto presentes na relao com outra
entidade. Tambm constatamos que existem dois tipos de cardinalidade a
mnima e a mxima. A grande parte dos modelos de dados apenas leva em
considerao a cardinalidade mxima, pois esta identifica o tipo de
cardinalidade de acordo com o relacionamento. Existem apenas 3 tipos:

1:1(um para um)

1:N(um para muitos)
N:N(muitos para muitos)

A figura 15, possui uma relao 1:N, j a figura 14 possui uma relao
N:N. Observe que para definir estes tipos de cardinalidade ou tambm
conhecido como tipos de relao, foram utilizadas apenas as cardinalidades
mximas de cada um dos exemplos apresentados nas figuras 14 e 15.
Cardinalidade Um para UM (1:1)
Dada duas entidades definidas como entidades A e B, dizemos que
existe uma cardinalidade 1:1, quando uma entidade em A est associada no
mximo a uma entidade em B e uma entidade em B est associada no mximo
a uma entidade em A. A figura 16 apresenta o conjunto de elementos de duas
entidades A e B distintas com cardinalidade 1:1. Observe que cada elemento
de cada uma das entidades possui apenas uma relao com um elemento da
outra entidade.

Figura 16 Exemplo um conjunto de dados de Cardinalidade 1:1

A figura 17 apresenta um exemplo de uma relao 1:1 entre as

entidades Homem e Mulher, chamada casamento monogmico.

Figura 17 Exemplo de Cardinalidade 1:1 Casamento Monogmico

36

Banco de Dados I

Neste exemplo cada homem pode participar (desempenhar o papel de

esposo) em no mximo uma ocorrncia de CASAMENTO, e cada mulher pode
participar (desempenhar o papel de esposa) em no mximo uma ocorrncia
de CASAMENTO
Cardinalidade Um para Muitos (1:N)
Dada duas entidades definidas como entidades A e B, dizemos que
existe uma cardinalidade 1:N, quando uma entidade em A est associada a
qualquer nmero de entidades em B, enquanto uma entidade em B est
associada no mximo a uma entidade em A. A figura 18 apresenta um exemplo
de dois conjunto de dados A e B com relao 1:N

Figura 18 Exemplo um conjunto de dados de Cardinalidade 1:N

Os diagramas apresentados na figura 19 descrevem exemplos do uso de

relaes 1:N. Observe que o exemplo a da figura 19 praticamente idntica
ao apresentado na figura 17, porm ao alterar a cardinalidade o sentido do
diagrama modificou-se completamente.

Figura 19 Exemplo de Cardinalidade 1:N

No exemplo a casamento Poligmico, cada homem pode participar

(desempenhar o papel de esposo) em vrias ocorrncias de CASAMENTO, j
cada mulher pode participar (desempenhar o papel de esposa) em no
mximo uma ocorrncia de CASAMENTO.

37

Banco de Dados I

No exemplo b que representa a participao de engenheiros em um

projeto, cada engenheiro pode participar em uma ou mais ocorrncias de
projeto, j cada projeto pode possui como responsvel no mximo uma
ocorrncia de PARTICIPAO de um engenheiro.
Cardinalidade Muitos para Muitos (N:N)
Dada duas entidades definidas como entidades A e B, dizemos que
existe uma cardinalidade N:N, quando uma entidade em A est associada a
qualquer nmero de entidades em B, e uma entidade em B est associada a
qualquer nmero de entidades em A. A figura 20 apresenta um exemplo de
dois conjunto de dados A e B, onde seus elementos podem se relacionar com
quaisquer elementos da outra entidade e vice versa.

Figura 20 Exemplo um conjunto de dados de Cardinalidade N:N

Os diagramas apresentados na figura 21 descrevem de forma prtica

como ocorre a definio de cardinalidade N:N.

Figura 21 Exemplo de Cardinalidade N:N

No exemplo a da figura 21, que representa a participao de

engenheiros em um projeto, cada engenheiro pode participar em uma ou mais
ocorrncias de projeto, e cada projeto tambm pode possui como responsvel
no mximo uma ou vrias ocorrncias de PARTICIPAO de um engenheiro. O

38

Banco de Dados I

exemplo b de fornecimento de produto, um produto pode ser fornecido por

vrios fornecedores, j um fornecedor pode fornecer mais do que um produto.
importante ressaltar que foram apresentados exemplos que possuem
as mesmas entidades e relacionamentos, entretanto o que mudou foi apenas o
tipo de relao entre eles. Pode parecer sem muita importncia esta
alterao, porm esta definio implicar em elaborar o banco de dados com
estruturas completamente diferentes de acordo com a definio do tipo. A
definio correta implicar tambm em elaborar uma interface correta para
cada tipo de relao. A escola equivocada trar um grande retrabalho para a
equipe de desenvolvimento. Desta forma fica o questionamento: como saber
o correto tipo de relao a ser aplicado?. A resposta simples, ela est na
etapa de levantamento de requisitos que foi elaborada junto ao cliente, antes
de dar incio ao desenvolvimento do projeto de banco. Uma anlise mal
elaborada causar a aplicao de forma errada do tipo de relao e com isto,
o desenvolvimento equivocado. Certamente ao apresentar parte do projeto ao
cliente, ser identificado o erro, porm o processo j gerou custos, e atrasos
em sua entrega. Sendo assim, sempre analise cada relao de forma a
implementar o tipo de relao que atenda as necessidades do cliente. A
mesma relao poder possuir tipos diferentes de acordo com a
implementao que se deseja realizar. A correta implantao depender de
cada caso. Isto pode ser evidenciado no exemplo b da figura 19 e no
exemplo a da figura 21, onde o que muda apenas a cardinalidade da
relao. Ambas esto corretas, mas sua aplicao depender de cada cliente.
Neste caso necessrio saber se o cliente realmente deseja que um projeto
possua como responsvel apenas um engenheiro ou mais de um. Somente de
posse desta informao ser possvel aplicar o tipo correto que atender a
necessidade do cliente final.

Generalizao/Especializao
Muitas vezes, quando analisamos um conjunto de entidades,
percebemos contedos iguais, que geralmente implicam em criar atributos
iguais em entidades diferentes. Por exemplo, imagine aluno e professor,
ambos possuem nome, CPF, data de nascimento entre outros campos
semelhantes. Normalmente criamos entidades distintas para ambos e
replicamos os atributos, adicionando outras caractersticas especficas para
cada entidade (carteira de trabalho, por exemplo, na entidade professor e
nome dos pais na entidade aluno). Em alguns casos existe outra alternativa de
representao. Ao invs de criar vrias entidades cria-se uma nica entidade
agrupando atributos comuns e outras entidades contendo somente os
atributos no compartilhados, em uma relao de generalizao ou
especializao. Este conceito de generalizao e especializao aplicado a
banco de dados. Por exemplo, vamos imaginar que seja necessrio armazenar

39

Banco de Dados I

informaes cadastrais de motoristas e engenheiros ambos empregados de

uma empresa. Dependendo o cenrio, estes podem possuir ambos nome,
endereo, bairro e CPF. Porm um motorista deve possuir o nmero de sua
carteira de habilitao e categoria. J um engenheiro deve possuir o seu
registro junto ao CREA(conselho de regulamentao de Engenheiros e
Arquitetos).
Neste caso ao invs de criarmos duas entidades contendo informaes
especficas de cada entidade (engenheiro e motorista) possvel utilizar o
conceito de generalizao/especializao. A figura 22 apresenta como seria a
implementao deste conceito.

Figura 22 Exemplo de Generalizao/Especializao

Na soluo proposta foi criado uma nova entidade chamada de

empregado que contm todas as informaes comuns entre os engenheiros e
motoristas. Em seguida foi definidas as entidades restantes contendo apenas
informaes peculiares a estas. Pela representao, foi adicionado um
triangulo representando a ligao entre a entidade emprego e as entidades
motorista e engenheiro, permitindo realizar uma leitura dizendo que alm dos
campos categoria e car_habilitacao existentes em motorista, este tambm
possui como campos todos os campos da entidade empregado. O mesmo
ocorre com a entidade engenheiro.

Recapitulando
Ao concluir este captulo, o leitor percebeu que o processo de
implementao de um banco de dados E-R, possui etapas importantes que
iniciam no levantamento de requisitos e concludo na implementao de
forma fsica do banco de dados.
Tambm foi estudada a estrutura proposta pelo modelo de Peter Chen,
onde foram apresentas as definies de entidades, atributos, relaes entre
entidades e cardinalidades.
Segundo estudos, a definio correta do tipo de relao (1:1 , 1:N e
N:N) indispensvel para atingir os objetivos do projeto elaborado de

40

Banco de Dados I

desenvolvimento da aplicao, minimizando a ocorrncia de aumento de

custos e atraso no desenvolvimento.

Atividades
Tendo como base nas afirmaes abaixo relacionadas marque (V) para as
assertivas Verdadeiras e (F) para as Falsas
V

1)

( )

( )

2)

( )

( )

3)

( )

( )

4)

( )

( )

Assertiva
Na etapa do esquema conceitual que compreende a modelagem
conceitual do processo de implementao de um banco de dados,
no necessrio saber qual o banco de dados que ser
implementado, pois a viso da informao no implica em qual
banco ser implementado.
Um atributo possui como caracterstica pode conter dados
Monovalorado ou dados repetitivos alm de permitir a
obrigatoriedade ou no da existncia de informao em seu
contedo.
Os tipos de Cardinalidade esto associados cardinalidade mnima
de uma relao
No modelo conceitual, um relacionamento possui:
- Nome
- Entidades que participam do relacionamento
- Cardinalidades mnimas e absolutas
- Papel desempenhado por cada entidade

5) Marque a alternativa que identifica o tipo de relao utilizada no exemplo

que segue:
a)
b)
c)
d)
e)

(
(
(
(
(

) 1:1
) 1:N
) N:N
) 0:N
) 0:1

Gabarito:
Questo 1 V
Questo 2 V
Questo 3 F (o correto associao pela cardinalidade mxima)
Questo 4 F (o erro est em que no existe cardinalidade e absoluta)
Questo 5 B

41

Banco de Dados I

Exemplos de Implementao do Modelo Conceitual

Christiano Cadon

Introduo
Neste captulo sero retomados alguns conceitos do modelo conceitual
e apresentado algumas novas especificidades deste modelo, atravs de
exemplos de construo deste diagrama. Desta forma, o aluno estar diante
de exemplos prticos que subsidiaro a elaborao destes diagramas
contribuindo na correta elaborao de um projeto de banco de dados.

Modelo Conceitual
Como j abordado no captulo anterior, o modelo conceitual, apresenta
uma viso de armazenamento, independente do SGBD que ser
implementado. Atravs deste modelo possvel identificar todas as entidades
e relaes existentes entre estas entidades, alm dos atributos necessrios de
cada entidade de um determinado domnio.
Partindo deste pressuposto, importante retomar que o modelo
depender exclusivamente do que a etapa de levantamento de requisitos
trouxe de informao para a elaborao do diagrama. Desta forma os
exemplos que seguem sero fruto exclusivo dos domnios que esto sendo
apresentados em cada exemplo. importante que seja destacado que o
diagrama poderia ser diferente dependendo da descrio do exemplo.
O diagrama conceitual a base para o desenvolvimento do modelo
lgico e por consequncia o modelo fsico. Assim sua correta elaborao
implicar na correta elaborao dos demais modelos, j que pelo processo,
um depende do outro.

Exemplo passo a passo de criao do Diagrama Conceitual

Tendo em vista, a necessidade da elaborao correta dos diagramas
conceituais, este tpico abordar um exemplo de uma descrio que ter
como consequncia a criao de um diagrama conceitual. No existe uma
ordem exata de desenvolvimento do diagrama, a nica premissa que exista
um domnio estabelecido contendo as necessidades a serem implementadas.
Contudo ser adotado neste documento um processo de elaborao, onde
inicialmente a partir de informaes do domnio, sero identificadas as
entidades, seus atributos, a relao entre as entidades determinado o tipo de
relao (1:1,1:N ou N:N) e por fim, determinar os atributos identificadores.

42

Banco de Dados I

importante que seja especificado que no est sendo considerado e aplicado

nestes primeiros exemplos o conceito de normalizao de dados, tema este
que ser abordado nos prximos captulos. Desta forma, caso exista algum
aluno que j conhea este conceito, perceber esta caracterstica.
Assim, o exemplo 2 apresenta uma descrio de um domnio hipottico,
no qual servir de base para elaborao do diagrama conceitual.
Exemplo 2: - Petshop
Uma Petshop deseja obter alguns controles sobre os animais vendidos em seu
estabelecimento e atendimentos realizados a estes. Segundo levantamento
necessrio armazenar o nome do animal, raa, data de nascimento e peso. Uma
venda possui um cliente, um nico animal, uma data e um valor que faz referencia ao
valor de venda do animal. Um animal somente pertencer a uma nica venda.
necessrio armazenar alguns dados sobre o cliente como seu nome, CPF, endereo
completo e telefone. Este cliente poder efetuar vrias compras de animais. Um
animal possui uma raa, j uma raa de vrios animais. A clnica tambm gostaria
de registrar os atendimentos realizados para cada animal. Cada atendimento possui
um animal, um veterinrio, uma data de atendimento e um cdigo de atendimento.
Um veterinrio poder atender nenhum ou vrios animais. Um animal poder ser
atendido vrias vezes, porm um atendimento possui apenas um animal. Um
veterinrio possui nome, registro no rgo responsvel e fone de contato. Um
veterinrio dever conter um nome, um cdigo de registro e um telefone de contato.

Como sugesto, vamos inicialmente identificar as entidades que esto

presentes na descrio. Uma entidade possui caractersticas especficas sobre
algo. Observe que as informaes sobre os dados das entidades esto
misturadas ao texto, por isso, o correto seria realizar mais de uma leitura. Ao
terminar a leitura possvel identificar princpio 5 entidades: Animal,
Cliente, Veterinrio, Atendimento e Venda, pois em cada uma destas
entidades o texto relata informaes para serem armazenadas. Neste ponto
j possvel desenhar as entidades e identificar os atributos que cada uma
das entidades faz parte. A figura 23 apresenta um esboo da elaborao desta
etapa. Note na realizao da primeira leitura do texto, cria-se uma falsa
impresso de que existem outros atributos em algumas entidades, como, por
exemplo, no trecho ...Uma venda possui um cliente, um nico animal, uma
data, e um valor que faz referencia ao valor venda do animal.... Neste caso
a tendncia que o cliente e o animal sejam atributos da entidade Venda,
porm tanto o animal e o cliente so entidades, pois no texto, ambos possuem
suas caractersticas estabelecidas. Na verdade o que ser criado uma
relao entre estas entidades, que refletir no mesmo efeito de forma
prtica. Sendo assim, no se preocupe inicialmente, em colocar estes
elementos como atributos e, ao perceber que o domnio descreve outras
informaes, gere uma entidade. Lembre-se que futuramente ser gerada
uma relao.

43

Banco de Dados I

Figura 23 Exemplo parcial 1 - Petshop

O prximo passo a definio das relaes existentes entre cada uma

das entidades. Como j abordado, atributos que inicialmente faziam parte da
entidade e no decorrer do texto se transformaram em outra entidade,
proporcionaro uma relao entre as entidades que originalmente faziam
parte com a entidade criada. o caso dos atributos cliente e animal que
davam a impresso de serem atributos da entidade venda. Neste caso ser
criada uma relao entre as entidades cliente e venda e outra entre as
entidades animal e venda. O mesmo ocorre na entidade atendimento, onde o
texto informava que o atendimento possui animal e veterinrio e ambos se
transformaram em entidades. Neste caso deve haver duas novas relaes,
sendo a primeira entre as entidades animal e a entidade atendimento e a
outra entre as entidades veterinrio e atendimento. A figura 24 apresenta
uma nova verso do diagrama agora com os respectivos relacionamentos.

Figura 24 Exemplo parcial 2 - Petshop

Outro ponto a ser destacado no diagrama da figura 24 a criao da

entidade Raa, que na figura 23 era atributo da entidade animal. Isto se deu

44

Banco de Dados I

pelo fato que o texto induz a criao da entidade. Segundo o texto ...Um
animal possui uma raa, j uma raa de vrios animais.... Perceba que o
texto relata um tipo de relao 1:N. Neste caso devemos criar uma nova
entidade e determinar um relao ligando a entidade que originou (neste caso
a entidade animal) e a nova entidade (neste caso a entidade Raa).
Os demais tipos de relao tambm foram determinados de acordo com
o texto. Segundo o exemplo temos 5 relaes com os respectivos tipos de
relao:

Relao compra entre as entidades Cliente e Venda: a relao

ficou definida como 1:N, pois o texto informa ...Uma venda
possui um cliente... o que determina que a cardinalidade
mxima do lado do cliente ser 1, e ...Este cliente poder
efetuar vrias compras de animais...
que determina a
cardinalidade N ao lado da venda. A figura 25 ilustra a definio
do tipo de relao 1:N, representando atravs do texto extrado
as cardinalidades mximas da relao.

Figura 25 Relao compra entre entidades cliente e venda

Relao compra entre as entidades Animal e Venda: a relao

ficou definida como 1:1, pois o texto informa ...Uma venda
possui...um nico animal... o que determina que a
cardinalidade mxima do lado do animal ser 1, e ...Um animal
somente pertencer a uma nica venda... que determina a
cardinalidade 1 ao lado da venda. A figura 26 descreve atravs
do texto, como foi definida a relao 1:1.

45

Banco de Dados I

Figura 26 Relao 1:1 entre as entidades Venda e Animal

Relao Caracterstica entre as entidades Animal e Raa: Como

j mencionado anteriormente o texto induziu a criao de uma
nova entidade, pois definiu uma relao 1:N. Sendo assim foi
criada uma nova entidade e definida uma relao que aqui foi
denominada de caracterstica. A figura 27 apresenta a definio
do tipo de relao 1:N, juntamente com o trecho que texto que
originou a relao.

Figura 27 Relao Caracterstica (1:N)

Relao Consulta entre as entidades Veterinrio e

Atendimento: Como possvel observar na figura 28, a relao
denominada consulta possui um tipo de delao 1:N, onde um
veterinrio realiza N atendimentos
e um atendimento
realizado por 1 veterinrio.Da mesma forma que os exemplos
anteriores esta definio estava especificada no texto.

46

Banco de Dados I

Figura 28 Relao consulta (1:N)

Relao Paciente entre as entidades Animal e Atendimento: Da

mesma forma que os demais tipos de relao, o tipo
determinado para a relao paciente teve origem no texto
apresentado no exemplo 2. Segundo o mesmo, a relao
paciente possui o tipo 1:N, onde um animal pode ser atendido
em vrios(N) atendimentos e um atendimento possui apenas um
animal. A figura 29 ilustra de acordo com o trecho do exemplo 2
a definio do tipo 1:N

Figura 29 Relao Paciente (1:N)

A figura 24 tambm apresentou alm dos tipos de relao s

cardinalidades mximas e mnimas definidas. A cardinalidade mxima est
explicita no texto, tanto que foram criados os tipos de relao. J a
cardinalidade mnima at aparece em alguns trechos do texto, mas no o
suficiente para elaborao completa do diagrama apresentado na figura 24.
Esta caracterstica no exclusividade somente no nosso exemplo 2. Em sua
maioria, as especificaes determinam somente as relaes e no a
obrigatoriedade de todas estas relaes. Isto se deve pelo fato de que quando
se realiza o levantamento de requisitos, no de desenvolve um digrama
conceitual, at porque, isto somente ser realizado posterior o levantamento

47

Banco de Dados I

de dados. Nestes casos a soluo contar com a expertise ou a lgica do

analista de banco de dados, que dever sempre validar seu diagrama junto ao
cliente em caso de dvida.
O exemplo apresentado na figura 29.a demonstra aplicao das duas
cardinalidades na relao de compra e a forma de como deve ser lida a
relao compra. Segundo o texto uma venda possui um cliente. Se possui um
cliente entende-se que obrigado que exista um cliente para que a venda
exista, e neste caso a cardinalidade mnima foi definida como sendo 1. O
texto relata que o cliente possui vrias compras, mas no relata nada se este
pode no possuir compra alguma. Neste caso foi optado em imaginar que um
cliente deva possuir pelo menos uma venda. Porm observe que neste caso
necessrio consultar o nosso cliente final para ter certeza desta informao.

29.a Definio de cardinalidades mnimas

A ltima etapa a definio dos atributos identificadores que

futuramente sero determinados como chaves primrias. Devemos selecionar
um atributo de cada entidade como sendo atributo identificador. Caso no
seja possvel, pois o contedo do atributo no garanta integridade de chave,
devemos selecionar mais de um atributo, criando uma chave composta, e ou
criar um novo atributo que gere a identificao. O diagrama apresentado na
figura 30 est finalizado e contm em cada uma das entidades um atributo
que o identifique.

48

Banco de Dados I

Figura 30 Exemplo final do Diagrama Conceitual da Petshop

Observe que foi criado um atributo novo nas entidades Venda, Animal e
Atendimento chamado de cdigo, o qual foi utilizado como atributo
identificador da entidade. Geralmente a soluo quando no existe um
identificador entre os atributos a criao de um cdigo. Constate tambm
que a entidade raa s possui um atributo denominada nome e este foi
utilizado como atributo identificador, pois pela lgica, no ser cadastrada
raas com o mesmo nome. Alguns analistas neste caso, preferem criar um
novo atributo (cdigo) e coloca-lo como atributo identificador.
O exemplo 3 apresenta outra descrio como forma de exemplificar a
criao do modelo conceitual. O domnio do exemplo 3 um hotel que
necessita controlar seu processo de hospedagem
Exemplo 3: - Hotel
Um hotel deseja informatizar seu processo de hospedagem. Sabe-se que necessrio
armazenar informaes de seus clientes, hospedagens por ele realizadas, e produtos
consumidos na hospedagem. O cliente possui cdigo, nome, endereo, cidade, estado,
CPF, RG e data de nascimento. Uma hospedagem possui um cliente, j um cliente pode
se hospedar nenhuma ou vrias vezes. Uma hospedagem possui tambm uma data de
entrada e uma data de sada. Uma hospedagem possui um quarto associado a ela j um
quarto pode estar relacionado a vrias hospedagens. Um quarto de uma categoria, j
uma categoria, pode estar relacionada com vrios quartos. Um quarto possui nome,
andar, categoria e nmero de camas.

Tendo como base o exemplo 3, podemos seguir o mesmo processo

realizado no exemplo 2, onde inicialmente identificamos as entidades. Em
seguida os atributos e relaes e por fim definir quais sero os atributos
identificadores. A figura 31 apresenta o diagrama conceitual gerado na
descrio apresentada no exemplo 3.

49

Banco de Dados I

Figura 31 Diagrama Conceitual parcial do Hotel

Aparentemente o diagrama possui todas as etapas definidas, entidade,

atributos, relacionamento, cardinalidades e atributos identificadores. Em
experincias j constatadas com alunos, ao apresentar o texto do exemplo 3,
estes em sua maioria, desenvolve um diagrama muito semelhante ao da figura
31. Ocorre que, se prestarmos ateno, faltou um item importantssimo no
diagrama que passou despercebido. A segunda frase do exemplo 3 relata
...Sabe-se que necessrio armazenar informaes de seus clientes,
hospedagens por ele realizadas, e produtos consumidos na hospedagem....
Como o restante do texto no fala nada sobre produtos consumidos na
hospedagem a tendncia desenvolver um diagrama idntico ao diagrama da
figura 31. Alguns at identificam esta informao e adicionam um atributo a
entidade hospedagem chamado produtos. Estaria at correto porm a nica
informao que temos produtos consumidos, est no plural o que leva a
dizer que uma hospedagem possui mais de um produto. Da mesma forma que
no atributo Raa da entidade Animal descrito no exemplo 2, a soluo correta
seria criar uma nova entidade, relacionando-a com a entidade hospedagem.
A figura 32 apresenta uma forma de soluo do exemplo 3 onde foi
criada uma nova entidade chamada produto relacionada com a entidade
hospedagem.

Figura 32 Diagrama Conceitual do Hotel Soluo 1

50

Banco de Dados I

Nesta soluo foram adicionados atributos que no so mencionados no

texto, como valor do produto na entidade produto e o atributo quantidade na
relao produto consumido. Isto ocorreu pela experincia do administrador
de banco que ao identificar que se trata de controlar o consumo de produtos,
imaginou que seja necessrio saber quanto de cada produto foi consumido e o
valor que cada produto custou. Neste exemplo o atributo quantidade ficou
associado relao, pois quantidade faz referencia a quantidade consumida e
no ao produto. Neste exemplo um produto possui caractersticas prprias de
produtos. A relao criada lida da seguinte maneira. Um produto pode ser
consumido em nenhuma ou em vrias hospedagens. Exemplo: possvel
vender refrigerante para vrias hospedagens. J uma hospedagem pode
possuir nenhum ou vrios produtos consumidos (exemplo: em uma
hospedagem possvel vender um refrigerante e um salgadinho).
Outra soluo no armazenar os dados de produtos de forma separada
do consumo realizado. Neste caso, o diagrama conceitual dever ser
modificado. A figura 33 apresenta esta outra soluo para os produtos
consumidos.

Figura 33 Diagrama Conceitual do Hotel Soluo 2

Nesta segunda soluo todos os atributos foram colocados na entidade

denominada Produtos Consumidos, alm do tipo de relao ter sido
alterada. A primeira soluo apresentada na figura 32 possua relao N:N, j
a soluo da figura 33 possui relao 1:N. Na prtica isto depender do que o
cliente final desejar implementar, pois se a implementao for a soluo 1,
este ter uma listagem de produtos e selecionar o produto que foi
consumido. J na soluo 2, ele no ter uma listagem de produto e sim
dever cadastrar sempre os produtos que foram consumidos. Novamente no
existe soluo correta at que esta informao seja validada junto ao cliente.
Este tipo de situao novamente ocorre por problemas na etapa de
levantamento de requisitos, pois nesta etapa que se obtm informaes
suficientes para soluo deste tipo de problema, o que na prtica no ocorreu
no exemplo 3.

51

Banco de Dados I

Sendo assim, a implementao do diagrama conceitual, depender

sempre do correto levantamento de requisitos. Outro fator importante a ser
considerado que em geral no existe uma nica soluo de desenvolvimento
do diagrama conceitual. Isto justifica o porqu existem tantos sistemas
desenvolvidos com o mesmo objetivo. Cada um possui uma estrutura
diferente. Avaliar se um diagrama est correto ou no depender
exclusivamente da existncia de requisitos que possam subsidiar o avaliador.

Recapitulando
Ao concluir este captulo, possvel realizar uma srie de constataes
prticas sobre o modelo conceitual, tendo em vista os exemplos de Petshop e
Hotel trabalhados.
Tendo como base as descries dos domnios possvel compreender
como ocorre a aplicao dos tipos de relao e a implantao das
cardinalidades mximas e mnimas. Tambm foi apresentada a soluo de
criao de novos atributos para atender a necessidade de definio de
atributos identificadores.
Segundo exemplos, foi possvel constatar a necessidade da correta
definio dos dados extrada no levantamento de requisito, como forma de
elaborar um diagrama conceitual sem que ocorram dvidas que possam
ocasionar atraso ou incerteza sobre a soluo de banco que est sendo
desenvolvida.

Atividades
1) Marque a alternativa que determina a correra leitura das cardinalidades
apresentadas no diagrama que segue:

a) ( ) Um produto possui uma categoria e uma categoria pertence a um ou vrios

produtos
b) ( ) Um produto pertence a uma categoria e uma categoria possui um ou vrios
produtos
c) ( ) Um produto pertence a nenhum ou a vrias categorias, j uma categoria
possui no mnimo um e no mximo um produto
d) ( ) Um produto possui nenhuma ou a vrias categorias, j uma categoria
pertence no mnimo um e no mximo um produto
e) ( ) Um produto possui uma categoria e uma categoria pertence a nenhum ou
vrios produtos

52

Banco de Dados I

2) Tendo como base o trecho que determina a criao de um modelo

conceitual e o modelo gerado, marque (V) para as assertivas Verdadeiras e (F)
para as Falsas que refletem as consideraes referentes ao diagrama
elaborado com base no domnio apresentado no texto:
Um supermercado necessita informatizar sua venda de produtos atravs do cupom fiscal.
Sabe-se que um cupom fiscal composto de um nmero, uma data e produtos que o compe.
Cada produto possui um cdigo, nome, uma classificao fiscal, um ndice de ICMS, e cdigo
de barras, e os fornecedores que fornecem os produto ao supermercado. Para cada produto
pertencente ao cupom necessrio armazenar a quantidade comprada do item

Tendo como base nas afirmaes abaixo relacionadas marque (V) para as
assertivas Verdadeiras e (F) para as Falsas
V

2)

( )

( )

3)

( )

( )

4)

( )

( )

5)

( )

( )

Gabarito:
Questo 1 E
Questo 2 F
Questo 3 V
Questo 4 F
Questo 5 V

Assertiva
O atributo quantidadecomprada deveria estar na entidade cupom
e no na relao
O atributo fornecedoredoproduto deveria ser uma entidade
possuindo relao com a entidade produto
O tipo de relao deste diagrama deveria ser 1:N e no N:N
O nome de produto no poderia ser identificador, pois pode
ocorrer de existir produtos cadastrados com mesmo nome

53

Banco de Dados I

Modelagem Lgica
Christiano Cadon

Introduo
Dando prosseguimento ao processo de banco de dados, este captulo
abordar a etapa de Modelagem lgica. Ser estudada a transformao do
modelo conceitual para o modelo lgico relacional possibilitando ao aluno
compreender de forma prtica os conceitos de chave primria e chave
estrangeira, alm de boas prticas na especificao das nomenclaturas do
diagrama.

Modelo Lgico
O modelo lgico descreve as estruturas que representam a base de
dados. Sua representao semelhante ao modelo conceitual, porm possui
suas particularidades. Diferentemente do modelo conceitual, para modelar
um diagrama lgico dependemos saber qual tipo de sistema gerenciador de
banco de dados ser implementado (relacional, rede, hierrquico, OO). Como
a proposta deste livro est embasada no modelo relacional, este ser utilizado
como base no decorrer deste material, at porque, como j mencionado
anteriormente, o modelo relacional, predomina no cenrio de
desenvolvimento que estamos atualmente inseridos. Sendo assim o modelo
lgico selecionado para representao dos exemplos o modelo relacional.
Relembrando, o modelo lgico possui como principal caracterstica a
definio no diagrama das chaves primrias e estrangeiras, o que define de
forma fsica as relaes entre as entidades. Da mesma forma que o modelo
conceitual, existe enumeras representaes deste diagrama, e geralmente os
fabricantes dos SGBD criam interfaces para modelagem seguindo um modelo
pr-estabelecido. O importante a ser definido aqui, que, independente do
modelo, o resultado de forma prtica ser o mesmo, o que muda sua
representao. De forma geral, ouso a definir, que se algum detm
conhecimento sobre um determinado modelo, certamente entender outro
modelo sem nenhuma dificuldade.
O modelo Entidade Relacionamento proposto por Peter Chen e
implementado como modelo conceitual, um modelo semntico que fala de
objetos (entidades e relacionamentos) que sero representados no banco de
dados, j o modelo relacional, representa o modelo de dado propriamente
dito que ser definido no SGBD.

54

Banco de Dados I

Enquanto o modelo ER descreve um banco de dados de forma

independente de implementao o modelo relacional descreve um banco de
dados a nvel de SGBD relacional.

Mapeamento modelo ER para Modelo Relacional

Aps estabelecido que o modelo lgico a ser implementado o modelo
relacional, partimos para transformao do modelo ER (conceitual), para o
modelo Relacional (lgico).
Para isto existe uma srie de transformaes proposta que so simples
de serem implementadas. A primeira delas implementao das entidades.
Cada conjunto de entidades implementado atravs de uma tabela. Os
atributos das entidades ER so implementados atravs de atributos no modelo
relacional. O atributo identificador fornece a chave primria da relao.
A figura 34 apresenta um exemplo da transformao da entidade Aluno
na tabela aluno no modelo relacional. No exemplo possvel visualizar a
definio do modelo relacional de duas formas. A primeira graficamente e a
segunda de forma textual. Ambas a formas de representao esto corretas,
mais a mais utilizada a grfica, por possuir como informao adicional o tipo
de dado que ser definido para cada um dos atributos, alm de ser mais
compreensvel em situaes de um conjunto contendo um nmero
significativo de entidades.

Figura 34 Transformao de entidade em tabela

Perceba que no modelo relacional o atributo de chave primria

identificado. No modelo grfico este ganhou um smbolo de uma chave, j no
modelo textual, o atributo ficou sublinhado.
Como j abordado, o modelo grfico j apresenta o conceito de tipo de
dado associado a cada um dos atributos, diferentemente do modelo textual.
Esta informao no obrigatria neste momento do processo de banco de
dados, porm quase todas as notaes j definem na elaborao do diagrama
a definio do tipo de dado de cada atributo. Isto se deve pelo fato que j

55

Banco de Dados I

existir uma definio de qual ser o banco de dados que ser implementado o
banco, e com isto j ter conhecimento dos tipos de dados suportados por
este. No exemplo apresentado na figura 34, apenas foi definido os tipos
nmero, texto e data, como forma de representar as informaes.
Geralmente o tipo de dados texto, definidos a quantidade mxima de
caracteres que seria necessria para armazenamento. J se tratando de
nmeros, importante dividir os campos que devem armazenar nmeros
inteiros dos campos de devem armazenar nmeros reias. Alguns campos que
normalmente so representados por nmeros, podem ser armazenados como
texto, como o caso do campo CPF que um nmero, e neste exemplo foi
definido com sendo do tipo texto. Isto se deve pois o analisa deseja
armazenas possivelmente os smbolos juntamente com os nmeros do CPF, o
que no possvel se este for definido como nmero. Em alguns casos existem
banco de dados, que possuem um recurso chamado, formatao, que permite
o armazenamento deste tipo de dado, e sua visualizao respeita uma
determinada formatao a qual apresenta os dados como se fosse um texto.
Contudo este recurso no implementado em todos os SGBD. Desta forma
estamos definindo neste material que se houver a necessidade de
armazenamento de informaes numricas contendo caracteres especiais
como CEP ou telefone, estes campos sero armazenados como texto.
Outra transformao relevante do modelo relacional em relao ao
modelo ER a definio das relaes. Neste caso a transformao depender
diretamente do tipo de relao definido no diagrama conceitual (1:1, 1:N ou
N:N).
Transformao de Relao do tipo 1:1
O mapeamento da de uma relao 1:1 depender diretamente da
cardinalidade mnima aplicada em cada relao. Caso exista obrigatoriedade
em abas cardinalidades mnimas de uma relao, a soluo a juno das
duas entidades participantes mais os atributos que existirem na relao em
uma nica tabela. O exemplo apresentado na figura 35 ilustra a aplicao da
transformao de uma relao do tipo 1:1 com as duas cardinalidades mnimas
obrigatrias.
Observe que as entidades empregado e equipamento se
transformaram em uma nica tabela chamada EmpregadoEquipemento,
contendo todos os atributos das entidades mais o atributo dataLocacao que
estava na relao Alocado. Como as duas entidades possuam um
identificador nico no modelo conceitual, na transformao no ocorre a
necessidade de existir uma chave primria composta, por mais que no esteja
errado ocorrer. Neste caso foi elegido um dos atributos como sendo chave
primria e implementado no diagrama.
Outra considerao a modificao dos nomes do atributos. Observe
que neste exemplo o nome dos atributos foi alterado como forma de

56

Banco de Dados I

identificar melhor o que cada um ir armazenar, at porque, vamos imaginar

que o campo identificado do equipamento possusse o nome de cdigo ao
invs do nmero, ambos campos teriam o mesmo nome, e isto no poderia ser
implementado na transformao.

Figura 35 Transformao relao 1:1 com cardinalidades obrigatrias

A prtica de determinar no prprio nome do atributo uma identificao

comum, alm de possibilitar maior clareza sobre o que ser armazenado em
cada campo. Uma prtica no usual, a determinao de nomes de atributos
atravs de identificadores como por exemplo atributos com nomes A1,
A2, A3, onde A1 representa o cdigo, A2 representa o nome, e A3
representa o telefone. Alm de desenvolver um diagrama com pouco ou
nenhum sentido, ocasiona ao desenvolvedor que ir utilizar este banco de
dados, confuso e atraso no desenvolvimento, pois estes alm de se basear no
diagrama desenvolvido tero que consultar em uma tabela o que significa
cada um dos atributos.
Caso exista uma relao 1:1 onde apenas um dos lados opcional, ou
seja, a cardinalidade mnima de um dos lados 0 (zero) e a outra 1 (um), a
transformao um pouco diferente. Neste caso , sero geradas duas tabelas
e a tabela que contm o lado opcional (0-zero), conter um novo atributo que
ser um atributo de chave estrangeira referenciando a chave primria da
entidade de lado obrigatrio.
O exemplo apresentado na figura 36 ilustra a transformao para o
modelo relacional de uma relao 1:1 com as entidades correntista e carto
magntico, onde um dos lados opcional, ou seja, um correntista pode no

57

Banco de Dados I

ter um carto magntico, j um carto magntico sempre ser de propriedade

de um correntista.

Figura 36 Transformao relao 1:1 com uma cardinalidade opcional

Observe que neste exemplo, abas as duas entidades se transformaram

em tabelas e a tabela cartaoMagnetico, possui 2 novos atributos, sendo o
primeiro o atributo que estava na relao e o segundo o atributo conta, que
uma chave estrangeira referenciando a tabela de correntista. Na primeira
forma de representar (representao grfica), o campo conta, possui como
smbolo uma chave com outra cor, j na segunda forma de representar
(textual) o atributo conta possui um trao em cima de seu nome
representando ser uma chave estrangeira.
No caso da existncia de uma relao 1:1 onde ambos os lados so
opcionais, ou seja, a cardinalidade mnima dos dois lados 0 (zero), a
transformao possui uma nova caracterstica. Neste caso, sero geradas alm
das duas tabelas que representam as entidades, mais uma tabela, que
armazenar a relao propriamente dita. Esta nova tabela ser composta
pelos atributos que nela existirem alm dos atributos chave estrangeira que
faro referencia as outras duas entidades envolvidas na relao.
A figura 37 apresenta uma relao entre as entidades pessoa e cargo do
tipo 1:1, onde ambos os lados so opcionais, ou seja, uma pessoa pode estar
alocada para no mximo um cargo e um cargo pode possuir no mximo uma
pessoa alocada. Porm ambos podem no possuir nenhuma alocao.
Segundo exemplo a relao que se chamava alocao, foi transformada
em uma tabela contendo os atributos que j possua (data e regime) alm de
mais outros dois atributos codpes e codcargo, que so chaves estrangeiras das
entidades pessoa e cargo. Por definio sabemos que toda entidade ou tabela

58

Banco de Dados I

necessariamente precisa de uma chave primria que a identifique. Neste caso

optamos por criar uma chave primria composta pelas duas chaves
estrangeiras. Desta forma os atributos codpes e codcargo, so chaves
primrias e estrangeiras ao mesmo tempo. Outra alternativa seria a criao de
um novo atributo que possa ser utilizado como chave primria como por
exemplo cdigo.

Figura 37 Transformao relao 1:1 com ambas cardinalidades mnimas opcionais

Perceba que as relaes que foram criadas entre as entidades pessoa e

entidade cargo continuam sendo 1:1, porm a cardinalidade mnima ficou
definida com sendo 1 e no mais 0 (zero) como o modelo conceitual. Desta
fora, criado uma obrigatoriedade de ao informar um novo registro na tabela
de Alocacao, seja obrigado informar um cargo e uma pessoa.
Transformao de Relao do tipo 1:N
O mapeamento da de uma relao 1:N bem mais simples do que o
tipo 1:1. No mapeamento 1:N, transformamos as entidades em tabelas e a
entidade que possui o lado N conter um novo atributo que ser a chave
estrangeira referenciando a chave primria da outra entidade. Todos os
atributos que pertencerem a relao tambm sero encaminhados para a
entidade que possui seu lado N.
O exemplo apresentado na figura 38 ilustra a transformao do modelo
conceitual para o modelo lgico relacional das entidades departamento e
empregado contendo uma relao 1:N. Observe que na tabela empregado que
possui o lado N, foi adicionado um novo atributo chamado coddep que foi
definido como chave estrangeira da tabela de empregado. Um outro fator

59

Banco de Dados I

relevante que ainda no havia sido comentado at ento faz referncia ao

tipo de dado da chave estrangeira. Toto atributo de chave estrangeira dever
obrigatoriamente possuir o mesmo tipo de dado da chave primria que esteja
referenciando.

Figura 38 Transformao de modelo relao 1:N

O atributo dataAlocacao que estava na relao tambm

foi
encaminhado para a entidade que possua o lado N, neste caso a entidade
empregado.
A cardinalidade mnima que antes influenciava na criao das entidades
aqui somente servir para determinar se o atributo de chave estrangeira
poder armazenar valores nulos ou no. Sendo assim, esta somente dever ser
testada no lado N da relao 1:N. No exemplo da figura 38, o lado N possui
cardinalidade mnima 1 o que gera a obrigatoriedade de existir um
departamento em um empregado. A definio desta obrigatoriedade ser
aplicada na etapa de modelagem fsica, onde ser construdo o banco de
dados.
Transformao de Relao do tipo N:N
Uma relao N:N, indica a existncia de mltiplos registros entre
entidades. Desta forma, o mapeamento de uma relao N:N gerar
impreterivelmente uma nova tabela no lugar da relao unindo de forma
fsica as outras duas tabelas geradas pela relao. Nesta, todos os atributos
que faziam parte da relao faro parte na nova tabela, alm da criao dos
atributos que sero as chaves estrangeiras, que faro referencia as outras
tabelas que faziam parte da relao.

60

Banco de Dados I

A figura 39 apresenta a transformao da relao do tipo N:N entre as

entidades engenheiro e projeto. Neste exemplo um engenheiro pode ser
alocado a um ou a vrios projetos, e um projeto possui um ou vrios
engenheiros vinculados.

Figura 39 Transformao de modelo relao N:N

Quando transformamos um tipo de relao N:N, as cardinalidades

mximas e mnimas sempre ficaro ao lado da relao e o outro lado receber
a cardinalidade mnima e mxima 1 (1,1). Isto pode ser percebido no exemplo
39 onde as cardinalicades que estavam em engenheiro e projeto passaram a
fazer parte na tabela Alocacao, enquanto ao lado das tabelas Engenheiro
e Projeto, foram adicionadas as cardinalidades (1,1).
Perceba que a tabela Alocado, foi criada no lugar da relao, e esta
possui o atributo dataAlocacao, que fazia parte da relao. Tambm foram
criadas as chaves estrangeiras CodEng que faz referencia a tabela de
engenheiro e CodProj que faz referencia a tabela de projeto. Neste
exemplo foi definido que a chave primria da tabela de Alocado composta
pelos atributos de chave estrangeira. Com isto garantimos que exista um
identificador nico e que no seja possvel um mesmo engenheiro estar
alocado para um mesmo projeto mais de uma vez.
Contudo, a criao de uma chave primria composta nem sempre a
melhor alternativa, e em alguns casos no pode ser implementada sob risco
de inviabilizar o sistema desenvolvido. Observe o exemplo apresentado na
figura 40 que contm uma relao N:N entre as entidades CupomFiscal e
Produto, onde a relao ItensVendidos, foi transformada em uma nova
tabela contendo como chave primria um novo atributo codigoItem.

61

Banco de Dados I

Figura 40 Transformao de modelo relao N:N (criando novo atributo primrio)

Neste caso, os atributos de chave estrangeira existentes na tabela

ItensVendidos so codProd referenciando a tabela de Produto e
numCupom referenciando a tabela de CupomFiscal. Estes no podem ser
definidos como chave primria composta pois na prtica se determinarmos
isto, no ser possvel existir em um mesmo cupom fiscal mais do que um
lanamento de produto, o que comum que ocorra em estabelecimentos
comerciais (permitir mais de um registro do mesmo produto em uma venda).
Imagine como exemplo um carrinho de compras de um supermercado
contendo muitos itens. normal que ocorra registros de mesmo itens na
mesma compra em momentos diferentes, como passar um sabonete logo no
incio da compra e outro no final. O operador deve poder passar novamente
um item idntico ao j passado anteriormente. Perceba que se tivssemos
definido que a chave primria seria composta, isto no seria permitido, mas a
alternativa apresentada na figura 40, permite que isto ocorra sem problemas.
Assim, a melhor forma de definio depender da aplicao a ser
implementada. Em algumas situaes definiremos as chaves estrangeiras
como chaves primrias compostas, e em outras definiremos outro atributo
como sendo chave primria.
Transformao de uma auto relacionamento.
A transformao do modelo conceitual para o modelo lgico relacional
de um auto relacionamento depender do tipo de relao existente no auto
relacionamento. Se o tipo de relao aplicado no auto relacionamento for 1:1
ou 1:N, dever ser criado um novo atributo na entidade contendo uma chave
estrangeira que ser associada ao atributo de chave primria da mesma
entidade. O exemplo apresentado na figura 41 apresenta uma associao 1:N
de um auto relacionamento, onde possvel identificar que no modelo

62

Banco de Dados I

relacional implementado foi criado um campo chamado codsup que uma

chave estrangeira vinculada a chave primria codEmp da mesma tabela
empregado.

Figura 41 Transformao de um auto relacionamento 1:N

Se um o tipo de relao de um auto relacionamento for N:N, ocorre a

necessidade de criao de uma nova entidade no lugar na relao. Esta
conter dois campos definidos como chaves estrangeiras que faro referencia,
ambos a mesma chave primria da tabela que contm a auto relao. A
figura 42 apresenta o mesmo exemplo de entidade, porm com o tipo de
relao N:N, onde um empregado pode ser supervisor de nenhum ou vrios
empregados, e um empregado poder ser supervisionado por nenhum ou
vrios supervisores.

Figura 42 Transformao de um auto relacionamento N:N

63

Banco de Dados I

Neste exemplo a relao superviso se transformou em uma tabela

contendo dois campos (codEmp e codSup), sendo estes chaves primrias
compostas e chaves estrangeiras referenciando a entidade empregado
Transformao de Generalizao/Especializao.
Como j abordado, o conceito de generalizao e especializao
utilizado no modelo conceitual para representar informaes comuns de um
conjunto de entidades (generalizao), e em seguida possuem uma diviso
criando outras entidades contendo especificacidades destas entidades criadas
(especializao). A transformao do modelo conceitual no modelo lgico
relacional neste caso, pode ocorrer de trs formas distintas, abas corretas. A
aplicao da melhor forma depender da forma como ser implementado o
sistema.
Usaremos como base a figura 43 j apresentada anteriormente como
exemplo de generalizao/especializao, para representar as trs formas de
transformao para o modelo lgico relacional.

Figura 43 Modelo Conceitual Generalizao/Especializao

A primeira alternativa de transformao a implementao de

diferentes tabelas com uma tabela para dados comuns. Esta soluo muito
semelhante ao conceito de classes e heranas de orientao a objetos. A
figura 44.a apresenta cada uma das entidades implementadas como tabelas, e
nas entidades especializadas Motorista e Engenheiro existe um campo de
chave estrangeira ligando-se tabela de Empregado. Estes atributos de
relao tambm serviram como atributos de chave primria.

64

Banco de Dados I

Figura 44.a Alternativa 1 de transformao generalizao/especializao.

A segunda alternativa de transformao a implementao de uma

nica tabela contendo todos os campos das entidades participantes da
generalizao/especializao. Nesta soluo em geral criado um novo
atributo como forma de identificar o tipo de especializao desejada. No
exemplo da figura 44.b identificamos a implementao do modelo lgico
relacional de generalizao/especializao onde percebido a criao do
atributo tipo_emp que servir como identificador de tipo de empregado que
se deseja armazenar. Este tipo de atributo conhecido como atributo flag,
pois possui como funcionalidade setar uma determinada informao.

Figura 44.b Alternativa 2 de transformao generalizao/especializao.

A terceira alternativa de transformao a implementao das

entidades especializadas em tabelas contendo todos os atributos que estas
possurem, mais os atributos que so originrios da entidade generalizada. As
entidades resultantes no sero relacionadas e seus dados ficaro
independentes. A figura 45 apresenta o resultado utilizando a terceira
alternativa.

Figura 45 Alternativa 3 de transformao generalizao/especializao.

65

Banco de Dados I

Recapitulando
Ao concluir este captulo, o aluno percebeu que o modelo lgico possui
como principal caracterstica o conceito de relacionamento atravs de campos
de chave primria e estrangeira.
O modelo lgico relacional possui uma estrutura bem mais simples que
o modelo conceitual proposto por Peter Chen, tanto que o resultado da
transformao dos modelos conceituais para o modelo lgico relacional
resulta em um conjunto de tabelas, atributos e relaes definidas pelos
atributos de uma tabela.
Atravs dos exemplos apresentados, foi possvel identificar como ocorre
a transformao do modelo conceitual para o modelo lgico, onde foram
abordados a transformao das entidades em tabelas, dos tipos de relao e
da generalizao/especializao.

Atividades
1) Tendo como base o diagrama conceitual, marque a alternativa correta que
representa a transformao para o modelo conceitual

a) ( ) Ser criada duas tabelas disciplina e professor e o atributo semestre ser

armazenado na tabela professor
b) ( ) Dever ser criado trs tabelas, sendo duas para cada entidade e uma terceira
para a relao ministrar que conter alm do atributo semestre, mais outros dois
atributos de chave estrangeira referenciando as entidades disciplina e professor
c) ( ) Ser criada duas tabelas disciplina e professor e o atributo semestre ser
armazenado na tabela disciplina
d) ( ) Ser criada apenas uma nica tabela contendo todos os dados das entidades
disciplina e professor alm do atributo semestre existente na relao ministrar
e) ( ) Dever ser criado trs tabelas, sendo duas para cada entidade e uma terceira
para a relao ministrar que conter dois atributos de chave estrangeira
referenciando as entidades disciplina e professor. Por ser uma relao, o atributo
semestre dever ser armazenado no lado obrigatrio, que neste caso faz
referencia a tabela professor.

66

Banco de Dados I

2) Tendo como base o diagrama conceitual apresentado e o diagrama lgico

relacional proposto para este, marque (V) para as assertivas Verdadeiras e (F)
para as Falsas:

2)

( )

( )

3)

( )

( )

4)

( )

( )

5)

( )

( )

Gabarito:
Questo 1 B
Questo 2 V
Questo 3 V
Questo 4 V
Questo 5 F

Assertiva
A transformao do tipo de relao est correto, pois criou duas
tabelas colocando no lado N um atributo de chave estrangeira
referenciando a outra entidade
As cardinalidades existentes na primeira fora de representar esto
invertidas
O atributo existente na relao no foi implementado. O correto
seria coloc-lo em uma tabela
Pela tabela de veculo possuir um atributo de chave estrangeira,
este dever tambm fazer parte da chave primria de veculo.

67

Banco de Dados I

Modelagem Fsica, Normalizao de Dados e lgebra

Relacional
Christiano Cadon

Introduo
Dando prosseguimento ao processo de banco de dados, este captulo
inicia com a etapa de Modelagem lgica. Ser estudada a transformao do
modelo conceitual para o modelo lgico relacional possibilitando ao aluno
compreender de forma prtica os conceitos de chave primria e chave
estrangeira, alm de boas prticas na especificao das nomenclaturas do
diagrama.
Em seguida sero bordados conceitos de normalizao de dados e
lgebra relacional, apresentando exemplos prticos de sua aplicabilidade.
Desta forma, este estudo possibilitar ao aluno concluir o processo de banco
de dados e ter uma viso de lgebra relacional a qual a base de diversas
linguagens DML como o SQL.

Modelo Fsico
A modelagem fsica a ltima etapa do processo de banco de dados.
Nesta etapa o modelo lgico ser transformado em uma estrutura, onde cada
tabela e seus atributos sero representados de forma que o banco de dados
possa ser construdo. O resultado desta aplicao uma descrio do esquema
DDL do SGDB, ou seja, teremos uma definio de todos os tipos de dados,
quais sero os ndices aplicados, mtodos de acesso entre outros. A partir
deste modelo possvel utilizar uma linguagem DML como, por exemplo, SQL
para criar um banco de dados contendo todas as informaes que o modelo
lgico gerou. Impreterivelmente nesta etapa o banco de dados j deve ter
sido definido.
No existe nenhum diagrama para representar o modelo fsico, sua
representao depender da metodologia de trabalho que cada empresa
desenvolvedora utiliza. O que ocorre geralmente nesta etapa, e o registro de
criao atravs de uma linguagem DML das tabelas como o caso do da
utilizao do comando CREATE TABLE e ALTER TABLE da linguagem SQL.
Como forma de representar o processo como um todo, o exemplo 4
apresenta uma descrio de um domnio que serve como base para elaborao

68

Banco de Dados I

de um processo de banco de dados que inicia-se na modelagem conceitual e

concludo no modelo fsico.

Exemplo 4: - Matrias primas de Sorvete

Uma sorveteria necessita informatizar o processo de registro de matrias primas
necessrias para produo de seus sorvetes. Sabe-se que um produto possui um cdigo,
um cdigo de barras, um nome comercial, e um valor de custo. Cada produto possui uma
ou vrias matrias primas, j uma matria prima pode ser de nenhum ou vrios produtos.
Uma matria prima possui um cdigo, um nome e um valor de compra. Para cada
matria prima adicionada a produto necessrio armazenar uma quantidade necessria
da matria prima para compor o mesmo.

A figura 46 apresenta uma alternativa de soluo para o exemplo 4

passando pela modelagem conceitual, sendo transformado para o modelo
lgico relacional e concludo no modelo fsico com instrues SQL de criao
de tabelas e suas respectivas relaes.

Figura 46 Etapas do processo de Banco de dados.

O cdigo gerado no modelo fsico ser detalhado no decorrer dos

prximos captulos onde ser abordada a linguagem SQL. O importante a ser
destacado no exemplo de modelagem fsica, est relacionado ao tipo de dado.
Perceba que o mesmo tipo de dado definido no modelo lgico foi aplicado no
modelo fsico, alm claro no mesmo nome dos atributos e entidades.

69

Banco de Dados I

Normalizao de Dados
O principal objetivo de normalizar tabelas est no fato de evitar os
problemas causados por falhas no projeto do banco de dados, bem como
eliminar a mistura de assuntos, evitando as correspondentes repeties
desnecessrias de dados.
Um fato a ser sempre observado em um projeto de banco de dados
baseado no modelo relacional o de no misturar assuntos em uma tabela.
Um exemplo disto seria em uma tabela de clientes colocar apenas os dados de
clientes. Informaes como seus pedidos, contas a receber devem estar em
outras tabelas. No devemos misturar os assuntos, pois como consequncia
teramos repeties desnecessrias, bem como uma possvel inconsistncia de
informao.
O Processo de normalizao aplica uma srie de regras sobre as tabelas
de um banco de dados, para verificar se esto bem projetadas. Embora exista
5 formas normais (regras) , na prtica usamos apenas 3 formas normais.
comum aps a aplicao das regras de normalizao, algumas tabelas
acabam sendo dividas em duas ou mais tabelas, o que no final, gera um
nmero maior de tabelas do que originalmente existe. Neste processo
observamos a simplificao dos atributos colaborando significativamente com
a estabilidade do modelo de dados, reduzindo-se consideravelmente as
necessidades de manuteno.
Primeira forma normal
Uma tabela est na primeira forma normal quando seus atributos no
possuem grupos de repetio. Considere a estrutura da tabela representada
na figura 47 e o exemplo de dados armazenados nesta.

Figura 47 Problemas na primeira forma normal.

70

Banco de Dados I

Uma tabela com esta estrutura apresenta diversos problemas, por

exemplo, se um fornecedor ou categoria possuir mais de um produto, ser
necessrio digitar diversas vezes, tantas quanto forem os produtos. Isto forma
um grupo de repeties. Alm do mais pode ser que por erro de digitao o
nome da categoria ou fornecedor no seja digitado exatamente igual todas as
vezes, o que poder acarretar problemas na hora de fazer pesquisas ou emitir
relatrios. No exemplo de tabela populada da figura 47, possvel evidenciar
os dois problemas apresentados.
Este problema ocorre porque misturamos assuntos em uma mesma
tabela. Colocamos as informaes de categoria e fornecedor na tabela de
produto. A resposta para este problema simples: Criamos uma tabela de
fornecedor e uma tabela de categoria relacionando-as com a tabela de
produto, utilizando um relacionamento um para muitos, ou seja, um
fornecedor poder ter vrios produtos; uma categoria pertence a vrios
produtos. A figura 48 apresenta a soluo para o problema de primeira forma
normal.

Figura 48 Aplicao da primeira forma normal

Conforme a soluo apresenta, a tabela de produtos possuir somente

os dados de chave estrangeira das demais tabelas de relao.
Segunda forma normal
A segunda forma normal ocorre quando a chave primria composta
por mais de um campo (chave composta). Neste caso, devemos observar se
todos os campos que no fazem parte da chave dependem de todos os campos
que compem a chave. Se algum campo depender somente de parte da chave
composta, ento este campo deve pertencer outra tabela. Observe a figura
49.

71

Banco de Dados I

Figura 49 Erro na Segunda Forma normal

A chave primria composta formada pela combinao dos campos

numMatricula e codCurso. O campo avaliacao depende tanto do
codCurso quanto do numMatricula, porm o campo nomeCurso depende
apenas do codCurso, ou seja, dado o cdigo do curso possvel localizar a
respectiva descrio, independentemente do nmero da matricula. Com isso
temos um campo que no faz parte da chave primria (nomeCurso) e
depende apenas de um dos campos que compem a chave primria composta.
Dizemos que esta tabela no est na segunda forma normal.
A resoluo deste problema tambm simples. Dividimos a tabela que
no est na segunda forma normal em duas tabelas, colocando o atributo que
depende somente de um atributo da chave primria composta em outra
tabela que contm como chave primria o atributo de dependncia. A figura
50 ilustra a soluo da segunda forma normal.

Figura 50 Soluo para erro na segunda forma normal

Terceira forma normal

Na definio dos campos de uma entidade, podem ocorrer casos em
que um campo no seja dependente diretamente de uma chave primria ou

72

Banco de Dados I

de parte dela, mas sim dependente de outro campo da tabela. Neste caso,
dizemos que a tabela no est na terceira forma normal. Observe o exemplo
da figura 51.

Figura 51 Erro na Terceira Forma Normal

Observe que o campo nomeCargo depende apenas do campo

codCargo, o qual no faz parte da chave primria. Por isso dizemos que esta
tabela no est na terceira forma normal. A soluo deste problema
simples, basta dividir a tabela em duas colocando o campo dependente
(nomeCargo) juntamente com o campo que o mesmo depende (codCargo) em
uma outra tabela. A tabela original ter apenas uma clave estrangeira
relacionada com a tabela criada em uma relao 1:N. A figura 52 ilustra a
soluo para o problema apresentado.

Figura 52 Soluo da Terceira Forma Normal

lgebra Relacional
A partir no desenvolvimento do modelo relacional, que definiu tabelas
e relao entre tabelas na dcada de 1970, surgiu a necessidade de extrair
informaes armazenadas neste modelo de dados. Nesta mesma poca, foram
estudados diversas metodologias, porm a que mais obteve resultado

73

Banco de Dados I

significativo foi a lgebra relacional. A lgebra Relacional uma linguagem de

consulta procedimental que possui operaes que produzem como resultado
uma relao contendo como resposta a pesquisa definida. Esta linguagem a
base do funcionamento de praticamente todas as instrues da linguagem
SQL, que atualmente a linguagem mais utilizada para manipulao de dados
em um banco de dados relacional.
Ela possui uma srie de operadores, mas os mais significativos so 6:

Seleo
Projeo
Produto Cartesiano
Unio
Diferena
Juno

Como forma de realizar exemplos relacionados aos cinco principais

operadores, a figura 53 apresenta duas tabelas populadas, que serviro como
base para exemplificar cada um dos operadores.

Figura 53 Tabelas base para exemplificar operadores relacionais

Seleo
Este operador tem como funo selecionar tuplas que satisfazem uma
dada condio (predicado). Sua aplicao produz um subconjunto horizontal
de uma relao. Sua notao :

Onde o <predicado> permite o uso de operadores relacionais. A figura

54 apresenta um exemplo da aplicao da operao de seleo, para
selecionar as tuplas da relao contas onde o nome da agncia seja
Farrapos

74

Banco de Dados I

Figura 54 Exemplo da aplicao de Seleo

Projeo
O operador de projeo seleciona atributos de interesse produzindo um
subconjunto vertical de uma determinada relao. Sua notao :

No exemplo apresentado na figura 55 so listados apenas os campos de

numConta e nomeCli da relao Contas. .

Figura 55 Exemplo da aplicao de Projeo

Produto Cartesiano
O produto cartesiano compreende a combinao de tuplas para
obtenso de dados presentes em duas ou mais relaes. O produto cartesiano
literalmente executa uma multiplicao dos registros envolvidos nas relaes.
Sua notao :

Sua resposta conter um conjunto contendo todas as colunas que

envolvem as relaes. A figura 56 apresenta o produto cartesiano entre as
tabelas Contas e Agncia.

75

Banco de Dados I

Figura 56 Exemplo da aplicao do Produto Cartesiano

Observe que para cada registro da tabela de Contas foi gerado uma
relao com todos os registros da tabela Agncia. Desta forma, se existir
como o caso do exemplo da figura 53, cinco registros na tabela de Contas e
trs registros na tabela de Agncia, ter um total de quinze registros como
resposta (5x3=15).
Sob o ponto de vista de produto cartesiano est correta a informao
apresentada na figura 56, porm sob o ponto de vista do contedo
apresentado, somente 5 linhas das 15 possuem a informao correta. Sendo
assim podemos utilizar uma seleo contendo um predicado que relaciona as
tabelas contidas no produto cartesiano. A figura 57 apresenta a aplicao de
uma regra sobre o produto cartesiano.

Figura 57 Exemplo da aplicao do Produto Cartesiano com regra de predicado

A figura 58 apresenta um refino ainda maior. Neste exemplo estamos

apresentando apenas o nome do cliente e o nome da agncia que est
relacionada a conta do cliente.

76

Banco de Dados I

Figura 58 Exemplo da aplicao do Produto Cartesiano

Unio
O operador unio une tuplas de duas relaes que sejam compatveis.
Neste caso que possuam, o mesmo tipo de dado como reposta. A notao de
unio :

O exemplo apresentado na figura 59 ilustra a implementao da unio

de uma consulta de todos os clientes e o nome de todas as agncias. A
informao apresentada em uma nica coluna, pois as informaes de nome
de cliente e nome da agncia so compatveis (tipo de dados igual, neste caso
texto).

Figura 59 Exemplo da aplicao de Unio

Diferena
O operador diferena retorna as tuplas de uma relao 1 cujos valores
dos atributos no esto presentes em uma relao 2. Sua notao :

A figura 60 apresenta um exemplo da aplicao do operador diferente

mostrando como resposta o nome das agncias da tabela de Agncia que no
so relacionadas na tabela de Contas.

77

Banco de Dados I

Figura 60 Exemplo da aplicao de Unio

Juno
A juno a combinao dos operadores de produto cartesiano e
seleo (retorna as tuplas de um produto cartesiano que satisfazem uma dada
condio, onde a condio um predicado). Sua notao :

O exemplo apresentado na figura 61 lista os dados das tabelas de

Contas e Agncia, que atendam a condio de o nome da agncia da tabela de
Contas ser o mesmo que o campo de nome de agncia da tabela de Agncia

Figura 61 Exemplo da aplicao de Juno

A juno muito semelhante ao produto cartesiano, a diferena que

a juno necessita de uma relao, enquanto o produto cartesiano no.

Recapitulando
Ao trmino deste captulo, o aluno compreendeu a ltima etapa do
processo de banco de dados a qual define de forma fsica o banco. Tambm
entendeu o quanto a normalizao de dados importante para garantir a
integridade dos dados armazenados.
Para isto, necessrio aplicar, caso necessrio, as trs formas normais
em cada entidade o que poder resultar na criao de outras entidades
relacionando-as com as entidades de origem.
Por fim, foi feito um estudo sobre lgebra relacional que utilizada
como base por muitas linguagens DML relacionais como SQL. Neste estudo
foram abordados os operadores de seleo, projeo, produto cartesiano,
unio diferena e juno.

78

Banco de Dados I

Atividades
Assinalar (V) para as assertivas Verdadeiras e (F) para as Falsas
1)

V
( )

F
( )

2)

( )

( )

3)

( )

( )

4)

( )

( )

Assertiva
No modelo fsico definimos a estrutura de banco de dados tendo
como base o modelo conceitual.
Somente poder ocorrer a aplicao da segunda forma normal se
a tabela possuir uma chave primria composta e um outro
atributo que dependa apenas de um campo da chave primria
composta.
Em alguns casos quando aplicado a normalizao poder ocorrer
uma diminuio do nmero de tabelas de um diagrama relacional
O produto cartesiano retornar as tups de uma relao 1 cujos
valores aparecem na relao 2

5) Tendo como base o conjunto de elementos apresentado na figura que

segue, marque a alternativa que representa a aplicao de lgebra relacional
para a consulta: liste o nome da cidade de todas as agncias que possuam
relao com contas

a)

( )

b)

( )

c)

( )

d)

( )

e)

( )

Gabarito:
Questo 1 F (na verdade o modelo base do modelo fsico o modelo lgico)
Questo 2 V
Questo 3 F (nunca aps a aplicao de normalizao reremos uma reduo
na quantidade de entidades)
Questo 4 F (um produto cartesiano combina os elementos de duas relaes)
Questo 5 C

79

Banco de Dados I

Introduo a SQL
Christiano Cadon

Introduo
Neste captulo ser abordado algumas consideraes sobre o modelo
fsico, as quais so importantes para a correta aplicao de comandos SQL.
Tambm sero abordados conceitos sobre a linguagem de consulta estruturada
SQL, alm dos principais comandos para criao de manuteno de tabelas.
Ao trmino deste captulo, o aluno ter conhecimento necessrio para
construir tabelas e relaes entre tabelas utilizando a linguagem SQL.

Consideraes sobre Modelo Fsico

Como j constatado, o processo de criao de banco de dados, passa
pelas etapas de modelagem conceitual, transformao do modelo conceitual
para o modelo lgico e por fim a implementao para o modelo fsico.
Muitos profissionais no seguem este processo, ignoram a etapa de
modelagem conceitual e partem diretamente para o modelo lgico. Esta ao
no inviabiliza o desenvolvimento de um sistema, porm indicada para
profissionais que tenham experincia significativa na implementao de banco
de dados, pois muitas premissas podem no ser identificadas e posteriormente
tornar o processo de implementao mais demorado, ou at mesmo
invalidado. As principais ferramentas disponibilizadas pelos fabricantes dos
SGBD implementam apenas digramas lgicos e no conceituais. O principal
fator para que isto ocorra est relacionado ao fato destas j aplicarem os
tipos de dados suportados pelo seu banco de dados e no de seu concorrente.
Inquestionavelmente, iniciar um projeto no modelo fsico
extremamente desaconselhvel, pois o desenvolvedor ter uma grande
probabilidade de desenvolver algo errado ou perder um tempo significativo
analisando o banco para gerao de um relatrio por exemplo. E este cenrio
piora na medida em que exista mais de um desenvolvedor ou um
desenvolvedor tenha que ser substitudo no meio do projeto. Inevitavelmente
o custo do projeto ser elevado. Um bom diagrama o projeto (documento)
indispensvel de um administrador de banco de dados.
Somente de posse do diagrama (planta do nosso sistema de banco de
dados), partimos para o processo codificao do banco de dados, atividade
esta que faz parte do modelo fsico.

80

Banco de Dados I

A primeira tarefa a ser executada na transformao do modelo lgico

para o modelo fsico a de identificar os tipos de dados que o SGBD no qual
selecionamos como sendo o banco de dados de nosso projeto suporta. Neste
material iremos trabalhar com o SGBD Oracle, que considerado um dos
melhores SGBD suportando muitas das funcionalidades que iremos trabalhar
na linguagem SLQ. Independentemente do banco de dados, a grande parte dos
conceitos que sero apresentados utilizando o banco de dados Oracle, podem
ser aplicados nos demais SGDB como Mysql, SQLServer, BD2, Firebird entre
outros.
O Oracle possui uma srie de tipos de dados em seu dicionrio de
dados. Como o objetivo deste material tratar de forma mais generalizada
possvel as atividades por ela proposta, sero utilizados os tipos de dados mais
comuns. A tabela 1 apresenta os tipos que serviro de base para nossas
atividades.
Tabela 1 Tipos de dados que sero utilizados

Tipo de dado
integer
number(presio,escala)

Date

Descrio
Armazena nmeros inteiros. Exemplo:

idade integer
Armazena nmeros reais. Neste tipo de
dados possvel que seja definido a
preciso e a escada do nmero. Exemplo:

salario number(15,2), onde a

preciso
so
15
dgitos
representativos antes da vrgula e 2
usados
como
escala(nmeros
representativos aps a vrgula)
Armazena
datas.
O
formato
do
armazenamento do tipo de dados data
depende da
configurao
de
cada
instalao Oracle. Por padro, quando o
Oracle instalado ele utiliza o mesmo
formato configurado de tipo de data do seu
computador. Nos exemplos em que
trataremos neste material o tipo data ter
o formato dia/ms/ano. Exemplo

datanascimento date
Obs: cada banco de dados representa o tipo
data de forma diferente, por exemplo, o
Mysql possui como formato padro de data
ano-ms-dia.

81

Banco de Dados I

Tipo de dado
varchar(tamanho)
e
varchar2(tamanho)

Descrio
Armazena dados alfanumricos, onde
tamanho define a quantidade mxima de
caracteres que pode ser armazenada no
campo especificado por este tipo de dados.
O tipo varchar2 tem como principal
caracterstica
armazenar
apenas
a
quantidade especfica de bytes que seu
contedo necessita para ser armazenado.
Por exemplo, quando definimos que o
mximo a ser armazenado 30 (nome
varchar2(30)), o mximo que o atributo
nome poder armazenar so 30 caracteres,
porm se for informado no campo nome
Ana, somente sero alocados 3 bytes,
diferentemente do tipo de dado varchar,
que ao definir seu tamanho mximo como
sendo 30 caracteres (varchar(30)), e
informar no campo nome Ana, o SGBD,
aloca 30 bytes mesmo este possuindo
apenas 3. Exemplo:

nome varchar(30)

endereco varcahr2(40)

SQL (Structured Query Language)

O SQL que em portugus significa linguagem de consulta estruturada,
surgiu em 1974 e foi desenvolvida nos laboratrios da IBM e teve com base um
artigo de 1970 escrito por Edgar Frank Codd. No decorrer do tempo muitas
linguagens foram criadas, mas o SQL tornou-se a mais popular. Em 1986 o
American National Standard Institute(ANSI) definiu um padro para o SQL o
que possibilitou que esta linguagem pudesse ser aplicada dentro de aplicativos
independente do SGBD que se esteja conectado.
A linguagem SQL implementa quatro operaes bsicas de manipulao
de registros em Banco de que Dados: criao, leitura, alterao e excluso de
dados, convencionalmente conhecidos como CRUD (Create, Read, Update e
Delete"). O SQL tambm implementa comandos de criao de banco, tabelas e
alterao na estrutura destas tabelas.
Neste captulo ser abordado a criao e manipulao de tabelas e
relaes utilizando a sintaxe do banco de dados Oracle. A sintaxe destes
comandos pode variar de um banco para o outro, mas o objetivo de cada
comando o mesmo.

82

Banco de Dados I

Tendo como base o modelo lgico apresentado na figura 62,

observamos a existncia de duas entidades, funcionrio e departamento,
relacionadas atravs do campo de cdigo de departamento (codigoDep).

Figura 62 Exemplo base de tabelas relacionadas

Cada uma das tabelas deve ser criada com suas respectivas chaves
primrias, alm da definio da relao existente. Como forma de
exemplificao, ser tratada cada uma das atividades de forma separada, e
no final deste captulo, sero apresentados exemplos de criao de entidades,
j especificando todas as relaes existentes em um nico comando SQL.
Comando para criar tabela
O comando Create Table deve ser utilizado quanto necessrio criar
uma nova tabela. Sua sintaxe composta por:

Onde:

Nome da tabela: representa o nome dado a entidade;

Atributo: identifica o nome do atributo a ser criado;
Tipo de atributo: define qual ser o tipo de informao a ser
armazenada em cada um dos atributos;
Definies do atributo: so parmetros que podem ser
atribudos a cada atributo, como por exemplo, se este
obrigatrio ou no (NOT NULL), de este armazena um valor nico
em seu registro (UNIQUE), valores padres (DEFAULT) ou at
mesmo restries como chaves primrias, estrangeiras alm de
validaes (CHECK).

Com base na sintaxe definida, segue a implementao das entidades

existentes na figura 62 (funcionrio e departamento) utilizando a sintaxe SQL
nos exemplos 5 e 6:

83

Banco de Dados I

Exemplo 5: - Criao da tabela departamento

create table departamento (
codDep integer not null,
nomeDep varchar2(20) UNIQUE
);

Exemplo 6: - Criao da tabela funcionario

create table funcionario (
codFunc integer not null,
nomeFunc varchar2(20) not null,
dtNascFunc date,
salarioFunc number(15,2) default 0,
numFilhosfunc integer default 0,
codDep integer not null
)

Obs:. Sempre que for criado um atributo de chave estrangeira, o seu

tipo dever ser o mesmo da chave primria que ele referencia. Neste caso,
observe o atributo chamado codDep da tabela funcionrio. Este atributo do
tipo integer, pois o campo codDep da tabela departamento do tipo integer.
importante destacar que os atributos que sero definidos como
chaves primrias devem ser definidos como NOT NULL, ou seja, so atributos
obrigatrios, no permitindo que seja informado um neste atributo um valor
vazio. Nesta transformao, alm das chaves primrias, o campo de nome de
funcionrio tambm foi definido como sendo um campo obrigatrio. O
atributo coddep da tabela de funcionrio ser um atributo de chave
estrangeira. Isto reflexo da obrigatoriedade identificada no diagrama da
figura 62, onde a cardinalidade mnima 1. importante ressaltar que um
atributo de chave estrangeira no possui como caracterstica a
obrigatoriedade em sua implementao. Isto depende da cardinalidade
mnima da relao existente com a entidade na qual ele referencia.
Tambm pode ser identificado a existncia da definio de atributo
DEFAULT como sendo 0(zero) nos atributos de salarioFunc e numFilhosFunc da
tabela de funcionrio. Neste caso, se for inserido ou alterado um registro na
tabela de funcionrio e o contedo destes campos seja vazio, o SGDB definir
estes como sendo 0 (zero), ou seja definiu um valor padro para os dados caso
no seja informado uma informao.
Adicionando mais um atributo a tabela existente
Todas as vezes que necessrio alterar alguma informao da estrutura
de uma tabela, deve ser executado o comando ALTER TABLE. Caso ocorra a
necessidade de adicionar mais um atributo a tabela, utilizamos a clausula ADD

84

Banco de Dados I

junto o comando ALTER TABLE. A sintaxe do comando para adicionar um novo

atributo a tabela :

Por exemplo, se quisssemos adicionar mais um campo a tabela de

funcionrio chamado de email do tipo varchar2(50) o comando seria:
Exemplo 7: - Adicionando um novo atributo a uma tabela j existente
alter table funcionario
add email varchar2(50);

Alterando o nome de um atributo j existente

A sintaxe do comando para alterar o nome de um atributo j existente
:

Por exemplo, vamos imaginar que o atributo email tenha sido criado
com o nome errado e o correto seria emailFunc. Para isto executaramos o
exemplo 8 que segue.
Exemplo 8: - Alterando o nome de um atributo de uma tabela
alter table funcionario
rename column email to emailFunc;

Alterando o tipo de dado de um atributo j existente

Para alterar um tipo de dado de um atributo j existente utiliza-se a
seguinte sintaxe:

Como forma de exemplificar uma alterao de tipo de dado, vamos

imaginar que o tamanho do campo emailFunc deva ser alterado para
varchar2(100) ao invs de 50. O exemplo 9 apresenta a soluo para esta
alterao.
Exemplo 9: - Alterando o tipo de dado de um atributo j criado
alter table funcionario
modify emailFunc varchar2(100);

85

Banco de Dados I

Obs.: No caso de alterao de tipo de dado, o banco de dados

somente ir permitir a alterao do tipo de um atributo, se o novo
atributo suportar os dados do antigo atributo. Por exemplo, caso seja
necessrio a alterao de dados do campo numFilhosFunc que integer para
number(10,2), o banco ir aceitar o comando. Porm se executado uma linha
de comando que tente alterar o campo salariofunc do tipo number(15,2) para
o tipo date, o banco no conseguir executar este comando. Isto tambm
pode ser identificado em atributos do tipo VARCHAR, quando necessrio
alterar o tamanho do campo. Caso queira aumentar o tamanho de um campo,
no haver problema algum, mas se for necessrio diminuir o tamanho do
campo e exista um contedo armazenado no campo que possua uma
quantidade inferior de dados que o novo tamanho definido pelo VARCHAR, o
banco no permitir a alterao.
Removendo um atributo de uma tabela
Caso queira remover um atributo de uma tabela basta executar a
sintaxe que segue:

O exemplo que segue apresenta a sintaxe para remoo do atributo

emailFunc.
Exemplo: - Removendo um atributo de uma tabela
alter table funcionario
drop column emailFunc;

Criando Chave Primria

Por definio, toda tabela possui um atributo que o identifique de
maneira nica entre os demais registros do banco. Este atributo deve ser
definido como sendo o atributo chave, ou como definimos em banco de dados,
chave primria de uma entidade. Assim toda entidade deve possuir uma chave
primria. A chave primria pode ser definida na criao da tabela atravs do
comando CREATE TABLE, ou aps a tabela j ter sido criada atravs de ALTER
TABLE. A sintaxe para criao de uma chave primria depois de criada uma
tabela :

86

Banco de Dados I

Onde:

nome_da_constraint: um identificador definido pelo usurio e

serve para ter maior controle sobre as operaes de banco de
dados.Neste caso, para definir o identificador no banco de dados
que faz referencia a chave primria. Atravs desta constraint,
por exemplo, possvel remover uma chave primria de uma
tabela.
atributo_chave_primria: o atributo da entidade que ser
definido como sendo chave primria. Em caso de chave primria
composta, devem ser informados os atributos separados por
vrgula.

No exemplo da figura 62 existem 2 atributos de chave primria, o

primeiro chamado codDep da tabela de departamento e o segundo codFunc da
tabela de funcionrio. Os exemplos 10 e 11 demonstram a definio das
chaves primrias utilizando o comando ALTER TABLE.
Exemplo 10: - Criando chaves primrias atravs de ALTER TABLE
alter table departamento add constraint departamento_pk primary key(codDep);
alter table funcionario add constraint tbfuncionario_pk primary key(codfunc);

Obs.: Lembre-se que os atributos que so definidos como chaves

primrias no devem suportar contedos vazios. Desta forma devem ser
definidos como NOT NULL. Isto pode ser observado nos exemplos 5 e 6.
Os exemplos 11 14 apresentam alternativas de definio de chave
primria no comando CREATE TABLE.
Exemplo 11: - Criando chave primria atravs de CREATE TABLE
create table cidade(
codcid integer not null,
nomecid varchar(30) not null,
uf varchar(2),
primary key(codcid)
);

Exemplo 12: - Criando chave primria atravs de CREATE TABLE

create table cidade(
codcid integer not null,
nomecid varchar(30) not null,
uf varchar(2),
constraint cidade_pk primary key(codcid)
);

87

Banco de Dados I

Exemplo 13: - Criando chave primria atravs de CREATE TABLE

create table cidade(
codcid integer not null,
nomecid varchar(30) not null,
uf varchar(2)
);
alter table cidade add constraint cidade_pk primary key (codcid);

Exemplo 14: - Criando chave primria atravs de CREATE TABLE

create table cidade(
codcid integer not null constraint cidade_pk primary key,
nomecid varchar(30) not null,
uf varchar(2)
);

Observe que no exemplo 11 a constraint no foi definida, porm a

chave primria foi criada. Na criao de chaves primrias dentro do comando
CREATE TABLE, no existe obrigatoriedade da definio do nome da constrait,
porm as boas prticas sugerem o uso de um nome.
Criando Chave Estrangeira
As chaves estrangeiras so atributos criados para definir de forma fsica
uma relao entre duas entidades. O contedo de uma chave estrangeira deve
ser identificado (existir) no atributo da chave primria que o atributo
referencia. Da mesma forma que a criao da chave primria, a chave
estrangeira pode ser definida tanto na criao da tabela, ou posterior
criao da mesma. A sintaxe para criao de uma chave estrangeira em uma
tabela j criada utilizando ALTER TABLE :

Onde:

nome_da_constraint: um identificador que deve ser definido

pelo usurio como forma de identificar a constraint, neste caso
a chave estrangeira;
atributo_chave_estrangeira: o atributo criado como chave
estrangeira da relao;
tabela_referenciada>(<atributo_chave_primria_referenciado>):
deve ser informada a tabela e o atributo de chave primria na
qual a chave estrangeira far referncia.

No exemplo apresentado na figura 62 existe o atributo codDep da

tabela de funcionrio fazendo referencia ao atributo codDep da tabela de

88

Banco de Dados I

Departamento. O exemplo 15 apresenta a soluo atravs do comando ALTER

TABLE para criao da chave estrangeira.
Exemplo 15: - Criando Chave estrangeira em uma tabela j existente
alter table funcionario add constraint funcionario_codDepFK foreign key(codDep)
references departamento(codDep);

Obs.: A definio de uma chave estrangeira somente ocorrer se a

chave primria da tabela em que a chave estrangeira fizer referencia j
tenha sido criada.
O exemplo 16 apresenta a definio da chave estrangeira na criao da
tabela de funcionrio. Observe que neste exemplo ambas as chaves esto
sendo definidas na criao da tabela. Neste caso, o comando somente ser
executado se a tabela departamento j tenha sido criada, juntamente com a
sua chave primria codDep.
Exemplo 16: - Criando Chave estrangeira no comando CREATE TABLE
create table funcionario (
codFunc integer not null,
nomeFunc varchar2(20) not null,
dtNascFunc date,
salarioFunc number(15,2) default 0,
numFilhosfunc integer default 0,
codDep integer not null,
constraint tbfuncionario_pk primary key(codfunc),
constraint
funcionario_codDepFK
foreign
departamento(codDep)
)

key(codDep)

references

Comandos teis para trabalhar com estrutura de tabelas

Como forma de auxiliar o usurio a encontrar informaes sobre a
estrutura das tabelas, a tabela 2 apresenta alguns comandos teis ao
administrador de banco de dados relacionados a estrutura de tabelas.
Tabela 2 Comandos teis para o administrador de banco

Descrio
Lista as Meta-informaes
sobre uma tabela
Listar as tabelas criadas
por um usurio
Listar as restries criadas
por um usurio

Comando
DESCRIBE nome_da_tabela
ou
DESC nome_da_tabela
SELECT * FROM USER_TABLES
SELECT * FROM USER_CONSTRAINTS

Apagar uma constraint

ALTER TABLE nome_da_tabela DROP CONSTRAINT

nome_da_constraint

Apagar uma tabela

DROP TABLE nome_da_tabela

89

Banco de Dados I

Recapitulando
Ao concluir este captulo, foi possvel compreender que iniciar um
projeto j codificando banco de dados no a melhor alternativa de
desenvolvimento de banco, e poder ocasionar um significativo aumento de
custo do projeto.
Tambm foi abordada, a necessidade de conhecer os tipos de dados
que um banco de dados selecionado para um determinado projeto. O tipo de
dados indispensvel para correta implementao do modelo fsico.
Com base em alguns comandos da linguagem SQL foi possvel conhecer
como possvel criar uma tabelas, alterar o nome e tipo de atributo, alm de
entender a forma de como se adiciona e remove atributos de uma tabela.
Utilizando os comandos SQL, foi possvel definir as chaves primrias e
estrangeiras, determinando uma relao fsica entre as tabelas criadas. Por
fim foi apresentado uma relao de alguns comandos teis para a
manipulao da estrutura de tabelas.

Atividades
Assinalar (V) para as assertivas Verdadeiras e (F) para as Falsas
V

1)

( )

( )

2)

( )

( )

3)

( )

( )

4)

( )

( )

Assertiva
Para a correta implementao do modelo fsico necessrio que
exista um diagrama lgico definido
O SQL obteve um padro pela ISO em 1986, onde a partir da se
tornou-se popular e utilizado at hoje.
possvel criar uma chave primria ou estrangeira no prprio
comando CREATE TABLE
S possvel criar uma chave estrangeira se a chave primria a
qual a chave estrangeira estiver referenciando j estiver sido
criada

2) Tendo como base o diagrama lgico que segue, e sabendo que a tabela de
raa juntamente com a sua chave primria j esteja definida, marque a
alternativa que no poder ser executada.

a)

( )

CREATE TABLE aminal (

codAni integer not null,
nomeAni varchar(20) not null,
dtnascAni date not null
);
alter table aminal add codRaca integer not null;

90

Banco de Dados I

b)

( )

c)

( )

d)

( )

e)

( )

CREATE TABLE aminal (

codAni integer not null,
nomeAni varchar(5) not null,
dtnascAni date not null,
codRaca integer not null
);
alter table aminal modify codRaca varchar(20) not null;
CREATE TABLE aminal (
codAni integer not null,
nomeAni varchar(20) not null,
dtnascAni date not null,
codRaca integer not null
)
CREATE TABLE aminal (
codAni integer not null PRIMARY KEY,
nomeAni varchar(20) not null,
dtnascAni date not null,
codRaca integer not null,
constraint codRacaFK foreign key(codRaca) references raca(codRaca)
)
alter table raca drop nomeRaca varchar(20);

Gabarito:
Questo 1 V
Questo 2 F
Questo 3 V
Questo 4 V
Questo 5 E (comando mal aplicado, falta clausula column e no
necessrio colocar o tipo de dado do atributo a ser
removido)

91

Banco de Dados I

Operaes CRUD
Christiano Cadon

Introduo
Este captulo abordar atravs de exemplos a utilizao dos comandos
de seleo, insero, alterao e remoo de dados os quais compem as
quatro operaes bsicas de banco de dados pelas aplicaes desenvolvidas.
Aps a concluso deste captulo o aluno ter
operacionalizar as tabelas de um sistema de banco de dados.

condies de

Operaes com dados de uma tabela

Quem desenvolve aplicativos, geralmente encontra muitos artigos de
acesso e manipulao de registros relacionados com o termo CRUD.
CRUD, um termo utilizado (convencionado) para designar as quatro
operaes bsicas em Banco de Dados, criao, leitura, alterao e excluso
de dados(Create, Read, Update e Delete"). A linguagem SQL possui as quatro
operaes com os comandos INSERT, SELECT, UPDATE e DELETE.
A definio do padro em SQL proporcionou que estes operadores
possam ser aplicados independentemente do SGBD selecionado. Desta forma,
a sintaxe que ser trabalhada nos comandos de insero, seleo, alterao e
excluso a mesma para qualquer banco de dados. A nica variao est
relacionada a utilizao de funes na operao de seleo, que depende de
cada SGBD. Em geral todos os SGBD possuem funes para realizao de uma
determinada ao, porm o nome ou os parmetros destas podem variar de
acordo com o banco de dados. Como j acordado no captulo anterior, ser
utilizado o SGBD ORACLE e por consequncia a sintaxe de suas funes.
Como forma de apresentar conceitos e exemplos relacionados aos
comandos que sero apresentados no decorrer deste captulo, ser utilizado o
diagrama lgico da figura 62 j trabalhado no captulo anterior.

Inserindo dados em uma tabela

A operao de insero responsvel por popular s tabelas. Sua
sintaxe :

92

Banco de Dados I

Os exemplos 16 e 17 apresentam a execuo do comando INSERT na

tabela de departamento e na tabela de funcionrio.
Exemplo 16: - Inserindo um novo registro na tabela de departamento
insert into departamento(coddep,nomedep) values (1, 'Comercial');

Exemplo 17: - Inserindo um novo registro na tabela funcionario

insert into funcionario(codfunc, nomefunc, dtnascfunc, salariofunc, numfilhosfunc,
coddep) values(50, 'Ana Maria', '20/03/1995', 1234.32, 2, 1)

Obs:. Para cada tipo de dado, existe uma representao de valor. Por
exemplo, dados do tipo integer devem ser informados somente atravs de
nmeros. o caso do valor dado ao codDep(1), codFunc(50) e do campo
numFilhosDep(2). Tipo de dados VARCHAR, deve ser informado colocando
seu contedo dentro de apstrofo ('), como o caso dos campos
nomeDep('Comercial') e nomeFunc('Ana Maria'). J atributos do tipo DATE
deve ser informado entre apstrofo (') com formatao de acordo como o seu
SGBD est configurado. No exemplo 17 percebemos que a data est formatada
em 'dia/ms/ano', e por isso no campo dtNascFunc o valor foi informado
como ('20/03/1995'). Os dados do tipo number, devem possuir como
separador decimal um ponto ao invs da vrgula que estamos acostumados. No
exemplo 17 campo salarioFunc possui como valor 1234.32 (um mil duzentos
e trinta e quatro reais com trinta e dois centavos).
Observe tambm que o valor contido no campo codDep do exemplo 17,
j estava cadastrado na tabela de departamento (exemplo 16). Se o banco de
dados estivesse vazio e os nicos comandos utilizados fossem os 16 e 17, no
seria possvel cadastrar um novo funcionrio com um cdigo de departamento
diferente de 1, pois somente existe este registro cadastrado na tabela e
departamento.
A ordem em que os atributos aparecem no comando INSERT influencia
na ordem como os valores sero informados. O exemplo 18 apresenta a
insero de um novo departamento com a ordem de seus campos alterada.
Exemplo 18: - Inserindo um novo registro com atributos fora da ordem original
insert into departamento(nomedep ,coddep) values ('Financeiro',2);

Vamos imaginar que as tabelas departamento e funcionrio j tenham

cido criadas, e o SQL utilizado para criao da tabela de funcionrio foi o do
exemplo 16 apresentado no captulo anterior. No exemplo 16, existem
atributos no obrigatrios e outros obrigatrios. Partindo desta premissa, o
exemplo 19 apresenta uma situao de insero na tabela de funcionrio
interessante. Nesta, no est sendo informado o campo de salarioFunc e nem
o campo numFilhosFunc. Isto possvel, pois na definio da criao da tabela

93

Banco de Dados I

(CREATE TABLE), os campos no eram obrigatrios (no havia clausula NOT

NULL). Desta forma, dizemos que acabamos de cadastrar um funcionrio sem
informar o seu salrio e nmero de filhos.
Exemplo 19: - Inserindo novo registro sem alguns atributos da tabela.
insert into funcionario(codfunc, nomefunc, dtnascfunc, coddep) values(52, 'Carla',
'17/05/1990', 1);

O comando INSERT tambm possibilita que seja realizado a insero de

dados tendo como base dados armazenados em outras tabelas. O exemplo que
segue, realiza a insero de dados na tabela de departamento buscando dados
em uma tabela de categoria. Neste caso, vamos imaginar que a tabela de
categia existisse e que esta estivesse populada. Vamos imaginar que a
consulta realizada pelo comando SELECT na tabela de categoria retornasse 10
registros, ambos os 10 seriam inseridos na tabela de departamento. Neste
caso, torna-se importante destacar que os tipos de campo devem coincidir.
Exemplo 20: - Exemplo de INSERT com SELECT
insert into departamento(coddep,nomedep)(
select codcategoria, nomecategoaria from categoria where codcategoria>3)

Selecionando dados de uma tabela

O comando de seleo de dados o comando mais utilizado do SQL.
Este possui uma srie de parmetros em sua sintaxe. Como forma de
exemplificar, neste tpico somente sero destacados os parametros que sero
utilizados neste captulo. Neste captulo somente ser utilizada a consulta
sobre uma nica tabela. Seleco de dados com mais de uma tabela envolvida
ser aborado no prximo captulo deste material.
Sintaxe bsica do comando SELECT:

Onde clausulas entre conchetes [ ] somente so utilizadas caso ocorra

necessidade.
Como forma de exemplificar a utilizao do comando de seleo, a
figura 63 apresenta uma tabela populada com um conjunto de informaes de
clientes quaisquer, a qual ser utilizada como base para execuo do
comando de seleo.

94

Banco de Dados I

Figura 63 Exemplo base para exerccios de seleo

Quando necessitamos mostrar todos os atributos de repostas utilizamos

o * (arterisco) para representar o retorno de todos os atributos. A figura 64
apresenta um exemplo e o resultado ca consulta realizada utilizando o
asterisco para retorno dos campos. Neste exemplo estamos listando todos os
dados de todos registros da tabela de Cliente.

Figura 64 Exemplo se seleo utilizando *

Porm quando necessitamos que a resposta seja apenas atributos

especficos adicionamos entre as clausulas select e from o nome dos atributos.
A figura 65 apresenta 3 formas diferentes de listar o somente o nome e salrio
de todos os clientes:

Figura 65 Exemplos selecionando apenas algumas colunas de uma tabela

95

Banco de Dados I

Ambas as solues para pesquisa apresentadas na figura 65 retornam a

mesma resposta. No exemplo a, apenas foram colocados os campos nomeCli
e o campo salarioCli. No exemplo b, foi adicionando antes do nome do
campo o nome da tabela que possui o campo, neste caso tbcliente. Isto
necessrio quando a consulta envolve mais de uma tabela, pois assim
identificamos de qual tabela queremos a respostas. J o exemplo c, possui
a mesma finalidade do que o exemplo b, a nica variao que neste
exemplo ao invs de colocarmos o nome da tabela antes de cada atributo de
reposta, definimos um apelido para a tabela que deve ser colocado aps o
nome da mesma. Este apelido poder ser utilizado como se fosse a tabela
referenciada. No exemplo, o apelido da tabela tbcliente ficou definido
como cl.
Nos exemplos das figuras 65 o nome das colunas de retorno so os
mesmos especificados em sua pesquisa neste caso nomeCli e salarioCli.
Caso ocorra a necessidade de alterar apenas o nome destas colunas no
momento de apresentar a resposta, basta adicionar aps o nome da coluna a
clausula AS seguida no nome da nova coluna. A figura 66 apresenta um
exemplo de implementao da clausula AS.

Figura 66 Definindo nome as colunas de retorno

Observe que no exemplo apresentado na figura 66, caso seja necessrio

colocar uma palavra composta como o caso de Sexo do cliente, esta
dever aparecer entres aspas duplas.
Alm de retornar os dados de uma coluna na sintaxe do SQL possvel
criar uma nova coluna de resposta utilizando ou no dados de colunas j
existentes. O exemplo da figura 67 lista o nome do cliente, seu salrio e seu
salrio acrescido de R$ 150.34 de todos os clientes cadastrados. O SQL
suporta as quatro operaes matemticas(soma, subtrao, diviso e
multiplicao) as quais podem ser aplicadas a qualquer atributo numrico. O
uso de parnteses para realizar expresses tambm permitido.

96

Banco de Dados I

Figura 67 Criando nova coluna de reposta

Outro recurso interessante do SQL a possibilidade de ordenar a

resposta por uma determinada coluna. Para isto utiliza-se a clausula ORDER
BY seguida do nome das colunas que se desejada ordenar. Caso seja
necessrio ordenar em ordem decrescente, basta utilizar aps o nome do
campo ordenado a clausula DESC. Os exemplos 21 23 mostram formas
diferentes de realizar a operao de ordenao.
Exemplo 21: - Lista todos os dados de todos os clientes em ordem de nome
de cliente
select * from tbcliente c order by nomecli;

Exemplo 22: - Lista todos os dados de todos os clientes em ordem de nome

de cdigo de cidade e em seguida em ordem de salrio
select * from tbcliente c order by c.sexoCli,c.salariocli;

Exemplo 23: - Lista todos os dados de todos os clientes em ordem

DECRESCENTE de nome de cliente
select * from tbcliente c order by c.nomecli DESC;

Um dos principais usos do comando de seleo est relacionado a busca

por uma informao especfica. Para isto utiliza-se a clausula WHERE seguida
de uma expresso condicional contendo um operador relacional. O SQL
suporta diversos operadores relacionais. A tabela 3 apresenta os operadores
relacionais do SQL
Tabela 3 Operadores Relacionais
Operador
=
>
<
>=
<=
<> ou !=

Descrio
Igual
Maior do que
Menor do que
Maior ou igual
Menor ou igual
Deferente de

Exemplo
358.50=358.50
584>352
584>352
125>=854
125<=854
125<>854

Resultado
Verdadeiro
Verdadeiro
Falso
Falso
Verdadeiro
Verdadeiro

A figura 68 apresenta dois exemplos da aplicao dos operadores

relacionais nos tipos de dados numricos e de data. Observe que da mesma

97

Banco de Dados I

forma que no comando INSERT cada tipo de dado deve possuir uma forma de
representa-lo em uma condio.

Figura 68 Exemplos de operadores relacionais

Antes de selecionar um atributo do tipo texto necessrio saber se

este banco de dados sensitive, ou seja, diferencia letras maisculas da
minsculas. Esta informao indispensvel, pois uma pesquisa pode ser
prejudicada caso no saibamos desta informao. Por exemplo, tendo como
base que o cliente Bozo da Silva esteja armazenado no banco de dados, e
em uma consulta SQL foi informado como parmetro bozo da silva, a
consulta no retornaria nada, pois as palavras no coincidem, tendo em vista
que o SGBD diferencia letras maisculas e minsculas. Neste caso, podemos
utilizar a funo SQL UPPER que possibilita a converso do contedo de seu
parmetro todo para maisculo.
Os dois exemplos apresentados nafigura 69, ilustram a aplicao da
funo upper.

Figura 69 Exemplos da funo UPPER

98

Banco de Dados I

Para dados do tipo texto o SQL tambm possui um operador lgico

chamado LIKE que retorna verdadeiro se uma cadeia de caracteres especfica
corresponde a um padro. Um padro pode incluir caracteres normais ou
curinga representado pelo carcter % (porcento). Este operador possibilita
consultas como por exemplo, listar todos os clientes que iniciam com a letra
b. A figura 70 ilustra 3 exemplos de busca utilizando o operador LIKE.

Figura 70 Exemplos do operador LIKE

O comando de seleo tambm possui uma srie de outras operaes

como a utilizao de operadores lgicos, funes de agrupamento alm da
utilizao de mais de uma tabela na busca de dados. Estes itens sero
apresentados no prximo captulo deste documento.

Alterando dados de uma tabela

normal que ocorra a necessidade de alterar o contedo j
armazenado de um registro. Para realizar este procedimento utilizamos o
comando UPDATE. Sua sintaxe :

O exemplo 23 apresenta o comando UPDATE para alterar o nome do

cliente para Maria Joaquina, a data de nascimento para 25/08/1998, e
seu salrio acrescido de mais R$ 200,00, o cliente de cdigo igual a 1. Observe

99

Banco de Dados I

que no caso da alterao de salrio, a expresso utilizou o antigo salrio

acrescido do valor 200.
Exemplo 24: - Altera os dados do cliente de cdigo 1
update tbcliente set
nomeCli='Maria Joaquina',
datanascCli='25/03/1998',
salarioCli =salarioCli+200
where pkcodcli=1;

A clausula WHERE opcional ao comando UPDATE, mas a ocorrncia de

sua utilizao significativa. Se o usurio no exemplo 24, no tivesse
adicionado uma condio, TODOS os registros da tabela de cliente seriam
alterados com as informaes determinadas pelo exemplo 24, o que traria
sem dvida, um grande problema, pois todos os clientes se chamariam Maria
Joaquina e teriam sua data de nascimento definida para 25/03/1998, alm
de seu salrio ser acrescido com mais R$ 200,00.
Mas o uso de UPDATE sem a clausula WHERE possui suas vantagens.
Vamos imaginar que ocorra a necessidade de aumentar 15% o valor de todos
os salrios dos clientes. Neste caso no haveria necessidade do uso da clausula
WHERE, pois todos os registros deveriam sofrer a mesma alterao. O exemplo
25 apresenta a soluo deste problema.
Exemplo 25: - Altera o salrio para mais 15% de TODOS os clientes
update tbcliente set
salarioCli =salarioCli+( salarioCli *10/100)

Todas as condies aplicadas no comando de seleo podem ser

aplicadas como condio no comando de alterao de dados. Outra
considerao importante sobre o comando de alterao que s possvel de
forma direta selecionar uma nica tabela para realizar a alterao de dados.

Removendo dados de uma tabela

Da mesma forma como ocorre o cadastro e alterao de dados,
comum que o usurio deseja remover um determinado registro. Para realizar
este procedimento utilizamos o comando DELETE. Sua sintaxe :

O exemplo 26 apresenta um exemplo da aplicao do comando DELETE,

onde esto sendo removidos todos os registros de cliente do sexo masculino.
Exemplo 26: - Apaga todos os clientes do sexo masculino
Delete from tbcliente where sexoCli='M'

100

Banco de Dados I

Da mesma forma que no comando UPDATE, a clausula where opcional

no comando DELETE. Agora imagine o estrago que seria a execuo do
comando delete sem a clausula where. Na execuo sem where, todos os
dados da tabela informada sero removidos e a tabela ficar vazia. Sendo
assim, tome muito cuidado na execuo deste comando, e s execute um
DELETE sem where se possuir certeza desta alterao.

Recapitulando
Ao concluir este captulo, o aluno percebeu o quanto valioso a
compreenso das quatro operaes bsicas de banco de dados, criao,
leitura, alterao e excluso de dados. Percebeu que cada tipo de dado possui
um tratamento diferenciado quando selecionado para uma operao, e
compreendeu que o tipo de dado data o tipo de dado que mais varia entre
os SGBD.
Compreendeu as formas de retornar somente as colunas que deseja
visualizar alm de criar colunas como resposta no existentes no banco.
Evidenciou com possvel definir nome de uma coluna na execuo de SQL e
obter a resposta ordenada. Estudou como possvel atravs dos operadores
relacionais criar uma regra de busca especfica. Estudou sobre o conceito de
sensitive de dados do tipo texto, e compreendeu como se obtm uma consulta
de campos do tipo texto, independente da forma como os dados esto
armazenados, podendo com estes realizar consultas com o operador LIKE.
Percebeu o quando a clausula where importante na execuo dos
comandos de alterao e remoo de dados, podendo sem aplicao correta
desta, comprometer definitivamente o contedo de um banco de dados.

Atividades
Assinale (V) para as assertivas Verdadeiras e (F) para as Falsas, tendo como
base a figura que segue

101

Banco de Dados I

1)

V
( )

F
( )

Assertiva
O comando abaixo relacionado lista o nome do cliente, a data de
nascimento e o sexo de todos os clientes do sexo masculino?
select a.nomecli as nome,a.datanasccli , a.sexocli as sexo from
tbcliente a where a.sexocli='M';

2)

( )

( )

O comando abaixo relacionado altera o nome do cliente para

ana, todos os clientes que possuem em seu nome a letra a
update tbcliente set nomecli='Ana' where upper(nomecli) like
upper('%a')

3)

( )

( )

O comando abaixo relacionado insere um novo registro na tabela

de cliente
insert into tbcliente(pkcodCli, nomeCli, endCli, salarioCli, datanascCli,
SexoCli) values (9, 'Jos', 'Rua solido 501', '10/12/1998', 2530.52, 'M');

4)

( )

( )

A execuo do comando que segue, apresenta o resultado

correto?
select c.nomecli,c.salariocli, c.sexocli from tbcliente where
c.salariocli>700 order by c.sexocli,c.nomecli
Resultado

5)

( )

( )

O comando abaixo relacionado lista o nome dos clientes que

nasceram aps o ano de 2000 em ordem decrescente de nome de
cliente
select tbcliente.nomecli from tbcliente where
tbcliente.datanasccli>='01/01/2000' order by tbcliente.nomecli desc

Gabarito:
Questo 1 V
Questo 2 F (faltou colocar um coringa na clausula like o correto seria like
upper('%a%'))
Questo 3 F (A ordem dos campos est errada, primeiro deveria ser
informado o salrio ao invs da data de nascimento a operao
correta seria: insert into tbcliente(pkcodCli, nomeCli, endCli, salarioCli,
datanascCli, SexoCli) values (9, 'Jos', 'Rua solido 501', 2530.52,
'10/12/1998', 'M');)

Questo 4 V
Questo 5 V

102

Banco de Dados I

Critrios de Seleo de Dados

Christiano Cadon

Introduo
Neste captulo ser estudado questes relacionadas a seleo de dados
como a utilizao dos operadores lgicos, funes de agrupamento alm de
estudar subconsultas utilizando o operador IN.
Ao trmino deste captulo o aluno ter conhecimento necessrio para
aplicar as tcnicas trabalhadas e resolver problemas reais de busca de
informao em tabelas.

Outras caractersticas do comando de seleo simples

Como j abordado no captulo anterior, a operao de seleo sem
dvida a mais utilizada entre as quatro operaes bsicas. Alm das
funcionalidades j trabalhadas, o comando de seleo possui outras
funcionalidades indispensveis de se conhecer. No captulo anterior, foi
abordado parte da sintaxe do comando SELECT. Segue uma nova verso da
sintaxe de seleo (mas no a verso final), onde possvel identificar
algumas novidades em sua sintaxe.

Como forma de demonstrar atravs de exemplos os novos parmetros,

ser utilizada a figura 63 que apresenta uma tabela de cliente com exemplos
de dados armazenados. Estes dados serviro como base dos exemplos que
sero apresentados neste captulo.
O SQL disponibiliza operadores lgicos utilizados nos critrios de busca.
Os operadores lgicos mais conhecidos no SQL, podem ser observados na
tabela 4.
Tabela 4 Operadores lgicos
Operador
AND
OR
NOT
IN

Descrio
Retorna verdadeiro se duas expresses booleanas retornarem verdadeiro
Retorna verdadeiro se qualquer expresso booleana retornar verdadeiro
Inverte o valor de qualquer operador booleano
Retorna verdadeiro se o operador for igual a um elemento contido na
lista

103

Banco de Dados I

A figura 71 apresenta trs exemplos da utilizao dos operadores

lgicos AND e OR. Estes so os operadores mais conhecidos e podem ser
utilizados individualmente ou em conjunto. Com eles possvel criar mais de
um critrios de busca, aumentando as possibilidades de pesquisa.

Figura 71 Exemplos dos operadores lgicos AND e OR

O exemplo a apresenta a utilizao do operador AND, j o exemplo

b utiliza o operador OR. No exemplo c, ocorre a utilizao de ambos os
operadores como regra de busca. Observe neste exemplo que para correta
implementao foi necessrio a utilizao de parnteses. Isto foi necessrio
devido a ordem de precedncia dos operadores lgicos. O operador AND
executado sempre com precedncia em relao ao operador OR. Perceba no
exemplo apresentado na figura 72 que ao retirar os parnteses a resposta ser
outra e no atende ao que o enunciado solicita. Neste exemplo o SGBD
interpreta que deve ser listados os clientes cujo cdigo seja 3 com salrio
superior a 730 ou que seu cdigo seja 5

Figura 72 Exemplos de falta de aplicao de parnteses

Os exemplos apresentados na figura 73 ilustram a aplicao do

operador NOT e IN. No exemplo a, a regra negar a expresso
c.sexocli='F', assim ser retornado tudo que no for possuir esta sentena.

104

Banco de Dados I

Figura 73 Exemplos de dos operadores NOT e IN

J no exemplo b, perceba que foi criada uma lista de valores que

sero comparados com o campo pkcodcli. Se algum dos argumentos existir
ser listado como resposta.
Dando prosseguimento, vamos imaginar que necessitssemos listar uma
lista contendo todos os sexos das pessoas cadastradas. Atravs do
conhecimento at aqui apresentado, simplesmente mandaramos selecionar a
coluna sexoCli de todos os clientes. A resposta para esta execuo est na
figura 74.

Figura 74 Selecionando todos os sexos cadastrados

Ao avaliar a resposta, percebemos que existe o sexo M e F, porem

estes aparecem repetitivos. Na verdade uma linha para cada registro da
tabela. Caso tivssemos 10.000 clientes seria listado um conjunto contendo
10.000 M e F. Contudo o objetivo aqui era apresentar somente duas
linhas como resposta. Caso isto seja necessrio podemos utilizar a clausula
DISTINCT antes dos campos que necessitamos retorno. Esta clausula no
permitir apresentar resultados repetitivos. O exemplo 75 apresenta a mesma

105

Banco de Dados I

consulta, porm agora com a clausula DISTINCT definida. Observe que o

retorno de informaes bem mais preciso.

Figura 75 Exemplo do uso de distinct

Uma das grandes funcionalidades do uso de SQL est relacionada a

possibilidade de execuo de funes. Uma funo serve para executar uma
determinada ao sobre um atributo ou conjunto de atributos. Cada SGBD,
possui um conjunto de funes especficas em seu dicionrio de dados. Em
exemplos anteriores j trabalhamos com a funo UPPER. Existe um grupo de
funes chamado funes de agregao que so muito utilizadas em
implementaes. A tabela 5 apresenta as funes de agregao mais
conhecidas.
Tabela 5 Funes de agregao
Funo
SUM(ATRIBUTOS)

Descrio
Realiza uma soma
do contedo dos
atributos
informados como
parmetro

Exemplo
a) Liste a soma de todos os salrios dos
clientes
select sum(c.salariocli) from tbcliente c;

COUNT(ATRIBUTOS)

Retorna a
quantidade de
registros
encontrados na
ocorrncia do
select executado

b) Liste a quantidade de clientes de sexo igual

a F
select count(*) from tbcliente c where
c.sexocli= 'F';

AVG(ATRIBUTOS)

Retorna a mdia
aritmtica do
contedo existente
nos atributos
informados

c) Liste a mdia de salrio dos funcionrios

do sexo F
select avg(c.salariocli)
from tbcliente c
where c.sexocli= 'F';

MAX(ATRIBUTOS)

Retorna o maior
valor contido na
coluna informada
como parmetro

d) Liste a maior data de nascimento

cadastrada na tabela de cliente
select max(c.datanasccli) from tbcliente c;

MIN(ATRIBUTOS)

Retorna o menor
valor contido na
coluna informada
como parmetro

e) Liste a menor data de nascimento

cadastrada na tabela de cliente
select min(c.datanasccli) from tbcliente c;

106

Banco de Dados I

Quando ocorre a necessidade de listar uma funo de agregao

juntamente com um atributo, necessrio agrupar sempre o atributo que no
faz parte da funo, para que a funo de agregao funcione. Por exemplo,
vamos imaginar que seja necessrio listar o sexo dos clientes a quantidade de
clientes e a soma dos salrios dos clientes do respectivo sexo. O campo
sexoCli que no faz parte das funes de agregao count() e sum(), dever
ser agrupado. Para isto utiliza-se a clausula GROUP BY no final do cdigo SQL
antes do comando de ordenao de dados (caso exista).
A figura 76 apresenta a implementao do exemplo citado utilizando a
clausula GROUP BY no campo sexoCli. No exemplo tambm foram definidos
nomes para as colunas criadas atravs das funes de agregao.

Figura 76 Exemplo do uso GROUP BY

comum tambm que o resultado de um SQL esteja condicionado a

uma condio relacionada ao resultado de uma funo. Caso isto ocorra
necessrio a execuo da clausula HAVING. Por exemplo, vamos imaginar que
seja necessrio listar em tela o sexo dos clientes, e a quantidade de clientes
do respectivo sexo cuja quantidade seja superior a 4. Perceba que a
quantidade de clientes faz parte de uma condio. Funes de agregao no
podem ser utilizadas nas condies de uma clausula WHERE por serem funes
especiais. Neste caso, aps a aplicao de uma possvel condio where
utilizamos a clausula HAVING.
A figura 77 apresenta a soluo para o problema apontado, onde
possvel perceber a aplicao da clausula HAVING sobre uma funo de
agregao.

Figura 77 Exemplo do uso HAVING

107

Banco de Dados I

Subconsulta
Este termo utilizado para designar a necessidade de realizar uma
consulta dentro de outra consulta para atender a um determinado critrio.
Imagine que seja necessrio listar todos os dados do cliente que possui o
maior cdigo, ou que seja necessrio listar os dados do cliente mais velho.
Utilizando os conceitos at aqui apresentados, no possvel executar este
tipo de consulta.
Para solucionar este tipo de problema, utilizamos o operador IN. O
operador IN realiza uma condio comparando um atributo ou valor uma
lista de valores. Ocorre que o SQL suporta que a lista existente no operador
IN, seja um resultado de outra consulta SELECT. Desta forma, dizemos que
utilizamos uma subconsulta para resolver o problema.
A figura 78 apresenta dois exemplos da implementao de
subconsultas, onde o primeiro soluciona o problema de listar os dados do
cliente do sexo masculino que possui o maior salrio. O segundo listando os
dados do cliente mais velho que recebe abaixo de R$ 1000,00.

Figura 78 Exemplo do subconsulta em SELECT

O SQL ir primeiramente executar a consulta existente dentro do

operador IN e criar como resposta, uma lista de opes que sero
comparadas com a regra definida no operador IN. No exemplo a, a consulta
interna retornou o salrio R$ 2354,89. Este valor ser a resposta a ser
comparada com a primeira parte do select executado. importante que seja
destacado que a consulta existente no operador IN no poder retornar duas
colunas como resposta. Caso isto ocorra o SGBD retornar um erro no
permitindo a pesquisa. O tipo de dado de retorno do operador IN, dever ser
do mesmo tipo o qual est sendo comparado com o operador IN. No exemplo
b o tipo de retorno ser uma data. Neste caso obrigatoriamente o campo de
comparao do operador IN deve ser um campo do tipo data.

108

Banco de Dados I

O operador IN muito utilizado com operaes UPDATE e DETELE,

principalmente se a soluo de uma alterao ou de uma excluso depender
de informaes contidas em outras tabelas que no seja a tabela que sofrer
alterao ou excluso. Isto porque, estes dois comandos s podem possuir
uma tabela como referencia, ou seja, em um comando de alterao ou
excluso somente dados de uma tabela podero sofrer modificaes. Observe
a figura 79 que possui um conjunto de duas tabelas (funcionrio e cargo)
relacionadas e populadas. O campo de relao entre as duas tabelas
codCargo.

Figura 79 Exemplo de duas tabelas relacionadas e populadas

Agora vamos imaginar que com base do exemplo da figura 79, ocorra a
necessidade de alterar o nome de todos os funcionrios para Fulana que
possuam o cargo Diretoria. Observe que neste caso, a alterao deve ser
feita na tabela funcionrio, porm o critrio de alterao est na tabela de
cargo. Como j mencionado o comando UPDATE no suporta informar mais
do que uma tabela, mas suporta a utilizao do operador IN.
Assim, podemos executar a rotina de UPDATE selecionando uma tabela,
e criar um critrio de busca utilizando o operador IN buscando informaes de
outra tabela. O exemplo 27 apresenta a soluo para este problema.
Exemplo 27: - UPDATE com subconsulta
Update funcionario f set
f.nomeFunc='Fulana'
where f.codCargo in(select d.codCargo from Cargo d where
upper(d.nomecargo)=upper('Diretoria'))

Observe que no exemplo 27 foi utilizado os campos de relao entre as

tabelas de funcionrio e cargo. A consulta do operador IN retorna o cdigo do

109

Banco de Dados I

cargo da tabela de cargo o qual comparado com o cdigo do cargo da tabela

funcionario.
O mesmo ocorre quando necessitamos remover um registro o qual
possui como critrio de remoo, dados de outra tabela. O comando Delete
suporta apenas uma nica tabela mas suporta o operador IN como critrio. Por
exemplo, vamos imaginar que seja necessrio remover todos os funcionrio
cujo cargo possua a letra s em seu nome. Nesta situao, utilizamos o
comando Delete removendo dados da tabela de funcionrio aplicando o
operador IN que buscar dados da tabela de cargo. A consulta existente na
clausula IN, dever retornar o cdigo dos cargos que possuam a letra s em
seu nome. Assim ser retornado uma lista de cdigos que sero utilizados para
remoo dos dados da tabela de funcionrio. O exemplo 28 apresenta a
soluo para este problema.
Exemplo 28: - DELETE com subconsulta
Delete from funcionario f
where f.codCargo in(select d.codCargo from Cargo d where upper(nomecargo)
like upper('%s%'))

O exemplo 29 apresenta uma linha de comando que remove o

funcionrio que possui o maior cdigo. Perceba que para isto no necessrio
uma outra tabela, mas para isto necessrio o uso de funes de agregao
as quais no so suportadas pelos operadores DELETE e UPDATE. Neste caso a
sada tambm foi a utilizao do operador IN, retornando o maior cdigo de
funcionrio como referncia para realizao da operao.
Exemplo 29: - DELETE com subconsulta a mesma tabela
Delete from funcionario f
where f.numMatricula in(select max(g.numMatricula) from funcionario g)

Recapitulando
Ao concluir este captulo, foi possvel evidenciar diversas situaes
relacionadas a critrios de pesquisa. Foi constatada a importncia dos
operadores lgicos, os quais possibilitaram alm de outras funcionalidades, a
criao de mais de uma regra de pesquisa.
Tambm foi destacada a ordem de execuo dos comandos AND e OR, o
qual atravs de exemplos, foi possvel concluir a necessidade em alguns casos,
do uso de parnteses como forma de execuo correta dos critrios definidos.
As funes de agregao trouxeram maiores possibilidades de
resultados, mas em caso de utiliz-las juntamente com um outro atributo da

110

Banco de Dados I

tabela pesquisa, haver necessidade do uso da clausula de agrupamento

GROUP BY. Estas funes de agregao tambm podem possuir condies, e
em caso de utiliz-las necessrio coloc-la na clausula HAVING do comando
SQL, pois a condio WHERE no suporta funes de agregao.
Este captulo tambm tratou do uso da clausula IN como alternativa
para realizar subconsultas as quais podem ser aplicadas em comandos de
seleo, alterao e excluso de dados. Desta forma, muitas rotinas que
aparentemente no eram possvel de ser executadas podem ser utilizadas.

Atividades
Assinale (V) para as assertivas Verdadeiras e (F) para as Falsas, tendo como
base a figura que segue contendo os dados armazenados na tabela de cliente.

1)

V
( )

F
( )

Assertiva
O comando abaixo relacionado lista todos os dados dos clientes do
sexo F cujo endereo possua o nmero 3
select * from tbcliente h where h.sexoCli='F' or upper(endcli) like
upper('%3%')

2)

( )

( )

O comando abaixo relacionado lista os dados de todos os

clientes que no tenham cdigo 4, 6 ou 1.
select * from tbcliente x where not x.pkcodcli in(4,6,1)

3)

( )

( )

O comando abaixo relacionado lista a soma e a mdia de salrio

de todos os clientes que possuem salrio abaixo de R$ 1000,00 e
nasceram antes de 20/10/1999.
select sum(t.salariocli) as soma, avg(t.salariocli) as media from
tbcliente t where t.salariocli<1000 and t.datanasccli<'20/10/1999'

4)

( )

( )

O comando que segue lista o sexo dos clientes e a quantidade de

clientes do respectivo sexo, cuja mdia salarial esteja superior a
R$ 800,00, dos clientes cujo nome termine com a lera o.
select j.sexocli, count(*)as quant from tbcliente j
where upper(j.nomecli) like upper('%o')
having avg(salariocli)>800
group by j.sexocli

111

Banco de Dados I

5)

( )

( )

O comando abaixo relacionado aumenta mais R$ 230,00 ao salrio

do cliente que possui o maior e o menor salrio.
update tbcliente w set
w.salariocli=salariocli+230
where w.salariocli in(select max(u.salariocli) from tbcliente u)
or w.salariocli in(select min(p.salariocli) from tbcliente p)

Gabarito:
Questo 1 F ( o operador correto neste exemplo deveria ter sido AND)
Questo 2 V
Questo 3 V
Questo 4 V
Questo 5 V

112

Banco de Dados I

Consultas envolvendo mais de uma tabela

Christiano Cadon

Introduo
Neste captulo ser estudado e exemplificado a utilizao de mais de
uma tabela para execuo de consultas. Sero implementados conceitos de
produto cartesiano, junes, consultas envolvendo outra consulta e vises de
dados.
Ao concluir este captulo o aluno ter conhecimento necessrio para
implementar consultas complexas utilizado mais do que uma tabela como
referencia.

Consulta envolvendo mais de uma tabela

Nos captulos anteriores foi estudado uma srie especificaes
relacionadas a consulta de dados. Contudo todas faziam referencia a
utilizao de uma nica tabela. De forma prtica um diagrama relacional
dificilmente ter apenas uma ou duas tabelas, principalmente se neste for
aplicada as tcnicas de normalizao de dados. Assim para obter uma
listagem que envolva mais de uma tabela necessrio citar as tabelas e
apresentar as relaes existentes entre estas tabelas.
Como forma de exemplificar os exemplos que sero trabalhados neste
captulo a figura 80 apresenta um diagrama relacional envolvendo as tabelas
de categoria, produto e fornecedor.

Figura 80 Diagrama ER base para exemplificar os tpicos deste captulo

Perceba que as cardinalidades mnimas das relaes no so

obrigatrias, o que implica em dizer que poder haver produtos que no
possuam categorias ou que no possuam fornecedores.
A figura 81 apresenta um conjunto de tabelas populadas relacionadas
ao diagrama apresentado na figura 80. Nesta pode ser identificada a
existncia de dois produtos que no possuem fornecedores vinculados a este,
ou seja a chave estrangeira fkcodforn da tabela de produto est vazia(nula).

113

Banco de Dados I

Figura 81 Tabelas populadas para exemplificao

comum em diagramas com mais de uma tabela, como o caso do

diagrama ER da figura 80, apresentar respostas que seja necessrio envolver
atributos de mais de uma tabela. Neste caso, necessrio que ocorra um
relacionamento entre as entidades. A aplicao de relacionamento entre
entidades pode ocorrer de formas diferentes. A maneira mais trivial de
relacionar mais de uma entidade informar o nome das tabelas entre a
clausula FROM e WHERE de um select. Segue uma nova atualizao da sintaxe
do comando select:

Por exemplo, caso seja necessrio listar o nome do produto

(nomeprod), o valor de venda do produto (valorvenda) e o nome da categoria
(nomecat), basta listar os atributos que deseja mostrar como retorno e
acrescentar as tabelas de categoria (tbcategoria) e produto (tbproduto) aps
a clausula FROM. O exemplo 30 ilustra a aplicao de mais de uma tabela na
mesma consulta.
Exemplo 30: - Listando dados de mais de uma tabela
select p.nomeprod,p.valorvenda,c.nomecat from tbproduto p, tbcategoria c

Contudo, ao executar cdigo do exemplo 30 o usurio perceber que a

resposta no est plenamente correta. Isto de deve pelo fato de que, ao
colocar mais de uma tabela aps a clausula FROM do select, o SGBD realiza

114

Banco de Dados I

um produto cartesiano entre as entidades. Tendo como base que a tabela de

categoria possua 3 registros e a tabela de produto possua 15 registros, o SQL
resultante do exemplo 30 trar 45 registros(3x15), pois para cada registro de
produto, o SGBD adiciona uma categoria. Isto se deve pelo fato do SQL utilizar
o conceito de lgebra relacional, j abordado nos captulos anteriores.
Da mesma forma que na lgebra relacional, a soluo do produto
cartesiano trazer apenas os registros corretos, identificar a relao
existente entre as tabelas envolvidas. Para isto, basta criar um critrio na
clausula WHERE do SELECT relacionando a chave estrangeira de categoria
existente na tabela de produto (fkcodcat), e a chave primria da tabela de
categoria (pkcodcat).
Assim, sempre que necessrio relacionar mais de uma tabela em uma
consulta SQL, deve tambm ser informado na clausula WHERE, a(s)
condio(es) que fazem referencia ao relacionamento entre as entidades
envolvidas. A figura 82 apresenta a implementao correta do exemplo 30 e o
resultado a pesquisa realizada.

Figura 82 Exemplo da utilizao de produto cartesiano

O mesmo ocorre quando existe a mais do que duas tabelas envolvidas

na consulta. Por exemplo, se necessitssemos listar o nome do produto, o
nome da categoria e o nome do fornecedor que forneceu o produto, cujos
produtos possuam mais do que 20 unidades em estoque, seria necessrio
informar todas as tabelas envolvidas e os relacionamentos existentes entre as
tabelas envolvidas.
A figura 83 apresenta a forma como deve ser
implementado o comando de seleo e o critrio de busca, juntamente com o
contedo de resposta do comando.

115

Banco de Dados I

Figura 83 Exemplo da utilizao de produto cartesiano com 3 tabelas e uma condio

Utilizando JOIN
A tcnica de utilizao do produto cartesiano soluciona o problema de
utilizar mais de uma tabela como resposta de uma pesquisa, porem no a
nica alternativa. Outra alternativa a utilizao da clausula JOIN no
comando SELECT. Esta clausula s funciona nos comandos de seleo e possui
algumas caractersticas particulares que possibilitam resultados de busca bem
interessantes. Desta forma segue novamente uma atualizao da sintaxe do
comando de seleo contendo JOIN.

Em geral a aplicao de JOIN mais otimizada do que a utilizao de

tabelas aps a clausula FROM de um SELECT. Contundo, os SGBD mais
modernos otimizaram a execuo de consultas, no apresentando diferena
de performance entre a utilizao de ambos os mtodos , com exceo da
execuo de consultas complexas.
A clausula JOIN possui algumas variaes (inner, left, right, full)
trazendo resultados diferentes de acordo com sua utilizao.
Para utilizar JOIN, basta informar uma tabela aps a clausula FROM e
em seguida utilizar o JOIN informado a outra tabela. Aps a aplicao da
clausula ON presente na sintaxe do JOIN deve ser informada a relao
existente entre as tabelas j especificadas. A figura 84 apresenta a mesma

116

Banco de Dados I

consulta utilizada no exemplo da figura 83, que lista o nome do produto, sua
categoria e fornecedor, onde seu estoque seja superior a 20.

Figura 84 Exemplo da utilizao de inner join

Observe que as restries que antes estavam sendo aplicadas (exemplos

das figuras 82 e 83) na clausula WHERE agora fazem parte do INNER JOIN. A
principal diferena est no momento em que for executada uma clusula
INNER, definir alm do critrio de relao entre as tabelas, outra(s)
condio(es) que possam fazer parte de um critrio de busca. Bem aplicada,
consultas com estas caractersticas, podem retornar os dados de forma mais
otimizada (rpida).
Observe os exemplos a e b da figura 85. Ambos retornam a mesma
resposta, porm internamente o SGBD trata a chamada de consulta de forma
diferente. Ambos os exemplos listam o nome do produto, o nome da categoria
e o nome do fornecedor que forneceu o produto, de todos os produtos cuja
categoria inicie com a letra P.

Figura 85 Exemplo da utilizao de INNER JOIN com mais um critrio

A principal diferena do ponto de vista de otimizao, est relacionado

ao fato que quando o SGBD realiza o produto cartesiano entre o produto e a

117

Banco de Dados I

categoria(primeira relao na clausula INNER JOIN), ele far somente com os

registros cuja categoria inicie com a letra P no caso do exemplo b,
enquanto o exemplo a s far o filtro aps realizar os demais produtos
cartesianos existentes, neste caso a segunda linha do INNER JOIN (entre
produto e fornecedor). Muitos SGBD inclusive detectam a possibilidade de
otimizar e internamente alteram a linha SQL de forma que a consulta possua
melhor performance. Sendo assim, se voc desenvolver uma consulta e esta
demorar para a ser processada, implemente alternativas como o exemplo b
da figura 85 que poder ocorrer melhorias no resultado da mesma.
Cabe salientar a velocidade na recuperao das informaes
importante para qualquer porte de sistema. Para atingi-la existe uma srie de
mecanismos, que iniciam na modelagem do banco e so concludas com o
mtodo de pesquisa e criao de ndices.
Vamos avaliar a figura 86, que possui duas consultas distintas, onde na
primeira (a) estamos listando o nome dos produtos e suas respectivas
categorias, e na segunda estamos listando o nome dos produtos e seus
respectivos fornecedores (b). Perceba que o nmero de retorno de registros
diferente de uma e da outra pesquisa realizada.

Figura 86 Exemplo de seleo com INNER JOIN

Na consulta a so listados 15 registros, exatamente os 15 produtos

cadastrados que foram definidos na figura 81. J o exemplo b so listados
apenas 13 registros. Esto faltando os registros de Po Frances e Bolo de
fub. Isto se deve pelo fato dos produtos Po Frances de cdigo 103 e o
produto Bolo de fub de cdigo 115, no possurem fornecedores
relacionados (contedo no campo fkcodforn nulo). Quando executamos um
INNER JOIN definindo uma relao onde o contedo de um atributo deve ser

118

Banco de Dados I

igual ao contedo de outro atributo de outra entidade, criando uma regra de

obrigatoriedade.
Se ocorrer a necessidade de, por exemplo, listar o nome do produto
(nomeprod) e o nome do fornecedor vinculado ao produto (nomeforn) onde
obrigatoriamente seja necessrio listar o nome do produto independente de
que exista ou no um fornecedor vinculado a ele, pode ser utilizado a clusula
LEFT JOIN ou RIGHT JOIN. A escolha de um ou outro depende do tipo de
informao que necessrio ser apresentado. A clusula LEFT JOIN utilizada
quando existe a necessidade de obrigatoriedade de visualizao dos dados da
tabela que se encontra a esquerda da clusula LEFT JOIN. J a clusula RIGHT
JOIN utilizada quando ocorre a necessidade de visualizar de forma
obrigatria informaes da tabela que est direita da clusula RIGHT JOIN.
A figura 87 apresenta o resultado da pesquisa utilizando a clusula LEFT JOIN.

Figura 87 Exemplo de seleo com LEFT JOIN

Neste caso, a consulta retornou todos os produtos, independente se o

produto possui ou no fornecedor. Nos registros os quais este no possui
fornecedor (chave estrangeira nula), o nome do fornecedor fica em branco.
Caso tivssemos utilizado a clusula RIGTH JOIN para esta mesma
consulta, o resultado no seria o mesmo. O exemplo apresentado na figura 88
ilustra o mesmo exemplo apenas alternado para a clausula para RIGTH JOIN.
Observe que a resposta ficou completamente diferente do exemplo da
figura 87. Alm de no apresentar os dois produtos que no possuram a chave
estrangeira, retornou como resposta o fornecedor que no possua nenhum
produto relacionado. Isto se deve pela definio da clausula. No exemplo da
figura 88 o SQL sempre retornar os dados de todos os fornecedores pois a
tabela est a direita da clausula RIGHT JOIN, alm de listar os produtos que
possuem relao com fornecedor.

119

Banco de Dados I

Figura 88 Exemplo de seleo com RIGHT JOIN

Existe tambm a possibilidade de utilizar a clusula FULL JOIN, que

possui como caracterstica, listar todos os elementos das tabelas envolvidas, e
caso exista relao, mostrar o elementos relacionados. A figura 89 apresenta
a implementao do mesmo exemplo agora utilizando a clausula FULL JOIN.

Figura 89 Exemplo de seleo com FULL JOIN

Utilizao de consultas como base para realizao de outras

consultas
A grande maioria dos SGBD do suporte a utilizao do resultado de
uma consulta no lugar de uma tabela fsica para execuo de uma outra
consulta. A implementao deste tipo de SQL muito comum, no processo de
otimizao de consultas complexas e ou facilitar encontrar dados em tabelas
relacionadas. A utilizao desta tcnica simples, basta colocar entre
parnteses o cdigo SQL desejado no lugar do nome da tabela de uma clusula

120

Banco de Dados I

SQL convencional. Neste caso necessrio que esta consulta interna possua
um alias (apelido). O alias definido, poder ser setado como se fosse uma
tabela no restante da consulta, e os atributos de retorno da consulta, sero os
atributos de resposta desta suposta tabela.
O exemplo apresentado na figura 90 apresenta uma listagem contendo
todos os dados da tabela produto, que possua relao com outra consulta
denominada cat, a qual lista o cdigo e nome de categoria de todas as
categorias cujo nome da categoria inicia com a letra B.

Figura 90 Exemplo 1 de consulta como base de novas consultas

Observe que a consulta de cdigo e nome de categoria que inicia com a

letra B executada dentro da clausula FROM do SELECT, e seu resultado
atribudo para o alias CAT. O SQL trata cat como se fosse uma tabela
contendo valores nela armazenada.
Neste caso, o SGBD executa primeiramente a consulta destacada
retornando apenas os registros que iniciam com a letra B, e em seguida
realiza o produto cartesiano com a tabela de produto. Esta execuo otimiza
significativamente uma consulta que possua um volume de dados significativo.
Imagine que exista cadastrado na tabela de produtos 5.000 produtos e 40
categorias, onde destas 40 categorias, 5 iniciem com a letra B. Se fosse
realizada a execuo apenas relacionando as duas tabelas na clusula from, o
SGBD inicialmente iria realizar um produto cartesiano retornando em memria
200.000 registros para da sim, aplicar as regras condicionais definidas (neste
caso where upper(c.nomecat) like 'B%' e p.fkcodcat=cat.codigo). Contudo o
exemplo apresentado na figura 90 otimiza o resultado, pois o produto
cartesiano possuir um conjunto contendo um nmero menor de registros. O
SGBD ir inicialmente executar a subconsulta definida como cat onde
retornar apenas 5 registros. Com base nestes 5 registros aplicar um produto
cartesiano nos outros 5.000 registros de produtos resultando em memria
25.000 registros, que posteriormente sero submetidos a clausula where do
select principal.

121

Banco de Dados I

Pode ser observado tambm, que o nome das colunas de resposta est
associado ao nome dos atributos que foram definidos na consulta denominada
cat, neste caso os campos codigo e categoria.
Alm de otimizar consultas, a aplicao deste mtodo de busca de
dados pode proporcionar a busca dados mais complexos facilitada. Por
exemplo: imagine que, necessitamos listar em tela o nome de todas as
categorias e duas outras colunas, sendo que a primeira listaria a quantidade
de produtos desta categoria que possusse seu estoque superior a 20 unidades,
e a outra coluna, contendo a quantidade de produtos desta categoria que
possua estoque at 20 unidades.
A figura 91 apresenta uma alternativa de resposta utilizando o mtodo
de seleo de dados na clusula from.

Figura 91 Exemplo 2 de consulta como base de novas consultas

Observe que so executadas outras duas consultas, sendo a primeira

listando o cdigo da categoria e a quantidade de produtos que possuem um
estoque superior a 20 unidades, e a outra consulta retornando o cdigo de
categoria e a quantidade de produtos vinculados que possuam seu estoque at
20 unidades. Como resposta, temos uma relao de categorias e outras duas
colunas que representam o resultado das outras duas consultas
respectivamente.
Cabe salientar que a utilizao deste mtodo tambm possvel nas
clausulas INNER, LEFT, RIGHT e FULL JOIN. Neste caso no lugar do nome das
tabelas apenas colocamos a consulta desejada.

Unio de consultas
Da mesma forma que a lgebra relacional une tupas de duas relaes
que sejam compatveis, a clausula UNION realiza a unio de dois comandos
SELECT que possuam colunas de resposta compatveis.

122

Banco de Dados I

Vamos imaginar, por exemplo, que seja necessrio listar uma relao
contendo o nome das categorias e o nome dos fornecedores cadastrados.
Neste caso basta executar dois SELECT sendo o primeiro retornando as
categorias e o segundo retornando fornecedores unindo-as com a clausula
UNION. A figura 92 apresenta a soluo do exemplo apresentado.

Figura 92 Exemplo de UNION

Criando vises de dados

Uma viso (ou view) classificada como uma tabela virtual, ou seja,
ela na prtica no existe de forma fsica, ao contrrio das tabelas da base,
cujas tuplas sempre esto armazenadas fisicamente no banco de dados.
(Elmasri, 2011)
Uma view pode ser visualizada como um modo de especificar uma
tabela que precisamos referenciar com frequncia, embora ela possa no
existir fisicamente. A partir da criao de uma view, esta pode ser acessada
como se fosse uma tabela, inclusive possvel relacionar a view com outras
tabelas ou outras veiw. (Elmasri, 2011)
A sintaxe da criao de uma view :

O exemplo 31 cria uma view chamada exemploview que possui como

contedo o cdigo do produto, o nome do produto, o nome da categoria do
produto, e o nome do fornecedor que fornece o produto.

123

Banco de Dados I

Exemplo 31: - Criando view

create view exemploview as

select p.pkcodprod, p.nomeprod, c.nomecat, f.nomeforn from tbproduto p
inner join tbcategoria c on c.pkcodcat=p.fkcodcat
left join tbfornecedor f on f.pkcodforn=p.fkcodforn
Assim que criada a view ela pode ser acessada. Os exemplos
apresentados na figura 93 apresentam a utilizao da view criada
(exemploview). Observe que a view est sendo utilizada como se fosse uma
tabela comum, inclusive aplicando condies sobre seus atributos, e
adicionando relaes com outras tabelas.

Figura 93 Exemplo do uso de VIEW

Caso seja necessrio remover uma view, utiliza-se o comando DROP

VIEW <nome_da_view>.

Recapitulando
Ao concluir este captulo, o aluno teve oportunidade de conhecer as
formas de realizar uma consulta com mais de uma tabela. Foi estudada a
aplicao de mais de uma tabela aps a clausula FROM, gerando um produto
cartesiano entre as tabelas envolvidas. Neste tpico o aluno recordou os
conceitos da lgebra relacional, e entendeu de forma prtica como
importante adicionar uma condio ligando as tabelas relacionadas para
trazer a correta informao. Em seguida, foi abordado o uso da clausula JOIN
como alternativa de relacionar mais de uma tabela, onde foi estudada atravs

124

Banco de Dados I

de exemplos prticos a diferena da aplicao INNER, LEFT, RIGHT e FULL

JOIN.
Em seguida, foi abordado o uso de consultas como base para realizao
de outras consultas. Atravs de um exemplo foi possvel compreender o do
porque este tipo de operao muito utilizado na otimizao de consultas,
pois minimiza significativamente o resultado de memria que um produto
cartesiano realiza ao relacional tabelas.
Este captulo tambm abordou o uso da clausula UNION, como forma de
unir duas consultas que retornam o mesmo tipo de dado em uma nica
resposta. Por fim, tambm foi possvel conhecer como funciona o conceito de
VIEW como alternativa de operacionalizar dados.

Atividades
Tendo como base o diagrama lgico que segue, assinale (V) para as assertivas
Verdadeiras e (F) para as Falsas

1)

V
( )

F
( )

Assertiva
Ambos os comandos que seguem possuem sua sintaxe correta e
retornam a mesma resposta
Comando 1:
select t.nometurma,c.nomecurso from tbturma t, tbcurso c
where t.fkcodcurso=c.pkcodcurso
Comando 2:
select t.nometurma,c.nomecurso from tbturma t inner join
tbcurso c on t.fkcodcurso=c.pkcodcurso

2)

( )

( )

O comando que segue lista o nome do curso de todas as turmas

cursadas pelos alunos que iniciam com a letra a cujo professor
possua em seu nome a palavra silva.
select distinct c.nomecurso from tbcurso c
inner join tbturma t on t.fkcodcurso=c.pkcodcurso
inner join tbalunoturma at on at.fkcodturma=t.pkcodturma
inner join tbaluno a on a.pkcodaluno=at.fkcodalu
inner join tbprofessor f on f.pkcodprof=t.fkcodprof
where upper(a.nomealuno) like upper('a%') and
upper(f.nomeprof) like upper('%silva%')

125

Banco de Dados I

3)

( )

( )

O comando que segue lista o nome do curso, o nome da turma de

todas as turmas de cdigo maior do que 300, cujo nome do curso
inicie em info, em ordem de nome de curso
select c.nomecurso, t.nometurma from tbturma t
left join tbcurso c on t.fkcodcurso=c.pkcodcurso and
upper(c.nomecurso) like upper('info%')
where t.pkcodturma>300 order by t.nometurma

4)

( )

( )

Gere uma lista contendo o nome de todos os alunos e

professores das turmas de cdigo menor do que 250
(select distinct a.nomealuno as nome from tbaluno a,
tbalunoturma at where a.pkcodaluno=at.fkcodalu and
at.fkcodturma<250)
union
(select p.nomeprof as nome from tbprofessor p
inner join tbturma t on t.fkcodprof=p.pkcodprof
where t.pkcodturma<250)

5)

( )

( )

Liste todos os dados da tabela de turma alm da maior e menor

mdia desta turma se existir.
select t.* , mm.maior, mm.menor from tbturma t
left join (select at.fkcodturma as cod, max(at.media) as
maior, min(at.media) as menor from tbalunoturma at group
by at.fkcodturma) mm on t.pkcodturma=mm.cod

Gabarito:
Questo 1 V
Questo 2 V
Questo 3 F (O nico erro que est sendo ordenado pelo nome da turma e
no pelo nome do curso)
Questo 4 V
Questo 5 V

126

Banco de Dados I

Referencias
Elmasri, Rames: Sistemas de Banco de Dados. 6 Edio. So Paulo.
Editora Personal, 2011
Date, C J,. Introduo a Banco de Dados. 8 Edio . So Paulo.
Editora
Campus,2003
Rob. Peter e Coronel, Carlos. Sistemas de Banco de Dados: Projeto
implementao e administrao. 8 Edio. So Paulo. Editora
Cengage Learning,2011
MEDEIROS, L. F. Banco de Dados: princpios e prtica. Curitiba :
Ibpex, 2007.

ULBRA . EAD

127