Modelagem de Dados

MODELAGEM DE
Dados
Guia de Estudo
Paulo Rocha Neto
Know How
São Luís Maranhão 2007
Projeto de Software Paulo Rocha Neto
ÍNDICE
DADOS E REALIDADE ................................................................

.............................................................................................
............................................................. 2
MODELAGEM DE DADOS ................................................................

.........................................................................................
......................................................... 3
1 O MODELO DE DADOS ........................................................................................................... 3
2 COMO OBTER UM MODELO DE DADOS ....................................................................................... 3
2.1 DECOMPOSIÇÃO FUNCIONAL ................................................................................................... 3
2.2 ANÁLISE DE REGRAS DE NEGÓCIOS ............................................................................................ 3
2.3 ANÁLISE DE EVENTOS............................................................................................................. 5
2.3.1 ABORDAGEM POR EVENTOS ..................................................................................................... 5
2.4 A ADOÇÃO DA ANÁLISE ESSENCIAL ........................................................................................... 7
2.5 A ANÁLISE DE EVENTOS E A ANÁLISE DE DADOS ........................................................................... 7
O MODELO CONCEITUAL ................................................................

........................................................................................
........................................................ 8
PRIMITIVAS DO MODELO E-R ................................................................

..................................................................................
..................................................10
..................10
1. ENTIDADE ......................................................................................................................... 10
2. ENTIDADE FRACA................................................................................................................ 10
2.6 ENTIDADE DE RELACIONAMENTO ............................................................................................ 11
3 ATRIBUTO ......................................................................................................................... 11
3.1 ATRIBUTO DE RELACIONAMENTO ............................................................................................ 12
3.2 ATRIBUTO COMPOSTO ......................................................................................................... 12
3.3 ATRIBUTO MULTIVALORADO .................................................................................................. 13
3.4 ATRIBUTO DERIVADO........................................................................................................... 13
3.5 ATRIBUTO AGREGADO ......................................................................................................... 13
3.6 ATRIBUTO DETERMINANTE .................................................................................................... 14
4 RELACIONAMENTO .............................................................................................................. 14
4.1 OPCIONALIDADE DE RELACIONAMENTO .................................................................................... 15
4.2 CARDINALIDADE DE RELACIONAMENTO .................................................................................... 16

Modelagem de Dados Paulo Rocha Neto
4.3 TIPO DE RELACIONAMENTO ................................................................................................... 17
4.3.1 RELACIONAMENTO 1 : 1....................................................................................................... 17
4.3.2 RELACIONAMENTO 1 : N ...................................................................................................... 17
4.3.3 RELACIONAMENTO N : M...................................................................................................... 17
4.3.4 AUTO-RELACIONAMENTO ..................................................................................................... 18
5 PAPÉIS DAS ENTIDADES NOS RELACIONAMENTOS ........................................................................ 18
6 GRAU DOS RELACIONAMENTOS .............................................................................................. 19
6.1 RELACIONAMENTOS MÚLTIPLOS.............................................................................................. 19
7 GENERALIZAÇÃO................................................................................................................. 20
8 ESPECIALIZAÇÃO ................................................................................................................. 25
9 AGREGAÇÃO ...................................................................................................................... 26
BIBLIOGRAFIA ................................................................
................................................................................................
.....................................................................
.....................................29
.....29
1
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
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.
2 Como obter um Modelo de Dados

Existem várias abordagens que conduzem à obtenção e cristalização dos Modelos de Dados e dependem do
"pedigree" metodológico adotado. As principais são:
• Decomposição funcional;
• Análise das regras de negócios;
• Análise de eventos.
2.1 Decomposição Funcional

A obtenção dos modelos de dados pela decomposição funcional se dá pela análise da hierarquia de Funções-
Processos-Atividades. Nessa abordagem, a identificação de entidades externas, ou de depósitos de dados
relacionados a cada processo, sugere entidades de dados que comporão o modelo. Essa abordagem foi
muito usada nas metodologias iniciais embasadas na Análise Estruturada Convencional e não será detalhada
nesse trabalho. A Análise Estruturada Convencional, promotora da decomposição funcional, está sendo
modernizada pelos conceitos de Eventos trazidos pela Análise Essencial.
2.2 Análise de Regras de Negócios

