UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

“Sistema de Servicio
de Atención para una Cafetería”

Asignatura:
Base de Datos II
Estudiantes:
1.- Alvarez Cuaretti Hugo Ramiro
2.- Gutierrez Llanco Gary Alejandro
3.- Laura Mancilla Brayan Hemer
4.- Quispe Hinojosa Ruth

Docente:
Ph.D. Rogelio Mamani Ramos

La Paz – Bolivia
2025
 ÍNDICE
ÍNDICE​ 2

I.​ INTRODUCCIÓN​ 4

1.1.​ BREVE DESCRIPCIÓN DEL PROYECTO​ 4

1.2.​ PROBLEMAS​ 4

1.2.1.​ PROBLEMAS SECUNDARIOS​ 4

1.2.2.​ PROBLEMA PRINCIPAL​ 4

1.3.​ OBJETIVOS​ 4

1.3.1.​ OBJETIVO GENERAL​ 4

1.3.2.​ OBJETIVOS ESPECÍFICOS​ 4

1.4.​ JUSTIFICACIÓN​ 4

II.​ REQUERIMIENTOS​ 5

2.1.​ DIAGNÓSTICO​ 5

2.2.​ REQUERIMIENTOS FUNCIONALES​ 5

2.3.​ REQUERIMIENTOS NO FUNCIONALES​ 5

III.​ ANÁLISIS​ 6

3.1.​ HERRAMIENTAS DE ANÁLISIS​ 6

3.2.​ COMPRENSIÓN DE LOS REQUERIMIENTOS​ 6

3.3.​ IDENTIFICACIÓN DE SUBSISTEMAS​ 6

IV.​ DISEÑO​ 7

4.1.​ HERRAMIENTAS DE DISEÑO​ 7

4.2.​ MODELO ENTIDAD RELACIÓN​ 7

4.3.​ DICCIONARIO DE DATOS​ 7

4.4.​ MODELO RELACIONAL​ 7

V.​ APLICACIÓN​ 8
5.1.​ CREACIÓN DE LA BASE DE DATOS​ 8

5.2.​ PRESENTACIÓN DEL DIAGRAMA​ 8

5.3.​ APLICACIÓN DE X​ 8

5.4.​ APLICACIÓN DE Y​ 8

5.5.​ APLICACIÓN DE LAS CONSULTAS DESDE EL LENGUAJE DE

PROGRAMACIÓN​ 8

VI.​ RESULTADOS​ 9

6.1.​ SELECCIÓN DE DATOS​ 9

6.2.​ RESULTADOS OBTENIDOS​ 9

VII.​ CONCLUSIONES​ 10

BIBLIOGRAFÍA​ 11
 I.​ INTRODUCCIÓN
Un sistema de servicio de atención en una cafetería es una solución tecnológica diseñada
para gestionar de manera integral la interacción entre el cliente, el personal de servicio y las
áreas internas del negocio (cocina, caja, administración). Este tipo de sistema puede incluir
funcionalidades como la asignación de mesas, la toma digital de pedidos, el envío
automático de órdenes a cocina o barra, la gestión de cuentas y pagos, así como la
generación de reportes de desempeño.

La implementación de un sistema de atención no solo mejora la experiencia del cliente al

reducir tiempos de espera y errores en los pedidos, sino que también permite al
administrador del negocio tener un mayor control operativo, identificar productos más
vendidos, y tomar decisiones basadas en datos reales. En cafeterías con atención en mesas,
este tipo de solución resulta especialmente valiosa, ya que permite gestionar de forma clara
y estructurada el flujo de trabajo entre meseros, baristas y cajeros.

Este documento (o proyecto) presenta el diseño y desarrollo de un sistema de servicio de

atención adaptado a las necesidades de una cafetería de tamaño pequeño o mediano, con
enfoque en eficiencia, simplicidad y mejora del servicio al cliente.

I.1.​ BREVE DESCRIPCIÓN DEL PROYECTO

El proyecto consiste en el diseño e implementación de un Sistema de Servicio de Atención

para una cafetería. Esta solución tecnológica tiene como objetivo mejorar la interacción
entre clientes, meseros, cocina/barra y administración. Este Proyecto se enfocara más en la
parte Administrativa donde se facilitara la gestión de inventario, reportes de ventas, mostrar
categorías, etc. buscando eficiencia operativa.

