MODELO ENTIDAD RELACIÓN – FERRETERÍA TUERCAS Y

ALGO MÁS…
Específicamente la sección de la BD que relaciona las tablas con las entidades que
intervienen en la consulta del historial de compras de los clientes para entonces aplicar
el descuento de la promoción para aquellos que más compras realicen.

Precio_venta
Descuento
El modelo E-R anterior, lo diseñé para hacer claridad en que dependiendo de la complejidad de las tareas que se quieran sistematizar, así será el
tamaño de la Base de Datos, es decir, llevará su diseño más tablas relacionadas.
 DISEÑO DE LA BASE DE DATOS: FERRETERÍA TUERCAS Y
ALGO MÁS…

La primero que hay que hacer, es identificar todas las entidades posibles que vayan a
intervenir en el proceso de facturación de la ferretería. A continuación mostraré algunas
recopilaciones descriptivas para modelar la base de datos:
 Registrar el Id, Nombre, Apellido, Dirección, Fecha de nacimiento, Teléfono y el Correo
electrónico de los clientes de la ferretería
 Registrar para los productos la siguiente información: Código, Nombre, Precio compra,
precio venta, Número de Existencias y Categoría a la que pertenece.
 Se debe especificar en la factura los Datos del cliente y una tabla que muestre
la Especificación del tipo de producto comprado, su precio, la cantidad suministrada y
el total parcial. Al final de la factura debe calcularse el valor antes de impuestos y
descuentos, y luego calcular el valor total de la compra.
 Un cliente puede pagar con las siguientes formas de pago: Efectivo, Tarjeta de
crédito, Tarjeta débito, Paypal y Neteller.
 Un cliente puede generar varias facturas debido a sus distintas compras, pero jamás una
misma factura podrá haber sido generada por más de un cliente.
 En una factura pueden contener varios productos vinculados, al igual que todos los
productos están posibilitados a aparecer en todas las facturas.
 Un cliente puede pagar el monto total de una factura con varios métodos de pago.
 …
Estas condiciones pueden cambiar dependiendo de las necesidades del cliente, ya que
pueden variar sus procesos de facturación o añadir más atributos relevantes para ellos. Pero
para los objetivos de este trabajo usaré solo las características esenciales.

CREAR EL MODELO RELACIONAL A PARTIR DE LOS

REQUERIMIENTOS
Bueno, es sencillo pensar en que primero están las personas que dan vida al negocio, es
decir, la entidad CLIENTE. Luego viene la satisfacción de las necesidades del cliente a través
del PRODUCTO. Y también es necesario entregar una FACTURA para constatar la entrega
del producto.
Por el momento CLIENTE, FACTURA y PRODUCTO son las entidades más relevantes, cuya
información debe ser almacenada en la base de datos. Veamos el Diagrama
Relacional preliminar para comprender este caso:
He puesto los signos de interrogación en las llaves foráneas
de FACTURA y PRODUCTO debido a que esta relación muchos a muchos es compleja. Para
entenderla quiero mostrarte las partes de una factura con un sencillo diseño perteneciente
a una Tienda de artículos para Computadoras.

La cabecera de la factura(Recuadro AMARILLO) contiene los datos del cliente y las

característica de la factura. Al final(Recuadro AZUL) se obtiene el resultado total de toda la
compra. Como muestro en el detalle(Recuadro ROJO) se encuentra una tabla que muestra
qué productos han sido comprados por el cliente en esta ocasión, la cual representa la
relación de factura y producto.
Hay que recordar que cuando se presenta una relación muchos a muchos
debemos reemplazar esa relación por una tabla intermediaria que reciba las claves
principales de ambas tablas referenciadas. Además de eso, las tablas originales deben tener
una relación uno a muchos con la tabla intermedia. Esto permite optimizar y normalizar los
datos.
Así que crearemos una nueva tabla llamada DETALLE en alusión a cada renglón detallado
en la factura. Veamos cómo quedaría el diagrama ahora:
¿POR QUÉ SE USA LA LLAVE COMPUESTA PK= {ID_FACTURA,
NUM_DETALLE} EN VEZ DE PK= {ID_FACTURA,
ID_PRODUCTO}?
Para diferenciar el orden de los items en la factura. Es decir, que al declarar “El tercer
producto de la factura N” podamos entender rápidamente a que nos referimos. Algo que
visualmente podría ser poco intuitivo de notar con la otra llave candidata.
Considera el siguiente ejemplo de una Tienda de Artículos de Deporte. A continuación se
muestra la tabla DETALLE con tres facturas distintas:
num_detalle id_factura id_producto cantidad Precio_venta

1 101 SDA 2 3000

2 101 SDB 3 5000

1 102 SDA 1 3000

1 103 SDC 4 7000

