Visual FoxPro y la optimizacin RushmorePublicado originalmente en UTMag/Rapozinehttp://www.UniversalThread.com/MagazineLa optimizacinMucho se ha escrito de la optimizacin Rushmore, caracterstica inconfundible de FoxPro. Muchos programadores, incluso sin conocer profundamente a FoxPro, intuyen que es algo que tiene que ver con los ndices, algo que acelera las consultas.

Pues entonces qu es precisamente la optimizacin Rushmore? Podramos decir, por ahora, que es la utilizacin de los ndices para acelerar la recuperacin de datos. Dicho as, nos quedamos con gran cantidad de preguntas sin respuestas.

Para entender un poco cmo funciona esto, demos un poco de base terica la que seguramente no nos vendr mal. Quizs algunas partes sean un poco difciles de entender, pero por lo menos los conceptos al final de cada punto sern igualmente tiles para el lector. Tampoco espere el lector que se toquen todos los aspectos de Rushmore, debido a que Microsoft - como hara cualquier otro fabricante - no da mayores detalles de su arquitectura interna.Jerarqua de almacenamientoLa jerarqua de almacenamiento se refiere a las distintas capas que tiene una computadora para almacenar informacin. En base de datos, la jerarqua es:

1. Memoria RAM fsica. Poca capacidad (menor que 2 GB), gran velocidad (10ns). Voltil.2. Medio magntico de acceso aleatorio. Normalmente es un disco rgido. Capacidad intermedia (unos 50 GB), velocidad media (7 ms). No voltil.3. Medio magntico de acceso secuencial. Normalmente es una unidad de cinta DLT, DAT, etc. Gran capacidad (centenares de gigabytes) velocidad lenta (del orden de segundos a minutos). No voltil.

Por lo tanto, decimos lo siguiente: las bases de datos operan en la jerarqua 1 y 2. En la 1 se efecta el PROCESO, en la 2 el ALMACENAMIENTO. De esto se deduce fcilmente que para que exista el PROCESO, debe transferirse informacin desde la jerarqua 2 a la 1, y viceversa. Volveremos sobre estos conceptos ms adelante.Modelo relacionalComo los sistemas de informacin hasta comienzos de los 70s eran propietarios, y sus datos se almacenaban en formatos tambin propietarios, se consuman muchas horas-hombre en alterar la funcionalidad de un sistema, ya que no exista una separacin clara entre el programa y los datos.

Se necesitaba lo que se conoce como "independencia de datos", es decir, el programa deba estar protegido de los cambios que pudiesen haber en los datos. Para ello era claro que adems del programa se necesitaba algo que estuviese separado del mismo: una base de datos. La base de datos provee independencia fsica, porque no importa cmo est almacenada la informacin, ni el tamao de las pginas, ni sobre qu soporte , el programa sigue viendo de la misma forma a los datos. Tambin provee cierta independencia lgica, ya que el hecho de agregar columnas o procedimientos almacenados no debe influir sobre el programa preexistente (esto no es cierto, obviamente, si quitamos columnas, etc.).

Hasta esa poca, los procesos en COBOL actuaban sobre archivos parecidos a los de texto, pero algunos usaban delimitadores especiales entre campos, otros utilizaban mecanismos de direccionamiento para saber dnde comenzaba y finalizaba cada campo, etc. Cada uno de estos mecanismos tena limitaciones.

Ahora bien qu es un modelo? Es un conjunto de conceptos utilizados para describir datos. Y por qu relacional? Porque est basado en la teora de conjuntos, donde el trmino "relacin" se aplica a una asociacin entre dos o ms elementos de un conjunto. O sea una tabla.

El modelo relacional est basado en "tablas", las cuales son "relaciones". Esto debe quedar bien claro: las tablas son las relaciones. Cada tabla est compuesta de filas y columnas. Repitamos mentalmente: las tablas son relaciones. "Tabla" y "relacin" son sinnimos.

La famosa "relationship" entre dos o ms tablas NO es la relacin que da el nombre al modelo relacional. Para eso, se utilizar el trmino vnculo, porque en espaol la traduccin de "relation" y "relationship" conduce desafortunadamente a la misma palabra "relacin". Por ello, la comunidad de habla hispana adopt otros trminos para referirse a "relationship", el ms aceptado es "vnculo". Recordemos, pues, que el "modelo relacional" se llama as porque las tablas son relaciones.

El modelo exige que cada tabla debe necesariamente tener una clave. Qu es una clave? Es el conjunto mnimo de columnas de la tabla que definen unvocamente la existencia de una fila. Por ejemplo, en una tabla PADRON la clave sera DNI, en una tabla ARTICULOS la clave sera (codigo_rubro,codigo_articulo), y as sucesivamente. Ntese que debe el conjunto "mnimo". En nuestra tabla PADRON, las columnas DNI y NOMBRE tambin definiran unvocamente la existencia de una fila, pero no sera un conjunto mnimo. Por esto se dice que DNI y NOMBRE no son una clave, sino una "superclave". En modelo relacional, las superclaves deben ser evitadas.

Las claves primarias, las candidatas, todas son claves. De esto se desprende que no pueden existir en el modelo relacional claves que sean repetidas, porque la definicin prohibe esto. La clave primaria sera nuestro ndice principal en VFP, la candidata nuestro ndice candidato en VFP.

Esto deriva en una consecuencia insospechada: como dijimos recin, en el modelo relacional no es posible que los campos que conforman la clave se repitan. Si lo pensamos un poquito, esto da como corolario que que ninguna tabla puede tener dos filas idnticas.