I.2.​ PROBLEMAS

PROBLEMAS SECUNDARIOS

●​ Falta de automatización en el registro de clientes.

●​ Dificultad para calcular las ventas por día de forma rápida.

 ●​ Complejidad para acceder al historial de pedidos.

●​ No se contaba con una forma eficiente de auditar precios y gestionar

promociones.

PROBLEMA PRINCIPAL

¿Cómo mejorar la eficiencia operativa y la atención al cliente en una cafetería mediante un

sistema que centralice la gestión de pedidos, ventas, inventario y administración de manera
automatizada y accesible?

I.3.​ OBJETIVOS

OBJETIVO GENERAL

Desarrollar un sistema de servicio de atención para una cafetería que integre de

forma eficiente la toma de pedidos, gestión de ventas, control de inventario, registro
de clientes y funciones administrativas, con el fin de optimizar el servicio al cliente
y mejorar la operatividad del negocio.

OBJETIVOS ESPECÍFICOS

●​ Automatizar el registro de clientes y su historial de compras.

●​ Facilitar el cálculo y visualización de ventas diarias, semanales y mensuales.

●​ Permitir el acceso rápido al historial de pedidos por cliente, fecha o mesa.

●​ Implementar una herramienta para gestionar precios y promociones activas o

futuras.

●​ Mejorar el seguimiento del estado de los pedidos desde la toma hasta la

entrega.

●​ Controlar el inventario con registros de ingresos, salidas, mermas y

disponibilidad de productos.
 ●​ Administrar los accesos del personal según roles y registrar horarios de

entrada y salida.

●​ Gestionar proveedores con historial de compras, productos suministrados y

control de pagos.

I.4.​ JUSTIFICACIÓN

El desarrollo de un sistema de servicio de atención para una cafetería responde a la

necesidad de optimizar los procesos internos y mejorar la experiencia del cliente en
establecimientos de tamaño pequeño o mediano. Actualmente, muchas cafeterías operan de
forma manual, lo que genera errores en pedidos, pérdida de tiempo y dificultades en la
administración del negocio. Este sistema facilitará la toma de decisiones mediante reportes
detallados, controlará el flujo de trabajo del personal y asegurará un mejor manejo del
inventario, promoviendo una atención más rápida, precisa y profesional. Además, permitirá
adaptarse a las nuevas tendencias tecnológicas en el sector gastronómico, brindando una
ventaja competitiva frente a negocios que aún no digitalizan sus operaciones.
 II.​ REQUERIMIENTOS
II.1.​ DIAGNÓSTICO

El levantamiento de requerimientos se realizó mediante los siguientes métodos:

●​ Entrevistas al personal del negocio (meseros, administradores, cajeros y cocineros)

para conocer sus necesidades, frustraciones y expectativas.
●​ Encuestas a clientes frecuentes, con el fin de comprender su experiencia actual y
sus sugerencias de mejora.
●​ Observación directa de los procesos diarios en la cafetería, identificando tiempos
muertos, errores en la toma de pedidos y manejo de pagos.
●​ Análisis de documentación existente, como cuadernos de pedidos, registros de
ventas y reportes manuales.
●​ Prototipado rápido con esquemas de interfaz (mockups) que fueron validados con
los usuarios antes del desarrollo final.

Se utilizaron las siguientes técnicas y modelos en el proceso de levantamiento:

●​ Modelo de casos de uso de UML: utilizado para describir funcionalmente las

interacciones entre los actores (meseros, cajeros, administradores, etc.) y el sistema.
●​ Técnica de entrevistas estructuradas y semiestructuradas: permite obtener
información directa de los usuarios finales sobre sus necesidades reales, de manera
detallada.
●​ Prototipado rápido: herramienta de desarrollo ágil que permite presentar posibles
soluciones a los usuarios mediante interfaces preliminares, obteniendo
retroalimentación inmediata.
●​ Checklist de requerimientos funcionales y no funcionales: para asegurar la
cobertura total de aspectos como usabilidad, seguridad, disponibilidad, entre otros.
●​ Observación participante: para comprender de forma práctica y contextual los
flujos operativos del negocio.
II.2.​ REQUERIMIENTOS FUNCIONALES

