GitLab

Banco de Dados

Esta página é dedicada ao banco de dados utilizado no projeto.

Sumário

• Descrição
• Modelagem
• Tabelas e Relações

Descrição

O PostgreSQL é um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) de código aberto que oferece um ambiente altamente escalável e seguro para armazenamento e recuperação de dados. Sua arquitetura modular e flexível, combinada com recursos avançados como transações ACID e suporte a JSON, tornou-o uma escolha preferencial para este projeto.

Modelagem

Esquema Conceitual

A modelagem conceitual é a primeira etapa do processo de construção de um banco de dados. Ela tem como objetivo representar graficamente os dados e as relações do mundo real que se busca modelar, de forma independente de qualquer tecnologia ou SGBD.

Inicialmente, foi elaborada a modelagem conceitual com o objetivo de compreender as entidades presentes no domínio do problema e as relações existentes entre elas. Durante esse processo, o grupo identificou as seguintes entidades: Usuário, Cliente, Empresa, Atendimento, Avaliação, Intérprete, Especialidade e Disponibilidade. A partir dessa identificação, foram definidos os relacionamentos entre as entidades, representando a dinâmica do sistema de forma abstrata e independente de implementação. A equipe optou por não incluir os atributos nem as cardinalidades nessa etapa, concentrando esses detalhes na modelagem relacional, onde seriam mais adequadamente representados de acordo com as regras do modelo lógico de banco de dados.

Esquema Lógico

Concluída a modelagem conceitual, partiu-se para a modelagem lógica, onde o modelo abstrato foi transformado em uma estrutura relacional composta por tabelas normalizadas, com chaves primárias, estrangeiras e restrições de integridade, visando garantir a consistência dos dados e evitar redundâncias.

Em seguida, essa modelagem lógica é convertida em uma modelagem física, que consiste na criação do banco de dados real dentro de um SGBD específico. Nesta etapa serão gerados os scripts SQL para criar as tabelas, índices, relacionamentos e demais objetos necessários ao funcionamento do sistema.

Modelagem Física e Implementação

To do

Tabelas e Relações

user

Representa os usuários do sistema (clientes, intérpretes ou empresas).

Atributos: id (PK), email, password, phone, picture, status, type.

Relacionamentos: 1:1 com person (usuário pessoa física). 1:1 com enterprise (usuário pessoa jurídica). 1:N com location. N:N com specialties (via user_specialties). 1:N com appointment.

person

Armazena dados pessoais de um usuário físico.

Atributos: id (PK), name, gender, birthday, cpf.

Relacionamentos: 1:1 com user. 1:1 com interpreter. 1:N com appointment — uma pessoa pode ter vários atendimentos registrados na agenda do sistema.

location

Guarda informações de endereço relacionadas a um usuário.

Atributos: id (PK), UF, city, user_id.

Relacionamentos: FK para user.

enterprise

Empresa solicitante do serviço de interpretação.

Atributos: id (PK), corporate_reason, cnpj.

Relacionamentos: 1:1 com user (cada empresa é um usuário do sistema). 1:N com appointment (uma empresa pode solicitar vários atendimentos com intérprete).

specialties

Atributos: id (PK), name

Relacionamentos: N:N com user (via user_specialties)

interpreter

Atributos: id (PK), cnpj, rating, min_value, max_value, image_rights, modality, description

Relacionamentos: 1:1 com person (cada intérprete é uma pessoa) 1:N com interpreter_documents (um intérprete pode ter vários documentos) 1:N com schedule (um intérprete pode ter várias disponibilidades) 1:N com appointment (um intérprete pode realizar vários atendimentos)

user_specialties (tabela associativa)

Atributos: id (PK), user_id, specialtie_id

Relacionamentos: N:1 com user N:1 com specialties Implementa um relacionamento N:N entre user e specialties

interpreter_documents

Atributos: id (PK), interpreter_id, document

Relacionamentos: N:1 com interpreter (cada documento pertence a um intérprete)

schedule

Atributos: id (PK), day, start_time, end_time

Relacionamentos: N:1 com interpreter (um intérprete pode ter vários horários disponíveis)

appointment

Atributos: id (PK), UF, city, modality, date, description, status, interpreter_id, user_id, start_time, end_time

Relacionamentos: N:1 com user N:1 com interpreter N:1 com enterprise N:1 com person (quem será atendido)

rating

Atributos: id (PK), stars, description, appointment_id

Relacionamentos: 1:1 com appointment (cada avaliação está vinculada a um atendimento)