Uma das áreas mais florescentes dentro da esfera que analisa dados, processos, objetos e suas correlações
é o estudo das Regras de Negócios. Esse componente, que juntamente com as Entidades, os
Relacionamentos e Atributos, forma o quarteto básico para a garimpagem de dados que suportam os
negócios da empresa, vem ganhando aceitação crescente nas abordagens metodológicas. A idéia é
aprofundar a prospecção em cima dessa, que é a mais fluídica das quatro integrantes citadas. O seu pleno
entendimento e o seu registro mais formal vem ganhando interesse, promovendo debates e produzindo
novos conceitos. O livro The Business Rule Book:Classifying, Defining and Modelíng de Ronald Ross,
publicado em 1994 é a mais recente Bíblia do assunto. A grande e intrigante questão sobre o assunto é
talvez aquela que deveria ser a mais óbvia. O que é regra de negócio e como expres¬sá-la formal e
adequadamente de maneira a torná-la um conceito gerencial útil? A sua definição, como todo conceito sem
paternidade definida, é hoje ambígua e sem fronteiras rigorosas. A indústria de softwares e metodologia,
provavelmente por não ter ainda entendido o seus contornos, não se arvorou em padronizá-la e passa ao
largo da sua utilização. A definição de regras de negócios (RN) possui vários ângulos. Alguns consideram as
regras de Entidades como sua mais perfeita tradução. Outros citam as regras de opcionalidade e
cardinalidade de relacionamento, tão usuais em modelagem de dados, como exemplos bem acabados de
RN. Outros entendem que as regras de Domínio de atributos são mais ajustadas ao figurino RN. Outros
apostam que as RN são mais válidas quando se referem a regras de inferência, como If condição then ação.
Na realidade RN é de tudo um pouco.
3
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
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?
2.3 Análise de Eventos

Com o surgimento das ferramentas Case nos anos 80, os conceitos de análise estruturada, aplicados à
confecção de sistemas, puderam ser efetivamente testados nas bancadas práticas dos CPD. Nesses
ambientes, diferentemente dos paraísos teóricos onde foram concebidas, essas técnicas tiveram que provar
a razão de seu intrigante magnetismo. Dessa forma passaram a ser consumidas pela área de Informática,
até atingirem um estágio de maturação normalmente presente nessas manifestações metodológicas. De um
lado surgiram as famosas metodologias definidas pelo rótulo de Engenharia de Informações, produzidas pela
esperteza de alguns consultores, que com um "label" estratégico (engenharia) conferiam uma característica
eminentemente técnica a algo que sempre fora considerado produto de certa inspiração. Do outro lado,
apareceram as abordagens capitaneadas pelo sucesso de "best-sellers" do tipo Gayne-Sarson, Yourdon,
Jackson etc. que se convencionou chamar de Análise Estruturada, pura e simplesmente. Essas duas
linhagens metodológicas, inicialmente divergiram entre si, com relação a dicotomia dados-processos já
discutida anteriormente. Como visto, bastou pouco tempo para que as novas versões dessas metodologias
buscassem o equilíbrio desejado entre esses dois ingredientes fundamentais. Isso provocou o que seriam os
primeiros sintomas dessa convivência pacífica, que hoje os objetistas (nova classe emergente) rotulam de
encapsulamento. No lado dos processistas, avanços significativos aconteceram, e o principal deles, além do
equilíbrio com os dados, foi a lanternagem oferecida pelos propositores da chamada Análise Estruturada
Moderna, ramo que surgiu calcado em idéias publicadas em alguns livros (Yourdon, Macmenamin, Palmer e
Ward), e que pode ser interpretada como a nova geração da Análise Estruturada.
No afã de evitar identificação com as imperfeições do passado, os propositores matreiramente denominaram
essa nova abordagem de Análise Essencial. A justificativa se deu pelo seu dedicado e exclusivo interesse
pela "essência" do sistema, independentemente dos aspectos da implementação que, erradamente,
costumam ser considerados em fases conceituais do projeto. Na realidade, percebeu-se nas entrelinhas mais
uma recaída da conhecida indústria do vocábulo, engrenagem virtual e operativa pilotada por empresas e
consulto rés, cuja finalidade é cunhar novos termos (modelo essencial, modelo de encarnação, blitzing etc.)
para definir coisas, que de certa forma já conhecemos e praticamos (talvez com ligeiras variações). A
indústria do vocábulo se aproveita das marés de modismos que sempre atingem a nossa praia (área de
Informática) produzindo o consumo de tecnologias variadas que têm invólucros diferentes mas o recheio de
mesmice.
No fundo, as diferenças entre a Análise Estruturada Convencional (AEC) e a Análise Estruturada Moderna
(AEM) ou Análise Essencial podem ser sin¬teticamente definidas por conta de dois pontos básicos:
• Abordagem por eventos.
• As técnicas de JAD.
2.3.1 Abordagem por Eventos