Los requerimientos funcionales definen las acciones específicas que el sistema debe ser
capaz de realizar, relacionadas directamente con los procesos del negocio y las
necesidades de los usuarios. Estos incluyen desde la toma de pedidos, la gestión de clientes
y promociones, hasta el control del inventario y los reportes de ventas. Cada requerimiento
funcional se orienta a resolver uno o más objetivos específicos del proyecto.

ID Nombre del Descripción Prioridad

Requerimiento

RF01 Registro de clientes Registrar datos personales del cliente y Alta

almacenar su historial de compras.

RF02 Consulta del historial de Permitir consultar rápidamente las Alta

clientes compras de un cliente por fecha o
monto.

RF03 Reportes de ventas por Generar reportes automáticos de ventas Alta

período por día, semana, mes o año.

RF04 Reporte por forma de Mostrar totales por tipo de pago, Media
pago y productos vendidos productos más vendidos y ventas por
categoría.

RF05 Historial de pedidos Permitir buscar pedidos anteriores por Alta

cliente, fecha o número de mesa.

RF06 Gestión de promociones Crear, activar y programar promociones Alta

(2x1, combos, descuentos, etc.).

RF07 Gestión de precios Modificar precios por producto o por Alta

categoría con control de cambios.

RF08 Seguimiento del estado de Cambiar y visualizar estados como Alta

los pedidos “Tomado”, “En preparación”, “Listo”,
“Entregado”.

RF09 Control de inventario Registrar entradas y salidas, mermas, Alta

generar alertas de stock bajo.
 RF10 Relación entre productos e Asignar ingredientes a productos del Alta
ingredientes menú para control automático de
insumos.

RF11 Gestión de proveedores Registrar proveedores, sus productos y Alta

ver historial de compras y pagos.

RF12 Visualización del menú Mostrar productos clasificados (bebidas Alta

por categorías calientes, frías, postres, promociones,
etc.).

RF13 Toma digital de pedidos Seleccionar productos desde una Alta

interfaz táctil o PC, con opciones y
observaciones.

RF14 Envío automático del Al confirmar un pedido, enviarlo Alta

pedido a cocina/barra automáticamente a la estación
correspondiente.

RF15 Emisión de factura o Emitir comprobante físico o digital con Alta

recibo QR y desglose de productos e
impuestos.

RF16 Administración de roles y Asignar permisos según el rol (mesero, Alta

accesos del personal cajero, administrador).

RF17 Registro de horarios del Registrar hora de ingreso y salida de Media

personal cada trabajador.

II.3.​ REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales establecen las condiciones de calidad, rendimiento,

seguridad y disponibilidad que debe cumplir el sistema. No están ligados directamente a
una funcionalidad específica, pero son fundamentales para garantizar que el sistema sea
usable, confiable, seguro y adaptable a distintos entornos tecnológicos. Incluyen aspectos
como el tiempo de respuesta, la escalabilidad, la usabilidad y la protección de los datos.
ID Nombre del Descripción Prioridad
Requerimiento

RNF01 Tiempo de respuesta El sistema debe responder a las solicitudes Alta

en menos de 2 segundos.

RNF02 Disponibilidad del El sistema debe estar disponible al menos Alta

sistema el 99% del tiempo.

RNF03 Seguridad de datos Los datos deben estar cifrados y protegidos Alta
mediante autenticación.

RNF04 Escalabilidad Capacidad para crecer en número de Media

usuarios sin afectar el rendimiento.

RNF05 Mantenibilidad El código debe estar modularizado y Alta

documentado para facilitar mejoras.

RNF06 Usabilidad Interfaz amigable para usuarios sin Alta

conocimientos técnicos.

RNF07 Portabilidad Ejecutarse en diferentes dispositivos y Media

sistemas operativos.

RNF08 Compatibilidad con Compatible con impresoras de tickets, Alta

hardware pantallas táctiles y lectores de código QR.

RNF09 Respaldo automático Copias de seguridad generadas Alta

automáticamente cada día.

RNF10 Gestión de accesos Permisos diferenciados por roles del Alta

personal.
 III.​ ANÁLISIS
III.1.​ HERRAMIENTAS DE ANÁLISIS

Para el análisis del sistema se utilizaron herramientas como:

