Documentación: BASE DE DATOS - Proyecto-Integrador-I-ISPC/AquaMovil GitHub Wiki

TECNICATURA SUPERIOR EN DESARROLLO WEB Y APLICACIONES DIGITALES

Proyecto AquaMóvil

Módulo: Iniciación a la Programación y Base de Datos

Proyecto: Sistema de gestión de servicios de lavado de autos a domicilio

Integrantes:

González, Emilse

Luppi, Astrid

Picone, Abigail

Pirles, Irina

Pucheta, Mauricio

Villanueva Cassini, Vanessa Marcela

Objetivo:

El presente documento tiene como finalidad detallar el diseño lógico de la base de datos para un sistema de gestión de lavado de autos a domicilio. El sistema permite registrar usuarios (clientes, empleados y administrador), sus vehículos, realizar pedidos de lavado, asignar empleados, gestionar pagos y servicios. El modelo fue representado inicialmente mediante un diagrama entidad-relación (ER) y posteriormente traducido a un modelo relacional implementable en SQL.

Modelo DER

Descripción del Diagrama Entidad-Relación (DER)

El DER representa el modelo conceptual del sistema AquaMóvil. Este modelo fue diseñado para reflejar las entidades reales del negocio (clientes, empleados, vehículos, pedidos, pagos, servicios, administrador) y las relaciones entre ellas. Se aplicaron las reglas de cardinalidad (1:1, 1: N, N:1) para representar cuántas instancias de una entidad pueden estar relacionadas con otras.

Relación CLIENTES – VEHÍCULOS

Un cliente puede tener uno o varios vehículos (1: N), pero un vehículo no puede pertenecer a varios clientes. Esto se refleja en la relación 'Tienen', con una clave foránea dni_cliente en la entidad VEHÍCULOS.

Relación CLIENTES – PEDIDOS

Cada cliente puede realizar un pedido y cada pedido corresponde a un único cliente por vehículo. Esta relación 1:1 está modelada con la FK dni_cliente en la entidad PEDIDOS. Es decir que cada cliente realizará un pedido por vehículo al margen si necesita lavar varios vehículos al mismo tiempo.

Relación EMPLEADOS – PEDIDOS

Los empleados son quienes toman los pedidos. Un empleado puede tomar muchos pedidos por día, pero cada pedido es tomado por un solo empleado. Relación 1: N representada con la FK dni_empleado en PEDIDOS. Aquí se hizo la suposición acerca de que, si era un vehículo grande, por ejemplo, un camión se iban a necesitar dos o más empleados para este pedido. Se decidió considerar este supuesto por fuera del sistema (entre empleados) o en otra etapa de desarrollo del proyecto.

Relación SERVICIOS – PEDIDOS

Cada pedido corresponde a un servicio. La relación es 1:1. Aquí se hizo la suposición que en otra etapa del desarrollo del proyecto se podrán agregar los tipos de servicios como, por ejemplo: básico (solo exterior), completo (interior, exterior) y Premium (interior, exterior y pulido y encerado)

Relación PAGOS – PEDIDOS

Cada pedido tiene un único pago asociado (1:1). Esto garantiza integridad entre el servicio brindado y el pago realizado, representado con la FK id_pedido en la entidad PAGOS. Aquí se propuso que para otra instancia del desarrollo del proyecto se podrán agregar diferentes formas de pago: efectivo, transferencia, tarjeta de débito, crédito, código QR.**

Relación ADMINISTRADOR – SERVICIOS

Cada servicio es gestionado por un administrador. Relación 1: N donde un administrador puede haber creado o gestionado múltiples servicios.

Relación ADMINISTRADOR – EMPLEADOS

Representa que los empleados están bajo supervisión de un administrador. La relación es de N:1 es decir, muchos empleados son gestionados por un administrador.

Entidad DIRECCIONES –EMPLEADOS

Se creó una entidad separada para la dirección del empleado para cumplir con la Tercera Forma Normal (3FN) y evitar redundancia. Cada empleado tiene una única dirección, representada con la FK id_direccion en EMPLEADOS. En un principio, no estaban discriminados los atributos de calle, número, barrio, localidad, etc., sino que las “direcciones” aparecían repetidas en varias entidades diferentes.

Modelo Relacional

