Se existe uma maneira de fazer compras online, por que não usá-la? Este artigo examina o modelo de dados por trás do sistema de entrega de um supermercado.
Ainda temos uma sensação especial ao colher algo do jardim e prepará-lo imediatamente – mas não é algo que possamos fazer com frequência. O ritmo acelerado de hoje não permite isso. Na verdade, às vezes nem nos permite ir à loja “pegar” nossas compras. Portanto, faz sentido economizar algum tempo e usar um aplicativo para pedir o que precisamos. Nosso pedido só vai aparecer em nossa casa. Talvez não tenhamos aquela sensação especial de recém-colhido, mas haverá comida na nossa mesa.
O modelo de dados por trás de tal aplicativo é o tema do artigo de hoje.
O que precisamos para um modelo de dados de entrega de supermercado?
A ideia desse modelo é que um aplicativo (web, mobile, ou ambos) permita que clientes cadastrados criem um pedido (composto por produtos da nossa loja). Em seguida, este pedido será entregue ao cliente. Obviamente, armazenaremos os dados do cliente e uma lista de todos os produtos disponíveis para dar suporte a isso.
Os clientes podem fazer vários pedidos que incluem itens diferentes em quantidades diferentes. Quando o pedido de um cliente é recebido, os funcionários da loja devem ser notificados para que possam encontrar e embalar os itens necessários. (Isso pode exigir um ou mais contêineres.) Finalmente, os contêineres serão entregues, juntos ou separadamente.
No próprio aplicativo, clientes e funcionários devem poder inserir notas e avaliar a outra parte após a entrega.
O modelo de dados
O modelo de dados consiste em três áreas de assunto:
Items & unitsCustomers & employeesOrders
Apresentaremos cada área de assunto na ordem em que está listada.
Seção 1:Itens e Unidades
Começaremos com os Items & units área de estudo. Embora seja uma pequena parte do nosso modelo, contém duas tabelas muito importantes.
A unit table armazena informações sobre as unidades que atribuiremos a qualquer item em nosso inventário. Para cada valor nesta tabela, armazenaremos dois valores UNIQUE:unit_name (por exemplo, “quilograma”) e unit_short (por exemplo, “kg”). Observe que unit_short é a abreviação de unit_name .
A segunda tabela nesta área de assunto é item . Ele lista todos os itens que temos em estoque. Para cada item, armazenaremos:
item_name– O nome ÚNICO que usaremos para esse item.price– O preço atual desse item.item_photo– Um link para uma foto deste item.description– Descrição textual adicional do item.unit_id– Faz referência àunitdicionário e denota a unidade usada para medir esse item.
Por favor, note que eu omiti algumas coisas aqui. O mais importante é um sinalizador que indica se um item de inventário está sendo oferecido para venda no momento. Por que não temos isso? Isso exigiria pelo menos um campo adicional (o sinalizador), bem como outra tabela (para armazenar as alterações históricas de cada item). Para simplificar as coisas, presumi que todos os itens que temos em estoque também estão disponíveis para venda.
A segunda coisa importante que omiti é rastrear o status do armazém. Minha suposição é que enviamos tudo de um armazém central e que sempre teremos itens disponíveis. Se não tivermos um item, simplesmente notificaremos o cliente e ofereceremos um item semelhante em substituição.
Seção 2:Clientes e Funcionários
Os Customers & employees A área de assunto contém todas as tabelas necessárias para armazenar dados de clientes e funcionários. Usaremos essas informações na parte central do nosso modelo.
O employee tabela contém uma lista de todos os funcionários relevantes (por exemplo, os embaladores de supermercado e os entregadores). Para cada funcionário, armazenaremos seu first_name e last_name e um employee_code ÚNICO valor. Embora a coluna id também seja ÚNICA (e a chave primária desta tabela), é melhor usar outro valor real (por exemplo, um número de IVA) como identificador de funcionário. Assim, temos o employee_code campo.
Observe que não incluí detalhes de login de funcionários, funções de funcionários e uma maneira de rastrear o histórico de funções. Estes podem ser facilmente adicionados, conforme descrito neste artigo.
Agora vamos adicionar clientes ao nosso modelo. Isso levará mais duas tabelas.
Os clientes serão segmentados geograficamente, então precisaremos de uma city dicionário. Para cada cidade onde oferecemos entrega de compras, armazenaremos o city_name e o postal_code . Juntos, eles formam a chave alternativa desta tabela.
Os clientes são definitivamente a parte mais importante deste modelo; são eles que iniciam todo o processo. Armazenaremos uma lista completa de nossos clientes no customer tabela. Para cada cliente, armazenaremos o seguinte:
first_name– O primeiro nome do cliente.last_name– O sobrenome do cliente.user_name– O nome de usuário que o cliente selecionou ao configurar sua conta.password– A senha que o cliente escolheu ao configurar sua conta.time_inserted– O momento em que este registro foi inserido no banco de dados.confirmation_code– Um código que foi gerado durante o código de registro. Este código será usado para verificar o endereço de e-mail.time_confirmed– Quando ocorreu a confirmação por e-mail.contact_email– O endereço de e-mail do cliente, que também é usado como e-mail de confirmação.contact_phone– O número de telefone do cliente.city_id– O ID dacityonde o cliente reside.address– O endereço residencial do cliente.delivery_city_id– O ID dacityonde o pedido do cliente deve ser entregue.delivery_address– O endereço de entrega preferido. Observe que isso pode ser (mas não precisa ser) o mesmo que o endereço residencial do cliente.
Seção 3:Pedidos
A parte central e mais importante deste modelo são os Orders área de estudo. Aqui encontraremos todas as mesas necessárias para fazer um pedido e acompanhar os itens até que sejam entregues aos clientes.
Todo o processo começa quando um cliente faz um pedido. Uma lista de todos os pedidos já feitos está em placed_order tabela. Eu usei intencionalmente esse nome e não “order” porque order é uma palavra-chave reservada do SQL. Para cada pedido, armazenaremos:
customer_id– O ID docustomerque fez este pedido.time_placed– O carimbo de data/hora em que este pedido foi feito.details– Todos os detalhes relacionados a esse pedido, em formato textual não estruturado.delivery_city_id– Uma referência àcityonde este pedido deve ser entregue.delivery_address– O endereço onde este pedido deve ser entregue.grade_customer&grade_employee– Notas dadas pelo funcionário e cliente após a conclusão de um pedido. Até aquele momento, este atributo contém um valor NULL. A nota de um cliente indica o quanto ele ficou satisfeito com nosso serviço; a nota de um funcionário nos fornece informações sobre o que esperar da próxima vez que o cliente fizer um pedido.
Durante o processo de fazer um pedido, um cliente selecionará um ou mais itens. Para cada item, eles definirão uma quantidade desejada. Uma lista de todos os itens relacionados a cada pedido é armazenada no
order_item tabela. Para cada registro nesta tabela, armazenaremos os IDs do pedido relacionado (placed_order_id ), item (item_id ), a quantidade desejada e o price quando este pedido foi feito. Além de o que eles querem que seja entregue, os clientes também definirão o tempo de entrega desejado . Para cada pedido, criaremos um registro na
delivery tabela. Isso gravará o delivery_time_planned e inserir notas textuais adicionais. O placed_order_id atributo também será definido quando este registro for inserido. Os dois atributos restantes serão definidos quando atribuirmos essa entrega a um funcionário (employee_id ) e quando o pedido foi entregue (delivery_time_actual ). Embora possa parecer que teremos apenas uma entrega por pedido, nem sempre será esse o caso. Podemos precisar fazer duas ou mais entregas por pedido, e essa é a principal razão pela qual optei por colocar os dados de entrega em uma nova tabela.
Quando começamos a processar um pedido, os funcionários embalam os itens em uma ou mais caixas. Cada
box será definido EXCLUSIVAMENTE por seu box_code e será atribuído a uma entrega (delivery_id ). Também armazenaremos o ID do funcionário que preparou essa caixa. Cada caixa conterá um ou mais itens. Portanto, no
item_in_box tabela, precisaremos armazenar referências à box tabela (box_id ) e o item tabela (item_id ), bem como a quantidade colocada nessa caixa. O último atributo, is_replacement , denota se um item é um substituto para outro item. Podemos esperar que um funcionário entre em contato com um cliente antes de colocar um item de reposição em uma caixa. Um resultado dessa ação pode ser que um cliente concorde com o item de substituição; outro poderia ser o cancelamento de todo o pedido. As três tabelas restantes no modelo estão intimamente relacionadas a status e comentários.
Primeiro, armazenaremos todos os status possíveis no
status_catalog . Cada status é definido EXCLUSIVAMENTE por seu status_name . Podemos esperar status como “pedido criado”, “pedido feito”, “itens embalados”, “em trânsito” e “entregue”. Os status serão atribuídos aos pedidos automaticamente (após a conclusão de algumas partes do processo) ou, em alguns casos, manualmente (por exemplo, se houver um problema com o pedido). Todos os status de pedidos disponíveis são armazenados em
order_status tabela. Além de chaves estrangeiras de duas tabelas (status_catalog e placed_order ), armazenaremos o timestamp real quando esse status foi atribuído (status_time ) e quaisquer details adicionais em formato textual. A tabela final neste modelo são as
notes tabela. A idéia por trás desta tabela é inserir todos os comentários adicionais relacionados a um determinado pedido (placed_order_id ). Os comentários podem ser inseridos por funcionários ou clientes. Para cada registro, apenas um dos employee_id ou customer_id os campos conterão um valor; o outro será NULL. Armazenaremos o momento em que esta nota foi inserida no sistema (note_time ) e o note_text . Que mudanças você faria no modelo de dados de entrega de supermercado?
Hoje discutimos um modelo de dados que poderia dar suporte a aplicativos de entrega de supermercado na web e em dispositivos móveis – tanto do ponto de vista do cliente quanto do funcionário. Como já mencionado neste artigo, existem muitas maneiras de melhorar esse modelo. Sinta-se à vontade para adicionar suas sugestões. Diga-nos o que você adicionaria a este modelo ou removeria dele. Ou talvez você organize essa estrutura de forma completamente diferente. Deixe-nos saber na seção de comentários!