●​ Diagramas de Casos de Uso (UML): Para representar las interacciones entre los
actores (mesero, cajero, administrador, cocina) y el sistema.
●​ Diagramas Entidad-Relación (ER): Para estructurar las tablas y relaciones de la
base de datos.
●​ Historias de usuario y flujos de trabajo: Para describir escenarios reales que
ocurren dentro de la cafetería.
●​ Herramientas de modelado como Draw.io: Para elaborar diagramas y visualizar la
arquitectura general del sistema.
III.2.​ COMPRENSIÓN DE LOS REQUERIMIENTOS

Los requerimientos obtenidos a través de entrevistas, observación directa y análisis de

procesos fueron organizados por categorías funcionales: gestión de pedidos, gestión de
clientes, inventario, ventas, promociones, y administración. Esta clasificación permitió
identificar prioridades, dependencias entre módulos y necesidades específicas de cada tipo
de usuario del sistema. El análisis detallado ayudó a traducir estas necesidades en
funcionalidades concretas que guiarán el desarrollo de los módulos principales del sistema.

III.3.​ IDENTIFICACIÓN DE SUBSISTEMAS

A partir del análisis de requerimientos, el sistema fue dividido en los siguientes

subsistemas:

1.​ Subsistema de Pedidos: Para tomar, gestionar y monitorear los pedidos

realizados en mesa o para llevar.
2.​ Subsistema de Cocina/Barra: Encargado de recibir y actualizar el estado de los
pedidos en preparación.

3.​ Subsistema de Clientes: Registro, historial de compras y beneficios por fidelidad.

4.​ Subsistema de Facturación y Pagos: Procesamiento de pagos, generación de
facturas y manejo de métodos de pago.

5.​ Subsistema de Reportes: Generación de estadísticas de ventas, productos más

vendidos, ingresos por día, etc.

6.​ Subsistema de Inventario: Gestión de stock de productos e ingredientes, control

de entradas, salidas y mermas.

7.​ Subsistema de Administración: Gestión del personal, control de accesos por rol y
administración de promociones.

8.​ Subsistema de Proveedores: Registro de proveedores, productos suministrados e

historial de compras.
 IV.​ DISEÑO
IV.1.​ HERRAMIENTAS DE DISEÑO

Para la etapa de diseño se utilizaron las siguientes herramientas:

●​ Draw.io: Utilizado para la elaboración del modelo Entidad-Relación (ER),

representando gráficamente las entidades del sistema, sus atributos y relaciones entre
tablas.
●​ Figma: Herramienta de diseño UI/UX empleada para crear mockups o vistas previas de
la interfaz web, permitiendo visualizar la disposición de los componentes (botones,
menús, formularios, etc.).
●​ PostgreSQL: Utilizado para estructurar y crear la base de datos relacional del sistema.
●​ Laravel (PHP): Framework backend elegido para implementar la lógica de negocio,
controladores, rutas y conexión con la base de datos.
●​ React: Librería de JavaScript seleccionada para desarrollar el frontend del sistema web,
brindando una interfaz dinámica e interactiva para los usuarios (cajeros, meseros,
administradores).
IV.2.​ MODELO ENTIDAD RELACIÓN
 Usuario(id_usuario, user, password, rol, nombre)

Cliente(id_cliente, nombre, telefono, correo_cli)

Mesa(id_mesa, estado, capacidad)

Pedido(id_pedido, tipo_entrega, estado, es_para_llevar, fecha_hora, id_usuario, id_cliente,

id_mesa)

Producto(id_producto, nombre, precio, categoria, stock)

Promocion(id_promocion, nombre, descripcion, tipo, fecha_inicio, fecha_fin)

Detalle_Pedido(id_detalle, cantidad, observaciones, id_pedido, id_producto, id_promocion)

Ingrediente(id_ingrediente, nombre, unidad_medida, cantidad, punto_reorden)

Producto_Ingrediente(id_producto, id_ingrediente, cantidad)

Proveedor(id_proveedor, nombre, contacto)

Proveedor_Ingrediente(id_proveedor, id_ingrediente)

Factura(id_factura, total, impuestos, metodo_pago, id_pedido)

Promocion_Producto(id_promocion, id_producto)

IV.3.​ DICCIONARIO DE DATOS

Entidad: Usuario

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_usuario INTEGER Identificador Numérico PRIMARY KEY, NOT

único del NULL
usuario
nombre VARCHAR(50) 50 Nombre Texto simple NOT NULL
completo del
usuario

rol VARCHAR(20) 20 Rol asignado Texto simple NOT NULL

(Ej:
administrador,
mesero)

