02a-+Modelo+ER

Prévia do material em texto

francisco.massetto@ufabc.edu.br
UFABC –UAB TSI –
TECNOLOGIA EM SISTEMAS DE
INFORMAÇÃO
AULA 2A: APROXIMANDO O
NEGÓCIO DA COMPUTAÇÃO
O MODELO ENTIDADE-
RELACIONAMENTO
AGENDA
 Modelo Entidade Relacionamento
 Técnicas de Modelagem
 Identificação de entidades, atributos
 Tipos de atributos
 Relacionamentos (formalmente e intuitivamente)
 Generalização, especialização
 Papéis (roles) em um relacionamento
 Entidades associativas
 Notações gráficas
APROXIMANDO O NEGÓCIO
DA COMPUTAÇÃO
 Técnicas para modelar regras de negócio em elementos a 
serem armazenados
 Definição dos participantes de um domínio de aplicação e 
suas características, restrições e relações
 Necessidade de poder de abstração de quem interpreta o 
problema para criar um modelo correto e coerente
MODELO ENTIDADE-
RELACIONAMENTO
 Modelo bastante intuitivo, que descreve elementos que 
participam do domínio da aplicação e como estes 
elementos se relacionam
 Descreve objetos (entidades) do domínio da aplicação e 
suas características (atributos)
 Descreve a interação entre esses elementos (relações)
 Uso facilitado se o conceito de relação matemática for 
aplicado
 Pense em conjuntos: Quais relações dois conjuntos de dados 
devem ter?
 Quais vínculos pode haver entre os objetos modelados?
 Como eu faço, para, a partir de um objeto, recuperar 
informações que estejam vinculadas a outro?
ENTIDADES E ATRIBUTOS
 Representa objetos do domínio da aplicação sobre os quais deseja-se 
manter informações armazenadas
 “coisas” com características
 Como identificar as entidades?
 A partir de uma descrição, identificar os “participantes”, os elementos 
descritíveis
 O que é possível identificar nessa descrição do sistema?
 Nem sempre as entidades são identificadas na 1ª vez em que se lê a descrição 
do sistema
 Muitas vezes a descrição deve ser revisitada para um melhor entendimento do 
próprio problema a ser modelado
 E os atributos?
 Características que descrevem esses objetos
 Não confundir atributos com outras entidades. Os atributos sempre 
DESCREVEM uma entidade. 
 Itens que podem ser atômicos ou compostos
TIPOS DE ATRIBUTOS
 Simples (atômico)
 Única informação para descrever o atributo
 Ex: número do RG (somente número), número do CPF, código de cadastro, 
preço
 Composto
 O atributo é caracterizado pela composição de vários outros atributos
 Exemplo: Endereço é caracterizado por: Rua, Número, Complemento, CEP, 
Cidade e Estado
 Ou o documento de Registro é caracterizado pelo número do RG, órgão de 
expedição e data de expedição (pensando em melhorar o exemplo do 
item anterior)
 Derivado
 Atributo é obtido através de um atributo já existente
 Exemplo: idade – obtido através da data de nascimento
 Exemplo: valor liquido – obtido através do valor bruto e desconto
TIPOS DE ATRIBUTOS
 Univalorado
 Único valor para o atributo
 Exemplo: número de registro em um cadastro de funcionários
 Multivalorado
 O atributo pode conter uma lista de valores (vazia ou não)
 Exemplo: telefones de contato em um cadastro de pessoas
EM LINHAS GERAIS
 Atributos Compostos e multivalorados podem confundir a 
cabeça do desenvolvedor da aplicação, induzindo-o a 
imaginar uma outra entidade (atributo composto) ou um 
vínculo entre entidades (atributo multivalorado)
 A má notícia é que não existe fórmula mágica: muito 
depende da experiência do desenvolvedor
 Entretanto, algumas boas dicas podem ser úteis nessa 
etapa
 Pense em descrição do objeto. Esse atributo composto ou 
multivalorado ter vínculos com outros objetos (entidades)?
 Se sim, o atributo multivalorado ou composto pode tornar-se 
