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:
- Cuando los DATOS no son los correctos.
- Cuando el PROCESO es incorrecto.
- Cuando la INFORMACIÓN es recibida después del momento requerido.
- 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:
Firebird SQL 
El índice del blog Firebird21 | Firebird SQL
Ago 18, 2013 @ 04:31:14
Ago 18, 2013 @ 07:21:43
Buenas Walter como estas. Amigo seria bueno para los que te seguimos que colocaras en el articulo: Consideraciones a tener en cuenta al diseñar una Base de Datos, especificamente en la parte donde dice: ¿Qué significa normalizar las tablas?, colocaras esas 6 formas normales para normalizar las tablas o sacaras un articulo nuevo donde expliques paso a paso esas 6 formas para normalizar.
Ago 18, 2013 @ 13:49:09
Ok José, es una buena propuesta, la tendré en cuenta.
Saludos.
Walter.
Diseño de bases de datos. 1FN | Firebird SQL
Ago 19, 2013 @ 15:42:52
Más ejemplos de tablas que no cumplen con la 1FN | Firebird SQL
Ago 19, 2013 @ 19:48:39
Diseño de bases de datos. 2FN | Firebird SQL
Ago 20, 2013 @ 17:01:16
Diseño de bases de datos. 3FN | Firebird SQL
Ago 20, 2013 @ 22:52:13
Sep 20, 2013 @ 13:07:15
Una anotación que nos puede ayudar, todos esos SI TU SABES que anotas , son los requerimientos que nos dan en comienzo, sobre estos se diseña la base y se pone en producción; lo que ocurre es que seguramente nuestro cliente se saltará esos SI TU SABES en el momento que quiera, sea porque cambió las políticas de la empresa de la noche a la mañana, por que esa factura es de un buen valor y que me importa que no cumpla una de esas condiciones, etc. etc. aclaro me estoy refiriendo aqui al cliente normalito (bienaventurados los que siempre trabajan con multinacionales o gandes empresas que mantienen sus directivas y estudian con detenimiento cada cambio para darnos asi tiempo de reaccionar).
De lo anterior podemos pensar que para nuestro cliente, nuestro trabajo quede sirviendo nada de la noche a la mañana, (peor si trabajamos directamente para la empresa, está en peligro la estabilidad); no se si les haya pasado casos como el que esa factura debe quedar en este mes como sea y que hacemos si ya estamos a último día… pienso que la mayoria lo único que no hacemos es botar el cliente o renunciar, asi que nos ponemos en la tarea de ver como le cumplimos, damos vueltas y vueltas hasta que queda, asi salgamos de la oficina a medianoche.
Aqui toma sentido este comentario, la recomendación es que para evitar el tener que dar muchas vueltas y vueltas nos fijemos muy bien en determinar cuando hacer validación a nivel de check, cuando a nivel de procedure y cuando a nivel de trigger; por ejemplo, si tengo un check que me dice que esa cantidad no puede superar las 50 unidades, es un sencillo check que figuraria en la base como CANTID <= 50, pero nuestro cliente nos dice que ese nuevo envio a x cliente de sus preferidos le va a permitir 60, no nos queda más que cambiar nuestro check por CANTID <= 60, hasta ahi muy bien….solucionado, pero que ocurre si nos dice luego que es a ese solo cliente al que le permite los 60 ?, ahi la cosa se complica y nos quedaria una base inconsistente si regreso el check a 50 o un hueco de seguridad si lo mantengo asi, el escenario empeora si lo que nos piden ahora es restringir más ese asunto porque ya no son 50 sino 40 .. peor la cosa …. seguramente tendré que quitar el check y mirar donde incrusto una validación a nivel de procedure, será una loteria si ese cambio nos sale sencillo de hacer o no.
Para evitar un poco el caos de los cambios, particularmente recomiendo utilizar los check en asuntos determinísticos SEXO IN ('H','M'), (siempre será hombre o mujer, asise lo cambie jejeje) STRLEN(TRIM(CODPOS))=5 (la longitud del codigo postal siempre ha sido 5-directivas demas de un siglo) etc, etc… y dejar a nivel de procedure y trigger esas cosas que pueden llegar a cambiar, cosas que nos juran que no van a cambiar dentro de la empresa pero nunca se sabe; pasado esto también debo analizar con juicio cuando utilizaré un trigger o cuando un procedure, esto pesa en asuntos de rendimiento, lo ideal es que se pase a los procedures cuando se haya validado todo en los casos que se pueda, en últimas tendré que validar durante el proceso pienso que basicamente resultados que dependen de otros.
Como vemos inicialmente el diseño nos llevará más trabajo, tendremos como recompensa sentirnos muy bien cuando nos pidan un cambio y lo podamos hacer sin entrar en pánico, esto le genera confianza a nuestro cliente y habla bien de nuestro trabajo, de todas maneras no nos olvidemos que será algo que se habrá de cobrar a buen precio (que no vayan a salir luego con el cuento uuuy pero tanto por 5 minutos que se demoró jejejejej) al fin y al cabo me esforzé al principio y entregué un producto de calidad.
Saludos
Sep 20, 2013 @ 19:13:54
Quizás el lugar mas apropiado para los valores de esas opciones sería un fichero de configuración, que aunque no fuera visible/editable por el usuario, si permitiría actualizar fácilmente sus valores, y hasta desde el sillón de casa.