usuario VARCHAR(30) 30 Nombre de Alfanumérico UNIQUE, NOT NULL

usuario para
login

contraseña VARCHAR(100) 100 Contraseña Hashed string NOT NULL

cifrada para
login

Entidad: Cliente

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_cliente INTEGER Identificador Numérico PRIMARY KEY,

único del NOT NULL
cliente

nombre VARCHAR(50) 50 Nombre Texto simple NOT NULL

completo
del cliente

teléfono VARCHAR(15) 15 Número de (+XX)XXXXXXX Formato válido,

teléfono del opcional
cliente

correo_cli VARCHAR(15) 15 Correo del Texto simple NOT NULL

cliente

Entidad: Mesa

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo
id_mesa INTEGER Identificador Numérico PRIMARY KEY, NOT
de la mesa NULL

estado VARCHAR(20) 20 Estado de la Libre, NOT NULL

mesa Ocupada,
Reservada

capacidad INTEGER Cantidad Numérico CHECK (capacidad > 0)

máxima de
personas

Entidad: Pedido

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_pedido INTEGER Identificador Numérico PRIMARY KEY, NOT

único del NULL
pedido

fecha_hora TIMESTAMP Fecha y hora aaaa-mm-dd NOT NULL

del pedido hh:mm:ss

estado VARCHAR(20) 20 Estado del Pendiente, NOT NULL

pedido Preparación,
Entregado

tipo_entrega VARCHAR(20) 20 Tipo de En mesa, NOT NULL

entrega Delivery

total DECIMAL(10,2) Total del Decimal CHECK (total >= 0)

pedido positivo

Entidad: Producto

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_producto INTEGER Identificador Numérico PRIMARY KEY, NOT

único del NULL
producto
nombre VARCHAR(50) 50 Nombre del Texto NOT NULL
producto

precio DECIMAL(10,2) Precio Decimal CHECK (precio >= 0)

unitario del
producto

categoría VARCHAR(30) 30 Categoría Ej: NOT NULL

del producto Bebida,
Comida

stock INTEGER Cantidad Entero CHECK (stock >= 0)

disponible
en
inventario

es_para_llevar BOOLEAN Indica si es true / NOT NULL

para llevar false

Entidad: Detalle_Pedido

Nombre del Atributo Tipo de Dato Tamañ Descripción Formato Restricciones

o

id_detalle INTEGER Identificador Numérico PRIMARY KEY,

del detalle del NOT NULL
pedido

cantidad INTEGER Cantidad del Entero CHECK (cantidad

producto en el > 0)
pedido

observaciones TEXT Observacione Texto Opcional

s del cliente libre

status_preparacion VARCHAR(20 20 Estado de Pendiente NOT NULL

) preparación , En
proceso,
Listo

Entidad: Ingrediente
Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones
Atributo

id_ingrediente INTEGER Identificador Numérico PRIMARY KEY,

único del NOT NULL
ingrediente

nombre VARCHAR(50) 50 Nombre del Texto NOT NULL

ingrediente

cantidad DECIMAL(10,2) Cantidad Decimal CHECK (cantidad >=

disponible 0)

unidad_medida VARCHAR(20) 20 Unidad de Ej: NOT NULL

medida gramos,
litros

punto_reorden DECIMAL(10,2) Cantidad Decimal CHECK

mínima (punto_reorden >= 0)
antes de
reordenar

Entidad: Proveedor

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_proveedor INTEGER Identificador Numérico PRIMARY KEY,

único del NOT NULL
proveedor

nombre VARCHAR(50) 50 Nombre del Texto NOT NULL

proveedor

contacto VARCHAR(100) 100 Información Teléfono, Opcional

de contacto email

Entidad: Factura

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo
id_factura INTEGER Identificador Numérico PRIMARY KEY,
de la factura NOT NULL

metodo_pago VARCHAR(30) 30 Método de Efectivo, NOT NULL

pago Tarjeta,
QR

impuestos DECIMAL(10,2) Monto de Decimal CHECK (impuestos

impuestos >= 0)
aplicados

total DECIMAL(10,2) Total Decimal CHECK (total >= 0)

facturado

Entidad: Promoción

Nombre del Tipo de Dato Tamaño Descripción Formato Restricciones

Atributo

id_promocion INTEGER Identificador Numérico PRIMARY KEY,

de la NOT NULL
promoción

descripcion TEXT Descripción Texto NOT NULL

