Integrantes:

o Carlos Eduardo Mercado Palacio

o Luis Santiago Canda Baldioseda

Docente: Ing. Ricardo Pérez

Fecha: 04 de Diciembre del 2024

Ingeniería en Sistemas.

Presentación de un Sistema de Bases de Datos para una Ferretería.

Objetivo general:

Crear una base de datos que pueda agilizar los procesos de

almacenamiento de datos y productos, garantizando así una correcta y segura
manipulación de estos.

Objetivos específicos:

 Diseñar el esquema lógico de la base de datos, definiendo tablas,

relaciones y atributos necesarios para garantizar un almacenamiento
eficiente y organizado de la información.

 Desarrollar consultas optimizadas que permitan la obtención de

información relevante de manera rápida y precisa.

 Implementar medidas de seguridad en la base de datos para garantizar la

integridad, confidencialidad y disponibilidad de la información
almacenada en ella.
 Planteamiento del problema

La creación de un diseño de base datos, para la gestión de inventarios

para la ferretería “El Progreso”, ubicada en Masatepe, del parque central, 1c y

½ al sur, busca agilizar los procesos de venta y almacenamiento de productos,

mejorando la eficiencia y precisión en la administración de los productos

disponibles en tienda. Actualmente, muchas ferreterías en el área enfrentan

dificultades relacionadas con la falta de visibilidad en tiempo real del stock, lo

que puede generar problemas como sobrestock (productos que no se venden a

tiempo, o son muy poco vendidos) o desabastecimiento (falta de productos

clave), lo cual impacta directamente en la satisfacción. del cliente y la

rentabilidad monetaria del negocio, siendo la primera la que impacta de mayor

manera en lo ámbito financiero. Una de los objetivos principales es ayudar a

mitigar problemas relacionados con la organización y almacenamiento de

información, optimizando el control de inventarios, proporcionando

información detallada y actualizada que permitirá una mejor toma de d-

ecisiones al momento de actuar en beneficio del negocio.

Uno de los aspectos más importantes del proyecto es su capacidad para

registrar múltiples atributos de los productos, tales como precios de compra y

venta, cantidades disponibles y el proveedor/es que puede poseer cada item.

Este nivel de detalle es crucial para ver la rentabilidad de cada artículo,

permitiendo a los administradores analizar los márgenes de ganancia y ajustar

las estrategias de venta en función de los costos. Además, al vincular cada

producto a un proveedor, la base de datos facilitará la gestión de relaciones

comerciales, proporcionando una visión clara de quién abastece a la ferretería

y permitiendo una reordenación de stock más eficiente y en el momento

adecuado.

Descripción de la estructura de la base de datos

Las entidades principales de la base de datos incluyen: Producto,

Cliente y Factura. La entidad Producto tiene como atributos: idProducto,

nombreProducto, precioCompra, precioVenta y Stock, estos atributos

permiten gestionar la información de los artículos disponibles en la tienda.

La entidad Cliente contiene atributos como: idCliente, nombreCliente y

contactoCliente. Dichos campos facilitaran el registro de los datos de todos

los clientes.

La entidad Factura tiene atributos: idFactura, fechaEmisión y

montoTotal, y está vinculada a una venta específica, funcionando como

comprobante oficial de la misma.

 El diseño de una base de datos para la gestión de inventarios propuesto

no solo permitirá un mayor control y seguimiento de los productos, sino que

además mejorará la eficiencia operativa, reducirá los riesgos asociados al mal

manejo de inventario y proporcionará información clave para la toma de

decisiones estratégicas. Además de agilizar los procesos de facturación al

tener información detallada del stock de cada producto para evitar errores de

facturación de productos inexistentes.

Entidades y atributos:
Relaciones:
Diagrama de Entidad-Relación simple

Diagrama relacionado en SQL

Diagrama MER
Producto – Proveedor (Muchos a Muchos)
(cantidadStock, idProveedor, idCategoria, nombreProducto, PrecioVenta, Precio real,
idproducto)

Factura – Cliente (Muchos a uno)

(idFactura, fechaFactura, montoTotal, idCliente)

Producto – Categoría (Uno a muchos)

(idProducto (FK), idCategoría(PK), nombreCategoría)

Producto – Factura (Muchos a Muchos)

(idFactura, idProducto, fechaFactura, montoTotal)

Normalización de la Base de Datos de una Ferretería

El proceso de normalización aplicado a las tablas de una base de datos para una ferretería.
El objetivo es organizar los datos de forma eficiente, eliminando redundancias y
asegurando la integridad de las relaciones entre tablas.

Análisis Inicial de las Tablas

