Existen una serie de reglas que se deben seguir para que las bases de datos no sean redundantes y se puedan utilizar eficientemente. La importancia de seguir estas reglas depende del tamaño de la base de datos. Conforme la base de datos va creciendo, se vuelve cada vez más crítico que esta este diseñada correctamente.
Si existen errores en el diseño se pueden presentar problemas como:
- Repetición de información.
- Inhabilidad de representar cierta información
- Perdida de información.
Considere la información de prestamos en un banco (ver Figura 1). En este ejemplo, si agregamos un nuevo préstamo, es necesario repetir los datos de ciudad y monto.
Figura 1. Ejemplo de relación de datos.
Podemos hacer las siguientes consideraciones.
- Una sucursal esta localizada en exactamente una ciudad.
- Una sucursal puede hacer muchos prestamos.
- Existe una dependencia funcional nombreSucursal->CiudadSucursal.
- No existe una dependencia funcional nombreSucursal->IdPrestamo.
- No es posible representar la información de sucursal a menos de que exista un préstamo.
Sin embargo, si no se tiene cuidado al hacer la partición de datos, pueden surgir otros problemas. Por ejemplo, considere que nuestro esquema original se divide en la forma de la Figura 2. Aparentemente podemos recuperar la tabla original al hacer la juntura natural de las dos tablas (ver Figura 3). En la Figura 3 se observan registros que no existen en la tabla original ¿Por qué pasa eso?
- La intersección de los dos esquemas es NombreCliente.
- Si existen dos prestamos para el mismo cliente, en la juntura natural habrá cuatro registros, dos de las cuales serán superfluas y no deberían aparecer en la base de datos. Es decir, aunque tenemos más registros tenemos menos información que en la tabla original.
[img]
[/img]
[img]
[/img]
Figura 2. Descomposición de la tabla de prestamos.
[img]
[/img]
Figura 3. Join de la descomposición de la tabla de prestamos.
Si descomponemos la tabla en un esquema de sucursal y otro de préstamo, no tendremos el mismo problema (ver Figura 4) ¿Porqué no?
[img]
[/img]
[img]
[/img]
Figura 4. Descomposición de tabla de prestamos en base a sucursal.
La relación entre las tablas es a través de NombreSucursal. Esto no causara problemas ya que para una sucursal dada solamente hay un fondo y una ciudad.
Entre mejor este hecho el diseño de un sistema, el resultado será mejor y se lograra más rápido. El propósito de una metodología de diseño es definir una secuencia de pasos para lograr un buen sistema.
En este manual se presenta una metodología de diseño apropiada para el uso de Access. Este un enfoque que empieza con el diseño conceptual y va elaborando de manera sucesiva un mayor detalle del diseño hasta terminar en el diseño del menú.
[img]
[/img]- Diseño conceptual.
- El primer paso en el diseño de un sistema es determinar las necesidades del usuario. El proceso de diseño es un proceso repetitivo; al terminar cada paso es necesario revisar los pasos anteriores para asegurarse de que nada en el diseño básico ha cambiado. Por ejemplo, si al crear las reglas de captura de datos, se decide que es necesario otro campo, que no esta definido en la tabla, para validar algún campo, es necesario regresar y seguir cada paso previo para agregar el campo. Es necesario asegurar que el nuevo campo esta incluido en los reportes en los que se quiera ver. Además, hay que asegurar que el nuevo campo esta incluido en alguna forma de entrada. Solo entonces se podrá usar el nuevo campo en el sistema. En esta etapa se hace un análisis de necesidades y de la situación actual, considerando puntos como los siguientes:
- ¿Qué reportes y formas se usan actualmente?
- ¿Qué datos se registran actualmente?
- ¿Cuáles son las reglas de negocio relevantes?
En esta etapa es recomendable el uso de prototipos o muestra de cómo seria el sistema. Un prototipo se construye con las componentes visuales del sistema, sin la lógica subyacente.
- Diseño de reportes.
- En esta etapa no es importante la distribución de los campos en el reporte, sino definir que datos serán necesarios para cumplir con los requerimientos de información del usuario.
- Diseño de datos.
- Después de decidir que es lo que se quiere en los reportes, es tiempo de pensar como organizar los datos del sistema para que estén disponibles para los reportes definidos, así como para las consultas especiales que pudieran surgir. El siguiente paso es tomar un inventario de toda la información o campos de datos que se requieren para los reportes y formas. Al hacer eso, hay que tomar nota de los campos que aparecen en más de un reporte. Asegúrese de que se utilice el mismo nombre de referencia para un dato en todos los reportes donde aparece. Otro método es agrupar los datos en un arreglo lógico que sirva de base para la definición de tablas. El proceso de agrupar información común se conoce como normalización.
- Diseño de tablas y relaciones (Normalización de una base de datos).
- Las reglas básicas de normalización son las de la primera forma normal (1NF):
- Eliminar columnas duplicadas en la misma tabla.
- Crear tablas separadas para cada grupo de datos relacionados e identificar cada hilera con una columna única ( la llave primaria).
Considere una tabla que guarda información de un supervisor y sus subordinados. Para efectos del ejemplo supondremos la regla de negocio de que un supervisor tiene varios subordinados mientras que un subordinado tiene un solo supervisor. Una primera solución se muestra en la Figura 5.
[img]
[/img]Figura 5. Tabla de supervisores.
Este esquema presenta varios problemas. Por un lado, en el caso de José se esta desperdiciando espacio en la tabla, y por otro, en el caso de María, si se agregara otro subordinado habría que modificar la tabla. La Figura 6 muestra otra alternativa. Esta opción resuelve el problema de espacio pero complica el proceso de seleccionar datos en consultas futuras.
[img]
[/img]Figura 6. Forma alternativa de la tabla de supervisores.
La Figura 7 muestra una tabla que cumple con la primera regla de la forma 1NF. Para que este en forma 1NF es necesario identificar cada hilera con una clave única. Lo mejor es utilizar un identificador que sea realmente único, como por ejemplo el RFC, como llave primaria (ver Figura 8 ).
Para que una base de datos este en segunda forma normal, adicionalmente a las reglas de la primera forma debe cumplir con los siguientes requerimientos:
- Remover subconjuntos de datos que aplican a múltiples hileras de una tabla y colocarlas en hileras diferentes.
- Crear relaciones entre las nuevas tablas y sus predecesores a través del uso de llaves foráneas.
[img]
[/img]Figura 7. Tabla de supervisores de acuerdo a la primera regla de la forma 1NF.
[img]
[/img]Figura 8. Tabla en 1NF.
[pagebreak]
Considere el ejemplo de una tabla de clientes (ver Figura 9). En este ejemplo existe un poco de redundancia. Las entradas Monterrey, Nuevo León, 11579 y Saltillo, Coahuila, 33157 están repetidas dos veces. Además, si los códigos postales de Monterrey llegaran a cambiar, se tendría que hacer el cambio en muchos sitios de la base de datos. Separando los datos de código postal (ver Figura 10 ), y utilizando el código postal como llave foránea se llega a la forma normal 2NF (ver Figura 11 ).
[pagebreak]
Para lograr la tercera forma normal (3NF) es necesario:
- Cumplir con los requerimientos de las formas 1NF y 2NF.
- Remover columnas que no sean completamente dependientes de la llave principal.
[img]
[/img]Figura 9. Tabla de clientes.
[img]
[/img]Figura 10. Tabla de códigos postales.
[img]
[/img]Figura 11. Tabla de clientes normalizada.
Considere los datos de una orden de compra (ver Figura 12). El total se puede calcular multiplicando el precio unitario por la cantidad y, por lo tanto, no es completamente dependiente de la llave primaria. Es necesario remover este campo para que esté en la tercera forma normal (ver Figura 13). El Total se puede calcular al hacer una consulta a la tabla (ver Figuras 14 y 15).
[img]
[/img]Figura 12. Tabla de ordenes de compra.
[img]
[/img]Figura 13.Tabla de orden de compra en forma 3NF.
[img]
[/img]Figura 14. Consulta de orden de compra con calculo de total.
[img]
[/img]Figura 15. Resultado de consulta con campo calculado.
Diseño de campos (Reglas de captura y validación).
El siguiente paso es definir en detalle los campos de datos.- Diseño de nombres, tipos y tamaños de campo.
- Diseño de reglas de captura. Es deseable que solo datos validos sean alimentados en el sistema. Se pueden especificar valores específicos, rangos, o condiciones compuestas.
- Diseño de tablas de búsqueda. Es posible definir tablas de búsqueda para facilitar la captura de información y reducir errores.
- Crear datos de prueba. Después de definir los reglas de captura y como se debe ver la base de datos es necesario crear datos de prueba . Estos datos se deben definir con cuidado para cubrir varios objetivos. Por ejemplo, debe probar el proceso de captura, las condiciones que se definieron, ¿generan los mensajes de error y aceptación apropiados? Además debe probar condiciones que no se consideraron en el diseño original. Por ejemplo, ¿qué pasa cuando alguien captura espacios en un campo? ¿números en un campo de texto? Access automáticamente intercepta fechas incorrectas y caracteres en campos numéricos y de fecha.
- El primer tipo de datos de prueba es simplemente datos para poblar la base de datos con datos apropiados.
- El segundo tipo de datos de prueba es para la prueba de la captura de datos. Esto debe incluir datos con errores que genere todos los mensajes de error posibles, y datos correctos que prueben las condiciones de aceptación.
- Los datos de prueba deben probar condiciones rutinarias, así como los limites del sistema.
- Diseño de formas.
- Al diseñar una forma, se colocan tres
tipos de objeto en la pantalla:- Etiquetas y campos de texto.
- Controles especiales.
-
- Cajas de texto multilínea
- Botones de opciones
- Cajas de lista
- Cuadros de chequeo
- Graficas de negocio
-
- Imágenes.
- Objetos gráficos para mejorar
el aspecto de la forma: Color, Líneas, Rectángulos, Efectos tridimensionales
Al diseñar una forma, cloque los campos en el lugar donde se quieren en la forma. Idealmente, debe existir una forma impresa que corresponde a la forma de Access. La forma de Access debe parecerse a la forma impresa. Es decir, los campos deben estar colocados en la misma posición relativa en la pantalla y en la forma impresa.
Después de colocar los campos, se debe revisar el orden de los campos. Es decir, después de llenar un campo y usar tab, ¿cuál es el campo siguiente? El orden normal es de arriba abajo y de izquierda a derecha.
Un campo calculado puede ser parte de una forma de captura.
- Diseño de Menús (Automatización).
- Después de crear los datos, diseñar los reportes, y crear las formas, es tiempo de integrar todo usando tableros de control y menús.
Bibliografía
[1] Date, C.J. “Introducción a los Sistemas de Bases de Datos”.
Vol I. Quinta Edición. Addison-Wesley Iberoamericana. 2000.
[2] Korth H.,
Silberschatz A. “Fundamentos de bases de datos”.
Segunda Edición. McGraw-Hill. 1998.
[3] Hansen & Hansen. “Diseño y Administración de Base de Datos”.
2da. Edición. 1997.
[4] Kaufeld, John. “Access 2000 for Windows for Dummies”.
2000.
[5] Prague,
Cary, Michael Irwin, “Access 2002 Bible”. 2002.