de la
promoción

tipo VARCHAR(30) 30 Tipo de Ej: NOT NULL

promoción Descuento,
Combo

fecha_inicio DATE Fecha de aaaa-mm-d NOT NULL

inicio d

fecha_fin DATE Fecha de aaaa-mm-d NOT NULL

finalización d
IV.4.​ MODELO RELACIONAL
 V.​ APLICACIÓN
V.1.​ CREACIÓN DE LA BASE DE DATOS
CREATE DATABASE sistema_cafeteria;

CREATE TABLE Usuario (

id_usuario SERIAL PRIMARY KEY,

nombre VARCHAR(100),

rol VARCHAR(50),

usuario VARCHAR(50) UNIQUE,

contraseña VARCHAR(100)

);

CREATE TABLE Cliente (

id_cliente SERIAL PRIMARY KEY,

nombre VARCHAR(100),

telefono VARCHAR(20),

correo_cli VARCHAR(50)

);

CREATE TABLE Mesa (

id_mesa SERIAL PRIMARY KEY,

estado VARCHAR(50),

capacidad INT

);
CREATE TABLE Pedido (

id_pedido SERIAL PRIMARY KEY,

fecha_hora TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

estado VARCHAR(50),

tipo_entrega VARCHAR(50),

total NUMERIC(10,2),

id_usuario INT REFERENCES Usuario(id_usuario),

id_cliente INT REFERENCES Cliente(id_cliente),

id_mesa INT REFERENCES Mesa(id_mesa)

);

CREATE TABLE Producto (

id_producto SERIAL PRIMARY KEY,

nombre VARCHAR(100),

precio NUMERIC(10,2),

categoria VARCHAR(50),

stock INT,

es_para_llevar BOOLEAN

);

CREATE TABLE Detalle_Pedido (

id_detalle SERIAL PRIMARY KEY,

 cantidad INT,

observaciones TEXT,

status_preparacion VARCHAR(50),

id_pedido INT REFERENCES Pedido(id_pedido),

id_producto INT REFERENCES Producto(id_producto)

);

CREATE TABLE Ingrediente (

id_ingrediente SERIAL PRIMARY KEY,

nombre VARCHAR(100),

cantidad NUMERIC(10,2),

unidad_medida VARCHAR(50),

punto_reorden NUMERIC(10,2)

);

CREATE TABLE Proveedor (

id_proveedor SERIAL PRIMARY KEY,

nombre VARCHAR(100),

contacto VARCHAR(100)

);

CREATE TABLE Factura (

id_factura SERIAL PRIMARY KEY,

 metodo_pago VARCHAR(50),

impuestos NUMERIC(10,2),

total NUMERIC(10,2),

id_pedido INT UNIQUE REFERENCES Pedido(id_pedido)

);

CREATE TABLE Promocion (

id_promocion SERIAL PRIMARY KEY,

descripcion TEXT,

tipo VARCHAR(50),

fecha_inicio DATE,

fecha_fin DATE

);

CREATE TABLE Producto_Ingrediente (

id_producto INT REFERENCES Producto(id_producto),

id_ingrediente INT REFERENCES Ingrediente(id_ingrediente),

cantidad_usada NUMERIC(10,2),

PRIMARY KEY (id_producto, id_ingrediente)

);

CREATE TABLE Proveedor_Ingrediente (

 id_proveedor INT REFERENCES Proveedor(id_proveedor),

id_ingrediente INT REFERENCES Ingrediente(id_ingrediente),

PRIMARY KEY (id_proveedor, id_ingrediente)

);

CREATE TABLE Promocion_Producto (

id_promocion INT REFERENCES Promocion(id_promocion),

id_producto INT REFERENCES Producto(id_producto),

PRIMARY KEY (id_promocion, id_producto)

);
V.2.​ PRESENTACIÓN DEL DIAGRAMA

V.3.​ APLICACIÓN - AUDITAR PRODUCTOS

Implementación de un mecanismo de auditoría automática para los cambios de los precios

de la tabla Producto.
La tabla Historial precios almacena el id_producto, su precio anterior, su precio nuevo
además la fecha y hora en la que ocurrió el cambio.

Función fn_auditar_precio() es de tipo TRIGGER, lo que significa que será llamada

automáticamente cuando se actualicen el precio de la tabla producto.