El modelo relacional fue construido en base al DER, asegurando consistencia y estructura normalizada hasta 3FN. Incluye entidades como Clientes, Vehículos, Empleados, Pedidos, Pagos, Servicios y Administrador. El modelo incluye tablas con claves primarias (PK), claves foráneas (FK), atributos correctamente normalizados y tipos de datos apropiados.

Descripción del Modelo Relacional

1. Cliente

Contiene los datos personales de cada usuario que solicita servicios a través del sistema.

Campos:

• id_cliente (PK): Identificador único.
• nombre
• apellido
• email: Se asumió que es único.
• clave
• teléfono
• fecha_registro: Fecha de alta.

Supuestos: explicación

Un cliente puede tener múltiples vehículos registrados (relación uno a muchos). Se puede desactivar un cliente (estado), sin borrarlo.

2. Vehículo

Representa los autos registrados por los clientes. Campos:

• patente (PK)
• dni_cliente (FK)
• marca
• nombre
• modelo
• color
• tipo

Supuestos: explicación

Un cliente puede registrar más de un vehículo. Cada vehículo pertenece a un solo cliente.

3. Empleado

Contiene los datos de los trabajadores que realizan los lavados.

Campos:

• dni_empleado (PK)
• id_direccion(FK)
• nombre
• apellido
• email
• clave
• telefono
• fecha_ingreso
• estado
• cvu_empleado
• alias_empleado

Supuestos: explicación

Cada pedido es atendido por un único empleado. Pero un empleado puede atender varios

pedidos.

4. Administrador

Representa al personal con acceso de control en el sistema. Campos:

• id_administrador (PK)
• nombre
• apellido
• email
• clave
• cvu_administrador
• alias_administrador

Supuestos: explicación

Los administradores no realizan lavados ni pedidos.

5. Servicio*

Define los tipos de lavado ofrecidos.

Campos:

• id_servicio (PK)
• tipo_servicio (en una próxima etapa podrán ser, por ejemplo, una lista que incluya básico, completo y premium)
• descripcion
• precio

Supuestos: explicación

Un pedido tiene un único servicio asignado.

6. Pago*

Registra los pagos efectuados por los clientes. Campos:

• id_pago (PK)
• id_pedido (FK)
• tipo_pago
• monto
• fecha_pago
• estado_pago

Supuestos: explicación

Cada pedido tiene un único pago asociado. No se modeló la relación muchos a muchos entre pedidos y pagos, ya que se asumió una transacción por pedido.

7. Pedido

Es la entidad central que vincula a cliente, servicio, empleado y pago. Campos:

• id_pedido (PK)
• dni_cliente (FK)
• dni_empleado(FK)
• id_servicio (FK)
• patente (FK)
• fecha_pedido
• provincia
• localidad
• barrio
• calle
• altura
• piso
• estado
• observaciones

Supuestos: explicación

Un pedido está asociado a un solo cliente, un servicio y un pago. Si bien en escenarios reales podría haber más complejidad (por ejemplo, múltiples pagos o empleados), se simplificó para facilitar el desarrollo inicial.

8. Dirección empleado

Representa la dirección de cada empleado Campos:

• id_direccion(PK)
• provincia
• localidad
• calle
• altura
• piso

Supuestos: explicación

Esta tabla se relaciona con la tabla Empleados mediante una clave foránea que permite asociar a cada empleado con su respectiva dirección.

Normalización

Se aplicó el proceso de normalización hasta la Tercera Forma Normal para evitar redundancia de datos y asegurar dependencia funcional directa entre atributos y claves primarias.

SCRIPTS

DDL

DML

En conclusión, el modelo entidad-relación y el modelo relacional diseñados para AquaMóvil cumplen con los requisitos funcionales actuales del sistema, asegurando integridad y normalización hasta la Tercera Forma Normal. No obstante, existen oportunidades de mejora y ampliación, como incorporar mayor flexibilidad en las formas de pago, permitir múltiples servicios por pedido o contemplar asignación colaborativa entre empleados. Estas mejoras podrán implementarse en futuras iteraciones del sistema. Si bien el modelo actual es sólido y funcional, queda abierta la posibilidad de futuras mejoras y ampliaciones que acompañen el crecimiento y la evolución del sistema.