UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA INFORMÀTICA

“SISTEMA WEB DE VENTA DE PRODUCTOS DE

ABARROTE”

Asignatura: Base de Datos II

Estudiantes:

1.​ Camargo Arce Cristhian Fernando

2.​ Soruco Salazar Victor Ezequiel
3.​ Yujra Machaca Gabriel

Docente: Ph.D. Rogelio Mamani Ramos

La Paz – Bolivia

2025

1
ÍNDICE.

I. INTRODUCCIÓN​ 3
1.1. Breve descripción del proyecto​ 4
1.2.2 Problema principal​ 5
1.3. OBJETIVOS​ 5
1.3.1. Objetivo general​ 5
1.3.2. Objetivos específicos​ 5
1.4. Justificación​ 6
II. REQUERIMIENTOS​ 6
2.1. Diagnóstico​ 6
2.2. Requerimientos funcionales​ 6
2.3. Requerimientos no funcionales​ 7
III. ANÁLISIS​ 8
3.1. Herramientas de análisis​ 8
3.2. Comprensión de los requerimientos​ 11
Validación de los Requerimientos con los Usuarios​ 12
IV. DISEÑO​ 15
4.1. Herramientas de diseño​ 15
4.3. Diccionario de datos​ 18
4.4. Modelo relacional​ 20
V. APLICACIÓN​ 21
5.1. Creación de la base de datos​ 21
5.2. Presentación del diagrama​ 23
5.3. Aplicación de procedimiento sp_registrar_venta para ALTA​ 24
5.4. Aplicación de procedimiento sp_eliminar_venta para BAJA​ 25
5.5 Aplicación de Trigger tg_log_venta con la función fn_log_venta para el registro de las
ventas eliminadas​ 25
5.6. Aplicación de las consultas desde el lenguaje de programación​ 26
VI. RESULTADOS​ 32
6.1. Selección de datos​ 32
6.2. Resultados obtenidos​ 33
VII. CONCLUSIONES​ 35
BIBLIOGRAFÍA​ 36

2
I. INTRODUCCIÓN
En la actualidad, los negocios dedicados a la venta de productos de abarrotes
enfrentan desafíos relacionados con la administración de inventario, la gestión de
clientes, la eficiencia en el proceso de ventas y la trazabilidad de sus operaciones.
Muchos de estos negocios aún dependen de sistemas manuales o planillas básicas
que no permiten un control riguroso del stock ni una atención adecuada a los
clientes.​

Este proyecto desarrolla un sistema web de venta de productos de abarrotes que

tiene como objetivo mejorar la gestión interna de este tipo de negocios mediante una
plataforma digital robusta y fácil de usar. El sistema se construyó sobre un modelo
entidad-relación relacional que integra las principales operaciones comerciales, tales
como el registro de productos clasificados por categorías, control de stock,
administración de clientes, generación de ventas, y seguimiento detallado de cada
transacción. Además, incorpora funcionalidades clave como la bitácora de
eliminación de productos y la administración de usuarios, lo que permite garantizar la
seguridad y control sobre el uso del sistema.​

Gracias a esta solución, se proporciona a los pequeños y medianos comerciantes de

abarrotes una herramienta adaptable, escalable y pensada para crecer junto con su
negocio. Se espera que la implementación del sistema contribuya a una mejor toma
de decisiones, al disponer de información precisa y actualizada sobre ventas,
productos y comportamiento del cliente.​

Asimismo, el sistema busca reducir significativamente los errores humanos

asociados al manejo manual de datos, automatizando tareas críticas y
proporcionando reportes fiables para el análisis del desempeño comercial. De esta
manera, se promueve la transformación digital de los comercios tradicionales,
fortaleciendo su competitividad en un mercado que exige cada vez mayor eficiencia
y control.

3
 1.1. Breve descripción del proyecto
El sistema de ventas para productos de abarrotes ha sido diseñado utilizando una
base de datos relacional que permite organizar y relacionar adecuadamente los
distintos componentes del negocio. Incluye tablas para gestionar clientes, productos,
categorías, ventas y detalles de venta. Además, incorpora un módulo de usuarios
con roles, permitiendo diferenciar accesos al sistema según el tipo de usuario.

El sistema contempla funcionalidades clave como:

●​ Registro y clasificación de productos por categorías.

●​ Gestión de clientes con información detallada.
●​ Registro de ventas y sus detalles (producto, cantidad, precio unitario, subtotal).
●​ Control de stock automático tras cada venta.
●​ Registro de productos eliminados mediante una bitácora.
●​ Seguridad básica mediante autenticación de usuarios con rol asignado.

Este modelo garantiza integridad de datos, facilita consultas eficientes y sienta las
bases para futuras expansiones, como la generación de reportes o integración con
módulos de compras.

1.2. PROBLEMAS

1.2.1 Problemas secundarios

●​ Descontrol del inventario: La ausencia de un sistema automatizado impide llevar

un control preciso del stock de productos, generando rupturas de stock o
acumulación innecesaria de mercadería.​

●​ Dificultad para registrar y consultar ventas: El registro manual o poco organizado

de las ventas dificulta la generación de reportes, la verificación de transacciones
anteriores y el análisis de ingresos.​

●​ Falta de trazabilidad de productos eliminados: No se cuenta con un historial o

bitácora de productos que han sido eliminados, lo cual impide realizar auditorías o
análisis de decisiones pasadas.​

●​ Gestión ineficiente de clientes: No existe una base de datos organizada de

clientes que permita un seguimiento de compras, historial o preferencias.​

