Você está na página 1de 4

Exercício 1:

O modelo apresentado não contém a restrição mencionada. Para incluir essa


restrição, pode-se adicionar uma condição de integridade referencial que impeça um
produto de ser listado como componente de si mesmo. Se o nível de profundidade
da hierarquia de composição de cada produto não exceder três, pode-se usar
gatilhos ou procedimentos armazenados para verificar essa condição durante a
inserção ou atualização dos dados.

Para uma hierarquia não limitada de níveis de composição, uma solução seria
implementar uma verificação recursiva durante a inserção ou atualização dos dados,
garantindo que nenhum produto possa ser seu próprio componente direto ou
indireto.

Exercício 2:

Vantagens de modelar o país como atributo da entidade cliente:

● Simplifica o modelo, reduzindo o número de entidades.


● Pode ser apropriado se o país não tiver muitos atributos associados.
● Desvantagens:
● Dificulta consultas relacionadas ao país, pois exigiria joins com a tabela de
países.
● Não permite armazenar informações adicionais sobre o país.
● Vantagens de modelar o país como entidade relacionada à cliente:
● Permite armazenar informações detalhadas sobre o país.
● Facilita consultas relacionadas ao país.
● Desvantagens:
● Complexidade adicional no modelo de dados.
● Pode aumentar a complexidade das consultas com joins adicionais.

Exercício 3:

Para modelar mais precisamente a realidade, pode-se criar duas entidades distintas:
PessoaFisica e PessoaJuridica. Cada uma terá seus próprios atributos, e a entidade
Cliente será uma entidade fraca, relacionada a PessoaFisica e PessoaJuridica por
meio de relacionamentos identificadores. Isso permite distinguir entre pessoas
físicas e jurídicas de forma mais clara e precisa.

Exercício 4:

Transformar o modelo ER da notação Chen para a notação da Engenharia de


Informações envolve basicamente representar entidades como retângulos, atributos
como elipses conectadas às entidades por linhas e relacionamentos como losangos
conectados às entidades participantes por linhas. Além disso, a cardinalidade dos
relacionamentos é representada diretamente nas linhas que conectam os
relacionamentos às entidades.

Exercício 5:

Para transformar o modelo ER para a notação europeia de cardinalidades, é


necessário analisar as cardinalidades dos relacionamentos e representá-las de
acordo com a convenção europeia. Se as restrições de integridade especificadas
pelo modelo da Figura 2.11 não estiverem refletidas na notação europeia, isso
exigiria uma análise mais aprofundada para garantir que todas as restrições sejam
adequadamente representadas.

Exercício 6:

Para incluir as informações de CPF e número de inscrição no PASEP para cada


servidor no modelo da Figura 3.10, pode-se simplesmente adicionar esses dois
atributos à entidade Servidor, conforme mostrado no diagrama ER.

exercício 7 Estudo de caso - Administradora de imóveis.

(administradora)-administra->(condomínio)
(condomínio)-formado_por->(unidade_condominial)
(unidade_condominial)-de_propriedade_de->(pessoa)
(pessoa)-possui->(unidade_condominial)
(unidade_condominial)-alugada_para->(pessoa)
(pessoa)-aluga->(unidade_condominial)

exercício 8 Estudo de caso - Locadora de mídias antigas (adaptado do material de


um curso de modelagem de dados da Oracle).

(filme)-contém->(fita)
(filme)-estrelado_por->(ator)
(ator)-estrela->(filme)
(cliente)-aluga->(fita)
(fita)-de->(tipo)
(fita)-em->(filial)
exercício 9 Estudo de caso — Sistema de reserva de passagens aéreas.

(cliente)-faz->(reserva)
(reserva)-compreende->(trecho_voo)
(trecho_voo)-de->(voo)
(voo)-operado_por->(aeronave)
(voo)-de->(origem)
(voo)-para->(destino)
(voo)-em->(data)
(reserva)-na_classe->(classe)
(assento)-reservado_para->(passageiro)
(reserva)-tem->(assento)
(voo)-em->(dia_semana)

exercício 10 Estudo de caso - Sistema para locadora de veículos.

(cliente)-aluga->(veículo)
(veículo)-em->(filial)
(veículo)-do->(tipo)
(tipo)-com->(características)
(veículo)-segurado_por->(seguradora)
(cliente)-motorista_de->(veículo)
(veículo)-tem->(reserva)
(reserva)-inclui->(pedido)
(pedido)-para->(tipo)
(pedido)-inclui->(peça)
(filial)-controla->(veículo)

exercício 11 Estudo de caso - Sistema de preparação de congressos da IFIP.

(congresso)-promovido_por->(GT)
(congresso)-organizado_por->(CO)
(congresso)-coordenado_por->(CP)
(congresso)-tem->(sessão)
(sessão)-inclui->(artigo)
(sessão)-moderada_por->(moderador)
(sessão)-acontece->(horário)
(artigo)-escrito_por->(autor)
(autor)-avalia->(artigo)
(autor)-convidado_para->(avaliador)
exercício 12 Estudo de caso - Sistema de almoxarifado. (O enunciado deste
trabalho foi adaptado de um livro de Peter Coad sobre projeto orientado a objetos.)

(empresa)-cliente_do->(almoxarifado)
(almoxarifado)-organizado_em->(corredor)
(corredor)-contém->(receptáculo)
(receptáculo)-estoca->(peça)
(receptáculo)-recebe->(estrado)
(estrado)-chegou_com->(entrega)
(entrega)-solicitada_por->(ordem_compra)
(ordem_compra)-emitida_por->(compras)
(ordem_compra)-aguarda->(entrega)
(ordem_compra)-inclui->(peça)
(pedido)-solicitado_por->(cliente)
(pedido)-inclui->(peça)
(pedido)-entregue_em->(rampa_carga)

Você também pode gostar