El siguiente extracto sobre el diseño de aplicaciones multiusuario se tomó de Dominar el desarrollo de Microsoft Office Access 2007 y se ha reimpreso con permiso de Pearson Education, copyright 2007. Lea el capítulo completo sobre estrategias de diseño de aplicaciones multiusuario para Microsoft Access.
 |
 |
Cuando desarrolle aplicaciones a las que varios usuarios accederán a través de la red, debe asegurarse de que manejen eficazmente los datos compartidos y otros objetos de la aplicación. Hay muchas opciones disponibles para los desarrolladores cuando diseñan aplicaciones multiusuario, y este capítulo cubre los pros y los contras de estas opciones.
Los problemas de múltiples usuarios giran en torno al bloqueo de datos; incluyen decidir dónde almacenar los objetos de la base de datos, cuándo bloquear los datos y cuántos datos bloquear. En un entorno multiusuario, tener varios usuarios intentando modificar simultáneamente los mismos datos puede causar conflictos. Como desarrollador, debe manejar estos conflictos. De lo contrario, sus usuarios experimentarán errores inexplicables.
Estrategias de diseño de aplicaciones multiusuario
Existen muchos métodos para manejar el acceso concurrente a datos y otros objetos de aplicación por parte de múltiples usuarios; cada uno ofrece tanto soluciones como limitaciones. Es importante seleccionar la mejor solución para su entorno particular.
Estrategias para instalar Microsoft Access
Hay dos estrategias para instalar Microsoft Access:
- Ejecute Microsoft Access desde un servidor de archivos a través de una red.
- Ejecute una copia separada de Microsoft Access en cada estación de trabajo.
Las ventajas de ejecutar Microsoft Access desde un servidor de archivos son que
- Permite la administración central del software Microsoft Access
- Potencialmente reduce los requisitos de licencia.
- Permite que las aplicaciones de Microsoft Access se instalen en estaciones de trabajo sin disco
- Reduce los requisitos de disco duro
Las instalaciones del servidor de archivos también tienen serios inconvenientes, incluidos los siguientes:
- Cada vez que el usuario inicia una aplicación de Access, Access EXE, DLL y cualquier otro archivo necesario para ejecutar Access se envían a través del cable de red a la máquina local. Evidentemente, esto genera un volumen importante de tráfico de red.
- El rendimiento generalmente se degrada a niveles inaceptables.
Debido a que las desventajas de ejecutar Microsoft Access desde un servidor de archivos son tan pronunciadas, fuertemente Recomendamos que instale Microsoft Access, o al menos el motor de tiempo de ejecución, en la máquina de cada usuario.
Estrategias para instalar su aplicación multiusuario
Así como existen diferentes estrategias para instalar Microsoft Access, también existen varias estrategias para instalar su aplicación, como las siguientes:
- Instale tanto la aplicación como los datos en un servidor de archivos.
- Instale los datos en el servidor de archivos y la aplicación en cada estación de trabajo.
- Instale la aplicación y los datos en una máquina que ejecute Windows 2003 Terminal Services.
En otras palabras, después de haber creado una aplicación, puede colocar la aplicación completa en la red, lo que significa que todas las tablas, consultas, formularios, informes, macros y módulos que componen el sistema residen en el servidor de archivos. Aunque este método de acceso compartido mantiene todo en el mismo lugar, verá muchas ventajas al colocar solo las tablas de datos de la base de datos en el servidor de archivos. Los objetos restantes se colocan en una base de datos en la máquina de cada usuario, y cada base de datos de la aplicación local está vinculada a las tablas de la red. De esta forma, los usuarios comparten datos pero no el resto de los objetos de la aplicación.
Las ventajas de hacer esto son las siguientes:
- Debido a que cada usuario tiene una copia de los objetos de la base de datos local, el tiempo de carga y el tráfico de la red se reducen.
- Puede realizar fácilmente una copia de seguridad de los datos sin tener que hacer una copia de seguridad del resto de los objetos de la aplicación.
- Al redistribuir nuevas versiones de la aplicación, no necesita preocuparse por sobrescribir los datos de la aplicación.
- Puede diseñar varias aplicaciones para utilizar los mismos datos ubicados centralmente.
- Los usuarios pueden agregar sus propios objetos (como sus propias consultas) a sus copias locales de la base de datos.
Además de almacenar las consultas, formularios, informes, macros y módulos que componen la aplicación en una base de datos local, también recomiendo que almacene los siguientes objetos en cada base de datos local:
- Mesas temporales
- Tablas estáticas
- Mesas semiestáticas
Las tablas temporales deben almacenarse en la base de datos que se encuentra en cada estación de trabajo porque, si dos usuarios realizan operaciones que crean las mismas tablas temporales, no desea que el proceso de un usuario interfiera con el proceso del otro usuario. Puede eliminar el conflicto potencial de que las tablas temporales de un usuario sobrescriban las del otro almacenando todas las tablas temporales en la copia local de la base de datos de cada usuario.
También debe colocar tablas de búsqueda estáticas, como tablas de estado, en cada estación de trabajo. Debido a que los datos no cambian, el mantenimiento no es un problema. El beneficio es que Access no necesita extraer esos datos a través de la red cada vez que la aplicación los necesita.
Las tablas semiestáticas (tablas que rara vez se actualizan) también se pueden colocar en la máquina local. Al igual que con las tablas estáticas, tener estas tablas en una base de datos local significa un tráfico de red reducido y un mejor rendimiento, no solo para el usuario que necesita los datos, sino también para cualquiera que comparta el mismo cable de red.
La configuración descrita a lo largo de esta sección se ilustra en la Figura 22.1.
Figura 22.1 Un ejemplo de una configuración con objetos de base de datos divididos, almacenando tablas temporales y estáticas localmente y tablas compartidas de forma remota (en el servidor de archivos).
Terminal Services ha surgido como una alternativa viable para la implementación de una aplicación de Access. Aborda problemas de centralización y de ancho de banda. Con esta opción, una máquina con Windows 2003 ejecuta Windows 2003 Terminal Services. A continuación, las máquinas cliente acceden a la máquina servidor mediante la utilidad de cliente de Terminal Server. En este escenario, Access, su aplicación y los datos a los que accede están instalados en la máquina con Windows 2003 Server. Todas las demás máquinas acceden a la aplicación a través de sesiones de usuario creadas en la máquina servidor. Las pulsaciones de teclas y los eventos del mouse se envían desde las máquinas cliente a la máquina servidor. La imagen de pantalla resultante se devuelve a la máquina cliente. Esta configuración resuelve muchos de los problemas inherentes a las otras dos soluciones.
