Você está na página 1de 61

Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense

Unidade: Computao e Sistemas


Prof. Eliana Caus Sampaio

Capitulo 4
MODELAGEM RELACIONAL DE DADOS

4.1 Processo de Desenvolvimento de Software 02


4.1.1 Software e Processo de Software 02
4.1.2 Ciclo de vida de um projeto 02

4.2 Abstrao de Dados 04

4.3 Modelagem Conceitual de Dados 07


4.3.1 Modelo 07
4.3.2 Motivos para a construo de modelos 07
4.3.3 Modelagem de dados 07
4.3.4 Formulao do Obvio 10
4.3.5 Entidade 11
4.3.6 Atributos 13
4.3.7 Relacionamentos 16
4.3.8 Notao a ser adotada 36
4.3.9 Dicionrio de Dados 37

4.4 Modelagem Lgica de Dados 40


4.4.1 Introduo 40
4.4.2 Propriedade do modelo relacional normalizado 41
4.4.3 Mapeamento do MCD para o MLD 41
4.4.4 Exemplo de Modelo Conceitual Entidades-Relacionamentos traduzido
para o Modelo Lgico Relacional 50

4.5 Normalizao 51
4.5.1 Anomalias de Modificao 51
4.5.2 Formas Normais 52

Bibliografia 61

Nesse capitulo voc conhecer os conceitos associados Modelagem de Dados a partir dos
conceitos de Entidades e Relacionamentos. Conhecer tambm uma tcnica para traduzir um
Modelo ER em um Modelo Lgico adequado a implementao em Bancos de Dados
Relacionais. E por fim, conhecer o processo de Normalizao de tabelas.

1/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

UNIDADE 4 MODELAGEM RELACIONAL DE DADOS

4.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Este capitulo tratar de uma srie de conceitos relacionados ao processo de elaborao do modelo conceitual
de dados a partir da utilizao do Diagrama Entidade e Relacionamentos.

4.1.1 Software e Processo de Software


Embora o uso de programas de computador j seja algo comum a muitos dos leitores desse material, faremos
aqui, como forma de nivelar os conhecimentos que sero tratados ao longo desse capitulo, uma breve
explanao do que seja um Software definindo inclusive o processo para elaborao do mesmo, ou seja,
Processo de Software.

Segundo Pressman (2002), um Software compreende um conjunto de programas que executam em


computadores, um conjunto de dados, que tanto podem ser nmeros, textos, vdeos, figuras, udio e um
conjunto de documentos associados.

So desenvolvidos e no manufaturados como nos casos clssicos de outros produtos. Embora j existam
muitas indstrias de software trabalhando com a perspectiva da montagem baseada em componentes, a maior
parte continua a ser construda sob encomenda.

A elaborao de um Software compreende um conjunto de atividades que sero realizadas de forma a alcanar
o produto ao final. Essas atividades so organizadas na forma de um roteiro PAREI AQUI

4.1.2 Ciclo de vida de um Projeto


Refere-se ao Plano do Projeto ou Metodologia que a empresa adota para desenvolver seus sistemas.

Segundo Yourdon (1992), podemos enumerar alguns propsitos para o Ciclo de Vida:

a) Definir as atividades a serem executadas em um Projeto de Desenvolvimento de Sistemas.


b) Introduzir consistncia entre muitos projetos de desenvolvimento de Sistemas na mesma organizao.
c) Para Introduzir pontos de verificao para o controle gerencial de decises.

Ao longo da evoluo do processo de software, diversos modelos de ciclo de vida surgiram. Cada modelo tenta
colocar um pouco de ordem em uma atividade inerentemente catica que o controle e coordenao de um
projeto de software real (PRESSMAN, 2002, p.26).

O Modelo Seqencial Linear (figura 4.1a), tambm chamado de ciclo de vida clssico ou modelo em cascata o
modelo mais antigo e tambm o paradigma de software mais utilizado. Sugere uma abordagem seqencial que
comea no nvel de sistema e progride atravs da anlise, projeto, codificao, teste e manuteno.

O Modelo de Prototipagem (figura 4.1b) pode ser adotado quando o cliente define critrios gerais para o
software, mas no define detalhadamente requisitos de entrada, processamento ou sada ou porque o
desenvolvedor no est seguro quando a questes do ambiente. Dessa forma, o prottipo utilizado como um
mecanismo de levantamento de requisitos.

O Modelo RAD (Desenvolvimento Rpido de Aplicao) da Figura 4.1c um processo incremental que enfatiza
um ciclo de desenvolvimento curto, a partir do uso de componentes. Aplicaes modularizveis e que possam
ser completada em menos de 3 meses so candidatas ao RAD.

Existem ainda os modelos de processo de software evolucionrio que podem ser: Incremental, Espiral, Espiral
ganha-ganha e de desenvolvimento concorrente. Temos ainda o Desenvolvimento Baseado em Componentes e
o Modelo de Mtodos Formais. No criamos figuras para estes modelos, pois a inteno de apresentar os
demais modelos foi somente a de conectar os elementos que sero estudados no contexto do desenvolvimento
de um software. Todos esses modelos de processo podem ser amplamente estudados na bibliografia citada.

2/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Anlise Projeto Codificao Teste

FIGURA4.1a Modelo Seqencial Linear (PRESSMAN, 2002).

Construir/
Ouvir o Revisar o
cliente prottipo

Cliente
Testa o
prottipo
FIGURA4.1b Modelo Prototipagem (PRESSMAN, 2002).

Equipe 3
Equipe 2
Modelagem
Equipe 1 de negcios
Modelagem
Modelagem de negcios Modelagem
de dados
de negcios
Modelagem Modelagem
de dados de processos

Modelagem
Gerao da
de dados Modelagem aplicao
de processos
Teste e
Modelagem entrega
Gerao da
de processos aplicao

Gerao da Teste e
aplicao entrega

Teste e
entrega

60 a 90 dias
FIGURA4.1c Modelo RAD (PRESSMAN, 2002).

3/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

4.2 ABSTRAO

Abordaremos aqui os nveis de abstrao necessrios a produo de um modelo da realidade que possa ser
processado e armazenado em um computador. Embora os nveis propostos aqui possam ser utilizados tambm
para o processo de elaborao dos programas (parte funcional do sistema), nos focaremos somente na questo
dos dados. A estrutura proposta suporta 5 nveis de abstrao: Nvel do Mundo Real, Nvel Descritivo, Nvel
Conceitual, Nvel Computacional e Nvel Interno, que esto detalhados abaixo: (Setzer, Silva, 2005)

Nvel do Mundo Real

O nvel do Mundo Real ainda muito nebulozo, pois representa a vastido da nossa realidade, mas h os que
acreditam que um dia ser possvel formaliz-lo. Essa realidade povoada de seres, fatos, coisas, organismos
sociais. Para se referenciar a esse elenco de elementos, utiliza-se a denominao entes. Alm de reconhecer e
identificar os entes, importante que se conhea as associaes que existem entre os entes no mundo real.
Observe que na descrio do mundo real listamos um elenco muito variado de elementos, tanto tangveis
(seres) quanto intangveis (fatos), ou seja, ao olharmos para o mundo real percebemos tanto coisas concretas
como abstratas. Cabe ento ao projetista determinar o que interessante do mundo real para fazer parte do
projeto de sistema que est sendo elaborado.

Nvel Descritivo

O segundo nvel de abstrao o das descries informais feitas em uma linguagem natural, tanto escrita
quanto falada. O artefato gerado nesse nvel denominado modelo descritivo. A elaborao desse modelo se
dar pela descrio da realidade por meio de frases, figuras, fotos, preferivelmente sem o uso de conceitos
matemticos formais de forma que as partes (pessoas) envolvidas no processo de elaborao entendam o que
ser modelado sem a necessidade de conhecimento adicional. As descries feitas no modelo descritivo devem
ser suficientes para se converterem em informao para os que delas fizerem uso. No h regras para
elaborao do Modelo Descritivo, pois tanto o mundo real quanto o modelo descritivo no so formais. No
entanto pode-se adotar um conjunto de diretrizes denominadas Anlise de Requisitos para a elaborao do
modelo descritivo. O produto da analise de requisitos ser uma descrio formal das regras de negocio e as
transaes pertinentes ao ambiente observado. Semelhante ao que ocorre no mundo real, adota-se o termo
ente para se referir aos elementos que esto sendo observados e modelados.

Nvel Conceitual

O terceiro nvel de abstrao diferente do segundo j adquire um formalismo matemtico para expressar seus
modelos. O documento elaborado no terceiro nvel denominado Modelo Conceitual, que j adotam uma
conceituao rigorosa, mas que eventualmente no podem ser introduzidos em um computador. Nesse nvel,
aparecem dois aspectos distintos, em geral misturados nos modelos descritivos: as estruturas de dados (que
daro forma ao Modelo Conceitual de Dados) e o tratamento dos dados (que do forma ao Modelo Conceitual
de Tratamento de dados ou simplesmente Modelo Funcional). No Modelo Conceitual os dados so provenientes
dos entes do mundo real de mesma categoria, como constituindo conjuntos abstratos como os da matemtica.
No nvel conceitual estamos atuando no tratamento dos dados que compreende aes de definio, excluso,
atualizao e seleo nos metadados, que possuem as informaes sobre os dados. Usa-se uma linguagem
grfica para definir as estruturas no nvel conceitual apoiada por uma linguagem textual que complementa a
linguagem grfica para no torn-la muito extensa.

Se a abordagem utilizada for a Orientao a Objetos OO, nesse nvel se faz a identificao das classes de
dados. Uma classe envolve as estruturas e o comportamento (mtodos) dos dados. Esse encapsulamento
denomina-se classe, pois agrupa em um nico elemento a definio das estruturas de dados e das rotinas
(mtodos) de tratamento dos mesmos. As classes identificadas no contexto da aplicao podero ser agrupadas
em um diagrama denominado Diagrama de Classes.

Na abordagem anterior a OO, o estudo desses dois componentes j era realizado, porm de maneira separada.
Nessa poca estudavam-se os Tipos de Dados e as rotinas ou procedimentos que processavam dados de
certos tipos. Na abordagem Estruturada, os dados so tratados como entidades e uma das maneiras de
express-los a partir de um diagrama denominado Diagrama Entidades-Relacionamentos.

4/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Ainda que se adote alguma notao grfica e at mesmo alguma ferramenta de software para apoiar a
elaborao do Modelo Conceitual, no deve ser preocupao desse nvel dos elementos relacionados a parte
de implementao, ou seja, com requisitos de hardware e software que sero utilizados para materializar a
soluo. A mesma regra utilizada para o Modelo Descritivo. Isso se da pelo fato de que modelos conceituais
no mudam sempre que houver uma mudana de SGBD. Modelos conceituais constituem uma documentao
de alto nvel sobre as estruturas de dados e os programas que podero ser implementados.

Nvel Operacional

O quarto nvel de abstrao o dos dados computacionais. O nvel computacional trata da viso externa que a
comunidade de usurios possui dos dados e tambm da viso que estes usurios tm do processamento que
feito pela maquina sobre esses dados. Nesse nvel os dados que ainda possuam uma concepo abstrata
proveniente do nvel conceitual, j podem ser vistos como um elemento concreto e passvel de tratamento por
um computador. Os dados no nvel conceitual podem ser descritos por qualquer formalismo matemtico, podem
existir no papel ou na mente. No nvel computacional os dados devem ser expressos de forma que um
computador possa receb-los e trat-los. Se no nvel conceitual as informaes devem ser expressas o mais
prximo possvel do mundo real, no nvel computacional tais informaes devem ser expressas de forma
algortmica, sendo tal algoritmo deve ser escrito em alguma linguagem de programao, de maneira a que seja
introduzida para ser executada em um computador.

nesse nvel que se faz a adequao dos modelos elaborados nos nveis anteriores para um Sistema de
Gerenciamento de Bancos de Dados (SGBD).

Nesse nvel temos a correspondncia com os dois aspectos do nvel conceitual, porm a um nvel
computacional: o das estruturas de dados, que ser tratado por uma linguagem de definio das estruturas de
dados (DDL) e o da especificao de tratamentos dos dados, que ser tratado por uma linguagem de
processamento dos dados (DML). Os tratamentos que os dados sofrero podem ser: Incluso, Atualizao,
Excluso e de Seleo.

Como o nvel computacional o nvel de mquina, j possvel tratar diversos elementos relacionados a
eficincia, sendo que para isso os desenvolvedores devam conhecer a estrutura interna dos arquivos gerados
pelo SGBD. No entanto, nos dias atuais alguns elementos de desempenho so absorvidos pelos produtos de
GBD que a partir de componentes internos escolhe a maneira mais eficiente para o processamento dos dados.

Nvel Interno

O quinto ultimo nvel o nvel e mquina, no mais do ponto de vista do usurio, mas sim dos aspectos
internos, ou seja, da representao interna dos dados e dos programas. No nvel interno no falamos mais de
dados, mas sim de cadeia de bits ou de bytes. comum chamar o nvel interno de nvel fsico. No muito
adequado, pois o nvel computacional j fsico, ou seja, j um nvel voltado para a mquina. De forma
semelhante, comum chamar o nvel computacional de nvel lgico o que no parece tambm ser uma boa
alternativa por entendermos que nvel lgico estaria mais adequado ao nvel conceitual. Enfim, para evitarmos
confuses, melhor mantermos os nomes convencionados.

5/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Os negcios da
Mundo Real empresa. Entes (seres,
coisas, organismos
sociais, fatos,
relatrios) e a
Descries Informais. associao entre os
Analise dos requisitos: Modelo entes.
descrio dos entes Descritivo
E suas associaes,
regras e transaes
Descries formais:
Modelo Dados. Estruturas
conceitual conceituais de dados;
operaes conceituais
Descries sobre os dados.
computacionais dos
dados. Estruturas
externas dos dados. Modelo
Mtodos (programas e computacional
Bits e Bytes.
rotinas de Estruturas internas de
processamento dos arquivos; programas e
dados). Modelo interno rotinas interpretaveis.

FIGURA4.2 Nveis de Abstrao (SETZER, 2005, p.8)

Em cada nvel de abstrao, encontramos diversos usurios atuando, desempenhando papeis distintos e
complementares:

Mundo Real Este o nvel onde encontramos somente o usurio final, desempenhando as atividades
relacionadas a sua rea de atuao.

Nvel Descritivo Aqui participam o usurio final e os analistas de sistemas. Os usurios finais atuam
fornecendo o conhecimento do objeto de estudo para os analistas de sistemas que os registrar de maneira livre
de restries de implementao, de forma que seja compreensvel a todos os envolvidos no processo.
Eventualmente, dependendo da estrutura organizacional podemos encontrar tambm DBAs atuando nessa fase
e em algumas situaes, os prprios programadores.

Nvel Conceitual Aqui participam o usurio final e os analistas de sistemas. Nessa fase, o usurio atua
junto com os analistas na identificao dos elementos relevantes de negcio que meream se transformar em
futuras estruturas de dados. Em algumas organizaes podemos ter a presena dos DBA j nessa fase da
modelagem.

Nvel Operacional Aqui participam os analistas de sistemas e DBAs. Nessa fase, os analistas em conjunto
com os DBAs iro aplicar regras especificas do produto utilizado para Gerenciar o Banco de Dados de maneira
a adequar o Modelo Conceitual elaborado no nvel anterior s exigncias desse produto especfico e aos
prprios requisitos relativos ao armazenamento de dados definidos pela organizao.

Nvel Interno Aqui participam somente os DBAs.

Durante as disciplinas de Banco de Dados estaremos abordando elementos tericos e prticos que representam
os nveis Conceitual e Computacional. O Nvel Conceitual tratado na seo 4.3 enquanto o Nvel
Computacional tratado na seo 4.4.

6/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

4.3 MODELAGEM CONCEITUAL DE DADOS

Segundo Cougo (1997), define-se como Modelo Conceitual aquele onde os objetos, suas caractersticas e
relacionamentos tm a representao fiel ao ambiente observado independentemente de restries impostas
pela tecnologia. Durante a elaborao do mesmo devem ser ignoradas quaisquer particularidades necessrias a
implementao. Dessa forma, ser possvel elaborar modelos que praticamente so imunes ao ambiente que
ser utilizado para implement-lo. No entanto, a partir do MCD, ser possvel derivar para qualquer tipo de
estrutura de implementao, como por exemplo, usar um SGBD Hierrquico ou um SGBD Relacional.

A elaborao do Modelo Conceitual d-se na fase de Anlise de um projeto de software, conforme pode ser
observado na figura 4.1.

4.3.1 Modelo

Um modelo a representao abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar
o seu comportamento, em seu todo ou em parte. Observe que nessa definio, no estamos condicionando que
o modelo seja computadorizado. Qualquer ambiente do mundo real passvel de ser modelado, j que o mesmo
busca expressar o objeto observado algumas vezes, mesmo antes da existncia fsica, tangvel de tal objeto.

Ex: As plantas de apartamentos dos jornais.


O manequim da vitrine
A foto de um conjunto estofado
Um aeromodelo sendo usado para testes de aerodinmica
O desenho em perspectiva de uma nova cozinha
O molde de uma roupa obtido em uma revista.

O importante, contudo, perceber que atravs de algum meio, seja uma maquete, desenho ou descrio, pode-
se antecipar ou substituir a existncia de uma realidade qualquer.

4.3.2 Motivos Para A Construo De Modelos


Segundo Cougo (1999), os principais motivos para elaborarmos modelos so:

a) Focalizar caractersticas importantes de sistemas deixando de lado as menos importantes.


b) Discutir alteraes e correes nos requisitos do usurio a baixo custo e com mnimo risco.
c) Para confirmar que o ambiente do usurio foi entendido.
d) Representar o ambiente observado
e) Servir de instrumento de comunicao
f) Favorecer o processo de verificao e validao
g) Capturar aspectos de relacionamento entre os objetos observados
h) Servir de referencial para a gerao de estruturas de dados

4.3.3 Modelagem De Dados


Tem por objetivo a obteno de estruturas de dados que nos levem a projetar Banco de Dados.

Definem-se basicamente, trs nveis de modelagem:

MCD (Modelo Conceitual de Dados): Objetos, caractersticas e relacionamentos, tm a representao fiel do


ambiente, independente das limitaes impostas da Tecnologia. Equivale ao Nvel Conceitual dos Nveis de
Abstrao apresentados anteriormente.

MLD (Modelo Lgico de Dados): Objetos, caractersticas e relacionamentos, tem a representao de acordo
com as regras de implementao e limitantes de alguma tecnologia. Deve observar conceitos de chave de

7/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

acesso, controle de chave duplicada, item de repetio, normalizao, integridade referencial. Equivale ao
Nvel Computacional dos Nveis de Abstrao apresentados anteriormente.

MFD (Modelo Fsico de Dados): A representao do objeto feita sob o foco do nvel fsico de
implementao. Equivale ao Nvel Interno dos Nveis de Abstrao apresentados anteriormente.

Schema Conceitual
Objetos de Interesse Modelo Conceitual