uma nova entidade
 Se não, é apenas um atributo que descreve um objeto
REPRESENTAÇÃO GRÁFICA
O atributo 1 está 
marcado diferente por 
ser um atributo chave 
(vamos discutir isso 
adiante)
O atributo 4 é um atributo 
multivalorado . A notação 
(0,n) indica que a entidade 
pode ter 0 ou várias 
ocorrências deste atributo
RELACIONAMENTOS
 Associações / relações entre as entidades envolvidas
 Matematicamente é um relação R sobre 2 conjuntos A e B
 Pense sempre em teoria dos conjuntos – costuma facilitar 
demais a interpretação
 Estabelece vínculos entre duas entidades
 A própria descrição do sistema pode induzir a estas 
relações
EXEMPLOS DE
RELACIONAMENTOS
Notação de conjuntos da relação que descreve quais 
funcionários trabalham em quais departamentos
NOTAÇÃO GRÁFICA
PAPÉIS (ROLES) EM UM
RELACIONAMENTO
 Para melhorar a legibilidade de um modelo, pode-se 
utilizar a notação de definir os papéis que cada entidade 
assume no relacionamento
 Em geral, isso é utilizado quando usa-se o auto-
relacionamento
 A entidade relaciona-se com ela mesma
 Como assim?
 Um elemento do conjunto pode possuir uma relação com 
outro elemento do conjunto (inclusive ele mesmo)
 Entretanto o auto-relacionamento não restringe certas 
situações (como o exemplo a seguir)
AUTO-RELACIONAMENTO COM
PAPÉIS
AUTO-RELACIONAMENTO COM
PAPÉIS
 Problema maior é a limitação descritiva do auto-relacionamento
 No caso do exemplo anterior (pessoa casa-se com pessoa), nada indica 
que uma pessoa possa não deva casar-se com ela mesma
 Algumas restrições não são tangíveis no modelo de armazenamento
 Devem ser responsabilidade da aplicação
CARDINALIDADE DOS
RELACIONAMENTOS
 Cardinalidade indica a quantidade de ocorrências de uma 
entidade associada a outra
 Muda totalmente a interpretação do problema
 Agora temos restrições de quantidades e isso impacta no 
projeto de todo o sistema
 Algumas regras devem ser obedecidas
 A cardinalidade deve refletir todo o ciclo de vida do sistema
 O sistema deve sempre ser modelado levando-se em 
consideração a execução permanente do sistema
 Cardinalidade não trata de uma situação específica, mas de todas 
as prováveis ocorrências das entidades na relação
 Em muitos casos, por não haver restrições de tempo, atributos 
indicando o momento ou instante em que a ocorrência se deu 
podem facilitar a interpretação da relação
CARDINALIDADES (1:1)
1
1 marido casa-se com 1 esposa
1 esposa casa-se com 1 marido
1
CARDINALIDADE 1:1
 Este exemplo reflete uma aplicação para um cenário 
monogâmico ocidental tradicional (rs)
 Restringe um elemento desta entidade (conjunto) a ter um 
vínculo com apenas 1 único elemento da mesma entidade.
 Pensando em relações, isso significa que nunca existirão 2 
ou mais pares ordenados onde o 1º ou o 2º elementos 
repitam
 Abstraindo o modelo, pense no significado levando em 
conta a aplicação e faça a pergunta: uma pessoa pode 
casar-se com mais de uma pessoa?
 Se a resposta for SIM, dependendo do tempo, então um 
atributo indicando data de início e data de término devem 
ser considerados na relação (e não nas entidades)
CARDINALIDADES (1:N)
1N
1 Funcionário trabalha em 1 Departamento
Em 1 Departamento trabalham N Nuncionários
CARDINALIDADES 1:N
 Algumas considerações
 Alguns projetistas de sistemas podem ser induzidos a erros 
conceituais quando se pensa em cardinalidade 1:N, 
principalmente quando são confundidos com atributos 
multivalorados
 No final das contas, na implementação, os resultados 
