modelagem de dados.pdf
TRANSCRIPT
Modelagem de Dados
Aula 01
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 1
OBJETIVOS
Apresentar os conceitos iniciais sobre bancos de dados e sua importância para as
organizações. Conceituar a diferença entre dado e informação. Apresentar as
diferenças entre sistemas baseados em arquivos e sistemas gerenciadores de
banco de dados.
CONCEITOS BÁSICOS DE BANCOS DE DADOS
Considerações iniciais
A modelagem de dados faz parte de uma etapa muito importante do
desenvolvimento de sistemas, na qual se desenha toda a estrutura dos dados que
envolvem uma atividade humana a ser informatizada. O estudo feito sobre a
modelagem de dados serve tanto para uma pequena atividade comercial como para
uma grande organização.
A modelagem de dados antecede a construção do banco de dados em um meio
computacional, ela mostra a estrutura do banco de dados, seja do ponto de vista do
usuário como da sua forma física.
Introdução ao banco de dados
Um banco de dados é um conjunto de elementos extraídos a partir de informações
do mundo real. Esses dados são organizados, classificados e relacionados de forma
que possam gerar novas informações para o mundo real. O nome banco de dados
teve sua origem na tradução da palavra inglesa data banks e mais tarde foi
modificada por database, que significa base de dados .
O século XXI está marcado pela “Era da Informação Digital”. O mundo dos negócios,
o sucesso das empresas, o comércio e a educação de um país dependem de um
elemento vital: a informação. As informações podem justificar fatos que contribuem
para a formação do conhecimento e a tomada de decisões.
A informática se preocupa em gerar a informação por meio de tecnologia ágil e
eficaz para que esteja ao alcance de todos. O banco de dados é um grande
responsável pelo processo. A montagem adequada, seguida de regras e métodos
permite que os dados extraídos sejam corretos e as informações geradas sejam
espelho da realidade.
Dado e informação, qual a diferença?
O dado identifica ou quantifica algo, é absoluto e objetivo. A informação tem um
significado para o mundo real, tem valor relativo ou é uma qualificação do dado. A
informação pode ter um ou mais dados. Quando um dado lembra um fato associado,
ele vira informação. Certos nomes de pessoas ou lugares que ficaram famosos
pelos seus fatos se tornaram ícones e agregam valores, por exemplo, Ronaldinho.
Exemplos de informações:
O aluno Mario Silva é casado com Laura, mora na Rua Abraão Lins, 230. Ele nasceu
no bairro da Bela Vista em São Paulo e sua profissão é vendedor.
Estas informações possuem vários dados envolvidos e o seu conjunto tem um
significado para o mundo real.
Examinando a frase, quais os dados que poderiam ser extraídos?
Se misturarmos os dados poderá não significar nada para nós que estamos lendo a
frase.
Laura Bernardes, vendedor, Mario Silva, Rua Abraão Lins 230, São Paulo, Bela
Vista.
Para que esses dados possam ser resgatados de um banco, é necessário classificá-
los, organizá-los e relacioná-los; caso contrário, teremos um “banco de dados
insignificante”.
Classificando os dados, teremos:
Nome do aluno: Endereço: Local de nascimento:Mario Silva Rua Abraão Lins, 230 Bela Vista
UF de nascimento: Profissão: Cônjuge:São Paulo Vendedor Laura Bernardes
Vamos analisar agora outro exemplo:
“O inverno do Canadá é mais frio que o inverno brasileiro.”
Essa é uma informação que pode ter significado para o mundo real. Nela está
implícita a comparação das temperaturas mínimas dos dois países. Se criarmos uma
tabela de países e suas temperaturas mínimas em um determinado ano, teremos os
seguintes dados:
Países Temperatura MínimaBrasil + 8º CCanadá - 43º CFrança - 3º C
A tabela contém dados: Canadá, Brasil, França; e a palavra países é apenas uma
classificação desses dados, bem como - 3 º C, - 43 º C e + 8 º C, que também são
dados classificados como temperatura mínima. A informação é uma mensagem
significativa que nos leva a associar fatos do mundo real. O dado, por si só, não tem
significado algum, ele apenas identifica algo. As comparações e as conclusões que
tiramos dos dados geram informações. A afirmativa acima poderia ser concluída por
um turista que sentiu na pele o frio dos dois países, mas se quisermos saber se
realmente é verdadeira, precisamos comparar os dados da tabela ou repetiremos a
mesma experiência de quem passou a informação. O banco de dados é formado por
um conjunto de elementos organizados em forma de tabelas e relacionados entre si,
de acordo com o significado que eles têm no mundo real. Se os dados e os seus
relacionamentos são verdadeiros, as informações que obtemos deles também serão
verdadeiras.
Formas de armazenamento de dados
Podemos armazenar os dados de uma aplicação de duas maneiras:
1. Sistema de armazenamento em arquivos
O que é um arquivo? É uma forma que os sistemas operacionais utilizam para
armazenar e organizar os dados em meio permanente. Um arquivo é composto por
uma identificação e um conjunto de dados agrupados em forma de registros. Cada
registro é formado por campos em que esses dados são armazenados, por exemplo,
imagine um arquivo para armazenar os dados de funcionários. Cada funcionário tem
seus dados dentro de um registro do arquivo.
Os arquivos são criados e mantidos pelos programas desenvolvidos em uma
linguagem que o programador escolhe para desenvolvê-los. Os dados somente
podem ser acessados em um programa da mesma linguagem em que foram
gerados ou algum programa compatível.
Os arquivos são dependentes da linguagem em que foram criados. Em uma
organização, os sistemas baseados em arquivos apresentam as seguintes
desvantagens:
• Inconsistência e redundância de dados :
Uma vez que os arquivos são mantidos por aplicações feitas por vários
programadores, ao longo do tempo, com as mudanças que as empresas
enfrentam, é comum haver alteração dos formatos e criação de arquivos para
novas implementações. Assim, os dados se repetem, pois cada aplicação possui
a sua forma de armazenamento.
• Dificuldade de acesso aos dados :
Toda vez que o usuário necessita de outra forma de acesso aos dados, diferente
da que o sistema oferece, o programador precisa mudar o programa ou, muitas
vezes, desenvolver outro para atender ao usuário. Isso tem um custo elevado de
desenvolvimento para as empresas, além do tempo gasto para elaborá-lo, na
maioria das vezes, há urgência em receber os dados, retardando a tomada de
decisões.
• Isolamento dos dados:
Como os dados estão armazenados em arquivos independentes, é possível que,
ao tentar acessá-los de outro arquivo com formato diferente, não seja possível ou
haja necessidade de criar novas aplicações para compatibilizá-los.
• Falta de integridade:
Uma aplicação de usuário geralmente é feita por vários arquivos e existe sempre
uma dependência e uma relação entre os dados de um arquivo para outro. Se o
programador não se preocupar, ou não conhecer essa dependência, correrá o
risco de criar programas que, ao buscar dados, resultem em uma pesquisa
errada, ocasionando danos à empresa.
• Falta de atomicidade:
Transação atômica – em computação – significa que, em uma interrupção
qualquer no sistema por falha técnica, essa transação deve ser completada ou
abortada, ou seja, todos os arquivos devem ser atualizados automaticamente ou
retornados à situação anterior. No sistema baseado em arquivos, esta
preocupação recai na mão dos programadores, que devem criar mecanismos de
tratamento a falhas. Se a empresa não possui uma política de padronização das
ações a serem tomadas, o programador pode errar no processo, afetando os
dados.
• Falta de segurança:
Os sistemas baseados em arquivos dependem da proteção do sistema
operacional e das permissões de acesso ao dispositivo onde estão
armazenados. O programador poderá ter se lembrado de criar senha na sua
aplicação, mas se outro programador tentar criar um programa para acessar o
mesmo arquivo, sem proteção alguma, este fica vulnerável a modificações
indesejadas, que normalmente são feitas pelos usuários.
2. Sistema de banco de dados
Um Sistema de Gerenciamento de Banco de Dados (SGBD) consiste em uma
coleção de dados inter-relacionados e um conjunto de programas que fazem acesso
aos dados. Os SGBDs são concebidos para gerenciar desde um pequeno conjunto
de dados até um grande volume. Oferecem as estruturas para armazenamento e
todos os mecanismos para manipulação, ou seja, inclusão, alteração, exclusão,
seleção e busca dos dados.
A estrutura é criada pelos analistas de banco de dados ou pelos desenvolvedores de
sistemas aplicativos para o usuário final ter fácil acesso.
Por que usar um sistema de banco de dados?
Os primeiros sistemas de armazenamento de dados eram baseados em arquivos.
Os SGBDs surgiram para eliminar todos os problemas apontados como
desvantagens na utilização dos sistemas baseados em arquivos.
Os sistemas de gerenciamento de banco de dados possuem as seguintes
vantagens:
• Integridade dos dados.
• Segurança de acesso aos dados.
• Atomicidade nas transações.
• Concentração dos dados em um repositório, geralmente em um servidor de
dados.
• Independência de linguagem de programação.
• Impõem regras de utilização para toda e qualquer aplicação que se conectar ao
banco de dados.
Observação
Os nomes das entidades e de seus respectivos atributos não foram acentuados, pois
não se recomenda utilizar acentos para denominar tabelas e colunas (de tabelas)
em bancos de dados.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 02
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 2
OBJETIVOS
Apresentar os modelos de dados em rede, hierárquicos, relacionais e orientados a
objetos. Demonstrar as etapas de desenvolvimento de um projeto de banco de
dados.
ETAPAS DA ELABORAÇÃO DE UM
PROJETO DE BANCO DE DADOS
Introdução
Os modelos de dados especificam a estrutura lógica dos dados. Os formatos mais
conhecidos são:
• Hierárquico.
• Rede.
• Relacional.
• Orientado a objetos.
Modelo hierárquico
Surgiu na década de 1960 com a primeira linguagem de banco de dados: a DL/I
desenvolvida pela IBM e a North American Aviation.
Organiza os dados de cima para baixo, como uma árvore. Cada registro é dividido
em partes denominadas segmentos. O banco de dados se assemelha a um
organograma com um segmento raiz e um número qualquer de segmentos
subordinados.
Modelo em rede
Definido pelo DBTG (Data Base Task Group) do comitê do CODASYL (Conference
on Data Systems Language) a partir de 1971. Esse modelo é uma extensão do
modelo hierárquico.
Nos modelos baseados em rede, os dados são agrupados em forma de registros em
que um aponta para outro por meio de ponteiros (links), exemplo:
Modelo relacional
O modelo relacional é um conjunto de tabelas relacionadas entre si por meio dos
próprios dados, não utilizando ponteiros para ligar os registros. Veja o mesmo
exemplo usando o modelo relacional:
Modelo orientado a objetos
Um objeto que representa algo no mundo real possui dados que o identificam e
funções que ele pode executar. As funções são escritas com uma linguagem de
programação. Os dados são chamados de atributos e as funções de métodos. As
classes são definições de como os objetos deverão ser. Cada objeto é uma instância
de uma determinada classe, um exemplo análogo: “A receita de um bolo é uma
classe e o bolo é o objeto dessa classe. A partir de uma única receita podemos gerar
vários bolos.”
Etapas de elaboração de um projeto de banco de dados
Um projeto de banco de dados é constituído por três níveis de abstração:
1. Modelo conceitual.
2. Modelo lógico.
3. Modelo físico.
O modelo lógico, que será estudado em detalhes nas próximas aulas, refere-se
especificamente ao modelo relacional, pois ainda é o mais usado atualmente.
Análise de requisi tos
O primeiro passo para modelar os dados é fazer a análise de requisitos, ou seja,
descrever todas as informações necessárias para extrair os dados que deverão
compor o banco de dados. A descrição a seguir é um roteiro de necessidades que
devem ser levantadas.
• Quais os problemas que o banco de dados poderá solucionar.
• Qual o objetivo de criar um banco de dados para aquela realidade específica, ou
seja, os resultados esperados.
• Quais as informações que desejamos saber do banco de dados.
• Quais as regras de negócio.
• Quem está participando diretamente e indiretamente no negócio.
• Verificar documentos que formalizam a negociação: notas, contratos, pedidos
etc.
• Dados relevantes, casos de sucesso ou fracasso, pertinentes à problemática.
• Datas críticas.
• Restrições de dados.
Roger Pressman, em seu livro Engenharia de Software, descreve algumas
características que um analista deve ter para fazer uma análise de requisitos com
sucesso, uma vez que o usuário geralmente é leigo em informática:
• A capacidade de compreender conceitos abstratos, reorganizá-los em divisões
lógicas e sintetizar “soluções” baseadas em cada divisão.
• A capacidade de absorver fatos pertinentes de fontes conflitantes.
• A capacidade de entender os ambientes do usuário/cliente.
• A capacidade de aplicar elementos do sistema de hardware e/ou software aos
elementos do usuário/cliente.
• A capacidade de se comunicar bem nas formas escrita e verbal.
Modelo conceitual
Para representar o modelo conceitual de dados usaremos o Modelo Entidade-
Relacionamento (MER) criado por Peter Chen, em 1976, baseado na teoria
relacional desenvolvida por E. F. Codd em 1970. O MER surgiu para padronizar a
modelagem de dados por meio de diagramas, assim, qualquer profissional poderia
ler e compreender toda a sua estrutura, sem mesmo conhecer a realidade a que se
referia. A padronização facilita a criação de ferramentas CASE (Computer Aided
Software Engineering), programas usados na engenharia de software para auxiliar
no desenvolvimento de sistemas.
O MER (Modelo Entidade-Relacionamento) tem como princípio a representação do
mundo real em forma de objetos dos quais queremos obter informações. Estes
objetos recebem o nome de entidades. Para desenhar o modelo conceitual, usamos
um diagrama com símbolos para representar as entidades, os atributos e descrever
os relacionamentos.
Simbologia do Diagrama Entidade Relacionamento (DER)
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 03
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 3
OBJETIVO
Desenvolver a percepção de entidades, atributos e relacionamentos, utilizando o
DER (Diagrama Entidade Relacionamento).
ENTIDADES, ATRIBUTOS E RELACIONAMENTOS
Entidade
Conjunto de objetos do mundo real dos quais queremos manter informações no
banco de dados.
As entidades representam os agentes que interagem em um relacionamento. Podem
representar pessoas, documentos (pedidos, notas fiscais etc.), objetos e resultado
de ações. Observe os exemplos a seguir:
Atributo
Representa um dado associado a cada ocorrência de uma entidade ou de um
relacionamento.
Relacionamento
É o conjunto de associações entre entidades.
Exemplo: clínica médica.
Suponha que você tenha sido convidado para fazer a modelagem de dados de um
sistema para uma clínica médica.
Tomando como exemplo essa clínica, vamos começar a fazer a modelagem dos
dados. Inicialmente, vamos identificar algumas entidades envolvidas e analisar seu
relacionamento.
A atividade exercida na clínica envolve o médico consultar o paciente. Nessa ação
encontramos duas entidades: médico e paciente e o relacionamento é o ato de
consultar.
Desenhando o diagrama temos:
Uma entidade possui um conjunto de atributos, cada atributo está associado a um
tipo de dado, por exemplo, para que cada médico seja identificado, precisamos dos
seguintes dados: CRM, nome, especialidade e telefone. Esses são os atributos da
entidade MÉDICO.
Quando o paciente chega para sua primeira consulta, é necessário que ele informe
seu CPF, nome, telefone e data de nascimento. Esses são os atributos da entidade
PACIENTE.
Vamos desenhar os atributos no diagrama:
No banco de dados, a entidade representa uma tabela de dados. Desenhando as
entidades em forma de tabela, teremos:
MÉDICO
CRM NOME TELEFONE ESPECIALIDADE
12345 Dr. Maurício Pereira 5125-4562 clínico geral
54321 Dra. Patrícia Peres 5264-9874 pediatra
23451 Dr. Hildebrando Alves 5689-5454 cardiologista
PACIENTE
CPF NOME TELEFONE DATA_NASC
00111222333-44 Mauro Souza 5521-6245 10/02/1985
22333444555-66 Lucia Prado 5642-7893 12/11/1975
99888777666-55 Maria Gomes 5967-8245 15/05/1995
As tabelas são as representações das entidades, contendo os dados armazenados.
Essa é uma visão lógica dos dados no banco de dados.
A modelagem de dados ainda não está pronta, precisamos agora identificar quais as
outras entidades envolvidas e aquelas associadas aos relacionamentos que
aparecem durante a análise.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 04
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 4
OBJETIVO
Apresentar os conceitos de cardinalidade dos relacionamentos para a elaboração do
DER. Apresentar como deve ser feito o questionamento em cada entidade para
descobrir qual o grau de cardinalidade.
CARDINALIDADE MÍNIMA E MÁXIMA E GRAU DE CARDINALIDADE
Na aula anterior, vimos os conceitos de entidade, atributo e relacionamento. Agora,
vamos analisar a quantidade de ocorrências de uma entidade associada à outra por
meio de um relacionamento. Isso é chamado de cardinalidade.
Cardinalidade
É o número (mínimo/máximo) de ocorrências de uma entidade associada a uma
ocorrência de outra entidade por meio de um relacionamento.
Cardinalidade mínima
Indica o número mínimo de ocorrências de uma entidade associada à outra
ocorrência da outra entidade relacionada. Pode ser representada por 0 (zero)
quando a associação é opcional (não existe correspondente na outra entidade) ou 1
(um) quando a associação é obrigatória (pelo menos um correspondente na outra
entidade).
Cardinalidade máxima
Indica o número máximo de ocorrências de uma entidade associada à outra
ocorrência de outra entidade relacionada. É representado por 1 (um) ou N (várias ou
muitas).
Exemplo:
No exemplo apresentado, vamos imaginar duas entidades, uma de homens e outra
de mulheres, alguns homens são casados com mulheres da outra entidade e outros
não. Da mesma forma, algumas mulheres são casadas, outras não.
Para identificar a cardinalidade, deve ser feita a pergunta de uma entidade para
outra.
Um homem pode ser casado no mínimo com quantas mulheres da outra entidade? E
no máximo (legalmente!)?
Uma mulher pode ser casada no mínimo com quantos homens da outra entidade? E
no máximo (legalmente!)?
Quando usamos a cardinalidade mínima e máxima, devemos escrever da seguinte
forma: mínima, máxima.
Observe agora outro exemplo:
Uma empresa possui funcionários e seus dependentes; nem todo funcionário possui
dependentes, mas todos os dependentes têm algum funcionário associado. Vamos
colocar a cardinalidade analisando primeiro a entidade funcionário.
Um funcionário possui no mínimo 0 (nenhum) dependente.
Um funcionário possui no máximo N (vários) dependentes.
Agora, analisando a entidade dependente:
Um dependente tem no mínimo 1 (um) funcionário associado.
Um dependente tem no máximo 1 (um) funcionário associado.
Acesse o ambiente virtual de aprendizagem UNINOVE para a visualização do
slideshow que explica passo a passo como interpretar cardinalidades em um DER.
Grau de cardinalidade
Grau de cardinalidade refere-se à cardinalidade máxima, observando-se ambos os
sentidos. Portanto, podemos encontrar os seguintes graus de cardinalidade:
1:1 (um para um)
Uma ocorrência da entidade 1 se relaciona no máximo com apenas uma ocorrência
da entidade 2 e uma ocorrência da entidade 2 se relaciona no máximo com apenas
uma ocorrência da entidade 1.
1:N (um para muitos)
Uma ocorrência da entidade 1 se relaciona com muitas ocorrências da entidade 2
e uma ocorrência da entidade 2 se relaciona com apenas uma ocorrência da
entidade 1.
N:N (muitos para muitos)
Uma ocorrência da entidade 1 se relaciona com muitas ocorrências da entidade 2
e uma ocorrência da entidade 2 se relaciona com muitas ocorrências da
entidade 1.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 05
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 5
OBJETIVO
Apresentar os diversos graus de relacionamentos: binários, autorrelacionamentos e
ternários (n-ários).
GRAUS DE RELACIONAMENTOS
Introdução
O grau de um relacionamento refere-se ao número de entidades que participam de
um relacionamento. Observe a seguir os diversos graus de relacionamentos:
Relacionamento binário
Um relacionamento binário é aquele envolve duas ocorrências de entidade.
Conforme observado na aula anterior, podemos classificar os relacionamentos
binários em:
• 1:1 (um-para-um): cada ocorrência de uma entidade relaciona-se com uma e
somente uma ocorrência da outra entidade.
• 1:N (um-para-muitos): uma ocorrência da entidade 1 relaciona-se com muitas
ocorrências da entidade 2, mas cada ocorrência da entidade 2 somente pode
estar relacionada com uma ocorrência da entidade 1.
• N:N (muitos-para-muitos): em ambos os sentidos encontramos um ou mais
relacionamentos de um-para-muitos, isto é, uma ocorrência da entidade 1
relaciona-se com muitas ocorrências da entidade 2 e vice-versa.
Relacionamento ternário
Denominamos ternários os relacionamentos entre três conjuntos de entidades.
Relacionamentos com quatro ou mais conjuntos de entidades são chamados de
n-ários, porém, sua utilização não é recomendada em virtude de sua complexidade.
Sugere-se que sejam “quebrados” em relacionamentos binários e/ou ternários.
No exemplo a seguir, queremos garantir que a seguinte situação seja representada
de forma apropriada: o professor x ministra a disciplina y para a turma z. Esta
condição deve ser representada por meio de um relacionamento ternário.
Observe que, no exemplo apresentado, cada par de ocorrências (turma, disciplina)
está associado a, no máximo, um professor.
Podem estar associadas muitas disciplinas a um par (turma, professor), ou, em
outros termos, um professor pode ministrar a uma determinada turma várias
disciplinas.
Podem estar associadas muitas turmas a um par (disciplina, professor), ou, em
outros termos, um professor pode ministrar uma determinada disciplina a várias
turmas.
Autorrelacionamento
Representa o relacionamento entre ocorrências de uma mesma entidade.
• Autorrelac ionamento 1:1
O diagrama a seguir representa a seguinte situação: uma ocorrência de pessoa
exerce o papel de marido e outra ocorrência de pessoa exerce o papel de esposa.
Uma pessoa pode ter no máximo um cônjuge (marido ou esposa).
• Autorrelac ionamento 1:N
A seguir, temos representada a seguinte situação: uma ocorrência de funcionário
exerce o papel de supervisor e outras ocorrências de funcionário exercem o papel
de supervisionado. Um supervisor pode ter muitos supervisionados, mas cada
supervisionado tem apenas um supervisor.
• Autorrelac ionamento N:N
E, finalmente, temos representada a seguinte situação: algumas ocorrências de
produto exercem o papel de composto e outras ocorrências exercem o papel de
componente. Um produto pode entrar na composição de muitos outros produtos e
cada produto é composto por vários (muitos) outros.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de
dados. São Paulo: Berkeley Brasil, 2002.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 06
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 6
OBJETIVO
Atribuir propriedades particulares a entidades por meio do conceito de generalização
e especialização de seus atributos.
GENERALIZAÇÃO E ESPECIALIZAÇÃO
Conceitos básicos de generalização e especialização
Algumas entidades podem apresentar ocorrências em que uma parte delas possui
as mesmas propriedades e a outra parte possui propriedades diferentes, sendo
necessário separá-las em subgrupos (especializações).
Usando o conceito de generalização e especialização, podemos subdividir uma
entidade em várias outras de acordo com o significado dos seus dados.
O símbolo usado é um triângulo e para definir o tipo utilizamos (t) total e (p) parcial.
Podemos ver, no exemplo a seguir, que a entidade cliente de uma empresa pode ter
ocorrências de pessoa jurídica e ocorrências de pessoa física; ambas podem ter
nome, código e outros atributos em comum, mas possuem também atributos que as
diferenciam, como CPF e RG. Esses atributos somente o cliente pessoa física
possui, enquanto que CNPJ e Inscrição Estadual pertencem apenas ao cliente
pessoa jurídica. Para que a entidade cliente não seja definida com todos os atributos
em que uma possua determinados dados e outra não, separa-se a entidade cliente
em duas para melhor organização: pessoa física e pessoa jurídica.
A generalização/especialização está associada à herança porque as entidades
especializadas, além dos seus próprios atributos, possuem também todos os da
entidade generalizada.
No exemplo, cada ocorrência de pessoa física possui: código, nome, RG e CPF,
enquanto as ocorrências de pessoa jurídica possuem: código, nome, CNPJ e
INSC_EST.
A generalização/especialização pode ser classificada em dois tipos: total e parcial.
Total (t)
Quando cada ocorrência da entidade generalizada possui obrigatoriamente uma
ocorrência correspondente a alguma das entidades especializadas. Cada cliente ou
é pessoa jurídica ou é pessoa física, não existe um que não seja nenhuma das duas,
conforme exemplo.
O símbolo usado é a letra t.
Parcial (p)
A generalização/especialização é parcial quando existem ocorrências na entidade
genérica que não possuem ocorrências correspondentes na entidade especializada.
Vejamos um exemplo:
Nesse caso, nem todo funcionário é engenheiro ou advogado. Algumas ocorrências
existem apenas na entidade genérica.
Generalização e especialização em vários níveis
Pode ocorrer que uma entidade genérica tenha várias entidades especializadas que,
por sua vez, também generalizem outras entidades especializadas. Não há limite no
número de níveis hierárquicos.
No exemplo apresentado, a pessoa física pode ser nativa do país em questão ou
pode ser estrangeira. Cada uma possui documentos diferentes, mas pertence à
mesma entidade genérica pessoa física. Pode-se observar que ambas possuem
CPF e carteira profissional.
Herança múltipla
Podem existir casos em que uma entidade seja especialização de várias entidades
genéricas, então, dizemos que a entidade possui herança múltipla de atributos.
Observe o exemplo a seguir:
A entidade veículo anfíbio é uma especialização da entidade genérica veículo
terrestre e da entidade genérica veículo aquático, portanto, possui uma herança
múltipla por especializar mais de uma entidade genérica.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de
dados. São Paulo: Berkeley Brasil, 2002.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 07
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 7
OBJETIVO
Identificar uma entidade associativa em um relacionamento de N para N.
ENTIDADE ASSOCIATIVA
A entidade associativa surge de um relacionamento de N para N, no qual existe uma
associação dos atributos identificadores das duas entidades relacionadas,
caracterizando uma nova entidade. A nova entidade gerada possui, normalmente,
atributos próprios do relacionamento, isto é, ela só existe por causa do
relacionamento.
Tomando-se como exemplo, novamente, uma clínica médica, observamos o
seguinte:
• Um médico pode consultar N pacientes.
• Um paciente pode ser consultado por N médicos.
• Uma consulta é realizada em uma data e em um horário; possui um preço; pode
ser paga por convênio ou pelo paciente; apresenta uma prescrição do médico e a
relação de medicamentos. Esses são alguns atributos que pertencem apenas ao
relacionamento CONSULTA.
Toda entidade possui um atributo identificador a partir do qual é feito o
relacionamento das entidades. Ele é único e identifica cada ocorrência da entidade.
No diagrama a seguir, os atributos identificadores são: CRM e ID_Paciente.
No caso dos relacionamentos de N para N, não é possível transportar o atributo
identificador de uma entidade para a outra que está relacionada, pois, assim,
estariam sendo repetidos dados desnecessários.
Nesse caso, cria-se uma terceira entidade, chamada consulta, contendo os
seguintes atributos: CRM, ID_Paciente, data e hora.
No banco de dados, procura-se escrever o dado uma única vez e relacioná-lo com
as demais entidades. Utilizando o exemplo da clínica médica, o nome de um médico
deve ser apenas uma ocorrência na tabela de médico dentro do banco de dados.
Embora a consulta tenha o médico responsável, não é necessário um atributo nome
do médico, devemos substituí-lo por seu CRM, pois esse atributo o identifica dentro
da entidade MEDICO. Do mesmo modo, o nome do paciente não precisa estar na
entidade CONSULTA.
Transformamos um relacionamento de duas entidades de N para N acrescentando
uma entidade e desmembrando o relacionamento.
Os atributos identificadores CRM e ID_PACIENTE são transportados para a nova
entidade CONSULTA, acrescentando os outros atributos pertencentes à consulta.
Ao ligarmos as duas entidades, é possível notar que a cardinalidade deixa de ser de
N para N.
Cada médico pode fazer N consultas, mas uma consulta é feita com apenas 1
médico.
Cada paciente pode fazer N consultas, mas cada consulta é feita com apenas 1
paciente.
A entidade CONSULTA é formada por identificadores de outras entidades, portanto,
trata-se de uma entidade dependente, pois ela não existiria se não houvesse o
relacionamento.
A entidade gerada por atributos identificadores de outras entidades também é
chamada de entidade fraca.
A entidade fraca é identificada graficamente pelo retângulo de linha dupla, embora
alguns autores prefiram utilizar a linha que liga a entidade ao relacionamento, em
negrito. Observe os diagramas a seguir:
ou
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 08
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 8
OBJETIVO
Apresentar a próxima etapa da modelagem de dados: o modelo lógico e os
conceitos de tabelas, chaves primárias e estrangeiras e como o banco de dados
mantém controle sobre os dados relacionados.
MODELO LÓGICO: TABELAS, CHAVES PRIMÁRIAS E
ESTRANGEIRAS
A próxima etapa do projeto de banco de dados envolve o chamado modelo lógico.
Atualmente, grande parte dos sistemas de banco de dados utiliza o modelo
relacional . Um banco de dados relacional é composto por tabelas (também
denominadas relações).
Observe a seguir alguns conceitos importantes para pleno entendimento do modelo
relacional:
Tabela
Estrutura bidimensional composta por linhas (tuplas) e campos (ou atributos).
Chave primária
Atributo por meio do qual é possível identificar determinado registro. Uma chave
primária não pode ser repetida, ou seja, o conjunto de valores que constituem a
chave primária deve ser único dentro de uma tabela.
Chave primária simples: apenas um atributo (campo) compõe a chave primária.
Chave primária composta: mais de um atributo compõe a chave primária.
Na aula anterior falamos sobre atributo identificador, responsável por identificar uma
ocorrência na entidade. Trata-se de um atributo em que não se encontra duplicidade
de dados. O atributo identificador corresponde normalmente à chave primária no
modelo lógico (relacional).
Portanto, para escolher uma chave primária é preciso certificar-se de que esse
atributo não terá duplicidade.
Chave estrangeira
Utilizada quando queremos que o valor de um atributo seja validado a partir do valor
de atributo de outra tabela. Criamos, assim, uma relação de dependência (um
relacionamento) entre as tabelas.
Observe que, no exemplo a seguir, antes de efetuar a alocação de um funcionário
em um departamento, é necessário que o departamento em questão conste na
tabela de departamentos.
Para que haja equivalência, o conteúdo da chave estrangeira deve ser igual ao da
chave primária. O SGBD (Sistema de Gerenciamento de Banco de Dados) “liga”
todos os registros em que o conteúdo da chave primária seja igual ao de sua chave
estrangeira.
Acesse o ambiente virtual de aprendizagem UNINOVE para a visualização do
Infográfico sobre chave estrangeira.
Chave única (Unique)
Utilizada quando determinado campo não deve ser repetido e não é chave primária.
Aumenta a consistência do banco de dados.
Exemplo: cadastro de funcionários. Cada funcionário recebe um código único, que é
a chave primária. Para maior segurança e consistência, podemos optar para que o
campo CPF também seja único, evitando que o mesmo funcionário seja cadastrado
duas vezes.
Notação resumida
Notação compacta, útil para discussões sobre a estrutura geral do banco de dados,
utilizada quando não se deseja entrar em um nível maior de detalhamento.
Para simplificar a representação da modelagem relacional, podemos utilizar o
esquema resumido da seguinte maneira:
1. Escrever o nome da entidade e, entre parênteses, todos os atributos, chave
primária e chaves estrangeiras (se houver).
2. Sublinhar a chave primária.
3. Na linha abaixo à da entidade devem ser referenciadas todas as chaves
estrangeiras e a entidade com as quais se relacionam.
O exemplo apresentado anteriormente poderia ser representado utilizando-se a
notação resumida da seguinte forma:
Departamento (CodDept
Funcionario (
, Nome)
CodFunc
CodDept referencia Departamento
, Nome, CPF, CodDept)
O relacionamento entre as tabelas Departamento e Funcionario também pode ser
representado por meio do seguinte diagrama:
Observe que por meio da notação resumida não é possível determinar se o
relacionamento é do tipo 1:1 ou 1:N (como no caso representado na figura acima).
Chave alternativa
É aquela chave que poderia, por causa de suas características, ser chave primária,
mas não é. Ela é única na entidade, assim como a chave primária, e pode ser
considerada uma chave secundária.
Podemos considerar chave alternativa o CPF. No mundo real, é o que identifica
qualquer pessoa física.
Escolha da chave primária
Geralmente, a chave primária é um número criado pela aplicação – costuma-se
utilizar um recurso de numeração automática do próprio banco de dados, de modo
que o número não se repita.
Se a chave primária é muito grande, está sujeita a erros de digitação.
Um nome de pessoa pode ser considerado uma chave primária? O maior problema
do nome é que duas ou mais pessoas podem apresentar o mesmo nome
(homônimos) e a chave deve ser única para cada registro de dados.
As pessoas podem ter os mesmos nome e sobrenome, mas o RG e CPF são
diferentes, entretanto, são números muito grandes, por isso, é costume escolher
outros identificadores como chaves primárias.
Integridade de dados
Impor a integridade de dados garante a qualidade destes em um banco de dados.
Eles devem refletir corretamente a realidade representada pelo banco e também
devem ser consistentes entre si. A integridade de dados deve ser implementada de
diversas formas em um banco de dados.
• Integridade de domínio
Zela pelos valores ideais e necessários para um atributo. Para isso, definimos
algumas regras de validação por meio de expressões compostas de valores
constantes. Exemplos:
• Não permitir um estoque negativo.
• Impedir uma data de nascimento superior à data atual.
• Não permitir que o valor de um produto seja negativo.
• Integridade de entidade
Tem o objetivo de validar os valores permitidos a partir de valores já inseridos na
própria entidade. Após uma “autoconsulta” a entidade vai permitir ou não a gravação
do novo registro. Exemplos:
• Não permitir duas pessoas com o mesmo CPF.
• Impedir a locação de uma fita que já está locada.
• Integridade referencial
Zela pela consistência dos registros de uma entidade a partir de valores
provenientes de outras entidades, isto é, determinado registro vai “depender”
diretamente de um registro de outra tabela. Exemplos:
• Um registro em uma tabela pai pode ter um ou mais registros em uma
tabela filho.
• Um registro em uma tabela filho sempre tem um registro coincidente em
uma tabela pai.
• Para a inclusão de um registro em uma determinada tabela filho, é
necessário que exista um registro pai coincidente.
• Um registro pai só poderá ser excluído se não possuir nenhum registro
filho.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 09
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 9
OBJETIVO
Conhecer e aplicar as regras utilizadas durante o processo de conversão do modelo
conceitual para o modelo lógico (relacional).
REGRAS DE DERIVAÇÃO DO MODELO CONCEITUAL
PARA O LÓGICO
Introdução
A construção de um modelo não é tarefa a ser executada uma única vez.
Gradativamente, são acrescentados novos conceitos aos já existentes,
aperfeiçoando o modelo.
Na prática, observa-se que nenhuma das estratégias propostas na literatura é
universalmente aceita. Normalmente, é aplicada uma construção das diversas
estratégias de modelagem (HEUSER, 1999).
A modelagem pode surgir da descrição de dados já existentes ou a partir do
conhecimento do mundo real relatado pelas pessoas envolvidas.
No caso de a modelagem estar baseada em dados já existentes, é utilizada a
engenharia reversa.
A engenharia reversa utiliza a estratégia botton-up (de baixo para cima), ou seja,
inicia a modelagem a partir das tabelas de dados já formatados no mundo real e
adapta-os, segundo as regras de normalização, até chegar ao modelo conceitual.
Quando a modelagem é feita por meio de uma análise de requisitos, em que a
descrição do mundo real é elaborada a partir daquilo que as pessoas conhecem a
respeito da realidade a ser moldada, podem ser adotadas duas estratégias: top-
down (de cima para baixo) ou inside-up (de dentro para fora) (HEISER,1999).
Top-down
Partindo de uma análise de requisitos, é possível identificar as entidades envolvidas
do mundo real e criar o primeiro modelo conceitual, definindo os relacionamentos e a
cardinalidade máxima.
Em uma próxima etapa, colocam-se as cardinalidades mínimas e atributos e
desmembram-se as entidades associativas dos relacionamentos de N:N.
Em seguida, realiza-se um teste de validação dos modelos, a partir de dados
fictícios, simulando a realidade. O usuário deve participar deste teste.
Inside-up
Parte de uma ideia central em que são definidas as principais entidades que se
relacionam no mundo real e, em seguida, são desenhadas no centro do modelo. A
partir dele, desenha-se o detalhamento, ampliando os relacionamentos, assim como
no modelo top-down.
Na primeira etapa, desenha-se o modelo conceitual com os relacionamentos e a
cardinalidade máxima, a generalização e especialização e os relacionamentos
ternários.
Na segunda, inserem-se os novos relacionamentos que surgem da ideia central e
acrescenta-se as entidades associadas aos relacionamentos de N:N. Em seguida,
coloca-se todos os atributos comuns.
A terceira etapa é o teste de validação, assim como no top-down.
Modelagem relacional
A modelagem relacional é a representação do modelo conceitual em forma de
tabela, com seus atributos, contendo dados fictícios que simulam a parte do mundo
real a ser modelada.
Tomando como exemplo o modelo conceitual do consultório médico, temos:
Passando para o modelo lógico (relacional) teremos o seguinte diagrama:
PK – Representa a chave primária.
FK – Representa a chave estrangeira.
Podemos utilizar a notação resumida (também chamada de esquema resumido)
para representar a mesma situação:
Medico (CRM
Paciente (
, Nome)
ID_Paciente
Consulta (
, Nome)
CRM, IdPaciente, Data, Hora
CRM referencia Medico
)
Id_Paciente referencia Paciente
As tabelas a seguir estão representadas com exemplos de dados. É possível notar
que elas foram preenchidas com suas chaves primárias e as chaves estrangeiras
correspondentes da tabela relacionada.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 10
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 10
OBJETIVO
Apresentar como efetuar a derivação do modelo conceitual para o modelo lógico
para os relacionamentos binários, ternários e autorrelacionamentos.
DERIVAÇÃO DO MODELO CONCEITUAL PARA O LÓGICO
PARA OS DIVERSOS GRAUS DE RELACIONAMENTOS
Introdução
Antes de apresentar como deve ser feita a derivação dos modelos conceituais para
os lógicos (relacionais), vamos revisar alguns conceitos sobre as chaves utilizadas
em bancos de dados relacionais.
• Chave Primária (PK – Primary Key)
Atributo por meio do qual é possível identificar determinado registro. O conjunto de
valores que constituem a chave primária deve ser único dentro de uma tabela.
• Chave estrangeira (FK – Foreign Key)
Utilizada quando queremos que o valor de um atributo seja validado a partir do valor
de atributo de outra tabela. Criamos assim uma relação de dependência (um
relacionamento) entre as tabelas.
• Chave única (unique)
Utilizada quando determinado campo não deve ser repetido e não é chave primária.
Aumenta a consistência do banco de dados.
Há ainda outro tipo de restrição muito utilizado em bancos de dados relacionais:
NOT NULL (não nulo), utilizado quando todos os valores relacionados a
determinado atributo são obrigatórios, ou seja, não nulos ou não “vazios”.
A partir da compreensão desses conceitos, podemos agora apresentar como deve
ser feita a derivação entre os modelos (lógico e relacional).
Nota: Consulte a aula 5 para uma revisão dos graus de relacionamento.
Utilizamos as seguintes abreviações na representação dos modelos conceituais e
lógicos.
A, B e C – Entidades e tabelas.
X, Y e Z – Atributos identificadores nas entidades e chaves primárias e/ou
estrangeiras nas tabelas.
PK – Primary Key (chave primária).
FK – Foreign Key (chave estrangeira).
Portanto, A, B e C podem representar qualquer conjunto de entidades presentes em
um relacionamento, por exemplo, cliente, pedido, produto etc.
Nota: Abaixo das entidades relacionadas são apresentadas as respectivas tabelas
que devem ser geradas a partir do processo de derivação entre os modelos.
Relacionamentos binários 1:1
As soluções são diversas para os relacionamentos 1:1, por exemplo, quando a
cardinalidade máxima for 1,1 nos dois sentidos, a solução mais comum é unir as
duas entidades em uma única tabela.
Relacionamentos binários 1:N
Observe que nos relacionamentos 1:N a chave primária sempre ficará do lado em
que a cardinalidade for N.
Relacionamentos binários N:N
Quando efetuamos o mapeamento para o modelo lógico de relacionamentos N:N,
devemos construir uma tabela associativa composta pelas chaves primárias das
duas tabelas (A e B). Os dois atributos (X e Y) formarão a chave primária (composta)
da nova tabela (AB).
Relacionamento com atributo identificador
A solução é semelhante à anterior, porém o atributo identificador do relacionamento
(Z, no exemplo a seguir) também fará parte da chave primária na tabela associativa.
Relacionamentos ternários
Os relacionamentos entre três entidades requerem a construção de uma quarta
tabela que deverá conter as chaves primárias das três tabelas (A, B e C). Os três
atributos (X, Y e Z) formarão a chave primária composta da nova tabela (ABC).
Autorrelacionamentos 1:1
Neste tipo de autorrelacionamento, a chave estrangeira ficará na mesma tabela com
uma restrição do tipo unique (chave única) para garantir a cardinalidade 1:1.
Autorrelacionamentos 1:N
Neste outro tipo de autorrelacionamento, a chave estrangeira também ficará na
mesma tabela, porém não terá a restrição unique (chave única).
O diagrama apresentado a seguir demonstra que um funcionário supervisor pode ter
vários supervisionados, porém, cada funcionário supervisionado tem apenas um
supervisor.
Autorrelacionamentos N:N
Os autorrelacionamentos com grau de cardinalidade N:N requerem uma segunda
tabela na qual teremos uma chave primária composta.
O modelo conceitual a seguir apresenta uma entidade DISCIPLINA e por meio do
relacionamento PRE_REQUISITO procura-se demonstrar que algumas disciplinas
são pré-requisito para cursar outras, por exemplo: para cursar Cálculo 2 há como
pré-requisito cursar Cálculo 1.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 11
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
AULA 11
OBJETIVO
Apresentar os conceitos necessários para compreender o processo de normalização
de tabelas.
NORMALIZAÇÃO DE TABELAS: DEPENDÊNCIAS FUNCIONAIS
Normalização
A normalização envolve um conjunto de regras aplicadas em um banco de dados
com a finalidade de corrigir redundâncias, separando os dados até que seus
atributos apresentem valores atômicos, isto é, indivisíveis.
O conceito de normalização foi introduzido em 1970 por Edgard F. Codd e baseia-se
no processo matemático formal com fundamento na teoria dos conjuntos.
O processo de normalização aplica uma série de regras sobre as tabelas de um
banco de dados para verificar se estas foram corretamente projetadas.
Objetivos da normalização de tabelas
Os objetivos principais da normalização de tabelas são os seguintes:
• Garantir a integridade dos dados, evitando que informações sem sentido sejam
inseridas.
• Organizar e dividir as tabelas da forma mais eficiente possível, diminuindo a
redundância e permitindo a evolução do banco de dados.
Formas normais
São seis as formas normais mais utilizadas:
• Primeira Forma Normal (1FN).
• Segunda Forma Normal (2FN).
• Terceira Forma Normal (3FN).
• Forma Normal de Boyce e Codd (FNBC).
• Quarta Forma Normal (4FN).
• Quinta Forma Normal (5FN).
Nota: Neste curso abordaremos as três primeiras formas normais, pois estas
atendem à maioria dos casos de normalização.
Uma forma normal engloba todas as anteriores, isto é, para que uma tabela esteja
na 2FN, ela obrigatoriamente deve estar na 1FN e assim por diante.
Normalmente, após a aplicação das regras de normalização, algumas tabelas
acabam sendo divididas em duas ou mais. Este processo colabora
significativamente para a estabilidade do modelo de dados e reduz
consideravelmente as necessidades de manutenção.
Antes de passarmos à parte prática, aplicando as regras conforme a 1FN, 2FN e
3FN, será necessário apresentar alguns conceitos fundamentais diretamente
relacionados às Formas Normais.
Dependência Funcional (DF)
Sempre que um atributo X identifica um atributo Y, dizemos que entre eles há uma
dependência funcional .
A representação é: X Y (lê-se X determina Y ou Y é dependente de X).
cidadeestado
Neste caso, estado é funcionalmente dependente de cidade ou ainda cidade
determina estado.
CIDADE ESTADOCampinas São PauloNatal Rio Grande do NorteNiteroi Rio de J aneiro
Transitividade
Se um atributo X determina Y e se Y determina Z, podemos dizer que X determina Z
de forma transitiva, isto é, existe uma dependência funcional transitiva de X para Z.
cidade estado
estado país
cidade país (cidade determina país de forma transitiva)
CIDADE ESTADO PAISCampinas São Paulo BrasilMiami Florida EUA
Dependência funcional ir redutível à esquerda
O lado esquerdo de uma dependência funcional é irredutível quando o determinante
está em sua forma mínima, isto é, quando não é possível reduzir a quantidade de
atributos determinantes sem perder a dependência funcional.
{cidade, estado} país Não está na forma irredutível à esquerda, pois
podemos ter somente o estado como determinante.
estado país Está na forma irredutível à esquerda.
CIDADE ESTADO PAIS ESTADO PAISCampinas São Paulo Brasil São Paulo BrasilMiami Florida EUA Florida EUA
Dependência Multivalorada (DMV)
A DMV é uma ampliação da Dependência Funcional (DF). Na DMV, o valor de um
atributo determina um conjunto de valores de outro atributo.
É representada por X Y (X multidetermina Y ou Y é multidependente de X).
DF: {CPF}{Nome} Temos somente um nome para cada CPF
DMV: {CPF}{Dependente} Temos vários dependentes para cada CPF
CPF DEPENDENTE
111222333-00Antonio SantosBeatriz SantosClaudio Santos
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 12
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 12
OBJETIVO
Apresentar os principais conceitos de normalização de banco de dados envolvendo
a Primeira Forma Normal (1FN).
NORMALIZAÇÃO DE BANCO DE DADOS:
PRIMEIRA FORMA NORMAL
Introdução
Conforme você aprendeu na aula anterior, a normalização envolve um conjunto de
regras aplicadas em um banco de dados com a finalidade de corrigir redundâncias,
separando os dados até que seus atributos apresentem valores atômicos, isto é,
indivisíveis.
Nesta e nas próximas duas aulas abordaremos as seguintes formas normais:
• Primeira Forma Normal (1FN).
• Segunda Forma Normal (2FN).
• Terceira Forma Normal (3FN).
Primeira Forma Normal (1FN)
Uma tabela se encontra na Primeira Forma Normal (1FN) quando não possui
tabelas aninhadas, ou seja, quando uma ocorrência de uma tabela possui dentro
dela um subconjunto de atributos multivalorados, isto é, com mais de um valor,
caracterizando outra tabela interna.
Para que uma tabela esteja na 1FN, é necessário que cada atributo de uma
ocorrência tenha apenas um valor.
Observe o seguinte exemplo:
Uma empresa de engenharia utiliza os formulários apresentados a seguir para
controle de seus projetos:
PROJETO PROJETO
NR_PROJ 001 NR_PROJ 002
NOME_PROJ Alfa NOME_PROJ Beta
LOCAL_PROJ São Paulo LOCAL_PROJ Jundiaí
ID_FUNC NOME_FUNC CARGO VL_HORA ID_FUNC NOME_FUNC CARGO VL_HORA
101 Antonio Analista Pleno 35,00 102 Beatriz Analista Pleno 35,00
102 Beatriz Analista Pleno 35,00 103 Claudio Analista Senior 35,00
103 Claudio Analista Senior 50,00 104 Daniela Analista Senior 50,00
Para registrar os dados dos seus projetos, a empresa adotou planilhas eletrônicas
com a seguinte estrutura:
NR_PROJ NOME_PROJ LOCAL_PROJ ID_FUNC NOME_FUNC CARGO VL_HORA
001 Alfa São Paulo
101 Antonio Alves Analista Pleno 35,00
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
002 Beta J undiaí
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
104 Daniela Dantas Analista Senior 50,00
No entanto, à medida que a quantidade de projetos e funcionários alocados neles
cresceu, observou-se que seria necessário utilizar um sistema de banco de dados.
Para garantir a integridade e controlar a redundância dos dados, aplicou-se à tabela
acima a Primeira Forma Normal (1FN).
A tabela para controle de projetos apresenta a seguinte tabela aninhada:
ID_FUNC NOME_FUNC CARGO VL_HORA
101 Antonio Alves Analista Pleno 35,00
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
104 Daniela Dantas Analista Senior 50,00
Não se deve simplesmente separar a tabela acima do restante da tabela de controle
de projetos, porque, neste caso, não seria mais possível determinar em quais
projetos cada funcionário trabalhou. Para que isso não ocorra, é preciso incluir a
coluna NR_PROJ na tabela que será denominada PROJ ETO_FUNCIONARIO:
PROJETO_FUNCIONARIO
NR_PROJ ID_FUNC NOME_FUNC CARGO VL_HORA
001 101 Antonio Alves Analista Pleno 35,00
001 102 Beatriz Bernardes Analista Pleno 35,00
001 103 Claudio Cardoso Analista Senior 50,00
002 102 Beatriz Bernardes Analista Pleno 35,00
002 103 Claudio Cardoso Analista Senior 50,00
002 104 Daniela Dantas Analista Senior 50,00
Consequentemente, a segunda tabela (PROJ ETO) apresentará a seguinte estrutura:
PROJETO
NR_PROJ NOME_PROJ LOCAL_PROJ
001 Alfa São Paulo
002 Beta J undiaí
Observe que após a aplicação da Primeira Forma Normal (1FN) não temos mais
tabelas aninhadas. Outro detalhe: os usuários terão acesso às mesmas informações
anteriormente disponibilizadas na tabela que não estava na Primeira Forma Normal.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 13
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 13
OBJETIVO
Apresentar os principais conceitos de normalização de banco de dados envolvendo
a Segunda Forma Normal.
NORMALIZAÇÃO DE BANCO DE DADOS: SEGUNDA FORMA
NORMAL
2FN – Segunda Forma Normal
Uma tabela está na Segunda Forma Normal (2FN) quando, além de estar na
Primeira Forma Normal (1FN), não contém dependências parciais .
Uma dependência funcional parcial ocorre quando uma coluna que não faz parte da
chave primária depende apenas de uma parte da chave primária COMPOSTA (veja
o tópico da aula 11: “Dependência funcional irredutível à esquerda”).
Sendo assim, toda tabela que está na Primeira Forma Normal e que possui chave
primária SIMPLES (formada por uma coluna) já está na Segunda Forma Normal.
Analisando a tabela PROJ ETO_FUNCIONARIO (veja aula anterior), nota-se que as
colunas (ou atributos) NOME_FUNC, CARGO e VL_HORA dependem apenas de
uma parte da chave primária, ou seja, do ID_FUNC.
PROJETO_FUNCIONARIO
NR_PROJ ID_FUNC NOME_FUNC CARGO VL_HORA
001 101 Antonio Alves Analista Pleno 35,00
001 102 Beatriz Bernardes Analista Pleno 35,00
001 103 Claudio Cardoso Analista Senior 50,00
002 102 Beatriz Bernardes Analista Pleno 35,00
002 103 Claudio Cardoso Analista Senior 50,00
002 104 Daniela Dantas Analista Senior 50,00
Portanto, ao aplicarmos a Segunda Forma Normal (2FN), teremos:
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO VL_HORA
101 Antonio Alves Analista Pleno 35,00
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
104 Daniela Dantas Analista Senior 50,00
A tabela PROJ ETO_FUNCIONARIO apresentará a seguinte estrutura após a
aplicação da Segunda Forma Normal (2FN):
PROJETO_FUNCIONARIO
NR_PROJ ID_FUNC
001 101
001 102
001 103
002 102
002 103
002 104
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 14
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
AULA 14
OBJETIVO
Apresentar os principais conceitos de normalização de banco de dados envolvendo
a Terceira Forma Normal.
NORMALIZAÇÃO DE BANCO DE DADOS:
TERCEIRA FORMA NORMAL
Terceira Forma Normal (3FN)
Uma tabela está na Terceira Forma Normal (3FN) quando, além de estar na 2FN
(Segunda Forma Normal), não contém dependências transitivas .
Uma dependência funcional transitiva ocorre quando uma coluna, além de depender
da chave primária da tabela, depende diretamente de outra(s) coluna(s) da tabela.
(veja o tópico da aula 11: “Dependência Funcional Transitiva”).
A tabela FUNCIONARIO apresenta uma dependência funcional transitiva. Observe
que o VL_HORA não depende diretamente do ID_FUNC. VL_HORA depende
diretamente do CARGO.
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO VL_HORA
101 Antonio Alves Analista Pleno 35,00
102 Beatriz Bernardes Analista Pleno 35,00
103 Claudio Cardoso Analista Senior 50,00
104 Daniela Dantas Analista Senior 50,00
Portanto, ao aplicar-se a Terceira Forma Normal (3FN), teremos uma tabela que
pode ser denominada CARGO_SALARIO com a seguinte estrutura:
CARGO_SALARIO
CARGO VL_HORA
Analista Pleno 35,00
Analista Senior 50,00
A tabela FUNCIONARIO, após a aplicação da Terceira Forma Normal, apresentará a
estrutura a seguir:
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO
101 Antonio Alves Analista Pleno
102 Beatriz Bernardes Analista Pleno
103 Claudio Cardoso Analista Senior
104 Daniela Dantas Analista Senior
Observe, a seguir, quais foram as tabelas geradas após a aplicação das três
primeiras Formas Normais (FN1, FN2 e FN3) e compare com a tabela controle de
projeto anteriormente apresentada (veja aula 12).
PROJETO
NR_PROJ NOME_PROJ LOCAL_PROJ
001 Alfa São Paulo
002 Beta J undiaí
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO
101 Antonio Alves Analista Pleno
102 Beatriz Bernardes Analista Pleno
103 Claudio Cardoso Analista Senior
104 Daniela Dantas Analista Senior
PROJETO_FUNCIONARIO
NR_PROJ ID_FUNC
001 101
001 102
001 103
002 102
002 103
002 104
CARGO_SALARIO
CARGO VL_HORA
Analista Pleno 35,00
Analista Senior 50,00
Importante
O exemplo apresentado tem objetivo exclusivamente didático para esclarecimento
dos conceitos envolvidos na aplicação de cada uma das três primeiras Formas
Normais. Outros detalhes deveriam ser levados em consideração para o
desenvolvimento de um sistema completo, por exemplo, armazenar os valores
históricos dos salários, quantidade de horas de cada funcionário nos respectivos
projetos etc.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de
dados. São Paulo: Berkeley Brasil, 2002.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 15
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
Aula 15: Álgebra relacional – seleção e projeção
OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações
de seleção e projeção.
Introdução
Até o presente momento, aprendemos a construção de um banco de dados
com suas formas de modelagem, que auxiliam a compreender o modo como os
dados estão distribuídos dentro de um SGBD (Sistema de Gerenciamento de Banco
de Dados). Utilizamos também suas regras de normalização com a engenharia
reversa para eliminar as redundâncias e facilitar os meios de acesso aos dados.
Os processos de busca dos dados estão fundamentados na álgebra
relacional.
Trata-se de uma linguagem formal utilizada nos SGBDs para consultar os
dados solicitados por um usuário. Essa linguagem possui um conjunto de operações
baseadas na teoria de conjuntos, que permite selecionar, unir, subtrair e projetar um
conjunto de dados relacionados.
O resultado de uma consulta é visto como um conjunto de tuplas (grupos de
dados pertencentes a uma linha de uma tabela).
As operações primitivas que utilizam a álgebra relacional são:
• Seleção
• Projeção
• Produto cartesiano
• União
• Diferença
As operações derivadas que utilizam a álgebra relacional são:
• Intersecção
• J unção (normal e natural)
• Divisão
Seleção σ
Indicada pela letra grega σ (sigma), esta operação produz uma nova relação
apenas com as tuplas (linhas) da primeira relação (tabela), que satisfazem a uma
determinada condição (também chamada de predicado).
A sintaxe básica é a seguinte:
σ predicado (relação)
Observe a tabela (relação) a seguir:
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO
101 Antonio Alves Analista Pleno
102 Beatriz Bernardes Analista Pleno
103 Claudio Cardoso Analista Senior
104 Daniela Dantas Analista Senior
Para efetuar a seleção do funcionário cujo ID_FUNC = 102, devemos utilizar
a seguinte expressão:
σ ID_FUNC=102 (FUNCIONARIO)
A execução desta operação produzirá uma tabela ou relação que atende à
condição ID_FUNC = 102. Observe:
ID_FUNC NOME_FUNC CARGO
102 Beatriz Bernardes Analista Pleno
Projeção π
Esta operação, indicada pela letra grega π (pi), produz uma nova relação ou
tabela com apenas alguns atributos da primeira relação, removendo as tuplas
duplicadas.
A sintaxe básica é a seguinte:
π nome da coluna, nome da coluna (relação)
Tomando-se ainda como base a tabela FUNCIONARIO, para efetuar a
projeção da coluna NOME_ FUNC devemos utilizar a seguinte expressão:
π CARGO (FUNCIONARIO)
A execução desta operação produzirá a tabela ou relação a seguir:
FUNCIONARIO
CARGO
Analista Pleno
Analista Senior
Note que as tuplas (linhas) repetidas foram removidas.
Veja agora como efetuar a projeção das colunas ID_FUNC e NOME_FUNC:
π ID_FUNC, NOME_FUNC (FUNCIONARIO)
A relação produzida pela expressão acima é a seguinte:
ID_FUNC NOME_FUNC
101 Antonio Alves
102 Beatriz Bernardes
103 Claudio Cardoso
104 Daniela Dantas
Podemos também aplicar as operações de seleção e projeção em
determinada relação ou tabela. No exemplo a seguir foi aplicada uma operação de
seleção para obter-se a tupla (linha) cujo ID_FUNC = 102 e depois uma operação de
projeção sobre a coluna NOME_FUNC.
π NOME_FUNC (σ ID_FUNC=102 (FUNCIONARIO))
O resultado da expressão acima é o seguinte:
NOME_FUNC
Beatriz Bernardes
Na próxima aula abordaremos outra operação da álgebra relacional: o
produto cartesiano.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de
dados. São Paulo: Berkeley Brasil, 2002.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 16
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
Aula 16: Álgebra relacional – produto cartesiano
OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações
de produto cartesiano.
Produto cartesiano X
O produto cartesiano (representado por X) de duas tabelas ou relações é uma
terceira relação contendo todas as combinações possíveis entre as tuplas (linhas) da
primeira e as tuplas da segunda tabela.
A sintaxe básica é a seguinte:
(relação 1) X (relação2)
A figura a seguir demonstra como é realizada a operação entre duas tabelas
genéricas TABELA_1 e TABELA_2:
Concluímos, portanto, que o produto cartesiano de uma tabela formada por
três colunas e quatro linhas com outra formada por duas colunas e três linhas será
uma terceira tabela com a seguinte estrutura:
3 colunas + 2 colunas =5 colunas
4 linhas x 3 linhas =12 linhas
Analisaremos agora um exemplo prático. Imagine que em determinado
campeonato de futebol entre os principais times dos estados de São Paulo e do Rio
de J aneiro foram formados dois grupos com quatro times em cada grupo. Os times
de um estado deverão enfrentar os times do outro. Aplicando-se a operação da
álgebra relacional denominada produto cartesiano teremos:
O produto cartesiano, embora na prática não tenha muitas aplicações diretas,
é uma forma primitiva utilizada para juntar informações de duas tabelas para
posterior processamento.
A operação de junção, conforme veremos nas aulas seguintes, é uma
derivação do produto cartesiano. Aplica-se, neste caso, uma operação de seleção
para obter apenas as combinações que realmente interessam.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de
dados. São Paulo: Berkeley Brasil, 2002.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 17
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns dediscussão e a comunicação com o professor devem ser feitos diretamente no ambientevirtual de aprendizagem UNINOVE.
Uso consciente do papel.Cause boa impressão, imprima menos.
Aula 17: Álgebra relacional – união, di ferença e intersecção
OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações
de união, diferença e intersecção.
União U
O resultado da união entre duas relações ou tabelas gera uma terceira
relação com todas as tuplas (linhas) comuns e não comuns.
As tuplas comuns às duas relações aparecerão apenas uma vez no resultado.
As duas relações devem ter o mesmo número de atributos (colunas) e
mesmos domínios para as colunas correspondentes.
A sintaxe básica é a seguinte:
(relação 1) U (relação 2)
A figura a seguir demonstra como é realizada a operação de união entre duas
tabelas genéricas TABELA_1 e TABELA_2:
Diferença -
A diferença entre duas relações produz uma nova relação com todas as
tuplas da primeira relação que não aparecem na segunda relação.
As duas relações devem ter o mesmo número de atributos (colunas) e
mesmos domínios para as colunas correspondentes.
A sintaxe básica é a seguinte:
(relação 1) - (relação 2)
A figura a seguir demonstra como é realizada a operação de diferença entre
duas tabelas genéricas TABELA_1 e TABELA_2:
É importante enfatizar que, se invertermos as tabelas, o resultado não será o
mesmo; a operação não é comutativa. Exemplificando, poderíamos dizer que:
(relação 1) - (relação 2) é diferente de (relação 2) - (relação 1)
Observe a seguir o resultado de (TABELA_2) – (TABELA_1):
Intersecção ∩
A intersecção entre duas relações produz uma nova relação entre a primeira
entidade e a segunda, em que somente aparecerão as tuplas em comum escritas
uma única vez.
Neste caso, as duas relações também devem ter o mesmo número de
atributos e mesmos domínios para as colunas correspondentes.
A sintaxe básica é a seguinte:
(relação 1) ∩ (relação 2)
A figura a seguir demonstra como é realizada a operação de intersecção
entre duas tabelas genéricas TABELA_1 e TABELA_2:
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 18
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
Aula 18: Álgebra relacional – junção e divisão
OBJETIVO: Apresentar os conceitos de álgebra relacional envolvendo as operações
de junção normal e junção natural e divisão.
Junção
A operação denominada junção combina as operações de seleção e produto
cartesiano produzindo uma combinação entre as tuplas de uma tabela com as tuplas
correspondentes de outra tabela que obedecem a uma condição.
A sintaxe básica é a seguinte:
σ relaçãoA.chave1=relaçãoB.chave2 ( relação A X relação B )
A figura a seguir demonstra como é realizada a operação de junção entre
duas tabelas DEPARTAMENTO e FUNCIONARIO:
DEPARTAMENTO FUNCIONARIO
CODDEPT NOMEDEPT IDFUNC NOMEFUNC CODDEPT
D1 Engenharia 101 Antonio Alves D2
D2 Comercial 102 Beatriz Bernardes D1
103 Claudio Cardoso D2
104 Daniela Dantas D1
σ DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT (DEPARTAMENTO X FUNCIONARIO)
CODDEPT NOMEDEPT IDFUNC NOMEFUNC CODDEPT
D1 Engenharia 102 Beatriz Bernardes D1
D1 Engenharia 104 Daniela Dantas D1
D2 Comercial 101 Antonio Alves D2
D2 Comercial 103 Claudio Cardoso D2
A operação de junção foi criada justamente porque esse tipo de combinação
de tabelas é de uso muito comum, facilitando, assim, a escrita de expressões. A
tabela resultante de uma junção tem todas as colunas da primeira tabela e todas da
segunda tabela. Isso faz os valores dos campos utilizados como critério para a
correspondência entre as linhas aparecerem duplicados, já que um vem da primeira
tabela e outro da segunda.
Junção natural |X|
Existe uma variação da junção, chamada junção natural, que fornece o
mesmo resultado, mas sem essa repetição de valores: uma das colunas
correspondentes aos atributos de relacionamento é descartada.
A sintaxe básica é a seguinte:
( relação A |X| relação B )
A figura a seguir demonstra como é realizada a operação de junção natural
entre as duas tabelas anteriores (DEPARTAMENTO e FUNCIONARIO):
(DEPARTAMENTO |x| FUNCIONARIO)
CODDEPT NOMEDEPT IDFUNC NOMEFUNC
D1 Engenharia 102 Beatriz Bernardes
D1 Engenharia 104 Daniela Dantas
D2 Comercial 101 Antonio Alves
D2 Comercial 103 Claudio Cardoso
NOTA: A simbologia utilizada para junção normal e junção natural pode apresentar
variações conforme a bibliografia consultada.
Divisão
Produz uma nova tabela ou relação contendo todas as tuplas da primeira
tabela (dividendo) que aparecem na segunda (mediador) com todas as tuplas da
terceira tabela (divisor).
No exemplo apresentado a seguir, observa-se que a TABELA_S contém
todas as tuplas da TABELA_1 (dividendo) que aparecem na TABELA_R (mediador)
com todas as tuplas da TABELA_2 (divisor):
O próximo exemplo apresenta o mesmo dividendo (TABELA_1) e o mesmo
mediador (TABELA_R), mas agora há outro divisor (TABELA_2). Note o resultado:
As últimas quatro aulas (15, 16, 17 e 18) apresentaram as operações da
álgebra relacional. Conforme mencionado (na aula 15), trata-se de uma linguagem
formal utilizada nos Sistemas de Gerenciamento de Banco de Dados para consultar
os dados solicitados por um usuário. A linguagem possui um conjunto de operações
baseadas na teoria de conjuntos que permite selecionar, unir, subtrair e projetar um
conjunto de dados relacionados.
Para recordar:
As operações primitivas que utilizam a álgebra relacional são:
• Seleção
• Projeção
• Produto cartesiano
• União
• Diferença
As operações derivadas que utilizam a álgebra relacional são:
• Intersecção
• J unção (normal e natural)
• Divisão
Mas não foi apresentado ainda como aplicar estas operações utilizando-se
um Sistema de Gerenciamento de Banco de Dados. Esta importante etapa será
abordada nas duas últimas aulas.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 19
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
Aula 19: SQL – Seleção, projeção, produto cartesiano e junção
OBJETIVO: Apresentar as operações de seleção, projeção e junção com a
linguagem principal utilizada pelos bancos de dados relacionais.
SQL – Structured Query Language
SQL é atualmente a principal linguagem utilizada para realizar consultas e
manipulações de dados em Sistemas de Gerenciamento de Bancos de Dados
Relacionais.
A primeira versão da linguagem foi apresentada pela IBM em 1974 com o
nome Structured English Query Language (Sequel) e disponibilizada para um
protótipo de banco de dados relacional denominado SEQUEL-XRM.
Em 1977, a IBM lançou um novo protótipo denominado SYSTEM/R e, ao final
deste, havia desenvolvido uma linguagem que permitia acesso fácil a múltiplas
tabelas, uma linguagem de quarta geração (4GL), que passou a ser denominada de
SQL (Structured Query Language).
Alguns anos depois, em 1979, um grupo de desenvolvedores que havia
participado do projeto SYSTEM/R fundou uma empresa – a Relational Software Inc.
– responsável pelo lançamento do primeiro Sistema de Gerenciamento de Banco de
Dados Relacional comercialmente viável. Esta empresa mais tarde teve o seu nome
alterado para Oracle.
A linguagem SQL é composta basicamente por quatro subconjuntos:
• DDL – Data Definition Language
• DML – Data Manipulation Language
• DQL – Data Query Language
• DCL – Data Control Language
Durante o seu curso você terá outras disciplinas que abordarão com detalhes
cada um dos comandos utilizados pelos quatro subconjuntos da SQL.
No entanto, você terá agora a oportunidade de conhecer alguns comandos
relacionados ao que foi apresentado nas aulas anteriores quando foram listadas as
operações da álgebra relacional.
Seleção
Conforme observado na aula 15, esta operação, indicada pela letra grega σ
(sigma), produz uma nova relação ou tabela apenas com as tuplas (linhas) da
primeira relação que satisfazem a uma determinada condição (também chamada de
predicado).
Tomando-se como exemplo a seguinte tabela, para efetuar a seleção do
funcionário cujo ID_FUNC = 102, devemos utilizar a expressão:
σ ID_FUNC=102 (FUNCIONARIO)
FUNCIONARIO
ID_FUNC NOME_FUNC CARGO
101 Antonio Alves Analista Pleno
102 Beatriz Bernardes Analista Pleno
103 Claudio Cardoso Analista Senior
104 Daniela Dantas Analista Senior
A expressão acima pode ser escrita na linguagem SQL da seguinte forma:
SELECT * FROM FUNCIONARIO WHERE ID_FUNC = 102;
Observa-se, portanto, que nesta linguagem utilizamos a palavra reservada
SELECT no lugar da letra grega σ (sigma).
O símbolo * é utilizado quando queremos que sejam apresentados os dados
de todas as colunas da tabela.
A preposição FROM é utilizada antes de informarmos o nome da tabela
consultada: FUNCIONARIO.
Na sequência, temos a condição, isto é, queremos que sejam apresentados
os dados do funcionário cujo ID_FUNC é igual a 102. Expressamos isso com o
seguinte predicado: WHERE ID_FUC = 102.
A execução do comando acima produzirá o seguinte resultado:
ID_FUNC NOME_FUNC CARGO
102 Beatriz Bernardes Analista Pleno
Projeção
Muitas vezes não desejamos que sejam apresentados todos os dados que
satisfazem a determinada condição. No exemplo considerado, uma hipótese seria
apresentar apenas o NOME do funcionário cujo ID_FUNC é igual a 102.
Neste caso, devemos projetar a coluna. Na SQL informamos os nomes das
colunas que queremos projetar logo após o comando SELECT. Observe:
SELECT NOME_FUNC FROM FUNCIONARIO WHERE ID_FUNC = 102;
A execução do comando acima produzirá o seguinte resultado:
NOME_FUNC
Beatriz Bernardes
Para projetar mais de uma coluna, separamos seus nomes utilizando vírgulas:
SELECT NOME_FUNC, CARGO FROM FUNCIONARIO WHERE ID_FUNC = 102;
A execução do comando acima produzirá o seguinte resultado:
NOME_FUNC CARGO
Beatriz Bernardes Analista Pleno
Mas qual comando deve ser utilizado para projetar TODOS os nomes dos
funcionários? Neste caso, basta omitir a condição expressa no final. Observe:
SELECT NOME_FUNC FROM FUNCIONARIO;
A execução do comando acima produzirá o seguinte resultado:
NOME_FUNC
Antonio Alves
Beatriz Bernardes
Claudio Cardoso
Daniela Dantas
Produto cartesiano
O produto cartesiano de duas tabelas ou relações é uma terceira tabela
contendo todas as combinações possíveis entre as tuplas ou linhas da primeira e as
tuplas da segunda tabela.
Observe novamente o exemplo apresentado na aula 16, o produto cartesiano
das tabelas GRUPO_SP e GRUPO_RJ :
A representação, conforme a álgebra relacional, do produto cartesiano acima
é a seguinte:
(GRUPO_SP) X (GRUPO_RJ)
Quando trabalhamos com a SQL, o produto cartesiano de duas tabelas é
obtido por meio da operação denominada CROSS JOIN. Observe:
SELECT TIME_SP, TIME_RJ FROM GRUPO_SP CROSS JOIN GRUPO_RJ;
A operação de junção, conforme veremos a seguir, é uma derivação do
produto cartesiano.
Junção (normal)
A operação de junção utiliza as operações de seleção e produto cartesiano
para produzir uma combinação entre as tuplas (linhas) de uma tabela com as tuplas
correspondentes de outra tabela que obedecem a uma condição.
Observe novamente o exemplo apresentado na aula 18:
DEPARTAMENTO FUNCIONARIO
CODDEPT NOMEDEPT IDFUNC NOMEFUNC CODDEPT
D1 Engenharia 101 Antonio Alves D2
D2 Comercial 102 Beatriz Bernardes D1
103 Claudio Cardoso D2
104 Daniela Dantas D1
A junção entre as tabelas DEPARTAMENTO e FUNCIONARIO deve ser
representada, conforme notação da álgebra relacional, da seguinte forma:
σ DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT (DEPARTAMENTO X FUNCIONARIO)
O resultado produzido será o seguinte:
CODDEPT NOMEDEPT IDFUNC NOMEFUNC CODDEPT
D1 Engenharia 102 Beatriz Bernardes D1
D1 Engenharia 104 Daniela Dantas D1
D2 Comercial 101 Antonio Alves D2
D2 Comercial 103 Claudio Cardoso D2
A expressão acima pode ser escrita na linguagem SQL da seguinte forma:
SELECT * FROM DEPARTAMENTO, FUNCIONARIO
WHERE DEPARTAMENTO.CODDEPT = FUNCIONARIO.CODDEPT;
Junção (natural)
A junção natural fornece o mesmo resultado da junção normal, mas sem a
repetição de valores das colunas comuns às duas tabelas.
A junção natural entre as tabelas DEPARTAMENTO e FUNCIONARIO é
representada, conforme notação da álgebra relacional, da seguinte forma:
(DEPARTAMENTO |x| FUNCIONARIO)
Quando utilizamos a SQL, a junção natural de duas tabelas é obtida por meio
da operação denominadaNATURAL INNER JOIN. Observe:
SELECT * FROM DEPARTAMENTO NATURAL INNER JOIN FUNCIONARIO;
A figura a seguir demonstra o resultado da operação de junção natural entre
as duas tabelas anteriores (DEPARTAMENTO e FUNCIONARIO):
CODDEPT NOMEDEPT IDFUNC NOMEFUNC
D1 Engenharia 102 Beatriz Bernardes
D1 Engenharia 104 Daniela Dantas
D2 Comercial 101 Antonio Alves
D2 Comercial 103 Claudio Cardoso
Observamos nesta aula como utilizar a SQL (Structured Query Language)
para realizar as seguintes operações da álgebra relacional: seleção, projeção,
produto cartesiano e junção (normal e natural).
Na última aula desta disciplina abordaremos as outras operações da álgebra
relacional: união, diferença e intersecção.
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.
Modelagem de Dados
Aula 20
Os direitos desta obra foram cedidos à Universidade Nove de Julho
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de
discussão e a comunicação com o professor devem ser feitos diretamente no ambiente
virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Cause boa impressão, imprima menos.
Aula 20: SQL – União, di ferença e intersecção
OBJETIVO: Apresentar as operações de união, diferença e intersecção com a
linguagem principal utilizada pelos bancos de dados relacionais.
União (Union)
A união entre duas relações ou tabelas gera uma terceira tabela com todas as
tuplas ou linhas comuns e não comuns.
As tuplas comuns às duas relações aparecerão apenas uma vez no resultado.
As duas tabelas devem ter o mesmo número de atributos ou colunas e
mesmos domínios para as colunas correspondentes.
Na álgebra relacional, para efetuar a união das tabelas CLIENTE_1 e
CLIENTE_2, utilizamos a expressão:
(CLIENTE_1) U (CLIENTE_2)
Na SQL devemos utilizar o operador denominado UNION da seguinte forma:
SELECT CODIGO, NOME FROM CLIENTE_1
UNION
SELECT CODIGO, NOME FROM CLIENTE_2;
A execução do comando acima produzirá o seguinte resultado:
Diferença (Minus)
A diferença entre duas tabelas produz uma nova com todas as linhas da
primeira tabela que não aparecem na segunda.
As duas tabelas devem ter o mesmo número de colunas e mesmos domínios
para as colunas correspondentes.
Na álgebra relacional, para efetuar a diferença entre as tabelas CLIENTE_1 e
CLIENTE_2, utilizamos a expressão:
(CLIENTE_1) - (CLIENTE_2)
Na SQL devemos utilizar o operador denominado MINUS da seguinte forma:
SELECT CODIGO, NOME FROM CLIENTE_1
MINUS
SELECT CODIGO, NOME FROM CLIENTE_2;
A execução do comando acima produzirá o seguinte resultado:
NOTA: O Oracle, a partir da versão 10g, utiliza o operador MINUS. Outros Sistemas
de Gerenciamento de Banco de Dados, como o Microsoft SQL Server e o IBM DB2
utilizam em seu lugar o operador EXCEPT.
Devemos lembrar que a operação de diferença não é comutativa:
(CLIENTE_1) - (CLIENTE_2) é diferente de (CLIENTE_2) - (CLIENTE_1)
Observe a seguir o resultado de:
SELECT CODIGO, NOME FROM CLIENTE_2
MINUS
SELECT CODIGO, NOME FROM CLIENTE_1;
Intersecção (Intersect)
A intersecção entre duas tabelas produz uma nova tabela na qual somente
aparecerão as linhas em comum entre a primeira e a segunda tabela escritas uma
única vez.
Neste caso, as duas relações também devem ter o mesmo número de
atributos e mesmos domínios para as colunas correspondentes.
Na álgebra relacional, para efetuar a intersecção entre as tabelas
CLIENTE_1 e CLIENTE_2, utilizamos a expressão:
(CLIENTE_1) ∩ (CLIENTE_2)
Na SQL devemos utilizar o operador denominado INTERSECT da seguinte
forma:
SELECT CODIGO, NOME FROM CLIENTE_1
INTERSECT
SELECT CODIGO, NOME FROM CLIENTE_2;
A execução do comando acima produzirá o seguinte resultado:
As duas últimas aulas apresentaram uma breve introdução à SQL (Structured
Query Language). O principal objetivo foi comparar as operações da álgebra
relacional com os comandos SQL correspondentes.
Há, sem dúvida, muito mais a ser considerado sobre esta linguagem utilizada
pela maioria dos bancos de dados relacionais. Mas isto será assunto para outra
disciplina que será oferecida em um dos próximos semestres do seu curso. Aguarde!
REFERÊNCIAS
CHEN, Peter. Modelagem de dados: a abordagem entidade-relacionamento para
projeto lógico. São Paulo: Makron Books, 1990.
DATE, C. J . Introdução a sistemas de banco de dados. Rio de J aneiro: Campus,
1991.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed.
São Paulo: Pearson Addison Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto,
2004.
SETZER, Valdemar W.; SILVA, Flávio Soares Corrêa da. Banco de dados: aprenda
o que são, melhore seu conhecimento, construa os seus. São Paulo: Edgard
Blücher, 2005.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. 3. ed. São Paulo: Makron Books, 1999.