Schema Externo
Modelo Lgico

Schema Interno

Modelo Fsico

FIGURA4.3 Relao entre os modelos e esquemas de um banco de dados

Por que Modelar Dados?

Porque Dados so mais estveis que os procedimentos.


Porque Dados existem e podem ser descritos independentemente de como so usados
Porque os Dados possuem propriedades prprias e bem definidas.

Um importante documento que trata de modelagem de dados foi proposto por Peter P. Chen, em Maro de
1976. Intitulado The Entity-Relationship Model: Toward the unified view of data, tornou-se uma referncia para
o processo de elaborao de modelos de dados. Com uma abordagem e simbologia simples, o Modelo
Entidade-Relacionamento (ER) possui flexibilidade e adaptabilidade. Utiliza-se, basicamente de 3 smbolos para
representar as Entidades (Retngulos), os Atributos (Bales) e Relacionamentos (Losangos). A figura 4.4 abaixo
demonstra o exemplo de um modelo ER com a simbologia proposta originalmente por Chen. Atualmente, como
forma de no poluir o diagrama, optou-se por no demonstrar os atributos com os crculos conectados nas
entidades. Os atributos so definidos a parte no Dicionrio de Dados, deixando assim o modelo de dados mais
limpo, conforme podemos observar na figura 4.5. A figura 4.6 apresenta outra notao para tributos.

8/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

complemento
numero

logradouro cidade estado

rua cep

CNPJ nome
Razao
codigo social codigo
endereco Preco unit

telefone FORNECEDORES FORNECIMENTO PRODUTOS

Fonte: Silberschatz, 2006, p.143-148

FIGURA4.4 Notao para Diagrama Entidade-Relacionamento proposto originalmente por Chen.

FORNECEDORES FORNECIMENTO PRODUTOS

DICIONRIO DE DADOS
FORNECEDORES = cdigo + cnpj + razo social + ENDERECO + {telefone}
PRODUTOS = codigo + nome + preco unit
ENDERECO= RUA + cidade + estado + cep
RUA = logradouro + numero + (complemento)

FIGURA4.5 Notao alternativa para Diagrama Entidade-Relacionamento

Complemento (0,1)
numero
logradouro
cidade
estado
rua
cep
Razao
CNPJ social
codigo nome
endereco codigo Preco unit

Telefone (0,n)

FORNECEDORES FORNECIMENTO PRODUTOS

FIGURA4.6 Outra notao para diagrama Entidade-Relacionamento

9/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

O modelo proposto por Chen assemelha-se ao que se pode chamar de Lei do Mundo (COUGO, 1997).

4.3.4 Formulao do bvio


1. Lei do Mundo: O mundo est cheio de coisas que possuem caractersticas prprias e que se relacionam
entre si (COUGO, 1997).

Analisando a Lei do Mundo, pode-se observar:

O mundo est cheio de coisas...: Dentro de um universo observado, ser possvel reconhecer objetos
(coisas).

Ex.: Num ambiente de uma fbrica, encontramos:


Mquinas de produo de peas.
Funcionrios operadores dessas mquinas
Conjunto de Ferramentas utilizadas para operar as mquinas
Procedimentos de Operao a serem executados.

... que possuem caractersticas prprias...: Os objetos identificados no universo tero caractersticas que
permitiro agrup-los em conjuntos particulares. Estas caractersticas so inerentes a todos os objetos de
um mesmo conjunto e assim devero ser representadas.

Ex.: Joo, Pedro, Jos, Maria e Ana so objetos ou elementos individualizados pertencentes ao conjunto
denominado FUNCIONRIOS.
Ex.: Alicate, Chave de Fenda, Chave Inglesa, Torqus so elementos individualizados pertencentes ao
conjunto denominado FERRAMENTAS.

... e que se relacionam entre si.: Tanto objetos como conjunto de objetos se relacionaro em funo das
suas prprias caractersticas.

Ex.: Joo opera Mquina de Produo X23


Joo substitui Pedro.
Carlos ajusta Maquina de Produo H124 usando Torqus.

A partir da anlise da Lei do Mundo, pode-se partir para a conceituao dos elementos componentes da
proposta de Chen Entidades-Relacionamentos.

4.3.5 Entidade

Para Setzer (2005, p.9) o mundo real povoado de objetos dos tipos mais variados, como por exemplo, os
seres, os fatos, as coisas e os organismos sociais. Por envolver elementos to distintos adota a denominao
entes para design-los, por julgar que para seres e organismos sociais o termo objeto no muito adequado.
Um indivduo do conjunto representa um objeto ou uma entidade. algo que possui caractersticas que a torna
distinguvel, que desempenha um papel especfico no sistema e sobre o qual desejamos guardar informaes,
define Pompilho (2002, p.78-79).

A percepo e a identificao de uma entidade dependem diretamente do ambiente analisado e da relevncia


dela no contexto. Uma pessoa poder ter papis distintos em ambientes distintos. Poder ser um aluno em um
sistema acadmico, um cliente em um sistema comercial e um paciente em um sistema de consultas mdica.

Entidades so abstraes de coisas do mundo real de forma que todas as coisas tenham as mesmas
caractersticas, e que estejam sujeitas e em conformidade com as mesmas normas. (SHLAER, MELLOR
(1990, p.16).

10/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Uma entidade pode ser:

Ex.: Um Ser, um fato, uma coisa, um organismo social.

4.3.5.1 - Conjunto de Entidades: O conjunto de cada um desses elementos (seres, fatos, etc...) denominado
Classe de Entidade ou Conjunto de Entidades. So identificadas a partir dos Substantivos e perduram no
tempo, podendo cada elemento do conjunto ocorrer uma nica vez. A representao grfica de uma entidade no
Modelo ER feita atravs de um retngulo, contendo um nome dentro do retngulo que nomeia a entidade. Este
nome dever ser escrito em letras maisculas e no plural (SETZER, 2005).

Ex.:
FUNCIONARIOS CARGOS NOTAS FISCAIS LIVROS

Identificar entidades e enquadr-las em grupos (conjuntos) uma tarefa que requer tanto conhecimentos
tcnicos quanto prtica. Para auxiliar nesse processo, Cougo prope a estratgia descrita abaixo, como meio de
apoiar o processo de aprendizado, ou mesmo para validao e verificao do processo de modelagem.

4.3.5.2 Estratgia para reconhecimento de Entidades: Esta estratgia prope separar os conjuntos de
entidades em 5 grandes grupos: Coisas tangveis, Funes, Eventos ou Ocorrncias, Interaes e
Especificaes (COUGO, 1997):

As Coisas Tangveis: Refere-se a tudo aquilo que pode ser tocado. Refere-se a todos os elementos que
tenham existncia concreta, que sejam manipulveis, que possam ser tocados e que ocupem lugar no espao.

Ex.: Um avio a jato, um Cavalo puro-sangue, um livro de fico, uma garrafa trmica, uma chave da porta
de entrada.

O agrupamento desses objetos em conjuntos (entidades ou classes) depender do ponto de vista


adotado pelo processo de modelagem. O nvel de abstrao a ser adotado para o agrupamento
poder ser de maior ou menor grau, o que nos levar a formao de diferentes conjuntos
(COUGO, 1997, p. 38).

A figura 4.7 abaixo, expressa um exemplo de agrupamento.

Conjunto (Entidade) Objetos que pertencem ao conjunto


MEIOS DE TRANSPORTE O avio, o automvel
ANIMAIS O cavalo, o elefante, o cachorro
UTENSLIOS DOMSTICOS A garrafa, a mesa, o telefone, o vidro
UTENSLIOS ESCOLARES O livro, o lpis, o quadro, o disquete
EQUIPAMENTOS O computador, a mquina de escrever
PERTENCES PESSOAIS A chave, a mala, a camisa, a carteira
FIGURA4.7 Modelo de agrupamento de elementos para coisas tangveis (Adaptado de COUGO, 1997, p.38).

As Funes exercidas por elementos: Algumas vezes, somente se percebe os objetos a partir das
funes por eles realizadas. Entendendo por Funo, todo o tipo de papel, atribuio, classificao, capacitao.

Ex.: O mdico cirurgio, um engenheiro naval, um departamento de compras, seu professor de ingls, o
autor de um livro, a gerncia de suporte tcnico, a recepcionista de um hotel, um mdico pediatra, a seo
de despacho de materiais.

Conjunto (Entidade) Objetos que pertencem ao conjunto Coisas Tangveis mapeadas como
FUNO
ESPECIALISTAS O Mdico Cirurgio, PESSOA
o Engenheiro Naval,

11/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

o Autor de um Livro
ORGANIZAES O Departamento de Compras, ORGO FUNCIONAL
A Gerncia de Suporte Tcnico
ATENDENTES O professor de Ingls, PESSOA
O gerente do hotel,
A recepcionista do hotel
CLIENTE Os alunos, PESSOA
O paciente
FIGURA4.8 Modelo de agrupamento de elementos para funes (COUGO, 1997, p.40)

Pode-se observar ainda, que existem especializaes dentro dos grandes grupos que foram definidos acima.
Por exemplo, poderamos distinguir os Especialistas em MDICOS, ENGENHEIROS e AUTORES enquadrando
cada um no seu devido contexto. Isso est diretamente relacionado ao nvel de abstrao que se deseja
modelar. Nveis mais elevados podem agrupar elementos com algumas caractersticas semelhantes, porm, se
desejarmos nveis baixos de abstrao, o ideal seria uma modelagem onde se diferencie os diversos papeis,
conforme proposto no incio do pargrafo.

Eventos ou Ocorrncias: Alguns objetos s conseguem ser percebidos, enquanto certa ao se desenrola,
ou quando algum fato acontece. Nesses casos conseguimos definir caractersticas que o tornam materializveis.
Em geral, possuem poucos dados prprios, pois a maioria dos dados a ele pertencentes so na verdade dados
de outros objetos participantes do prprio evento (COUGO, 1997, p.41).

Ex.: Um vo comercial, um acidente de trnsito, uma apresentao tcnica de um fornecedor, uma festa
beneficente, uma gincana esportiva.

Conjunto (Entidade) Objetos que pertencem ao conjunto Demais objetos que participam
da realizao do evento
VOO TAM3195, GOL1404, VRG2133 COMISSRIOS, PILOTOS,
AERONAVES
ACIDENTE Batida na av. Fernando Ferrari, VEICULOS, PESSOAS
atropelamento
APRESENTACAO Palestra dia 20/12/2009 PALESTRANTE, LOCAL,
TCNICA OUVINTES
FESTA BENEFICENTE Jantar danante dos idosos, churrasco da PESSOAS, LOCAL,
sociedade contra o cncer.
GINCANA ESPORTIVA Gincana de vlei de praia, gincana de EQUIPES, ATIVIDADES,
ginstica rtmica, gincana dos alunos de PREMIOS, JUIZES, LOCAL
medicina
FIGURA4.9 Modelo de agrupamento de elementos para eventos ou ocorrncias

Interaes: Nascem como resultado da associao de objetos em funo da execuo de um processo. Os


objetos-interao passam a existir de maneira individualizada, alm dos objetos que participam dessa
interao. Em alguns momentos, estes objetos podem ser confundidos, e at mesmo substitudos por
Associaes (Relacionamentos) entre objetos.

Ex.: A compra de um imvel, uma adoo de uma criana por um casal, uma venda realizada por um
fornecedor.

Objeto-interao Objetos que participam da Substituio possvel


interao
A compra de um imvel Comprador, imvel, proprietrio, relacionamento comprado por
corretor, agente financeiro evento aquisio
coisa tangvel contrato de compra
Uma adoo de uma Famlia cedente, famlia receptora, Relacionamento adotada por
criana criana, rgo regulamentador Evento adoo

12/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Coisa tangvel registro de adoo


Uma venda realizada por Fornecedor, produto, cliente Relacionamento vendido por
um fornecedor Evento venda
Coisa tangvel nota de venda
FIGURA4.10 Modelo de agrupamento de elementos para funes (COUGO, 1997, p.43)

Especificaes: Refere-se aos objetos que definem caractersticas de outros objetos. Isoladamente no
representam objetos, mas sim especificaes que quando aplicadas ou seguidas, daro origem aos objetos.
vlida sua supresso no MCD. Sero obtidos no MDL a partir do processo de Normalizao.

Certamente que a percepo dos elementos que comporo um Modelo Entidades-Relacionamentos e em


especial a descoberta das entidades no uma atividade trivial. Por isso, algumas dicas podem ser bem boas
na hora que voc se depara com uma situao real (SQL MAGAZINE, 2004, p.23-24).

1) Identificar substantivos que designem objetos: A partir da leitura dos requisitos marque e faa uma lista
de todos os substantivos que designem elementos do mundo real como pessoas, coisas, documentos,
controles, sistemas. Caso o substantivo aparea mais que uma vez, ou mesmo que o nome no seja o mesmo
mas esteja representando o mesmo objeto, consider-lo apenas uma vez.

2) Descartar substantivos que representem um nico indivduo: Para chegar a essa concluso, uma boa
idia fazer a seguinte pergunta: Se este elemento se transformar em uma tabela ter somente uma linha?.
Caso a resposta for afirmativa, descartar este substantivo.

3) Descartar substantivos que esto presentes somente para entendimento do problema: tambm nesse
caso, podemos identificar melhor estes elementos a partir de uma pergunta: Preciso guardar informaes sobre
este objeto?. Se a resposta for no, significa que o mesmo no relevante a ponto de ser mantido no modelo e
dever ser descartado.

4) Descartar objetos que so referncia a uma futura aplicao: Por tratar-se do processo de elaborao do
Modelo Conceitual, no deve haver, nesse momento, preocupao com telas, relatrios, estatsticas, clculos e
portanto, caso tais elementos tenham sido identificados, devero ser descartados.

5) Descartar substantivos que se transformados em entidades teriam apenas um atributo: Analisar se o


objeto identificado, o substantivo possui somente uma caracterstica, ou seja, caso venha a se transformar em
tabela tenha somente uma coluna. Se sim, possivelmente esse elemento no ser mais tratado como entidade,
mas possivelmente como atributo de outra entidade.

Aps analisados estes elementos, sobraro da lista realizada conforme a sugesto do item 1 um elenco de
substantivos que possivelmente representaro as reais entidades que o modelo poder ter.

4.3.6 Atributos
A identificao de entidades est diretamente relacionada a necessidade de se armazenar dados
(caractersticas ou propriedades) a seu respeito. Tais caractersticas ou propriedades so denominadas
atributos. O papel do atributo o de descrever caractersticas ou propriedades relevantes de um conjunto de
Entidades.

Os atributos referem-se aquilo que o intelecto percebe a respeito da entidade. a partir da observao das
propriedades que cada objeto do mundo real possui que conseguimos identific-los, distingui-los, reconhec-los.
Alm disso, conforme referenciado por Shlaer e Mellor na seo 4.3.1 todas as entidades de uma determinada
classe possuem o mesmo elenco de atributos. Os valores que cada atributo ir assumir podem ser distintos para
cada entidade no conjunto, no entanto, tais valores sero retirados de um conjunto denominado domnio
(POMPILHO, 2002, p.79).

13/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
O nome dos atributos ser sempre em letras minsculas e no singular quando o atributo for monovalorado ou
no plural quando o atributo for multivalorado.

Deseja-se que o processo de identificao de atributos alcance um elenco de atributos que sejam completos,
fatorados e independentes (SHLAER e MELLOR, 1990, p.31).

Completo: Deve abranger todas as informaes pertinentes ao objeto que est sendo definido. Os
atributos devem contemplar todas as caractersticas que proporcionem uma perfeita identificao das entidades
a qual esteja associado. Assim, ao se definir a entidade PESSOAS, deve-se prever todos os atributos que me
permitam caracterizar completamente os elementos (pessoas) que comporo esta entidade.

Ex.: Entidade: PESSOAS


Atributos: nome, rua, numero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

Fatorado: Cada atributo deve ser responsvel por um aspecto. No se deve agrupar responsabilidades
acessrias aos atributos. Cada parte, cada caracterstica, deve significar um trao, uma particularidade da
entidade e no estar agregando um conjunto de informaes em um nico elemento, em um nico atributo.

Ex.: Entidade: PESSOAS


Atributos: nome, rua, numero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

Note que o endereo est fracionado nas suas partes constituintes e no agrupado num nico elemento
denominado endereo.

Independente: Os valores que um atributo pode receber (domnio) devem ser independentes uns dos
outros. Isso no significa que no possamos ter atributos distintos com o mesmo domnio. Cada atributo possui
um conjunto dos possveis valores que pode assumir e isso independe dos demais atributos da entidade.

Ex.: Entidade: PESSOAS


Atributos: data de nascimento
Domnio: deve ter as caractersticas de data e ser menor que a data corrente

4.3.6.1 Classificao dos Atributos quanto a Finalidade:

Segundo Cougo, (1997, p.60-63) no vital que se estabelea alguma classificao dos atributos na fase da
modelagem conceitual, pois isso no agregar semntica. No entanto, quando chegarmos na fase da
modelagem lgica, conhecermos particularidades relacionadas aos atributos ir influenciar o estabelecimento de
chaves primrias e chaves estrangeiras. Por isso, aps a identificao de cada um dos atributos que as
entidades tero, interessante enquadrar cada atributo em um dos trs grupos propostos abaixo:

Atributos Descritivos: Sob enfoque funcional, aplicam-se a representao das caractersticas intrnsecas
dos objetos. Todo atributo que seja capaz de demonstrar ou representar, caractersticas formadoras, ou
pertencentes, a um objeto poder vir a ser enquadrado como descritivo. Todos os atributos podem ser
classificados como descritivos. Alguns atributos podero deixar de ser enquadrados como Descritivos e
passarem a pertencer aos demais grupos em funo de possurem caractersticas funcionais adicionais que
podero ser captadas atravs de suas interpretaes (COUGO, 1997, p.60-61). A figura 4.11 demonstra
alguns exemplos de atributos descritivos.

Atributo Descritivo valor Objeto


Nome Maria Silva PESSOA
Cor Branca IMOVEL
Sabor Doce Fruta
FIGURA4.11 Exemplo de atributos descritivos

Atributos Nominativos: Alm de cumprirem a funo de Descritivos, servem tambm como definidores de
nomes ou rtulos de identificao aos objetos aos quais pertencem. Os fortes candidatos a atributos
normativos sero sempre aqueles que, j no nvel conceitual, so reconhecidos e denominados como nome
do ..., cdigo do..., numero do..., identificador do ..., sigla do .....e que na fase do projeto lgico podero vir a

14/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

se tornar chaves candidatas contanto que atendam ao requisito de garantirem a unicidade da entidade
(COUGO, 1997, p.61).

Observe que, atributos nominativos no necessariamente devam ser unvocos com relao as entidades, ou
seja, no obriga que todas as entidades tenham valores distintos. O importante que para ser nominativo
ele deve rotular uma instncia de um objeto, ainda que de maneira no unvoca. A figura 4.12 demonstra
alguns exemplos de atributos nominativos.