Pero nosotros, viejos programadores de FoxPro, sabemos que esto no es as, que muchos de nuestros sistemas tienen filas duplicadas, y que muchas tablas tienen los campos clave duplicados. Qu estar pasando? Lo vemos un poco ms adelante.El lgebra relacionalPor qu tanto alboroto con el modelo relacional? Porque era la primera vez que se describa una estructura de datos basndose en modelos matemticos precisos. Como las tablas son "relaciones", las operaciones entre esas relaciones form el llamado "lgebra relacional".

A ver si entendemos: as como existe una operacin de suma para los nmeros en el lgebra comn, existe una operacin de unin de tablas para el lgebra relacional. El lgebra comn opera con nmeros, el lgebra relacional opera con tablas. As como el lgebra relacional devuelve resultados que son otros nmeros, el lgebra relacional devuelve resultados que son otras tablas. Este es un concepto fundamental: los resultados del lgebra relacional son siempre tablas.Entonces, hacia 1973 el modelo estaba completo. Se definieron cinco operaciones bsicas para operar con las tablas, que formaron la base del lgebra relacional: seleccin, proyeccin, renombrado, reunin y unin. Cada operacin actuaba sobre tablas, y devolva necesariamente otras tablas.

Incluso para que el lgebra tuviese todas la operaciones, se deriv la operacin de divisin entre dos tablas, un tanto extica porque es la secuencia de varios operadores simples, y se la incluy para que el modelo del lgebra fuese cerrado y completo (es decir, hubiera siempre una forma de recorrer el camino inverso en una cadena de operaciones, por lo tanto, para una multiplicacin entre tablas - producto cartesiano - debera por lo tanto existir la divisin, etc.)

Si nos fijamos bien, no existe la operacin de borrado. En efecto, la operacin de borrado no se contempla en el lgebra relacional. Tampoco se contempla el "ordenado". Y entonces?Los lenguajes de bases de datos y la prctica vs. la teoraEl lgebra relacional di paso a que D.D. Chamberlin, que trabajaba en los laboratorios de IBM en San Jos, California, hacia 1973, y otros, dieran los primeros bosquejos de SQL, el lenguaje estructurado de consulta. Entonces, por ejemplo, la operacin de seleccion di paso a la clusula WHERE, la operacin de proyeccin di paso a la lista de campos que siguen a la clusula SELECT, la de reunin di paso a los JOINs en todas sus variantes, la de union a la SELECT... UNION... SELECT, y as sucesivamente.

Para cada operacin del lgebra, los investigadores de IBM dieron nacimiento a comandos especficos que los cubran. Haba una equivalencia de 1 a 1 con el lgebra de tablas y los comandos de SQL.

El mundo de las bases de datos le debe mucho a IBM. Sin sus investigadores, SQL no habra visto la luz. En cuanto a herencia y linaje, IBM es la madre de todas las bases de datos. Por ejemplo, fu la primera en resolver consultas recursivas en implementaciones dede motores comerciales (la clusula WITH RECURSIVE ya poda usarse en algunas versiones de DB/2 para mainframes) en pocas en que SQL 3 era slo un sueo. Oracle sera protagonista recin varios aos despus.

Pocos aos despus, los investigadores se retiraron de IBM, y formaron su propia empresa: The Relational Institute. El mismo sigue hasta la actualidad, investigando los fundamentos matemticos del modelo relacional, que parecen an hoy no tener fin.Existen slo dos lenguajes "puros" para bases de datos relacionales puras: el SQL y el QBE (consultas por ejemplo), creado por M. Zloof en 1975. Los dems no implementan totalmente el lgebra relacional, aunque cueste creerlo. QBE es un lenguaje que utiliza una grilla para armar las consultas, y no es declarativo, sino que uno ms bien rellena esa grilla de acuerdo de los criterios de filtrado, seleccin, etc, y el sistema ejecuta la consulta. Estuvo muy en boga hace unos aos, pero actualmente est en desuso, totalmente superado por SQL.

El lenguaje de consultas estructurado, SQL, ha pasado a ser la base para variados dialectos. Existen tres normas ANSI que definene los alcances del lenguaje, que se identifican con niveles o con los aos donde fueron promulgadas: nivel 1, para el ao 1989 (SQL 89), nivel 2, para el ao 1992 (SQL 92), y nivel 3 en 1999 (SQL 99).

Cada fabricante libera su dialecto SQL con un determinado grado de porcentaje de cumplimiento de la norma. De esta manera, tenemos que el fabricante XXX tiene un 80% de cumplimiento o adhesion a SQL nivel 2 (SQL 92), etc., y que el YYY tiene un 90 % de adhesin a la misma norma. Esto no indica que YYY sea mejor que XXX, slo significa que son distintos. Idealmente, sera bueno que exista un 100% de adhesin a los estndares, pero eso es algo casi imposible de lograr, debido a que implementar toda la norma dara un gestor de bases de datos extremadamente caro de construir. Hoy en da, ninguna de las bases de datos cumple 100% todas las premisas del modelo relacional propuesto por ANSI, por ejemplo, nadie soporta el operador DIVIDE de divisin entre tablas, o el operador INTERSECT el cual no es soportado ni siquiera por Oracle. Existen caminos para llegar a lo mismo, pero son combinaciones de comandos ms sencillos. Son, de hecho, soluciones de compromiso.

Un 80% de los fabricantes recin estn dando un porcentaje de cumplimento razonable al nivel 2. Slo unos pocos al nivel 3. Una honrosa excepcin a la regla es la IBM DB/2, la cual tiene un alto grado de adhesin a estos estndares, como era de preveerse, cercano al 100%.Tambin es de destacar el papel de la PostGRESQL, un gestor acadmico que tiene su versin en fuente abierta bajo licencia GNU, para el mundo de Linux, la cual es altamente compatible con el estndar, incluyendo algunas caractersticas de SQL3. Desafortunadamente, la IBM DB/2 es un gestor con una gran complejidad tcnica, y la curva de aprendizaje es francamente empinada si uno desea sacarle todo su potencial. En nuestras pruebas, el SQL Server ha resultado ser un gestor liviano, rpido y eficaz a la vez que relativamente fcil de aprender, con performance igual o superior a su contrincante del gigante azul. Algunos colegas podrn seleccionar la profundidad y rigidez tcnica de DB/2, mientras que otros se quedarn con la interfaz amigable e intuitiva de SQL Server. No estamos aqu emitiendo opinin alguna sobre las velocidades de estos gestores ni otros factores de performance, simplemente hacemos notar las distintas idiosincracias de dos contendientes mayores en la arena de las bases de datos, como lo son Microsoft e IBM.

