Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • Coopera RS
  • Wiki
  • Wiki
  • banco de dados

banco de dados · Changes

Page history
Update banco de dados authored Jun 21, 2025 by Tomás Bringhenti Onofrio's avatar Tomás Bringhenti Onofrio
Hide whitespace changes
Inline Side-by-side
banco-de-dados.md
View page @ 3212fa4f
......@@ -9,8 +9,6 @@
<th> [Infra](infraestrutura) </th>
<th> [Código](codigo) </th>
<th> [BD](banco de dados) </th>
<th> [Frontend](Frontend) </th>
<th> [API Backend](API-Backend) </th>
</tr>
</table>
......@@ -18,45 +16,377 @@
<img src="uploads/0abf773b4ac758539bb0e6c6daf2a481/LogoCooperaRS.png" width="150">
</div>
# Documentação do Banco de dados
## Visão Geral
Neste projeto, utilizamos um banco de dados misto, com a base em um banco de dados relacional - utilizando o PostgreSQL - para os dados de quase toda a aplicação, exceto pela lógica dos carrinhos de compras dos usuários, que foi feita de maneira não relacional - utilizando o Redis - para ter um melhor desempenho com esses registros de maior volatilidade.
Este banco de dados suporta toda a criação e relacionamento das entidades necessárias para funcionamento da API do Coopera-RS. Armazena todas as entidades necessárias para o relacionamento de usuários, produtos e compras.
## Banco de Dados Relacional PostgreSQL 15
Foram utilizados o PostgreSQL 15 como banco de dados relacional e o Redis como banco de dados não relacional.
Neste projeto, utilizamos o PostgreSQL 15 como nosso sistema de gerenciamento de banco de dados. O PostgreSQL é um sistema de banco de dados relacional de código aberto altamente confiável e poderoso, que oferece suporte a uma variedade de recursos avançados, como transações, indexação eficiente e consultas complexas.
## 1. Modelagem
### Modelo Conceitual
### 1.1 Modelo Conceitual
A modelagem conceitual foi feita utilizando a ferramenta Astah Professional:
![Captura_de_tela_2025-06-18_212403](uploads/5693056649b005245080a038ca088463/Captura_de_tela_2025-06-18_212403.png)
### Modelo Lógico
### 1.2 Modelo Lógico
A modelagem lógica foi feita utilizando a ferramenta online DrawSQL, por oferecer suporte às funcionalidades específicas do PostgreSQL:
![drawSQL-image-export-2025-06-16](uploads/7ef64ef12371d8d33a37bbcead1d196b/drawSQL-image-export-2025-06-16.png)
![image](uploads/325327671f52ccb180d7a4e2ac584475/image.png)
### Funções de Acesso
Foram feitas Stored Procedures para limitar o acesso ao banco, de maneira que seja controlada. Foram feitas funções para todos os métodos necessários de inserção, remoção, atualização e visualização dos dados.
### PostgreSQL 15
## 2. Diagrama do Banco de Dados (DER)
![[drawSQL-image-export-2025-06-16.png]]
![[Pasted image 20250616192237.png]]
## 3. Tabelas
![image](https://thedeveloperspace.com/wp-content/uploads/2019/09/PostgreSQL-Logo-Smaller.png)
Abaixo segue uma descrição detalhada de cada tabela no banco de dados.
- **Desempenho**: O PostgreSQL é conhecido por seu desempenho excepcional, especialmente quando se trata de consultas complexas e grandes conjuntos de dados.
- **Confiabilidade**: É altamente confiável, com suporte a transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) para garantir a integridade dos dados.
- **Escalabilidade**: O PostgreSQL é escalável e pode lidar com cargas de trabalho crescentes à medida que o projeto se expande.
---
## Banco de Dados Não Relacional com Redis
### 3.1. Tabela `user` (`client`)
Neste projeto, utilizamos o Redis como nosso sistema de gerenciamento de banco de dados não relacional. O Redis é um banco de dados em memória de código aberto, amplamente utilizado por sua alta performance, simplicidade e suporte a estruturas de dados avançadas, como listas, conjuntos, hashes e strings.
A tabela `user` foi criada como `client` para evitar a palavra reservada 'user' do SQL. No entanto, toda a modelagem seguiu a nomenclatura 'user' para manter maior lógica semântica.
Utilizamos uma estrutura em JSON com a lista de itens do carrinho, contendo todas as informações necessárias em cada item, e indexado pelo ID do usuário, aproveitando que o carrinho e o usuário tem uma relação 1-1.
O `user` é o usuário base da aplicação, contendo informações necessárias para poder atuar como comprador. Toda loja também será um user, por isso há a definição do `role`, diferenciando lojas e apenas usuários compradores. Ao ser criado, o usuário é do tipo CLIENT, ativo e não verificado.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ------------------------------- | ------------------------------------------------------------------- | --------------------- |
| `id_user` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o usuário. Auto-incrementado e sequencial. | `57` |
| `email` | `varchar` | `UNIQUE`, `NOT NULL` | Endereço de e-mail do usuário. | `[email protected]` |
| `role` | `enum` | `DEFAULT 'CLIENT'` | Papel do usuário. | `CLIENT` ou `STORE` |
| `name` | `varchar` | `NOT NULL` | Nome completo do usuário. | `João Silva` |
| `phone` | `varchar` | `NOT NULL` | Número de telefone do usuário. | `+5551912345678` |
| `id_address` | `long` | | Marcador do endereço ativo do usuário | `2` |
| `is_verified` | `boolean` | `DEFAULT false` | Sinalizador indicando se o e-mail do usuário foi verificado. | `true` |
| `password` | `varchar` | `NOT NULL` | Senha criptografada do usuário. | `(valor_hash)` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização do registro do usuário. | `2025-06-03 10:00:00` |
| `is_active` | `boolean` | `DEFAULT true` | Sinalizador indicando se a conta do usuário está ativa. | `true` |
---
### 3.2. Tabela `address`
Armazena informações referentes ao endereços cadastrados. Está equipada para receber endereços completos, inclusive com bairro, cidade, estado e país.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ---------------------------------------- | -------------------------------------------------------- | --------------------- |
| `id_address` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o endereço. | `201` |
| `id_user` | `bigint` | `FOREIGN KEY` referencia `user(id_user)` | Identificador do usuário ao qual este endereço pertence. | `101` |
| `cep` | `varchar`(8) | `NOT NULL` | Código de Endereçamento Postal (CEP). | `90000000` |
| `street` | `varchar` | `NOT NULL` | Nome da rua. | `Avenida Brasil` |
| `number` | `INT` | `NOT NULL` | Número do imóvel/edifício. | `123` |
| `unit` | `varchar` | | Complemento. | `301` |
| `neighborhood` | `varchar` | `NOT NULL` | Nome do bairro. | `Centro` |
| `city` | `varchar` | `NOT NULL` | Nome da cidade. | `Alegrete` |
| `state` | `varchar` | `NOT NULL` | Estado ou província (UF). | `RS` |
| `country` | `varchar` | `NOT NULL` | Nome do país. | `Brasil` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização. | `2025-06-03 10:05:00` |
| `is_active` | `boolean` | `DEFAULT true` | Sinalizador indicando se o endereço está ativo. | `true` |
**Relacionamentos:**
* `fk_user`: Relacionamento N:1 com a tabela `user` (`address.fk_user` -> `user.id_user`): cada endereço pertence a um usuário.
---
### 3.3. Tabela `store`
Armazena informações da loja. Como a loja também será um possível usuário comprador, essa tabela é tratada como "extensão" da tabela `user`.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| ----------------- | ------------- | ------------------------------------------------------ | --------------------------------------------------------------------------- | ---------------------------------- |
| `id_store` | `bigint` | `PRIMARY KEY`, `FOREIGN KEY`referencia `user(id_user)` | Identificador único para a loja. **É o mesmo ID do usuário dono da loja.** | `101` |
| `store_name` | `varchar` | `NOT NULL` | Nome da loja. | `Loja Sensacional` |
| `cnpj` | `varchar(14)` | `UNIQUE`, `NOT NULL` | Cadastro Nacional da Pessoa Jurídica (CNPJ) da loja. | `00000000000100` |
| `description` | `text` | | Descrição detalhada da loja. | `Vende produtos de alta qualidade` |
| `main_address_id` | `bigint` | `FOREIGN KEY` referencia `address(id_address)` | Identificador do endereço principal da loja, com a localização física dela. | `205` |
| `profile_img_url` | `text` | | URL da imagem de perfil da loja armazenada no S3. | `https://cdn.example.com/loja.jpg` |
**Relacionamentos:**
* Relacionamento 1:1 com tabela de usuário, replicando o ID, e agindo como uma extensão da tabela.
* Relacionamento 1:1 com tabela de endereços, registrando, opcionalmente, o endereço da loja física, para exibição no mapa.
---
### 3.4. Tabela `store_photo`
Armazena as informações referentes à galeria de uma loja, inclusive as posições para manter o posicionamento desejado. Não contém a foto de perfil.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| ---------------- | ------------ | ------------------------------------------ | ------------------------------------------------ | ----------------------------------- |
| `id_store_photo` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para cada foto da loja. | `401` |
| `fk_store` | `bigint` | `FOREIGN KEY` referencia `store(id_store)` | Identificador da loja à qual esta foto pertence. | `301` |
| `photo_url` | `text` | `NOT NULL` | URL da foto armazenada no S3. | `https://cdn.example.com/foto1.jpg` |
| `position` | `int` | | Ordem/posição da foto no template da galeria. | `NULL`, `1`, `2`, `3` ou `4` |
**Relacionamentos:**
* `fk_store`: Relacionamento N:1 com a tabela `store` (`store_photo.fk_store` -> `store.id_store`).
---
### 3.5. Tabela `metrics`
Armazena as métricas diárias de uma loja, com um registro para cada par loja-dia.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ------------------------------------------ | ------------------------------------------------------------ | --------------------- |
| `id_metrics` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o registro de métricas. | `501` |
| `id_store` | `bigint` | `FOREIGN KEY` referencia `store(id_store)` | Identificador da loja à qual estas métricas pertencem. | `301` |
| `date` | `date` | `NOT NULL` | Data do registro de métricas. | `01/02/2023` |
| `removals` | `int` | `DEFAULT 0` | Contagem de remoções de produtos da loja do carrinho no dia. | `5` |
| `visits` | `int` | `DEFAULT 0` | Contagem de visitas à página da loja no dia. | `5` |
| `views` | `int` | `DEFAULT 0` | Contagem de visualizações de produtos da loja no dia. | `1250` |
| `carts` | `int` | `DEFAULT 0` | Contagem de carrinhos da loja no dia. | `150` |
| `reviews` | `int` | `DEFAULT 0` | Contagem de revisões de pedido da loja no dia. | `45` |
| `completed` | `int` | `DEFAULT 0` | Contagem de pedidos concluídos da loja no dia. | `130` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização das métricas. | `2025-06-03 11:00:00` |
**Relacionamentos:**
* `id_store`: Relacionamento N:1 com a tabela `store` (`metrics.id_store` -> `store.id_store`).
* `UNIQUE(id_store, date)`: O par loja-dia na tabela de métricas deve ser único.
---
### 3.6. Tabela `category`
Armazena as categorias de produto (Eletrônico, Roupas, Etc.).
Será carregada com valores pré-determinados, não recebendo inserções do usuário.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ------------------------------- | ------------------------------------- | ------------- |
| `id_category` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a categoria. | `601` |
| `name` | `varchar` | `UNIQUE`, `NOT NULL` | Nome da categoria. | `Eletrônicos` |
**Relacionamentos:**
* É um 'guarda-chuva' de produtos.
---
### 3.7. Tabela `product`
Armazena as informações gerais do produto, sem ter as informações pertinentes apenas à cada variação.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ------------------------------------------ | --------------------------------------------- | -------------------------------------- |
| `id_product` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o produto. | `701` |
| `id_store` | `bigint` | `FOREIGN KEY` referencia `store(id_store)` | Identificador da loja que vende este produto. | `301` |
| `name` | `varchar` | `NOT NULL` | Nome do produto. | `Super Smartphone` |
| `description` | `text` | | Descrição genérica do produto. | `Smartphone com sistema operacional X` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização. | `2025-05-20 10:00:00` |
**Relacionamentos:**
* `id_store`: Relacionamento N:1 com a tabela `store` (`product.id_store` -> `store.id_store`).
---
### 3.8. Tabela `product_photo`
Armazena N fotos para um produto.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| ------------------ | ------------ | ---------------------------------------------- | ---------------------------------------------------- | --------------------------------------- |
| `id_product_photo` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a foto do produto. | `801` |
| `fk_product` | `bigint` | `FOREIGN KEY` referencia `product(id_product)` | Identificador do produto ao qual esta foto pertence. | `701` |
| `photo_url` | `varchar` | `NOT NULL` | URL da foto do produto armazenada no S3. | `https://cdn.example.com/produto_A.jpg` |
**Relacionamentos:**
* `id_product`: Relacionamento N:1 com a tabela `product` (`product_photo.id_product` -> `product.id_product`).
---
### 3.9. Tabela `product_category` (Tabela Intermediária)
Armazena os relacionamentos categoria-produto, já que estes tem uma relação N:N. Na modelagem do banco, ele foi preparado para um produto ter várias categorias e uma categoria ter vários produtos.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ----------------------------------------------------------------------------------- | --------------------------- | ------------- |
| `fk_product` | `bigint` | `FOREIGN KEY` referencia `product(id_product)`, `PRIMARY KEY` (parte de composta) | Identificador do produto. | `701` |
| `fk_category` | `bigint` | `FOREIGN KEY` referencia `category(id_category)`, `PRIMARY KEY` (parte de composta) | Identificador da categoria. | `601` |
**Relacionamentos:**
* `fk_product`: Relacionamento N:1 com a tabela `product` (`product_category.fk_product` -> `product.id_product`).
* `fk_category`: Relacionamento N:1 com a tabela `category` (`product_category.fk_category` -> `category.id_category`).
---
### 3.10. Tabela `variant_category`
Armazena as **características** de um produto, como Cor, Tamanho, Tecido, etc. Aqui é guardado um valor digitado pelo usuário e cada uma é relacionada apenas ao produto específico.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| --------------------- | ------------ | ---------------------------------------------- | ------------------------------------------------------- | ------------- |
| `id_variant_category` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a categoria da variante. | `1001` |
| `name` | `varchar` | `NOT NULL` | Nome da categoria da variante (e.g., "Cor", "Tamanho"). | `Cor` |
| `id_product` | `bigint` | `FOREIGN KEY` referencia `product(id_product)` | ID do produto com essas características. | `10` |
**Relacionamentos:**
* Referencia o ID do produto `variant_category_product`.
---
### 3.11. Tabela `variant_option`
Armazena as opções para cada característica (`variant_category`) de um produto, como Cores (vermelho, azul), tamanho (P, M, G, 41, 42) etc.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| --------------------- | ------------ | ---------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------- |
| `id_variant_option` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a opção da categoria da variante (característica). | `1001` |
| `option` | `varchar` | `NOT NULL` | Opção | `Vermelho` |
| `id_variant_category` | `bigint` | `FOREIGN KEY` referencia `variant_category(id_variant_category)` | ID da característica. | `10` |
**Relacionamentos:**
* Referencia o ID da característica `id_variant_category`.
---
### 3.12. Tabela `product_variant`
Armazena cada uma das variantes do produto. Cada produto deve ter ao menos uma variante, para ter indicação de preço e estoque. Tem um campo `details` que armazena uma string concatenada de uma opção para cada característica. A concatenação dos valores da variantes é verificada no *backend* e estruturada de forma que, para cada característica do produto, haja um valor de opção na string concatenada, ordenada por valor crescente de `id_variant_category`.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------------- | ------------ | ---------------------------------------------- | -------------------------------------------------------------- | --------------------- |
| `id_product_variant` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a variante do produto. | `1101` |
| `fk_product` | `bigint` | `FOREIGN KEY` referencia `product(id_product)` | Identificador do produto base. | `701` |
| `stock` | `int` | `NOT NULL` | Estoque disponível para esta variante. | `50` |
| `price` | `decimal` | `NOT NULL` | Preço desta variante específica. | `29.99` |
| `details` | `varchar` | `NOT NULL` | Detalhes específicos da variante concatenados de forma lógica. | `vermelho_gg_algodao` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização. | `2025-06-01 12:00:00` |
| `is_active` | `boolean` | `DEFAULT true` | Sinalizador indicando se esta variante está ativa. | `true` |
**Relacionamentos:**
* `fk_product`: Relacionamento Muitos-para-Um com a tabela `product` (`product_variant.fk_product` -> `product.id_product`).
---
### 3.13. Tabela `sponsor`
Armazena as informações dos patrocinadores do Coopera-RS.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------- | ------------ | ------------------------------- | ---------------------------------------- | ------------- |
| `id` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o patrocinador. | `1001` |
| `name` | `varchar` | `NOT NULL` | Nome do patrocinador | `PUCRS` |
| `url` | `text` | | URL do site do patrocinador. | `pucrs.br` |
| `image_url` | `text` | | URL da imagem do patrocinador | |
**Relacionamentos:**
* Nenhum
---
### 3.14. Tabela `order`
Armazena as ordens do *marketplace*.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| ---------------- | ------------ | ---------------------------------------------- | ------------------------------------------ | -------------------------------------------- |
| `id_order` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o pedido. | `1301` |
| `fk_user` | `bigint` | `FOREIGN KEY` referencia `user(id_user)` | Identificador do usuário que fez o pedido. | `101` |
| `fk_store` | `bigint` | `FOREIGN KEY` referencia `store(id_store)` | Identificador da loja de onde o pedido é. | `301` |
| `date` | `date` | `NOT NULL` | Data em que o pedido foi feito. | `2025-06-03` |
| `payment_method` | `enum` | `NOT NULL` | Método de pagamento utilizado. | `'PIX','CREDIT','DEBIT','CASH'` |
| `status` | `enum` | `NOT NULL` | Status atual do pedido. | `PENDING,PREPARING,SENT,DELIVERED,CANCELLED` |
| `fk_address` | `bigint` | `FOREIGN KEY` referencia `address(id_address)` | Endereço de entrega do pedido. | `201` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização do pedido. | `2025-06-03 14:30:00` |
**Relacionamentos:**
* `fk_user`: Relacionamento N:1 com a tabela `user`.
* `fk_store`: Relacionamento N:1 com a tabela `store`.
* `fk_address`: Relacionamento N:1 com a tabela `address`.
---
### 3.15. Tabela `order_item`
Armazena cada item de uma ordem, com referência para o item, a ordem e a quantidade.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| -------------------- | ------------ | -------------------------------------------------------------- | --------------------------------------------------- | ------------- |
| `id_order_item` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para o item do pedido. | `1401` |
| `fk_order` | `bigint` | `FOREIGN KEY` referencia `order(id_order)` | Identificador do pedido ao qual este item pertence. | `1301` |
| `fk_product_variant` | `bigint` | `FOREIGN KEY` referencia `product_variant(id_product_variant)` | Identificador da variante do produto pedida. | `1101` |
| `quantity` | `int` | `NOT NULL` | Quantidade da variante do produto pedida. | `2` |
**Relacionamentos:**
* `fk_order`: Relacionamento N:1 com a tabela `order`.
* `fk_product_variant`: Relacionamento N:1 com a tabela `product_variant`.
---
### 3.16. Tabela `evaluation`
Armazena todas as informações pertinentes ao sistema de avaliações.
**Colunas:**
| Nome da Coluna | Tipo de Dado | Restrições (Constraints) | Descrição | Valor Exemplo |
| --------------- | ------------ | ------------------------------------------ | ------------------------------------------------- | --------------------- |
| `id_evaluation` | `bigserial` | `PRIMARY KEY`, `AUTO_INCREMENT` | Identificador único para a avaliação. | `1501` |
| `fk_order` | `bigint` | `FOREIGN KEY` referencia `order(id_order)` | Identificador do pedido sendo avaliado. | `1301` |
| `rating` | `int` | `NOT NULL` | Avaliação dada pelo usuário (e.g., 1-5 estrelas). | `5` |
| `comment` | `varchar` | `NOT NULL` | Comentário em texto ou avaliação. | `Ótimo produto!` |
| `answer` | `varchar` | | Resposta da loja à avaliação. | `Obrigado!` |
| `date` | `date` | `NOT NULL` | Data em que a avaliação foi enviada. | `2025-06-10` |
| `last_updated` | `timestamp` | `DEFAULT CURRENT_TIMESTAMP` | Timestamp da última atualização. | `2025-06-10 09:00:00` |
**Relacionamentos:**
* `fk_order`: Relacionamento 1:1 com a tabela `order`.
---
## Modelo não-relacional utilizando Redis
![image](uploads/a3b0a597e21603c1a427673b57464d71/bd-redis-logo-ag2.png)
Para a implementação do carrinho, devido à sua alta volatilidade e frequentes operações de sobrescrever e deletar informações, optou-se por integrar um modelo não relacional. Cada carrinho irá conter informações do usuário dono do carrinho e da loja, bem como uma lista de itens, como mostra o exemplo abaixo:
```json
{
"id_user": 17,
......@@ -89,15 +419,4 @@ Utilizamos uma estrutura em JSON com a lista de itens do carrinho, contendo toda
}
]
}
```
### Redis
![image](uploads/a3b0a597e21603c1a427673b57464d71/bd-redis-logo-ag2.png)
- **Desempenho:** O Redis é extremamente rápido, oferecendo operações com latência muito baixa, uma vez que armazena todos os dados diretamente na memória. Isso o torna ideal para aplicações que exigem respostas em tempo real.
- **Confiabilidade:** Apesar de ser um banco em memória, o Redis oferece mecanismos robustos de persistência, como snapshots e log de operações (AOF), garantindo a durabilidade dos dados mesmo em caso de falhas.
- **Escalabilidade:** O Redis é altamente escalável, suportando replicação, particionamento de dados (sharding) e integração com soluções de alta disponibilidade (Redis Sentinel) e escalabilidade horizontal (Redis Cluster), permitindo seu uso em aplicações com grande volume de acessos simultâneos.
```
Clone repository
  • API Backend
  • Escopo e Cronograma
  • Frontend
  • Processo
  • arquitetura
  • banco de dados
  • codigo
  • configuracao
  • design
    • mockups
  • Home
  • infraestrutura