Atributo Nominativo valor Objeto


Numero do CPF 88416618876 EMPREGADO
Sigla do Estado ES UNIDADE FEDERATIVA
Numero do Chassis 1ABD333GD55534 VEICULO
Nome Rita de Cssia ALUNO
FIGURA4.12 Exemplo de atributos nominativos

Atributos Referenciais: No pertencem propriamente ao objeto onde esto alocados, mas fazem algum
tipo de citao, ou ligao desse objeto com outro objeto. Ao identificarmos um atributo referencial estar se
assumindo a existncia de outro objeto ao qual nos referenciamos. Este outro objeto, o objeto origem do
atributo, pode j ter sido percebido claramente e existir previamente em nosso modelo, ou ento poder ser
criado para fins de modelagem como local nativo para o atributo em questo (COUGO, 1997, p.63).

Os atributos referenciais somente devem ser demonstrados em modelos quando nos referenciamos a
entidades que no constam no nosso diagrama. Quando todas as entidades envolvidas no relacionamento
estiverem presentes no diagrama, as relaes so configuradas visualmente pela linha (relacionamento)
entre as entidades. A figura 4.13 demonstra alguns exemplos de atributos referenciais.

Atributo Referencial Exemplo Objeto no qual est Objeto de origem


definido
Matricula 1234 DEPENDENTE EMPREGADO
CNPJ 9192847127 NOTA FISCAL FORNECEDOR
Fabricante HONDA VEICULO FABRICA
FIGURA4.13 Exemplo de atributos referenciais

- Na Fase de Modelo Conceitual: Nesta fase, a presena de atributos referenciais pode demonstrar no
normalizao, ou seja, a alocao de dados em lugares no adequados sob o ponto de vista de
manipulao de dados.
- Na Fase do Modelo Lgico: Nesta fase, quando num ambiente Relacional, a existncia de atributos
referenciais poder ser normal, desde que estes atributos caracterizem-se como chaves estrangeiras
(COUGO, 1997, p.63-64).

Algumas consideraes adicionais sobre os atributos:

Ainda sobre a identificao dos atributos interessante que se distinga alguns elementos adicionais conforme
descritos abaixo. (POMPILHO, 2002, p.80-81). Para ilustrar usaremos as entidades da figura 4.4.

Atributos Monovalorados ou Univalorado: um atributo que recebe um nico valor para cada entidade.
So atributos que possuem cardinalidade mxima 1.

Ex.: FORNECEDORES (cdigo, CNPJ, razosocial, logradouro, numero, complemento, cidade, estado,
codigopostal)

Atributos Multivalorados: um atributo que pode assumir vrios valores para cada entidade. So atributos
que possuem cardinalidade mxima N.

15/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Ex.: FORNECEDORES (telefone).

Atributos Obrigatrios: um atributo que obriga a existncia de valor para cada entidade. So atributos
que possuem cardinalidade mnima 1.

Ex.: FORNECEDORES (cdigo, CNPJ, razosocial, logradouro, numero, cidade, estado, codigopostal)

Atributos Opcionais: um atributo que NO obriga a existncia de valor para cada entidade. So atributos
que possuem cardinalidade mnima 0.

Ex.: FORNECEDORES (complemento)

Atributo Composto: So atributos formados por um ou mais atributos, ou seja, so atributos que abrigam
uma estrutura de dado. O atributo nome em uma entidade pessoa, tambm poder ser visto como composto
se for possvel e necessrio separ-los nas suas varias partes (primeiro-nome, nome-intermediario, ultimo-
nome). Quando no so compostos, os atributos so denominados simples.

Ex.: FORNECEDORES (endereo e rua).

Atributo Determinante ou Identificador: Atributo que identifica de modo inequivocamente uma Entidade.
Pode ser visto como a Chave Primria dessa entidade ou Identificador dessa entidade. Sero sublinhados
no diagrama como forma de distingui-lo dos demais. H que j chame o atributo identificador de Chave
Candidata.

Ex.: FORNECEDORES (cdigo)

Na figura 4.14 abaixo temos uma forma de representao dessas definies para atributos.
Complemento (0 , 1 )
numero
logradouro
cidade
estado
rua
codigo postal
Razao
CNPJ social
codigo
endereco

Telefone (0 , n )

FORNECEDORES

FIGURA4.14 notao dos atributos

Na figura 4.15 abaixo temos uma forma alternativa de representao dessas definies para atributos.

16/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

FORNECEDORES

Dicionrio de Dados:
FORNECEDORES = codigo + CNPJ + razaosocial + ENDERECO + {telefone}
ENDEREO = RUA + cidade + estado + codigopostal
RUA = logradouro + numero + (complemento)

FIGURA4.15 notao alternativa para atributos

4.3.6.2 Domnio:

o conjunto dos possveis valores que um atributo pode assumir. No domnio de um atributo, especificamos o
Formato desse atributo, seu tamanho, os valores especificamente. Por exemplo, um atributo nome para uma
classe de entidades PESSOAS, poder ter como domnio uma cadeia de caracteres, j o atributo sexo poder
ter como domnio as opes Masculino ou Feminino. Ser mantido o estudo de domnio at este ponto, j
que tal assunto foi estudado em mais detalhes no capitulo 3.

Ex.: Atributo (Sexo do Empregado)


Domnio (Campo Alfanumrico, 1 caracter, s pode assumir os valores F e M).

4.3.7 Relacionamentos
Pompilho (2002, p.79) define relacionamento como uma estrutura que indica associaes entre elementos de
um conjunto de entidades. Representa um conjunto de conexes entre objetos. Cada Instncia de um
relacionamento representa uma ou mais associaes entre zero ou mais ocorrncias de um objeto e zero ou
mais ocorrncias de outro objeto. Um Relacionamento Binrio um par ordenado (e1, e2), onde e1 e e2 so
respectivamente elementos dos conjuntos de Entidades E1 e E2.

Um relacionamento uma afirmao de ao realizada envolvendo entidades. Por ser uma afirmao,
normalmente dita nos dois sentidos.

Ex.: CLIENTES COMPRAM ITENS


ITENS SO COMPRADOS POR CLIENTES

4.3.7.1 Representao Grfica:

representado por um Losango (diamante). Na parte externa coloca-se o VERBO que simboliza a ao que
vincula os indivduos das duas entidades. Na parte de dentro do losango, coloca-se uma seta indicativa do
sentido de leitura do verbo. Com esses dois elementos (verbo e seta) possvel estabelecer uma forma ativa
ou passiva para leitura do modelo. Observe o exemplo abaixo. Podemos afirmar que clientes compram
itens denotando a voz ativa do verbo referido e por outro lado, itens so comprados por clientes denotando
a voz passiva. Fazer esse exerccio na construo dos relacionamentos dar maior semntica ao mesmo,
proporcionando a validao e anlise dos relacionamentos modelados. Observe que da mesma maneira que
uma entidade possui uma denominao (nome) um relacionamento tambm o ter. Esta denominao, nesse
caso, dada pelo verbo utilizado. Tambm da mesma forma que um nome inadequado para uma entidade
poder acarretar em uma interpretao incorreta do modelo, um nome inadequado para um relacionamento
poder causar o mesmo transtorno no entendimento e validao do modelo.

Nas figuras abaixo suprimimos os atributos para no poluir o modelo,


j que o foco agora o estudo dos relacionamentos.

17/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

COMPRAM

CLIENTES ITENS

FIGURA4.16 Notao grfica para relacionamento

Pode existir mais que um tipo de relacionamento entre duas entidades:

POSSUEM

PESSOAS VEICULOS
UTILIZAM

FIGURA4.17 Dois relacionamento envolvendo o mesmo conjunto de entidades

O relacionamento poder ocorrer tanto entre elementos do mesmo tipo (as instancias que participam do
relacionamento pertencem a mesma classe), quanto entre elementos de tipos diferentes (as instncias que
participam do relacionamento pertencem a classes diferentes).

4.3.7.2 Relacionamento entre objetos do mesmo tipo Auto-relacionamento

Tambm chamado de Relacionamento Recursivo, ocorre quando esto envolvidos objetos da mesma
entidade. Isso faz com que tenhamos que reconhecer diferentes papeis para um mesmo objeto. Se R um
relacionamento que relaciona elementos de um conjunto de entidades E a elementos desse mesmo conjunto E,
R denominado de um Auto-Relacionamento (COUGO, 1997, p.70).

ENTIDADE

PAPEL1 PAPEL2

FIGURA4.18 Notao genrica para auto-relacionamento

18/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

FUNCIONRIOS MATERIAIS


GERENCIA GERENCIADO COMPONENTE COMPOSTO
GERENCIAM COMPEM
DE DE

FIGURA4.19 Exemplos de auto-relacionamento

Observe que o auto-relacionamento faz com que tenhamos que perceber diferentes papis para os indivduos
de uma mesma classe.

4.3.7.3 Relacionamento entre objetos de tipo diferente

So os mais freqentemente observados, pois ocorrem quando esto envolvidos objetos de entidades
diferentes. Aqui, instncias de um tipo de objeto associam-se a instncias de outro tipo. (COUGO, 1997, p.67).

COMPRAM

CLIENTES ITENS

FIGURA4.20 Relacionamento entre indivduos de entidades diferentes

4.3.7.4 Caracterizao dos Relacionamentos

Um relacionamento demonstra uma associao entre objetos, de igual ou diferente tipo. Embora parea
extremamente simples, a fase de caracterizao dos relacionamentos um dos pontos vitais para a construo
de modelos ntegros. Tal caracterizao deve ser baseada no entendimento de alguns requisitos (COUGO,
1997, p.75):

a) Grau ou Cardinalidade do Relacionamento


b) Numero de elementos que participam do relacionamento
c) Condio de participao do elemento no relacionamento
d) Condio de estabelecimento do relacionamento

Aqui, por questes didticas, ser tratado cada requisito isoladamente, porm nos modelos devero ser
analisados de maneira integrada.

a) Grau ou Cardinalidade do Relacionamento:

Refere-se ao numero mximo de possveis associaes de um relacionamento. Busca definir o numero


mximo de pares que cada indivduo de uma entidade poder fazer com os indivduos de outra entidade (ou da
mesma, para o caso de auto-relacionamento) (COUGO, 1997, p.75). Tratam das regras de negcio que iro
impactar diretamente o projeto lgico do banco de dados, pois a anlise das cardinalidade influencia diretamente
a construo do projeto lgico do banco de dados.

19/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

EMITEM

1 N
FORNECEDORES NOTAS FISCAIS

FIGURA4.21 Notao do grau ou cardinalidade do relacionamento

Tomando como exemplo o modelo acima, podemos estabelecer a seguinte regra para notao da cardinalidade:

Fixar um elemento fictcio da entidade FORNECEDORES e perguntar a ele: Um fornecedor pode emitir
quantas notas fiscais? A resposta a esta pergunta ser anotada ao lado da entidade NOTAS FISCAIS. De
forma semelhante, deve-se fazer a pergunta no sentido contrrio, pois tambm precisamos saber quantos pares
NOTAS FISCAIS faz com FORNECEDORES. Ento, faa novamente a pergunta: Uma nota fiscal pode ser
emitida por quantos fornecedores? A resposta dever ser anotada ao lado da entidade FORNECEDORES.

emite

EMITEM
Um fornecedor N notas fiscais
1 N
FORNECEDORES NOTAS FISCAIS
Uma nota fiscal
Por Um fornecedor

emitida

FIGURA4.22 Notao do grau ou cardinalidade do relacionamento

Interpretao do modelo proposto:


- Um fornecedor pode emitir no mximo vrias notas fiscais.
- Uma nota fiscal pode ser emitida por no mximo um fornecedor.

Em alguns casos possvel identificar o limite mximo de ocorrncias de determinado objeto, no


relacionamento, como por exemplo:

EMITEM
1 10
FORNECEDORES NOTAS FISCAIS

FIGURA4.23 relacionamento com limite mximo de cardinalidade


definido

Interpretao:
- Um fornecedor emite no mximo 10 notas fiscais.
- Uma nota fiscal emitida por no mximo 1 fornecedor.

Os graus dos relacionamentos podem ser enquadrados em trs grandes grupos:

20/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

- 1:1 (Um-para-um)
- 1:N (Um-para-Muitos)
- M:N (Muitos-para-Muitos)

Relacionamento 1:1: um caso especial de relacionamento 1:N onde o N fixado com o valor Mximo de
1. Significa que 1 elemento do Tipo A se relaciona com no mximo 1 elemento do Tipo B e que 1 elemento do
Tipo B se relaciona com no mximo 1 elemento do Tipo A.

RECEBEM
1 1
PESSOAS CERTIDES DE OBITO

FIGURA4.24 relacionamento de cardinalidade 1:1 (um para um)

Conjunto simblico
Conjunto simblico
da entidade PESSOAS
da entidade CERTIDES DE
BITO

FIGURA4.25 representao simblica de relacionamento 1:1 (um para um)

Observe que no estamos tratando nesse momento do grau mnimo, que diz se todo elemento do grupo A deve
obrigatoriamente se relacionar a no mnimo um elemento do grupo B e vice-versa. Este dado ser tratado mais
adiante no item c) condio de participao do elemento no relacionamento.

Relacionamento 1:N: Este relacionamento bastante comum, sendo encontrado na maior parte dos
modelos. Significa que 1 elemento do Tipo A se relaciona com no mximo N elementos do Tipo B e que 1
elemento do Tipo B se relaciona com no mximo 1 elemento do Tipo A. Note que novamente no estamos
tratando da obrigatoriedade do relacionamento, ou seja, de que todo A esteja relacionado a no mnimo um B ou
que todo B esteja relacionado a no mnimo um de A. Mas importante que, para respeitar os nmeros de pares
possveis idealizados na combinao 1:N, uma vez que um elemento de B faa par com algum elemento de A,
ele no poder formar par com nenhum outro elemento de A.

POSSUEM
1 N
EMPRESAS FILIAIS

FIGURA4.26 relacionamento de cardinalidade 1:N (um para muitos)

21/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Conjunto simblico Conjunto simblico


da entidade EMPRESAS da entidade FILIAIS

FIGURA4.27 representao simblica de relacionamento 1:n (um para muitos)

Relacionamento M:N: Nesse tipo de relacionamento, teoricamente, no h restrio quanto s possveis


ligaes a serem estabelecidas entre os conjuntos A e B. Num relacionamento M:N, um elemento de um
conjunto A pode se associar a 0 (nenhum) , 1 (um) ou N (muitos) elementos do conjunto B. Por sua vez, um
elemento de um conjunto B pode se associar a 0 (nenhum) , 1 (um) ou N (muitos) elementos do conjunto A.

ESCREVEM
M N
AUTORES LIVROS

FIGURA4.28 relacionamento de cardinalidade 1:N (um para muitos)

Conjunto simblico Conjunto simblico


da entidade AUTORES da entidade LIVROS

FIGURA4.29 relacionamento de cardinalidade M:N (muitos para muitos)

Observe que no h obrigatoriedade de que todos os elementos do conjunto A tenham vrios elementos do
conjunto B associados a ele. Alguns podem ter nenhum, outros podem ter somente 1 e outros podem ter vrios.
O mesmo tambm valido para relao do conjunto B.

Outra observao importante, o porqu da denominao desse gnero como M:N e no N:N. Utiliza-se as
duas letras para que fique explicito que as duas grandezas so totalmente diferentes. Isso quer dizer que se um
elemento do conjunto A pode ser relacionar com at 10 elementos do conjunto B, o inverso no obrigatrio,
um elemento do conjunto B no necessariamente precisar se relacionar com 10 elementos do conjunto B.

22/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

b) Numero de elementos que participam do relacionamento:

At agora, a modelagem baseou-se no relacionamento que envolve somente dois conjuntos de entidades, ou
somente nos objetos pertencentes a duas entidades. Na verdade, um relacionamento pode se estabelecer entre
duas ou mais entidades (SETZER, 2005, p.52). Do ponto de vista conceitual, o estabelecimento de
relacionamentos Ternrios (3 conjuntos de entidades), Quaternrios (4 conjuntos de entidades) ou maiores no
muito freqente. Algumas vezes, mas no sempre, no lugar de um relacionamento ternrio ou maior, pode
existir um objeto que no est explicito e que agrega em si um conjunto de outras informaes bem como de
relacionamento com outros objetos (COUGO, 1997, p.85).

- Relacionamentos Binrios: AVIO transporta CARGA.


- Relacionamentos Ternrios: PROFESSORES ministram DISCIPLINAS para ALUNOS.

Na falta de um nome adequado para o relacionamento, podemos adotar outra soluo como por exemplo,
colocar as iniciais dos nomes das entidades envolvidas ou mesmo colocar os trs nomes por extenso (SETZER,
2005, p.51).
P-A-D

1 N
PROFESSORES ALUNOS

DISCIPLINAS

FIGURA4.30 relacionamento ternrio

- Dado um aluno em uma disciplina, h um S professor associado a eles, isto , um aluno NO pode ter em
uma certa disciplina mais do que um professor.
- Por outro lado, um professor pode ministrar uma disciplina para um nmero qualquer de alunos;
- E um professor pode dar para um certo aluno mais do que uma disciplina.

Em um relacionamento ternrio, a leitura da cardinalidade refere-se a pares de entidades. Em um


relacionamento R entre as entidades A, B e C, a cardinalidade mxima de A e B dentro de R indica quantas
ocorrncias de C podem estar associadas a um par de ocorrncias de A e B (HEUSER, 2001, p.19-20).
Tomando o exemplo acima, faz-se a seguinte leitura:

- Toma-se o par formado por um elemento da entidade PROFESSOES e um elemento da entidade ALUNOS e
faz-se a leitura de quantos elementos da entidade DISCIPLINAS podero participar do par formado por
PROFESSORES-ALUNOS.
- Feita a primeira anlise considerando-se esta lgica, faz-se o rodzio das entidades: Agora se toma um
elemento de ALUNOS e um elemento de DISCIPLINAS e perguntam-se quantos PROFESSORES podero
participar do par de ALUNOS-DISCIPLINAS;
- E por fim, toma-se o par formado por um elemento de DISCIPLINAS e um elemento de PROFESSORES e
perguntam-se quantos ALUNOS podero estar presentes no par de DISCIPLINAS-PROFESSORES.

No exemplo acima, leramos:

- para um professor e uma disciplina, podemos ter N alunos associados.


- para um professor e um aluno, podemos ter vrias disciplinas.
- para uma disciplina e um aluno, podemos ter somente 1 professor.

Um dado muito importante nesse tipo de relacionamento, que todos os elementos envolvidos tm que estar
presente simultaneamente para que o relacionamento ocorra.

23/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Segundo Silberschatz (2006, p.148-149) algumas vezes possvel desenvolver um modelo de dados que s
possua relacionamentos binrios. Dessa forma, situaes onde se mapeia inicialmente relacionamentos
ternrios ou de grau maior, poderiam ser transformados em vrios relacionamentos binrios. Observando a
figura do relacionamento PROFESSORES, ALUNOS e DISCIPLINAS demonstrado anteriormente poderamos
ter como soluo o modelo proposto abaixo.