Veamos un ejemplo de diferencia entre la teora y la prctica: el modelo relacional establece que una tabla no puede tener dos filas exactamente iguales, porque esto impedira que exista una clave. Y no puede existir una relacin sin una clave. Pero nosotros sabemos que en el mundo real eso no es as. El SQL Server permite generar tablas y cargar datos repetidos, lo mismo hace Visual FoxPro. Qu sucede? Sucede que no hay un grado de cumplimento total con la teora, que la prctica se aparta de la teora. En las bases de datos, la prctica siempre est a una saludable distancia de la teora. Esto siempre fu as, y por fundadas razones que veremos ms adelante.

Otro ejemplo: el resultado de una operacin de lgebra relacional debe ser otra relacin que cumpla con el modelo. Por lo tanto, el resultado de una seleccin debe ser una tabla sin filas repetidas. Pero en el mundo real, tampoco es as: por defecto, el resultado de una consulta SQL-SELECT puede dar filas repetidas. Para evitar repetidos, debemos utilizar la clusula DISTINCT y entonces cumplir con el modelo.

De estos ejemplos, se deduce que: los gestores comerciales de bases de datos en su comportamiento por defecto no trabajan totalmente de acuerdo al modelo, pero tienen mecanismos para forzar el cumplimiento del mismo si el programador as lo desea. Esto tambin es un concepto fundamental.Qu es un optimizador?El optimizador es la parte del gestor de bases de datos que se encarga de reducir al mnimo el traspaso de informacin de una jerarqua de almacenamiento a otra. En nuestro caso, minimiza el tiempo que se accede al subsistema de disco. Para lograrlo, existen diversos mecanismos que ayudan a que en tiempo en transferir la informacin de la jerarqua 2 (disco rgido) a la 1 (memoria RAM) sea el mnimo posible.

Porqu no optimizamos el acceso a la RAM? Porque el tiempo de acceso al disco es varias magnitudes ms grande que el acceso la RAM. Suponiendo tiempos promedios, para una SDRAM tpica oscila en unos 10 ns (10-9 seg.), mientras que para un disco rgido oscila en unos 5 ms (5x10-3 seg.). Ntese que existe una diferencia del orden de seis magnitudes (106) entre ambos. Por lo tanto, se gastan todos los recursos de lgica de programacin en acortar el tiempo de acceso al disco, con ello se tiene ms del 90% de la ganancia posible.Cuando un gestor de base de datos accede al disco, efecta una serie de operaciones que se conforman un mtodo de acceso. El optimizador simplemente altera el mtodo de acceso con un slo objetivo en mente: minimizar el tiempo que duran sus operaciones.Los ndices: qu son y qu no sonEntonces llegamos al punto de tener que preguntarnos qu son los ndices? Son necesarios?

La respuesta es desconcertante: NO. Cualquier sistema de bases de datos relacional debe poder funcionar sin los ndices.Entonces la pregunta de rigor es para qu sirven los ndices? sirven para ordenar? La respuesta es an ms desconcertante: Los ndices NO sirven para ordenar. Su cometido es otro.Entonces, veamos precisamente lo que es un ndice y para qu existe: Un ndice es una estructura externa fsica de una tabla. No forma parte del modelo relacional, ni del lgebra relacional (por eso cualquier motor de bases de datos debe servir an sin tener un slo indice definido). Su nico cometido es acelerar el acceso a los datos. El gestor de base de datos los utiliza para alterar su mtodo de acceso. El hecho que eventualmente ordenen datos es un efecto casual de cmo estn estructurados los ndices. Los ndices son tablas, por lo tanto, los ndices tambin son relaciones. Los indices tienen dos columnas: una columna, la primera, contiene el valor de la clave, en el caso del ndice se llama "clave de bsqueda". Por ejemplo, si tenemos un indice por codigo_articulo+codigo_sucursal, en la primera columna irn todos los valores de esa expresin. En la segunda columna se graba lo que se conoce como RID (record identification). El RID es un par ordenado de nmeros enteros, el primer nmero indica el nmero de la pgina del archivo de la tabla donde se encuentra el registro que tiene la clave grabada en la primera columna, el segundo nmero indica la posicin del registro dentro de la pgina. Existen otras organizaciones ms complicadas, pero todas son derivadas de este concepto de< pagina,RID>.Tipos de ndices en gestores convencionalesEstos conceptos que se indican a continuacin son aplicables a bases de datos relacionales en general. Ms adelante veremos que slo son implementables en bases de datos servidoras, en las de escritorio, tales como VFP, se utilizan derivados de estas aproximaciones.

Todos los ndices sirven para lo mismo: acelerar el acceso a los datos. Cmo hacen esto? Del mismo modo que el ndice de un libro: si queremos leer un segmento del libro, buscamos primero en el ndice. Si el libro no tuviese ndice, deberamos explorar todas la pginas desde el principio hasta hallar lo que necesitamos. Con las tablas pasa lo mismo. Ante la carencia del mismo, el gestor deber "escanear" todas las pginas del archivo de la tabla para encontrar el registro deseado.

Existen dos tipos de ndices:

Indices clustered o agrupados. El ndice clustered tiene una caracterstica: hace ordenar fsicamente al archivo de la tabla de acuerdo al ordenamiento interno del propio ndice. En otras palabras, si tenemos un indice 'clustered' por nombre de una persona, la tabla misma se ordenar alfabticamente por esa columna. Indices normales (esto siempre referido a gestores de bases de datos servidoras, no de escritorio, veremos luego las diferencias, pero por ahora los conceptos son genricos para bases de datos relacionales servidoras). Son los que no son clustered, aunque esta es una clasificacin muy general, servir para nuestros propsitos.

Nosotros dijimos que el ordenamiento es un resultado colateral del ndice. La razn de esto es la siguiente: para ubicar un dato en un ndice, es necesario utilizar algn algoritmo. El ms adecuado fu en su momento el llamado de "busqueda binaria", y consiste en:

Ir a la mitad del ndice, y preguntar si el valor que estamos buscando es menor que la clave de bsqueda en la mitad del archivo. Si es menor, entonces descartamos la mitad inferior del archivo del indice, porque sabemos que el dato buscado estar en la mitad superior. Si es mayor, entonces descartamos la mitad superior del archivo de ndice, porque sabemos que el dato buscado estar en la mitad inferior. Luego vamos a la mitad del segmento que qued remanente, y repetimos la pregunta. Este mecanismo se repite hasta que se produzca la coincidencia.

Figura 1: Bsqueda binaria simple.El tiempo que se necesita para encontrar un dato es uno de los menores posibles, siempre y cuando la tabla que representa el ndice est ordenada. Si la tabla que contiene al ndice no est ordenada, la bsqueda binaria no sirve, no funciona. Es por esta razn que los archivos de ndices estn ordenados, pero esto es una necesidad del algoritmo de bsqueda binaria, no el fin primordial del ndice.

Una vez que se ubica el RID en la tabla del ndice, es relativamente rpido ubicar el registro de datos de la tabla verdadera.La pregunta normal sera entonces: porqu no hacemos una bsqueda binaria en las tablas, de esa manera nos evitaramos el ndice? La respuesta es que eso sera aplicable si slo existe un ndice por tabla, pero si llegamos a necesitar cinco ndices sobre una misma tabla, es inaplicable. Por lo tanto, se necesitan archivos que sean externos a las tablas - los ndices.

Otro concepto fundamental: como el ndice tiene menor cantidad de informacin que la tabla propiamente dicha, es mejor buscar primero en el ndice que en la tabla, ya que hay que transferir menor cantidad de informacin del disco a la memoria para ser procesada.

Como el ndice clustered ordena la tabla fsica de acuerdo a su propio ordenamiento, es que slo puede existir un ndice clustered por tabla (obviamente, una tabla no puede estar fsicamente ordenada por dos o ms claves distintas al mismo tiempo). Entonces, dentro de los ndices, el clustered ser el ms veloz, ya que la tabla mantiene el ordenamiento igual que el ndice. El resto de los ndices tendrn un rendimiento menor. Por esta razn, cuando se define una clave primarial en una tabla de SQL server, el gestor automticamente impone un ndice clustered en virtud de su mayor rendimiento.El optimizador y el plan de accesoDijimos que el optimizador minimiza tiempos. Hablando en la jerga de los gestores de bases de datos, diremos que minimiza el "costo" de la consulta para que sea el menor posible. El mtodo que se usa para acceder al disco se llama "plan de acceso". Una consulta puede tener una infinidad de planes de acceso, el tema es encontrar el mejor de todos ellos, es decir, el que involucre el menor costo.

En qu se mide el costo de la consulta? Inicialmente se meda en ticks del microprocesador, mientras ms ticks necesita ms cara ser la consulta. Actualmente, se definen otras unidades de medida. Las ms modernas involucran tiempo de acceso al disco, velocidad del frontside bus del procesador, velocidad de la RAM, velocidad del procesador, etc., as algunos gestores definen unidades de medida abstractas. Por ejemplo, en la DB/2, los ingenieros de IBM definieron una unidad de medida llamada "timeron", etc.

De todos modos, recordemos que ms del 90 del tiempo gastado en una consulta se consume en el subsistema de disco. Por lo tanto, de poder minimizar el tiempo de acceso al disco, estaramos optimizando en gran medida el costo de la consulta. Esto es lo que hacen la mayora de los gestores en primera instancia, de eso se encarga primordialmente el optimizador.Existen entonces distintos tipos de optimizadores:

Automticos o heursticos: constantemente intentan optimizar la consulta. Para ello disponen de una base de conocimientos provista por el fabricante, y celosamente programada en el motor de la base de datos, y de un motor de inteligencia artificial - aunque usted no lo crea, es bsicamente una red neuronal. Supongamos que una consulta complicada tenga 100 formas distintas de ejecutarse. debera el optimizador averiguar cul es la optima? Si lo hiciere, gastara ms tiempo averiguando la solucin perfecta que ejecutando dicha solucin. Por lo tanto, en motor de inteligencia artificial lo que hace es: buscar una solucin aceptablemente buena (heurstica) en un tiempo tal que no comprometa el gasto total. De esas 100 formas, slo examinar 5 6. Posiblemente la solucin no sea perfecta, pero como no se consume mucho tiempo decidiendo cul usar, el tiempo total se ve optimizado. Funcionan en tiempo de ejecucin. Los ms avanzados efectan una reescritura de la consulta, de tal manera que uno nunca est seguro si la consulta que se escribi es la que realmente se ejecuta.

Por sintaxis o cdigo: depende del programador. Las consultas deben escribirse apropiadamente para que el gestor de base de datos utilice la optimizacin. Es obviamente, en tiempo de diseo. El ejemplo ms claro es la correcta escritura de las expresiones bsicas optimizables de Rushmore.

