Diseñar la base de datos de un “Sistema de facturación”

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ónico de los clientes de la compañía.
Registrar para los productos la información de 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ó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 en 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
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:
Entidad relación, CLIENTE, FACTURA, PRODUCTO
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.
Ejemplo de una Factura
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:
Entidad relación, CLIENTE, FACTURA, DETALLE, PRODUCTO
 
¿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.
¿Es importante?… ¡Claro!.
Imagina que un Almacén de Ropa está vendiendo la camisa de la selección de Fútbol en 10 USD. 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 12 USD 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  = 10 USD
Unidades vendidas = 200
Ingresos por ventas esperados = 2000 USD
Después de la manifestación aumentada de demanda
Precio = 12 USD
Unidades vendidas = 250
Ingresos por ventas esperados = 3000 USD
Ingresos por ventas totales esperados = 5000 USD

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
Precio = 12 USD
Unidades vendidas = 450
Ingresos totales por ventas = 450 x 12 USD = 5400 USD

¡Son 400 USD 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 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
Precio = 10 USD
Unidades vendidas =200
Ingresos parciales por venta = 2000 USD
Precio = 12 USD
Unidades vendidas = 350
Ingresos parciales por venta = 3000 USD
Ingresos totales por venta = 5000 USD

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.
 
¿Por qué esta el precio del producto en DETALLE y en PRODUCTO al mismo tiempo?
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:
Relación entre cliente, factura y productos

Volver al menú de Informática Volver a Inicio

Anuncios