DESARROLLO DE APLICACIONES CON BASE DE DATOS

Los Sistemas de facturacin estn en la mayora 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 artculo estudiaremos el diseo de una base de datos para un sistema de

facturacin, a travs de un enfoque generalizado. Veremos que entidades, atributos y
relaciones existen y como normalizar las anomalas ocurrentes.

Diseo de la Base de Datos

La primera tarea es identificar todas las entidades posibles que vayan a intervenir en el
proceso de facturacin de la empresa. Normalmente estas entidades ya estn definidas
previamente en el Modelo de datos para la elaboracin de los Componentes de
Software.

Tambin puedes explorar en los Requerimientos funcionales, Historias de usuario,

Reglas de negocio, el Formato de las Facturas emitidas, los Diseos de formularios
y Reportes.

A continuacin te mostrar algunas recopilaciones descriptivas para modelar la base de

datos:

Registrar el Id, Nombre, Apellido, Direccin, Fecha de nacimiento, Telfono

y el Correo electrnico de los clientes de la compaa.
Registrar para los productos la siguiente informacin: Cdigo, Nombre, Precio,
Nmero de Existencias y Categora a la que pertenece.
Se debe especificar en la factura los Datos del cliente y una tabla que muestre la
Especificacin 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
crdito, Tarjeta dbito, Paypal y Neteller.
Un cliente puede generar varias facturas debido a sus distintas compras, pero
jams una misma factura podr haber sido generada por ms de un cliente.
En una factura pueden contener varios productos vinculados, al igual que todos
los productos estn posibilitados a aparecer en todas las facturas.
Un cliente puede pagar el monto total de una factura con varios mtodos de pago.

Estas condiciones pueden cambiar dependiendo de las necesidades del cliente, ya que
pueden variar sus procesos de facturacin o aadir ms atributos relevantes para ellos.
Pero para los objetivos de este articulo usaremos solo las caractersticas esenciales.
Crear el Modelo Relacional a partir de los
Requerimientos
Bueno, es sencillo pensar en que primero estn las personas que dan vida al negocio, es
decir, la entidad CLIENTE. Luego viene la satisfaccin de las necesidades del cliente a
travs del PRODUCTO. Y tambin es necesario entregar una FACTURA para constatar
la entrega del producto.

Por el momento CLIENTE, FACTURA y PRODUCTO son las entidades ms

relevantes, cuya informacin debe ser almacenada en la base de datos. Veamos el
Diagrama Relacional preliminar para comprender este caso:

He puesto los signos de interrogacin en las llaves forneas de FACTURA y

PRODUCTO debido a que esta relacin muchos a muchos es compleja. Para entenderla
quiero mostrarte las partes de una factura con un sencillo diseo perteneciente a una
Tienda de artculos para Computadoras.

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

caracterstica 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 ocasin, la cual
representa la relacin de factura y producto.
Recuerda que cuando se presenta una relacin muchos a muchos debemos reemplazar
esa relacin por una tabla intermediaria que reciba las claves principales de ambas
tablas referenciadas. Ademas de eso, las tablas originales deben tener una relacin uno a
muchos con la tabla intermedia. Esto permite optimizar y normalizar los datos.

As que crearemos una nueva tabla llamada DETALLE en alusin a cada rengln
detallado en la factura. Veamos como quedara 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 rpidamente a que nos referimos. Algo que
visualmente podra ser poco intuitivo de notar con la otra llave candidata.

Considera el siguiente ejemplo de una Tienda de Artculos de Deporte. A continuacin

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

Fjate que en la factura 101 podemos distinguir que el primer item registrado es el
producto con cdigo SDA, ya que num_detalle es igual a 1. Y que el producto con
cdigo SDB esta ubicado en el segundo rengln detallado de la factura.

Si la clave primaria fuera id_factura + id_producto no tendramos 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 impresin parece redundancia de datos al extremo, pero hay un secreto
escondido. La razn por la cual indujimos esta redundancia fue por que los precios de
los productos varan en el mercado.
Importante?

