Modelagem de Dados.pdf

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


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




1991.




2004.

PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.



Blücher, 2005.



Modelagem de Dados

Aula 03




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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 04




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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 05








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




1991.




2004.

MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de

dados. São Paulo: Berkeley Brasil, 2002.



Blücher, 2005.



Modelagem de Dados

Aula 06








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




1991.




2004.

MULLER, Robert J . Projeto de Banco de Dados: Usando UML para modelagem de




Blücher, 2005.



Modelagem de Dados

Aula 07








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




1991.




2004.



Modelagem de Dados

Aula 08




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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 09




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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 10








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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 11




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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 12








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í



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







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 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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 13








AULA 13

OBJETIVO


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





002 104 Daniela Dantas Analista Senior 50,00

Portanto, ao aplicarmos a Segunda Forma Normal (2FN), teremos:

FUNCIONARIO






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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 14








AULA 14

OBJETIVO


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






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






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




1991.




2004.

MULLER, Robert J . Projeto de Banco de Dados: usando UML para modelagem de




Blücher, 2005.



Modelagem de Dados

Aula 15








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






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:



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.


π 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




1991.




2004.





Blücher, 2005.



Modelagem de Dados

Aula 16








Aula 16: Álgebra relacional – produto cartesiano


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.


(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




1991.




2004.





Blücher, 2005.



Modelagem de Dados

Aula 17




Aula 17: Álgebra relacional – união, di ferença e intersecção


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.


(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



(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.


(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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 18








Aula 18: Álgebra relacional – junção e divisão


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.


σ 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)


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.


( 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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 19








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






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:



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;


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;


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;


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


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:


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




1991.




2004.



Blücher, 2005.



Modelagem de Dados

Aula 20








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


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;


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:


MINUS



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:


MINUS


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:


INTERSECT



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




1991.




2004.



Blücher, 2005.



Documents

Modelagem de Dados.pdf