Modelo de datos del taller de reparación de automóviles

Dirigir un taller de reparación de automóviles/automóviles es un negocio realmente complejo. Deberá hacer citas mientras algunos clientes llegarán y no querrá que esperen durante horas. Además, deberá organizar a los empleados, realizar un seguimiento de las reparaciones, los materiales, cobrar a los clientes, etc. Definitivamente necesitará una solución de TI y, por supuesto, un modelo de datos en segundo plano. Hoy hablaremos de uno de esos modelos.

La idea

Ya he mencionado que este modelo de negocio es realmente complejo. Por lo tanto, no intentaré cubrirlo todo. Omití intencionalmente el seguimiento de materiales y repuestos y también simplifiqué algunas partes del modelo. La razón de esto es bastante simple. Si he incluido realmente todo, el modelo simplemente sería demasiado grande para un artículo de tamaño razonable. Entonces, comencemos.

Modelo de datos

El modelo consta de 5 áreas temáticas:

• Repair shops & employees
• Customers & contacts
• Vehicles
• Services & offers y
• Visits

Describiremos cada una de estas 5 áreas temáticas en el orden en que se enumeraron.

Sección 1:Talleres de reparación y empleados

La primera área temática, con la que comenzaremos, es Repair shops & employees área temática. Es bastante obvio que necesitamos saber lo que tenemos a disposición antes de poder hacer ofertas a los clientes.

La city El diccionario se utiliza para almacenar todas las ciudades distintas donde tenemos talleres de reparación o de donde provienen nuestros clientes. Cada ciudad está definida de forma única por el par postal_code – city_name . Podríamos decidir tener solo una entrada por cada ciudad, incluso si esa ciudad tiene varios códigos postales. En ese caso, usaríamos solo el código postal “principal” de esa ciudad. Aún así, tenemos la opción de tener múltiples entradas para la misma ciudad y diferentes códigos postales, en caso de que lo deseemos.

El repair_shop table es el lugar donde almacenaremos una lista de todos nuestros talleres de reparación. Podemos esperar que operemos más de uno en algún momento. Cada tienda se define de forma única por su shop_name y el id de la ciudad a la que pertenece (city_id ). También almacenaremos la dirección de la tienda y details adicionales en el formato textual si lo hay.

La position el diccionario se usa para almacenar position_names únicos que podrían asignarse a nuestros empleados. Si bien la mayoría de los puestos estarán relacionados con nuestro negocio principal, también tendremos algunos que no forman parte del negocio principal (puestos/funciones técnicas) pero que también son esenciales (administración, ventas, etc.).

Una lista de todos nuestros empleados se almacena en el employee mesa. Para cada empleado, almacenaremos su:

• first_name &last_name – El nombre y apellido del empleado.
• employment_start_date &employment_end_date – Fecha de inicio y finalización del empleado en la empresa. La fecha de finalización contendrá un valor NULL hasta que podamos definirlo.
• position_id – Una referencia al puesto actual en la empresa.
• city_id – Una referencia a la ciudad donde vive actualmente el empleado.
• is_active – Una bandera que indica si el empleado está actualmente activo o no.

La última tabla en esta área temática es el schedule mesa. En esta tabla, almacenaremos horarios exactos para todos nuestros empleados a nivel diario. También tendremos la opción de almacenar múltiples intervalos para el mismo empleado durante el mismo día. Para lograr esto, utilizaremos los siguientes atributos:

• repair_shop_id – Una referencia al taller de reparación relacionado.
• employee_id – Una referencia al empleado relacionado.
• position_id – Una referencia al puesto relacionado que el empleado tendría durante el período de tiempo definido. En la mayoría de los casos, este sería su puesto actual, pero tenemos la flexibilidad de asignar otro puesto aquí.
• schedule_date – Una fecha con la que está relacionada esta entrada.
• time_from &time_to – Este par define el período de tiempo con el que se relaciona esta entrada.
• plan – Una bandera que indique si se trataba de una entrada planificada. La entrada no se planificará solo si la insertamos ad-hoc.
• actual – Esta bandera indica si se realizó esta entrada. Tenga en cuenta que, en la mayoría de los casos, ambos indicadores, plan y real, se establecerán en True. Esto señalaría que planeamos y en realidad cumplimos ese plan.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

