Ganhe dinheiro com coisas não utilizadas:um modelo de dados de economia compartilhada

Não há muita chance de você ter perdido toda a ideia da economia compartilhada – goste ou não. Popularizado por empresas como Airbnb, Uber, Lyft e muitas outras, permite que as pessoas ganhem algum dinheiro alugando suas coisas não utilizadas. Vamos ver o modelo de dados por trás de tal aplicativo.

Tem um quarto vago? Inscreva-se no Airbnb e ganhe um dinheiro extra alugando. Tem um carro e algum tempo livre? Torne-se um motorista Uber. E assim vai – a ideia por trás dessas empresas e muitas outras como elas é quase a mesma. Trata-se de compartilhar um recurso com (principalmente) estranhos, com vantagens para ambas as partes. O proprietário recebe dinheiro por sua propriedade não utilizada, enquanto o cliente geralmente recebe um bom negócio; esta deve ser uma situação ganha-ganha.

É claro que precisamos de uma plataforma para conectar proprietários com clientes e acompanhar detalhes importantes. Hoje, apresentaremos um modelo de dados que pode gerenciar a tarefa. Acomode-se em sua cadeira e aproveite o passeio pelo modelo de dados de economia compartilhada.

O que precisamos em nosso modelo de dados?

A ideia de alugar um imóvel quando não estamos usando parece muito sábia. Primeiro, a propriedade é usada para o propósito pretendido; segundo, o aluguel gerará algum tipo de renda adicional. Isso pode ser dinheiro, mas também pode ser uma troca (por exemplo, alguém em Nova York trocando de apartamento com alguém em Paris por uma semana).

Modelos sem dinheiro são muito legais e geralmente dependem de compreensão mútua, boa vontade e honestidade. No entanto, este artigo se concentrará nos modelos de economia compartilhada que exigem pagamento. Não é tão romântico quanto os modelos sem dinheiro, mas o modelo de pagamento é bastante eficaz.

Precisamos de uma maneira muito simples para que um grande número de proprietários alcance um grande número de clientes interessados e vice-versa. Este é o primeiro requisito para o nosso modelo de dados. Teremos contas de usuário e pelo menos dois papéis distintos – proprietário e cliente.

A próxima coisa que precisamos é que nosso aplicativo liste todas as propriedades disponíveis. Para o Airbnb, seriam apartamentos; para Uber, seriam carros. Este artigo se concentrará mais no aluguel de apartamentos (um modelo de dados semelhante ao Airbnb), mas manterei o modelo geral o suficiente para que possa ser facilmente convertido em qualquer outro serviço de economia de compartilhamento desejado.

Para cada proprietário, precisaremos definir o local onde eles operam. Para apartamentos, isso é bastante óbvio (a cidade onde o apartamento está localizado). Para serviços de transporte, isso dependerá da localização atual do carro e/ou de seu proprietário.

Para cada propriedade ou recurso, precisaremos rastrear períodos de uso e solicitações/reservas. Isso nos permitirá encontrar imóveis disponíveis quando um novo pedido for feito e calcular a taxa de ocupação e o preço. Também poderemos usar outros programas para analisar esses dados e produzir outras estatísticas.

O modelo de dados

O modelo de dados consiste em cinco áreas temáticas:

Países e cidades
Usuários e funções
Serviços e documentos
Solicitações
Serviços fornecidos

Apresentaremos cada área de assunto na mesma ordem em que está listada.

Seção 1:Países e cidades

Começaremos com os Países e cidades área de estudo. Embora não sejam específicas para esse modelo de dados, essas tabelas são muito importantes. Os serviços relacionados à propriedade geralmente são orientados geograficamente. Nosso modelo está intimamente relacionado ao aluguel de algum tipo de moradia, então a localização física é crucial aqui. Claro, esse local geralmente não muda. Existem alguns casos muito especiais que podem resultar na mudança de localização de uma propriedade, mas eu trataria essa moradia em sua nova localização como uma propriedade completamente nova.

Para aplicativos de carro e/ou motorista como o Uber, a localização atual do carro e do motorista também é muito importante. Ao contrário dos aluguéis de apartamentos no estilo Airbnb, esses locais de propriedade podem mudar com frequência.

O país tabela contém uma lista de nomes ÚNICOS dos países onde operamos. A cidade tabela contém uma lista de todas as cidades onde operamos. A combinação ÚNICA para esta tabela é a combinação de postal_code , city_name e country_id atributos.

Ambas as tabelas podem conter muitos atributos adicionais, mas eu os omiti intencionalmente porque não agregam valor a este modelo.

Seção 2:usuários e funções

A próxima coisa que precisamos fazer é definir os usuários e seus comportamentos ou funções em nosso aplicativo. Para fazer isso, usaremos as três tabelas em Usuários e funções área de estudo.

Uma lista de todos os usuários está na user_account tabela. Para cada usuário, armazenaremos os seguintes detalhes:

