Início / dba / Perguntas / 334625
Accepted
McNanners
Asked: 2024-01-07 03:03:27 +0800 CST

ERD 2ª Forma Normal

  • 772

Atualmente estou estudando uma unidade sobre desenvolvimento de banco de dados e estou em um módulo sobre normalização, acredito que este ERD completou a normalização da 2ª forma, pois cada tabela possui uma chave primária, todos os dados são atômicos e não há grupos repetidos, e Não acredito que haja qualquer dependência parcial de chave. Mas sou novo e meu entendimento ainda é fraco. Então, eu queria saber se alguém poderia dar uma olhada e me dizer o que pensa e, possivelmente, qualquer ajuda que eu agradeceria muito.

(Incluirei uma foto do ERD também, obrigado novamente)insira a descrição da imagem aqui

Editar: não tenho certeza se devo raspar a tabela PostCodeAndCity e incluir os dados da cidade na tabela de endereços, mas isso foi sugerido pelos meus materiais de estudo.

Edit2: Por ter criado uma conta para esta pergunta, não tenho reputação de votar positivamente em suas respostas, mas só queria agradecer a todos que dedicaram seu tempo para compartilhar seu conhecimento, eu realmente aprecio isso e ajudou ainda mais meu muito!

database-design

3 respostas

  1. Best Answer

    O maior problema é a tabela de pedidos. Da forma como está, um usuário pode fazer apenas um único pedido. Você precisará de vários order_ids para compras de muitos produtos. Na verdade, você precisa de duas tabelas: uma para manter o total de uma compra (pense nela como todas as metainformações que você encontra em um recibo) e uma tabela que contém os produtos e quantidades associadas a um order_id específico. Você também deseja manter um preço no produto adquirido, uma vez que os preços mudam nos produtos do catálogo.

    O engraçado é que nosso livro trata exatamente do mesmo problema de banco de dados e foca no design. Está em acesso antecipado, então não tenho o capítulo 5 ao vivo que mostraria o diagrama, mas você pode ver a análise de requisitos aqui só para ter uma ideia: https://livebook.manning.com/book/grokking-relational-database -design/capítulo-3/v-1/ponto-18510-126-133-1

    • 0

  2. código postalCidade:

    postalCode PK
city

postalCode    city
-------------------
1234          abcd
5678          lmnop
8900          xy123

    endereço:

    addressId PK
propertyNo
street
postalCode (associated with the postalCodeCity.postalCode)

addressId    postalCode
------------------------
1            5678
2            1234
3            5678

    Não tenho certeza se devo raspar a tabela PostCodeAndCity e incluir os dados da cidade na tabela de endereços, mas isso foi sugerido pelos meus materiais de estudo.

    Ter uma tabela postalCodeCity garante que a cidade e o código postal estejam relacionados de forma consistente.

    Outra coisa a observar é que os pedidos são normalmente modelados como pedidos e linhas de pedido – ou seja, duas entidades. Um cliente está associado a um pedido. Um pedido possui informações como ID do pedido (ou número) e isso identifica um pedido de forma exclusiva, a data do pedido e o cliente (que fez o pedido). E um pedido tem várias linhas. Cada linha de pedido possui ID de linha de pedido, ID de pedido, ID de produto e quantidade do pedido. Este é um conceito geral de clientes e pedidos.

    • 0
    • Ter um ID substituto como chave primária não identifica uma linha nem impõe qualquer exclusividade em relação aos dados reais. Não há nada que o impeça de ter vários produtos com o mesmo nome, clientes com o mesmo nome completo, endereços de e-mail duplicados, etc. Você deve identificar as chaves reais que tornam cada linha única e, se insistir em manter os substitutos, então marque as chaves reais como Chaves Alternativas (AK).
    • Pratique um método de modelagem padrão se você o levar a sério.
    • Não há razão para lidar com questões físicas como tipos de dados em um estágio tão inicial de modelagem. Eu entendo que é uma prática que você vê em todos os lugares, em livros e online, mas ela já ofereceu algum valor real para você? Além disso, remova os prefixos inúteis de tudo. Mesmo que houvesse uma razão para ter este tipo de prefixos na implementação física, o que não creio que exista, todo o ruído é especialmente prejudicial nesta fase.
    • 0

relate perguntas