Com essa proposta, a AEM sugere uma cambalhota na famosa abordagem "Top-Down" transformando-a em
"Middle-down/Middle-up". Isso sig¬nifica que, ao invés de se iniciar o desenho do sistema pela clássica
decomposição de funções/processos/atividades, propõem-se um exercício de descoberta de eventos, como
ponto de partida da técnica.
Eventos são definidos como os fatos que provocam estímulos, para os quais os sistemas deverão conter
processos de resposta. Eles podem ser originados externamente por fluxos (Figura 2,3) ou internamente por
um mecanismo temporal de disparo (Figura 2.4). Essa tática dribla de forma desconcertante as tediosas
dissecações funcionais propostas originalmente, podendo produzir processos (num patamar intermediário)
que poderão, se necessário, ser decompostos (middle-down) ou agregados (middle-up), dependendo de sua
granularidade. Segundo os seus propositores, o particionamento por eventos oferece um conceito também
mais objetivo, por fugir dos aspectos protocolares existentes nas definições de
funções/processos/atividades. Tal objetividade se concretiza na medida em que os estímulos ajudam na
garimpagem dos verdadeiros requerimentos do sistema, desconsiderando aspectos superficiais ou de baixa
relevância. Esses requerimentos verdadeiros são, portanto, aqueles sem os quais o sistema não atinge seus
objetivos.
5
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
• Sistema de Folha de Pagamento:

1. Empregado é admitido.
2. Empregado recebe aumento de salário.
3. Empregado é demitido.
4. Receita Federal envia alterações de tabelas de dedução.
5. Hora de emitir contra-cheque (Evento temporal).
• Sistema de empréstimo de Livros:
1. Cliente solicita livros.
2. Cliente devolve livros.
3. Hora de fechar a loja (Evento temporal).
• Sistema de Controle de Hotel:
1. Cliente faz reserva.
2. Cliente cancela reserva.
3. Cliente faz check-in.
4. Cliente faz check-out.
5. Hora de cancelar não comparecimento (Evento temporal).
2.4 A adoção da Análise Essencial

Curiosamente, a AEM, dita essencial, embora reconhecida como um novo release da Análise Estruturada
Convencional, enfrentou alguns obstáculos justificáveis na sua plena adoção. O primeiro foi um certo
ceticismo natural provocado pela sua origem processista, embora hoje se mostre afinada com a
indispensável análise de dados. O segundo foi motivado pela ausência de ferramentas CASE que a
suportasse plenamente. Esse aspecto, hoje não é mais relevante, pois as principais ferramentas CASE
existentes no mercado já oferecem releases contemplando a Análise de Eventos. Para isso, alteraram os
seus "engines" desenhadores que aprenderam a realizar a síntese de níveis de DFD (Diagrama de Fluxo de
Dados), em vez de somente realizar sua decomposição, como na abordagem top-down. Ligeiras
modificações na estrutura do dicionário dessas ferramentas também foram necessárias para a adoção da
Análise Essencial.
2.5 A Análise de Eventos e a Análise de Dados

