CMS modules by everest poker.

Dividir una BD: back-end / front-end

Imprimir
Valoración del Usuario:  / 16
MaloBueno 
Categoría: Teórico-práctico
Escrito por Neckkito

Si queréis bajaros el artículo en pdf pulsad aquí.

Índice de contenidoBackEndFrontEnd


COMPARTIENDO UNA BASE DE DATOS
¿DIVIDIR LA BASE DE DATOS? ¿POR QUÉ?
¿CÓMO DIVIDIR UNA BASE DE DATOS?
NO ME DEJA DIVIDIR. ¿QUÉ PASA?
PROBLEMAS DE CÓDIGO VBA
PROBLEMAS DE COMPACTACIÓN
Y UNA VEZ DIVIDIDA... ¡A TRABAJAR!

 

COMPARTIENDO UNA BASE DE DATOS
Tenemos nuestra base de datos y queremos que varios usuarios puedan acceder al mismo tiempo. Por eso no hay ningún problema puesto que, a diferencia de Excel, por ejemplo, Access es una aplicación multiusuario.

Supongamos que tenemos un servidor con una carpeta compartida por varios PC's locacles. ¿Cómo compartimos la BD?

Una primera manera de compartirla sería situar nuestra aplicación en ese servidor y crear accesos directos en cada uno de los PC's locales. De esta manera cada local abriría una instancia de nuestra BD y podría trabajar con la misma sin problemas.

Sin embargo, este sistema, si bien es perfectamente válido (yo lo he utilizado para compartir una BD con ocho usuarios al unísono), no es el recomendado por temas de optimización. Entonces, ¿cuál es el mejor sistema? Pues lo ideal sería dividir la base de datos.

 

¿DIVIDIR LA BASE DE DATOS? ¿POR QUÉ?
Dividir la base de datos es simplemente crear dos bases de datos: una, denominada Back-End, es la que contiene las tablas exclusivamente; otra, llamada Front-End, que es la que contiene el resto de objetos de Access: formularios, consultas, informes, macros, módulos...

¿Por qué este sistema se considera mejor? Como os comentaba básicamente por temas de optimización de recursos. Veamos algunos motivos:

~ Aumento del rendimiento y velocidad de respuesta de la base de datos: si cada uno de los PC's tiene todos los objetos en local (menos las tablas, claro) el hecho de cargar formularios, cargar consultas, iniciar informes, etc. se realiza en local. Lógicamente eso aumenta la velocidad de respuesta de Access. El tráfico con el servidor (es decir, el tráfico por la red, aunque en este caso sea una intranet) se reduce al mínimo posible, es decir, cuando se requiere acceso a las tablas, ya sea por lectura o por escritura.

~ Personalización de los front-end por el administrador de la BD: al “repartir” los front-end entre los distintos usuarios podemos manipularlos en función de lo que queramos permitir al usuario. Es decir, que si un usuario no puede ver los informes de otro departamento podríamos crear un front-end personalizado eliminando los informes que hacen referencia a dicho “departamento prohibido”, al tiempo que también eliminamos su acceso a través de formularios (simplemente borrando el botón que permite imprimir el informe, por ejemplo).

~ Personalización de los front-end por el usuario de la BD: si, por las características tanto del usuario como de nuestra BD, decidimos que el usuario (con algunos conocimientos de Acccess) pueda construirse sus propias consultas o diseñar sus propios informes, dicho usuario podrá realizar dichas operaciones en su front-end, sin “tocar” el front-end del resto de PC's locales.

~ Introducción de tablas personalizadas: un front-end no tiene la obligación de poseer únicamente las tablas vinculadas al back-end, sino que puede tener sus propias tablas. Relacionado con el motivo anterior, y a modo de ejemplo, si un usuario introduce información en un Excel y desea que esa información “personalizada” sea incorporada a su “base de datos” con realizar una importación o vinculación del Excel en su front-end ya tenemos la mejora implantada. De nuevo el resto de usuarios locales no dispondrán de la “tabla-Excel” puesto que, sencillamente, no la necesitan.

~ La información se halla concentrada en las tablas del back-end, que está en el servidor. ¿Y qué implica eso? Que usualmente el servidor recibe unos “mimos” mayores que los que puede recibir un PC local. Luego se sobrentiende que habrá alguna política de copia de seguridad periódica de datos del servidor, o incluso contaremos con un “sistema mirror”, con lo que todos nuestros datos tendrán, al menos en teoría, una mayor salvaguarda. Si se estropea un disco duro de un PC local y no tenemos copia de seguridad lo máximo que perderemos será el front-end, pero no los datos, y el resto de locales podrá seguir funcionando sin problemas.