práticos da cardinalidade 1:N e de atributos multivalorados 
podem resultar na mesma coisa
 Depois veremos ressalvas a respeito desses questionamentos
 Vale a recomendação vista anteriormente 
CARDINALIDADES (M:N)
N
1 Médico consulta N Pacientes
M
1 Paciente é consultado por M Médicos
CARDINALIDADES M:N
 Novamente segue a dica
 A cardinalidade deverefletir todo o ciclo de vida da 
aplicação
 No caso do exemplo anterior, durante todo o ciclo de vida 
de uma clínica (ou hospital), imagine que um paciente só 
possa ser atendido por um único médico
 Estranho né?
 Ou pior... Um médico só pode atender um único paciente!
 Absurdo!
 A cardinalidade M:N é justamente para modelar esses 
casos
ENTIDADES FRACAS
 Entidades que não fazem sentido existir se não houver 
outra entidade para as representar
 Existe uma dependência entre as entidades envolvidas
 Entidade fraca não existe sem a entidade principal
 Alguns autores não fazem menção a este tipo de entidade 
por considerarem restritos ao modelo
 A questão maior é: para que se possa identificar uma 
entidade fraca, o atributo-chave da entidade principal 
deve ser considerado (veremos isso adiante)
 Novamente: entidades fracas não são atributos compostos 
ou multivalorados
 Depende da interpretação do problema? SIM
REPRESENTAÇÃO GRÁFICA
Nota: o traço mais “gordinho” indica a existência da 
entidade fraca
ESPECIALIZAÇÕES E
GENERALIZAÇÕES
 Muito usado para descrever de forma genérica entidades 
que tenham características comuns
 Preserva a identidade individual de cada entidade
 Oferece mecanismos de maior abstração para o projeto do 
banco de Dados
 Facilita a leitura, inclusive
ESPECIALIZAÇÕES E
GENERALIZAÇÕES
O “t” indica uma especialização total, isto é, 
o cliente é necessariamente pessoa física 
‘ou jurídica
O “p” indica uma especialização parcial, 
isto é, o funcionário pode ser um 
professor, um assessor ou simplesmente 
um funcionário (genérico)
RELACIONAMENTOS
TERNÁRIOS
 Quando existe a necessidade de representar a relação 
entre mais de duas entidades 
 O produto cartesiano agora, é composto de uma trinca 
composta pelos elementos dos três conjuntos
 Situação
 Como modelar uma situação onde um Distribuidor de 
produtos é exclusivo para uma cidade?
RELACIONAMENTOS
TERNÁRIOS - VISÃO 1
M
N 1
Nesta primeira 
visão 
modelamos que 
um produto 
pode ser 
fornecido para 
várias cidades e 
uma cidade 
pode receber 
vários produtos 
(sem contar 
quem é o 
distribuidor)
RELACIONAMENTOS
TERNÁRIOS – VISÃO 2
M
N 1
Já nesta 2ª 
visão vemos que 
um distribuidor 
pode distribuir 
vários produtos, 
porém um 
produto é 
distribuído por 
apenas 1 
distribuidor 
(caracterizando 
uma 
exclusividade 
de produto).
RELACIONAMENTOS
TERNÁRIOS - VISÃO 3
M
N 1
Finalmente 
nesta 3ª, vemos 
que uma cidade 
possui um único 
distribuidor de 
produtos e que 
um distribuidor 
pode distribuir 
para mais de 
uma cidade, 
caracterizando 
a exclusividade 
de distribuição 
de produtos por 
um distribuidor 
em uma 
determinada 
cidade.
ENTIDADES ASSOCIATIVAS
 Possibilidade de representar um relacionamento na forma 
de uma entidade.
 Em quais situações?
 Na verdade o fato de existir um relacionamento entre duas 