Por asistentes: lo que hacen en realidad es optimizar el cdigo a travs de un asistente, en tiempo de diseo. Es una variacin del segundo. Generalmente son interfaces grficas que descomponen la consulta en sus procesos bsicos, y los muestran en una especie de flujograma con smbolos geomtricos sencillos. Cada smbolo representa un proceso primitivo o bsico del gestor de bases de datos, y por cada uno se evala un costo. El programador deber examinar este diagrama y determinar dnde est el cuello de botella de su consulta, para adicionar ndices, etc. Algunos asistentes hacen sugerencias acerca de los ndices que faltaran para mejorar la consulta.

Los optimizadores automticos estn en todas las bases de datos servidoras, y los fabricantes jams revelan mucho acerca de cmo funcionan, porque ese es su secreto. El del SQL Server es ciertamente refinado y poderoso, si bien gran parte de su actividad es secreta y en segundo plano. Tambin depende de estadsticas recolectadas a travs del tiempo que ayudan al motor de decisin a encotrar rpidamente una solucin aceptablemente buena.

Existen otros mtodos de mejora de tiempo de respuesta, pero no actan sobre el costo de la consulta, sino reasignando los recursos de procesador y memoria al gestor de base de datos a travs de mecanismos de "paralelizacin". En efecto, aunque el equipo disponga de un slo procesador, algunos motores de bases de datos permiten ejecutar en paralelo ciertas partes de la consulta (paralelismo intra-consulta - intraquery parallelism). Uno de los ejemplos ms notables es el Oracle, donde se puede exigir que determinada consulta se ejecute en paralelo insertando ciertas directivas (hints) entre delimitadores especiales en el cdigo de la consulta. Estas directivas se evalan por el compilador, y se ejecuta en paralelo. El preprocesador del compilador decide qu segmentos de cdigo son aptos para paralelismo. En nuestras pruebas, en un padrn de 1.980.000 registros, sin ndice alguno, sin paralelismo (funcionamiento normal) el Oracle 8.0.x arroja un tiempo de 1 (20 segundos), con paralelismo activado - limitando a 2 procesos paralelos en la consulta - el resultado es de 0,4 (8 segundos), es decir, un ahorro de tiempo de 60%.

Microsoft sin duda no se quedar atrs, pronto alcanzar este tipo de sofisticacin, las nuevas versiones de SQL prometen ser las mejores bases de datos jams construidas. Recordemos adems que VFP y SQL Server tienen una perfecta sinergia para construir sistemas, y SQL Server las menores tasas de consumo de recursos - eso lo hemos comprobado.Optimizaciones en VFPEn Visual FoxPro, como en casi todas las bases de datos de escritorio (las que no son client-server), no existe el concepto de ndice clustered. Las tablas por lo general son archivos de registros desordenados (heap-files), es decir, no tenemos porqu asumir que las tablas de VFP deban estar ordenadas, a diferencia de las de SQL Server, IBM DB/2 u Oracle, donde de existir una clave primaria, se presume la existencia de un ndice clustered que ordena fsicamente la tabla.

Nosotros podemos emular la existencia de ndice clustered en VFP corriendo peridicamente el comando SORT sobre los campos de la clave del ndice, y crear sobre la nueva tabla los ndices que sta tena, pero hasta all podemos llegar.

En VFP existen tres tipos de optimizaciones: (1) la automtica, (2) la explcita, por cdigo del programador, y la (3) implcita, que opera sobre las marcas de borrado. Lo que s es automtico es la utilizacin de los ndices si el optimizador encuentra una clusula correctamente escrita.Optimizacin automtica VFP evala si existen algn ndice creado que coincida con la clusula WHERE o FOR. Si existe, utilizar los ndices.

Si no existen, evaluar el tiempo de imposicin de los ndices. Si el tiempo estimado para crear un ndice sobre la clave de bsqueda definida en la clusula WHERE o FOR es menor que el tiempo para ejecutar la consulta, VFP crear primero un ndice temporal y luego ejecutar la consulta sobre ese ndice. Para tomar una decisin, primero debe medir el tiempo de acceso al disco, la cantidad de memoria disponible, la cantidad de disco libre, el nmero de filas a indexar, etc. Los ndices temporales se almacenarn en el directorio definido por TMPFILES en CONFIG.FPW, o en el directorio temporal por defecto dado por la funcin SYS(2023) en Visual FoxPro.

Es poco probable que sea una optimizacin heurstica tal como la que presentan las bases de datos servidoras, debido al reducido tamao del motor VFP es que seguramente ser un algoritmo ms directo y compacto. Creemos ms bien que todo el esfuerzo fu puesto en el mecanismo de indexacin, y de recuperacin y evaluacin de ndices, con un algoritmo ultra veloz - el mejor de la industria. Sin embargo, esto son slo especulaciones basadas en la poca evidencia que podemos ver desde el exterior.

VFP No presenta mecanismo de almacn de estadsticas, ni mantiene registros de planes de acceso de las consultas efectuadas, por lo tanto, es casi seguro que no existe una heurstica basada en tal base de conocimiento.

Como era de preveerse, ni Fox Software ni Microsoft han dado mayores detalles acerca del mecanismo de decisin de optimizacin de VFP.Optimizacin explcitaLa optimizacin explcita consiste en hacer coincidir la expresin de una clusula de comparacin FOR o WHERE con la expresin con la que se construy un ndice. Es decir, el programador explcitamente optimiza el cdigo de consulta o de comandos xBASE. Si se cumplen ciertas condiciones entonces es de uso automtico.

Por ejemplo, si se ha creado un ndice con:

INDEX ON codart+codsuc TAG i1Lo correcto es hacer una consulta tal comoSELECT * FROM artic WHERE codart+codsuc=lcArticlo cual quedara correctamente optimizada, y lo incorrecto sera hacerlo sobreSELECT * FROM artic WHERE codart=lcArticen cuyo caso, al no encontrar VFP una expresin explcitamente optimizada, intentar imponer una optimizacin automtica. Ntese que para que la sentenciaSELECT * FROM artic WHERE codart+codsuc=lcArtic

sea efectiva, la comparacin ANSI debe estar en OFF, de otra manera, para que la igualdad devuelva TRUE, ambas cadenas debern tener el mismo largo (asumiendo comparaciones de cadenas), y en general devolvern FALSO porque lcArtic es una variable de memoria que contiene slo una parte de la clave de bsqueda la cual contiene aqu 2 campos.Optimizacin implcitaLa optimizacin implcita acta sobre la marca de borrado. Para ello, cada tabla que participa de una consulta, de un filtrado o de un comando que acepte clusula FOR, deber tener un ndice sobre la marca DELETED(). Por ejemplo, un ndice tal como:

INDEX ON DELETED() TAG deltd

debe existir en cada tabla del sistema que participe en consultas o filtrados para que efectivamente ocurra la optimizacin implcita.

Esto es as porque el motor de optimizacin Rushmore agrega invariablemente una clusula invisible si SET DELETE est en ON:

...AND NOT DELETED()

Por lo tanto, de tener ese ndice disponible, se lo utilizar y la consulta ser 100% optimizable. En otras palabras, la optimizacin implcita siempre est presente. De esto se desprende que todas las optimizaciones de cdigo explcito que podamos escribir no sern 100% optimizadas a menos que exista el ndice sobre DELETED(). Ntese que en las bases de datos cliente-servidor, no existe el concepto de marca de borrado porque en el lgebra relacional no hay tal concepto: o un conjunto tiene un elemento, o no lo tiene.

Si hablamos estrictamente, las bases de datos client-server tambin utilizan marcas de borrado, pero lo hacen autnomamente, y el usuario no puede interactuar con la misma. Las marcas de borrado se almacenan en un lugar de la pgina, y al conjunto de estos datos se le da el nombre de "mapa de bits". Cada bit representa una fila dentro de la pgina, de acuerdo a su posicin dentro del mapa. Cuando existe un TRUE, el registro correspondiente tiene datos vlidos. Cuando est en FALSE, el registro correspondiente est vaco o tiene datos que son "sobreescribibles", pero para el usuario final, esos datos no estn disponibles, estn efectivamente borrados.Cuando no se puede optimizar con ndices?Cuando VFP determina que no se puede optimizar, no le queda otro camino que escanear (explorar) todas las pginas del archivo. Desafortunadamente, este es un proceso lento, ya que debe cargar todas las pginas en la memoria y esto consume gran cantidad de tiempo.

Existen mecanismos para optimizar el acceso a las pginas aunque no se disponga de un ndice. Uno de los ms utilizados es el mecanismo de archivo disperso (hashed file). El motor de base de datos implementa una funcin de dispersin (hash function) representada para nuestros propsitos como H(). El argumento de H es el dato que deseamos ubicar, y la funcin devuelve en forma de nmero entero positivo una posicin posible del dato.

Por ejemplo, H("carlos") puede devolver 1632. Este nmero representa un conjunto de pginas o bucket (cubo). Si las pginas 200,201,202 y 203 tienen nmero de bucket 1632, entonces el motor de base de datos busca en esas 4 pginas y no en todo el archivo. Cuando se crean las tablas el gestor de bases de datos ya crea las mismas asociadas a los buckets iniciales.

Figura 2: Archivo disperso.El truco est en programar la funcin de dispersin H para que no se produzca un congestionamiento de pginas y que se direccionen los datos parecidos al mismo bucket. Si esto sucediese se corre el riesgo de que la funcin de dispersin mande a buscar los datos en demasiadas pginas a la vez, y entonces perdera razn de ser. Esto se evita con una cuidadosa programacin del algoritmo en la funcin de dispersin, la cual suele ser inescrutable y bastante complicada, a la vez que veloz.

Desafortunadamente, no creemos que VFP utilice esto en las tablas -Microsoft nunca dijo nada al respecto- ya que el mtodo de dispersin necesita ms almacenamiento que una base de datos regular. Por ejemplo, si una tabla ocupa 100MB, con el archivo disperso ocupara 125MB, ya que el 25% se mantiene siempre como buckets de reserva. El motor de base de datos reserva este espacio en el mismo momento que se crea la base de datos. Como VFP no utiliza un contenedor fsico centralizado - todas son tablas sueltas que se presentan logicamente unidas al estar presente una DBC - lamentablemente el mtodo de dispersin no es aplicable. Como sabemos, la base de datos de VFP es un contenedor lgico, no fsico, (eso significa que no existe como unidad sino desde dentro de VFP). Como contrapartida, una base de datos servidora normalmente tiene asociado un espacio de tablas (tablespace), el cual normalmente es un archivo, directorio o volumen unitario - puede despus adicionarse ms elementos al mismo espacio de tablas.

Algunos motores de bases de datos aplican el mismo concepto de archivo disperso a los mismos ndices (porque despus de todo, los ndices tambin son tablas), dando an ms rendimiento a los ndices normales, y utilizan un algoritmo de busqueda binaria aplicable slo a un subconjunto de pginas.

