Database
 sql >> Base de Dados >  >> RDS >> Database

Projeto de Banco de Dados 101


Um bom exercício de modelagem de dados para iniciantes é criar um modelo de dados de uma loja on-line . Toda vez que dou este exercício aos meus alunos, fico surpreso com o quão difícil é para eles.

Encontre os conceitos...


Vamos ver como isso pode ser feito. Sabemos que temos que criar uma tabela para cada conceito no domínio. Pense nos substantivosfrases nominais você usaria para descrever o domínio. Grosso modo, todo substantivo é um conceito, um atributo de um conceito ou um exemplo . Quais são os conceitos básicos em uma loja online? Duas palavras imediatamente me vêm à mente:
  • clientes – pessoas que compram coisas em nossa loja e
  • produtos – itens que as pessoas compram em nossa loja.

Cada cliente tem um conjunto básico de dados que os descrevem:id (geralmente você precisa de um atributo id em sua tabela), nome, email e senha. Da mesma forma, um produto tem um id e um nome. Poderíamos adicionar mais atributos para clientes e produtos, mas para este exemplo, eles servirão. Adicionamos as duas tabelas em nosso modelo.


... Assim como os conceitos abstratos


Esta é uma loja, então, obviamente, queremos saber o que foi solicitado e por quem . “Ordem” é uma palavra-chave na maioria dos bancos de dados, portanto, não devemos usá-la para um nome de tabela. Em vez disso, usaremos o nome purchase para a terceira tabela em nosso modelo. A tabela deve estar de alguma forma conectada ao customer e para o product . Para começar, vamos apenas desenhar uma referência entre purchase e customer , e entre purchase e product .



A customer-purchase referência está OK. Cada compra é feita por um cliente; cada cliente pode fazer várias compras. Esta referência veio para ficar.

No entanto, há algo errado com o purchase-product referência. Vários produtos podem ser adquiridos em uma compra; várias compras podem incluir o mesmo produto. Mas nossa referência só permite a compra de um produto em uma única compra. Vamos excluir a referência e pensar em uma maneira diferente de modelá-la.


Um campo de texto grande para todos os produtos comprados?


Que tal adicionarmos um grande campo de texto que pode armazenar os nomes ou ids dos produtos comprados? Agora podemos comprar vários produtos em uma só compra. No entanto, existem alguns problemas aqui:
  • Primeiro, é difícil verificar se o produto em purchased_items campo está realmente no banco de dados.
  • Segundo, se você quiser alterar o nome do produto (porque você o digitou incorretamente), precisará atualizar todos os purchased_items instâncias de campo em purchase tabela.
  • Finalmente, é difícil analisar dados no banco de dados. Por exemplo, se você quiser descobrir qual produto é comprado com mais frequência, precisará usar uma operação de substring de texto. E isso nunca é muito eficiente.


Várias colunas de produtos na tabela de compras?


Quais são algumas outras opções? Queremos que uma compra seja conectada a vários produtos, então talvez devêssemos adicionar vários purchase_item colunas em uma tabela de compra? Bem, isso é cansativo (só adicionei 5 colunas e cansei) e cria um artificial e estúpido limite no número de produtos comprados.


Use uma tabela intermediária!


A solução tola sugere a solução certa. Queremos ter um ilimitado número de produtos vinculados à compra. A única maneira é ter uma tabela de conexão intermediária . Vamos chamá-lo de purchase_item . O purchase_item a tabela está conectada com purchase e product . Agora uma compra pode incluir quantos produtos quisermos. Como bônus, podemos adicionar dados adicionais na tabela:número de vezes comprado, preço total para este item e assim por diante.

Conclusões:

  • As tabelas no modelo podem representar não apenas objetos físicos como cliente ou produto. As tabelas podem representar mais conceitos abstratos como uma compra. Outros exemplos podem ser uma reserva em um sistema de reservas de hotel, um book_loan em um modelo para biblioteca, uma consulta em um sistema para médicos etc.
  • Quando você modela uma transação (ou seja, compra ou venda de muitas coisas), geralmente precisa de três tabelas :um para a transação (compra ou reserva em um sistema de reservas de hotel), um para itens comprados/vendidos em uma transação (produto, quarto de hotel) e um para itens de transação (compra_item, reserva_item). Você pode adicionar informações adicionais na tabela intermediária, se necessário.

Crie seu próprio modelo de banco de dados de loja com Vertabelo!