La combinación repair_shop_id - employee_id - schedule_date - time_from forma la clave ÚNICA/alternativa de esta tabla. Antes de insertar un nuevo registro, también debemos verificar ese nuevo intervalo time_from – time_to no se superpone con ningún intervalo existente para ese mismo empleado y fecha.

Sección 2:Clientes y contactos

Ahora estamos listos para pasar a la parte del modelo relacionada con el cliente.

Guardaremos todos los clientes con los que hemos trabajado antes o con los que hemos tenido contacto, en el customer mesa. Para cada cliente, almacenaremos:

• first_name &last_name – El nombre y apellido del cliente, en caso de que nuestro cliente sea un particular.
• company_name – Un nombre de empresa, en caso de que el cliente sea una empresa y no un particular.
• address – La dirección del cliente.
• mobile – El número de teléfono móvil del cliente.
• email – El correo electrónico del cliente
• details – Todos los detalles adicionales del cliente, si los hay, en formato de texto.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

La mayoría de los atributos en esta tabla aceptan valores NULL porque probablemente no tendremos algunos de ellos y algunos (first_name &last_name frente a company_name ) excluir a otros.

Tendremos que hacer un seguimiento de todos los contactos que hicimos con cada cliente. Para hacer eso, usaremos dos tablas. Primero, el contact_type table, es un diccionario simple que contiene solo el ÚNICO type_name valor.

Los datos de contacto reales se almacenan en el contact mesa. Guardaremos referencias al tipo de ese contacto (contact_type_id ), un cliente con el que tuvimos contacto (customer_id ), un empleado que hizo ese contacto (schedule_id ) y también almacenar detalles de contacto y la hora en que se insertó este registro en la tabla (insert_ts ).

Sección 3:Vehículos

Después de conocer nuestros recursos y clientes, necesitamos almacenar los vehículos con los que trabajaremos. Además de rastrear datos y crear informes internos, en la mayoría de los países también necesitaremos crear informes para las agencias reguladoras, las compañías de seguros y la policía.

Primero, definiremos los modelos de nuestros vehículos. Usaremos 3 tablas para lograr eso. En el make diccionario, enumeraremos make_names únicos para todas las marcas/fabricantes de automóviles/vehículos. Además de eso, necesitaremos conocer los tipos de vehículos, por lo que usaremos un diccionario más con un solo atributo de valor único:type_name . El 3 diccionario utilizado es el model diccionario. Este contendrá la lista de todos los modelos que entraron por nuestras puertas. Para cada modelo, definiremos la combinación única model_name – make_id – vechicle_type_id .

Terminaremos de describir este tema con el vehicle mesa. Esta es la única tabla en esta área temática que contiene datos "reales". Usaremos esta tabla para almacenar los siguientes detalles:

• vin – Un número de identificación del vehículo, que define de manera única este vehículo.
• license_plate – Un número de matrícula actual.
• customer_id – Una referencia al cliente al que pertenece este vehículo. En caso de que el vehículo cambie de propietario, lo insertaremos como un nuevo registro, pero sabremos que es el mismo vehículo según el número de serie.
• model_id – Una referencia al diccionario modelo.
• manufactured_year &manufactured_month – Indique el año y el mes en que se fabricó este vehículo.
• details – Todos los detalles adicionales en formato de texto.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

Sección 4:Servicios y ofertas

Estamos listos para dar el próximo gran paso. Necesitamos definir lo que ofrecemos a nuestros (potenciales) clientes. Estas pueden ser tareas individuales o un conjunto de tareas:servicios.

La lista de todos los servicios se almacena en el service_catalog diccionario. Cada servicio consta de algunas tareas y está definido de forma única por su service_name . Además del nombre, también almacenaremos una descripción, si la tenemos, el porcentaje de service_discount y el is_active bandera. El descuento del servicio se utilizará para todas las tareas incluidas en este servicio.

A continuación, definiremos las tareas. Las tareas son parte de nuestros servicios. Son la acción básica que podría hacerse de forma independiente. Cada tarea está definida por estos valores en el task_catalog tabla:

• task_name &service_catalog_id – Un nombre que usaremos para describir esta tarea y el servicio al que pertenece. Este par de atributos forma la clave única de la tabla.
• description – La descripción textual adicional, si la hay, utilizada para describir esta tarea.
• ref_interval – Una bandera que indica si mediremos el intervalo para esta tarea.
• ref_interval_min &ref_interval_max – El límite mínimo y máximo del rango de referencia.
• describe – Una bandera que indica si debemos agregar un comentario textual para esta tarea.
• task_price – Un precio actual, sin descuentos de servicio, para esta tarea.
• is_active – Una bandera que indica si la tarea está actualmente activa (en nuestra oferta) o no.

