Documente Academic
Documente Profesional
Documente Cultură
Dados
Guia de Estudo
Paulo Rocha Neto
Know How
São Luís Maranhão 2007
Projeto de Software Paulo Rocha Neto
ÍNDICE
1. ENTIDADE ......................................................................................................................... 10
2. ENTIDADE FRACA................................................................................................................ 10
3 ATRIBUTO ......................................................................................................................... 11
4 RELACIONAMENTO .............................................................................................................. 14
7 GENERALIZAÇÃO................................................................................................................. 20
8 ESPECIALIZAÇÃO ................................................................................................................. 25
9 AGREGAÇÃO ...................................................................................................................... 26
BIBLIOGRAFIA ................................................................
................................................................................................
.....................................................................
.....................................29
.....29
1
Modelagem de Dados Paulo Rocha Neto
Dados e Realidade
Um dos aspectos mais importantes a ser observado pelos projetistas de Bancos de Dados e seus pares da
administração de dados é que projetar um Banco de Dados é, na realidade, um intrigante exercício de
simulação de um pedaço do universo da empresa. Para isso, dispomos de um conjunto tipo "lig-lig" de
estruturas, símbolos, caixas e setas que, montados como num jogo de "Lego", formam uma linguagem
reconhecida e digerível pelo computador. Essa simulação visa, na realidade, transformar a nuvem esquisita,
amorfa e semanticamente ambígua que representa a realidade de dados e processos da empresa, em
losangos e retângulos que ilustram as linguagens gráficas disponíveis nas ferramentas e metodologias de
hoje. A essa técnica, de escultura quase semântica, chamamos de Modelagem de Dados. Gradativamente
refinada pela prática, a Modelagem de Dados foi desenvolvida ao longo dos anos 70 e possui uma
paternidade discutível. Em suas origens são encontrados DNA de Charles Bachman, James Martin, Peter
Chen e outros, mas é desse último, o rótulo MER (Modelo de Entidades e Relacionamentos) que se
transformou em quase sinônimo da técnica. As técnicas de Modelagem são usadas para registrar os dados
nos mais diferentes níveis de abordagem (de planejamento estratégico de negócios a modelo lógico de
implementação). Essa, aliás, é uma das primeiras indagações normalmente surgidas num processo de
Modelagem de Dados de uma empresa ou de parte dela: o seu nível de abrangência horizontal e de
profundidade vertical. Até onde se estendem os limites elásticos da modelagem de dados? Isso acontece
justificado pelas características fluídicas apresentadas pelos dados, o que os levam a habitar diferentes
regiões funcionais da empresa, normalmente atrelados a processos diferentes e, por vezes, encapados por
sentidos e interpretações até, conflitantes. Não é à toa que esse conjunto de objetos semânticos tem o
nome de "entidades" e, parece, que sua correlação com os correspondentes do sincretismo religioso não é
mera coincidência.
Como o objetivo da modelagem é dar fidelidade à representação das "coisas do mundo" através do
computador, as fronteiras de seus conceitos não são rigorosamente definidas. Isso confere à Modelagem de
Dados um sabor muito mais de arte do que tonalidade de ciência exata. Os dados podem demonstrar toda
essa sua elasticidade polimórfica (assumir várias formas), dependendo do contexto e das regras de negócio
que os envolvem. Suponha, por exemplo um Banco de Dados genérico, onde a Entidade PESSOA seja o
objeto maior. Essa Entidade PESSOA seria uma classe e teríamos várias subclasses para caracterizar suas
peculiaridades. Um dos relacionamentos que certamente apareceriam nesse modelo seria o tipo de
interações entre elas (as pessoas). Usei a palavra interação para não usar a palavra óbvia "relacionamento",
pois vários tipos de relacionamentos aparecerão, como: casamento, filiação, apadrinhamento etc. Ou seja,
CASAMENTO é um relacionamento entre pessoas. Razoável não? Teria dados de data, padrinhos etc. Agora,
imagine o modelo de dados de um Cartório, onde desejo um sistema que controle todos os tipos de
REGISTROS CÍVEIS (casamento, divórcio, morte etc.) efetuados. Certamente, agora, CASAMENTO poderia
ser visto como um dos tipos de Entidades de Dados (Registro) que surgiria no modelo de dados. Ou seja, às
vezes, Entidades e Relacionamentos não possuem fronteiras rígidas. Os conceitos de Entidades de
Relacionamento ou Associativas, a serem discutidos nos capítulos específicos, foram cunhados exatamente
para esse propósito, No fundo esses objetos darão origem a registros no momento de implementação
(considerando os atuais Gerenciadores de Bancos de Dados) e aí somem todas as diferenças conceituais -
Os modelos de dados estendidos cada vez mais buscam aprimorar essas representações semânticas,
conforme também será discutido mais adiante.
A finalidade da modelagem de dados, que diferentemente do Brasil é para principiantes, é pavimentar esse
caminho nada retilíneo e ajudar na garimpagem desses elementos e suas abstrações. Hoje, todas as
linhagens metodológicas em prática, visando ao desenvolvimento de sistemas de informação, usam a análise
e modelagem de dados como processo fundamental para compreensão dos dados e de sua complexa
personalidade.
Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994.
2
Modelagem de Dados Paulo Rocha Neto
Modelagem de Dados
Modelagem de Dados é uma atividade desenvolvida em fases variadas do processo metodológico de
desenvolvimento de sistemas, com a finalidade de garimpar informações para a obtenção do modelo de
dados. Um modelo de dados a nível macro pode ser obtido em fases de planejamento, por exemplo,
enquanto modelos de dados detalhados podem ser obtidos em fases de análise e projeto. Tudo depende do
foco que se deseja aplicar ao trabalho de levantamento e seus objetivos.
1 O Modelo de Dados
Modelo de Dados é a representação gráfica e textual das ESTRUTURAS, dos OPERADORES e das REGRAS
que definem dados. As Estruturas são formadas de:
• As Regras são asserções que regulam o funcionamento dessas estruturas.
• Os Operadores, embora equivocadamente não considerados como parte dos modelos de dados, são
os comandos que permitem a manipulação das estruturas segundo as regras estabelecidas. Os
operadores não serão objetos diretos desse texto.
Com a finalidade de se tentar harmonizar esse balaio de conceitos pouco claros, alguns autores como
Barbara Von Halle, Ronald Ross e outros têm exercitado propostas interessantes a respeito de RN. O
primeiro passo tem sido o estabelecimento de uma correlação clara entre FATOS, RESTRIÇÕES e REGRAS
de DERIVAÇÃO com as regras de negócios.
Fato: é definido como sendo uma asserção que estabelece que um objeto tem determinadas propriedades
ou desempenha determinado papel. Por exemplo: CLIENTE tem endereço ou CLIENTE emite FATURA. Um
fato pode ser visto também como combinações de estruturas gramaticais do tipo sujeito verbo objeto. Por
exemplo: CX-INFO atua em New York.
Restrições: são limitações colocadas aos fatos para diminuição de ocorrências válidas naquele universo.
Por exemplo: Um PEDIDO deve ser colocado para uma CLIENTE cadastrado.
Regras de Derivação: são condicionantes colocadas sobre fatos e que podem gerar outros fatos. Por
exemplo: Se um PEDIDO for colocado até o dia 15 do mês ele será processado no mês corrente.
Todos esses novos ingredientes relacionados a fatos, permitem uma melhor captura do universo das Regras
de Negócios e facilitam a identificação de suas possíveis formas de implementação em sistemas de Bancos
de Dados. Porque podemos afirmar isso? Simplesmente pelo fato de que essas técnicas propõem na
realidade, uma estratégia de decompor o universo das regras de negócios em formas atômicas de
pensamento. Seria algo como uma unidade lógica mínima de expressão de negócio, sem que haja perda de
sentido. Por exemplo: O fato CLIENTE emite PCM é uma unidade mínima para expressar uma verdade ou
uma asserção. Qualquer decomposição efetuada sobre esse fato acarretará perda de semântica (CLIENTE
emite ???, ou ??? emite PCM) Uma expressão ou fato como CLIENTE envia um PEDIDO e tem um limite de
crédito, na realidade engloba dois fatos em um único e poderia ser decomposto em CLIENTE envia PEDIDO
e CLIENTE tem um limite de crédito. Uma das principais dicas para decomposição de fatos compostos em
fatos atômicos é a presença de conectores lógicos (e, ou, não etc) na expressão do fato.
A garimpagem das Regras de Negócios sobre o prisma de fatos atômicos conduz a descoberta de
ENTIDADES e RELACIONAMENTOS, como no expresso por ÓRGÃO emite PCM. Duas Entidades e um
relacionamento podem ser levantados na expressão desse fato. Outros fatos sugerem além de Entidades,
alguns atributos específicos, como por exemplo CLIENTE tem limite de crédito.
Alguns fatos,digamos compostos, porém não passíveis de decomposição, indicam relacionamentos de ordem
maior como por exemplo ÓRGÃO requisita MATERIAL em ALMOXARIFADOS locais. Esse fato, que não pode
ser decomposto sem perdas, aponta para um relacionamento ternário clássico e já originou até uma das
formas de normalização (5a FN) para tratamento de fatos valorados dependentes. A expressão de fatos com
restrições permite a garimpagem de relacionamentos e suas características. Por exemplo: Um CLIENTE tem
no mínimo um endereço de correspondência, mas pode ter vários. Esse fato é a própria indicação do
relacionamento entre CLIENTE e algo que pode ser definido como atributos multivalorados ou entidade
fraca.
Uma abordagem baseada em Regras de Negócios pode ser realizada através dos seguintes passos:
• Levantar os problemas, objetivos e requerimentos necessários ao negócio do sistema.
• Decompor os objetivos e requerimentos em unidades lógicas mínimas de pensamento, ou Regras de
Negócios.
• Definir o consenso sobre cada Regra de Negócio garimpada.
• Classificar as Regras de Negócios em Definições, Fatos, Restrições e Regras de derivação.
• Analisar cada Fato, Restrição, Definição e Regra de Derivação garimpando as Entidades de Dados,
Relacionamentos e primeiros atributos emergentes.
• Refinar o Modelo de Dados através de funções, eventos e outras informações complementares.
O formalismo sobre REGRAS de NEGÓCIOS, na realidade possui certa semelhança com outros conceitos já
discutidos em várias abordagens anteriores. Os conceitos de eventos da análise essencial ou de ações do
novo modelo de Chen são manifestações com inspiração próxima dessas idéias. Na realidade, a busca
espartana por métodos que auxiliem no flagrante dos negócios de sistemas é dever de todos. O cuidado é
para não descer em labirintos de termos novos, com sentidos quase sempre conhecidos e turbinados por
modismos ocos.
4
Modelagem de Dados Paulo Rocha Neto
Seria RN mais uma ação da velha e indivisível indústria do vocábulo e da consultoria, como sempre
engenhosa e criativa, induzindo ações modernas através da reembalagern de conceitos antigos?
5
Modelagem de Dados Paulo Rocha Neto
Além disso, o modelo funcional obtido em nível de eventos apresenta-se revestido de certa facilidade de
articulação, pois os processos chamados essenciais, nesse nível, estão fechados em si e só se comunicam
através dos depósitos de dados, nunca via fluxos. Isso facilita a sua distribuição para implantação por
equipes distintas, bastando para isso somente um consenso a implantação por equipes distintas, bastando
para isso somente um consenso a respeito dos layouts dos depósitos comunicadores.
A falta de costume com a abordagem, bem como a confusão do conceito de Eventos com relação a Função
e Processos leva a uma dificuldade inicial que o tempo, a experiência e o exercício contínuo se incumbem de
desfazer.
Para entender o conceito de Eventos:
Os eventos são disparadores de processos. Logo, os eventos externos estão relacionados com fluxos
externos de dados. Pode-se imaginar que a chegada de alguns fluxos externos (nem todos) determinam
alguns eventos e, por conseqüência, o seu processo. Esses são os eventos externos.
Outros eventos são disparados por um mecanismo interno tipo "clock" sem motivações externas. São os
eventos temporais. É como se existisse um relógio interno no sistema que em certos momentos disparasse
processos, não provocados por fluxos externos.
Como os eventos são produtores de estímulos ao sistema, ao término deles (resposta de cada evento) o
sistema retornará ao seu estado de inatividade, até ser ativado novamente por outro evento.
Analisando-se cada entidade externa no Diagrama de Contexto, e questionando a sua inter-relação com o
sistema, garimpa-se facilmente os eventos externos.
Analisando-se eventos externos iniciais, pode-se obter outros pela regra de contrários (Ex.: Cliente emite
pedido, e o evento contrário, cliente cancela pedido).
Analisando-se eventos externos iniciais, pode-se obter eventos sucessores e antecessores. Analise também a
NÃO - ocorrência do Evento e suas conseqüências.
Deve-se atentar para o fato de eventos empacotados e falsamente percebidos como único. Para isso, analise
o fluxo de chegada de um evento e verifique se para todas as ocorrências do evento os dados serão os
mesmos.
Como método prático, inicie a garimpagem dos eventos pelo Diagrama de Contexto, ou seja, a visão mais
macro do seu sistema. Para os casos onde o Diagrama de Contexto não pôde ainda ser obtido, inicie pela
Análise de Dados, criando o Modelo de Dados e através das Entidades e Relacionamentos garimpe os
Eventos. A criação, eliminação e alteração dos objetos e de seus relacionamentos é fonte fidedigna de
origem de eventos. As alterações de um valor de um objeto, no fundo, representa uma mudança de estado
dele e também sugere eventos. Por exemplo, Cliente e Pedidos são objetos do MER de um sistema de
Materiais e um relacionamento de solicitação existe. Logo, um evento de solicitação e outro de
cancelamento de Pedidos poderão ser inferidos via MER.
1. Faça algumas confirmações quando terminado o modelo dos eventos:
Cada evento externo possui fluxo de entrada?
Cada evento externo possui um ou mais fluxo de saída?
Cada evento esta produzindo saída imediata, ou armazenando dados para processamentos
posteriores?
2. Considere as seguintes regras para rotular eventos:
Para eventos externos, ou seja, aqueles iniciados por uma ação externa ao sistema:
Entidade externa + verbo + objeto Ex.: Cliente emite pedido. Para eventos temporais ou internos,
ou seja, aqueles disparados por um mecanismo de clock interno do sistema: É hora de <verbo>
<fluxo>/ <objeto>. Ex.: E hora de emitir relatório financeiro para diretoria. Alguns eventos internos
podem ser disparados por acontecimentos outros, além do aspecto temporal. Por exemplo, o ponto
de reabastecimento de estoque. E o caso de eventos internos, onde alguns atributos ao atingirem
determinados valores pré-definidos, disparam um processo associado. São denominados Eventos
Condicionais e podem ser identificados por: É hora de <ação> por causa de <condição>.
Alguns exemplos de eventos em sistemas de Informação
6
Modelagem de Dados Paulo Rocha Neto
Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994.
7
Modelagem de Dados Paulo Rocha Neto
O Modelo Conceitual
Modelo conceitual é o modelo em que os dados são vistos como objetos conceituais em nossas mentes, isto
é, estamos no mundo das idéias. Neste modelo estão incluídos todos os dados formais e informais,
necessários a operação das organizações, descritos de forma adequada.
Um modelo conceitual engloba bem mais do que a simples pretensão de representar a realidade. Seu
emprego encontra a utilização mais nobre relacionado ao processo criativo. Desvinculado da criação,
modela-se o que existe, e, como conseqüência, muitas vezes, apenas se automatiza o que é feito de forma
manual. A modelagem oportuniza contato com as práticas operacionais existentes. O questionamento destas
práticas muitas vezes possibilita a descoberta de funções duplicadas ou conflitantes. Eliminar estes e outros
aspectos nocivos é também criação. Um modelo é uma antecipação do futuro, sendo portanto também uma
definição de como queremos o futuro.
Idêntica função tem uma planta baixa ou maquete na área da construção civil. Elas são uma linguagem
gráfica simples, que o usuário precisa entender, e são usadas no processo de criação de alternativas, bem
como para aprovação e obtenção da escolhida. Nelas se definem localizações de portas, janelas, corredores,
paredes, tubulações embutidas, etc. A planta serve como orientação para a primeira versão e como guia do
que futuramente vai ser possível ou não de se modificar. Além de auxiliar na visualização e no perfeito
entendimento do que se está projetando, a planta também representa um compromisso formal entre as
partes. Imagine-se um eventual proprietário de uma casa que resolve unificar dois ambientes derrubando
uma parede e constata que lá existe uma tubulação qualquer. Ele poderá ficar aborrecido, mas, se esta
tubulação constar da planta arquitetônica que ele aprovou, não lhe cabe outra alternativa senão reconhecer
o problema como dele. Imaginemos que ele argumente não ter se dado conta de que devia ter se
preocupado com estes detalhes. Neste caso pode ter acontecido que o engenheiro falhou, impondo sua
solução sem validá-la exatamente com aquele que iria conviver com o produto gerado. A estes profissionais
lembramos que a mais espetacular criação arquitetônica pode não satisfazer a um usuário simplório. Esta é
uma analogia que visa conscientizar da importância não só da participação, mas também do entendimento e
concordância do usuário. Pois sabendo ou não, ele está sendo corresponsabilizado com a solução. O mínimo
de ética profissional nos indica que devemos alertá-lo para isso.
No que diz respeito aos sistemas de informações, fazer um modelo de dados conceitual significa criar uma
representação da realidade, para usá-la como ferramenta de especificação de uma base de dados e de um
conjunto de processos para sua geração e manutenção.
O modelo é também o instrumento de comunicação que o analista usa para induzir o usuário a descrever
sua organização, sua realidade, seu negócio. Porém, o analista deve policiar sua tendência técnica
(tendência a pensar em termos de sistemas, arquivos, programas, etc.), para que possa ver as coisas tanto
quanto possível do ponto de vista do usuário. É imprescindível que analista, usuário e administrador de
dados (AD), não só entendam o modelo, mas que também concordem e se comprometam com a solução
adotada. Através dele as partes envolvidas passam a conhecer a abrangência e as informações que vão ser
manipuladas. Muitos analistas e ADs tentam, através de argumentação variada, impor ao usuário a sua
solução, cometendo dupla falta: uma profissional pois não estão sendo honestos com o usuário; e a segunda
com o Centro de Processamento de Dados (CPD) que espera a co-autoria do usuário para também
responsabilizá-lo pela solução adotada, como forma de garantir qualidade e como estratégia para manter o
cliente.
Existindo tantas alternativas, o que deve ser considerado, na escolha de um modelo em detrimento aos
demais? As seguintes qualidades caracterizam um bom modelo:
• Completeza: Deve possibilitar a representação de todas as características da realidade. Não deve
necessitar anotações complementares;
• Precisão: A representação deve ser precisa, com associação natural às características
representadas. Não deve necessitar anotações complementares;
• Simplicidade: O número de conceitos deve ser pequeno;
8
Modelagem de Dados Paulo Rocha Neto
• Consistência: Os conceitos utilizados devem ser independentes entre si. Cada conceito do modelo
deve ter um significado distinto. Todos os conceitos do modelo devem ter uma única interpretação,
independente de contexto;
• Ortogonalidade: Cada característica da realidade deve ter apenas uma forma de ser representada;
• Diagramação: Os conceitos devem ter uma forma de representação gráfica. Pode-se dizer que o
sucesso de um modelo depende em grande parte da sua representação gráfica. Um modelo tem boa
diagramação se ele é graficamente completo e sua representação é de fácil leitura. O número de
símbolos deve ser pequeno.
• Expressividade: Riqueza semântica inerente que serve de guia para expressar as restrições e as
propriedades dos dados. Possibilita uma melhor compreensão do mundo real representado.
Algumas destas características desejadas se opõem como expressividade e simplicidade: Se um modelo é
semanticamente rico, ele pode não ser simples, etc. Então devemos buscar por um modelo que, no conjunto
de características desejadas, atinja satisfatoriamente as consideradas indispensáveis e de forma aceitável as
demais.
Optamos pelo modelo entidade-relacionamento estendido, por considerarmos que ele atende
satisfatoriamente os itens referentes a "precisão", "simplicidade", "consistência", "diagramação", e
razoavelmente aos demais.
O Modelo entidade-relacionamento foi proposto por Peter Chen como alternativa para representar o mundo
real, dentro de uma ótica simplificada, qual seja, de que a realidade consiste de entidades e seus
relacionamentos.
Existem muitas propostas de extensões ao modelo original. Neste texto muitas delas foram incorporadas,
outras adaptadas e outros conceitos foram propostos, sempre com o intuito de aumentar o potencial
semântico do modelo adotado.
Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994 e Eti, Francisco –
Engenharia de Informações: conceitos, técnicas e métodos – Porto Alegre: Sagra: D.C. LUZZATTO, 1993.
9
Modelagem de Dados Paulo Rocha Neto
1. Entidade
Qualquer coisa (concreta ou abstrata), a respeito da qual devam ser mantidas informações em uma base de
dados (pessoas, lugares, objetos, eventos, itens fundamentais de interesse da organização, etc.).
O termo "entidade" foi proposto para designar um específico componente, e "conjunto de entidade" como o
conjunto de todas as entidades de mesma espécie, portanto com propriedades comuns. Ex: João da Silva é
uma "entidade", do "conjunto de entidade" Pessoa. Porém, o que se nota na prática, é a utilização do termo
"entidade", com o significado de "conjunto de entidades". Ex: Normalmente falamos na entidade Pessoa,
quando queremos referenciar todo o conjunto de Pessoas. E, mais interessante, esta simplificação não causa
qualquer problema de comunicação. Devido a isto, neste trabalho, adotamos a terminologia consagrada na
prática. "Entidade", para nós, assume o significado do "conjunto de entidades", preferindo-se o termo
"Entidade" porque simplifica a comunicação. Quando quisermos referenciar um específico representante de
uma entidade (conjunto de entidade), usaremos o termo "ocorrência-de-entidade". Ex: João da Silva é uma
"ocorrência-de-entidade" da "entidade" Pessoa.
É uma representação abstrata de um objeto do mundo real. Pode ser a representação de um ser, de um
fato, de uma coisa, de um organismo social, etc. Todo objeto que tiver “vida própria” dentro do sistema em
estudo, ou seja, que existir naturalmente pode ser considerado como uma entidade. Por exemplo, são
entidades as representações abstratas de um Funcionário, um Projeto, um Departamento, etc.
Podemos considerar um grupo de entidades que têm características semelhantes como formando conjunto
de entidades, como por exemplo, o conjunto dos Contribuintes, o conjunto das Notas Fiscais.
Devido a questões de simplificação da terminologia, adotaremos o nome do conjunto de entidades sempre
no singular.
Para evitar uma redundância na representação das informações, cada objeto do mundo real deve estar
representado por uma única entidade de um único conjunto de entidades, Por exemplo, se modelarmos o
departamento COMPRAS como um ponto (entidade) do conjunto de entidade Departamento, ele não deverá
ser representado novamente em nenhuma outra parte do modelo.
No diagrama E-R, as entidades são representadas por retângulos, que contêm no seu interior os nomes das
entidades por eles representadas. Como padrão adotou-se o nome das entidades grafado sempre no
singular.
Cliente
2. Entidade Fraca
"Em certos casos, as ocorrências de entidade não podem ser inequivocamente identificadas por valores de
seus próprios atributos; então nós utilizamos relacionamentos para identificá-las" (Chen, 1990).
Diz-se que uma entidade é fraca quando são utilizados relacionamentos para individualizar suas ocorrências.
Em outras palavras, para o universo modelado, a entidade só tem existência se vinculada a outra entidade.
No diagrama E-R, as entidades fracas são representadas por dois retângulos sobrepostos, com leve
deslocamento de um em relação ao outro, tanto na vertical quanto na horizontal, conforme mostrado na
figura 1
Embora raro, uma entidade pode ser fraca de mais de uma entidade. Um exemplo é mostrado na figura 2,
item b, onde a Seção (mesa eleitoral) é dependente da Zona eleitoral e do Município.
10
Modelagem de Dados Paulo Rocha Neto
Figura 1
Zona define
Município
Seção
Filhos
Figura 2
Código
Matrícula
Nota
Figura 3
3 Atributo
"Um atributo pode formalmente ser definido como a função que mapeia uma entidade ou relacionamento
em um conjunto de valores, ou no produto cartesiano do conjunto de valores; f:Ei ou Ri -» Vi ou Vil x Vi2
x... x Vin"( Chen, 1990).
Informalmente, descrevemos atributo como cada um dos valores descritivos, propriedades ou dados
associados a uma entidade ou relacionamento.
É uma característica inerente a uma entidade. Os atributos representam as informações que caracterizam
exclusivamente a entidade e que desejamos guardar sobre a entidade.
Um atributo é de uma entidade quando identifica uma característica que é só da entidade, independente do
contexto em que ela existe e dos relacionamentos que participa. Ex: Data de nascimento.
Nem sempre existe interesse em visualizar o atributo na representação gráfica. Quando for desejado, usa-se
a forma mostrada na figura 4.
11
Modelagem de Dados Paulo Rocha Neto
Número
Nome
Projeto
Localização
Figura 4
Código
Matrícula
Nota
Figura 5
Nome
Empregado
Salário
Logradouro
Endereço
Complemento
Número
Bairro
Figura 6
12
Modelagem de Dados Paulo Rocha Neto
Nome
Cliente
Telefones
Figura 7
Obs.: Se para o nosso contexto interessasse saber apenas no máximo 2 números de telefone de contato dos
funcionários, poderíamos substituir o atributo multivalorado Fones por dois atributos monovalorados Fone1 e
Fone2.
SSN
Nome
Empregado
SalárioBruto
Desconto
SalárioLíquido
Figura 8
Código
Nome
Departamento
TotalDeEmpregados
Figura 9
13
Modelagem de Dados Paulo Rocha Neto
Na figura 9 o atributo "Total Líquido" é agregado, pois é obtido pelo somatório (vertical) de todos os
"salários líquidos".
Com atributo agregado se evita que, para se obter informações totalizadas, seja necessário acessar e
acumular vários registros. Ex.: se é desejado saber o saldo da conta corrente "empréstimos a funcionários",
não é preciso acessar e somar todos os lançamentos existentes.
CPF
Nome
Cliente
Endereço
Figura 10
4 Relacionamento
“É uma associação entre entidades” (Chen, 1990)
O relacionamento, matematicamente, pode ser representado como um par ordenado que associa elementos
(ocorrências) de entidades (fig. 11).
Aluno Disciplina
João *
* Análise
Marcos *
* Java
Silvia *
* Redes
* TGA
Bianca *
Figura 11
É importante ressaltar que no modelo E-R, o relacionamento é um objeto e, portanto, pode possuir atributos
próprios.
O relacionamento possui uma riqueza semântica muito grande, propiciando a representação das regras de
negócio do usuário. Ex. um Empregado obrigatoriamente está lotado em um Departamento.
A mesma adaptação feita para “entidade” e “conjunto de entidade”, é adotada para relacionamento e
“conjunto de relacionamento”. Também adotamos o termo “ocorrência-de-relacionamento”, para definir um
elemento específico do relacionamento.
Um relacionamento só tem sentido quando as entidades envolvidas são consideradas: “Um relacionamento é
identificado pelas entidades envolvidas” (Chen, 1990). Em um modelo conceitual as entidades são
representadas por suas chaves primárias.
14
Modelagem de Dados Paulo Rocha Neto
No diagrama E-R, os relacionamentos são representados por um losango e como nome do relacionamento é
adotado geralmente um verbo inscrito no interior do losango que identifica o tipo de associação que existe
entre as entidades (fig. 12). Juntamente com o nome do relacionamento, podemos incluir uma seta que
indica o sentido principal da leitura. Ex. Empregado TEM Dependente.
Para relacionamentos múltiplos, adotamos uma das duas alternativas:
a) Usar como nome do relacionamento, um nome que identifique a associação. Ex. O relacionamento
ternário entre Pessoa (quem solicita um porte de arma), Arma (objeto do pedido) e o Órgão policial
(que autoriza), pode ser substituído (balizado) por "Licenciamento".
b) Usar tantos verbos quantos forem precisos para identificar o relacionamento: Pessoa/TEM/Conta-
Corrente/TEM/Cartao-Magnético
1 N
Departamento lota Empregado
Figura 12
1 M
Departamento tem Empregado
Figura 13
O número mínimo de vezes que a entidade deverá participar do relacionamento chama-se totalidade
mínima. Essa totalidade mínima deve ser expressa no diagrama Entidade-Relacionamento. Caso a totalidade
mínima seja maior que 1, o número deve ser escrito em cima da bolinha cheia do relacionamento. Por
exemplo, vamos supor que todo Departamento deva obrigatoriamente ter no mínimo 2 funcionários lotados,
poderíamos representar essa situação como na fig. 14. Analisando o diagrama baixo, concluímos que toda
ocorrência de Departamento deve participar do relacionamento pelo menos 2 (duas) vezes, ou seja, cada
ocorrência da entidade Departamento deverá ter associado a ela no mínimo 2 (duas) ocorrências da
entidade Empregado, devendo ocorrer 2 (duas) vezes no par ordenado lota = ( Emp, Dep ).
2 N
Departamento tem Empregado
Figura 14
No momento da identificação de um relacionamento nem sempre possuímos condições para já
especificarmos a natureza das entidades associadas. Muitas vezes ela fica para ser posteriormente apurada.
Por isso, consideramos muito importante a especificação de símbolos distintos para identificar tanto a
natureza opcional como a obrigatória. A marcação das duas naturezas propicia a rápida descoberta de
omissões. Identificando, por exemplo, só as naturezas obrigatórias, as omissões são assumidas
(erroneamente) como natureza opcional, e não são descobertas.
15
Modelagem de Dados Paulo Rocha Neto
(a) (b)
1 1
Departamento tem Empregado Departamento tem Empregado
(c) (d)
1 M
Departamento tem Empregado
(e)
Figura 15
A seguir explica-se como se identificam as cardinalidades. O processo deve ser feito para todas as entidades
do relacionamento. Nós vamos explicar o método identificando a cardinalidade das entidades Departamento
e Empregado, referentemente ao relacionamento Departamento/TEM/Empregado. Iniciaremos pela entidade
Departamento:
1) Isola-se a entidade Departamento, conforme mostrado na figura 15, item (b);
2) Faz-se a pergunta, sempre partindo da(s) entidade(s) do outro lado: existindo uma ocorrência da
entidade Funcionário, qual o máximo de ocorrências de Departamento que podem se relacionar com
esta ocorrência da entidade Empregado? A resposta é 1 (um) (tendo um Empregado, apenas um
Departamento se relaciona com ele), a cardinalidade da entidade Departamento no relacionamento é l
(um).
3) Isola-se a entidade Empregado, conforme mostrado na figura 15, item (d);
16
Modelagem de Dados Paulo Rocha Neto
4) Faz-se a pergunta: Existindo um Departamento, qual o máximo de Empregados que podem se relacionar
com este Departamento? Como a resposta é vários, a cardinalidade da entidade Empregado no
relacionamento é "M".
No diagrama E-R, a cardinalidade é grafada sobre, ou ao lado, da natureza.
A cardinalidade fica bastante visível quando se representa o relacionamento em termos de uma relação
matemática, conforme mostrado na figura 11. Neste exemplo, é visível que um Aluno pode cursar "M"
Disciplinas e que uma Disciplina pode ser cursada por vários alunos.
A natureza e a cardinalidade das entidades nos relacionamentos complementam a riqueza semântica do
modelo, possibilitando a representação precisa das regras de negócio. Na figura 15 item (e) está formalizada
a seguinte regra: Um Departamento opcionalmente tem vários Empregados e um Empregado
obrigatoriamente pertence a um único Departamento
4.3.1 Relacionamento 1 : 1
A classe de relacionamentos 1:1 significa que cada ocorrência das entidades envolvidas no relacionamento,
relaciona-se com uma e somente uma ocorrência da outra entidade. Por exemplo, cada Departamento é
chefiado por somente um Empregado e, um Funcionário pode chefiar um e somente um Departamento (fig.
16).
1 1
Departamento chefia Empregado
Figura 16
4.3.2 Relacionamento 1 : N
A classe de relacionamentos 1:N significa que cada ocorrência da entidade do lado N do relacionamento
pode se relacionar com somente uma ocorrência da outra entidade e, uma ocorrência da entidade do lado 1
do relacionamento pode se relacionar com várias ocorrências de entidade no lado N.
Por exemplo, um determinado Empregado está lotado em um Departamento e, um determinado
Departamento possui vários Empregados lotados (fig. 17).
1 N
Departamento lota Empregado
Figura 17
4.3.3 Relacionamento N : M
Nessa classe de relacionamento não há restrições na associação entre as ocorrências das entidades que
participam do relacionamento. As entidades participantes podem ocorrer várias vezes nesse relacionamento.
Por exemplo, um determinado Aluno pode cursar de várias Disciplinas e, uma Disciplina pode ser cursada
por vários Alunos (fig. 18).
17
Modelagem de Dados Paulo Rocha Neto
N N
Aluno cursa Disciplina
Figura 18
Obs.: Quando soubermos o número exato de vezes que as ocorrências de uma entidade ocorrem num
determinado relacionamento, podemos substituir o N por esse número decimal. Por exemplo, se fosse
estipulado que os Alunos podem cursar no máximo 2 Disciplinas, podemos substituir a cardinalidade N da
fig. 18 pelo número 2 (fig. 19).
N 2
Aluno cursa Disciplina
Figura 19
4.3.4 Auto-relacionamento
Se R é um relacionamento que associa elementos (ocorrências) de uma entidade E a elementos dessa
mesma entidade, R é denominado auto-relacionamento (ou relacionamento reflexivo).
Por exemplo, um empregado pode chefiar vários outros empregados e um empregado pode ainda ser
chefiado por apenas 1 empregado (fig. 20).
1
M
chefia Empregado
Figura 20
Os auto-relacionamentos são utilizados para expressar também situações de composição. Por exemplo, uma
peça é composta de várias outras peças e, uma determinada peça pode fazer parte de várias composições
(fig. 21).
N
M
compõe Peça
Figura 21
18
Modelagem de Dados Paulo Rocha Neto
papel de cada entidade, uma vez que a mesma entidade participa duas vezes mas com papéis distintos. Por
exemplo, no auto-relacionamento da fig. 20 não estão explicitados os papéis das entidades, portanto não há
como saber quando ela participa como componente e quando ela é a peça composta. Os papéis É-DE e
TEM-COMO aplicam-se a quase todos os auto-relacionamentos (fig. 22).
é componente de
N
M
compõe Peça
R E1 R E2
E1
E1
E1 E2
E4 R E3
R E3
E2
E2
Figura 23
19
Modelagem de Dados Paulo Rocha Neto
Por exemplo, uma pessoa compra uma arma e, deverá ser feito no momento da compra o registro da arma
em um Órgão Policial. Essa situação envolve a participação de 3 entidades distintas pois, uma pessoa
somente pode adquirir uma arma mediante o registro da mesma em um Órgão Policial.
Como não é trivial, e para sedimentar o método, a seguir é explicado como se obtém a cardinalidade no
caso de relacionamentos múltiplos. Para tanto vamos considerar o relacionamento triplo da figura 24, item
(a). Para descobrir-se a cardinalidade das entidades procede-se como segue:
Órgão Órgão
(a) (b)
Órgão Órgão
1 1
Pessoa registra Arma Pessoa registra Arma
(c) (d)
Órgão Órgão
1 1
1 1 M
Pessoa registra Arma Pessoa registra Arma
(e) (f)
Figura 24
1) Isola-se a entidade Pessoa, conforme mostrado na figura 24 em (b);
2) Faz-se a pergunta: se existe uma "ocorrência-de-entidade" de Arma e uma de órgão-Policial, qual o
máximo de ocorrências de Pessoa que podem se relacionar com elas. A resposta é 1 (uma Arma é
liberada para apenas uma Pessoa). Logo a cardinalidade da entidade Pessoa no relacionamento é 1,
conforme mostrado em (c).
3) De forma análoga, descobre-se as outras cardinalidades. Este processo é complementado em (d, e,
f, g).
7 Generalização
Existem muitos casos em uma entidade representa elementos do mundo real que se subdividem em
categorias com atributos parcialmente distintos.
A generalização é uma noção de abstração na qual um conjunto de entidades semelhantes, possivelmente
com alguns atributos comuns e outros diferentes, são vistas como sendo uma única entidade "genérica". Por
exemplo na figura 25, as entidades Digitador, Engenheiro e Motorista, possivelmente com diferentes
atributos e relacionamentos, podem ser generalizadas em uma única entidade genérica Empregado. Neste
exemplo, as entidades Digitador, Engenheiro e Motorista são ditas "ESPECIALISTAS" ou "ESPECIALIZADAS"
e a entidade Funcionário é dita "GENÉRICA".
20
Modelagem de Dados Paulo Rocha Neto
Matrícula
Empregado
Nome
função
d
ToquesPorMinuto
U
NumeroCarteira
U
Digitador Engenheiro Motorista
NumeroCREA
Figura 25
Na generalização existe um relacionamento implícito, que relaciona cada uma das entidades "especialistas"
com a entidade "genérica", que pode ser enunciado como: entidade "especialista" é entidade "genérica".
Aplicando ao exemplo (figura 25): Digitador é Empregado, Engenheiro é Empregado e Motorista é
Empregado. Devido a isso, adaptou-se a representação gráfica de generalização para representar este
relacionamento implícito. Utilizou-se um símbolo de relacionamento como um círculo, com a inscrição dentro
definindo se as entidades especialistas são mutuamente exclusivas ou não, conforme mostrado na figura 25.
A letra “d” define uma disjunção isto é, a entidade genérica EMPREGADO é um DIGITADOR OU um
ENGENHEIRO OU um MOTORISTA. Caso um EMPREGADO pudesse exercer mais de uma função,
colocaríamos a letra “o”.
O conceito de generalização adotado parte do pressuposto de que as entidades especialistas estão incluídas
na genérica. Sendo uma vinculação natural, sempre existirá um atributo, na entidade genérica, que identifica
qual especialista a genérica é. Se houver dificuldade em encontrar este atributo, provavelmente esta
generalização não é correia.
Para dar mais semântica ao modelo de dados, foi incluído, no interior do símbolo proposto para representar
generalização (losango em duplicata), o atributo da entidade "genérica", que individualiza as entidades
"especialistas", e os conteúdos desse atributo, nos ramos que levam a entidade "especialista"
individualizada. No exemplo mostrado na figura 26, definiu-se que se o atributo Função (que é um atributo
de Empregado) tiver o conteúdo "A", o Empregado é Administrativo, "G" Gerencial e "O" um Operacional.
Até aqui viu-se a generalização na sua forma mais simples. Uma entidade especialista pode, por sua vez, ser
a generalização de outras entidades especialistas, seguindo os mesmos critérios até aqui apresentados.
Olhando-se a generalização como uma hierarquia (árvore), pode-se chegar a qualquer quantidade de níveis.
21
Modelagem de Dados Paulo Rocha Neto
Empregado
função
U
A G O
escolaridade
U
M S
Figura 26
Em uma generalização, uma entidade especialista é sempre também uma entidade genérica. Porém, o
inverso nem sempre é verdadeiro. Na figura 25, existem duas entidades genéricas: Funcionário e Motorista.
Neste modelo específico, ocorre o seguinte:
a) Além das especializações de Empregado em Digitador, Engenheiro e Motorista, certamente existem
outras funções, como Office-boy, Contador, etc... Portanto existem especializações de Empregados
que não aparecem no modelo;
b) Todo o Motorista é Amador ou Profissional. Neste caso, o modelo mostra todas as especializações da
entidade genérica.
Para representar esta característica foi estendido o conceito de natureza de relacionamento (ver 27). Junto
ao símbolo da generalização (losango em duplicata), no lado da entidade genérica, é grafado um círculo que
pode ser branco (natureza opcional) ou preto (natureza compulsória).
Natureza opcional (círculo branco) significa que existem outras entidades especialistas, além das que
aparecem no diagrama E-R.
Natureza compulsória (círculo preto) indica que todas as entidades especialistas estão mostradas no
diagrama E-R.
Empregado
função
U
U
A G O
escolaridade
d
U
M S
Figura 27
22
Modelagem de Dados Paulo Rocha Neto
Complementando o exemplo, se a aplicação exigir uma nova especialização da entidade Empregado, desta
feita em Estagiários e Efetivos, todo Funcionário seria Administrativo, Gerencial, Operacional ou uma outra
função que não aparece no modelo e também um Estagiário ou Efetivo.
Estas novas entidades "especialistas" (Estagiário e Efetivo) não estão individualizadas pelo mesmo atributo
que as entidades Secretária, Engenheiro e Motorista (função). Essa especialização é identificada por outro
atributo (situação) que individualiza as novas entidades "especialistas".
A representação desta situação no modelo de dados é feita pela especificação de uma nova generalização,
baseada em outro atributo (e conteúdo). Pode-se enxergar como uma nova árvore, separada da anterior,
tendo em comum apenas a raiz (Funcionário).
No conceito de generalização é vazia a intersecção entre todas as entidades que são "especializações" de
uma mesma entidade, pelo mesmo atributo. A união corres¬ponde (se natureza compulsória) ou não (se
natureza opcional) ao total das ocorrências da entidade "genérica". Isto significa que cada ocorrência da
entidade "genérica", pode ser também ocorrência de uma, e somente uma, das entidades "especialistas"
(especializadas pelo mesmo atributo).
E
Estagiário
U
situação
Empregado d
U
função
Efetivo
F
d
U
U
A G O
escolaridade
d
U
M S
Figura 28
Este conceito de generalização é muito rico em semântica. Suas principais características são:
• Representa quantos níveis de especialização forem necessários ou desejados;
• Representa de forma inteligível a natureza das generalizações;
• Permite representar intersecção de entidades que são especializações de uma mesma entidade
genérica, mostrando inequivocamente quais entidades especialistas não interseccionam, quais as
que podem interseccionar e, quais obrigatoriamente interseccionam. No exemplo desenvolvido, um
Funcionário pode ser Estagiário e Engenheiro, mas não pode ser Motorista e Secretária. Toda
Secretária, Engenheiro e Motorista é também, necessariamente Estagiário ou Efetivo. Porém um
Efetivo ou Estagiário não necessariamente é uma Secretária, Engenheiro ou Motorista. A quantidade
de informações inserida na representação é muito grande;
• Deixa explícito no diagrama toda a lei de geração da generalização como um todo. Mostra baseado
em que atributo e conteúdo são geradas as especializações.
Decidiu-se não permitir duas situações que são:
a) Intersecção não vazia entre as entidades que são especialização de uma mesma entidade genérica
pelo mesmo atributo. No exemplo permitir que um Funcionário seja ao mesmo tempo um
Engenheiro e Motorista;
b) Uma entidade ser a especialização de duas entidades.
23
Modelagem de Dados Paulo Rocha Neto
A situação do item (a) não foi prevista por não ser necessária. Como a especialização é baseada em um
atributo e seu conteúdo, admitir que pode haver intersecção não vazia é admitir que o atributo que define a
generalização possa ser multivalorado, possuindo mais de um valor numa única ocorrência da entidade. É
possível se aplicar as regras de normalização e obter uma solução com semântica superior. Se no exemplo
usado, um Funcionário pode ter mais de um contrato e em cada um deles ter uma função, a modelagem
correia seria normalizar toda a estrutura e gerar um modelo como o mostrado na figura 29.
Esta solução é superior pois representa a realidade e permite inclusive guardar o histórico (Ex: admissões e
demissões de um Funcionário, etc.).
Pessoa
tipo
E
U Estagiário
U
situação
Empregado d
U
função
Efetivo
F
d
U
U
A G
U O
escolaridade
d
U
U
M S
Figura 29
Alguém poderia argumentar que o atributo que identifica as especializações poderia não ser multivalorado se
fossem especificados conteúdos que identificassem combinações. Por exemplo o valor 9 em Função
identificaria que o Funcionário é ao mesmo tempo Administrativo e Gerencial. Neste caso forçou-se uma
solução pelo uso de um artifício e a solução é nitidamente a mesma.
Outra argumentação é a apresentada em exemplos como a especialização da entidade ANIMAL, pelo
atributo "habitat", em ANIMAL-TERRESTRE, ANIMAL-AQUÁTICO, etc.. Existem animais que vivem tanto na
água quanto na terra, sendo pois duas entidades especialistas, o que reforçaria a necessidade de se aceitar
que uma entidade genérica, especializada por um único atributo, pudesse ser mais de uma entidade
especialista. O erro na verdade é que existe uma outra entidade especialista ANIMAL-ANFÍBIO que foi,
erroneamente, assumida como sendo a união de ANI-MAL-AQUÁTICO mais ANIMAL-TERRESTRE.
Quanto ao item (b), não foi adotado por considerar-se que ele fere a própria definição de generalização e
especialização. Se for necessário que uma entidade seja a especialização de outras duas, certamente esta
entidade pode ser especializada por um outro atributo na raiz geral.
Sempre que houver necessidade de se especializar uma entidade, tem de haver, naturalmente, alguma
informação primitiva baseado na qual a especialização é feita.
Para concluir, proibir os casos "a" e "b" não significa limitar a capacidade semânti¬ca do modelo. É
simplesmente garantir que soluções erradas não sejam adotadas.
Quando se generaliza uma entidade
As abstrações de uma forma geral, devem ser utilizadas com algum cuidado, pois podem acabar com uma
das característica mais importante dos modelos que é a simplicidade. A seguir apresentamos algumas
características que podem justificar a adoção de generalizações:
a) Existem atributos comuns a todas as entidades (candidatas a serem especialistas);
24
Modelagem de Dados Paulo Rocha Neto
b) Todas as entidades (candidatas a especialistas) devem ter o(s) mesmo(s) atributo(s) como chave
primária;
c) As entidades candidatas a especialistas possuem atributos que não são comuns a todas elas;
d) Existe uma entidade (candidata a genérica) que naturalmente, sem artifícios, satisfaz ao
relacionamento: entidade especialista é entidade genérica;
e) A generalização vai propiciar ganhos inquestionáveis de semântica ao modelo;
f) Existem relacionamentos que referenciam todas as entidades candidatas a "especialistas". Com a
generalização, estes (vários) relacionamentos podem ser substituídos por um único, na entidade
"genérica";
g) Todos os atributos das entidades especializadas devem satisfazer a terceira forma normal
(independência funcional em relação à chave primária cujo(s) atributo(s) está(rão) na entidade
genérica geral). Este item é muito importante pois propicia identificar falsas generalizações.
8 Especialização
O conceito é exatamente o mesmo que generalização. A diferença é quanto à origem no modelo. Partindo-
se das entidades "especialistas" ou "especializadas", para identificarmos a "genérica", o processo é de
"generalização". Se partimos de uma entidade, e identificamos outras que são suas "especializadas", o
processo chama-se "especialização" (fig. 30).
Empregado
ESPECIALIZAÇÃO
GENERALIZAÇÃO
função
U
U
A G O
Figura 30
Quando se especializa uma entidade
a) Existem entidades (candidatas a especialistas) que naturalmente, sem artifícios, satisfazem ao
relacionamento: entidade especialista é entidade genérica;
b) Existe um atributo na entidade candidata a genérica cujo conteúdo identifica inequivocamente cada
uma das entidades candidatas a especialistas;
c) Existem atributos comuns a todas as entidades candidatas a serem as especializadas;
d) As entidades candidatas a serem as especializadas possuem atributos que não são comuns a todas
elas;
e) Todas as entidades (candidatas a especialistas) tem o(s) mesmo(s) atributo(s) como chave primária;
f) Quando a especialização vai incorporar mais semântica ao modelo;
g) Os atributos das entidades especialistas satisfazem a terceira forma normal (independência
funcional);
h) Nota-se que as ocorrências-de-entidade (da entidade candidata a ser genérica) possuem atributos
com conteúdo opcional. Ex: na entidade Pessoa, o atributo "Certificado militar", é opcional. Este fato
pode induzir a especialização de Pessoa em Homem e Mulher;
i) Existem relacionamentos que referenciam somente algumas ocorrências da entidade (candidata a
genérica), que identificam uma entidade especialista; j) Quando existem procedimentos distintos
25
Modelagem de Dados Paulo Rocha Neto
9 Agregação
A agregação pode ser entendida como uma entidade abstrata derivada de um relacionamento, que não
possui atributos próprios, pois os seus atributos são os do próprio relacionamento. É utilizada para
representar “relacionamentos múltiplos parciais”. Sua representação gráfica é feita desenhando-se um
retângulo em volta do relacionamento e das entidades que dele participam
Agregação é utilizada quando se quer transformar um relacionamento entre entidades, em uma entidade
(abstraia). Desta forma, em procedimentos simples, é possível se referenciar várias entidades relacionadas.
Como agregação transforma um relacionamento em uma entidade (embora abstrata), essa entidade precisa
receber um nome, para que possa ser referenciada em relacionamentos e procedimentos.
Chamamos a atenção para o fato de que agregação é uma entidade que não tem atributos próprios. Os
atributos da agregação são os do(s) relacionamento(s) c entidade(s) que geram a agregação.
Quando se usa agregação
Em três situações utiliza-se agregações:
a) Para representar entidades que existem no dia-a-dia do usuário. Este caso engloba entidades que
são frequentemente citadas e referenciadas em procedimentos. Alguns exemplos podem ser vistos
na figura 31
Correntista
1 M
Pessoa tem Conta
Reservista
M 1
Pessoa serve Quartel
Figura 31
Este tipo de agregação sempre tem um nome natural, sem artifício.
Usa-se agregações nestes casos para propiciar a identificação e visualização, bem como operações
sobre entidades que existem no dia-a-dia do usuário, entidades consagradas na prática, sendo
referenciadas e conhecidas por todos na organização e no seu meio ambiente.
b) Para representar relacionamento múltiplo parcial
Para ficar mais claro, vamos explicar através de um exemplo.
Considere-se a seguinte situação:
• Uma Pessoa pode ter várias Contas-correntes;
• Uma Conta Corrente pode ser de várias Pessoas (conta conjunta);
• Algumas Pessoas que possuem Contas-correntes recebem um Cartão Magné¬tico (cheque
forte);
• Em conta conjunta, apenas o titular da Conta Corrente pode ter Cartão Magnético.
Neste exemplo, existe um relacionamento (Pessoa/tem/Conta Corrente) que é independente de
Cartão Magnético. O que ocorre é que, para algumas ocorrências de Pessoa/tem/Conta Corrente,
existem Cartões Magnéticos. Uma forma de representar esta situação é mostrada na figura 11.20.,
item a.
26
Modelagem de Dados Paulo Rocha Neto
A seguir, vamos supor que a Pessoa p1 tenha as Contas-correntes c1 e c2; p1 referente a c1 tem
Cartão Magnético m1, e não há Cartão Magnético referente a c2. Desta forma teríamos nos
relacionamentos Pessoa/tem/Conta Corrente e Cheque Forte as seguintes situação:
Pessoa/tem/Conta Corrente = {(p1,c1),(p1,c2)} Cheque Forte = {(p1,c1,m1)}
No exemplo acima ficou claro que esta solução gera redundância ("p1,c1" estão relacionados tanto
em "Pessoa/tem/Conta Corrente" como em "Cheque Forte").
O que foi mostrado até aqui é que Cartão Magnético não se relaciona diretamente com Pessoa nem
com Conta Corrente e sim com as ocorrências do relacionamento entre as duas (Pessoa/tem/Conta
Corrente). Assim, vemos que o relacionamento é entre um Objeto (Cartão Magnético) e um par de
objetos (ocorrência de "Pessoa/tem/Conta Corrente"). Isto configura um relacionamento entre uma
entidade (Cartão Magnético) e um relacionamento (Pessoa/tem/Conta Corrente).
Na figura 32, item b, apresentamos a solução que consideramos a mais indicada na representação
da realidade descrita.
Correntista
1 M 1 M
Pessoa tem Conta Pessoa tem Conta
Cheque Cheque
especial especial
Cartão Cartão
magnético magnético
(a) (b)
Figura 32
Porém, muito cuidado: a redundância só existe se os relacionamentos são os mesmos. No exemplo,
descobre-se o proprietário de uma Conta Corrente especial (que tem Cartão Magnético), tanto pelo
relacionamento Pessoa/tem/Conta Corrente, como pelo Forte Cheque.
c) Para especificar algum tipo de restrição ou integridade
Este caso também vamos apresentar através de um exemplo. Suponha-se a seguinte realidade:
• Várias Pessoas prestam o serviço militar em um Quartel;
• Uma Pessoa presta o serviço militar em apenas um Quartel;
• A brigada militar só contrata Pessoas que prestaram o serviço militar (restrição).
Na figura 33 foram feitas duas representações desta realidade, uma utilizando o conceito de
agregação (item b) e a outra não (item a). O que notamos é que somente na representação com
agregação é possível representar a restrição de que a brigada militar só contrata Pessoas que
prestaram o serviço militar.
27
Modelagem de Dados Paulo Rocha Neto
Reservista
M 1 M 1
Pessoa serve Quartel Pessoa serve Quartel
contrata contrata
Brigada Brigada
Militar Militar
(a) (b)
Figura 33
Lembremos que a agregação serve para selecionar alguns pares de um relacionamento e associá-los com
outra entidade. No caso de relacionamentos de classe 1:N, cada elemento do lado N já representa o par em
que eventualmente ocorre. Portanto, usamos a agregação somente em relacionamentos M:N, onde o par
que deverá ser selecionado se encontra representado somente no relacionamento.
Conteúdo extraído e adaptado de: Eti, Francisco – Engenharia de Informações: conceitos, técnicas e
métodos – Porto Alegre: Sagra: D.C. LUZZATTO, 1993 e Barbiere, Carlos – Modelagem de Dados – Rio de
Janeiro: Infobook, 1994.
28
Modelagem de Dados Paulo Rocha Neto
Bibliografia
Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994.
Chen, Peter – Modelagem de Dados – São Paulo: McGraw-Hill, 1990.
Eti, Francisco – Engenharia de Informações: conceitos, técnicas e métodos – Porto Alegre: Sagra: D.C.
LUZZATTO, 1993.
Feliciano Neto, Acácio – Engenharia da Informação: metodologias, técnicas e ferramentas – São Paulo:
McGraw-Hill, 1988.
29