La base de datos inicial consta de las siguientes tablas:
1. Productos:
Contiene información sobre los productos que se venden en la ferretería, incluyendo
su stock, precios y las categorías a las que pertenecen.
o Columnas: cantidadStock, idProveedor, idCategoria, nombreProducto,
precioVenta, precioReal, idProducto.
2. Factura:
Registra las facturas emitidas, con información básica como la fecha, el monto total
y el cliente.
o Columnas: idFactura, fechaFactura, montoTotal, idCliente.
3. Cliente:
Almacena los datos de los clientes que realizan compras.
o Columnas: nombreCliente, contactoCliente, idCliente, teléfonoCliente.
4. Proveedor:
Contiene los datos de los proveedores que abastecen la ferretería.
o Columnas: contactoProveedor, nombreProveedor, correoProveedor,
idProveedor.
5. Categoría:
Clasifica los productos según su tipo.
o Columnas: idCategoria, nombreCategoria.
Aunque estas tablas ya están organizadas, carecen de relaciones explícitas entre relaciones
de muchos a muchos
Primera Forma Normal (1NF)
La regla dice qué: “Cada celda de una tabla debe contener un único valor (datos
atómicos), y cada registro debe ser único.” En esta etapa se verifica que todas las tablas
cumplen con esta regla. Los datos son únicos y no hay celdas con valores múltiples.
Sin embargo, es necesario reestructurar algunas relaciones.

Segunda Forma Normal (2NF)

Acá, la regla dice que se debe cumplir con la 1NF y eliminar dependencias parciales.
“Cada columna debe depender completamente de la clave primaria.”
 En la tabla productos, la columna idProveedor representa una relación que no es
directa, ya que un producto puede ser suministrado por varios proveedores. Esto
sugiere la necesidad de una tabla intermedia.
Cambios realizados:
1. Eliminamos la columna idProveedor de la tabla productos.
2. Creamos una tabla intermedia llamada Producto_Abastecimiento para representar la
relación de muchos a muchos entre productos y proveedores.
Nueva tabla Producto_Abastecimiento:
| IDProducto | IDProveedor | cantidadEntrada | medidaProducto | fechaEntrada
 idProducto: Clave foránea hacia la tabla productos.
 idProveedor: Clave foránea hacia la tabla proveedores.
 cantidadEntrada: Mínimo de unidades que el proveedor puede suministrar.
 medidaProducto: El tipo medida en la cual se abastece los productos
 fechaEntrada: Fecha en la cuál se recibieron los productos

Aplicación de la Tercera Forma Normal (3NF)

Regla: Cumplir con la 2NF y “eliminar dependencias transitivas, es decir, los atributos
no clave deben depender únicamente de la clave primaria.”
En la tabla factura, identificamos la necesidad de una relación entre facturas y productos.
Para resolverlo, añadimos una tabla intermedia que permita detallar cada producto incluido
en una factura.
Cambios realizados:
1. La tabla factura ahora solo contiene información básica de la factura.
2. Se crea la tabla detalleFactura para detallar los productos y cantidades de cada
factura.
Nueva tabla detalleFactura:
IDFactura | IDProducto | cantidadSalida | SubTotal |

Paso 5: Estructura Final Normalizada

1. Productos:
o Columnas: idProducto, nombreProducto, cantidadStock, precioVenta,
precioReal, idCategoria.
2. Proveedor:
o Columnas: idProveedor, nombreProveedor, contactoProveedor,
correoProveedor.
3. Producto_Abastecimiento:
o Columnas: idProducto, idProveedor, precioCompra, cantidadMinima.
4. Factura:
 o Columnas: idFactura, fechaFactura, montoTotal, idCliente.
5. DetalleFactura:
o Columnas: idDetalle, idFactura, idProducto, cantidad, precioUnitario,
subTotal.
6. Cliente:
o Columnas: idCliente, nombreCliente, contactoCliente, teléfonoCliente.
7. Categoría:
o Columnas: idCategoria, nombreCategoria.

Relaciones Finales
1. Productos ↔ Categoría: Relación de muchos a uno. Un producto pertenece a una
categoría.
2. Productos ↔ Proveedores (Producto_Abastecimiento): Relación de muchos a
muchos modelada mediante Producto_Abastecimiento.
3. Factura ↔ Cliente: Relación de muchos a uno. Una factura pertenece a un cliente.
4. Factura ↔ Productos (DetalleFactura): Relación de muchos a muchos modelada
mediante DetalleFactura.

Con las tablas “Producto_Abastecimiento” y “Detalle_Venta”, logramos modelar la

relación de muchos a muchos entre productos-proveedores y clientes y factura. Esto, junto
con las demás modificaciones permite:
1. Eliminar redundancias en las tablas.
2. Representar relaciones.
3. Facilitar consultas.
 Diccionario de datos

Productos

Llave Nombre Tipo Tamaño Restricciones Descripción Ejemplo

Llave Almacena el ID
PK idProducto nchar 10 principal, no del producto 48837
nulo
Almacena la
cantidadStock float No nulo cantidad que 57
existe de cada
producto
Guarda el
idProveedor nchar 10 No nulo código de cada Ferretería
uno de los Jenny
proveedores

Llave Almacena el
FK idCategoría nchar 10 foránea. No código de cada 001
nulo una de las
categorías
existentes
Almacena el
nombreProducto nvarchar 50 No nulo nombre de cada Clavo
producto Corriente