Excluindo-se as diferenças anteriormente discutidas, todo o resto das técnicas, símbolos e terminologia da
AEM ou Essencial, é emprestado do antigo concubinato Análise Estruturada Convencional e Análise de
Dados. São obtidos os DFD (Diagramas de Fluxos de Dados-nível eventos), os DER (Diagrama de
Entidade/Relacionamento-nível eventos) com os seus componentes tradicionais (entidade externa, fluxos,
depósitos, e entidades de dados, relacionamentos, atributos e regras). Na realidade, a Análise de Eventos
pode ser vista como um importante ponto de início para a Análise de Dados. O processo se inicia pela
Modelagem Ambiental, onde os objetivos do sistema são levantados, o diagrama de contexto é produzido e
a lista de Eventos é elaborada. Após essa fase, que mostra o sistema incrustrado no seu contexto, vem a
Modelagem Comportamental. Nela, para cada evento da lista é elaborado o seu processo de resposta com o
respectivo DFD.
Extraído de: Barbiere, Carlos – Modelagem de Dados – Rio de Janeiro: Infobook, 1994.
7
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
• 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
Primitivas do Modelo E-R

As noções primitivas de modelagem conceitual e a abrangência do modelo estendido adotados são a seguir
definidas ou explicadas:
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
Funcionário possui Filhos
Figura 1
Zona define
Município
Seção
Filhos
Figura 2
2.6 Entidade de Relacionamento

Uma entidade de relacionamento é aquela que não existe por si só. Sua existência está condicionada a
existência de duas ou mais entidades, a partir da qual é concebida. Surge da necessidade de armazenarmos
informações que não pertencem a nenhuma das entidades envolvidas no relacionamento. Desta forma, a
entidade de relacionamento (também denominada entidade associativa) tem como finalidade prover um
mecanismo de armazenamento de atributos de um relacionamento conforme mostrado na figura 3.
Código
Matrícula
Aluno avaliação Disciplina

Nome Nome
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
Número
Nome
Projeto
Localização
Figura 4
3.1 Atributo de Relacionamento

Um atributo é de um relacionamento quando ele só existe vinculado a uma ocorrência do relacionamento.
Ex: O atributo data de casamento só existe se existir uma ocorrência-de-entidade da entidade Homem
associada, através do relacionamento Matrimônio, com uma ocorrência-de-entidade da entidade Mulher.
São atributos que não caracterizam exclusivamente nenhuma das entidades participantes do
relacionamento, mas a própria associação dessas entidades.
Por exemplo, um Aluno cursa várias Disciplinas, essas mesmas Disciplinas podem estar sendo cursadas por
diversos Alunos. Existem alguns atributos nesse relacionamento que não caracterizam nem Aluno e nem
Disciplina como no caso de Nota. Nesse caso, o atributo pertence ao relacionamento (fig. 5).
Código
Matrícula
Aluno avaliação Disciplina

Nome Nome
Nota
Figura 5
3.2 Atributo Composto

É um atributo que tem em sua composição um ou mais de um sub-atributos. Por exemplo, o Endereço de
um Contribuinte é formado por: Tipo-Logradouro , Nome-Logradouro , Numero-Logradouro.
Os atributos compostos representam um agrupamento lógico dos sub-atributos, onde o valor do atributo é a
concatenação dos valores dos sub-atributos. Isso, na prática, se traduz em grande facilidade de manipulação
das informações. Graficamente, pode ser representado conforme o atributo endereço-cliente da figura 6.
SSN
Nome
Empregado
Salário
Logradouro
Endereço
Complemento
Número
Bairro
Figura 6
12
3.3 Atributo Multivalorado

