Como habíamos visto en este artículo:

https://firebird21.wordpress.com/2013/03/15/entendiendo-a-las-bases-de-datos/

una Base de Datos sirve para guardar datos en ella y para procesar dichos datos. El resultado de ese proceso se llama INFORMACIÓN.

DATOS —> PROCESO —> INFORMACIÓN

Los usuarios ingresan los DATOS en las tablas, en los stored procedures y en los triggers se PROCESAN esos datos, y el resultado de ese procesamiento es la INFORMACIÓN que se obtiene.

Para que la INFORMACIÓN sirva debe ser exacta, oportuna y confiable. Esto solamente puede conseguirse si los DATOS introducidos son exactos y si el PROCESO al que son sometidos es correcto. Si cualquiera de ellos (datos o proceso) están mal entonces es seguro que la INFORMACIÓN estará mal.

La introducción de los DATOS corre por cuenta y es responsabilidad de los usuarios.

El PROCESAMIENTO y la INFORMACIÓN corren por cuenta y es responsabilidad del diseñador de la Base de Datos.

Si un DATO es incorrecto, fue mal introducido, parte de la culpa puede ser del usuario y la otra parte de la culpa puede ser del diseñador de la Base de Datos. ¿Por qué? Porque es posible evitar la introducción de muchos datos erróneos si la Base de Datos está bien diseñada.

  • Si sabes que la Empresa inició sus actividades en el año 2013 y por lo tanto no pudo haber realizado una venta en el año 2012. ¿Por qué permitiste que se guardara esa venta?
  • Si sabes que las cobranzas se realizan siempre después que las ventas ¿Por qué la fecha de la cobranza es anterior a la fecha de la venta?
  • Si sabes que está prohibido venderle a crédito a los clientes que adeudan 3 cuotas o más. ¿Por qué permitiste esa venta a crédito a ese cliente que nos debe 4 cuotas?
  • Si sabes que a todos los clientes morosos se les cobra una multa ¿Por qué a este cliente moroso no se le cobró la multa?
  • Si sabes que el precio de venta de un producto siempre debe ser mayor que el precio de costo. ¿Por qué permitiste grabar un precio de venta menor al precio de costo?
  • Si sabes que los vendedores no pueden cambiar los precios de venta de los productos. ¿Por qué permitiste que este vendedor los cambiara?
  • Si sabes que el precio de venta no puede ser negativo. ¿Por qué este producto tiene un precio de venta negativo?
  • Si sabes que en el Punto de Ventas Nº 2 no se aceptan cheques. ¿Por qué este cliente abonó con un cheque?
  • Etc., etc., etc.

En todos los casos anteriores (y miles más por el estilo) la culpa es en una pequeña parte del usuario y en una grandísima parte del diseñador de la Base de Datos porque si ésta hubiera tenido un diseño correcto ninguno de esos problemas hubieran ocurrido.

¿Cómo se evita que los usuarios introduzcan DATOS erróneos?

Para evitar o al menos disminuir grandemente la posibilidad de que un usuario introduzca datos erróneos el Firebird nos provee de varias herramientas: restricción Foreign Key, restricción Unique Key, restricción Check, dominios, triggers.

Mediante la restricción Foreign Key nos aseguramos que en una columna solamente se puedan guardar valores que existen en otra tabla. Si no existen en la otra tabla, no se grabarán.

Mediante la restricción Unique Key nos aseguramos que en una columna no haya datos repetidos. Ni duplicados, ni triplicados, ni nada de eso. Solamente datos únicos.

Mediante la restricción Check nos aseguramos que en una columna (o serie de columnas) solamente se puedan introducir valores que cumplen con las condiciones impuestas.

Mediante los dominios nos aseguramos que los valores de una columna sean solamente los permitidos.

Mediante los triggers nos aseguramos que antes de insertar o actualizar una fila los valores de sus columnas sean valores permitidos.

¿Cómo se evita que los PROCESOS produzcan resultados incorrectos?

Verificando intensivamente su funcionamiento, ejecutándolos muchas veces con una gran variedad de datos distintos y prestando especial atención a los valores de bordes. ¿Qué son los valores de bordes? Los valores mínimo y máximo que pueden ocurrir.

¿En qué casos la INFORMACIÓN no sirve?