Almacena el
precioVenta float No nulo precio de venta 1.5
al cliente
Guarda el precio
precioReal float No nulo real del 1
producto antes
de ajustes
 Proveedores

Llave Nombre Tipo Tamaño Restricciones Descripción Ejemplo

Almacena el
contactoProveedor nvarchar 50 No nulo número del 59885068
proveedor
Almacena el
nombreProveedor nvarchar 50 No nulo Nombre de cada Modelo S.A
proveedor
Guarda el correo
correoProveedor nvarchar 50 Opcional, no de PinturasModelo@
nulo contacto/soporte [Link]
de cada
proveedor

Llave Almacena el
PK idProveedor nchar 10 principal, no código de cada 78362-992
nulo uno de los
proveedores

Factura

Llave Nombre Tipo Tamaño Restricciones Descripción Ejemplo

Llave Almacena id
PK idFactura nchar 10 primaria, no de cada 374334
nulo Factura
Almacena la
fechaFactura nchar 10 No nulo fecha de la 20-09-2024
factura
Almacena el
montoTotal float -- No nulo monto total 899.50
Almacena el
FK idCliente nchar 10 Llave código de 9899
foránea , no cada uno de
nulo los clientes
 Cliente

Llave Nombre Tipo Tamaño Restricciones Descripción Ejemplo

Llave primaria, Almacena el id de
PK idCliente nchar 10 no nulo cada cliente 011172
Almacena el correo
contactoCliente nchar 10 Opcional de cada cliente Null
Guarda el nombre
nombreCliente float -- No nulo del cliente Betania
Almacena el
teléfonoCliente nchar 10 Llave foránea número de cada 85217774
cliente

Categoría

Llave Nombre Tipo Tamaño Restricciones Descripción Ejemplo

Llave Primaria, Almacena el

PK idCategoría nchar 10 no nulo código de cada 001
categoría
Contiene el
nombreCategoría nvarchar 50 No nulo nombre de la Carpintería
categoría

Consultas básicas para ver tablas y columnas:

select * from Productos // Permite ver todas la columnas de la tabla

select idProducto, idCategoria, precioReal from Productos // Permite ver

columnas seleccionadas mediante el “Select”

SELECT COLUMN_NAME, DATA_TYPE

FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'productos'; // Permite ver el nombre de la tabla y
los tipos de datos de cada columna.

Saber cuántos registros hay en una tabla específica, por ejemplo, en la tabla
productos:
SELECT COUNT(*)
FROM productos;
Explicación: COUNT(*) cuenta todos los registros (filas) de la tabla
productos.

Obtener Todos los Registros de una Tabla

Ver todos los registros de la tabla productos:
SELECT * FROM productos;
Explicación: SELECT * selecciona todas las columnas de todos los registros
en la tabla productos. El * significa "todo".

Filtrar Registros con Condiciones

Obtener los productos cuyo precio real sea mayor a 100:
SELECT nombreProducto, PrecioReal
FROM productos
WHERE PrecioReal > 100;
Explicación: WHERE PrecioReal > 100 filtra los registros para que solo se
muestren los productos con un precio real mayor a 100.

Agregar Nuevos Registros

Agregar un nuevo producto a la tabla productos,
INSERT INTO productos (nombreProducto, PrecioVenta, PrecioReal,
cantidadStock, idProveedor, idCategoria)
VALUES ('Producto X', 150, 120, 50, 1, 2);
Explicación: INSERT INTO agrega un nuevo registro a la tabla productos. Se
especifican los valores de cada columna entre paréntesis.

Eliminar un Registro
Eliminar un producto específico de la tabla:
DELETE FROM productos
WHERE idProducto = 1;
Explicación: DELETE FROM elimina un registro de la tabla. En este caso,
eliminamos el producto con idProducto = 1.

Conclusiones
La creación de un diseño de una Base de datos para “Ferretería El Progreso”
busca satisfacer las necesidades o problemas más comunes que pueden llegar
a tener este tipo de negocios, por ejemplo, la nula visibilidad en tiempo real de
la cantidad de productos que hay en existencia en determinados momentos y
quienes son los responsables de suministrar dichos productos.

Creemos que este diseño puede ayudar a corregir errores comerciales y

financieros, colaborando así mismo en una buena planificación a futuro
respectos a los elementos a surtir en el Negocio, aspectos importantes como la
implementación de apartados como guardar el correo y números telefónicos de
contacto para la consultas o servicios varios, esperamos que sean de mucha
utilidad para el Negocio.

Sin embargo, esta no será la etapa final del proyecto propuesto, si bien,
tenemos una estructura lo suficientemente sólida para un negocio de tal
Magnitud, seguiremos trabajando para añadir funciones que actúen en Pro del
mismo, ya sea por medio de actualizaciones al sistema lógico o un apartado de
facturación a futuro, que esté conectado directamente a la base de datos con el
propósito de optimizar aún más este proyecto.