1 N N N
PROFESSORES CLASSES ALUNOS

DISCIPLINAS

FIGURA4.31 soluo alternativa para relacionamento ternrio

No entanto, que fique claro que isso nem sempre possvel e nesses casos, tentar transformar qualquer
relacionamento que no seja binrio em relacionamento binrio pode no ser uma boa alternativa. Mesmo
assim, fica aqui a reflexo, para efeito de enriquecimento do aprendizado e do processo de modelagem.

c) Condio de participao do elemento no relacionamento:

Vimos anteriormente que o grau do relacionamento trata do numero de pares possveis entre os indivduos das
entidades. Naquele momento, abordado no item a) Grau ou Cardinalidade do Relacionamento tratamos
somente da cardinalidade mxima, ou seja, do numero mximo de pares possveis. Nesse momento,
trataremos da analise da obrigatoriedade ou no do relacionamento. A obrigatoriedade ou no do
relacionamento trata da possibilidade de que elementos de um conjunto A possam no formar par com nenhum
elemento de um conjunto B e vice-versa.

Tomemos novamente o exemplo utilizado anteriormente para ilustrarmos a questo proposta. O Grau estudado
anteriormente, determinada que:

- uma empresa pode ter muitas filiais


- uma filial deve estar associada a somente uma empresa

POSSUEM
1 N
EMPRESAS FILIAIS

FIGURA4.32 condio de participao no relacionamento

Porem, algumas outras questes muito importantes para o projeto no esto sendo respondidas, como por
exemplo:

- toda empresa deve ter alguma filial, nem que seja uma?

24/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

- uma filial pode estar associada a nenhuma empresa?

Observe que tais questes no esto sendo respondidas pelo modelo. Certamente que as respostas podem
variar de acordo com o contexto, mas haver uma resposta e essa dever estar mapeada no modelo. Para
expressar tais informaes, ampliaremos o conceito de Grau do Relacionamento estudado anteriormente para
abrigar o grau mnimo. Nos exemplos mostrados na seo que tratou do grau, quando expressamos um
relacionamento como sendo 1:N, nos referamos aos graus mximos de cada lado do relacionamento. O grau
mnimo trata do limite mnimo de pares possveis ou o menor valor de participao dos elementos do conjunto A
e B no relacionamento (COUGO, 1997, p.90).

Para expressar graficamente os graus mximos e mnimos, modificaremos levemente a notao vista ate aqui,
acrescentando o valor mnimo, antes do valor mximo, separados por uma vrgula. Assim, o exemplo de
EMPRESAS e FILIAIS visto acima cujo grau foi expresso como sendo 1:N (representando somente os
mximos), para abrigar o grau mnimo passar a ser notado 1,1:0,N. Observe o modelo abaixo com a
modificao proposta.

POSSUEM
(1,1) (0,N)
EMPRESAS FILIAIS

FIGURA4.33 relacionamento com cardinalidade mxima e mnima

Interpretao:
- Uma empresa possui no mnimo nenhuma e no mximo muitas filiais.
- Uma filial de no mnimo 1 e no mximo 1 empresa.

Tambm podemos ler:


- A empresa pode no ter filiais ou poder ter muitas.
- toda filial deve estar vinculada a obrigatoriamente uma e somente uma empresa.

at Grau mximo

possui Grau mnimo


pelo menos

POSSUEM

(1,1) (0,N)
EMPRESAS FILIAIS

Grau mximo at
de
Grau mnimo
pelo menos

FIGURA4.34 detalhamento da cardinalidade mxima e mnima

Dessa forma, toda vez que desejamos expressar que um indivduo de uma entidade pode no participar de
qualquer relacionamento (relacionamento condicional), representaremos com a cardinalidade mnima 0, ao
passo que para representar a obrigatoriedade de participao em pelo menos um relacionamento
(relacionamento incondicional), usaremos cardinalidade mnima 1.

25/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Outra informao importante sobre a notao adotada a de que o valor referente cardinalidade mnima
(obrigatoriedade ou opcionalidade de participao no relacionamento) est sempre escrita no lado esquerdo da
vrgula, dentro do parntesis, ao passo que a cardinalidade mxima est sempre escrita no lado direito da
vrgula.

Em algumas situaes, ser possvel determinar um grau mnimo e mximo especfico, como o exemplo abaixo
ir expressar. Nesse exemplo, o nmero mnimo e mximo de tripulantes que devem estar presentes em um vo
conhecido, ou seja, um vo deve ter no mnimo 4 e no mximo 15 tripulantes. Embora semanticamente possa
estar correto, modelos com esta caracterstica podem ser mais frgeis, pois mudanas nesses valores podem
impactar o projeto.

POSSUEM
(0,N) (4,15)
VOOS TRIPULANTES

FIGURA4.35 limite restrito de cardinalidade mxima e mnima

d) Condio de estabelecimento do relacionamento:

Nessa fase, analisaremos quando o relacionamento de elementos de duas entidades impacta os possveis
relacionamentos desses mesmos indivduos com estas ou outras entidades. As condies possveis podem ser
enquadradas em trs tipos (COUGO, 1997, p.94):

- Relacionamentos Independentes
- Relacionamentos Contingentes
- Relacionamentos mutuamente exclusivos

- Relacionamentos Independentes: Permitem que ocorra relacionamento entre elementos das entidades, sem
que se tenha que avaliar qualquer outro relacionamento existente (COUGO, 1997, p.94).

MINISTRAM
(0,N) (1,N)
DISCIPLINAS

PROFESSORES
COORDENAM
(1,1)
(0,1)
CURSOS

FIGURA4.36 exemplo de relacionamento independente com mesma entidade

Podem ocorrer tanto entre entidades distintas, como entre as mesmas entidades.

26/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

VENDEM

(0,N) (0,N)

CLIENTES VEICULOS
COMPRAM
(0,N) (0,N)

FIGURA4.37 relacionamento independente com entidades distintas

- Relacionamentos Contingentes: So relacionamento que, tendo dependncia uns com os outros, impem o
estabelecimento simultneo de associaes entre os vrios elementos envolvidos (COUGO, 1997, p.94). A
presena desse tipo de relacionamento mais comum quando se percebe associaes com a mesma finalidade
porem envolvendo elementos diferentes. Nessa situao, mais de um relacionamento deve ocorrer em um dado
instante. A notao adotada so duas barras verticais sobre as linhas que expressam os relacionamentos que
sero tratados como contingentes.

NECESSITAM
(1,N)
EXAMES LABORATORIAIS
(0,N)

CIRURGIA CARDACA
NECESSITAM
(0,N)
(1,N)
EXAMES FSICOS

FIGURA4.38 relacionamento contingente

- Relacionamentos mutuamente exclusivos: Nesse tipo de relacionamento, se a associao de um elemento


for estabelecida, no poder ser estabelecida pelos demais (COUGO, 1997, p.97). A notao adotada uma
barra vertical sobre as linhas que expressam os relacionamentos que sero tratados como mutuamente
exclusivos.

REALIZAM
(1,N)
(0,N)
PARTO NORMAL

GRAVIDAS
REALIZAM
(1,N)
(0,N) CESREA

FIGURA4.39 relacionamento mutuamente exclusivo

4.3.7.5 Relacionamentos Parciais ou Totais

27/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

A noo de Parcialidade e Totalidade est ligada a Cardinalidade Mnima de um relacionamento. Trata-se de


uma restrio muito comum e importante na modelagem de casos prticos (SETZER, 2005, p.38).

Diz-se que um relacionamento parcial, quando no par ordenado dos elementos x e y oriundos da Entidades X
e Y, no existe a obrigatoriedade de que para todo x exista um y relacionado, ou seja, voc pode encontrar
elementos na Entidade X para o qual no exista relao com nenhum elemento da Entidade Y.

Diz-se que um relacionamento total, quando no par ordenado dos elementos x e y oriundos da Entidades X e
Y, existe a obrigatoriedade de que para todo x exista um y relacionado, ou seja, todo elemento na Entidade X
deve possuir uma relao com no mnimo um elemento da Entidade Y.

Notao: Representamos a totalidade acrescentando uma bolinha cheia na sada da aresta do Relacionamento
que une o Losango ao ngulo da Entidade, no caso desse Relacionamento ser Total para esta Entidade.

POSSUEM

1 N
EMPREGADOS DEPENDENTES

FIGURA4.40 notao para totalidade de relacionamento

Analisando o Modelo:
- Um Empregado pode ter no mnimo 0 e no mximo N Dependentes. Porm todo Dependente deve estar
associado no mnimo 1 e no mximo 1 Empregado.
- Diz-se que o relacionamento POSSUEM Total em relao a DEPENDENTES e Parcial em relao a
EMPREGADOS

Dado o conjunto de Entidades EMPREGADOS e DEPARTAMENTOS e o Relacionamento LOTAM, a


restrio de totalidade impe que todo elemento de EMPREGADOS esteja no relacionamento LOTAM. No
entanto, podemos ter um departamento que no esteja em nenhum relacionamento em LOTAM, ou seja, um
departamento que no possua nenhum empregado lotado. Se ambas restries so verdade, diz-se que o
Relacionamento Total em EMPREGADOS e Parcial em DEPARTAMENTOS.

LOTAM

N N
DEPARTAMENTOS EMPREGADOS

FIGURA4.41 outro exemplo de totalidade de relacionamento

Uma notao alternativa para a totalidade a de explicitar na prpria cardinalidade os valores mximos e
mnimos conforme adotado nos demais exemplos desse material. Nesse caso, a totalidade representada
pela cardinalidade mnima igual a 1 ao passo que a parcialidade representada pela cardinalidade mnima igual
a 0.

LOTAM
(1,N) (0,N)
DEPARTAMENTOS EMPREGADOS

FIGURA4.42 totalidade utilizando cardinalidade mnima

28/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
4.3.7.6 Relacionamentos com Atributos

Assim como um conjunto de entidades possuem caractersticas, em varias situaes de modelagem podemos
encontrar atributos que pertencem no a um conjunto de entidades, mas sim a um conjunto de relacionamento.
Atributos de relacionamento so atributos que no pertencem exclusivamente s entidades presentes em um
modelo, mas sim, ao relacionamento que vincula estas entidades. O dado para este atributo s existir quando o
relacionamento ocorrer, j que Esses dados denotam a existncia de informaes que s podem ser
estabelecidas ou consideradas quando da existncia de uma associao entre elementos (COUGO, 1997,
p.100). Somente pela existncia das entidades separadamente no garantia de valor para este tipo de
atributo.

No entanto, alguns tipos de atributos de relacionamento podem ser perfeitamente alocados nas entidades
participantes do mesmo. O que determinar se o atributo do relacionamento poder ser alocado em alguma
entidade pertencente ao relacionamento ser a cardinalidade mxima desse relacionamento
(SILBERSCHATZ, 2006, p.149-150).

- Para relacionamentos de cardinalidade 1:1 o atributo do relacionamento dessas duas entidades poder ser
alocado em qualquer uma das entidades participantes.

- Para relacionamentos de cardinalidade 1:N, o atributo do relacionamento somente poder ser alocado na
entidade que possui a cardinalidade N.

- Para relacionamentos de cardinalidade M:N no teremos esta liberdade de alocar tais atributos nas entidades
participantes e nesse caso, devero obrigatoriamente ser alocados no relacionamento.

Para ilustrar as trs situaes de cardinalidade, vamos analisar os trs exemplos abaixo que possuem
cardinalidade 1:1, 1:N e M:N

Exemplo 1 Relacionamento com cardinalidade mxima 1:1 com atributo alocado no relacionamento.

Data nascimento
nome livro
Cdigo
Data registro numero folha

(1,1) RECEBEM (1,1)

PESSOAS CERTIDES DE NASCIMENTO

FIGURA4.43 relacionamento de cardinalidade 1:1 notao do atributo de relacionamento

Relacionamento com cardinalidade 1:1 com atributo alocado na entidade da direita.

nome livro
Cdigo Data nascimento numero folha Data registro

RECEBEM
(1,1) (1,1)

PESSOAS CERTIDES DE NASCIMENTO

FIGURA4.44 relacionamento de cardinalidade 1:1 - notao do atributo do relacionamento

29/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Exemplo 2 Relacionamento com cardinalidade mxima 1:N com atributo alocado no relacionamento.

nome Data cadastramento nome


matricula Data admisso numero Data de nascimento

POSSUEM

(1,1) (0,N)
EMPREGADOS DEPENDENTES

FIGURA4.45 relacionamento de cardinalidade 1:N - notao do atributo do relacionamento

Relacionamento com cardinalidade 1:N com atributo alocado na entidade de cardinalidade mxima N.

nome nome Data de nascimento


matricula Data admisso numero
Data cadastramento
POSSUEM

(1,1) (0,N)
EMPREGADOS DEPENDENTES

FIGURA4.46 relacionamento de cardinalidade 1:N - notao do atributo do relacionamento

Exemplo 3 Relacionamento com cardinalidade mxima M:N com atributo alocado no relacionamento.

nome
Nome
faixa codigo ano da criao
codigo durao

COMPEM
(0,N)
(1,N)
MUSICAS CDS

FIGURA4.47 relacionamento de cardinalidade M:N - notao do atributo do relacionamento

Em um relacionamento de cardinalidade M:N, pode-se aplicar o seguinte teste para analisar onde dever
ser alocado o atributo do relacionamento.

- Fixa o um individuo da entidade da esquerda e variam-se os indivduos da entidade da direita.


Se o contedo do atributo em questo se mantm o mesmo, significa que ele pertence entidade
da esquerda.
Se o contedo de atributo se modifica, significa que ele no pertence entidade da esquerda.

- Fixa um indivduo da entidade da direita e variam-se os indivduos da entidade da esquerda.


Se o contedo do atributo se mantm o mesmo, significa que ele pertence entidade da direita.
Se o contedo do atributo se modifica, significa que ele no pertence entidade da direita.

30/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Se ao final do teste, conclui-se que o atributo analisado no pode pertencer nem na entidade a esquerda nem a
entidade a direita do relacionamento, e que este atributo essencial ao modelo, significa que o atributo deve
pertencer ao relacionamento.

4.3.7.7 Entidade Fraca

So entidades que no possuem identidade prpria, ou seja, no possuem atributos suficientes para formar uma
chave. Sua existncia est condicionada a existncia de outra entidade dita Forte. O relacionamento entre a
entidade forte e a fraca e de grau 1:N e a participao da entidade fraca total. Por essa razo, o atributo
determinante da entidade fraca ser formado pelo atributo determinante da entidade forte mais um atributo
diferenciador pertencente a entidade fraca (SILBERSCHATZ, 2006, p.150-151).

nome
matricula nome numero Data de nascimento
Data admisso matricula

POSSUEM

(1,1) (0,N)

EMPREGADOS DEPENDENTES

FIGURA4.48 entidade fraca

No exemplo acima, a entidade DEPENDENTES fraca e depende da existncia da entidade EMPREGADOS


para que possa existir. O atributo determinante de DEPENDENTES ser formado pelo atributo determinante de
EMPREGADOS (matricula) mais um atributo diferenciador pertencente a ela (numero). A representao grfica
nesse caso modificada tanto na entidade fraca, no relacionamento e na aresta que a vincula ao
relacionamento. Todos estes elementos passaram a ter linha dupla.

4.3.7.8 Recursos estendidos de Entidades e Relacionamentos: Embora seja possvel construir modelos
bastante completos somente pelo uso de entidades, atributos e relacionamentos, o tempo demonstrou que
novas figuras de modelagem se tornaram necessrias para melhor expressar a realidade observada. Nessa
seo abordaremos dois importantes elementos. So eles: Agregaes e Estrutura de Generalizao-
Especializao (SILBERSCHATZ, 2006, p.156).

Agregaes

Embora o MER seja bastante expressivo para representar uma gama vasta de situaes da vida real, ele possui
a limitao de no permitir o relacionamento entre relacionamentos. Em alguns casos (e no raros)
necessitamos vincular uma entidade C a um par, formado pelo relacionamento de outras entidades A e B. Ou
seja, precisamos construir um relacionamento entre a C com o relacionamento de A e B. Para resolver este
problema, adotamos uma estrutura denominada Agregao. Agregao uma abstrao pela qual os
relacionamentos so tratados como entidades de nvel superior (SILBERSCHATZ, 2006, p.156).

Agregao ento o tratamento de um relacionamento como sendo um conjunto de entidades. importante


ressaltarmos que os dois relacionamentos ocorrem em momentos distintos do tempo (SETZER, 2005).
Analisando o modelo proposto abaixo e tomando por base a linha do tempo, est sendo demonstrado que o
relacionamento REQUISITAM envolvendo as entidades PEDIDOS DE COMPRA e MATERIAIS d-se em um
primeiro momento. Em um segundo momento, d-se o relacionamento entre o agregado ITENS DE PEDIDO e a
entidade ORDENS DE COMPRA.

31/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Dessa forma, existe uma dupla formada pelo primeiro relacionamento que existir por um perodo de tempo e ao
juntar-se com o segundo relacionamento dar vida a uma tripla (SETZER, 2005, p.56).

Notao: Um agregado pode ser representado por um retngulo envolvendo o relacionamento das entidades.

ITENS PEDIDO
REQUISITAM
(0,N) (1,N)
PEDIDOS DE COMPRA MATERIAIS

(1,1)

ATENDEM

(0,N)

ORDENS DE COMPRA

FIGURA4.49 Agregao

Algumas regras sobre agregaes (SETZER, 2005, p.58):

- se a cardinalidade mnima do relacionamento entre a agregao e a outra entidade for 1, estaremos na


verdade tratando de um relacionamento ternrio ao invs de uma agregao. Em outras palavras, quando uma
agregao se relacionar com uma outra entidade, a cardinalidade mnima desse relacionamento com relao a
nova entidade dever ser 0, para que fique configurado que o primeiro relacionamento (gerador da agregao)
ocorre em um momento diferente do segundo relacionamento (da agregao com a outra entidade).

- Agregaes obrigatoriamente so oriundas de relacionamento M:N.

- Agregaes no possuem atributos. O que pode ocorrer a presena de atributos do relacionamento que dar
origem ao agregado.

- Agregaes tambm podero ocorrer em relacionamentos ternrios, porm com o mesmo objetivo, que o de
permitir que uma quarta entidade se relacione ao trio formado anteriormente, em um momento distinto do
momento em que o trio se relacionou inicialmente.

- Podemos representar a agregao de duas maneiras, conforme pode ser visto das figuras 4.50 e 4.51 abaixo.
Preferimos, no entanto, a segundo hiptese (figura 4.51), envolvendo somente o relacionamento.

32/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

A-B
R1
(0,N) (1,N)
A B

(1,1)

R2

(0,N)

FIGURA4.50 Notao alternativa para agregao

A-B
R1
(0,N) (1,N)
A B

(1,1)

R2

(0,N)

FIGURA4.51 Notao alternativa para agregao