Puede ser que por ahí encontremos otras razones más técnicas que refuercen la idea de dividir una BD compartida, pero creo que con lo dicho ya nos podemos hacer una buena idea de las “bondades” del sistema, al menos a nivel de administrador-usuario.

Si queremos profundizar un poco en el tema podemos echar un vistazo a este artículo del propio Microsoft. Hace referencia sólo a bases de datos mdb, aunque hay muchos conceptos que podrían aplicarse a versiones posteriores.

El enlace: http://office.microsoft.com/es-es/access-help/compartir-una-base-de-datos-de-access-en-una-red-mdb-HP005240860.aspx

 

¿CÓMO DIVIDIR UNA BASE DE DATOS?
Por suerte para nosotros Access cuenta con un asistente que nos guía en el proceso de división de una base de datos.

Si utilizamos Access 2003 lo que tenemos que hacer es irnos a Menú -> Herramientas -> Utilidades de la base de datos -> Divisor de base de datos

A partir de ahí nos saldrá el asistente que nos permitirá dividir la BD, preguntándonos dónde queremos ubicar el back-end (el título de la ventana de navegación nos indicará: “Crear una base de datos de servidor”).

Si utilizamos Access 2007 o Access 2010 la opción se halla en el Menú -> Herramientas de base de datos. En la cinta de opciones veremos un grupo denominado “Mover datos”, y dentro del mismo un botón llamado “Base de datos de Access”, que tiene un dibujo de tres cilindros en triángulo y unas flechas. Si pulsamos sobre dicho botón del ribbon se iniciará el asistente e, igual que indicaba en el párrafo anterior, se nos pedirá si queremos dividir la BD y se abrirá una ventana de navegación para indicar donde queremos situar el back-end, con el mismo título de ventana.

Podríamos realizar una división manual de una BD en lugar de operar a través del asistente. Sin embargo, como no es el objetivo de este artículo, quien quiera “estrujarse el cerebro” un poco puede visitar el siguiente enlace, donde el proceso está explicado.

El enlace: http://support.microsoft.com/kb/304932/es

 

NO ME DEJA DIVIDIR. ¿QUÉ PASA?
En ocasiones intentamos dividir una base de datos y el proceso nos da continuamente problemas de división.

Moraleja e importante: guardémonos siempre una copia de seguridad “entera” de nuestra BD antes de realizar un proceso de división

Los problemas que impiden la división de una BD pueden ser muchos y variados, y quizá deban analizarse las características de nuestra aplicación para intentar descubrir cuál es el “inconveniente”. Es decir, no podemos generalizar una solución.

Sin embargo, sí hay dos causas que suelen ser usuales y que producen problemas en la división de una base de datos. Echémosles un vistazo.

 

PROBLEMAS DE CÓDIGO VBA
En ocasiones (por no decir muchas veces) hemos ido creando nuestra base de datos programando código que a veces funcionaba y otras no, o bien hemos añadido código a un control para después decidir que el control no era necesario, con lo que hemos borrado el control pero no el código, y, en definitiva, otras situaciones con las que hemos “trasteado” con nuestro código VBA.

Cabe la posibilidad de que este “pequeño desastre” a nivel de código nos dé problemas a la hora de dividir la base de datos (con seguridad sí nos dará problemas si queremos convertir nuestra BD en un archivo mde o accde).

¿Cómo lo solucionamos?  Pues simplemente depurando el código. ¿Cómo se hace eso? Pues nos situamos en el editor de VB y nos vamos a Menú -> Depuración -> Compilar <nombre proyecto>. Si hacemos click sobre dicha opción el depurador nos llevará al error que encuentre y nosotros podemos corregirlo. Repetimos esta operación tantas veces como sea necesario hasta que la opción Compilar <nombre proyecto> nos aparezca atenuada.

 

PROBLEMAS DE COMPACTACIÓN
Si no hemos realizado ninguna compactación nuestra BD no está optimizada, y quizás pueda interferir en el proceso de división.

Como tenemos un artículo dedicado al tema de la compactación si queréis consultarlo podéis clickar aquí.

 

Y UNA VEZ DIVIDIDA... ¡A TRABAJAR!
Si hemos conseguido dividir la BD tendremos el back-end en el directorio del servidor que hayamos indicado y el front-end donde teníamos nuestra BD “entera”. Ahora sólo se trata de copiar y repartir el front-end al resto de los PC's locales (si no tenemos que hacer ningún front-end especial para algún o algunos usuarios) y, a partir de ahí, ya podemos trabajar tranquilamente con nuestra BD dividida.

 

Y eso es todo. Espero que el artículo os haya sido de utilidad.

 

Un saludo, y...

¡suerte!

 

Wednesday the 13th. Joomla 2.5 Templates. Neckkito's baby 2012 --- Hosted by: www.siliconproject.com.ar
Copyright 2012

©