Estructura lógica vs. estructura física.

ESTRUCTURA LÓGICA VS ESTRUCTURA FÍSICA

Es claro que la forma física como estén almacenados los datos es independiente del concepto que tengamos de ellos. Son el conjunto de programas que saben como traer, unir y mostrar los datos, así como aquellos encargados de almacenarlos, los que le dan coherencia al concepto Base de Datos.
Digamos que es como la diferencia entre harina, levadura, sal y agua por separado y una pieza de pan. Quién le dá coherencia a esa pieza de pan es el proceso que se sigue para elaborarlo.
Es importante conceptualizar esto, porque del diseño de la estructura lógica depende toda la funcionalidad del sistema. Almacenar datos en una base de datos aprovechando solamente la estructura física no ofrece, relativamente, ninguna ventaja. En cambio un buen diseño de acuerdo a la naturaleza de los datos y a la forma como serán explotados hace toda la diferencia.
Un gran problema es la inconsistencia de datos. Digamos que empleamos un archivo secuencial para almacenar la información de clientes. Supongamos que tenemos varios programas que utilizan esa información y que en un momento dado se pueden tener registros duplicados con atributos diferentes. Por ejemplo, una persona cambia de dirección y al no tener una estructura bien definida, no alteramos el registro, sino que lo damos de alta de nuevo con la nueva dirección. De esta manera, tendremos a la misma persona con dos datos diferentes y sin posibilidad de garantizar que todos los programas tendrán en cuenta que la dirección válida es la del segundo registro que aparece.
Puede ocurrir también que dos personas estén modificando simultáneamente atributos distintos del mismo registro. Sin un sistema de manejo de concurrencia, no podemos garantizar que ambos cambios permanezcan.
Bajo la misma suposición de uno o más archivos con la información y varios programas independientes que la explotan, es fácil ver que cualquier nueva explotación de la información implica un nuevo programa y que mantener un sistema como este conlleva toda la complejidad de mantener varios programas cuando se añade o elimina una columna a los registros.
Otro ejemplo, si tenemos un registro de personas donde almacenamos datos como: nombre, RFC, puesto, salario base, dirección, teléfono, fecha de nacimiento, gustos musicales, aficiones, nombre, fecha de nacimiento y ocupación del cónyugue, nombres y fechas de nacimiento de sus hijos, nombres de sus mascotas, autos que posee (con todas las características), etc; y frecuentemente sólo utilizaremos nombre, RFC, puesto y salario base para generar una nómina, esto implica que en cada corrida, recuperaremos información que no necesitamos, con el agravante de que tenemos que traer registros inmensos para utilizar sólo cuatro campos. El problema no es el almacenaje en disco, sino el tiempo desperdiciado en recuperar registros de tal magnitud.
Un diseño un poco más inteligente tendría dos tablas, una con los datos más frecuentemente empleados de cada persona y la otra con el resto de la información que se emplea quizá sólo para fines estadísticos o para enviar tarjetas de felicitación. Por supuesto, ambas tablas estarán relacionadas por una llave primaria común.
Si tenemos un sistema donde por un lado hacemos un abono y por otro un cargo en una operación que está relacionada, es de esperar que no ocurra el cargo si no puede ocurrir el abono, o viceversa. Es decir, debemos de tener transacciones atómicas. En este caso, la pareja de transacciones debe de ocurrir por completo o no debe de ocurrir en lo absoluto.
Finalmente, un terrible problema es la exposición de los datos. En muchos casos nos interesa que ciertas gentes tengan acceso sólo a parte de la información. Es de mal gusto que todos los empleados sepan cuál es el salario del director.