Analicemos que en la factura 101 podemos distinguir que el primer item registrado es el
producto con código “SDA“, ya que num_detalle es igual a 1. Y que el producto con código
“SDB” esta ubicado en el segundo renglón detallado de la factura.
Si la clave primaria fuera id_factura + id_producto no tendríamos claro el orden de los
productos comprados. Es por eso que agregar el atributo num_detalle es tan beneficioso
para nosotros.
 ¿POR QUÉ SUBTOTAL, IVA Y TOTAL NO SON ATRIBUTOS DE
FACTURA?

Porque son atributos derivados. Es decir, podemos calcularlos a través del precio del
producto y la cantidad cuando queramos. Guardarlos en nuestra base de datos sería
espacio de almacenamiento adicional.
En cambio, si realizamos los cálculos en tiempo real, a nuestra aplicación solo le tomaría un
pequeño instante de tiempo que no interferiría con la velocidad de nuestro Software
Comercial. Es un sacrificio de tiempo vs memoria muy efectivo.

CREAR TABLAS AISLADAS PARA ALGUNOS ATRIBUTOS

Darnos cuenta que el atributo categoría de la entidad PRODUCTO es poco eficiente. Esto se
debe a que la categoría se repetirá un sinnúmero de veces por todos los registros que
tengamos (redundancia).
Veamos un ejemplo con los productos de un Supermercado:

id_producto nombre precio stock categoría

10011 Cemento Ultracem 25000 100 CONSTRUCION

10012 Cuñete Estuco SIKA 33000 230 CONSTRUCION

40023 Cbo SANIT. corona verde 230000 219 BAÑO

87451 Cuñete de Pintura Gris T1 200000 341 PINTURA

De los 4 hay 2 que repiten la categoría CONSTRUCCIÓN. ¿Que tal si hubiesen 1000
productos?, la cantidad de espacio usado para almacenar VARCHARS repetidos sería muy
grande.
La solución es sencilla, expandiremos nuestro diagrama para quitar el atributo categoría de
la entidad PRODUCTO y agregaremos una nueva tabla llamada CATEGORIA. Esta
modificación añadirá una relación uno a muchos entre producto y categoría, por lo cual
incluiríamos la llave foránea de categoría.
¿Ventajas?
 Mayor claridad e integridad en la base de datos
 Economizar espacio en disco. Rinde mejor el valor de una llave foránea ‘1‘ que el nombre
de la categoría ‘CONSTRUCCION‘.
 Añadir nuevos atributos como por ejemplo la descripción de la categoría.
 Facilidad en la consulta de productos por categoría y elección de nuevas métricas.
Si el cliente decidiera que sus productos pueden pertenecer a más de una categoría,
entonces se debe crear una tabla intermedia por la relación muchos a muchos que se
genera.

Con la solución implementada, las tablas quedarían así:

id_producto nombre precio stock id_categoría

10011 Cemento Ultracem 25000 100 1

10012 Cuñete Estuco SIKA 33000 230 1

40023 Cbo SANIT. corona verde 230000 219 2

87451 Cuñete de Pintura Gris T1 200000 341 3

id_categoría nombre

1 CONSTRUCCION

2 BAÑO

3 PINTURA
El modelo E-R quedaría así:
PAGOS EN LA BASE DE DATOS DEL SISTEMA DE
FACTURACIÓN

No entraré en muchos detalles sobre la tabla PAGO ya que este tema es muy
extenso. Inicialmente podemos considerar datos como Fecha del pago, el Monto pagado y
el Método de pago que se usó, ya sea efectivo, tarjeta de débito, etc.
Cuando un Sistema de facturación acepta varias formas de pago electrónico, es necesario
realizar una investigación sobre bases de datos e-Commerce. Esta característica expande
más el concepto de pagos, generado nuevas tablas y relaciones en el modelo, lo cual queda
a criterio de nosotros los aprendices si deseamos profundizar en esto.
Es importante tener en cuenta la forma en que se realizarán los pagos, ya que hay negocios
donde la factura debe pagarse en un solo pago, otros donde se debe hacer un solo pago
pero divido en porcentajes con diferentes formas de pago. También existen acuerdos donde
abonas un poco al inicio y en otra fecha pagas el valor restante.

O en el caso de las compras por Internet, se debe generar una Orden que sincronice
la Cuenta del cliente, sus Pagos y el Envío del producto.
En mi caso elegí una forma muy sencilla de pago, donde el negocio recibe un pago por los
productos de la factura y puede usar varios métodos de pago:

Podemos notar que un cliente tiene posibilitado pagar con varias formas de pago su
compra, por lo cual creamos una relación uno a muchos entre MODO_PAGO y la factura.

Webgrafía de ayuda:
http://www.hermosaprogramacion.com/2014/07/sistema-facturacion-base-datos

Trbajao realizado por: Jesús Torrealba Castro – Cel. 321 5491075