Observe que a linha que vincula a entidade C ao relacionamento A-B, em ambos os casos, NUNCA ultrapassa o
retngulo simblico do agregado. fundamental que se observe este detalhe, sob pena de se ter um modelo
incorreto, com um relacionamento nem binrio, nem ternrio.

Generalizao e Especializao

A partir do processo de Abstrao possvel analisar o Mundo Real e dele extrair objetos, classes. Tal extrao
baseia-se na capacidade de se conseguir encontrar semelhanas entre determinados objetos de forma a
agrup-los em conjuntos. Atravs desse processo identificamos as Entidades que propiciam a elaborao de
Modelos Entidades e Relacionamentos.

Avanando no processo de modelagem, depois da tomada inicial de conhecimento dos objetos (entidades)
existentes no ambiente, parte-se para uma anlise mais profunda de tais elementos que permitir visualizar sub-
conjuntos dentro dos conjuntos inicialmente identificados. Outras vezes, se perceber semelhantes em
elementos colocados em objetos distintos, dando a idia de que esses objetos pertenam a um conjunto maior.
Surge ento uma nova figura de modelagem denominada Generalizao-Especializao. Generalizamos
objetos que foram modelados separados inicialmente, mas que pelas caractersticas observadas podero fazer
parte de um conjunto maior. Assim como, especializamos objetos que, tendo sido modelados inicialmente
como pertencentes a um nico conjunto, possuem algumas caractersticas distintas de outros indivduos do

33/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

mesmo conjunto. As caractersticas que permitem tais modificaes no modelo so tanto a presena de
atributos como de relacionamentos.

Por exemplo, ao analisar um ambiente hospitalar verificamos os seguintes elementos: MDICOS, PACIENTES,
QUARTOS, SALAS DE CIRURGIA. Observamos que cada conjunto identificado, conter um numero X de
elementos que se integram. Porm, numa anlise posterior, distingue-se no conjunto MEDICOS as categorias
MEDICOS RESIDENTES e MEDICOS EFETIVOS. Cada uma dos elementos da entidade MEDICOS tem apesar
de diversas caractersticas comuns algumas que so particulares a cada especializao, como por exemplo
(COUGO, 1997):
- todos os mdicos, indistintamente possuem uma matricula, um nome e uma especialidade.
- Quando tratar-se de um Efetivo tem-se, alm dos atributo descritos acima, um local de atuao, tempo de
permanncia e data de efetivao.
- Por outro lado, quando tratar-se de um Residente tem-se tambm uma data inicio da residncia, nome do
orientador, data avaliao.

Para resolver este problema, passamos a adotar uma nova figura no Modelo que representa esta presena de
Grupos e Subgrupos.

nome especialidade
matricula

MDICOS

Nome Tempo de
Data inicio
orientador Data Local de permanncia
Data
residncia avaliao atuao
efetivao

RESIDENTES EFETIVOS

FIGURA4.52 Estrutura de Generalizao-Especializao

Esta notao nos permite visualizar o conjunto maior (Entidade Genrica), MEDICOS, conectada aos seus
subconjuntos (Entidades Especficas) atravs de um triangulo. Dessa forma no temos trs entidades distintas,
mas sim, uma entidade representando o conjunto completo (MEDICOS) e duas entidades representando
subconjuntos extrados desse conjunto maior (RESIDENTES e EFETIVOS).

A partir dessa figura, podemos realizar a seguinte leitura.

- Todo RESIDENTE naturalmente um MEDICO, assim como,


- Todo EFETIVO tambm um MEDICO
- Todo MEDICO ou EFETIVO ou RESIDENTE

Um indivduo, Residente ou Efetivo, ter o conjunto de suas caractersticas (dados), formado pelas
caractersticas presentes na entidade genrica (MEDICOS) mais as caractersticas presentes na entidade
especfica ao qual se enquadra (RESIDENTES ou EFETIVOS).

Abaixo se encontra outro exemplo do uso da estrutura de Generalizao e Especializao, porm agora com 3
ramificaes de especializao.

34/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

nome
codigo Ano fabricao

MEIOS DE
TRANSPORTE

Quilometragem Profundidade
mxima mnima regio

Altitude Altitude
mnima mxima

TERRESTRE AQUATICO
AEREO

FIGURA4.53 Estrutura de Generalizao-Especializao

Regras para se identificar necessidade de Especializao (COUGO, 1997, p.122):

Regra1: Existe algum atributo que seja aplicvel a somente um subconjunto de elementos e no a todos.
Regra2: Existe algum relacionamento que seja aplicvel a somente um subconjunto de elementos e no a
todos?
Regra3: No poluir o modelo inserindo detalhes desnecessrios.
Regra4: Garantir a mxima compreenso do modelo com o mnimo de uso de recursos adicionais, como
dicionrios de dados, documentos, anexos.

Os dois modelos propostos acima (MEDICOS e MEIOS DE TRANSPORTE) refletem a situao de um processo
de projeto realizado com uma abordagem TOP DOWN, onde parte-se de um conjunto de entidades iniciais e vai
se refinando at alcanar nveis mais detalhados e representativos da realidade observa. Nesses dois exemplo,
realizou-se a Especializao das Entidades inicialmente propostas, quebrando-as em subgrupos. Outra
abordagem denominada BOTTOM UP, parte da anlise de elementos mais detalhados, e novamente a medida
que se analisa em detalhes cada um desses elementos, percebe-se semelhanas (atributos ou
relacionamentos) entre eles que permitam agrup-los em uma estrutura superior, resguardando suas
caractersticas particulares. Este processo de agrupamento denominado Generalizao. Mas no importa, se
o processo foi a Especializao ou a Generalizao. Ambos produzem modelos semelhantes. O ponto de
partida para a anlise que foi diferente. De fato, a generalizao uma inverso da especializao
(SILBERSCHATZ, 2006, p.152-153).

Os modelos propostos nos dois exemplos acima retratam um tipo de especializao no qual os subconjuntos
so mutuamente exclusivos, ou seja, dado um determinado indivduo pertencente Entidade Genrica, ele s
poder pertencer a uma nica Entidade Especfica. Um Mdico ou Residente ou Efetivo. Um Meio de
Transporte ou Terrestre ou Areo ou Aqutico. Nesses casos, diz-se que a as especializaes so
disjuntas, pois define que, um individuo, poder pertencer a no mximo uma entidade especializada a uma
Categoria. (COUGO, 1997, p.112-114; SETZER, 2005, p.63-64)

Em outros casos, encontramos especializao no-mutuamente exclusiva, ou seja, um individuo da Entidade


Genrica poder pertencer a mais que uma entidade especfica. Nesse caso dizemos que a especializao
no-disjunta ou Inclusiva, pois reconhece a possibilidade de um mesmo indivduo realizar papis distintos no
contexto. (COUGO, 1997, p.112-114; SETZER, 2005, p.63-64)

Como o smbolo utilizado para representar a especializao o mesmo, ou seja, um tringulo que vincula a
entidade genrica as suas entidades especficas, precisamos complement-lo de forma a distinguir as

35/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
especializaes disjuntas (categoria) das no-disjuntas (papeis). Na bibliografia consultada encontramos as
seguintes sugestes, ambas a serem escritas dentro do tringulo:

- Um X para especializao disjunta e um O para no-disjunto, ou


- Um C para especializao disjunta e um P para no-disjunto

Como as especializaes disjuntas so as mais comuns, podemos convencionar no acrescentar nenhuma


caracterstica nesses casos e adotar um P para representar a especializao no-disjunta.

Alem disso, precisamos distinguir a totalidade do vinculo entre a entidade genrica e as entidades especficas.
Se cada entidade do nvel superior precisa pertencer a um conjunto de entidades de nvel inferior, diz-se que
existe generalizao ou especializao total. No entanto, se alguma entidade do nvel superior pode no
pertencer a um conjunto de entidades de nvel inferior, diz-se que existe generalizao ou especializao
parcial. Podemos omitir qualquer simbologia adicional nos casos de generalizao parcial por ser o mais
comumente encontrado e podemos adotar um smbolo (bolinha cheia) somente para as totais. Nesse caso,
podemos optar por colocar a bolinha na linha que liga a entidade genrica ao tringulo.

A figura 4.54 abaixo demonstra uma estrutura de generalizao-especializao contendo os elementos grficos
adicionais: Uma bolinha cheia para indicar a parcialidade e a letra P para indicar que as entidades especificas
so papeis. Nesse exemplo, vemos que na entidade genrica G existem 5 indivduos. Um individuo (Pedro),
aparece em duas entidades especficas. No entanto, que fique claro, de que todo individuo que aparea em uma
entidade especfica, obrigatoriamente deve existir na entidade genrica.

Individuos de G:
ENTIDADE G Pedro, Paulo, Rita, Carlos, Fernando

ESPEC E1 ESPEC E3
Individuos de E1: ESPEC E2 Individuos de E3:
Pedro, Fernando Paulo, Rita, Carlos
Individuos de E2:
Pedro

FIGURA4.54 Estrutura de Generalizao-Especializao no-disjunta

4.3.8 Notao a ser adotada


Diversos so as notaes que podem ser utilizadas para representar um Modelo Conceitual. As mais difundidas
so as de James Martin e as de Peter Chen. Nesse trabalho estaremos adotando a notao de Peter Chen com
alguns elementos adicionais propostos ao longo desse material.

Elemento Descrio Smbolo


Entidade forte Retngulo simples

36/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
Elemento Descrio Smbolo
Entidade Fraca Retngulo duplo

Atributo Sero declarados a parte no dicionrio Monovalorado Sem smbolo


de dados
Multivalorado x{nome}y, onde x e y referem-se a
cardinalidade mnima e mxima de
ocorrncias.
Opcional (nome)
Composto
Determinante sublinhado
Relacionamento Um losango com uma seta dentro
indicando o sentido de leitura do verbo

Nome do Verbo no infinitivo COMPRAM


relacionamento Escrito do lado de fora do lasngo

Cardinalidade do Mnimos e mximos expressos dentro (X:Y) representando a cardinalidade mxima para
relacionamento de parntesis cada entidade pertencente ao relacionamento.

Limites de Sero alocados ao lado de cada (X,Y) onde X representa a cardinalidade mnima e Y
cardinalidade entidade pertencente ao representa a cardinalidade mxima.
relacionamento
Totalidade do Ser demonstrada pela cardinalidade
relacionamento mnima do relacionamento
Generalizao- Um tringulo tendo no topo a entidade
especializao (Gen- Genrica e na base as entidades
Espec) Especficas
Totalidade da Uma bolinha cheia ligando a entidade
Gen-Espec Genrica ao Tringulo somente para o
caso de totalidade. Quando for parcial
no ser usado nenhum smbolo. No
entanto, aqui a totalidade ser
expressa pela cardinalidade mnima.
Disjuno e No- Dentro do tringulo ser colocado: C
disjuno da C para Gen-Espec disjunto P
Gen-Espec P para Gen-Espec no-disjunto
Agregao Um retngulo envolvendo o losando do
relacionamento a ser agregado

Relacionamento Nenhum simbolo ser adotado


Independente
Relacionamento Ser representado por duas barras na ||
Contigente vertical cortando os relacionamentos
com esta caracterstica
Relacionamento Ser representado por uma barra na |
Mutuamente Exclusivo vertical cortando os relacionamentos
com esta caracterstica
FIGURA4.55 notaes utilizadas

4.3.9 Dicionrio de Dados


O dicionrio de dados uma relao de todos os elementos de dados componentes do sistema.

37/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Notao do Dicionrio de Dados

SMBOLO SIGNIFICADO
= composto de
+ E
() Opcional (pode estar presente ou ausente)
x{}y Iterao
[|] Escolha uma das opes alternativas
** Comentrio
@ Identificador (campo chave)
FIGURA4.56 notaes para dicionrio de dados

Algumas Explicaes:

= Definies: Smbolo que representa a definio de um elemento de dado. lido como definido como ou
composto de ou simplesmente significa.
Ex.: A = B + C , interpretado como A composto de B mais C ou ainda A definido como B e C.

() Elemento de dados opcionais: o elemento que pode ou no estar presente como um componente de um
elemento de dados composto.
Ex.: Endereo-cliente = (endereo-remessa) + (endereo-cobrana). Pode ser lido como sendo, um
Endereo-cliente pode ter endereo-remessa, ou endereo-cobrana ou ambos ou nenhum.

{}Iterao: Indica a ocorrncia repetida de um componente de um elemento de dados, onde X indica a


ocorrncia mnima e Y a ocorrncia mxima.
Ex.: Pedido = nome-cliente + endereo-remessa + 1{item}10. Significa que um Pedido deve ter o
nome do cliente, o endereo de remessa e no mnimo 1 e no mximo 10 itens. Pode-se ter as
seguintes combinaes para os limites da iterao:
1. X{}Y Informando limite inferior e superior
2. {}Y Informando somente limite superior
3. X{} Informando somente limite inferior
4. {} No informando nenhum limite

[ | ] Seleo: Indica que o elemento de dados consiste em exatamente uma escolha de um conjunto de opes
alternativas. As opes so delimitadas por colchetes [ e ] e separadas pelo caracter de barra vertical.
Ex.: Sexo [masculino | feminino]

Exemplo1:

NOME = TITULO-CORTESIA + PRIMEIRO-NOME + (NOME-INTERMEDIRIO) + ULTIMO-NOME


TITULO-CORTESIA = [ Sr. | Srta. | Sra. | Sras. | Dr. | Professor ]
PRIMEIRO-NOME = {CARACTER-VALIDO}
NOME-INTERMEDIARIO = {CARACTER-VALIDO}
ULTIMO-NOME = {CARACTER-VALIDO}
CARACTER-VALIDO = [ A Z | a z | 0 9 | | - | | ]

4.3.10 Exemplo de Modelo Conceitual Entidades-Relacionamentos.

O modelo de dados abaixo tem por objetivo demonstrar o produto do processo de modelagem de dados a nvel
conceitual tomando por base o modelo entidade-relacionamento. Este um cenrio hipottico, ou seja, no
reflete nenhuma situao real justamente para garantir que teramos condies de modelar diversos elementos
tericos abordados ao longo do capitulo.

38/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
COMPOEM
Modelo de Dados Fabrica de Chocolate Bombom
(1,N) (0,N)

CONSOMEM

MATERIAIS (1,N) (0,N) PROJETOS

c (0,N)

POSSUEM
FABRICACAO
COMPRADOS ALOCAO ATUAM (0,N) (1,1) CARGOS
INTERNA

UTILIZAM (1,N) (1,N)


(0,N)
(1,N)
(0,N)
COMPRAM
EMPREGADOS
(1,1)

COMPRAM ALUGAM
(0,N)
(0,N) (0,N)

(0,N) (0,1)
REPRESENTANTES
ARMAZENS

SITUAM-SE

AVALISAM
CLIENTES (1,1)
(0,N) (0,N)

LOCAIS

DICIONRIO DE DADOS
MATERIAIS = codigom + nome + quantidade
FABRICAO INTERNA = codigom + modelo + precocusto
COMPRADOS = codigom + precocompra + dataultimacompra
PROJETOS = codigop + nome + dataelaborao + objetivo
CLIENTES = codigoc + razaosocial + ENDEREO + (e_mail) + 1{telefones}
REPRESENTANTES = codigor + razosocial + endereo + (e_mail) + 1{telefones}
ARMAZENS = codigoa + telefone
LOCAIS = codigol + bairro + cidade
EMPREGADOS = codigoe + nome + dataadmissao
ALOCAO = datainicio + datafim
CARGOS = codigoc2 + nome + salario
ENDERECO=logradouro + numero + (complemento) + bairro + cidade + UF + CEP

FIGURA4.57 Exemplo de Modelo Conceitual Entidade-Relacionamento

39/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

4.4 MODELAGEM LGICA DE DADOS

4.4.1 Introduo

Uma vez obtido o Modelo Conceitual conforme descrito na seo 3.4, j temos condies de partir para um
modelo de implementao, ou seja, para um Modelo Lgico de Dados (MLD). Um Modelo Lgico aquele em
que os objetos, caractersticas e relacionamentos so representados de acordo com as regras de
implementao a partir das restries impostas por uma tecnologia. A obteno do modelo lgico se d pela
traduo dos elementos presentes no Modelo Conceitual (COUGO, 1997).

Tal converso baseia-se num conjunto de regras, que so aplicadas sobre o Modelo Conceitual. Cada regra
direcionada a atender a determinados requisitos associados tecnologia na qual o modelo ser construdo. Esta
tecnologia pode ser Relacional, Rede-Codasyl, Orientada a Objetos (COUGO, 1997).

Nesse caso, adota-se a Tecnologia Relacional e mais especificamente, Relacional Normalizada e por esta
razo, a converso do MCD para o MLD dever usar Regras para Bancos de Dados Relacionais. O produto
gerado pela traduo ser um Diagrama Relacional.

Modelos Lgicos esto associados a fase de Projeto de um projeto de software.

Com isso, pode-se obter um MLD a partir de um MCD seguindo os seguintes passos (COUGO, 1997):

Obter o MCD
Definir o tipo de Implementao (Relacional, Rede-codasyl, OO).
Aplicar as regras de derivao
Adaptar modelo s necessidades.

A simbologia utilizada no Diagrama Relacional a seguinte:

Tabelas (traduo das Entidades) so representadas por um Retngulo, com o nome da tabela escrito
dentro do retngulo. Observe que por se tratar de um objeto a ser compreendido e armazenado dentro de
um SGBD, aceita-se abreviaturas.

MATERIAIS Ou MAT

Colunas (traduo dos atributos) so representadas dentro do retngulo da tabela, com suas
respectivas caractersticas. Ex.: Tabela MATERIAIS representando a entidade MATERIAIS e as colunas
CODIGO, NOME e QUANTIDADE representando atributos com mesma nomenclatura.

MATERIAIS
CODIGOM
NOME
QUANTIDADE
FIGURA4.58 Tabelas e suas colunas

Ligaes (traduo dos relacionamentos) so representadas conforme a tabela abaixo. As regras para
anlise e traduo dos relacionamentos sero estudadas em detalhes na seo 4.4.3 Mapeamento do
MCD para o MLD.

40/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Cardinalidade Ligao

0,1

1,1

0,N

1,N

FIGURA4.59 Notao da cardinalidade para modelo lgico (p-de-galinha)

4.4.2 Propriedades do Modelo Relacional Normalizado


Para se garantir a perfeita adequao do Modelo Conceitual sem com isso perder as caractersticas modeladas,
precisamos respeitas e considerar as seguintes regras do Modelo Relacional.

Cada clula pode ser vazia ou conter no Mximo 1 valor.


A ordem das linhas irrelevante do ponto do visto do usurio.
No h duas linhas iguais
Cada coluna tem um nome
Duas colunas distintas devem ter nomes diferentes.
A partir do nome, a ordem das colunas irrelevante.
Cada relao tem um nome prprio diferente dos demais nomes de relao.
Os valores de uma coluna so retirados de um conjunto denominado Domnio.
Duas ou mais colunas podem ter o mesmo domnio