user_name – O nome ÚNICO que o usuário escolheu para acessar nosso aplicativo.
senha – Um valor de hash da senha escolhida pelo usuário.
first_name e last_name – O nome e sobrenome do usuário.
city_id – Uma referência à cidade onde o usuário geralmente está localizado.
current_city_id – Uma referência à cidade onde o usuário está localizado no momento.
e-mail – O endereço de e-mail do usuário.
time_inserted – O carimbo de data/hora em que este registro foi inserido na tabela.
confirmation_code – Um código gerado durante o processo de registro para confirmar o endereço de e-mail do usuário.
time_confirmed – O carimbo de data/hora em que o endereço de e-mail foi confirmado. Este atributo contém um valor NULL até que a confirmação seja concluída.

O usuário terá diferentes direitos no aplicativo de acordo com sua função. Também é possível que um usuário possa ter mais de uma função ativa ao mesmo tempo, por exemplo, eles podem ser o proprietário de uma propriedade e o cliente de outra propriedade. Nesse caso, o usuário usará os mesmos detalhes de login e terá a opção de alternar entre as funções. Cada função terá sua própria tela no aplicativo.

Uma lista de todas as funções possíveis é armazenada na função dicionário. Cada função é definida EXCLUSIVAMENTE por seu role_name . Para simplificar, podemos esperar apenas dois papéis:“proprietário” e “cliente”.

Um usuário pode ter a mesma função atribuída várias vezes durante diferentes períodos. Um desses casos seria se o usuário estivesse alugando seu apartamento não utilizado e decidisse não alugar seu apartamento porque precisava dele. No entanto, após alguns meses, o mesmo usuário decidiu alugar seu apartamento novamente. Nesse caso, desativamos a função deles e ativá-la novamente.

Uma lista de todas as funções que já foram atribuídas aos usuários é armazenada em has_role tabela. Para cada registro nesta tabela, armazenaremos:

user_account_id – O ID do usuário relacionado .
role_id – O ID da função relacionada .
time_from – O carimbo de data/hora em que essa função foi inserida no sistema.
time_to – O carimbo de data/hora em que essa função foi desativada. Isso conterá um valor NULL enquanto a função ainda estiver ativa.
is_active – É definido como False quando a função é desativada por qualquer motivo.

Ao inserir um novo registro nesta tabela, devemos verificar se há registros sobrepostos. Isso nos permite evitar que a mesma função seja válida duas vezes durante o mesmo período.

Seção 3:Serviços e Documentos

A próxima coisa que precisamos definir são os serviços fornecidos pelos usuários. Também precisaremos acompanhar todos os documentos relacionados. Para fazer isso, precisaremos das tabelas em Serviços e documentos área de estudo.

Vamos começar com a propriedade tabela. Propriedades são quaisquer que sejam os objetos do nosso serviço:residências, carros, bicicletas, etc. Podemos esperar que os usuários cuidem de suas próprias propriedades. Para cada propriedade, precisaremos definir:

nome_propriedade – O nome de tela dessa propriedade, escolhido pelo usuário. Esse nome é usado ao exibir a propriedade para clientes em potencial no aplicativo. Ele deve ser breve e descritivo e diferenciar essa propriedade de outras propriedades.
property_description – Descrição textual adicional em formato não estruturado. Podemos esperar muitos detalhes aqui – basicamente tudo, desde o tamanho do apartamento até se os clientes receberão uma bebida de boas-vindas quando chegarem. Bebidas de boas-vindas em serviços de transporte são muito menos prováveis de acontecer.
active_from e active_to – O período de tempo em que essa propriedade estava ativa em nosso sistema. O active_to O atributo conterá valor NULL até que a propriedade seja desativada.
está_disponível – Um sinalizador indicando se esta propriedade está disponível em um horário específico ou não.
is_active – Um sinalizador indicando se essa propriedade ainda está ativa em nosso sistema. O valor deste atributo será definido como False no mesmo momento active_to está definido.

Agora passaremos para o serviço dicionário. É aqui que definiremos todos os tipos de serviços possíveis, como “aluguel de longo prazo”, “aluguel de curto prazo”, “transporte” etc. Ele contém o nome ÚNICO do tipo de serviço e uma