VFP, en cambio, adopta otra filosofa. Por compatibilidad, la forma de almacenar los datos deben ser archivos DBF sueltos - sino, no sera FoxPro. Esto elimina la posibilidad de utilizar archivos de dispersin, y slo deja la opcin de utilizar lo ms eficientemente posible los ndices cuando se desee optimizacin.NOTA: No debemos confundirnos con las operaciones de JOIN resueltas mediante estructuras de dispersin (hashed joins), que son mecanimos que permiten resolver JOINs entre tablas con mucha eficiencia. Este tipo de JOINs utilizan una tabla de dispersin en memoria. En el prrafo anterior, nos estbamos refiriendo a archivos almacenados en el disco con estructura dispersa (hashed file), no a la operacin JOIN basada en esta tcnica. La explicacin de cmo funciona esta clase de JOINs va ms all del propsito de esta nota, y posiblemente ser tema para futuros documentos. De hecho, nosotros creemos que VFP puede ejecutar algo parecido a hashed JOINS si ciertas condiciones se cumplen- aunque por supuesto, son slo inferencias.

Por lo tanto, de no existir ndices, VFP no puede ejecutar la optimizacin que mejores resultados brinda .Esto puede parecer desalentador a simple vista, pero miremos desde este punto de vista: VFP es una coleccin de funciones de acceso a datos escritas en C++ (posiblemente con algunos segmentos de assembler). Ninguno de nosotros podr escribir algo mejor. Por lo tanto, se pude asumir sin dudas que el uso de ndices que hace VFP al optimizar las consultas es el mejor posible. Teniendo esto siempre en mente, al programador slo le queda disear cuidadosamente el conjunto de ndices a utilizar en funcin de las consultas esperadas del sistema.SYS(3054) y el plan de accesoEl plan de acceso en FoxPro - que en nuestro caso es sinnimo de cmo se efecta optimizacin - puede averiguarse con la funcin SYS(3054). Por ejemplo, veamos un sencillo caso de consulta simple.

SELECT * FROM solic WHERE nrorec="00001452"

Donde se ejecuta una consulta sobre la tabla SOLIC.DBF, que por ahora no tiene ningn ndice. Veremos estos distintos casos.Activemos primero la exhibicin del plan de acceso. La funcin SYS(3054,x) tiene un argumento segundario, x, el cual puede tomar los siguientes valores:

0 = no se muestra el nivel de optimizacin. 1 = slo se muestra el nivel de optimizacin de clusulas FOR, y de clusulas WHERE que no incluyan combinaciones entre tablas, es decir , de seleccin (filtrado) de datos. 2 = se muestran niveles de optimizacin para filtros y para combinaciones indistintamente.Filtrado de tablasEn lgebra relacional existe el operador de seleccin, el cual indica la operacin de seleccin de registros o filas (la letra griega sigma es la "s"), y se aplica a la operacin de filtrado de tablas - es decir, seleccin de registros. Por ejemplo, para indicar en lgebra relacional la seleccin de el registro de la tabla SOLIC que tenga el numero de recibo igual a "00001452", indicaramos as:

El comando equivalente de SQL para esa operacin de seleccin sera:

SELECT * FROM solic WHERE nrorec="00001452"

donde se impone un filtrado a la tabla. Para ver si se utiliza o no el ndice, debemos usar la funcin SYS(3054). Coloquemos pues =SYS(3054,2) en la ventana de comandos para activarla y observemos lo que sucede:

EjecutemosSELECT * FROM solic WHERE nrorec="00001452".

Al no tener ndices, no existe ningn tipo de optimizacin, en la ventana del escritorio de VFP se devuelve lo siguiente:

Nivel de optimizacin Rushmore para tabla Solic: nada

Ahora impongamos un ndice para la columna liquid mediante

INDEX ON nrorec TAG nrorec

El ndice puede ser de cualquier clase, no necesariamente compacto CDX. Una vez indexado, reemitamos la consulta

SELECT * FROM solic WHERE nrorec="00001452"

y podremos verificar este nuevo mensaje:

Utilizando indice de etiqueta Nrorec para optimizar con Rushmore tabla solicNivel de optimizacin Rushmore para tabla Solic: parcial

Como era de esperarse, se utiliza el ndice para optimizar la consulta. Sin embargo, la optimizacin no es completa porque el filtro se impone utlizando el ndice y la marca de borrado, que se evala siempre que SET DELETED est en ON, como es nuestro caso en la mayora de las veces. Por ello, al estar SET DELETED ON, VFP agrega internamente una clusula AND NOT DELETED() a la consulta. Como no existe el ndice sobre DELETED(), la optimizacin es parcial.

Verifiquemos esto. Coloquemos SET DELETE OFF y reemitamos la misma consulta. Esta vez el resultado arroja:

Utilizando indice de etiqueta Nrorec para optimizar con Rushmore tabla solicNivel de optimizacin Rushmore para tabla Solic: completo

Ntese que al no tener que evaluar la marca de borrado, VFP impuso el filtro para armar la consulta exclusivamente basndose en el ndice sobre la columna NROREC, por lo tanto, la optimizacin fu completa.

Ahora coloquemos SET DELETE ON nuevamente, como ocurre con la mayora de nuestros sistemas - pensemos que seran poco tiles si no ignorasen la marca de borrado. Con este ajuste en ON, indexemos ahora por la marca de borrado a travs de esta sentencia:

INDEX ON DELETED() TAG Deltd

NOTA: Si bien el nombre del tag puede ser "deleted", como en este ejemplo:

INDEX ON DELETED() TAG deleted

autores como Pat Adams, una de las gures de FoxPro 2.x, desaconsejaban este comportamiento, en parte para mantener al mximo la portabilidad del cdigo (dBASE IV no era tan indulgente como FoxPro en el uso de las palabras reservadas, as como otros lenguajes tampoco).

Con el ndice sobre la marca de borrado ya impuesto, se reemite la consulta, y el resultado es ahora -con SET DELETE ON - el mismo que se obtuvo con [SET DELETE OFF y sin ndice sobre DELETED]

Utilizando indice de etiqueta Nrorec para optimizar con Rushmore tabla solicNivel de optimizacin Rushmore para tabla Solic: completo

Se tiene una optimizacin completa, ya que se utilizan ambos ndices para la consulta. En este caso, la clusula where queda escrita de la siguiente manera:

SELECT * FROM solic WHERE nrorec="00001452" AND NOT DELETED()

donde

nrorec="00001452"

es la condicin colocada por nosotros en el cdigo, y

AND NOT DELETED()

es la condicin agregada por VFP automticamente al estar SET DELE ON.

Cuando se tiene un operador AND, el optimizador interrumpe la evaluacin cuando el primer operando devuelve FALSE, es decir, cuando nrorec no es igual a "00001452", se descarta la fila, y ni siquiera se evala la marca de borrado.

NOTA: Cabe preguntarse entonces si no sera mejor ubicar NOT DELETED() delante y nrorec="00001452" despus, de tal forma que sea la marca de borrado la que se evale primero. Esto no sera conveniente porque existen muchos menos registros que cumplan la condicin nrorec="00001452" que registros que cumplan la condicin DELETED(). De esto deducimos que siempre conviene colocar la condicin ms restrictiva al comienzo de la cadena de ANDs, a fin de minimizar el tiempo de proceso de VFP al evaluar la condicin lgica. El disponer as la clusula FOR o WHERE es tarea del programador, y es un ejemplo ms de optimizacin explcita a cargo de nosotros. En bases de datos servidoras, este reacomodamiento est a cargo del optimizador automtico, ya que a travs de estadsticas y de las caractersticas de las tablas, saben cul de las condiciones ser la ms restrictiva. Por ejemplo, un gestor avanzado de BD colocar primero una condicin que afecte una clave primaria - slo habr como mximo una coincidencia.VFP y Select-SQL filtradoCuando se efecta una consulta SELECT-SQL con una condicin de filtro, es probable que VFP haga esta operacin:

1. Se abre la tabla de origen en otra rea seleccionada en el momento. No es posible predecir el rea de trabajo que VFP seleccionar para ejecutar el equivalente a un USE .. AGAIN NOUPDATE

2. Se impone un filtro sobre la tabla recin abierta utilizando el ndice. De no existir el ndice ,se indexa temporalmente basndose en si conviene o no hacerlo por mediciones de procesador, memoria, etc.

3. Como resultado, se obtiene un cursor de slo lectura. Este cursor est asociado a una tabla subyacente, por eso para evitar cambios en entornos multiusuarios se marca el cursor como slo lectura (ver NOUPDATE).

La operacin es muy rpida porque no hay transferencia de informacin de la tabla de origen al cursor de resultados, simplemente se vuelve abrir la tabla en otra rea de trabajo. La imposicin del filtro sobre el ndice es extremadamente rpida.

Si no se desea que se utilice este mecanismo, debe adicionarse la clusula NOFILTER en SELECT-SQL, entonces efectivamente se crea un cursor independiente en el directorio indicado por SYS(2023). Este cursor, por compatibilidad, seguir siendo de slo lectura. Sin embargo, es probable que nunca se grabe en el disco sino en el cach administrado por VFP. Hasta tamaos de cursores igual a un 25% de la memoria RAM fsica, el cursor se mantendr en la memoria. La funcin DBF() ejecutada con el alias del cursor como argumento devolver una informacin de archivo que es inexistente. Es por esta razn que cuando uno cierra el cursor, no quedan rastros de l en el directorio SYS(2023): sencillamente, nunca se grab fsicamente nada all.

En versiones de FoxPro 2.x donde la clausula NOFILTER no est disponible, debe adicionarse un campo calculado o virtual a la consulta para impedir que FoxPro utilice el mecanismo de filtrado y USE..AGAIN NOUPDATE. Supongamos que deseamos ejecutar esta consulta.

SELECT * FROM artic WHERE codrub+codart="01"

como vimos, esto ser una consulta filtrada con USE..AGAIN NOUPDATE.Si deseamos evitar que se use el filtro, podemos digitar

SELECT *,.F. AS otrocampo FROM artic WHERE codrub+codart="01"

con ello FoxPro crear otro cursor en el directorio SORTWORK o en su defecto en TMPFILES. Si no hay nada especificado en esas variables de entorno DOS, entonces se usar el mismo directorio donde residen los programas en ejecucin - lo que no es muy recomendable porque hay que efectuar su remocin manualmente.Reunin (combinacin) de tablas y su optimizacin.El lgebra relacional contempla otra operacin bsica: la reunin de tablas (JOINs). Para que la operacin de reunin pueda darse, es necesario que exista un condicin de reunin. Por ejemplo, existe una tabla EMPLEADOS y una tabla DEPARTAMENTOS (el viejo ejemplo). Para efectuar una reunin, es necesario que existan al menos una columna en comn en cada tabla. Supongamos que esta columna en comn sea empID (identificador de empleado), y que la misma exista en ambas tablas.

La reunin de EMPLEADOS (E) y DEPARTAMENTOS (D) sobre la columna empID quedara expresada en lgebra relacional como:

donde la condicin de reunin es E.empID=D.empID. Como la condicin de reunin es una igualdad, entonces se tiene la llamada equi-join. El comando SQL que materializa la reunin sera:

SELECT E.*,D.* FROM empleados E INNER JOIN departamentos D ON E.empID=D.empID

que es la sintaxis correcta para la reunin. Tambin se permite la denominada reunin implcita, que se da cuando la condicin de reunin va en la clusula WHERE de la consulta:

SELECT E.*,D.* FROM empleados E,departamentos D WHERE E.empID=D.empID

NOTA: El lgebra relacional no indica cul condicin de comparacin se debe usar en la condicin de reunin. Incluso puede utilizarse un operador que no sea el signo igual, es decir, se permiten reuniones de no sean equi-join. Por ejemplo: cuya consulta equivalente sera:

SELECT E.*,D* FROM empleados E INNER JOIN departamentos D ON E.empID