Trigger trg_auditar_precio que se activará después de actualizar un precio de la tabla

producto.

V.4.​ APLICACIÓN - ELIMINACIÓN DE PROVEEDORES

Se implementó un mecanismo de auditoría y respaldo automático para controlar las

operaciones de eliminación (baja) de registros en la tabla Proveedor.

La tabla proveedores_eliminados almacena el id_proveedor, su nombre, el

contacto, y la fecha y hora en la que se realizó la eliminación. Esto permite
conservar un historial de proveedores eliminados para fines de trazabilidad y auditoría.

La función fn_borrar_relaciones_proveedor() es de tipo TRIGGER

BEFORE DELETE, y se encarga de eliminar previamente todas las relaciones del
proveedor con los ingredientes registrados en la tabla Proveedor_Ingrediente,
evitando errores de integridad referencial.

La función fn_backup_proveedor() también es de tipo TRIGGER, y se activa

después de eliminar un proveedor. Su objetivo es guardar automáticamente una copia de
los datos eliminados en la tabla proveedores_eliminados.

El trigger trg_borrar_relaciones_proveedor se activa antes de eliminar un

proveedor, y ejecuta la función que limpia sus relaciones.

El trigger trg_backup_proveedor se activa después de la eliminación, y llama a la

función que registra el respaldo del proveedor eliminado.

Esta implementación garantiza que no queden registros huérfanos en otras tablas y que toda
eliminación tenga un respaldo automático sin intervención manual.

---eliminar un proveedor:

-- 1. Crear tabla para respaldo de proveedores eliminados

CREATE TABLE IF NOT EXISTS proveedores_eliminados (

id_backup SERIAL PRIMARY KEY, -- Identificador único

del respaldo

id_proveedor INT, -- ID del proveedor

eliminado

nombre VARCHAR(100), -- Nombre del proveedor

contacto VARCHAR(100), -- Contacto del

proveedor

fecha_eliminacion TIMESTAMP DEFAULT CURRENT_TIMESTAMP -- Fecha y

hora del respaldo automático

);

-- 2. Función para borrar relaciones antes de eliminar un proveedor

CREATE OR REPLACE FUNCTION fn_borrar_relaciones_proveedor()

RETURNS TRIGGER AS $$

BEGIN

DELETE FROM Proveedor_Ingrediente WHERE id_proveedor =

OLD.id_proveedor;

RETURN OLD;

END;

$$ LANGUAGE plpgsql;

-- 3. Trigger BEFORE DELETE para ejecutar la función anterior

DROP TRIGGER IF EXISTS trg_borrar_relaciones_proveedor ON Proveedor;

CREATE TRIGGER trg_borrar_relaciones_proveedor

BEFORE DELETE ON Proveedor

FOR EACH ROW

EXECUTE FUNCTION fn_borrar_relaciones_proveedor();

-- 4. Función para respaldar proveedor eliminado

CREATE OR REPLACE FUNCTION fn_backup_proveedor()

RETURNS TRIGGER AS $$

BEGIN

-- Insertar los datos del proveedor que se está eliminando en la

tabla de respaldo

INSERT INTO proveedores_eliminados (id_proveedor, nombre,

contacto)

VALUES (OLD.id_proveedor, OLD.nombre, OLD.contacto);

 -- Devolver la fila antigua para continuar con la operación de
eliminación

RETURN OLD;

END;

$$ LANGUAGE plpgsql;

-- 5. Trigger AFTER DELETE para ejecutar la función de respaldo

-- Primero eliminamos el trigger si ya existe para evitar errores al

crear uno nuevo

DROP TRIGGER IF EXISTS trg_backup_proveedor ON Proveedor;

-- Creamos un nuevo trigger llamado 'trg_backup_proveedor' que se

ejecuta después de eliminar un registro

CREATE TRIGGER trg_backup_proveedor

AFTER DELETE ON Proveedor -- Se activa justo después de

borrar un proveedor

FOR EACH ROW -- Se ejecuta una vez por cada fila

eliminada

EXECUTE FUNCTION fn_backup_proveedor(); -- Llama a la función que

guarda el respaldo del proveedor eliminado

SELECT * FROM proveedor;

-- Borra un proveedor (por ejemplo el id 20)

DELETE FROM Proveedor WHERE id_proveedor = 20;

-- Verifica que se borraron sus relaciones