4.4.3 Mapeamento do MCD para o MLD (ELMASRI/NAVATHE, 2005, p.139-141; SILBERSCHATZ,


2006, p.161-165)

4.4.3.1 Entidade Regulares Para cada Entidade Forte E no MCD ser criada uma tabela T no MLD. Incluir
todos os atributos simples e os atributos compostos j decompostos como colunas em T. Por exemplo,
tomando a entidade CLIENTES e seus respectivos atributos presentes no MCD da figura 4.57 teramos
a seguinte traduo:

CLIENTES
CODIGOC <pk> not null
RAZAO_SOCIAL not null
LOGRADOURO not null
NUMERO not null
COMPLEMENTO null
BAIRRO not null
CIDADE not null
ESTADO not null
CEP not null
E_MAIL null

FIGURA4.60 Tabela derivada de entidade regular

Observando-se esta figura percebemos as seguintes caractersticas: A entidade CLIENTES deu origem a tabela
denominada CLIENTES. Cada atributo simples (codigoc, razo social, e_mail) da entidade CLIENTES tornou-se
um atributo simples na tabela CLIENTES. O atributo composto Endereo, foi desmembrado em seus vrios

41/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

componentes (logradouro, numero, complemento, bairro, cidade, estado e CEP). O atributo telefone aparecer
em outra tabela conforme ser definido no item 4.4.3.4.

4.4.3.2 Atributos Determinantes O Atributo Determinante de uma relao ser transformado na Chave
Primria da Tabela. Se o atributo determinante for composto na forma A=(a1, a2, a3), cada atributo que o
compe ser parte da Chave Primria da tabela. Ao observarmos a tabela CLIENTES da figura 4.60, percebe-se
que o atributo determinante codigoc tornou-se a Chave Primria da tabela.

4.4.3.3 Atributos Monovalorados Todos os atributos simples, monovalorados sero transformados em


colunas nas tabelas. De forma semelhante, percebe-se que todo atributo monovalorado presente na entidade
CLIENTES (codigoc, razo social e e-mail) tornou-se uma coluna na tabela clientes.

4.4.3.4 Atributos Multivalorados Para cada atributo multivalorado, criar uma nova tabela. Nessa nova
tabela o atributo no ser multivalorado. Tambm dever estar nessa nova tabela a PK da tabela origem de
onde o atributo multivalorado saiu. Essa PK, junto com o atributo que deixou de ser multivalorado formaro a PK
da nova tabela. Para preservar a multivalorao do atributo, a nova tabela ter uma cardinalidade N para 1 com
a tabela origem. Na entidade CLIENTES havia o atributo 1{telefones}, um multivalorado obrigatrio. A traduo
desse atributo produzir o modelo relacional da figura 4.61. Nesse caso, o atributo telefone deu origem a uma
nova tabela (TELEFONES_CLIENTE) contendo o numero do telefone e a Chave Primria da tabela ao qual ele
est vinculado. As duas colunas (codigoc e telefone) formaro a Chave Primria dessa nova tabela.

CLIENTES TELEFONES_CLIENTE
CODIGOC <pk> not null CODIGOC <pk,fk> not null
RAZAO_SOCIAL not null TELEFONE <pk> not null
LOGRADOURO not null
NUMERO not null
COMPLEMENTO null
BAIRRO not null
CIDADE not null
ESTADO not null
CEP not null
E_MAIL null

FIGURA4.61 Traduo de Atributo Multivalorado

4.4.3.5 Atributos Compostos Cada atributo composto dever ser desmembrado em atributos simples.
Conforme observa-se na figura 4.60, o atributo composto endereo foi desmembrado nos seus vrios
componentes (logradouro, numero, complemento, bairro, cidade, estado, CEP).

4.4.3.6 Entidades Fracas Para cada entidade fraca ser criada uma tabela. Incluir todos os atributos simples
e os atributos compostos j decompostos como colunas nessa tabela. Incluir tambm como Chave Estrangeira a
Chave Primria da tabela que corresponde Entidade Forte do relacionamento. Esta Chave Estrangeira, junto
com a chave parcial da entidade fraca formao a Chave Primria dessa tabela. Se a Entidade Forte do
relacionamento de uma determinada Entidade Fraca for tambm uma Entidade Fraca em outro relacionamento,
ento a Chave Primaria desse primeiro relacionamento dever ser identificada para ento derivar esta Chave
para o segundo relacionamento. Tomaremos como exemplo a situao proposta na seo 4.3.7.7 Entidade
Fraca, figura 4.48. A figura 4.62 abaixo expressa a soluo para derivao de entidades fracas.

EMPREGADOS DEPENDENTES

MATRICULA <pk> not null MATRICULA <pk,fk> not null


NOME not null NUMERO <pk> not null
DATA_ADMISSAO not null NOME not null
DATA_NASCIMENTO not null

FIGURA4.62 Traduo de Entidade Fraca

4.4.3.7 Relacionamentos Binrios Os relacionamentos sero traduzidos conforme a cardinalidade dos


mesmos.

42/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Relacionamento de Cardinalidade 1:1: Para ilustrar esse relacionamento usaremos a situao proposta na
figura 4.43. Nesse tipo de cardinalidade, podemos adotar 3 solues possveis:

o Transposio de Chave Estrangeira A coluna Chave Primria de uma das tabelas pertencentes
ao relacionamento ser transposta para a outra tabela onde passar a ser tratada como chave
estrangeira.

CERTIDOES_DE_NASCIMENTO
PESSOAS NUMERO <pk> not null
CODIGO <pk> not null CODIGO <fk> not null
NOME not null LIVRO not null
DATA_NASCIMENTO not null FOLHA not null
DATA_REGISTRO not null
FIGURA4.63 Traduo de Relacionamento 1:1 Transposio de Chave

Na figura 4.63 acima, o relacionamento foi traduzido transpondo-se a Chave Primria da tabela
PESSOAS (cdigo) para a tabela CERTIDOES_DE_OBITO, onde ser Chave Estrangeira. Alm
disso, o atributo de relacionamento (se houver) tambm poder ser alocado em
CERTIDOES_DE_OBITO

PESSOAS
CERTIDOES_DE_NASCIMENTO
CODIGO <pk> not null
NUMERO <fk> not null NUMERO <pk> not null
NOME not null LIVRO not null
DATA_NASCIMENTO not null FOLHA not null
DATA_REGISTRO not null

FIGURA4.64 Traduo de Relacionamento 1:1 Transposio de Chave (outra direo)

De forma semelhante, a figura 4.64 expressa a traduo do relacionamento transpondo a Chave


Primria da tabela CERTIDOES_DE_OBITO (numero) para a tabela PESSOAS, onde ser
Chave Estrangeira. Alm disso, o atributo de relacionamento (se houver) tambm poder ser
alocado em PESSOAS.

o Unificar em uma nica tabela Nessa opo, as entidades participantes do relacionamento so


fundidas em uma nica tabela. Esta opo pode ser apropriada quando o relacionamento total
nos dois sentidos. Caso um dos lados do relacionamento no seja total, os atributos referentes a
esta entidade devero ser nulos na tabela oriunda da fuso.

PESSOAS
CODIGO <pk> not null
NOME not null
DATA_NASCIMENTO not null
DATA_REGISTRO not null
NUMERO not null
LIVRO not null
FOLHA not null

FIGURA4.65 Traduo de Relacionamento 1:1 Fuso na tabela da esquerda

Na figura 4.65 acima, a traduo do relacionamento deu-se pela eliminao da tabela da direita e a
transposio dos atributos da mesma para a tabela da esquerda. Ao olhar a tabela PESSOAS,
vemos que as colunas cdigo, nome e data_nascimento pertenciam a entidade PESSOAS, a
coluna data_registro pertencia ao relacionamento e as colunas numero, livro e folha pertencem a
entidade CERTIDOES_DE_OBITO que j no existe mais.

43/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

CERTIDOES_DE_NASCIMENTO
NUMERO <pk> not null
LIVRO not null
FOLHA not null
CODIGO not null
NOME not null
DATA_DE_NASCIMENTO not null
DATA_REGISTRO not null

FIGURA4.66 Traduo de Relacionamento 1:1 Fuso na tabela da direita

De forma semelhante ao realizada na figura 4.65, a traduo do relacionamento tambm poder ser
feita pela fuso na tabela da esquerda do relacionamento. Ao olhar a tabela
CERTIDOES_DE_OBITO, vemos que as colunas numero, livro e folha pertenciam a entidade
CERTIDOES_DE_OBITO, as colunas cdigo, nome e data_nascimento pertenciam a entidade
PESSOAS e a coluna data_registro pertencia ao relacionamento.

o Tabela de Relacionamento a terceira soluo ser criar uma nova tabela para abrigar o
relacionamento. Esta soluo mais indicada para relacionamento de cardinalidade M:N.

REGISTRO CERTIDOES_DE_NASCIMENTO
PESSOAS
CODIGO <pk> not null CODIGO <pk,fk1> not null NUMERO <pk> not null
NOME not null NUMERO <pk,fk2> not null LIVRO not null
DATA_NASCIMENTO not null DATA_REGISTRO not null FOLHA not null

FIGURA4.67 Traduo de Relacionamento 1:1 criar tabela de relacionamento

Aqui surge a tabela REGISTRO que representa o relacionamento entre PESSOAS e


CERTIDOES_DE_OBITO. Tambm nessa nova tabela ser abrigado o atributo de relacionamento
(data_registro) se houver.

Relacionamento de Cardinalidade 1:N: Para ilustrar esse relacionamento usaremos a situao proposta
na figura 4.32 com os respectivos atributos conforme demonstramos abaixo. Nesse tipo de cardinalidade
podemos adotar 2 solues:

Razao Razao
CNPJ social CNPJ social
codigo codigo

POSSUEM
(1,1) (0,N)
EMPRESAS FILIAIS

FIGURA4.68 relacionamento 1:N

o Transposio de Chave Estrangeira inserir na entidade que possui a cardinalidade N a Chave


Primria da Entidade que possui cardinalidade 1 como Chave Estrangeira.

44/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
FILIAIS
EMPRESAS
CODIGOFILIAL <pk> not null
CODIGO <pk> not null CODIGO <fk> not null
CNPJ not null CNPJ not null
RAZAO_SOCIAL not null RAZAOSOCIAL not null

FIGURA4.69 Traduo de Relacionamento 1:N transposio de chave

o Tabela de Relacionamento Nessa soluo cria-se uma nova tabela para abrigar o
relacionamento, cujas colunas seriam duas Chaves Estrangeiras oriundas da Chave Primria das
duas entidades participantes do relacionamento. A Chave Primria dessa nova tabela ser a Chave
Primria da entidade de cardinalidade N. Esta pode ser uma alternativa quando poucos elementos
da entidade de cardinalidade N participam do relacionamento evitando-se assim excesso de valores
nulos na Chave Estrangeira.

EMPRESAS FILIAIS
EXPANSAO
CODIGO <pk> not null CODIGOFILIAL <pk> not null
CODIGO <fk1> not null CNPJ not null
CNPJ not null CODIGOFILIAL <pk,fk2> not null
RAZAO_SOCIAL not null RAZAOSOCIAL not null

FIGURA4.70 Traduo de Relacionamento 1:N criao de tabela de relacionamento

Relacionamento de Cardinalidade M:N: Nesse tipo de cardinalidade temos somente uma soluo:

o Tabela de Relacionamento Nessa soluo nica cria-se uma nova tabela para abrigar o
relacionamento, cujas colunas seriam duas Chaves Estrangeiras oriundas da Chave Primria das
duas entidades participantes do relacionamento. A Chave Primria dessa nova tabela ser formada
por todas as Chaves Estrangeiras oriundas da Chave Primria das tabelas origem. Ser utilizada a
figura 4.47 para ilustrar esta situao.

CDS
MUSICAS GRAVACAO
CODIGO <pk> not null
CODIGO <pk> not null CODIGO <pk,fk1> not null NOME not null
NOME not null CDS_CODIGO <pk,fk2> not null ANOCRIACAO not null
DURACAO not null FAIXA not null

FIGURA4.71 Traduo de Relacionamento 1:N criao de tabela de relacionamento

4.4.3.8 Relacionamentos enrios Os relacionamentos sero traduzidos conforme a cardinalidade dos


mesmos. Para ilustrar esse relacionamento usaremos a situao proposta na figura 4.30 com os respectivos
atributos conforme demonstramos abaixo.

nome Data admissao nome e_mail


matricula matricula
P-A-D

1 N
PROFESSORES ALUNOS

nome carga horaria


codigo
N

DISCIPLINAS

FIGURA4.72 relacionamento ternrio

45/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Soluo para traduzir relacionamento ternrio. Observe que para dar maior semntica ao modelo lgico,
renomeamos o relacionamento P-A-D pelo termo TURMAS. A soluo seria exatamente a mesma se a
multiplicidade fosse 1:1:1 ou 1:1:N ou M:N:N (SETZER, 2005, p.142).

PROFESSORES TURMAS ALUNOS

MATRICULA <pk> not null MATRICULA <pk,fk1> not null MATRICULA <pk> not null
NOME not null ALU_MATRICULA <pk,fk2> not null NOME not null
DATA_ADMISSAO not null CODIGO <pk,fk3> not null E_MAIL null

DISCIPLINAS
CODIGO <pk> not null
NOME not null
CARGA_HORARIA not null

FIGURA4.73 Traduo de Relacionamento ternrio

Tambm ser adotada a mesma soluo, ou seja, gerar uma tabela


para abrigar o relacionamento caso este seja de grau maior que 3
(SETZER, 2005, P.142).

4.4.3.9 Generalizao-Especializao A estrutura de Generalizao-Especializao suporta 3 solues de


traduo (COUGO, 1997, p.237-246). Tomaremos como exemplo a figura 4.52.

1 - Criar uma tabela para cada entidade generalizada e uma tabela para cada entidade especializada
nessa soluo a transposio do MCD para o MLD praticamente direta. A Chave Primria da tabela que
representa a entidade genrica ser a Chave Primria de cada tabela que representa cada entidade
especfica. Dessa maneira est se criando um relacionamento artificial entre a tabela genrica e as
especficas de cardinalidade 1:1.

MEDICOS
MATRICULA <pk> not null
NOME not null
ESPECIALIDADE not null

RESIDENTES EFETIVOS
MATRICULA <pk,fk> not null MATRICULA <pk,fk> not null
NOME_DO_ORIENTADOR not null LOCAL_DE_ATUACAO not null
DATA_INICIO_RESIDENCIA not null TEMPO_DE_PERMANENCIA not null
DATA_AVALIACAO not null DATA_EFETIVACAO not null

FIGURA4.74 Traduo da Generalizao-Especializao uma tabela para cada entidade

2 - Criar somente a tabela para a entidade generalizada e migrar todos os atributos e relacionamentos das
entidades especializadas para ela Nesse caso, existir somente a tabela representando a entidade

46/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

genrica e todos os atributos, dela e das entidades especficas que no esto sendo representadas por
tabelas. Tambm os relacionamentos das entidades especficas devero ser transferidos para a tabela
gerada. Nesse caso, os atributos das entidades especficas devero ser opcionais (nulos) na tabela que
representa a entidade genrica.

MEDICOS
MATRICULA <pk> not null
NOME not null
ESPECIALIDADE not null
NOME_DO_ORIENTADOR null
DATA_INICIO_RESIDENCIA null
DATA_AVALIACAO null
LOCAL_DE_ATUACAO null
TEMPO_DE_PERMANDENCIA null
DATA_EFETIVACAO null

FIGURA4.75 Traduo da Generalizao-Especializao fundir atributos na tabela genrica

3 - Criar somente tabelas para as entidades especializadas e migrar todos os atributos e relacionamentos
da entidade generalizada para cada uma dessas tabelas Esta soluo evita os problemas de nulidade
causada pela soluo anterior. Nessa soluo, fazemos o inverso da soluo anterior, pois criamos uma
tabela para cada entidade especfica e migramos os atributos e relacionamentos da entidade genrica para
cada tabela representativa de cada entidade especfica criada.

RESIDENTES EFETIVOS
MATRICULA <pk> not null MATRICULA <pk> not null
NOME not null NOME not null
ESPECIALIDADE not null ESPECIALIDADE not null
NOME_DO_ORIENTADOR not null LOCAL_DE_ATUACAO not null
DATA_INICIO_RESIDENCIA not null TEMPO_DE_PERMANENCIA not null
DATA_AVALIACAO not null DATA_EFETIVACAO not null

FIGURA4.76 Traduo da Generalizao-Especializao Desmembrar somente nas especficas

4.4.3.10 Agregao A traduo da Agregao se dar em duas partes: primeiro ser tratado o
aspecto relativo ao relacionamento (aquele que dar vida ao agregado), e em segundo lugar faremos a traduo
do aspecto relativo a entidade, ou seja, ao agregado e seus vnculos com os demais elementos do modelo
(COUGO, 1997, p.237-246). Para ilustrar esse relacionamento usaremos a situao proposta na figura 4.49 com
os respectivos atributos conforme demonstramos abaixo

data valortotal nome


numero ITENS PEDIDO codigo
quantidade
quantidade
REQUISITAM
(0,N) (1,N)
PEDIDOS DE COMPRA MATERIAIS

(1,1)

ATENDEM

data valortotal
numero

(0,N)

ORDENS DE COMPRA

FIGURA4.77 Agregao

47/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

Aspecto relativo ao relacionamento ser analisado inicialmente o relacionamento e claro a


cardinalidade que compe o agregado. A traduo dessa parte usar os mesmos critrios daquele adotado
para qualquer relacionamento visto anteriormente. No caso, por tratar-se de um relacionamento M:N, traduz-
se o relacionamento criando-se uma tabela para representar a referncia cruzada das duas entidades, cuja
Chave Primria ser formada pelas Chaves Estrangeiras oriundas das tabelas participantes do
relacionamento.

PEDIDOS_COMPRA ITENS_PEDIDO MATERIAIS

NUMERO <pk> not null NUMERO <pk,fk1> not null CODIGO <pk> not null
DATA not null CODIGO <pk,fk2> not null NOME not null
VALORTOTAL not null QUANTIDADE not null VALOR_UNITARIO not null

FIGURA4.78 Traduo da Agregao aspecto relativo ao relacionamento

Aspecto relativo Entidade Aps a derivao do relacionamento visto no item anterior, o agregado
passar a ser representado pela tabela gerada da derivao do relacionamento. Nesse caso, analisam-se
as demais partes do modelo conforme as regras de relacionamento estudadas anteriormente, sendo que
agora, o agregado reconhecido como uma tabela com identidade e para a qual podero fluir
relacionamentos ou de qual podero sair relacionamentos.

ITENS_PEDIDO
NUMERO <pk,fk1> not null
CODIGO <pk,fk2> not null
QUANTIDADE not null

ORDENS_COMPRA
CODIGO_ <pk> not null
NUMERO <fk> not null
CODIGO_MATERIAL <fk> not null
DATA not null
VALOR_TOTAL not null