É um atributo assume mais de um valor para uma mesma ocorrência de entidade. Seu nome deve estar no
plural e representado graficamente por uma elipse dupla
Por exemplo, um cliente possui vários números de telefone para contato (fig. 7).
SSN
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.
3.4 Atributo Derivado

São os obtidos através de operações sobre outros atributos pertencentes a mesma ocorrência-de-entidade
(operação na horizontal).
Como exemplo citamos os totais, diferenças, somatórios, etc. Os atributos derivados são representados por
uma elipse pontilhada.
O atributo "Salário Líquido" é derivado, pois ele é apurado a partir da operação: Salário Líquido = Salário
Bruto – Descontos (fig. 8).
SSN
Nome
Empregado
SalárioBruto
Desconto
SalárioLíquido
Figura 8
3.5 Atributo Agregado

São os tipos especiais de atributos derivados obtidos por operações ou comparações entre atributos
pertencentes a ocorrências-de-entidade distintas de uma ou mais entidades (operação ou comparação na
vertical).
Os principais exemplos são os valores máximos, mínimos, médias, somatórios, saldos, etc.
Código
Nome
Departamento
TotalDeEmpregados
Figura 9
13
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.
3.6 Atributo Determinante

É um atributo que identifica (determina) uma única ocorrência da entidade.
Graficamente ele é representado no diagrama sublinhado (fig. 10).
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
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
4.1 Opcionalidade de Relacionamento

Dada uma entidade E e um relacionamento R em que E participa, dizemos que o relacionamento R é total
em relação a E, se e somente se, toda ocorrência de E tiver que ocorrer em R, sendo representado
graficamente por uma bola cheia conforme fig. 13; se ao contrário, nem toda ocorrência de E tiver que
participar(ocorrer) do relacionamento R, dizemos que R é parcial em relação a E.
Por exemplo, vamos supor que todo Empregado deva estar lotado pelo menos (no mínimo) um
Departamento (fig. 13). Dizemos que lota é total em relação a entidade Empregado, pois todo elemento
(ocorrência) da entidade Funcionário deve ocorrer (participar) no par ordenado (relacionamento) lota no
mínimo 1 (um) vez.
No diagrama E-R representamos por um "círculo preto", situado entre o símbolo do relacionamento
(losango) e o símbolo da entidade (retângulo), se a entidade tiver suas ocorrências obrigatoriamente
participando do relacionamento, e com uma "circulo branco", se for opcional.
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
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
A identificação da natureza de uma entidade num relacionamento é muito simples. No relacionamento

Departamento/TEM/Empregado, para identificar a natureza de Departamento, basta fazer a pergunta: pode
haver Departamento sem Empregados? Sendo a resposta "sim", a natureza da entidade Departamento no
relacionamento Departamento/TEM/Empregado é opcional. Se a resposta for não, é natureza obrigatória. No
caso da entidade Empregado, a pergunta se adapta para: pode haver Empregado sem Departamento? Como
a resposta é não (todo Empregado deve estar vinculado a um Departamento), a natureza da entidade
Funcionário no relacionamento é obrigatória.
Diversos autores adotam este conceito com o nome de "totalidade de relacionamento".
4.2 Cardinalidade de Relacionamento