Claro!, imagina que un Almacn de Ropa est vendiendo la camisa de la seleccin de

Ftbol en 10USD. Debido a que al equipo le est yendo muy bien en los ltimos
partidos, muchas personas vienen a comprar la camisa. Al dueo 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 clculos pretenciosos antes y despus del cambio de precio:

Antes de la manifestacin aumentada de demanda

Precio = 10USD
Unidades vendidas = 200
Ingresos por ventas esperados = 2000USD
Despus de la manifestacin aumentada de demanda
Precio = 12USD
Unidades vendidas = 250
Ingresos por ventas esperados = 3000USD

Ingresos por ventas totales esperados = 5000USD

Los resultados anteriores seran los resultados ideales, pero al no incluir el precio del
artculo en la tabla DETALLE, suceder lo siguiente a la hora de calcular los ingresos
totales:

Clculo de los ingresos con el precio actual

ARTICULO.precio = 12USD
Unidades vendidas = 450
Ingresos totales por ventas = 450 x 12USD = 5400USD

Son 400USD de ms!, es decir, tu Software est produciendo un error del 8% en el

ingreso total por ventas. Algo desastroso para tu reputacin. 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 ocasin
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 clculo exacto para cada producto en el
momento actual, porque DETALLE cumple la funcin de mantener el mismo estado para
cada rengln 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 travs del precio del
producto y la cantidad cuando queramos. Guardarlos en nuestra base de datos sera
espacio de almacenamiento adicional.

En cambio, si realizamos los clculos en tiempo real, a nuestra aplicacin solo le tomara
un pequeo instante de tiempo que no interferira 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 categora de la entidad PRODUCTO es poco eficiente.
Esto se debe a que la categora se repetir un sinnmero de veces por todos los registros
que tengamos(redundancia).

Veamos un ejemplo con los productos de un Supermercado:

id_producto nombre precio stock categora

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 categora COMIDA. Que tal si hubiesen 1000 productos?,
la cantidad de espacio usado para almacenar VARCHARS repetidos sera muy grande.

La solucin es sencilla, expandiremos nuestro diagrama para quitar el atributo categora

de la entidad PRODUCTO y agregaremos una nueva tabla llamada CATEGORIA. Esta
modificacin aadir una relacin uno a muchos entre producto y categora, por lo cual
incluiramos la llave fornea de categora.

Ventajas?

Mayor claridad e integridad en la base de datos

Economizar espacio en disco. Rinde mejor el valor de una llave fornea 1 que
el nombre de la categora COMIDA.
Aadir nuevos atributos como por ejemplo la descripcin de la categora.
Facilidad en la consulta de productos por categora y eleccin de nuevas mtricas.

Si el cliente decidiera que sus productos pueden pertenecer a ms de una categora,

entonces ya sabes que debes crear una tabla intermedia por la relacin muchos a muchos
que se genera.

Con la solucin implementada, las tablas quedaran as:

id_producto nombre precio stock id_categora

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_categora nombre
1 TECNO
2 COMIDA
3 BEBIDA

Ahora veamos nuestro diagrama:

Pagos en la Base de Datos del Sistema de Facturacin

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 Mtodo de pago que se us, ya sea efectivo, tarjeta de dbito, etc.

Cuando un Sistema de facturacin acepta varias formas de pago electrnico, es

necesario realizar una investigacin sobre bases de datos e-Commerce. Esta
caracterstica expande ms el concepto de pagos, generado nuevas tablas y relaciones en
el modelo, lo cual queda en tus manos si te encuentras en esa situacin.

Es importante tener en cuenta la forma en que se realizarn 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. Tambin 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 Envo del producto.

En mi caso eleg una forma muy sencilla de pago para terminar este articulo, donde el
negocio recibe un pago por los productos de la factura y puede usar varios mtodos de
pago:

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