FIGURA4.79 Traduo da Agregao aspecto relativo a entidade

A viso completa do Agregado traduzido conforme demonstrado abaixo.

PEDIDOS_COMPRA ITENS_PEDIDO MATERIAIS3

NUMERO <pk> not null NUMERO <pk,fk1> not null CODIGO <pk> not null
DATA not null CODIGO <pk,fk2> not null NOME not null
VALORTOTAL not null QUANTIDADE not null VALOR_UNITARIO not null

ORDENS_COMPRA
CODIGO_ <pk> not null
NUMERO <fk> not null
CODIGO_MATERIAL <fk> not null
DATA not null
VALOR_TOTAL not null

FIGURA4.80 Traduo da Agregao modelo completo

48/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
4.4.3.11 Auto-relacionamento A traduo do autor relacionamento dever considerar a cardinalidade
do mesmo e para tanto existem duas solues (COUGO, 1997, p.232-234; SETZER, 2005, p.140-141). Para
ilustrar esse relacionamento usaremos a situao proposta na figura 4.19 com os respectivos atributos conforme
demonstramos abaixo
Data admissao nome
nome codigo
matricula cargo quantidade

(1,N) (0,N)
(1,1) (0,N) MATERIAIS
FUNCIONRIOS


GERENCIA GERENCIADO COMPONENTE COMPOSTO
GERENCIAM DE COMPEM DE

FIGURA4.81 Exemplos de auto-relacionamento

Para auto-relacionamento de cardinalidade 1:1 e 1:N, migrar a Chave Primria da tabela para ela mesma
como chave estrangeira.

EMPREGADOS
MATRICULA <pk> not null
NOME not null
DATA_ADMISSAO not null
CARGO not null
EMP_MATRICULA_GERENTE <fk> not null

FIGURA4.82 Traduo do Auto-Relacionamento cardinalidade 1:1 ou 1:N

Para auto-relacionamento de cardinalidade M:N, criar uma nova tabela para comportar a referncia cruzada
entre os indivduos da tabela original. A Chave Primria da tabela original dever ser migrada duas vezes
para a nova tabela para que se passa construir os pares.

MATERIAIS
COMPOSICAO
CODIGO <pk> not null
NOME not null CODIGO <pk,fk1> not null
QUANTIDADE not null PRO_CODIGO <pk,fk2> not null

FIGURA4.83 Traduo do Auto-Relacionamento cardinalidade M:N

4.4.3.12 Valores Nulos para a PK em algumas situaes pode existir uma Foreign Key que suporte
valores nulos. Tais situaes esto descritas abaixo.

A(1,1) B(0,N) Na situao acima, a FK nunca ser nula pois cada elemento de B est associado a
no mnimo 1 elemento de A, ou seja, adotando a nomenclatura relacional, cada linha existente na tabela B
dever estar obrigatoriamente vinculada a uma linha de A, e como este vinculo se d pelo preenchimento da
coluna FK, ento ela sempre ter que ter valor.

A(1,1) B(1,N) Semelhante ao caso anterior, a cardinalidade mnica de B com A um, ou seja, toda
linha de B deve estar associada atravs da FK a uma linha de A, fazendo-a ser obrigatria.

49/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
A(0,1) B(0,N) ou B(1,N) Neste caso, a FK poder ser nula, pois a cardinalidade mnima de B para A
0, o que significa que pode existir alguma linha de B que no est ligado a nenhuma linha de A

4.4.4 Exemplo de Modelo Conceitual Entidades-Relacionamentos traduzido para o


Modelo Lgico Relacional. A figura 4.83 abaixo demonstra o MLD da traduo do MCD da figura 4.57.

composio
codigom_composto <pk,fk1> not null
codigom_componente <pk,fk2> not null

consumo
codigom <pk,fk1> not null projetos
codigop <pk,fk2> not null
materiais codigop <pk> not null
nome not null
codigom <pk> not null dataelaboracao not null
nome not null objetivo not null
quantidade not null

alocacao
CARGOS
comprados codigop <pk,fk1> not null
fabricacaointerna codigoe <pk,fk2> not null codigoc2 <pk> not null
codigom <pk,fk1> not null datainicio <pk> not null nome not null
codigom <pk,fk> not null
codigoe <fk2> not null codigoc2 <fk3> not null salario not null
modelo not null
precocompra not null datafim not null
precocusto not null
dataultimacompra not null

empregados
uso
codigoe <pk> not null
codigom <pk,fk1> not null nome not null
com_codigom <pk,fk2> not null dataadmissao not null

compras alugueis
codigom <pk,fk1> not null codigor <pk,fk1> not null
codigoc <pk,fk2> not null codigoa <pk,fk2> not null
representantes
codigor <pk,fk3> not null
codigor <pk> not null armazens
razaosocial not null
logradouro not null codigoa <pk> not null
numero not null codigol <fk> not null
bairro not null telefone not null
cidade not null
estado not null
cep not null
e_mail null
clientes avalistas
codigoc <pk> not null codigor <pk,fk1> not null
razaosocial not null codigoa <pk,fk2> not null
logradouro not null
numero not null
bairro not null
cidade not null telefones
estado not null
cep not null codigoc <pk,fk> not null locais
e_mail null telefone <pk> not null
codigol <pk> not null
bairro not null
cidade not null

FIGURA4.83 Modelo Lgico obtido da traduo do MCD da figura 4.57.

50/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

4.5 NORMALIZAO

A Normalizao um processo surgido com o aperfeioamento do Sistema Relacional na dcada de 70, e tem
por objetivo, simplificar as tabelas bem como, a obteno do Modelo Lgico a partir do Modelo Conceitual. Este
processo de simplificao segue um conjunto de regras, denominadas Formais Normais. O processo de
adequao das tabelas a estas regras chamado de Normalizao.

A normalizao busca evitar que dentro de uma tabela exista mistura de assuntos que podem provocar
redundncias desnecessrias nos dados (MACHADO, 2004, p. 181). Durante o processo de normalizao,
analisa-se a relao para determinar algum tipo de interdependncia entre os atributos e nesse caso,
transformar tais atributos em novas tabelas (TEOREY, LIGHTSTONE, NADEAU, 2007, p.111). Dessa maneira,
alcanamos tabelas purificadas e imunes a anomalias de atualizao que por sua vez podem causar problemas
tais como: grupos repetitivos, dependncias parciais de chave concatenada, redundncias de dados
desnecessria, etc (MACHADO, ABREU, 1996, p.165).

Para realizar a normalizao necessrio que cada tabela a ser analisada tenha uma Chave Primria que
permite identificar as demais colunas (MACHADO, 2004, p.182).

Atualmente so 6 as formas normais. Cada forma normal representa um conjunto cada vez mais rigoroso de
regras, e que quanto mais alta a forma normal ao qual o projeto corresponda, melhor este ser (HARRINGTON,
2002, p.85). No entanto, se voc conseguir colocar suas tabelas at a 3 Forma Normal, j ter resolvido a
maioria dos problemas de projeto.

A figura 4.84 abaixo expressa estas formas normais. Nela possvel perceber que se uma tabela estiver em
uma forma normal mais interna (mais alta) estar tambm em todas as formas normais abaixo dela (mais
externa).

Primeira Forma Normal

Segunda Forma Normal

Terceira Forma Normal

Forma Normal de Boyce_Codd

Quarta Forma Normal

Quinta
Forma
Normal

FIGURA4.84 Formais Normais (Harrington, 2002, p.85)

4.5.1 Anomalias de Modificao

Considere estrutura de dados proposta na figura 4.85 abaixo. Nela possvel perceber que estamos abrigando
dentro de uma nica estrutura elementos de assuntos distintos (Pedidos, Fornecedores e Produtos) ainda que

51/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
relacionados. Uma estrutura dessa maneira est sujeita de um conjunto de anomalias de modificao, j que,
se tentarmos eliminar o pedido numero 5, estaremos eliminando por conseqncia todos os dados relativos
ao Fornecedor computer. Se quisermos incluir um novo produto, no temos condies de faz-lo sem que
este esteja atrelado a um pedido. E por fim, se houver alguma alterao no endereo de um determinado
Fornecedor, temos que atualizar em diversos registros.

No entanto, se for possvel desmembrar os elementos de cada assunto em estruturas separadas, tais problemas
sero amenizados, ou at mesmo resolvidos.

PEDIDO
Num. Data Nome CNPJ Endereo Produtos
Pedido Emisso Fornec. Cd. Nome Qtde. Preo
Produto Produto Unit.
003 20-jan Software 12345-78 Av. Lapa 777, Lapa 033A DOS 04 130,00
RJ 20000 002M COREL 01 499,00
145J ABC 13 256,00
004 27-Jan Brasoft 23456-89 R. Itu 49, Itu SP 002M COREL 02 450,00
11000 083P ZAPT 10 85,00
005 27-Jan Computer 34567-00 R. Vitoria 12, Vitoria 033A DOS 50 110,00
ES 30000 145J ABC 50 110,00
006 14-Mar Brasoft 23456-89 R. Itu 49, Itu SP 029K WIN 15 200,00
11000 083P ZAPT 10 87,00
FIGURA4.85 Estrutura Desnormalizada

4.5.2 Formas Normais

Primeira Forma Normal (1FN): Qualquer tabela que atenda a definio de uma relao est na Primeira
Forma Normal. Uma tabela, para que possa representar uma relao deve ter nas suas clulas valores nicos,
ou seja, no permitir colunas ou grupos de repetio ou arrays como valores. Todos os valores de uma coluna
devem ser do mesmo tipo. No importa a ordem das colunas nem das linhas contanto que cada coluna tenha
um nome exclusivo e que as linhas no sejam idnticas (KROENKE, 1999, p.89). Por isso, diz-se que a 1FN faz
parte da definio formal de uma tabela no modelo relacional (ELMASRI,NAVATHE, 2005, p.224.

Para Cougo, (1997, p.185), uma tabela est na primeira forma normal se:

Est integrado por tabelas: Se estamos modelando para modelos lgicos relacionais devemos respeitar o
conceito bsico relativo ao objeto tabela, ou seja, uma estrutura bidimensional formado por linhas e colunas;

As linhas da tabela so unvocas: Deve-se obrigatoriamente definir identificador (es) unvoco(s) ou chave(s)
primaria(s) da tabela de forma a garantir a diferenciao entre duas linhas de uma tabela;

As linhas no contem itens repetitivos: So valores ou grupos de valores que se repetem para determinado
elemento da relao. So tambm chamadas colunas multivaloradas;

Os Atributos so atmicos: Denominamos atmicos itens de dados indivisveis. Conjuntos de itens atmicos
podem formar um item composto;

Os atributos no contem valores nulos: Refere-se a no permitir que existam colunas com valor nulo na
tabela. Embora, atualmente, no h mais restrio quanto existncia de valores nulos em colunas de uma
tabela.

Processo de Obteno da Primeira Forma Normal:

Definir as Chaves Candidatas e escolher a Chave Primria: A partir da escolha de um ou mais atributos
de uma tabela, deve-se buscar diferenciao entre uma linha e outra.

52/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio
Transformar atributos compostos em atmicos: Atributos compostos, que claramente tenham elementos
distintos em sua estrutura, devero ser separados.

Eliminar grupos repetitivos: Significa desmembrar as colunas com valores repetidos de forma a termos
somente atributos atmicos monovalorados.

Etapas do processo de normalizao da 1 Forma Normal:

Acabar com os itens de repetio As repeties ou multivaloraes podem ser resolvidas de 3 formas
diferentes: 1) Desmembramento em novas tabelas, 2) Desmembramento em novas linhas ou 3)
Desmembramento em novas colunas. Analisemos cada elemento individualmente (ELMARSI,NAVATHE,
2005, p.225).

1) Desmembramento em novas tabelas: Nessa soluo, os itens repetitivos sairo da tabela original
(PEDIDO) e daro origem em uma nova tabela (ITENS_PEDIDO). A Chave Primria dessa nova tabela
(ITENS_PEDIDO) ser formada pela Chave Primria da tabela origem (PEDIDO) mais a coluna ou a
coluna representativa do grupo que saiu da tabela origem. Aplicando na tabela desnormalizada da figura
4.85, temos a seguinte soluo:

PEDIDO
Num. Data Nome CNPJ Endereo
Pedido Emisso Fornec.
003 20-jan Software 12345-78 Av. Lapa 777, Lapa RJ 20000
004 27-Jan Brasoft 23456-89 R. Itu 49, Itu SP 11000
005 27-Jan Computer 34567-00 R. Vitoria 12, Vitoria ES 30000
006 14-Mar Brasoft 23456-89 R. Itu 49, Itu SP 11000
FIGURA 4.86 Estrutura com desmembramento de atributos/grupos multivalorados novas tabelas

ITEM_PEDIDO
Num. Cd. Nome Qtde. Preo
Pedido Produto Produto Unit.
003 033A DOS 04 130,00
003 002M COREL 01 499,00
003 145J ABC 13 256,00
004 002M COREL 02 450,00
004 083P ZAPT 10 85,00
005 033A DOS 50 110,00
005 145J ABC 50 110,00
006 029K WIN 15 200,00
006 083P ZAPT 10 87,00
FIGURA 4.87 Estrutura com desmembramento de atributos/grupos multivalorados novas tabelas

2) Desmembramento em novas linhas: Nessa soluo, os itens repetitivos sero desmembrados


dentro da mesma tabela porem em linhas, uma para cada repetio. Nesse caso, a chave primria da
tabela dever ser revista para comportar a redundncia da parte comum a ser repetida para formar as
novas linhas. Aplicando na tabela desnormalizada da figura 4.85, temos a seguinte soluo:

PEDIDO
Num. Data Nome CNPJ endereo Cd. Nome Qtde. Preo
Pedido Emisso Fornec. Produto Produto Unit.
003 20-Jan Software 12345-78 Av. Lapa 777, Lapa RJ 20000 033A DOS 04 130,00
003 20-jan Software 12345-78 Av. Lapa 777, Lapa RJ 20000 002M COREL 01 499,00

53/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

003 20-jan Software 12345-78 Av. Lapa 777, Lapa RJ 20000 145J ABC 13 256,00
004 27-Jan Brasoft 23456-89 R. Itu 49, Itu SP 11000 002M COREL 02 450,00
004 27-Jan Brasoft 23456-89 R. Itu 49, Itu SP 11000 083P ZAPT 10 85,00
005 27-Jan Computer 34567-00 R. Vitoria 12 Vitoria ES 30000 033A DOS 50 110,00
005 27-Jan Computer 34567-00 R. Vitoria 12 Vitoria ES 30000 145J ABC 50 110,00
006 14-Mar Brasoft 23456-89 R. Itu 49, Itu SP 11000 029K WIN 15 200,00
006 14-Mar Brasoft 23456-89 R. Itu 49, Itu SP 11000 083P ZAPT 10 87,00
FIGURA 4.88 Estrutura com desmembramento de atributos/grupos multivalorados novas linhas

Observe que a Chave Primria dessa nova tabela ser formada por um elemento da parte repetida
(cabealho do PEDIDO) e outra por um elemento da parte desmembrada (corpo do PEDIDO).

3) Desmembramento em novas colunas: Nessa soluo, os itens repetitivos sero desmembrados


dentro da mesma tabela em novas colunas. Vale lembrar que esta soluo s deve ser adotada se o
numero de ocorrncias for conhecido e no muito grande. Aplicando na tabela desnormalizada da figura
4.85, temos a soluo abaixo.

PEDIDO
Num. Cd. Nome Qtde1. Preo Cd. Nome Qtde2. Preo Cd. Nome Qtde3. Preo
Pedido Produto1 Produto1 Unit1. Produto2 Produto2 Unit2. Produto3 Produto3 Unit3.
003 033A DOS 04 130,00 002M COREL 01 499,00 033A DOS 04 145J
004 002M COREL 02 450,00 083P ZAPT 10 85,00
005 033A DOS 50 110,00 145J ABC 50 110,00
006 029K WIN 15 200,00 083P ZAPT 10 87,00
FIGURA 4.89 Estrutura com desmembramento de atributos/grupos multivalorados novas colunas

Observe que nessa soluo, devemos considerar que em algumas linhas encontraremos colunas nulas,
pois o numero de ocorrncias menor do que o previsto. Alm disso, nessa soluo, como pr-
definimos a quantidade de colunas que sero construdas para abrigar o contedo, no temos a
flexibilidade de armazenarmos um determinado pedido que tenha mais produtos do que o previsto no
modelo. Para que no paire dvidas, suprimimos do modelo os atributos data emisso, nome fornec,
CGC e endereo simplesmente por questo de espao. Os mesmos esto simbolicamente
representados pelas 4 colunas em branco logo aps a coluna num.pedido.

Em modelos de dados que possuam mais que um atributo ou grupo


multivalorado, a melhor soluo desmembr-los em novas tabelas
(alternativa 1) descrita acima (ELMASRI,NAVATHE, 2005, p.227).

Transformar os Atributos Compostos em Atributos Atmicos. Analisando a tabela, vamos considerar


que Data de Emisso e CGC sero mantidos como Atmicos, e o Endereo, ser considerado com
composto e nesse caso, devemos decomp-lo conforme abaixo. Alm disso, utilizamos como tabela fonte
para esta decomposio a tabela da figura 4.86 oriunda da primeira soluo para atributos compostos vistos
anteriormente. A tabela da figura 4.87 no foi alterada pois no possui atributos compostos, mantendo-se
inalterada conforme demonstra a figura 4.91.

PEDIDO

Num. Data Nome CNPJ Logradouro Numero Cidade Uf cep


Pedido Emisso Fornec.
003 20-jan Software 12345-78 Av. Lapa 777 Lapa RJ 20000
004 27-Jan Brasoft 23456-89 R. Itu 49 Itu SP 11000
005 27-Jan Computer 34567-00 R. Vitoria 12 Vitoria ES 30000
006 14-Mar Brasoft 23456-89 R. Itu 49 Itu SP 11000
FIGURA 4.90 Estrutura com desmembramento de atributos compostos

54/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

ITENS_PEDIDO
Num. Cd. Nome Qtde. Preo
Pedido Produto Produto Unit.
003 033A DOS 04 130,00
003 002M COREL 01 499,00
003 145J ABC 13 256,00
004 002M COREL 02 450,00
004 083P ZAPT 10 85,00
005 033A DOS 50 110,00
005 145J ABC 50 110,00
006 029K WIN 15 200,00
006 083P ZAPT 10 87,00
FIGURA 4.91 Estrutura com desmembramento de atributos compostos no sofreu alterao

Definir uma Chave para que tenhamos unicidade nas linhas da tabela. Em algumas situaes, pode
ocorrer da perda da integridade da chave primria, especialmente quando se adota reduzir os atributos
multivalorados desmembrando-os como linhas na mesma tabela (conforme visto anteriormente). Por isso,
necessrio rever as colunas da tabela para se determinar a Chave Primria da mesma. No caso, somente
na soluo proposta na figura 4.88 seria necessrio rever a Chave acrescentando coluna cod.produto
conforme demonstrado abaixo.