●​ Acceso sin control por roles: Todos los usuarios pueden acceder a las mismas
funciones sin distinción, lo que representa un riesgo de seguridad y manipulación
indebida de la información.​

●​ Clasificación desordenada de productos: La falta de categorización dificulta

ubicar productos rápidamente y analizar el inventario por tipo o familia.​

4
 ●​ Proceso de ventas lento y propenso a errores: El registro manual de cada venta y
sus detalles puede generar errores de cálculo en precios, subtotales o totales,
afectando la exactitud de los ingresos.

1.2.2 Problema principal

La falta de un sistema digital de gestión de ventas e inventario en negocios de abarrotes
provoca errores frecuentes en los registros, pérdida de información, dificultad para controlar
el stock y retrasos en la atención al cliente, afectando directamente la eficiencia operativa y
la toma de decisiones del negocio. Esta situación obliga a los comerciantes a depender de
métodos manuales o planillas básicas que no garantizan la precisión ni la disponibilidad
inmediata de los datos. Además, la carencia de reportes automatizados limita la capacidad
de análisis sobre productos más vendidos, comportamientos de compra y niveles de
inventario, dificultando la planificación de compras y la reposición oportuna de mercadería.
Todo esto representa una barrera significativa para el crecimiento del negocio y su
competitividad frente a otros comercios que ya han adoptado soluciones digitales modernas.

1.3. OBJETIVOS

1.3.1. Objetivo general

Desarrollar un sistema web de gestión de ventas para productos de abarrotes, basado en
una base de datos relacional, que permita automatizar y optimizar el control de inventario, la
administración de clientes, el registro de ventas y la trazabilidad de las operaciones,
mejorando así la eficiencia operativa del negocio.

1.3.2. Objetivos específicos

●​ Diseñar la estructura de base de datos que permita organizar de manera eficiente la
información de productos, categorías, clientes, ventas, usuarios y registros
históricos.

●​ Implementar procedimientos almacenados, funciones y triggers en PostgreSQL que

automaticen las operaciones clave como la inserción, modificación y eliminación de
ventas, garantizando la integridad de los datos y facilitando su trazabilidad.

●​ Automatizar el control de stock mediante la actualización dinámica del inventario al

momento de realizar o modificar ventas.

●​ Incorporar mecanismos de autenticación y control de acceso por roles, diferenciando

entre administradores y vendedores para fortalecer la seguridad del sistema.

●​ Registrar automáticamente en una bitácora las eliminaciones de ventas, permitiendo

un seguimiento histórico confiable para auditorías y análisis posteriores.

●​ Facilitar la consulta de datos a través de funciones que permitan listar ventas, ver
detalles específicos y obtener información organizada para su análisis.

5
 ●​ Sentar las bases para una interfaz web amigable que permita a los usuarios
interactuar con el sistema de forma sencilla, rápida y segura.

1.4. Justificación

La implementación de un sistema web para la gestión de ventas de productos de abarrotes

surge como respuesta a las necesidades actuales de digitalización y eficiencia operativa en
los pequeños y medianos comercios. Estos negocios, al no contar con una herramienta
tecnológica adecuada, enfrentan limitaciones que afectan directamente su productividad,
control administrativo y capacidad de crecimiento.

La automatización de procesos clave como el control de inventario, el registro de ventas y la

administración de clientes permite reducir errores humanos, mejorar la organización de la
información y disponer de datos actualizados en tiempo real. A través del uso de una base
de datos relacional y el desarrollo de funciones, triggers y procedimientos almacenados en
PostgreSQL, se garantiza la integridad de los datos y se facilita la trazabilidad de las
operaciones.

Además, la incorporación de roles de usuario y bitácoras fortalece la seguridad y la

responsabilidad dentro del sistema, permitiendo un manejo más transparente de la
información. Esto no solo contribuye al buen funcionamiento diario del negocio, sino que
también prepara el camino para futuros módulos de análisis, reportes y expansión del
sistema.

II. REQUERIMIENTOS

2.1. Diagnóstico
Observación directa: Actualmente, muchos negocios de venta de abarrotes operan sin
sistemas digitales adecuados, lo cual genera desorganización en la administración del
inventario, falta de control sobre las ventas realizadas, y una gestión ineficiente de la
información de clientes y productos. El uso de métodos manuales como planillas,
anotaciones en cuadernos o archivos dispersos limita la capacidad del negocio para crecer,
atender de forma eficiente a los clientes y tomar decisiones estratégicas basadas en datos
reales.

Este diagnóstico revela la necesidad urgente de implementar una solución digital que
automatice las operaciones del negocio, brinde seguridad en el manejo de los datos y
proporciona reportes claros y confiables para la toma de decisiones. Asimismo, se identificó
la falta de control de acceso por roles, ausencia de trazabilidad en las eliminaciones de
ventas y dificultades para consultar información histórica como aspectos críticos a resolver.

Metodología diagramas casos de uso contexto y secuencia: A través de diagramas de

casos de uso (primer diagrama), se han identificado las funcionalidades que cada rol puede
realizar dentro del sistema. Estos incluyen desde registrar clientes y productos, hasta
realizar ventas y gestionar el inventario. La descripción de los casos de uso permite
entender cómo interactúan los usuarios con el sistema, detallando las operaciones

6
principales que el sistema debe soportar, tales como la actualización de stock, la
registración de ventas y el seguimiento de clientes.

En resumen, la metodología utilizada para el levantamiento de requerimientos de este

sistema de ventas está basada en un enfoque estructurado que contempla la identificación
de roles, la definición de casos de uso, el modelado del flujo de trabajo, la validación de
datos en tiempo real mediante diagramas de secuencia, y la implementación de controles
de seguridad y trazabilidad. Este enfoque garantiza que el sistema no solo cumpla con los
requerimientos actuales, sino que también esté preparado para crecer y adaptarse a las
necesidades futuras del negocio.