descrição , se necessário. 
 
 Manteremos propriedades, serviços e usuários relacionados nos fornece  tabela. Ele armazenará períodos em que uma propriedade estava disponível. No caso do transporte, isso nos diria quando um carro e um motorista estavam realmente trabalhando para nossa empresa. No caso de aluguel de apartamentos, ele nos informava quando um imóvel estava disponível. Para cada registro aqui, teremos:
  user_account_id – O ID do usuário que fornece esse serviço.
 service_id – O ID do serviço  tipo fornecido.
 id_propriedade – Faz referência à propriedade  usado.
 time_from e time_to – Quando esta propriedade foi utilizada para prestar este serviço. O time_to O atributo conterá um valor NULL até que este registro seja desativado.
 is_active – É definido como False quando esta propriedade não for mais utilizada ou quando este usuário deixar de fornecer este serviço. Isso é definido no mesmo momento em que time_to está definido.
 
 
 As restantes duas tabelas desta área temática estão relacionadas com documentos. (A tabela user_account é apenas uma cópia do original, usada aqui para evitar sobreposição de relações.) Nossa empresa trabalhará com muitos proprietários e quase não haverá chance de verificar tudo pessoalmente. Uma forma de garantir a qualidade do serviço é ter tudo bem documentado. 
 
 A primeira tabela relacionada a documentos é o document_type  tabela. Este dicionário simples contém uma lista de type_name ÚNICO valores. Podemos esperar valores como “imagem da propriedade” e “ID do proprietário” aqui. 
 
 Uma lista de todos os documentos é armazenada no document  tabela. Esses documentos podem estar relacionados a contas de usuário, propriedades ou ambos. Para cada documento, armazenaremos:
  document_location – O caminho completo para esse documento.
 document_type_id – Uma referência ao document_type  dicionário.
 user_account_id – Uma referência à user_account  tabela. Este atributo só terá um valor quando o documento estiver relacionado ao usuário ou se o documento estiver relacionado à propriedade, mas o usuário também possuir essa propriedade.
 id_propriedade – Uma referência à propriedade relacionada .
 is_active – Indica se este documento ainda está ativo (válido) ou não.
 
 Seção 4:Solicitações
   
 
 Antes de podermos fornecer qualquer serviço, precisamos obter algumas solicitações de usuários. Nos arrendamentos de apartamentos, o cliente fará o seu pedido do imóvel pretendido depois de pesquisar os imóveis e encontrar a habitação que pretende. No caso de serviços de transporte, as solicitações são feitas pelos clientes via aplicativo móvel (por exemplo, estão no aeroporto e precisam de uma carona em 20 minutos). Falaremos sobre como processamos solicitações na próxima seção; por enquanto, vamos ver como os gerenciamos. 
 
 A tabela central nesta área de assunto é a solicitação  tabela. Para cada solicitação, armazenaremos:
 
 has_role_id – Uma referência ao usuário (e sua função atual, por meio do has_role  table) que fez essa solicitação.
 request_status_id – Uma referência ao status atual dessa solicitação.
 status_time – O carimbo de data/hora em que esse status foi atribuído.
 service_id – O ID do serviço  exigido com essa solicitação.
 city_id – Uma referência à cidade  onde este serviço é necessário.
 request_details – Todos os detalhes adicionais da solicitação, em formato textual não estruturado.
 é_processado – Um sinalizador indicando se esta solicitação foi processada (ou seja, atribuída ao provedor de serviços).
 is_active – Este sinalizador será definido como False somente se um cliente cancelou sua solicitação ou se a solicitação foi cancelada pelo aplicativo por algum motivo.
 
 
 Uma lista de todos os status possíveis é armazenada no request_status  dicionário com status_name como o valor ÚNICO (e único). Podemos esperar valores como “solicitação feita”, “propriedade reservada”, “atribuída ao motorista”, “viagem em andamento” e “concluída”. 
 
 O request_status_history  A tabela armazenará o histórico de todos os status relacionados às solicitações. Para cada registro nesta tabela, armazenaremos o ID da solicitação relacionada (request_id ), o ID do status (request_status_id ), o ID da conta do usuário e a função que o usuário tinha ao definir esse status (has_role_id ). Também registraremos quando cada status foi atribuído (status_time ). 
 Seção 5:Serviços fornecidos
   
 
 Após a solicitação ser feita, precisamos processá-la. Uma solicitação será atribuída automaticamente ao provedor de serviços apropriado (com base no tipo de serviço solicitado, localização etc.) ou será aceita manualmente pelo provedor de serviços. Precisamos apenas de mais duas tabelas para lidar com isso. 
 
 O primeiro é o serviço_fornecido  tabela. Para cada registro, incluiremos:
 
 request_id – O ID da solicitação relacionada  .
 provides_id – Uma referência ao fornece  tabela que denota o provedor de serviços e a propriedade incluída nesta ação.
 detalhes – Todos os detalhes adicionais, em formato textual estruturado. Essa estrutura pode incluir tags e valores que descrevem os detalhes da solicitação. Para um passeio, isso significaria o ponto inicial e final, a distância percorrida etc.
 start_time e end_time – O período durante o qual este serviço foi prestado. Ambos os valores serão definidos quando o serviço tiver acabado de iniciar e terminar.
 grade_customer e grade_provider – Notas dadas pelo cliente e pelo provedor de serviços para esse serviço.
 
 
 A última tabela em nosso modelo é a fatura  tabela. Cobraremos os clientes (customer_name ) para os serviços fornecidos (provided_service_id ). Para cada fatura, precisamos saber o total_amount , quaisquer taxas pagas (fee_amount ), quando a fatura foi emitida (time_issued ) e quando foi pago (time_paid ) O campo pago serve como um sinalizador que indica se uma fatura foi paga. 
 O que você acha do nosso modelo de dados de economia compartilhada?
 
 Hoje discutimos um modelo de dados que poderia ser usado por uma empresa como Airbnb ou Uber. A espinha dorsal desse modelo de negócios são os clientes e os prestadores de serviços. Há uma série de detalhes que eu poderia adicionar a este modelo. Ainda assim, decidi não fazer isso porque o modelo ficaria muito grande rapidamente. Você acha que eu deveria ter acrescentado algo? Se sim, por favor me diga nos comentários abaixo.