A Cardinalidade de um relacionamento indica o número de vezes que uma ocorrência de entidade ocorre em
um determinado relacionamento. Para entendermos melhor o conceito de cardinalidade, precisamos saber
que o relacionamento nada mais é que um par ordenado (x,y), associando ocorrências das entidades X e Y e
que a cardinalidade é apenas uma restrição que indica o número de vezes que as ocorrências de entidades
participantes do relacionamento participam naquele par ordenado.
Analisando as representações da figura 13, podemos notar que a classe do relacionamento é 1:N, e a sua
leitura (interpretação) é feita da seguinte maneira: Um determinado Empregado está associado (lotado) em
no máximo uma ocorrência da entidade Departamento, portanto Empregado ocorre somente uma única vez
no relacionamento (par ordenado) lota. Representamos essa restrição assinalando a cardinalidade 1 do lado
de Departamento (cardinalidade de Funcionário); do outro lado, um determinado Departamento pode conter
vários Empregados, portanto uma ocorrência da entidade Departamento ocorre várias vezes no
relacionamento lota e por isso assinalamos a cardinalidade N do lado de Funcionário.
É interessante identificar os valores mínimos, médios e máximos que a cardinalidade de cada entidade pode
assumir no relacionamento.
Departamento tem Empregado Departamento tem Empregado
(a) (b)
1 1
Departamento tem Empregado Departamento tem Empregado
(c) (d)
1 M
(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
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 Tipo de Relacionamento

É a combinação das cardinalidades das entidades associadas pelo Relacionamento. Assim temos, os
relacionamentos tipo 1:1, 1:M, M:M, 1:1:M, etc.
Note-se que o tipo do relacionamento é dependente do sentido de leitura. Ex.: O relacionamento
Departamento/TEM/Funcionário é de tipo 1:M; o relacionamento Funcionário/PERTENCE/Departamento
(mesmo relacionamento lido no sentido inverso) é de tipo M:1.
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
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
5 Papéis das Entidades nos Relacionamentos

"Papel de uma entidade num relacionamento é a função que ela desempenha no relacionamento. Marido e
esposa são papéis" (Chen, 1990)
Muitas vezes o papel que uma entidade desempenha no relacionamento se confunde com a própria
entidade. Uma situação peculiar ocorre nos auto-relacionamentos onde uma entidade desempenha mais de
um papel. Por exemplo: No auto-relacionamento Pessoa/casa-com/Pessoa, a entidade Pessoa desempenha
dois papéis, e uma ocorrência do relacionamento sempre associa duas ocorrências da entidade Pessoa, mas
sempre cada uma delas em um dos dois papéis possíveis: marido e esposa. Nenhuma ocorrência deste
relacionamento associa duas esposas ou dois maridos.
Analisando o auto-relacionamento da fig. 21, podemos dizer que o auto-relacionamento representa a
composição de peças. Temos uma única entidade participando duas vezes do relacionamento. Nos
relacionamentos que envolvem duas ou mais entidades, o papel desempenhado por cada entidade no
relacionamento é obvio e comumente omitido, porque o nome do relacionamento traduz claramente a
associação do mundo real. Já no auto-relacionamento, como no da fig. 19, faz-se necessário explicitar o
18
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
tem como componente

Figura 22
6 Grau dos Relacionamentos

Indica a quantidade de entidades que participam do relacionamento. O menor grau é 2 (dois), pois nos
auto-relacionamentos, embora sendo apenas uma entidade ela desempenha dois papéis (fig. 23).
R E1 R E2
E1
E1
E1 E2
E4 R E3
R E3
E2
E2
Figura 23
6.1 Relacionamentos Múltiplos

São os relacionamentos que tem grau superior a dois (triplos, quádruplos, etc.).
Uma consideração importante, é que: se um relacionamento é de grau "n", as ocorrências deste
relacionamento são "n-uplas", mais os atributos próprios do relacionamento. Ex: Se o relacionamento é
duplo, suas ocorrências são duplas, se triplos, triplas, etc. É muito comum a utilização errada dos
relacionamentos múltiplos. Sempre que especificarmos um relacionamento múltiplo temos que assegurar
que sempre o relacionamento associa todas as entidades. Não pode haver relacionamento múltiplo parcial,
do tipo: as vezes é triplo, mas em alguns casos uma das entidades não participa, ficando vazia sua posição
(veja contorno para este caso em "agregação").
19
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
Pessoa registra Arma Pessoa registra Arma
(a) (b)
Órgão Órgão
1 1
(c) (d)
Órgão Órgão
1 1
1 1 M
(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
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
Empregado
função
U
A G O
Administrativo Gerencial Operacional
escolaridade
U
M S
Nível Médio Nível Superior
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
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
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
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
para certas ocorrências de entidade. Os termos generalização e especialização só tem sentido

quando interessa a origem da representação. Quando se vê o modelo já gerado, não se sabe se o
processo usado foi generalização ou especialização. Devido a isto, no diagrama E-R tanto faz usar o
termo generalização ou especialização. O mais difundido é generalização.
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
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
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
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

Modelagem de Dados

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelagem de Dados

Uploaded by

Copyright:

Available Formats

MODELAGEM DE

DADOS E REALIDADE ................................................................

MODELAGEM DE DADOS ................................................................

1 O MODELO DE DADOS ........................................................................................................... 3

2 COMO OBTER UM MODELO DE DADOS ....................................................................................... 3

2.1 DECOMPOSIÇÃO FUNCIONAL ................................................................................................... 3

2.2 ANÁLISE DE REGRAS DE NEGÓCIOS ............................................................................................ 3

2.3 ANÁLISE DE EVENTOS............................................................................................................. 5

2.3.1 ABORDAGEM POR EVENTOS ..................................................................................................... 5

2.4 A ADOÇÃO DA ANÁLISE ESSENCIAL ........................................................................................... 7

2.5 A ANÁLISE DE EVENTOS E A ANÁLISE DE DADOS ........................................................................... 7

O MODELO CONCEITUAL ................................................................

PRIMITIVAS DO MODELO E-R ................................................................

2.6 ENTIDADE DE RELACIONAMENTO ............................................................................................ 11

3.1 ATRIBUTO DE RELACIONAMENTO ............................................................................................ 12

3.2 ATRIBUTO COMPOSTO ......................................................................................................... 12

3.3 ATRIBUTO MULTIVALORADO .................................................................................................. 13

3.4 ATRIBUTO DERIVADO........................................................................................................... 13

3.5 ATRIBUTO AGREGADO ......................................................................................................... 13

3.6 ATRIBUTO DETERMINANTE .................................................................................................... 14

4.1 OPCIONALIDADE DE RELACIONAMENTO .................................................................................... 15

4.2 CARDINALIDADE DE RELACIONAMENTO .................................................................................... 16

4.3 TIPO DE RELACIONAMENTO ................................................................................................... 17

4.3.1 RELACIONAMENTO 1 : 1....................................................................................................... 17

4.3.2 RELACIONAMENTO 1 : N ...................................................................................................... 17

4.3.3 RELACIONAMENTO N : M...................................................................................................... 17

4.3.4 AUTO-RELACIONAMENTO ..................................................................................................... 18

5 PAPÉIS DAS ENTIDADES NOS RELACIONAMENTOS ........................................................................ 18

6 GRAU DOS RELACIONAMENTOS .............................................................................................. 19

6.1 RELACIONAMENTOS MÚLTIPLOS.............................................................................................. 19

2 Como obter um Modelo de Dados

2.1 Decomposição Funcional

2.2 Análise de Regras de Negócios

2.3 Análise de Eventos

2.3.1 Abordagem por Eventos

• Sistema de Folha de Pagamento:

2.4 A adoção da Análise Essencial

2.5 A Análise de Eventos e a Análise de Dados

Primitivas do Modelo E-R

Funcionário possui Filhos

2.6 Entidade de Relacionamento

Aluno avaliação Disciplina

3.1 Atributo de Relacionamento

Aluno avaliação Disciplina

3.2 Atributo Composto

3.3 Atributo Multivalorado

3.4 Atributo Derivado

3.5 Atributo Agregado

3.6 Atributo Determinante

4.1 Opcionalidade de Relacionamento

A identificação da natureza de uma entidade num relacionamento é muito simples. No relacionamento

4.2 Cardinalidade de Relacionamento

Departamento tem Empregado Departamento tem Empregado

4.3 Tipo de Relacionamento

5 Papéis das Entidades nos Relacionamentos

tem como componente

6 Grau dos Relacionamentos

6.1 Relacionamentos Múltiplos

Pessoa registra Arma Pessoa registra Arma

Administrativo Gerencial Operacional

Nível Médio Nível Superior

Administrativo Gerencial Operacional

Nível Médio Nível Superior

Administrativo Gerencial Operacional