2.2. Requerimientos funcionales

Los requerimientos funcionales describen las funcionalidades que el sistema debe cumplir
para satisfacer las necesidades del negocio. A continuación, se listan los principales:

●​ El sistema debe permitir el registro, edición y eliminación de productos, asociados a

una categoría específica.

●​ El sistema debe registrar clientes con datos como nombre, CI, teléfono y dirección.

●​ El sistema debe permitir realizar ventas seleccionando productos, cantidades y

precios, y debe generar automáticamente el total de la transacción.

●​ El sistema debe actualizar el stock de los productos de manera automática después

de cada venta.

●​ El sistema debe permitir la consulta de todas las ventas registradas, mostrando

cliente, fecha y total.

●​ El sistema debe mostrar el detalle de cada venta, incluyendo productos vendidos,

precios unitarios, cantidades y subtotales.

●​ El sistema debe permitir editar ventas y actualizar automáticamente el total y el

inventario.

●​ El sistema debe permitir eliminar ventas, y registrar automáticamente un log con la

información eliminada.

●​ El sistema debe permitir crear usuarios con roles (administrador, cajero) y autenticar
el acceso con credenciales.

●​ El sistema debe restringir el acceso a ciertas funcionalidades según el rol del

usuario.

7
2.3. Requerimientos no funcionales
Los requerimientos no funcionales definen las condiciones bajo las cuales el sistema debe
operar:

●​ Usabilidad: La interfaz del sistema debe ser clara, simple e intuitiva, diseñada con
HTML y Bootstrap para garantizar una experiencia de usuario agradable, accesible
incluso para usuarios sin experiencia técnica.

●​ Disponibilidad: El sistema debe estar disponible durante las horas operativas del
negocio, ejecutándose localmente o desde un servidor que garantice acceso
constante. Flask será configurado para correr de forma estable durante el uso
cotidiano.

●​ Escalabilidad: La arquitectura debe permitir integrar nuevas funcionalidades en el

futuro (como generación de reportes, módulo de compras, gráficos de ventas) sin
necesidad de rediseñar completamente el sistema.

●​ Mantenibilidad: El sistema debe seguir buenas prácticas de desarrollo con Flask

(modularidad, rutas bien definidas, separación entre lógica y presentación), y una
estructura clara de carpetas y archivos que facilite su mantenimiento y evolución.

●​ Integridad de datos: PostgreSQL (administrado con pgAdmin 4) debe garantizar

que los datos cumplan reglas de validación mediante restricciones (CHECK, NOT
NULL), claves foráneas, triggers y procedimientos almacenados.

●​ Compatibilidad: La interfaz desarrollada con HTML y Bootstrap debe ser

completamente funcional y responsive, compatible con los navegadores más usados
como Google Chrome, Mozilla Firefox y Microsoft Edge.

●​ Rendimiento: Las consultas realizadas desde Flask hacia PostgreSQL deben

ejecutarse eficientemente incluso al manejar volúmenes crecientes de datos. Las
operaciones comunes (registro de ventas, consultas, stock) no deben exceder los 2
segundos de respuesta bajo condiciones normales.

●​ Modularidad: El sistema debe estar dividido claramente entre capa de presentación

(frontend con Bootstrap), lógica de negocio (Flask) y persistencia (PostgreSQL), lo
cual permite mantener y extender el sistema con mayor facilidad.

8
III. ANÁLISIS

3.1. Herramientas de análisis

En este punto se indican las herramientas teóricas o técnicas utilizadas para analizar los
requerimientos obtenidos. Aquí se puede incluir los modelos de diagramas

●​ Diagramas de casos de uso

●​ Diagrama de actividades

9
 ●​ Diagrama de contexto

●​ Diagrama de secuencia de datos

10
3.2. Comprensión de los requerimientos
Este apartado describe cómo se interpretan y organizan los requerimientos funcionales y no
funcionales del sistema. Aquí se detalla la clasificación de los requerimientos y el proceso
de validación con los usuarios, garantizando que las necesidades del negocio estén
cubiertas y que no haya ambigüedades o conflictos en los requisitos establecidos.

Clasificación de Requerimientos
Requerimientos funcionales: Los requerimientos funcionales describen las
funcionalidades esenciales del sistema para que cumpla con las expectativas del negocio. A
continuación, se listan los requerimientos clave que el sistema debe cumplir:

●​ Registro, edición y eliminación de productos: El sistema debe permitir gestionar

productos, asociándose a categorías específicas. Esta funcionalidad es esencial
para mantener actualizado el catálogo de productos.​

●​ Gestión de clientes: El sistema debe permitir registrar clientes con datos como
nombre, CI, teléfono y dirección para garantizar una correcta identificación de los
compradores.​

●​ Realización de ventas: El sistema debe permitir seleccionar productos, cantidades

y precios, calculando automáticamente el total de la transacción. Esta es una de las
funcionalidades principales del sistema.​

●​ Actualización de stock: El sistema debe actualizar el inventario de productos

automáticamente después de cada venta, asegurando que el stock refleje siempre la
disponibilidad real.​

●​ Consulta de ventas: El sistema debe permitir consultar todas las ventas

registradas, mostrando la información relevante como cliente, fecha y total.​

●​ Detalle de venta: El sistema debe mostrar un detalle de cada venta, incluyendo los
productos vendidos, precios unitarios, cantidades y subtotales para proporcionar
claridad al usuario.​

