Reflejando la Organización en la Base de

Datos
Las Bases de Datos Relacionales almacenan y recuperan los datos de los
documentos comerciales (Facturas, Remitos y otros) como de gestión (informes,
listados u otros), en un conjunto de tablas. La novedad en este tipo de Base de Datos
es que las tablas son similares a planillas de cálculo. En términos más específicos,
cada tabla es un archivo o fichero plano que enlazados entre sí conforman la Base
de Datos.
¿Por qué se divide un documento comercial en varias tablas? Si bien existe un
modelo descriptivo, se recurre a una metáfora para su exposición. Dicha metáfora
puede enunciarse como: las tablas de una Base de Datos son los sellos virtuales de
tipos móviles de las Oficinas Modernas. A continuación se explica dicha metáfora.
Un comerciante, imaginariamente, tiene 3 clientes y vende 2 productos, con
una alta rotación de estos últimos. Como prueba de cada una de sus ventas, “emite
manualmente” las Facturas. ¿Qué significa “emite manualmente”? Cada cierto período
de tiempo recibe de la imprenta un formulario en donde están previamente impresos
los nombres de los datos (casilleros) que debe recolectar en cada venta. En otras
palabras, en el formulario aparece “Nombre del Cliente” o “Descripción mercadería” o
“fecha”, entre otros. En un primer momento, rellena cada casilla (que tiene el nombre
del dato) con los valores específicos de cada venta. Estos últimos, se los denomina
valores de datos. Con el tiempo, de tanto escribir los valores de los datos (Santiago
Pérez o ‘Producto A’ o 12/02/2020) el comerciante advierte que estos se repiten con
distinta frecuencia unos de otros.
Como tiene 3 clientes y vende 2 productos, se tienen 9 posibles “tipos de
facturas” o combinaciones “Cliente compra Producto”: Cliente 1 Producto A, Cliente1
Producto B, Cliente1 Producto A y B; Cliente 2 Producto A, Cliente2 Producto B, Cliente 2
Producto A y B; Cliente3 Producto A, Cliente3 Producto B, Cliente3 Producto A y B. Una
posible alternativa sería tener las facturas preparadas para cuando concurriese el
cliente al local. Esto implicaría “predecir” cuándo comprarán nuestros clientes, qué
combinación de productos y la cantidad respectiva. Y ese es tema de la Inteligencia
de Negocio… (El software RapidMiner ofrece un modelo interesante sobre esta
temática: Market Basket Analysis).
¿Qué solución rápida le encuentra el Comerciante? Bien, como
hipotéticamente tiene tres clientes y dos productos; recurre a los sellos para estampar
los valores de datos. Tiene 3 sellos con los valores de cada cliente, 2 sellos con los
datos de sus productos, un sello fechador; quedando la cantidad, importe y Total para
el relleno manual. Por consiguiente, ante una venta, comienza una “serie de
estampados” de sellos y reduce el tiempo considerablemente. En otras palabras, sólo
“pierde” tiempo con los valores calculados: importe y total, y, la Cantidad ha vender.
Luego, aparecen los problemas: se enreda con los sellos. Ante esta situación, nota
que en el sello fechador los valores “rotan” en el mismo sello. A este tipo de sello se lo
denomina “sello de tipos móviles”. Acrecentando la imaginación, el comerciante reduce
el número de sellos: uno para los clientes y otro para los productos, cada uno de los
anteriores es un sello con tipos móviles.
Si el comerciante pasara a la emisión digital de sus comprobantes, cada sello
de tipos móviles se convertirían en tablas de una base de datos relacional. Como las
tablas son similares a planillas de cálculo, las filas son los registros o los sellos de
tipos fijos (el comerciante tenía tres sellos para sus tres clientes) en donde se guardan
los valores de datos. En las columnas o campos son los “casilleros” anteriores que
contienen los nombres de datos. El formulario previamente impreso también es una
tabla, se identificaría como otro “gran sello”.
¿Cómo se vinculan las tablas? En el caso hipotético, es el comerciante quien
coordinaba los estampados en el formulario. La relación de las tablas “guardan” la
misma lógica que en la transacción que representan cada una de estas. En una
Factura, ¿cuántos clientes se “registran”? uno y solo uno, Persona Humana o Jurídica
pero uno solo. Entonces, la relación entre Factura y Cliente es 1. Por otro lado, a los
clientes ¿cuántas facturas pueden emitírseles? Tantas como las ventas que se le
efectúen, el fin de lucro estipula que sean las máximas posibles. Esto significa que la
relación entre Cliente y Factura es varias/muchas. De esta manera, entre las tablas
Factura y Cliente existe una cardinalidad de “uno a varios”. La cardinalidad resume las
relaciones de las permutaciones matemáticas: Factura-Cliente y Cliente-Factura.
Por otro lado, una Factura ¿Cuántos productos puede contener? Desde el lado
del Comerciante, la mayor cantidad y variedad posible; entre Factura y Producto hay
una relación de muchos o varios. Un tipo de producto, ¿cuántas veces puede
facturarse? Para aumentar la rentabilidad, el comerciante aspira a la máxima rotación
de productos. Entre Producto y Factura existe una cardinalidad de “varios a varios”.
¿Por qué? Porque resume las relaciones de las permutaciones matemáticas: Factura-
Producto y Producto-Factura.
Como primera conclusión, las tablas relacionales respetan la lógica de las
transacciones como su imposición legal. En el caso planteado, los nombres de datos
están estipulados, principalmente, en el Anexo II A de la Resolución General N.º 1415
de AFIP, apartado I. Mientras que la “carga” de los valores de datos en el apartado II
de la referida resolución.
¿Qué sucede con aquellas transacciones que no están legisladas o son
diseñadas bajo Políticas de una Empresa en particular?
En otro caso hipotético, una empresa cuenta con varios locales en la ciudad de
Rosario. Cada uno de estos cuenta con 4 empleados, un encargado de local y tres
dependientes. ¿Cómo se refleja en la Base de Datos Relacional? Por un lado, se
tendrá una tabla que contenga los nombres de datos identificatorios de un local (Nro.
Local, Domicilio, teléfono, correo electrónico y otros) como también los valores de
datos de cada uno de los locales (Local nº 2, Av. SiempreViva 234, 0341 4493453,
ejemplo@locales.com, entre otros). En otra tabla, los nombres y valores de datos de
los empleados. La cardinalidad entre las tablas es el resumen de las permutaciones
matemáticas entre las primeras. Las cuales serían:
1. Permutación Local-Empleado: ¿cuántos Empleados tiene un
Local? VARIOS
2. Permutación Empleado-Local: ¿un Empleado en cuántos
Locales trabaja? En UN Local.
De esta manera, la cardinalidad resultante es “UNO a VARIOS”.
Si por alguna razón estratégica, se decide la rotación de los empleados ¿Qué
sucede con la Base de Datos Relacional? CAMBIA. La cardinalidad entre las tablas se
ve afectada:
a) Permutación Local-Empleado: ¿cuántos Empleados tiene un
Local? VARIOS
b) Permutación Empleado-Local: ¿un Empleado en cuántos
Locales trabaja? VARIOS
Por consiguiente, la nueva cardinalidad resultante es “VARIOS A VARIOS”. Y
este es el origen de los problemas cuando el Sistema de Información no refleja las
reglas de negocio de una Empresa. O en otras palabras, se debe “emparchar” o
parametrizar el sistema (más aún si se adquirió un Sistema Integrado: ERP o CRM)
A partir de esta situación, los Profesionales en Ciencias Económicas deben
adoptar el rol de Analista Funcional de Sistemas y Agente de Cambio. Con los
conocimientos de Base de Datos se debe elaborar un Plan Estratégico Informático en
donde se atempere el cambio de las Reglas de Negocio en las Relaciones de la Base
de Datos. Para no extenderse en el presente artículo, esto último se desarrollará en
distintas notas.