Después del contacto con los clientes, les haremos ofertas. La oferta puede ser un servicio completo, con todas sus tareas o un conjunto de tareas. Todas las ofertas se almacenan en la offer mesa. Para cada oferta, almacenaremos:

• customer_id – Una identificación del cliente relacionado.
• contact_id – Una identificación del contacto relacionado, si lo hubiera. Esta podría ser información importante para determinar cuántas ofertas surgieron como resultado de contactos anteriores.
• offer_description – Una descripción textual adicional de esta oferta.
• service_catalog_id – Un id del servicio que hemos ofrecido al cliente. Este id podría ser NULL en caso de que no le hayamos ofrecido un servicio completo, sino una o más tareas que no forman parte del servicio.
• service_discount – El descuento del servicio en el momento de creación de la oferta. Este valor deberá contener NULL en caso de que la oferta no esté relacionada con el servicio.
• offer_price – Un precio final de esa oferta. Podría calcularse como la suma de todas las tareas menos el descuento del servicio.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

La última tabla en esta área temática es offer_task mesa. Para cada oferta, sin importar si ofrecimos un servicio completo o no, almacenaremos el conjunto de todas las tareas. Necesitamos almacenar los siguientes detalles:

• offer_id – Una identificación de la oferta relacionada.
• task_catalog_id – Una identificación de la tarea relacionada. Junto con el offer_id , forma la clave única/alternativa de esta tabla
• task_price – Un precio actual de esa tarea en el momento en que se insertó este registro.
• insert_ts - Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

Sección 5:Visitas

La última área temática de nuestro modelo se utiliza para almacenar las visitas reales de los clientes a nuestro taller de reparación. Aunque parece complejo, solo tenemos 2 mesas nuevas aquí, visit y visit_task .

Cuando el cliente acepta nuestra oferta o simplemente entra en nuestra tienda, lo trataremos como una visit . Para cada uno de estos eventos, almacenaremos los siguientes detalles:

• repair_shop_id – Una referencia al taller de reparación relacionado.
• customer_id – Una referencia al cliente con el que está relacionada esta visita.
• vehicle_id – Una referencia al vehículo con el que está relacionada esta visita.
• visit_start_date – Una fecha de inicio de la visita (planificada).
• visit_start_time – Una hora de inicio de la visita (planificada).
• visit_end_date – Una fecha de inicio de la visita (real). Este valor se fijará cuando finalice efectivamente la visita.
• visit_end_time – Una hora de inicio de la visita (real). Este valor se fijará cuando finalice efectivamente la visita.
• license_plate – Un número de matrícula en el momento en que ocurrió la visita. Tenga en cuenta que las matrículas cambian durante el tiempo.
• offer_id – Una identificación de la oferta relacionada, si corresponde.
• service_catalog_id – Una identificación del servicio relacionado, si corresponde.
• service_discount – Una cantidad porcentual de descuento en el momento en que se agregó este registro y en caso de que ofrezcamos un servicio completo.
• visit_price – Un precio total que un cliente debe pagar por esa visita.
• invoice_created – Una marca de tiempo cuando se generó la factura.
• invoice_due – Una marca de tiempo cuando venció la factura.
• invoice_charged – Una marca de tiempo cuando se cargó la factura.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

La última tabla de nuestro modelo es visit_task mesa. Este es el lugar para almacenar todas las tareas que realmente formaron parte de esa visita. Para cada registro aquí, almacenaremos los siguientes valores:

• visit_id – Una referencia a esa visita.
• task_catalog_id – Una referencia a la tarea relacionada
• value_measured – Un valor que se midió durante esta tarea, si la tarea requería medición.
• task_description – Una descripción relacionada con esa tarea si la tarea requería una descripción.
• pass – Una bandera que indica si esta tarea estaba en el intervalo esperado o no.
• task_price – Un precio real de esa tarea en el momento insertado en esta tabla.
• insert_ts – Una marca de tiempo que indica el momento en que se insertó este registro en la tabla.

Si bien este modelo está bastante simplificado, contiene todos los elementos necesarios que necesitará para construir un modelo completo a su alrededor. Las piezas que requieren mejoras son definitivamente el material utilizado y el procesamiento de pagos. ¿Añadirías algo más a este modelo?