●​ Edición y actualización de ventas: El sistema debe permitir editar ventas

existentes y actualizar automáticamente el total y el inventario, brindando flexibilidad
en la gestión de ventas.​

●​ Eliminación de ventas: El sistema debe permitir eliminar ventas, registrando

automáticamente un log con la información de la transacción eliminada,
garantizando la trazabilidad.​

●​ Gestión de usuarios: El sistema debe permitir crear usuarios con roles

(administrador, cajero) y autenticar el acceso con credenciales. Esta funcionalidad
garantiza la seguridad del sistema.​

11
 ●​ Control de acceso: El sistema debe restringir el acceso a ciertas funcionalidades
según el rol del usuario, asegurando que solo los usuarios autorizados puedan
realizar acciones específicas.

Requerimientos no funcionales: Los requerimientos no funcionales definen las

condiciones y características bajo las cuales el sistema debe operar, tales como
rendimiento, seguridad, y facilidad de uso. A continuación se describen los requerimientos
no funcionales más relevantes:

●​ Usabilidad: La interfaz debe ser clara, simple e intuitiva, diseñada con HTML y
Bootstrap. La experiencia de usuario debe ser accesible, incluso para usuarios sin
experiencia técnica.​

●​ Disponibilidad: El sistema debe estar disponible durante las horas operativas del
negocio, ejecutándose de forma estable localmente o en un servidor que garantice
acceso constante.​

●​ Escalabilidad: La arquitectura del sistema debe permitir la integración de nuevas

funcionalidades, como la generación de reportes, módulo de compras y gráficos de
ventas, sin necesidad de rediseñar el sistema.​

●​ Mantenibilidad: El sistema debe seguir buenas prácticas de desarrollo con Flask,

garantizando modularidad, rutas bien definidas y separación entre lógica y
presentación. Además, debe tener una estructura clara de carpetas y archivos para
facilitar el mantenimiento.​

●​ Integridad de datos: PostgreSQL debe garantizar que los datos estén validados
mediante restricciones (CHECK, NOT NULL), claves foráneas, triggers y
procedimientos almacenados, manteniendo la calidad de la información.​

●​ Compatibilidad: La interfaz desarrollada con HTML y Bootstrap debe ser

completamente funcional y compatible con los principales navegadores como
Google Chrome, Mozilla Firefox y Microsoft Edge.​

●​ Rendimiento: Las consultas realizadas desde Flask hacia PostgreSQL deben

ejecutarse eficientemente, incluso al manejar grandes volúmenes de datos. Las
operaciones más comunes, como el registro de ventas, deben ejecutarse en menos
de 2 segundos.​

●​ Modularidad: El sistema debe estar claramente dividido en capas: presentación

(frontend con Bootstrap), lógica de negocio (Flask) y persistencia (PostgreSQL).
Esto permitirá una mayor facilidad de mantenimiento y expansión del sistema.

Validación de los Requerimientos con los Usuarios

12
La validación de los requerimientos con los usuarios finales es un proceso esencial para
garantizar que las funcionalidades del sistema realmente respondan a las necesidades del
negocio. Para ello, se realizaron las siguientes acciones:

●​ Iteración en el diseño: Durante la fase de diseño, los usuarios fueron consultados

sobre la funcionalidad de cada módulo y se les permitió hacer ajustes a las
funcionalidades propuestas.​

●​ Pruebas iniciales: Se implementaron versiones iniciales de las funcionalidades

clave (como la gestión de productos y ventas) para ser probadas en un entorno real,
permitiendo a los usuarios validar su efectividad.

​
3.3. Identificación de subsistemas
El sistema se divide en varios subsistemas o módulos independientes, cada uno con
responsabilidades específicas y funcionalidades bien definidas. Esta división permite un
diseño más claro, facilita la implementación y mejora el mantenimiento del software,
permitiendo además una escalabilidad adecuada para el futuro. A continuación, se
describen los principales subsistemas del sistema de ventas de productos de abarrotes:

●​ Subsistema de autenticación y roles:Este subsistema se encarga de gestionar la

autenticación de usuarios y la gestión de roles dentro del sistema. Su propósito es
asegurar que solo los usuarios autorizados puedan acceder al sistema y realizar
acciones de acuerdo a su rol (administrador o vendedor).

Funciones principales:

○​ Registro de nuevos usuarios.

○​ Autenticación de usuarios mediante credenciales (nombre de usuario y
contraseña).​
Asignación de roles (administrador, cajero).
○​ Restricción de acceso a funcionalidades según el rol asignado (por ejemplo,
el administrador puede gestionar productos y usuarios, mientras que el cajero
solo puede registrar ventas).

●​ Subsistema de Gestión de Productos: Este subsistema se encarga de la gestión

del catálogo de productos, permitiendo realizar operaciones sobre los productos que
se venden en el negocio de abarrotes. Su objetivo es asegurar que el sistema tenga
un control adecuado sobre los productos, permitiendo su registro, edición y
eliminación.

Funciones principales:

○​ Registro de nuevos productos con detalles como nombre, descripción, precio

y categoría.
○​ Edición y eliminación de productos.

13
 ○​ Categorización de productos para facilitar su búsqueda y clasificación.
○​ Consulta de productos registrados y su información detallada.

●​ Subsistema de Gestión de Ventas:El subsistema de ventas es el núcleo operativo

del sistema. Este módulo está diseñado para gestionar todo el proceso de
transacción comercial, garantizando que cada venta se registre de manera precisa y
que los cálculos sean automáticos, lo cual contribuye a la eficiencia y a la
eliminación de errores humanos.

Funciones principales:

○​ Selección de productos para realizar la venta: Permite al vendedor

seleccionar los productos desde el catálogo, especificando cantidades y
precios de cada uno.
○​ Registro de las ventas: Registra los detalles de la venta, incluyendo cliente,
productos vendidos, cantidades, precios unitarios, impuestos y descuentos
aplicados.
○​ Cálculo automático del total de la venta: El sistema calcula automáticamente
el total de la transacción, teniendo en cuenta los subtotales, impuestos y
descuentos, garantizando que el monto a pagar sea exacto.
○​ Actualización automática del inventario: Cada vez que se registre una venta,
el inventario se actualiza automáticamente, reflejando la reducción en stock
de los productos vendidos.
○​ Generación de recibos o tickets de compra: Después de completar la venta,
se genera un recibo o ticket de compra para el cliente, que incluye detalles
de la transacción.

●​ Subsistema de Control de Stock:El subsistema de control de stock es esencial

para la gestión eficiente del inventario de productos. Este subsistema asegura que el
stock se mantenga actualizado en tiempo real y proporciona herramientas para
realizar ajustes en el inventario según sea necesario, evitando la sobreventa de
productos no disponibles.

Funciones principales:

○​ Actualización automática del stock: Después de cada venta, el sistema ajusta

automáticamente el inventario, reduciendo la cantidad disponible de los
productos vendidos.
○​ Consulta del estado del inventario: Los usuarios pueden consultar el
inventario, visualizando los productos disponibles, aquellos agotados y
aquellos con bajo stock.

14
 ○​ Generación de alertas para productos con bajo stock: El sistema envía
alertas a los administradores o encargados cuando los productos alcanzan
niveles críticos de stock, ayudando a prevenir rupturas de inventario.
○​ Posibilidad de modificar manualmente el stock: En caso de reposición de
productos, devoluciones o ajustes, el sistema permite a los usuarios realizar
modificaciones manuales al inventario, con registro de cambios para
mantener la trazabilidad.

IV. DISEÑO

4.1. Herramientas de diseño

En el desarrollo de este sistema de gestión de ventas de productos de abarrotes, se
utilizaron varias herramientas de diseño que nos permitieron crear y visualizar tanto el
modelo de datos como las relaciones entre las tablas de la base de datos. Las herramientas
utilizadas fueron Draw.io, PostgreSQL, y PlantUML, cada una cumpliendo un papel clave en
el diseño de la arquitectura y el modelo relacional

Descripción:

●​ Draw.io es una herramienta de diagramación en línea que nos permitió crear el

diagrama entidad-relación (ER) del sistema. Con esta herramienta, representamos
gráficamente las entidades, sus atributos y las relaciones entre ellas. Las entidades
como Producto, Venta, Cliente, DetalleVenta, entre otras, fueron definidas
claramente, así como las relaciones entre ellas (por ejemplo, un Cliente realiza
muchas Ventas).

Beneficio:

●​ Nos ayudó a visualizar la estructura del sistema, facilitando la comprensión de cómo

interactúan las distintas tablas y asegurando que el modelo de datos fuera coherente
con los requerimientos del sistema.

Descripción:

●​ PostgreSQL fue la base de datos utilizada para almacenar los datos del sistema.
Tras definir el modelo de datos en Draw.io, lo llevamos a la práctica con la creación
de las tablas en PostgreSQL. Utilizamos esta herramienta para definir la estructura
de la base de datos mediante comandos SQL, que permitieron crear las tablas como
Cliente, Producto, Venta, DetalleVenta, entre otras.

15
Beneficio:

●​ Aseguró que la base de datos estuviera optimizada y fuera eficiente, al mismo

tiempo que nos permitió aplicar llaves primarias y foráneas para garantizar la
integridad referencial entre las tablas.

Descripción:

●​ PlantUML es una herramienta que permite la creación de diagramas a partir de

texto, lo que la convierte en una excelente opción para documentar diagramas de
flujo, de clases y otros. En este caso, PlantUML nos ayudó a generar diagramas de
clases y diagramas de secuencia, que complementaron el modelo ER visualizado
en Draw.io y ayudaron a entender los procesos dinámicos del sistema (por ejemplo,
el flujo de datos durante la venta).​

Beneficio:

●​ Proporcionó una forma estructurada de representar cómo las operaciones del

sistema interactúan entre sí, lo que fue útil para definir cómo las funciones y
procesos de negocio se integran con la base de datos.

4.2. Modelo Entidad Relación

16
17
4.3. Diccionario de datos
●​ Tabla: categoría

Campo Tipo de Dato PK FK Nulo Restricciones

id_categoria SERIAL ✔️ No Autoincremental

nombre_categoria VARCHAR(50) No Único

●​ Tabla: producto

Campo Tipo de Dato PK FK Nulo Restricciones

id_producto SERIAL ✔️ No Autoincremental

nombre VARCHAR(100) No

descripcion TEXT Sí

precio NUMERIC(10,2) No CHECK (precio > 0)

stock INTEGER No CHECK (stock >= 0)

id_categoria INTEGER ✔️ Sí FK → categoria(id_categoria)

●​ Tabla: cliente

18
 Campo Tipo de Dato PK FK Nulo Restricciones

id_cliente SERIAL ✔️ No Autoincremental

nombre VARCHAR(100) No

ci VARCHAR(20) Sí Único

telefono VARCHAR(20) Sí

direccion TEXT Sí

●​ Tabla: venta

Campo Tipo de Dato PK FK Nulo Restricciones

id_venta SERIAL ✔️ No Autoincremental

id_cliente INTEGER ✔️ Sí FK → cliente(id_cliente)

