Diseñar Base De Datos De Un

Sistema De Facturación
James Revelo Julio 24, 2014
Los Sistemas de facturación están en la mayoría de Tiendas,
Supermercados, Almacenes, y otras Organizaciones comerciales, para Optimizar
el Proceso de Venta y los Reportes de flujo de ingresos. Este tipo de sistemas se
caracterizan por almacenar los datos de los clientes que compran en la empresa, emitir
facturas generadas en base a la cantidad de productos que han sido comprados por los
clientes, manejar inventarios y muchas funciones mas.
En este artículo estudiaremos el diseño de una base de datos para un sistema de facturación,
a través de un enfoque generalizado. Veremos que entidades, atributos y relaciones existen
y como normalizar las anomalías ocurrentes.

DISEÑO DE LA BASE DE DATOS

La primera tarea es identificar todas las entidades posibles que vayan a intervenir en el
proceso de facturación de la empresa. Normalmente estas entidades ya están definidas
previamente en el Modelo de datos para la elaboración de los Componentes de Software.
También puedes explorar en los Requerimientos funcionales, Historias de
usuario, Reglas de negocio, el Formato de las Facturas emitidas, los Diseños de
formularios y Reportes.
A continuación te 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ónicode los clientes de la compañía.
 Registrar para los productos la siguiente información: Código, Nombre, Precio, 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óndel 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 articulo usaremos 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 ves en el detalle(Recuadro ROJO) se encuentra una tabla que muestra que
productos han sido comprados por el cliente en esta ocasión, la cual representa la relación de
factura y producto.
Recuerda 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. Ademas 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 como 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

1 101 SDA 2 3

2 101 SDB 3 5

1 102 SDA 1 3

1 103 SDC 4 7
Fíjate 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É ESTA EL PRECIO DEL

PRODUCTO EN DETALLE Y EN
PRODUCTO AL MISMO TIEMPO?
A primera impresión parece redundancia de datos al extremo, pero hay un secreto
escondido. La razón por la cual indujimos esta redundancia fue por que los precios de los
productos varían en el mercado.
¿Importante?…
¡Claro!, imagina que un Almacén de Ropa está vendiendo la camisa de la selección de
Fútbol en 10USD. Debido a que al equipo le está yendo muy bien en los últimos
partidos, muchas personas vienen a comprar la camisa. Al dueño se le ocurre subir a 12USD
el precio de la camisa, ya que la demanda así lo está imponiendo.
Al final de mes la Tienda de Ropa ejecuta un reporte para ver el ingreso total por ventas,
donde se muestra que la cantidad de dinero contado no coincide con el valor del sistema.
¿Que pasó?
Miremos algunos cálculos pretenciosos antes y después del cambio de precio:

Antes de la manifestación aumentada de demanda

Precio = 10USD

Unidades vendidas = 200

Ingresos por ventas esperados = 2000USD

Después de la manifestación aumentada de demanda

Precio = 12USD

Unidades vendidas = 250

Ingresos por ventas esperados = 3000USD

Ingresos por ventas totales esperados = 5000USD

Los resultados anteriores serían los resultados ideales, pero al no incluir el precio del artículo
en la tabla DETALLE, sucederá lo siguiente a la hora de calcular los ingresos totales:
Cálculo de los ingresos con el precio actual

ARTICULO.precio = 12USD

Unidades vendidas = 450

Ingresos totales por ventas = 450 x 12USD = 5400USD

¡Son 400USD de más!, es decir, tu Software está produciendo un error del 8% en el ingreso
total por ventas. Algo desastroso para tu reputación. Al no incluir este atributo has calculado
los ingresos con el precio actual que refleja ARTICULO.precio, por lo cual todas las
unidades valen lo mismo.
No obstante, si incluyes el precio en DETALLE sucederá lo siguiente:
Calculo de los ingresos con el precio de la ocasión

DETALLE.precio= 10USD

Unidades vendidas =200

Ingresos parciales por venta = 2000USD

 DETALLE.precio = 12USD

Unidades vendidas = 350

Ingresos parciales por venta = 3000USD

Ingresos totales por ventas = 5000USD

Con esta redundancia inducida puedes tener el cálculo exacto para cada producto en el
momento actual, porque DETALLE cumple la función de mantener el mismo estado para
cada renglón en la factura a lo largo del tiempo.

¿AMIGO Y POR QUÉ SUBTOTAL 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

ATRIBUTOS MULTIVALUADOS
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

 SDA X-box 360 500 100 TECNO

SDB Caja de huevos 5 230 COMIDA

SDC Aceite de girasol 6 219 COMIDA

SDD Coca-cola 200ml 2,3 341 BEBIDA

De los 4 hay 2 que repiten la categoría COMIDA. ¿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 ‘COMIDA‘.
 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
ya sabes que debes 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

SDA X-box 360 500 100 1

SDB Caja de huevos 5 230 2

SDC Aceite de girasol 6 219 2

SDD Coca-cola 200ml 2,3 341 3

id_categoría nombre

1 TECNO

2 COMIDA

3 BEBIDA
Ahora veamos nuestro diagrama:
PAGOS EN LA BASE DE DATOS DEL
SISTEMA