Scribd Logo
Carregar

Bem-vindo(a) ao Scribd!

  • 31 visualizações

    Sodapdf

    Enviado por

    Zack do mine
    Este documento contém exercícios sobre modelagem de banco de dados relacional a partir de modelos entidade-relacionamento. Nos exercícios, são apresentados modelos ER e perguntas sobre a melhor implementação relacional ou sobre a geração de um modelo ER a partir de um esquema relacional existente.

    Direitos autorais:

    © All Rights Reserved
    Baixe no formato PDF, TXT ou leia online no Scribd

    Sodapdf

    Enviado por

    Zack do mine
    31 visualizações11 páginas
    Este documento contém exercícios sobre modelagem de banco de dados relacional a partir de modelos entidade-relacionamento. Nos exercícios, são apresentados modelos ER e perguntas sobre a melhor implementação relacional ou sobre a geração de um modelo ER a partir de um esquema relacional existente.

    Título original

    sodapdf-converted (2)

    Direitos autorais

    © © All Rights Reserved

    Formatos disponíveis

    PDF, TXT ou leia online no Scribd

    Você considera este documento útil?

    Este conteúdo é inapropriado?

    Este documento contém exercícios sobre modelagem de banco de dados relacional a partir de modelos entidade-relacionamento. Nos exercícios, são apresentados modelos ER e perguntas sobre a melhor implementação relacional ou sobre a geração de um modelo ER a partir de um esquema relacional existente.

    Direitos autorais:

    © All Rights Reserved
    Baixe no formato PDF, TXT ou leia online no Scribd
    Fazer download em pdf ou txt
    31 visualizações11 páginas

    Sodapdf

    Enviado por

    Zack do mine
    Este documento contém exercícios sobre modelagem de banco de dados relacional a partir de modelos entidade-relacionamento. Nos exercícios, são apresentados modelos ER e perguntas sobre a melhor implementação relacional ou sobre a geração de um modelo ER a partir de um esquema relacional existente.

    Direitos autorais:

    © All Rights Reserved
    Baixe no formato PDF, TXT ou leia online no Scribd
    Fazer download em pdf ou txt
    Você está na página 1de 11

    FATEC DE BARUERI

    AAP

    JAVALEARNERS

    Davi Araujo Oliveira | RA: 2090782311020


    Gabriel Spisso | RA: 2090782311038
    Isac de Oliveira Nascimento | RA: 2090782311022
    Luiz Eduardo Trindade Almeida | RA: 2090782311003

    Questionário Cap. 5

    Barueri
    2024
    Exercício 1: Considere as seguintes alternativas de implementação de um
    banco de dados relacional:
    Alternativa 1:
    Aluno(CodAl, Nome, CodCurso, Endereco)
    Alternativa 2:
    Aluno(CodAl, Nome, CodCurso)
    EnderecoAluno(CodAl, Endereco)
    CodAl referencia Aluno
    Em ambos os casos está sendo representado um conjunto de alunos e
    informações (código, nome, código de curso, endereço) a ele referentes. À luz
    dos princípios que baseiam as regras de tradução de diagramas ER para
    modelo relacional, discuta qual das duas alternativas é preferível.
    R:
    A alternativa 1 (Aluno(CodAl, Nome, CodCurso, Endereco)) é preferível, caso
    considerarmos os princípios nos quais estão baseadas as regras de tradução
    de modelos ER para modelos relacionais. Os princípios são (ver livro):

    ➢ Evitar junções - ter os dados necessários a uma consulta em uma única


    linha

    ➢ Diminuir o número de chaves primárias

    ➢ Evitar campos opcionais

    A alternativa 1 atende aos dois primeiros princípios. O terceiro princípio não


    é considerado neste caso, já que nenhuma das alternativas implica em criar
    campos opcionais.
    Quanto ao primeiro princípio, a alternativa 1 minimiza a necessidade de
    junções. Na alternativa 2, cada vez que forem necessários dados do aluno
    junto com dados de seu endereço será necessário fazer uma junção entre as
    duas tabelas.
    Quanto ao segundo princípio, a alternativa 1 implica em um menor número
    de chaves primárias, já que implica em uma única tabela.
    Conforme mencionado no livro, as regras de tradução apresentadas
    representam um conjunto de heurísticas que, em geral, levam a um banco de
    dados bem projetado. Podem existir casos, em que as regras não devem ser
    adotadas, principalmente por limitações do SGBD ou considerações de
    performance. Assim, podem haver situações em que a alternativa 2 é usada,
    mesmo violando os princípios acima. Abaixo consideramos uma situação em
    que a alternativa 2 poderia ser preferível.
    Considere que os dados de aluno (nome e código do curso) e endereço
    sofrem constantemente alterações de valores. Além disso, considere que o
    nome e o código do aluno são alterados através de transações diferentes das
    que alteram o endereço do aluno e que estas alterações ocorrem de forma
    concorrente. A maioria dos SGBD relacionais não permite que duas transações
    diferentes alterem a mesma linha concorrentemente. Neste caso, a alternativa
    1 implica em sequencializar as transações que alteram informações referentes
    a um mesmo aluno, fazendo com que uma transação tenha que esperar pela
    outra. Já na alternativa 2, como os dados estão em tabelas diferentes, as
    transações podem ser executadas de forma concorrente.

    Exercício 2: Usando as regras de transformação de modelos ER para modelo


    lógico relacional apresentadas neste capítulo, projete um BD relacional para o
    modelo ER da Figura 5.30. Para não sobrecarregar o diagrama os atributos das
    entidades são listados a seguir. Os atributos identificadores estão sublinhados.

    Figura 1
    R:
    A Figura 2 mostra o esquema relacional referente ao modelo ER da Figura 1.
    Em relação a este modelo, cabem os seguintes comentários.
    ➢ O relacionamento entre FABRICANTE e PRODUTO foi implementado
    através da chave estrangeira CGC dentro da tabela Produto. Como o
    relacionamento é identificador, a chave estrangeira faz parte da chave
    primária da tabela.

    ➢ A especialização de PRODUTO foi implementada através de tabela


    única (ver seção 5.2.4.3 para uma discussão de alternativas). Para
    identificar o tipo de produto (medicamento ou perfumaria) foi criada uma
    coluna (TipoProd) na tabela Produto.

    Produto (CGC, NúmeroProd, NomeComercial, TipoEmbalagem, Quantidade,


    PreçoUnitário, TipoProd, Tarja, Fórmula, Tipo)
    CGC referencia Fabricante
    Fabricante (CGC, Nome, Endereço)
    Venda (Data, NúmeroNota, NomeCliente, CidadeCliente)
    PerfumariaVenda (CGC, NúmeroProd, NúmeroNota, Quantidade, Imposto)
    (CGC, NúmeroProd) referencia Produto
    NúmeroNota referencia Venda
    MedicamentoVenda (CGC, NúmeroProd, NúmeroNota, Quantidade, Imposto,
    CRM, Número)
    (CGC, NúmeroProd) referencia Produto
    NúmeroNota referencia Venda
    (CRM, Número) referencia ReceitaMédica
    ReceitaMédica (CRM, Número, Data)
    Figura 2: Modelo relacional para o Exercício 2

    ➢ A entidade associativa (relacionamento entre VENDA e


    MEDICAMENTO) foi implementada como um relacionamento n:n
    através de tabela própria.

    ➢ O relacionamento com RECEITA MÉDICA foi implementado através de


    chave estrangeira, dentro da tabela referente à entidade associativa.
    Exercício 3: Usando as regras de transformação de modelos ER para modelo
    lógico relacional apresentadas neste capítulo, projete um BD relacional para o
    modelo ER da Figura 5.31. Para não sobrecarregar o diagrama os atributos das
    entidades são listados a seguir. Os atributos identificadores estão sublinhados.
    Escritório (Número, Local)
    Cliente (NúmeroCartMotorista, EstadoCartMotorista, Nome, Endereço,
    Telefone)
    Contrato aluguel (Número, Data, Duração)
    Veículo (Número, DataPróximaManutenção, Placa)
    Automóvel (NúmeroPortas, DireçãoHidráulica,
    CâmbioAutomático, Rádio)
    Tipo de Veículo (Código, Nome, ArCondicionado)
    Ônibus (NúmeroPassageiros, Leito, Sanitário)

    R:
    A Figura 4 mostra o esquema relacional referente ao modelo ER da
    Figura 3. A implementação segue as regras apresentadas. A única decisão
    tomada foi a de implementar a especialização de TIPO DE VEÍCULO através
    de uma tabela para cada entidade especializada (ver discussão no livro)
    Escritório (NúmeroEscr, Local)
    Contrato aluguel (NúmeroEscr, NúmeroContr, Data, Duração, NúmeroVeic,
    NúmeroCarMotorista, EstadoCarMotorista)
    NúmeroEscr referencia Escritório
    NúmeroVeic referencia Veículo (NúmeroCarMotorista,
    EstadoCarMotorista)
    referencia Cliente
    Cliente (NúmeroCartMotorista, EstadoCartMotorista,
    Nome, Endereço, Telefone)
    Veículo (Número, DataPróximaManutenção, Placa, CódigoTipo)
    CódigoTipo referencia TipoVeiculo

    TipoVeículo (CódigoTipo, Nome, ArCondicionado)


    Similaridade (CódigoTipo, CódigoTipoSimilar)
    CódigoTipo referencia TipoVeiculo
    CódigoTipoSimilar referencia TipoVeiculo
    Automóvel (CódigoTipo, NúmeroPortas, Direção Hidráulica,
    CâmbioAutomático, Rádio)
    CódigoTipo referencia TipoVeículo
    Ônibus (CódigoTipo, NúmeroPassageiros, Leito, Sanitário)
    CódigoTipo referencia TipoVeículo
    Figura 4: Modelo relacional para o Exercício 3

    Exercício 4: Abaixo é apresentado um esquema lógico de um BD relacio- nal


    que armazena dados sobre produtos e vendas em uma loja. Usando as regras
    de engenharia reversa apresentadas anteriormente, construa um diagrama ER
    para este BD.

    Produto (CodigoTipoProd, NumeroProd, DescricaoProd, PreçoProd)


    CodigoTipoProd referencia TipoProd
    /* tabela de produtos de uma loja CodigoTipo Prod é o código do tipo do
    produto, NumeroProd é seu código, DescriçãoProd é uma descrição do produto
    e PreçoProd é seu preço */

    Similaridade (CodigoTipo Prod, NumeroProd, CodigoTipo ProdSim,


    NumeroProdSin
    (CodigoTipoProd, NumeroProd) referencia Produto
    (CodigoTipo Prodsim, NumeroProdSim) referencia Produto

    /* tabela de similaridade de produtos - para cada produto, informa quais são


    seus produtos similares*/

    TipoProd (CodigoTipoProd, DescricaoTipo Prod)

    /* tabela de tipos de produtos, com código e descrição */

    Venda (NúmeroNF, DataVenda, CodReg, CodEmp)


    (CodigoReg) referencia Registradora
    (CodEmp) referencia Empregado

    /* tabela que informa as vendas que ocorreram na loja informa o número da


    nota fiscal, a data da venda, a registradora na qual ocorreu, bem como o
    empregado que a realizou */

    ItemVenda (NúmeroNF, CodigoTipoProd, NumeroProd, Qtdeltem, PreçoItem)


    (NúmeroNF) referencia Venda
    (CodigoTipo Prod, NumeroProd) referencia Produto

    /* tabela com informações dos itens de uma venda, isto é, que produtos e em
    que quantidade e com que preço foram vendidos em uma venda */

    Registradora (CodReg, SaldoReg)


    /* tabela com código e saldo de cada registradora na loja */

    Empregado (CodEmp, Nome Emp, SenhaEmp)

    /* tabela com código, nome e senha de cada empregado da loja */

    R:

    Produto (NumeroProd, DescricaoProd, PreçoProd)


    TipoProd (CodigoTipoProd, DescricaoTipoProd)
    Venda (NúmeroNF, DataVenda)
    ItemVenda (QtdeItem, PreçoItem)
    Registradora (CodReg, SaldoReg)
    Empregado (CodEmp, Nome Emp, SenhaEmp)
    Figura 6: Atributos do modelo ER do Exercício 4
    /* tabela com código, nome e senha de cada empregado da loja */

    A Figura 5 apresenta o modelo ER obtido através da aplicação das


    regras de engenharia reversa de modelos relacionais.
    Os atributos de cada entidade/relacionamento estão listados na Figura 6
    (atributos identificadores estão sublinhados).
    A aplicação das regras é direta. No modelo, apenas foram apresentadas
    as cardinalidades que puderam ser obtidas a partir do modelo ER:
    • A cardinalidade do relacionamento ITEM VENDA é n:n, pois ele repre-
    senta uma tabela cuja chave primária contém múltiplas chaves
    estrangeiras. A regra não determina a cardinalidade mínima.

    • O mesmo se aplica ao relacionamento SIMILAR.

    • Cada ocorrência da entidade PRODUTO está associada a exatamente


    uma ocorrência de TIPO DE PRODUTO. Esta cardinalidade é obtida
    pela sequência de raciocínio abaixo:

    ➢ O relacionamento representa a chave estrangeira CodigoTipoProd da


    tabela Produto. Como no modelo relacional todos campos são
    monovalorados, conclui-se que cada produto pode estar associado a no
    máximo um tipo de produto (cardinalidade máxima 1).

    ➢ Além disso, a chave estrangeira CodigoTipoProd faz parte de uma


    chave primária. Colunas que fazem parte da chave primária são
    obrigatórias. Daí conclui-se que cada produto deve estar
    obrigatoriamente associado a um tipo de produto (cardinalidade mínima
    1).

    • O relacionamento entre VENDA e EMPREGADO representa uma chave


    estrangeira dentro da tabela Venda que não faz parte da chave primária.
    A única restrição de cardinalidade que pode-se derivar do modelo
    relacional é que cada venda tem a ela associado no máximo um
    empregado (cardina- lidade máxima 1). Como o modelo relacional do
    exercício é incompleto e não informa que colunas são obrigatórias e que
    colunas são opcionais, não é possível determinar se uma venda está
    obrigatoria- ou opcionalmente as- sociada a um empregado. Já na outra
    direção do relacionamento (quantas vendas estão associadas a um
    empregado), não é possível derivar nenhuma informação referente à
    cardinalidade a partir do modelo relacional forne- cido.
    • O mesmo aplica-se ao relacionamento entre VENDA e
    REGISTRADORA.

    Exercício 5: Abaixo é apresentado um esquema lógico de um BD relacional


    que armazena dados genealógicos. Usando as regras de engenharia reversa
    apresentadas anteriormente, construa um diagrama ER para este BD.

    Pessoa (PessID, PeasNome, NascLocID, DataNasc,FaleclocID, DataFalec,


    ProfID, FilhoCasamID, Sexo)
    NascLocID referencia Local
    FalecLocID referencia Local
    ProfID referencia Profiss
    FilhoCasamID referencia Casam

    /* Tabela de pessoas: contém o identificador da pessoa, seu nome, local (iden-


    tificador) e data de nascimento, local (identificador) e data de falecimento,
    profissão, identificador do casamento que gerou a pessoa e sexo */

    Local (LocID, Cidade, Pais)

    /* Tabela de locais */

    Profiss (ProfID, Prof Nome)

    /* Tabela de profissões */

    Casam (CasamID, MaridoPessID, EsposaPessID, DataCasam, CasamLoCID)


    EsposaPessID referencia Pessoa
    MaridoPessID referencia Pessoa
    CasamLocID referencia Local
    /* Tabela de casamentos: contém identificador do casamento, identificador do
    marido, identificador da esposa, data do casamento e local (identificador) */
    R:
    A Figura 7 apresenta o diagrama ER obtido por engenharia reversa do
    modelo relacional do exercício.
    Os atributos das entidades e relacionamentos estão listados abaixo
    (atributos identificadores sublinhados):
    Pessoa (PessID, PessNome, DataNasc, DataFalec, Sexo)
    Local (LocID, Cidade, País)
    Profissão (ProfID, ProfNome)
    Casamento (CasamID, DataCasam)

    Você também pode gostar