SELECT * FROM Proveedor_Ingrediente WHERE id_proveedor = 20;

-- Verifica el respaldo del proveedor eliminado

SELECT * FROM proveedores_eliminados WHERE id_proveedor = 20;

Select * From proveedor;

V.5.​ APLICACIÓN DE LAS CONSULTAS DESDE EL LENGUAJE DE

PROGRAMACIÓN

Para interactuar con la base de datos PostgreSQL, se utilizó el lenguaje de programación

PHP mediante el framework Laravel. Laravel proporciona herramientas poderosas para
ejecutar consultas SQL de forma segura y estructurada a través de su sistema de Eloquent
ORM y del componente Query Builder.

Consultas realizadas:

1.​ Consulta para listar los clientes registrados

Se implementó un controlador en Laravel (ClienteController) que consulta

la tabla cliente y devuelve todos los registros en orden descendente por el ID:

Esta consulta es consumida desde el frontend (React) mediante una petición

axios.get(...) al endpoint /api/cliente.
2.​ Consulta para calcular el total de ventas por fecha específica

Se implementó una función almacenada en PostgreSQL llamada

registrar_ventas_diarias_proc(fecha_input DATE), la cual
calcula el total de ventas para un día determinado. Luego, desde Laravel, se ejecuta
esta función mediante el siguiente código:

Esta consulta permite que el frontend consulte el total de ventas diario con solo
ingresar una fecha, a través de una petición axios.get(...).

3.​ Consulta para adicionar datos a la tabla clientes

Este método permite registrar un nuevo cliente desde una interfaz web (por ejemplo, un
formulario en React) y guarda automáticamente los datos en la tabla cliente de la base
de datos.
4.​ Implementación de un mecanismo de auditoría automática para los cambios de
los precios de la tabla Producto.

Para comprobar el funcionamiento del Trigger actulizaremos el precio a 60 del

producto de ID 2.

Una vez insertado el nuevo precio se mostrará la Tabla Historial Precios donde
podremos apreciar la actualización realizada.
 VI.​ RESULTADOS
VI.1.​ SELECCIÓN DE DATOS

Para el Trigger de “Implementación de un mecanismo de auditoría automática para los

cambios de los precios de la tabla Producto” se utilizó la Tabla Producto donde se
actualizarán los precios.

Además se utilizó la Tabla Historial Precios donde se mostrará el cambio de los últimos 5
cambios de precios registrados.

VI.2.​ RESULTADOS OBTENIDOS

El resultado obtenido del Trigger de “Implementación de un mecanismo de auditoría

automática para los cambios de los precios de la tabla Producto” es el esperado. Este
resultado es apreciado en PHP.
 VII.​ CONCLUSIONES
Desde una perspectiva administrativa, el desarrollo del sistema de atención para la cafetería
representa una herramienta útil para optimizar la gestión interna del negocio. La
automatización de procesos como el registro de clientes, el control de inventario, auditoria
de precios, alertas, mostrar productos por categoría y el seguimiento de ventas permite al
administrador contar con información clara, precisa y en tiempo real, lo cual facilita la toma
de decisiones más efectivas y oportunas.

El sistema también mejora significativamente la coordinación entre áreas operativas, al

permitir un control detallado de la gestión de promociones, el historial de consumo por
cliente y la administración del personal.

En conjunto, esta solución tecnológica no solo optimiza los recursos disponibles, sino que
también fortalece el control y la supervisión general del negocio, permitiendo al
administrador enfocar sus esfuerzos en estrategias de mejora continua y crecimiento
sostenible.
 BIBLIOGRAFÍA
Alarcón Herrera, E., & Crovetto Huerta, C. (2004). Bases de Datos en SQL Server 2005.
Megabyte.

De Miguel Castaño, A., Martínez Fernández, P., & Castro Galán, E. (2001). Diseño de
Bases de Datos: Problemas resueltos. Alfaomega Grupo Editor / Ra-ma.

Matsukawa Maeda, S. (2006). Oracle: Implementación y operación de una base de datos

para versiones 8i, 9i y 10g. Empresa Editora Macro E.I.R.L.

Shvets, A. (2019). Sumérgete en los patrones de diseño. Refactoring.Guru.

Robles, J. (2023). Máster en Laravel: Guía completa para el desarrollo web. Laravel Daily.

[Autor no especificado]. (2005). Programación en SQL 2005. Megabyte.