fecha TIMESTAMP No DEFAULT CURRENT_TIMESTAMP

total NUMERIC(10,2) No DEFAULT 0

●​ Tabla: detalle_venta

Campo Tipo de Dato PK FK Nulo Restricciones

id_detalle SERIAL ✔️ No Autoincremental

id_venta INTEGER ✔️ No FK → venta(id_venta), ON DELETE

CASCADE

id_producto INTEGER ✔️ No FK → producto(id_producto)

cantidad INTEGER No CHECK (cantidad > 0)

precio_unitari NUMERIC(10,2 No
o )

subtotal NUMERIC(10,2 No Calculado: cantidad * precio_unitario

) (STORED)

●​ Tabla: usuario

19
 Campo Tipo de Dato PK FK Nulo Restricciones

id_usuario SERIAL ✔️ No Autoincremental

username VARCHAR(50) No Único

password TEXT No

rol VARCHAR(30) No CHECK (rol IN ('admin', 'vendedor'))

●​ Tabla: log_venta

Campo Tipo de Dato PK FK Nulo Restricciones

id_log SERIAL ✔️ No Autoincremental

id_venta INTEGER ✔️ No FK → venta(id_venta)

id_cliente INTEGER ✔️ No FK → cliente(id_cliente)

fecha TIMESTAMP No

total NUMERIC(10,2) No

20
4.4. Modelo relacional

CATEGORIA(id_categoria SERIAL PRIMARY KEY, nombre_categoria VARCHAR(50))

USUARIO(id_usuario SERIAL PRIMARY KEY, password TEXT, username VARCHAR(50),
rol VARCHAR(30))

PRODUCTO(id_producto SERIAL PRIMARY KEY, descripcion TEXT, stock INTEGER,

id_categoria INT, nombre VARCHAR(100), precio NUMERIC(10,2), FOREIGN KEY
(id_categoria) REFERENCES CATEGORIA(id_categoria))

VENTA(id_venta SERIAL PRIMARY KEY, id_cliente INT, fecha TIMESTAMP, total

NUMERIC(10,2), FOREIGN KEY (id_cliente) REFERENCES CLIENTE(id_cliente))

CLIENTE(id_cliente SERIAL PRIMARY KEY, direccion TEXT, nombre VARCHAR(100), ci

VARCHAR(20), telefono VARCHAR(20))

DETALLE_VENTA(id_detalle SERIAL PRIMARY KEY, id_venta INT, id_producto INT,

cantidad INTEGER, precio_unitario NUMERIC(10,2), subtotal NUMERIC(10,2), FOREIGN
KEY (id_venta) REFERENCES VENTA(id_venta), FOREIGN KEY (id_producto)
REFERENCES PRODUCTO(id_producto))

21
LOG_VENTA(id_log SERIAL PRIMARY KEY, id_venta INT, id_cliente INT, fecha
TIMESTAMP, total NUMERIC(10,2), FOREIGN KEY (id_venta) REFERENCES
VENTA(id_venta), FOREIGN KEY (id_cliente) REFERENCES CLIENTE(id_cliente))

USUARIO(id_usuario SERIAL PRIMARY KEY, password TEXT, username VARCHAR(50),

rol VARCHAR(30))

V. APLICACIÓN

5.1. Creación de la base de datos

Base de datos: (pgAdmin 4)

CREATE DATABASE tienda_web_abarrotes;

tablas:​

CREATE TABLE categoria (

id_categoria SERIAL PRIMARY KEY,
nombre_categoria VARCHAR(50) NOT NULL UNIQUE
);

CREATE TABLE producto (

id_producto SERIAL PRIMARY KEY,
nombre VARCHAR(100) NOT NULL,
descripcion TEXT,
precio NUMERIC(10,2) NOT NULL CHECK (precio > 0),
stock INT NOT NULL CHECK (stock >= 0),
id_categoria INT REFERENCES categoria(id_categoria)
);

CREATE TABLE cliente (

id_cliente SERIAL PRIMARY KEY,
nombre VARCHAR(100) NOT NULL,
ci VARCHAR(20) UNIQUE,
telefono VARCHAR(20),
direccion TEXT
);

22
CREATE TABLE venta (
id_venta SERIAL PRIMARY KEY,
id_cliente INT REFERENCES cliente(id_cliente),
fecha TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total NUMERIC(10,2) DEFAULT 0
);

CREATE TABLE detalle_venta (

id_detalle SERIAL PRIMARY KEY,
id_venta INT REFERENCES venta(id_venta) ON DELETE
CASCADE,
id_producto INT REFERENCES producto(id_producto),
cantidad INT NOT NULL CHECK (cantidad > 0),
precio_unitario NUMERIC(10,2) NOT NULL,
subtotal NUMERIC(10,2) GENERATED ALWAYS AS (cantidad *
precio_unitario) STORED
);

CREATE TABLE usuario (

id_usuario SERIAL PRIMARY KEY,
username VARCHAR(50) UNIQUE NOT NULL,
password TEXT NOT NULL,
rol VARCHAR(30) CHECK (rol IN ('admin', 'vendedor')) NOT
NULL
);

------ TABLA TRIGGER -------

CREATE TABLE log_venta (

id_log SERIAL PRIMARY KEY,
id_venta INT,
id_cliente INT,
fecha TIMESTAMP,
total NUMERIC(10,2)
);

23
5.2. Presentación del diagrama

5.3. Aplicación de procedimiento sp_registrar_venta para ALTA

Para registrar una venta con sus productos asociados, se creó el procedimiento
almacenado sp_registrar_venta. Este procedimiento permite insertar datos en las tablas
venta y detalle_venta de forma automatizada y estructurada.

