No hay muchas posibilidades de que te hayas perdido toda la idea de la economía colaborativa, te guste o no. Popularizado por compañías como Airbnb, Uber, Lyft y muchas otras, permite a las personas ganar algo de dinero alquilando sus cosas sin usar. Veamos el modelo de datos detrás de dicha aplicación.
¿Tienes una habitación libre? Regístrese en Airbnb y gane algo de dinero extra alquilándolo. ¿Tienes un coche y algo de tiempo libre? Conviértete en un conductor de Uber. Y así sigue:la idea detrás de estas empresas y muchas más como ellas es casi la misma. Se trata de compartir un recurso con (en su mayoría) extraños, con un beneficio para ambas partes. El propietario obtiene dinero por su propiedad sin usar, mientras que el cliente suele obtener un buen trato; esto debería ser una situación de ganar-ganar.
Por supuesto, necesitamos una plataforma para conectar a los propietarios con los clientes y realizar un seguimiento de los detalles importantes. Hoy, presentaremos un modelo de datos que podría administrar la tarea. Recuéstese en su silla y disfrute del viaje a través del modelo de datos de economía colaborativa.
¿Qué necesitamos en nuestro modelo de datos?
La idea de alquilar una propiedad cuando no la estamos usando parece muy sabia. Primero, la propiedad se usa para su propósito previsto; segundo, el alquiler generará algún tipo de ingreso adicional. Eso podría ser efectivo, pero también podría ser un intercambio (por ejemplo, alguien en Nueva York intercambia apartamentos con alguien en París por una semana).
Los modelos sin efectivo son realmente geniales y generalmente dependen del entendimiento mutuo, la buena voluntad y la honestidad. Sin embargo, este artículo se centrará en los modelos de economía colaborativa que requieren pago. No es tan romántico como los modelos sin efectivo, pero el modelo de pago es bastante efectivo.
Necesitamos una forma muy sencilla para que un gran número de propietarios llegue a un gran número de clientes interesados y viceversa. Este es el primer requisito para nuestro modelo de datos. Tendremos cuentas de usuario y al menos dos roles distintos:propietario y cliente.
Lo siguiente que necesitamos es que nuestra aplicación enumere todas las propiedades disponibles. Para Airbnb, serían apartamentos; para Uber, serían los automóviles. Este artículo se centrará más en el alquiler de apartamentos (un modelo de datos similar a Airbnb), pero mantendré el modelo lo suficientemente general para que pueda convertirse fácilmente en cualquier otro servicio de economía colaborativa deseado.
Para cada dueño de propiedad, necesitaremos definir la ubicación donde operan. Para los apartamentos, esto es bastante obvio (la ciudad donde se encuentra el apartamento). Para los servicios de transporte, esto dependerá de la ubicación actual del automóvil y/o de su propietario.
Para cada propiedad o recurso, necesitaremos realizar un seguimiento de los períodos de uso y las solicitudes/reservas. Esto nos permitirá encontrar propiedades disponibles cuando se realice una nueva solicitud y calcular la tasa de ocupación y el precio. También podremos usar otros programas para analizar estos datos y generar otras estadísticas.
El modelo de datos
El modelo de datos consta de cinco áreas temáticas:
Países y ciudadesUsuarios y funcionesServicios y documentosSolicitudesServicios proporcionados
Presentaremos cada área temática en el mismo orden en que aparece.
Sección 1:Países y ciudades
Comenzaremos con los Países y ciudades área temática. Aunque no son específicas de este modelo de datos, estas tablas son muy importantes. Los servicios relacionados con la propiedad suelen estar orientados geográficamente. Nuestro modelo está muy relacionado con el alquiler de algún tipo de vivienda, por lo que aquí la ubicación física es crucial. Por supuesto, esa ubicación no suele cambiar. Hay algunos casos muy especiales que podrían resultar en el cambio de ubicación de una propiedad, pero trataría esa vivienda en su nueva ubicación como una propiedad completamente nueva.
Para aplicaciones de automóviles y/o conductores como Uber, la ubicación actual del automóvil y del conductor también es muy importante. A diferencia de los alquileres de apartamentos al estilo de Airbnb, la ubicación de estas propiedades podría cambiar con frecuencia.
El país La tabla contiene una lista de nombres ÚNICOS de los países donde operamos. La ciudad La tabla contiene una lista de todas las ciudades donde operamos. La combinación ÚNICA para esta tabla es la combinación de postal_code , nombre_ciudad y id_país atributos
Ambas tablas podrían contener muchos atributos adicionales, pero los omití intencionalmente porque no agregarán ningún valor a este modelo.
Sección 2:Usuarios y roles
Lo siguiente que debemos hacer es definir los usuarios y sus comportamientos o roles en nuestra aplicación. Para hacer esto, usaremos las tres tablas en Usuarios y roles área temática.
Hay una lista de todos los usuarios en user_account mesa. Para cada usuario, almacenaremos los siguientes detalles:
nombre_usuario– El nombre ÚNICO que el usuario ha elegido para acceder a nuestra aplicación.contraseña– Un valor hash de la contraseña elegida por el usuario.nombreyapellido– El nombre y apellido del usuario.id_ciudad– Una referencia a laciudaddonde se encuentra habitualmente el usuario.id_ciudad_actual– Una referencia a laciudaddonde se encuentra actualmente el usuario.correo electrónico– La dirección de correo electrónico del usuario.tiempo_insertado– La marca de tiempo cuando se insertó este registro en la tabla.código_de_confirmación– Un código generado durante el proceso de registro para confirmar la dirección de correo electrónico del usuario.tiempo_confirmado– La marca de tiempo cuando se confirmó la dirección de correo electrónico. Este atributo contiene un valor NULL hasta que se realiza la confirmación.
El usuario tendrá diferentes derechos en la aplicación según su rol. También es posible que un usuario pueda tener más de un rol activo al mismo tiempo, p. podrían ser el dueño de una propiedad y el cliente de otra propiedad. En ese caso, el usuario utilizará los mismos datos de inicio de sesión y tendrá la opción de cambiar de función. Cada rol tendrá su propia pantalla en la aplicación.
Una lista de todos los roles posibles se almacena en el rol diccionario. Cada rol está definido ÚNICAMENTE por su role_name . En aras de la simplicidad, podemos esperar solo dos roles:"propietario de la propiedad" y "cliente".
Un usuario podría tener el mismo rol asignado varias veces durante diferentes períodos. Uno de esos casos sería si el usuario estuviera alquilando su apartamento sin usar y luego decidiera no alquilar su apartamento porque lo necesitaba. Sin embargo, después de unos meses, el mismo usuario decidió volver a alquilar su apartamento. En este caso, desactivaríamos su rol y luego lo volveríamos a activar.
Una lista de todos los roles que alguna vez se asignaron a los usuarios se almacena en has_role mesa. Para cada registro en esta tabla almacenaremos:
id_de_cuenta_de_usuario– El ID delusuario relacionado.role_id– El ID delrol relacionado.tiempo_desde– La marca de tiempo cuando se insertó este rol en el sistema.tiempo_hasta– La marca de tiempo cuando se desactivó este rol. Esto contendrá un valor NULL mientras el rol aún esté activo.es_activo– Se establece en Falso cuando el rol está desactivado por cualquier motivo.
Al insertar un nuevo registro en esta tabla, debemos verificar si hay registros superpuestos. Esto nos permite evitar que el mismo rol sea válido dos veces durante el mismo período.
Sección 3:Servicios y Documentos
Lo siguiente que debemos definir son los servicios prestados por los usuarios. También tendremos que realizar un seguimiento de los documentos relacionados. Para hacer eso, necesitaremos las tablas en Servicios y documentos área temática.
Comencemos con la propiedad mesa. Las propiedades son cualesquiera que sean los objetos de nuestro servicio:viviendas, automóviles, bicicletas, etc. Podemos esperar que los usuarios se ocupen de sus propias propiedades. Para cada propiedad, necesitaremos definir:
nombre_de_la_propiedad– El nombre de pantalla para esa propiedad, elegido por el usuario. Este nombre se usa cuando se muestra la propiedad a clientes potenciales en la aplicación. Debe ser breve y descriptivo y diferenciar esa propiedad de otras propiedades.descripción_de_la_propiedad– Descripción textual adicional en formato no estructurado. Podemos esperar un montón de detalles aquí, básicamente todo, desde el tamaño del apartamento hasta si los clientes recibirán una bebida de bienvenida cuando lleguen. Las bebidas de bienvenida en los servicios de transporte son mucho menos probables.activo_desdeyactive_to– El período de tiempo en que esa propiedad estuvo activa en nuestro sistema. Elactive_toEl atributo contendrá un valor NULL hasta que se desactive la propiedad.está_disponible– Una bandera que indica si esta propiedad está disponible en un momento específico o no.es_activo– Una bandera que indica si esa propiedad todavía está activa en nuestro sistema. El valor de este atributo se establecerá en False en el mismo momentoactive_toestá configurado.
Ahora pasaremos al servicio diccionario. Aquí es donde definiremos todos los tipos de servicios posibles, como "alquiler a largo plazo", "alquiler a corto plazo", "transporte", etc. Contiene el nombre ÚNICO del tipo de servicio y una descripción , si es necesario.
Mantendremos las propiedades, los servicios y los usuarios relacionados en proporciona mesa. Almacenará períodos en los que una propiedad estuvo disponible. En el caso del transporte, esto nos indicaría cuándo un automóvil y un conductor estaban realmente trabajando para nuestra empresa. En el caso de alquileres de apartamentos, nos indicaría cuándo una propiedad estaba disponible. Para cada registro aquí, tendremos:
id_de_cuenta_de_usuario– El DNI del usuario que presta ese servicio.id_servicio– El ID delserviciotipo proporcionado.id_propiedad– Hace referencia a lapropiedadusado.tiempo_desdeytime_to– Cuando se utilizó este inmueble para prestar este servicio. Eltiempo_paraEl atributo contendrá un valor NULL hasta que se desactive este registro.es_activo– Se establece en False una vez que esta propiedad ya no se utilizará o cuando este usuario dejará de proporcionar este servicio. Esto se establece en el mismo momento en quetime_toestá configurado.
Las dos tablas restantes en esta área temática están relacionadas con documentos. (La tabla user_account es solo una copia del original, que se usa aquí para evitar la superposición de relaciones). Nuestra empresa trabajará con muchos propietarios y casi no habrá posibilidad de verificar todo en persona. Una forma de garantizar la calidad del servicio es tener todo bien documentado.
La primera tabla relacionada con documentos es document_type mesa. Este diccionario simple contiene una lista de type_name ÚNICOS valores. Podemos esperar valores como "imagen de la propiedad" e "identificación del propietario" aquí.
Una lista de todos los documentos se almacena en el documento mesa. Estos documentos pueden estar relacionados con cuentas de usuario, propiedades o ambos. Para cada documento, almacenaremos:
ubicación_documento– La ruta completa a ese documento.document_type_id– Una referencia aldocument_typediccionario.id_de_cuenta_de_usuario– Una referencia a lauser_accountmesa. Este atributo solo tendrá un valor cuando el documento esté relacionado con el usuario o si el documento está relacionado con la propiedad pero el usuario también es dueño de esa propiedad.id_propiedad– Una referencia a la propiedad relacionada .es_activo– Indica si este documento aún está activo (válido) o no.
Sección 4:Solicitudes
Antes de que podamos proporcionar cualquier servicio, necesitamos recibir algunas solicitudes de los usuarios. En el alquiler de apartamentos, el cliente realizará su solicitud de la propiedad deseada después de haber buscado en los listados y encontrado la vivienda que desea. En el caso de los servicios de transporte, los clientes realizan las solicitudes a través de la aplicación móvil (por ejemplo, están en el aeropuerto y necesitan un viaje en 20 minutos). Hablaremos sobre cómo procesamos las solicitudes en la siguiente sección; por ahora, veamos cómo los gestionamos.
La tabla central en esta área temática es la solicitud mesa. Para cada solicitud, almacenaremos:
tiene_role_id– Una referencia al usuario (y su rol actual, a través dehas_roletable) que hizo esa solicitud.request_status_id– Una referencia al estado actual de esa solicitud.tiempo_estado– La marca de tiempo cuando se asignó ese estado.id_servicio– El ID delserviciorequerido con esa solicitud.id_ciudad– Una referencia a laciudaddonde se requiere este servicio.solicitud_detalles– Todos los detalles adicionales de la solicitud, en formato de texto no estructurado.es_procesado– Una bandera que indica si esta solicitud ha sido procesada (es decir, asignada al proveedor de servicios).es_activo– Este indicador se establecerá en False solo si un cliente canceló su solicitud o si la aplicación canceló la solicitud por algún motivo.
Una lista de todos los estados posibles se almacena en el request_status diccionario con status_name como valor ÚNICO (y único). Podemos esperar valores como "solicitud realizada", "propiedad reservada", "asignado al conductor", "conducción en curso" y "completado".
El request_status_history La tabla almacenará el historial de todos los estados relacionados con las solicitudes. Para cada registro de esta tabla, almacenaremos el ID de la solicitud relacionada (request_id ), el ID de estado (request_status_id ), el ID de la cuenta de usuario y el rol que tenía el usuario cuando estableció ese estado (has_role_id ). También registraremos cuándo se asignó cada estado (status_time ).
Sección 5:Servicios prestados
Después de realizar la solicitud, debemos procesarla. Una solicitud se asignará automáticamente al proveedor de servicios adecuado (según el tipo de servicio solicitado, la ubicación, etc.) o el proveedor de servicios la aceptará manualmente. Solo necesitamos dos mesas más para manejar esto.
Primero está el provided_service mesa. Para cada registro, incluiremos:
solicitud_id– El ID de lasolicitud relacionada.proporciona_id– Una referencia a losproporcionatabla que denota el proveedor de servicios y la propiedad incluida en esta acción.detalles– Todos los detalles adicionales, en formato de texto estructurado. Esta estructura puede incluir etiquetas y valores que describen los detalles de la solicitud. Para un viaje, esto significaría el punto inicial y final, la distancia recorrida, etc.hora_de_inicioyend_time– El período durante el cual se prestó este servicio. Ambos valores se establecerán cuando el servicio acaba de comenzar y finalizar.calificación_clienteygrade_provider– Calificaciones otorgadas por el cliente y el proveedor de servicios para ese servicio.
La última tabla de nuestro modelo es la factura mesa. Cobraremos a los clientes (customer_name ) para los servicios proporcionados (provided_service_id ). Para cada factura, necesitamos saber el total_amount , cualquier tarifa pagada (fee_amount ), cuando se emitió la factura (hora_emitida ) y cuándo se pagó (time_paid ) El campo pagado sirve como bandera que indica si se ha pagado una factura.
¿Qué opinas sobre nuestro modelo de datos de economía colaborativa?
Hoy discutimos un modelo de datos que podría ser utilizado por una empresa como Airbnb o Uber. La columna vertebral de este modelo de negocio son los clientes y los proveedores de servicios. Hay una serie de detalles que podría agregar a este modelo. Aún así, decidí no hacer eso porque el modelo se volvería demasiado grande rápidamente. ¿Crees que debería haber añadido algo? Si es así, dígame en los comentarios a continuación.
