Criando um modelo de dados para carona

Design de dados, conheça a carona

Requisitos do projeto:

• O site deve permitir que os usuários (também conhecido como membros de compartilhamento de viagens) para se registrarem usando seu nome, número de telefone, endereço de e-mail, número da carteira de motorista etc.
• Os membros devem ter permissão para definir suas preferências em relação a viagens e acompanhantes.
• Os membros chamados proprietários de corridas podem criar uma corrida inserindo os detalhes da viagem (ou seja, pontos de início e destino, horário de início, custos por passageiro etc.)
• Outros membros podem pesquisar viagens disponíveis para um destino cidade .
• Os membros que procuram uma carona podem entrar em contato com o proprietário da viagem e fazer uma reserva para seus assentos.
• O proprietário da viagem deve poder aprovar ou rejeitar solicitações de reserva.
• Com base na ação tomada pelo proprietário da corrida na solicitação de reserva, a contagem de assentos disponíveis deve ser atualizada.
• O proprietário do passeio também pode marcar cidades no trajeto, que são cidades no caminho do ponto de partida até o destino. Se desejarem, os proprietários de passeios também devem poder acomodar pessoas para cidades no trajeto.

Identificando Entidades e Relacionamentos

• membros (incluindo proprietários de passageiros e co-viajantes )
• carro
• preferências
• passeio
• cidade
• solicitação de viagem

Carro – O proprietário do passeio precisa adicionar detalhes de pelo menos um carro antes de criar um passeio. Então, vamos criar outra tabela, chamada car , para armazenar essas informações. Um membro pode possuir mais de um carro. Uma carona pode depender de um par membro-carro, então precisamos de outra tabela para estabelecer essa relação. Chamaremos essa tabela de member_car . Vou referir a chave primária desta tabela no meu ride tabela onde armazenarei os detalhes do passeio. Também adicionarei uma coluna, chamada comfort_level , que armazena o nível de conforto de um carro em uma escala de 0 a 5. Esse nível é calculado automaticamente pelo sistema, com base nos outros detalhes fornecidos pelo membro sobre o carro.

Preferências – As preferências são importantes para todos. O site permite que os membros preencham suas preferências sobre o carro e seus companheiros de viagem. Esses detalhes permanecem opcionais no momento do registro, mas devem ser preenchidos antes de criar uma corrida . O proprietário do passeio provavelmente procurará pessoas com preferências semelhantes para que todos viajem confortavelmente. As pessoas que estão procurando caronas fazem o mesmo.

Algumas preferências básicas para viagens de carro são:

• É permitido fumar dentro do carro?
• Os animais de estimação são permitidos?
• Quão falante é o dono do passeio? Que nível de conversa é aceitável durante o passeio? (As respostas possíveis aqui incluem nenhum, bate-papo leve, gabfest.)
• Que tipo de música o proprietário do passeio gosta?
• Qual ​​volume de música o proprietário do passeio permite?

Cidade – Uma tabela mestra, city , é necessário para armazenar uma lista de todas as cidades atendidas pelo site. Deve incluir as informações relevantes do estado e do país para cada cidade.

Passeio – Um membro pode criar uma carona preenchendo em qual carro ele está viajando; de qual cidade ele está partindo; para qual cidade ele está indo; a data e hora da viagem; o número de lugares disponíveis; e contribuição per capita. A contribuição per capita é o valor que cada co-viajante tem que pagar para as despesas da viagem. O proprietário do passeio também pode mencionar quanta bagagem espera dos co-viajantes para que tudo caiba no carro. Então adicionamos uma coluna, luggage_size_allowed , para este item. Os valores possíveis para esta coluna seriam leve, médio e pesado.

Solicitação de viagem – Os membros podem consultar a lista de passeios disponíveis de uma cidade para outra ou solicitar uma viagem específica. Definitivamente, precisamos de uma tabela para armazenar detalhes sobre tais solicitações. Uma tabela chamada request atende ao propósito. A solicitação é inicialmente inserida como uma solicitação "enviada", e o proprietário da corrida é a única pessoa que pode aprová-la ou rejeitá-la. O número de assentos disponíveis na tabela de passeios será ajustado para cada aprovação e/ou rejeição.