CREATE OR REPLACE PROCEDURE sp_registrar_venta(

p_id_cliente INT,

p_productos JSON

LANGUAGE plpgsql

AS $$

DECLARE

v_id_venta INT;

v_item JSON;

v_id_producto INT;

24
 v_cantidad INT;

v_precio NUMERIC;

v_total NUMERIC := 0;

BEGIN

INSERT INTO venta(id_cliente) VALUES (p_id_cliente)

RETURNING id_venta INTO v_id_venta;

FOR v_item IN SELECT * FROM json_array_elements(p_productos)

LOOP

v_id_producto := (v_item->>'id_producto')::INT;

v_cantidad := (v_item->>'cantidad')::INT;

v_precio := (v_item->>'precio')::NUMERIC;

INSERT INTO detalle_venta(id_venta, id_producto, cantidad, precio_unitario)

VALUES (v_id_venta, v_id_producto, v_cantidad, v_precio);

v_total := v_total + (v_precio * v_cantidad);

END LOOP;

UPDATE venta SET total = v_total WHERE id_venta = v_id_venta;

END;

$$;

5.4. Aplicación de procedimiento sp_eliminar_venta para BAJA

Para eliminar una venta del sistema, se definió el procedimiento sp_eliminar_venta. Este
procedimiento borra un registro de la tabla venta, y gracias a las relaciones establecidas,
también se eliminan automáticamente sus detalles correspondientes en la tabla
detalle_venta.

CREATE OR REPLACE PROCEDURE sp_eliminar_venta(p_id INT)

LANGUAGE plpgsql
AS $$
BEGIN

25
 DELETE FROM venta WHERE id_venta = p_id;
END;
$$;

5.5 Aplicación de Trigger tg_log_venta con la función fn_log_venta para el registro de

las ventas eliminadas
Para mantener un registro histórico de las ventas eliminadas, se diseñó el trigger
tg_log_venta, que se activa después de ejecutar un DELETE sobre la tabla venta. Este
trigger llama a la función fn_log_venta, la cual inserta automáticamente en la tabla
log_venta los datos de la venta eliminada: el ID de la venta, el id_cliente, el total y la
fecha. De esta forma se preserva un historial de ventas eliminadas para auditoría o control.
CREATE OR REPLACE FUNCTION fn_log_venta()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO log_venta(id_venta, id_cliente, fecha, total)
VALUES (OLD.id_venta, OLD.id_cliente, OLD.fecha,
OLD.total);
RETURN OLD;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER tg_log_venta

AFTER DELETE ON venta
FOR EACH ROW
EXECUTE FUNCTION fn_log_venta();

5.6. Aplicación de las consultas desde el lenguaje de programación

Frontend con HTML

base.html
<!DOCTYPE html>
<html lang="es">
<head>

26
 <meta charset="UTF-8">
<meta name="viewport" content="width=device-width,
initial-scale=1.0">
<title>Sistema de Ventas</title>
<link
href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/b
ootstrap.min.css" rel="stylesheet">
</head>
<body>
<div class="container py-4">
{% block content %}{% endblock %}
</div>
</body>
</html>

ventas.html

{% extends 'base.html' %}
{% block content %}
<h2 class="mb-4 text-center">Ventas y Detalles</h2>
<a href="/log" class="btn btn-secondary mb-3">Ver Log de
Eliminaciones</a>
<a href="/nueva" class="btn btn-success mb-3 float-end">Nueva
Venta</a>
<table class="table table-bordered">
<thead>
<tr>
<th>ID
Venta</th><th>Cliente</th><th>Fecha</th><th>Total</th><th>Acc
iones</th>
</tr>
</thead>
<tbody>
{% for venta in ventas %}
<tr>

27
 <td>{{ venta.id_venta }}</td>
<td>{{ venta.cliente }}</td>
<td>{{ venta.fecha }}</td>
<td>Bs. {{ venta.total }}</td>
<td>
<a href="/editar/{{ venta.id_venta }}"
class="btn btn-warning btn-sm">Editar</a>
<a href="/eliminar/{{ venta.id_venta }}"
class="btn btn-danger btn-sm" onclick="return
confirm('¿Eliminar esta venta?')">Eliminar</a>
</td>
</tr>
<tr>
<td colspan="5">
<strong>Detalle:</strong>
<ul>
{% for d in venta.detalles %}
<li>{{ d.producto }} x {{ d.cantidad
}} (Bs. {{ d.precio_unitario }})</li>
{% endfor %}
</ul>
</td>
</tr>
{% endfor %}
</tbody>
</table>
{% endblock %}

formulario.html

{% extends 'base.html' %}
{% block content %}
<h2>{{ 'Editar' if venta else 'Nueva' }} Venta</h2>
<form method="POST">
<div class="mb-3">
<label>Cliente:</label>

28
 <select name="id_cliente" class="form-select"
required>
{% for cliente in clientes %}
<option value="{{ cliente.id_cliente }}" {%
if venta and cliente.id_cliente == venta.id_cliente
%}selected{% endif %}>
{{ cliente.nombre }}
</option>
{% endfor %}
</select>
</div>
<h5>Productos:</h5>
{% for producto in productos %}
<div class="mb-2">
<label>{{ producto.nombre }} (Bs. {{
producto.precio }})</label>
<input type="number" name="producto_{{
producto.id_producto }}" class="form-control" min="0"
placeholder="Cantidad">
</div>
{% endfor %}
<button type="submit" class="btn
btn-primary">Guardar</button>
<a href="/" class="btn btn-secondary">Cancelar</a>
</form>
{% endblock %}