entidades pode fazer com que a interpretação do problema 
crie uma entidade própria, fruto deste relacionamento
ENTIDADES ASSOCIATIVAS
Neste caso, 
podemos 
modelar o 
relacionamento 
“consulta” 
como uma nova 
entidade 
(resultante da 
associação 
entre médico e 
paciente). 
Pensando em 
implementação, 
o resultado é o 
mesmo, porém 
a leitura do 
modelo torna-se 
mais intuitiva
CONSIDERAÇÕES SOBRE O
MODELO ER
 O modelo ER é um modelo Formal
 Mesmo conceitual e em alto nível, ele é um modelo que 
segue regras bem definidas de construção
 Ausência de ambiguidades 
 Diversos leitores sempre terão o mesmo entendimento do 
modelo
 Para se poder extrair corretamente dados de uma base é 
imprescindível a compreensão do modelo de dados 
 Para manipular um modelo ER, deve-se antes compreender 
as notações, regras e leitura dos diagramas ER
CONSIDERAÇÕES SOBRE O
MODELO ER
 Abordagem ER tem poder de expressão limitado
 Nem sempre é possível restringir todas as situações do 
domínio da aplicação
 Exemplo do relacionamento “Casa-se com”
 Quem garante que não estamos representando um marido 
casado com mais de uma esposa?
 Ou ainda, uma pessoa casada com ela mesma?
CONSIDERAÇÕES SOBRE O
MODELO ER
 Diferentes modelos podem ser equivalentes
 Dois modelos são ditos equivalentes quando ambos geram o 
mesmo esquema de Banco de Dados
 Em termos lógicos, modelos conceituais são convertidos para o 
mesmo conjunto de tabelas
 Podem ser usadas diferentes formas de representar a mesma coisa
 Quando um atributo pode ser multivalorado ou tornar-se uma 
entidade com relacionamento?
 O relacionamento “Consulta” entre as entidades “Paciente” e 
“Médico” foi modelado como uma entidade associativa no M-ER.
 Em ambos os casos, “Consulta” será mapeada para uma tabela no 
modelo Relacional
 Respostas para estas perguntas são difíceis de se formalizar e 
dependem muito da “expertise” do desenvolvedor
ALGUNS CRITÉRIOS A
DISCUTIR
 Atributo x Entidade
 Se o atributo em questão estiver vinculado a outras entidades, ideal é que seja modelado como 
entidade
 Para evitar erros ou variações de digitação na inclusão de registros
 Atributo x Generalização/Especialização (como diferenciar uma entidade genérica de uma 
especializada)
 Pergunta básica: a entidade especializada possui atributos específicos?
 Se a resposta for afirmativa, o ideal é criar uma entidade para representar
 Senão provavelmente a alternativa é criar um novo atributo
 Atributos Opcionais e Atributos Multivalorados
 Em geral essa situação ocorre com situações de generalização/especialização
 Deve-se verificar a integridade das combinações dos atributos
 Exemplo: Empregado, Engenheiro, Motorista, Médico (um empregado pode ser Engenheiro e 
Motorista ao mesmo tempo? Seu modelo deve prever esse tipo de inconsistência)
VERIFICAÇÃO DO MODELO
 Erros Sintáticos x Erros Semânticos
 Uma coisa é não entender as notações, outra é criar modelos que não condizem com 
a descrição do sistema
 Completude do modelo
 O modelo atende todas as especificações consegue “enxergar” todas as entidades 
envolvidas na descrição?
 Alguma coisa não foi considerada?
 Modelo deve refletir aspectos temporais
 Atributos que são alterados com o tempo
 Salário-base do funcionário (armazena-se somente o atual ou cria-se um histórico de 
aumentos?)
 Definição das grades de disciplinas em um curso (quando o curso muda de grade, uma 
mesma disciplina pode ter seu conteúdo alterado?)
 Ideal criar um relacionamento para manter o histórico
VERIFICAÇÃO DO MODELO
 Modelo deve ser livre de redundâncias
 Atributos redundantes
 Salário líquido pode ser perfeitamente obtido ao invés de ser 
modelado como um atributo
 Relacionamentos Redundantes
 Um professor ministra uma disciplina.
 Uma disciplina tem vários estudantes
 Um relacionamento vinculando professor e estudantes é 