Cidades no caminho – O compartilhamento de carona não é apenas ir direto do ponto de partida ao destino. Pode-se compartilhar uma carona com outras pessoas para cidades em rota também. Por exemplo, se um homem está viajando de Chicago para Miami, ele pode acomodar alguém que queira ir de Chicago para Nashville. Nashville é uma das cidades que ele passará em sua rota, então é uma cidade em rota. Nosso sistema deve permitir que os proprietários de viagens definam cidades no trajeto com base na rota que seguirão para chegar ao destino. Se os co-viajantes quiserem, podem descer em qualquer uma das cidades em rota; seus custos de viagem serão rateados de acordo.

Criaremos outra tabela chamada enroute_city para este fim. Os registros serão adicionados quando o proprietário do passeio adicionar cidades no trajeto ao passeio. Os membros podem então solicitar reservas para viajar para uma das cidades em rota. Portanto, indico a chave primária desta tabela na request tabela.

O order_from_source coluna em enroute_city tabela significa o curso que o proprietário do passeio seguirá para a viagem.

Relatórios no site:

1. 
   Viagens disponíveis de uma cidade específica para outra – Este é um dos relatórios que serão extraídos com bastante frequência, pois retrata a essência deste site. A maioria dos membros acessará este site para buscar alternativas de viagem ou compartilhamento de carona. Ao extrair este relatório, os membros precisam inserir os nomes das cidades de início e destino. O SQL segue:
   
   

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, seats_offered 
   from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = u.id 
   and mc.car_id = c.id and m.id = mp.member_id
   and source_city_id = (select city_id from city where city_name = ‘CHICAGO’)
   and destination_city_id = (select city_id from city where city_name = ‘MIAMI’)
   and seats_offered > (select count(id) from request req, request_status reqs where req.request_status_id = reqs.id and upper(reqs.description) = ‘APPROVE’ and req.ride_id = r.id);
   

   
   
2. 
   Lista de solicitações de viagem enviadas/aprovadas – Este relatório será exibido para o proprietário do passeio. Ele mostrará quem enviou a solicitação de carona, e o proprietário poderá tomar medidas somente nas solicitações deste relatório. Segue o SQL para isso:
   
   

   select first_name || ‘ ‘ || last_name as “Submitter”,  req.created_on as “Submitted on”, rs.description as “Request Status” 
   from member m, request req, request_status rs
   where m.id = req.requester_id and rs.id = req.request_status_id
   and req.ride_id = ;
   

   
   
3. 
   Viagens anteriores e atuais oferecidas – Esses relatórios serão exibidos para os proprietários de corridas em seus próprios painéis. O SQL a seguir pode ser usado para gerar uma lista de corridas que o proprietário da corrida oferece atualmente:
   
   

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = m.id 
   and mc.car_id = c.id and u.id = mp.member_id
   and r.travel_start_time >= sysdate
   and m.id = ;
   

   
   
   E esse SQL pode ser usado para extrair uma lista de passeios oferecidos anteriormente:
   
   

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = m.id 
   and mc.car_id = c.id and u.id = mp.member_id
   and r.travel_start_time < sysdate
   and m.id = ;
   

   
   
4. 
   Lista de co-viajantes para um passeio – Este relatório estará disponível para todos os co-viajantes, incluindo o proprietário da viagem. Todos eles podem gerar uma lista de todos os co-viajantes para qualquer uma de suas viagens passadas ou futuras.
   
   

   select first_name || ‘ ‘ || last_name 
   from member m, request req, request_status rs
   where m.id = req.requester_id and rs.id = req.request_status_id
   and rs.description = ‘APPROVED’
   and req.ride_id = 
   UNION
   select first_name || ‘ ‘ || last_name 
   from member m, member_car mc, ride r
   where m.id = mc.member_id and mc.id = r.member_car_id 
   and r.id = ;
   

   
   

O modelo de dados final

E as melhorias?