Si la INFORMACIÓN no sirve entonces es basura. Eso puede ocurrir:

  1. Cuando los DATOS no son los correctos.
  2. Cuando el PROCESO es incorrecto.
  3. Cuando la INFORMACIÓN es recibida después del momento requerido.
  4. Cuando la INFORMACIÓN no es relevante.

Si los DATOS o el PROCESO son incorrectos entonces lo que se obtiene no sirve, en otras palabras se obtiene basura, porque DATOS correctos utilizados por un PROCESO incorrecto da como resultado basura y DATOS incorrectos utilizados por un PROCESO correcto también dan por resultado basura. Si la INFORMACIÓN es recibida después del momento requerido tampoco sirve, por ejemplo se la necesitaba con urgencia a las 9:00 y se la recibió a las 17:00, ya es totalmente inútil, o sea que es basura. Y si no es relevante tampoco es útil, por ejemplo se necesitaba un informe con las ventas del mes de “Julio” y se recibió un informe (muy correcto y muy preciso, por cierto) con las ventas del mes de “Junio”, entonces también es basura.

¿Cuál es la diferencia entre DATOS e INFORMACIÓN?

Un “dato” es lo que se guarda, una “información” es lo que se obtiene después de “procesar” a los “datos”. Los datos por sí solo no tienen significado, por ejemplo: ¿Qué significa el número 12345? ¿Es el identificador de un cliente? ¿Es el número de un comprobante? ¿Es la cantidad en stock de un producto? ¿Es el precio de venta de otro producto? ¿Es el código de un producto? No lo sabemos ni lo podemos saber.

¿Por dónde se empieza el diseño de la Base de Datos?

Siempre por el final, o sea por la INFORMACIÓN que los usuarios desean obtener. Esto implica que se debe entrevistar a los usuarios para preguntarles todo lo concerniente a la INFORMACIÓN que necesitan.

Si un futuro usuario te dice: “necesito un informe de las ventas diarias, otro informe de las ventas mensuales, otro informe de la cantidad en stock actual de cada producto, otro informe de las cobranzas realizadas a la fecha, otro informe de las cuotas a cobrar a los clientes durante el mes en curso, otro informe de los pagos a realizar a los proveedores durante el mes en curso, otro informe de los clientes que adeudan 2 ó más cuotas” entonces puedes determinar que necesitarás, al menos, las siguientes tablas:

  • PRODUCTOS (Identificador, Código, Nombre, Cantidad inicial, Fecha de la cantidad inicial, etc.)
  • CLIENTES (Identificador, Nombre, Dirección, Teléfono, etc.)
  • VENTAS CABECERA (Identificador, Tipo de documento, Número de documento, Fecha de la venta, Identificador del cliente, etc.)
  • VENTAS DETALLES (Identificador, Identificador de la cabecera, Identificador del producto, Cantidad, Precio unitario, etc.)
  • COBRANZAS (Identificador, Fecha de la cobranza, Identificador del cliente, Número de Factura cobrada, Monto cobrado, etc.)
  • PROVEEDORES (Identificador, Nombre, Dirección, Teléfono, etc.)
  • COMPRAS CABECERA (Identificador, Tipo de documento, Número de documento, Fecha de la compra, Identificador del proveedor, etc.)
  • COMPRAS DETALLES (Identificador, Identificador de la cabecera, Identificador del producto, Cantidad, Precio unitario, etc.)
  • PAGOS (Identificador, Fecha del pago, Identificador del proveedor, Número de la factura pagada, Monto pagado, etc.)

Al saber cuales informes requieren los usuarios ya es fácil determinar cuales tablas se deberán crear para cumplir con ellos.

El siguiente paso es normalizar las tablas.

¿Qué significa normalizar las tablas?

Hacer que en cada tabla se guarde la cantidad mínima de datos necesarios, que las tablas puedan actualizarse correctamente y asegurando la integridad de los datos. Hay 6 formas normales (puedes buscar más información sobre este tópico en Internet) y si consigues que una tabla cumpla con esas 6 formas normales entonces puedes asegurar que está bien diseñada.

Artículos relacionados:

Entendiendo a las bases de datos

Diseño de bases de datos. 1FN

El índice del blog Firebird21