desnecessário, uma vez que essa informação pode ser obtida 
indiretamente
 Recupera-se qual a disciplina lecionada pelo professor e, em 
seguida a lista de estudantes
VERIFICAÇÃO DO MODELO
 Entidades isoladas
 São aquelas que não possuem relacionamento com 
nenhuma outra entidade do modelo
 Alguns casos
 Entidade EMPRESA em um sistema de folha de pagamentos 
de 1 única empresa
 Entidades que representam parâmetros para o sistema
 De qualquer forma, qualquer entidade isolada deve ser 
analisada com cuidado para não gerar erros semânticos
ESTRATÉGIAS PARA
MODELAGEM
 “Comece a construir uma casa pela planta e não pelo 
telhado”
 Invista maior partedo seu tempo entendendo o problema e 
modelando seus sistema antes de escrever uma linha 
sequer de código
 Construir um sistema é uma atividade incremental
 Não se obtém em um único passo
 Refinamentos e revisões constantes fazem-se necessárias
 Novas restrições, itens não observados e diferenças de 
interpretação podem forçar alterações no modelo
 Idéia básica: conhecer ao máximo sobre o sistema a partir 
da fonte de informação disponível
ESTRATÉGIA 1: DESCRIÇÕES
DE DADOS
 Coletar documentos que possam descrever as informações 
que se deseja armazenar no Banco de Dados
 Nota fiscal, exemplo de pedido, fichas de cadastro
 Dificuldade em extrair informações deste documentos por 
também não conhecer a fundo o processo onde se encaixa 
o domínio da aplicação
 Necessidade de mais ferramentas e maior interação entre 
desenvolvedor e demandante (cliente ou usuário)
 Entrevistas, questionários, acompanhamento do dia-a-dia
 Apesar de parecer algo muito discutido, ainda temos 
muitos problemas de adequação de sistemas ao processo 
da empresa
 O sistema que tem que refletir a empresa e não a empresa 
mudar por causa do sistema
ESTRATÉGIA 2: CONHECIMENTO DOS
ENVOLVIDOS
 Idéia básica é começar a visualizar o sistema como 
uma caixa preta e, gradativamente, detalhar
 Abstracão
 Visão menos detalhada do problema, em um nível mais alto
 Refinamentos
 A partir de um modelo prévio, começa-se a inserir mais 
detalhes e identificar mais elementos (outros 
relacionamentos, atributos, identificadores, cardinalidades)
 Estratégia TOP-DOWN
 Estratégia INSIDE-OUT
TOP-DOWN
 Modelagem Superficial
 Identificação das entidades
 Identificação dos relacionamentos/hierarquias
 Identificação das cardinalidade máximas
 Determinação dos atributos e dos identificadores
 Verificação temporal do Banco de Dados
 Modelagem detalhada
 Domínio dos atributos (tipos dos atributos: numéricos, caracteres, enumerativos)
 Cardinalidades mínimas e máximas, opcionais
 Definem-se mais restrições e integridades que não são representadas pelo Diagrama ER
 Validação do Modelo
 Procura por construções redundantes
 Validação com o usuário (necessita conhecimento e leitura do diagrama)
INSIDE-OUT
 Foco nos conceitos centrais do problema
 Aqueles considerados “principais”
 Relacionamentos imprescindíveis
 A partir daí começam a ser detalhados os conceitos 
periféricos
 Especializações, relacionamentos de entidades 
especializadas
 Muito próximo ao TopDown
 Maior interação e repetições dos 3 primeiros passos da 
modelagem superficial são necessários
ENFIM
 Ideal é fazer uso das diversas técnicas e do máximo de interação 
possível com os interessados (usuários, clientes) do sistema
 Boa capacidade de comunicação e absorção de informações
 Clareza nas definições, para evitar ambigüidades 
 O modelo não é único nem existe “verdade absoluta”
 Olhe, analise, faça a modelagem, olhe novamente, refaça se for o 
caso
 Mas o principal: PENSE UM PASSO A FRENTE.
 Pense naquilo que você quer recuperar e como essa recuperação 
de informação dar-se-á