log.html

{% extends 'base.html' %}
{% block content %}
<h2>Log de Eliminaciones</h2>
<table class="table table-bordered">
<thead>
<tr>

29
 <th>ID</th>
<th>ID Venta</th>
<th>Fecha</th>
<th>Cliente</th>
<th>Total</th>
</tr>
</thead>
<tbody>
{% for log in logs %}
<tr>
<td>{{ log.id_log }}</td>
<td>{{ log.id_venta }}</td>
<td>{{ log.fecha }}</td>
<td>{{ log.cliente }}</td>
<td>Bs. {{ log.total }}</td>
</tr>
{% endfor %}
</tbody>
</table>
<a href="/" class="btn btn-secondary">Volver</a>
{% endblock %}

app.py

@app.route('/nueva', methods=['GET', 'POST'])

def nueva_venta():
conn = get_db_connection()
cur = conn.cursor()

if request.method == 'POST':
id_cliente = request.form['id_cliente']

# Construimos la lista de productos en formato JSON

cur.execute("SELECT id_producto, precio FROM
producto")

30
 productos_db = cur.fetchall()

productos = []
for p in productos_db:
cantidad =
int(request.form.get(f"producto_{p['id_producto']}", 0))
if cantidad > 0:
productos.append({
"id_producto": p['id_producto'],
"cantidad": cantidad,
"precio": float(p['precio'])
})

# Llamamos al procedimiento almacenado

cur.execute("CALL sp_registrar_venta(%s, %s)",
(id_cliente, json.dumps(productos)))
conn.commit()
cur.close()
conn.close()
return redirect('/')

# Obtener datos para mostrar en el formulario

cur.execute("SELECT * FROM cliente")
clientes = cur.fetchall()
cur.execute("SELECT * FROM producto")
productos = cur.fetchall()

cur.close()
conn.close()
return render_template('formulario.html',
clientes=clientes, productos=productos, venta=None)

@app.route('/eliminar/<int:id_venta>')
def eliminar_venta(id_venta):
conn = get_db_connection()
cur = conn.cursor()

31
 # Llamamos al procedimiento que eliminará la venta y
activará el trigger
cur.execute("CALL sp_eliminar_venta(%s)", (id_venta,))
conn.commit()
cur.close()
conn.close()
return redirect('/')

@app.route('/log')
def log():
conn = get_db_connection()
cur = conn.cursor()

cur.execute("""
SELECT
l.id_log,
l.id_venta,
l.fecha,
COALESCE(c.nombre, 'Cliente eliminado') AS
cliente,
l.total
FROM log_venta l
LEFT JOIN cliente c ON l.id_cliente = c.id_cliente
ORDER BY l.id_log DESC
""")

logs = cur.fetchall() # Ya son diccionarios

cur.close()
conn.close()
return render_template('log.html', logs=logs)

32
VI. RESULTADOS

6.1. Selección de datos

registrar una nueva venta

eliminar una venta

se eliminó el registro anterior​

respaldo de ventas eliminadas usando el trigger​

33
6.2. Resultados obtenidos
Reporte en la página

agregar una nueva venta

34
Eliminar registro de venta

respaldo de ventas eliminadas con el trigger que se activa al eliminar un registro

VII. CONCLUSIONES
Tras el desarrollo de la base de datos y del sistema web para la gestión de ventas de
productos de abarrotes, se pueden destacar las siguientes conclusiones:
●​ El diseño del sistema permite una gestión eficiente de ventas y del inventario,
automatizando tareas que anteriormente se realizaban manualmente.​

35
 ●​ La implementación de relaciones bien definidas entre las tablas garantiza la
integridad referencial de los datos, lo que permite mantener consistencia y
evitar errores en los registros.​

●​ Se ha incorporado un registro de eliminaciones de productos utilizando

triggers y procedimientos, por lo cual aporta un componente de auditoría y
trazabilidad fundamental para mantener un historial seguro de
modificaciones.​

●​ Gracias a la separación clara de responsabilidades entre entidades como

cliente, producto, venta y detalle_venta, se logra una estructura
flexible que permite futuras ampliaciones, como agregar reportes o
estadísticas.​

●​ Este sistema constituye una base sólida para la digitalización de negocios de

abarrotes, mejorando la atención al cliente, la precisión del stock y la rapidez
en el proceso de venta.

36
BIBLIOGRAFÍA

1.​ Elmasri, R., & Navathe, S. B. (2016).​

Fundamentos de Sistemas de Bases de Datos (7.ª ed.). Pearson.​
→ Referencia clásica sobre bases de datos relacionales, diseño ER, SQL,
integridad y normalización.​

2.​ Date, C. J. (2004).​

Introducción a los Sistemas de Bases de Datos (8.ª ed.). Addison-Wesley.​
→ Uno de los libros más sólidos para comprender teoría de bases de datos
relacionales.​

3.​ IEEE Xplore Digital Library​

https://ieeexplore.ieee.org​
→ Sitio académico para consultar investigaciones relacionadas con sistemas de
información, transformación digital y automatización de procesos en pymes.​

6.​ PostgreSQL Documentation​

https://www.postgresql.org/docs/​
→ Documentación oficial sobre procedimientos almacenados, funciones, triggers y
JSON.​

7.​ Scielo.org​
https://www.scielo.org/​
→ Biblioteca científica electrónica que puedes usar para buscar artículos sobre
automatización en comercios, bases de datos o digitalización de PYMES.​

8.​ ResearchGate​
https://www.researchgate.net/​
→ Artículos académicos sobre diseño e implementación de sistemas de ventas y
control de inventarios.

37