PEDIDO
Num. Cd. Data Nome CNPJ Logradouro Num Cidade Uf cep Nome Qtde. Preo
Pedido Produto Emisso Fornec. Produto Unit.
003 033A 20-Jan Software 12345-78 R. Lapa 777 Lapa RJ 20000 DOS 04 130,00
003 002M 20-jan Software 12345-78 R. Lapa 777 Lapa RJ 20000 COREL 01 499,00
003 145J 20-jan Software 12345-78 R. Lapa 777 Lapa RJ 20000 ABC 13 256,00
004 002M 27-Jan Brasoft 23456-89 R. Itu 49 Itu SP 11000 COREL 02 450,00
004 083P 27-Jan Brasoft 23456-89 R. Itu 49 Itu SP 11000 ZAPT 10 85,00
005 033A 27-Jan Computer 34567-00 R. Vitoria 122 Vitoria ES 3000 DOS 50 110,00
005 145J 27-Jan Computer 34567-00 R. Vitoria 122 Vitoria ES 3000 ABC 50 110,00
006 029K 14-Mar Brasoft 23456-89 R. Itu 49 Itu SP 11000 WIN 15 200,00
006 083P 14-Mar Brasoft 23456-89 R. Itu 49 Itu SP 11000 ZAPT 10 87,00
FIGURA 4.92 Redefinio de chave para alternativa de desmembramento em linhas para atributos/grupos
multivalorados.

Uma vez realizada a Normalizao da 1 Forma Normal, chegamos a uma situao de modelo no qual os
problemas de atributos compostos e multivalorados j no existem mais. No entanto, aquelas questes
propostas anteriormente continuam em aberto. So elas:

Somente pode-se incluir um novo fornecedor, se for includo um novo pedido para este fornecedor.
Se for eliminado o pedido nmero 005, perde-se junto, todas as informaes do fornecedor Computer.
Se for alterada a data do pedido 003, tem-se que alterar vrias linhas da tabela (esta situao somente se
manifesta quando se opta por desmembrar os atributos multivalorados em novas linhas).

Para tratarmos desses problemas, devemos avanar no processo de normalizao. Porm, precisamos, antes
disso, introduzir o conceito que ir sustentar estas outras Formas Normais, que o de Dependncia Funcional
e sobre o qual a maior parte da teoria de normalizao foi baseada (MACHADO, ABREU, 1996, p.172).

Dependncia Funcional a situao na qual, um atributo x de uma entidade X funcionalmente dependente


de outro atributo y tambm presente na mesma entidade X, ou seja, se a cada valor de x corresponde
exatamente um valor de y. Por exemplo, suponha uma entidade CLIENTES que possuam diversos atributos e
entre eles o atributo ESTADO e DDD, representando a Unidade Federativa e o DDD onde ele mora. Nesse
caso, sempre que o atributo ESTADO tiver o valor ES, o DDD ter o valor 27. Diz-se ento que o atributo
DDD funcionalmente dependente do atributo ESTADO (MAYER, 2001, p.30). Em outras palavras, dizer que

55/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

um atributo y dependente de um atributo x significa dizer que basta conhecer o valor x para se chegar a um
nico valor do atributo y. O atributo x determina o valor do atributo y (MACHADO, 2004, p.187).

A Dependncia Funcional pode ser total ou transitiva. Diz-se que h uma dependncia funcional total
quando existe uma Chave Primria composta e os atributos presentes na relao (e que no so chave)
dependem da chave como um todo e no somente de parte da chave (MACHADO, ABREU, 1996, p172-173). A
figura 4.87 referente a normalizao de 1 Forma Normal demonstra uma situao de dependncia total de
chave primria. Os atributos qtde e preo unit dependem totalmente da Chave Primria composta num
pedido e cod produto para que se conheam os seus valores. Podemos resumir ento que a dependncia
funcional total ou completa s ocorre em tabelas que possuam Chave Primria composta.

Por outro lado, a dependncia funcional transitiva ocorre quando a interdependncia entre os atributos se d
sem que algum dos atributos seja Chave Primria da tabela. Observe a tabela da figura 4.86. Analisando os
atributos CNPJ e Nome Fornec percebe-se que se conhecermos o valor do CNPJ conheceremos o valor do
Nome Fornec, no entanto, o CNPJ no Chave Primria da tabela. Diz-se ento que o atributo Nome Fornec
depende transitivamente do atributo CNPJ. Este, o CNPJ, depende por sua vez da Chave Primria da tabela.

A determinao das dependncias funcionais requer a interpretao semntica dos valores armazenados nos
elementos da relao, ou seja, depende de uma anlise humana de tais valores o que torna difcil a
mecanizao desse processo (MAYER, 2001, p.31).

Segunda Forma Normal (2FN): A Segunda Forma Normal baseada no conceito de Dependncia Funcional
Total visto anteriormente. Uma tabela est na segunda forma normal, se (COUGO, 1997, p.200-202):

Ela est na Primeira Forma Normal: Para se aplicar a 2FN, deve-se garantir que a tabela est na 1FN.

Cada uma das colunas no pertencentes Chave Primria, no for dependente parcialmente dessa chave:
Havendo Chave Primria composta, ou seja, formada por mais de uma coluna, todas as demais colunas da
tabela devem ser dependentes da chave como um todo e no s de parte da chave. Se uma tabela tiver
somente uma coluna como Chave Primria, ela estar automaticamente, na 2FN .

Na tabela da figura 4.87, tem-se a situao na qual as colunas Cod. Produto e Nome Produto possuem
uma interdependncia entre elas sem com isso depender obrigatoriamente da Chave Primria completa da
tabela a qual esto associadas. Note que para conhecermos o nome do produto basta que se conhea o
Cd Produto. No entanto, a Chave Primria formada por Cod. Pedido + Cod. Produto.

Processo de Obteno da Segunda Forma Normal:

Identificar as Colunas que no participam da Chave Primria da Tabela.

Para cada uma das colunas identificadas, analisar se o seu valor determinado por parte ou pela totalidade
da Chave Primria.

Para as colunas que forem identificadas como sendo dependentes parcialmente da chave:

o Criar novas tabelas (tantas quantas forem as dependncias parciais) para abrigar as colunas que so
dependentes parcialmente da Chave Primria;
o Excluir essas colunas da tabela original;
o A Chave Primria dessas novas tabelas ser a parte da Chave Primria da tabela original que
determinava o valor das colunas dependentes parcialmente.

Tomemos como exemplo a tabela da figura 4.87. Ao aplicarmos a regra definida acima, temos:

Identificar as colunas no Chave: nome produto, qtde. e preo unit.

Identificar as dependncias parciais: Para cada uma das colunas descritas anteriormente, analisar as
dependncias:

56/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

COLUNA DEPENDNCIA CHAVE


NOME PRODUTO PARCIAL COD PRODUTO
QTDE TOTAL NUM PEDIDO + COD PRODUTO
PRECO UNIT TOTAL NUM PEDIDO + COD PRODUTO
FIGURA 4.93 Anlise de dependncia parcial de chave composta

Criar novas tabelas com as colunas dependentes parcialmente das chaves e excluir essas colunas
da tabela original. O resultado demonstrado na figura 4.94 abaixo:

ITEM_PEDIDO
Num. Cd. Qtde. Preco
Pedido Produto Unit.
003 033A 04 130,00
003 002M 01 499,00
003 145J 13 256,00
004 002M 02 450,00
004 083P 10 85,00
005 033A 50 110,00
005 145J 50 110,00
006 029K 15 200,00
006 083P 10 87,00
FIGURA 4.94 Tabela PEDIDO, renomeada para ITEM_PEDIDO contendo somente as colunas com
dependncia total da Chave Primria composta.

PRODUTO
Cd. Nome
Produto Produto
033A DOS
002M COREL
145J ABC
083P ZAPT
029K WIN

FIGURA 4.95 Tabela PRODUTO, contendo somente as colunas com dependncia parcial da Chave Primria
composta, no caso a coluna cod. produto.

Se a Chave Primria tiver um nico atributo, no precisa se analisada


para a 2 Forma Normal (ELMASRI,NAVATHE, 2005, p.227).

Ao final da anlise de 2FN a tabela inicial deu origem a uma nova tabela (PRODUTO, figura 4.95) para abrigar
os atributos com dependncia parcial.

Terceira Forma Normal (3FN): A Segunda Forma Normal baseada no conceito de Dependncia Funcional
Transitiva visto anteriormente. Uma tabela est na terceira forma normal, se (COUGO, 1997, p.209-211)

Est na segunda forma normal

Nenhuma coluna no pertencente chave, fica determinada transitivamente por esta. Por dependncia
transitiva, pode-se entender a situao onde um atributo depende de outro e este segundo depende de um
terceiro. Pode-se tambm dizer que possui dependncia transitiva, um atributo que depende de um outro
atributo chave presente na Tabela, mas esta chave, no a Chave Primria.

57/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

A dependncia transitiva de uma chave s ser possvel se a tabela tiver ao menos duas colunas no
pertencentes chave. Caso tenhamos somente uma coluna externa chave, essa tabela j estar
automaticamente na 3FN.

Processo de Obteno da Terceira Forma Normal:

Identificar as Colunas que no participam da Chave Primria da Tabela.

Para cada uma das colunas identificadas, analisar se o seu valor determinado por alguma outra coluna
no pertencente Chave.

Para colunas dependentes transitivamente da chave, deve-se:

o Criar novas tabelas para estas colunas;


o Excluir da tabela origem as colunas dependentes transitivamente das chaves mantendo e que foram
deslocadas para novas tabelas, porm, manter a coluna determinante da transitividade na tabela
origem;
o A chave primria dessas novas ser(o) a(s) coluna(s) que determinou(aram) o valor da coluna
analisada.

Para analisar tais dependncias conforme as regras acima tomaremos as tabelas das figuras 4.90, 4.94 e 4.95
(PEDIDO, ITEM_PEDIDO e PRODUTO respectivamente). Vale destacar que estas 3 tabelas j se encontram na
2 Forma Normal. A tabela da figura 4.90 no precisou ser analisada na 2 FN, pois possui Chave Primria
formada por um nico atributo, ao passo que as tabelas das figuras 4.94 e 4.95 surgiram do desmembramento
de 2FN realizado sobre a tabela da figura 4.91.

Aqui tambm encontramos nova restrio. Tabelas que possuam um nico atributo alm da Chave Primria
esto automaticamente na 3 Forma Normal. Por isso, no analisaremos a tabela da figura 4.95. Nossa anlise
ento se centrar nas tabelas da figura 4.90 e 4.94. A figura 4.96 abaixo demonstra as tabelas que iremos
analisar, cada atributo no chave dessas tabelas e se existe ou no dependncia transitiva. Caso exista, a
coluna que determina a dependncia ser demonstrada em DEPENDNCIAS TRANSITIVAS.

TABELA COLUNAS DEPENDNCIAS TRANSITIVAS


PEDIDO data emissao No possui
PEDIDO nome fornec CNPJ
PEDIDO cnpj nome fornec
PEDIDO Logradouro CNPJ
PEDIDO Numero CNPJ
PEDIDO Cidade CNPJ
PEDIDO Uf CNPJ
PEDIDO CEP CNPJ
ITEM_PEDIDO Qtde No possui
ITEM_PEDIDO Preo No possui
FIGURA 4.96 Anlise de dependncia transitiva

Analisar as Dependncias Transitivas, individualmente:

A coluna data emisso no determinada, conhecida a partir de nenhuma outra coluna presente na
tabela, ou seja, ela depende do conhecimento da Chave Primria para conhecermos o seu valor.
A coluna nome fornec poder ser conhecida a partir do conhecimento da coluna CNPJ. Dessa forma, ela
no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna cnpj tambm poder ser conhecida a partir do conhecimento da coluna nome fornec. Dessa
forma, ela no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna logradouro tambm poder ser conhecida a partir do conhecimento da coluna cnpj. Dessa
forma, ela no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.

58/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

A coluna numero tambm poder ser conhecida a partir do conhecimento da coluna cnpj. Dessa forma,
ela no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna cidade tambm poder ser conhecida a partir do conhecimento da coluna cnpj. Dessa forma,
ela no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna uf tambm poder ser conhecida a partir do conhecimento da coluna cnpj. Dessa forma, ela no
depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna cep tambm poder ser conhecida a partir do conhecimento da coluna cnpj. Dessa forma, ela
no depende do conhecimento somente da Chave Primria para conhecermos o seu valor.
A coluna qtde no determinada, conhecida a partir de nenhuma outra coluna presente na tabela, ou seja,
ela depende do conhecimento da Chave Primria para conhecermos o seu valor.
A coluna preco unit tambm no determinada, conhecida a partir de nenhuma outra coluna presente na
tabela, ou seja, ela depende do conhecimento da Chave Primria para conhecermos o seu valor.

Aps tal anlise, caso existam colunas com dependncia transitiva, deve-se criar novas tabelas para abrig-
las:

PEDIDO
Num. Data CNPJ
Pedido Emisso
003 20-Jan 12345-78
004 27-Jan 23456-89
005 27-Jan 34567-00
006 14-Mar 23456-89
FIGURA 4.97 Tabela PEDIDO, contendo somente as colunas com dependncia da Chave Primria.

FORNECEDOR
CNPJ Nome Fornec. Logradouro Numero Cidade Uf cep
12345-78 Software Av. Lapa 777 Lapa RJ 20000
23456-89 Brasoft R. Itu 49 Itu SP 11000
34567-00 Computer R. Vitoria 12 Vitoria ES 30000

FIGURA 4.98 Tabela FORNECEDOR, contendo as colunas que foram eliminadas da tabela PEDIDO devido a
dependncia transitiva

ITEM_PEDIDO
Num. Cd. Qtde. Preco
Pedido Produto Unit.
003 033A 04 130,00
003 002M 01 499,00
003 145J 13 256,00
004 002M 02 450,00
004 083P 10 85,00
005 033A 50 110,00
005 145J 50 110,00
006 029K 15 200,00
006 083P 10 87,00
FIGURA 4.99 Tabela PEDIDO que no sofreu alterao pois nenhuma de suas colunas possuem dependncia
transitiva.

59/61
Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense
Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

PRODUTO
Cd. Nome
Produto Produto
033A DOS
002M COREL
145J ABC
083P ZAPT
029K WIN
FIGURA 4.100 Tabela PRODUTO (oriunda da tabela da figura 4.95) que no sofreu alterao, pois j estava na
3 Forma Normal.

Ao analisarmos as tabelas descritas na 3 Forma Normal, possvel validar se as anomalias de Insero,


Alterao e Excluso definidas na seo 4.5.1 Anomalias de Modificao.

Se desejarmos eliminar o pedido 5, no mais perderemos os dados do Fornecedor computer.


Podemos incluir um novo produto sem ter que vincul-lo a um pedido.
Qualquer alterao nos dados de um determinado Fornecedor agira somente no registro a ele pertencente.

Dessa forma, podemos concluir que ao alcanarmos as 3 primeiras Formas Normais obtermos um modelo livre
dessas anomalias.

O Quadro abaixo faz um resumo das trs Formas Normais estudadas acima com as aes previstas para cada
uma.

TESTE PARA A FORMA NORMAL (AES) NORMALIZAO


1 Forma Normal A relao no deve conter atributos no Formar uma nova relao para cada atributo
atmicos ou relaes aninhadas. S deve no atmico ou para cada relao aninhada.
conter atributos atmicos
2 Forma Normal Para as relaes que possuam chave Decompor e montar uma nova relao para
primria composta (com vrios atributos), cada chave parcial com seus atributos
nenhum atributo externo deva ser dependentes. Manter, na relao original, a
funcionalmente dependente de parte da chave composta com todos os atributos que
chave. dependam totalmente dela.
3 Forma Normal As relaes no devem ter atributos que Decompor e montar uma nova relao para
dependam de qualquer outro atributo todos os atributos que tenham dependncia
presente na mesma relao, sendo que transitiva. A chave da nova relao ser o
esse atributo determinante no seja atributo que determinava a transitividade na
chave primria. No deve haver relao origem. Este atributo permanecer na
dependncia transitiva entre um atributo relao origem para criar o vinculo com a
no-chave e a chave primria. nova relao.
FIGURA 4.101 Resumo para Formas Normais e Aes Previstas (baseada em ELMARSI,NAVATHE, 2005,
p.229)

60/61
@matricula
Nome
Nome
Cargo
salario
(0,N)

Fundao de Assistncia e Educao Faculdades Integradas Espiritosantense


Unidade: Computao e Sistemas
Prof. Eliana Caus Sampaio

BIBLIOGRAFIA

[1] COUGO, P. Modelagem Conceitual e Projeto de Banco de Dados. Rio de Janeiro: Campus, 1997.

[2] DATE, C.J. Introduo a Sistemas de Banco de Dados. 8ed. Rio de Janeiro: Elsevier, 2003.

[3] ELMASRI, R., NAVATHE, S. B. Sistemas de Banco de Dados. 4ed. So Paulo: Adisson Wesley, 2005.

[4] HEUSER, C. A. Projeto de Banco de Dados. Porto Alegre: Instituto de Informtica da UFRGS: Sagra
Luzzatto, 2001.

[5] KORTH, H. F. & SILBERSCHATZ, A. Sistema de Bancos de Dados. Rio de Janeiro: Elsevier, 2006.

[6] KROENKE, D.M. Banco de Dados. Fundamentos, projeto e implementao. Rio de Janeiro: LTC, 1999.

[7] HARRINGTON, J. L. Projetos de Bancos de Dados Relacionais. Teoria e Prtica. 2ed. Rio de Janeiro:
Campus, 2002.

[8] MACHADO, F. N. R., ABREU, M. Projetos de Bancos de Dados. Uma viso prtica. So Paulo: rica,
1996.

[9] MAYER, R. C. Otimizando a performance de Bancos de Dados Relacionais. Rio de Janeiro: Axel Books,
2001.

[10] POMPILHO, S. Anlise Essencial guia prtico de Anlise de Sistemas. Rio de Janeiro: Editora
Cincia Moderna Ltda, 2002.

[11] PRESSMAN, R.S. Engenharia de Software. 5ed. Rio de Janeiro: McGraw-Hill, 2002.

[12] SETZER, W. W. Banco de Dados. 1ed. So Paulo: Edgard Blucher, 2005.

[13] SHLAER, S., MELLOR, S. J. Anlise de Sistemas Orientada para Objetos. So Paulo: McGraw-Hill :
Newstec, 1990.

[14] SQL Magazine. Rio de Janeiro: DEVMEDIA Group, Ed. 16. Ano 2. 2004.

[15] TEOREY, T., LIGHTSTONE, S., NADEAU, T. Projeto e Modelagem de Banco de Dados. Rio de Janeiro:
Elsevier, 2007.

[16] TOGNERI, D. F. Notas de Aula. Disciplina Analise e Projeto de Sistemas. 2005.

[17] YOURDON, E. Anlise Estruturada Moderna. Traduo da terceira edio americana. Rio de Janeiro:
Campus, 1992.

61/61