Optimización de Consultas SQL parte II

Posted Junio 16, 2007 by roquesalde
Categories: Técnico

Continuando con el post iniciado por mi compañero Lucas Forchino enunciaré algunos tips a tener en cuenta a la hora de generar la sentencia SQL de manera que el motor de BD la ejecute más eficientemente.

Comenzaremos con tres puntos en particular a tener en cuenta y entender porqué mejoran tanto nuestras sentencias SQL.

  • EMPAREJAMIENTOS EN WHERE VS. EMPAREJAMIENTOS EN EL FROM
    • ORDEN DE PROCESAMIENTO DE UNA CONSULTA MULTITABLA
  • COMPOSICIONES EXTERNAS (EN EL WHERE Y EN EL FROM)
  • QUERY PERFORMANCE

COMPOSICIONES EN EL WHERE VS. COMPOSICIONES EN EL FROM

Debido al orden de procesamiento de una consulta multitabla el motor de BD se ve beneficiado si las composiciones son realizadas en el FROM a través de INNER JOIN o alguna de sus variantes (LEFT OUTER JOIN, RIGHT OUTER JOIN). Esto se debe a que el motor al procesar una consulta SQL lo hace en este orden:

  • Realiza el producto cartesiano de las tablas en el FROM
  • Si existe cláusula WHERE aplica la condición de búsqueda
  • Para las filas restantes calcula el valor de cada elemento en la lista del SELECT
  • Si existe un SELECT DISTINCT elimina las filas duplicadas
  • Si existe un ORDER BY ordena el resultado

Al ser el primer paso el producto cartesiano de las tablas que se encuentran listadas en el FROM, dependiendo del número de columnas de cada tabla y la cantidad de registros en cada una de ellas, se genera un resultado que puede llevarle demasiado tiempo al motor de BD, y luego tiene que aplicar la condición existente en la cláusula WHERE para reducir el número de registros resultante del producto cartesiano. Si nosotros realizamos la composición directamente en el FROM evitamos utilizar la cláusula WHERE para dicho propósito haciendo mucho más eficiente la consulta, ya que al momento de realizar el producto cartesiano estamos diciéndole al motor qué registros queremos de ese producto. La sintaxis sería la siguiente:

                SELECT F.numFactura,C. CliNom, F.Monto

                FROM Factura F INNER JOIN Cliente C ON F.codcli=C.codcli

Como vemos no necesitamos la cláusula WHERE para realizar el emparejamiento de las tablas, si sería necesaria la cláusula WHERE  si quisiéramos filtrar los resultados de dicha consulta por fecha o monto por ejemplo. Si nuestra composición entre tablas requiere más de un campo y más de dos tablas la sintaxis sería la siguiente:

SELECT F.numFactura, C.cliNom, F.Monto, V.venNom

FROM Factura F INNER JOIN Cliente C ON F.tipoDoc=C.tipoDoc     AND F.numDoc=C.numDoc INNER JOIN Vendedor ON F.codVen=V.codVen

COMPOSICIONES EXTERNAS

Al realizar composiciones internas o INNER JOIN entre dos tablas, los registros que no se correspondan en ambas tablas son eliminados de la lista de resultados, si yo no deseo que se eliminen los registros de una o ambas tablas aunque queden desemparejados debo realizar composiciones externas. Por ejemplo:

join_00011.jpg

Existen registros en la tabla TMARCAS que no se encuentran en la tabla TCOCHES, si yo realizo una composición interna esas marcas no formarían parte de mi conjunto de resultados. Al realizar una composición externa podría recuperar todo el conjunto de resultados, las composiciones externas dependen del orden en el que se listen las tablas:

SELECT TC.Coche, TM.marca

 FROM TCOCHES TC RIGHT OUTER JOIN TMARCAS TM ON TC.marca=TM.codigo

QUERY PERFORMANCE

Buenas prácticas para mejorar nuestras consultas SQL

  • Realizar las composiciones en el FROM
  • Tener en cuenta el orden en el que enunciamos las tablas en el FROM
  • Uso de funciones de T-SQL
  • Evitar el uso de SELECT *
  • Evitar el SELECT DISTINCT y el ORDER BY

Estas fueron unas breves recomendaciones a tener en cuenta a la hora de generar nuestras sentencias SQL, más adelante seguiremos con este tema, por ejemplo el uso de subconsultas, consultas en el FROM, uso de IF y CASE para condiciones, etc. las cuales son fundamentales a la hora de realizar nuestros procesos ETL.

Optimización de consultas SQL

Posted Junio 3, 2007 by lucasforchino
Categories: Técnico

Uno de los temas más importantes en el desarrollo de cubos y reportes es el tiempo de procesamiento y ejecución. Cada día se necesita procesar mayor cantidad de datos y obtener de manera más rápida y precisa la información. Muchos de los problemas de rendimiento se deben entre otras cosas  al hardware, al software, al motor de base de datos y por sobre todo al diseño, índices y mala formulación de consultas SQL. En este apartado nos centraremos en estos últimos en donde siguiendo algunas recomendaciones veremos que se puede  mejorar el tiempo de respuesta de nuestro motor de BD significativamente.

A la hora de diseñar la base de datos

·         Las tablas normalizadas permiten reducir al mínimo el espacio ocupado por nuestra base y permiten asegurar la consistencia de la información al mismo tiempo que son muy rápidas para la realización de transacciones, pero generan un mayor tiempo de demora a la hora de consultarlas ya  que se deben realizar generalmente la unión de varias tablas, por lo que en caso de necesidad de altas velocidades de respuesta con grandes volúmenes de datos un modelo desnormalizado es más que conveniente teniendo en cuenta todas las implicancias del caso.

·         Ajustar al máximo el tamaño de los campos ayuda a no desperdiciar espacio.

·         Eliminar todo campo que no sea de utilidad ya que por más que  no contenga datos genera retrasos.

Que pasa con los índices

·         Los índices son campos que permiten la búsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo cuentan con la desventaja que hacen más lenta la actualización, carga y eliminación de los registros ya que por cada modificación en la tabla se deberá modificar también el índice, además se debe tener en cuenta el hecho de que los índices también ocupan espacio en disco. Es por esto que no  es factible indexar todos los campos de la base y se hace necesario seleccionarlos cuidadosamente. Cabe destacar que por defecto las tablas no contienen índices por lo que la introducción de estos puede llegar a producir mejoras de más del 100% en algunos casos.

Los campos que se recomiendan indexar son:

o   Claves Primarias

o   Claves Foráneas

o   Campos por los cuales se realizaran búsquedas

o   Campos por los cuales se va a ordenar

Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas intensamente.

Donde escribir las sentencias

·         Siempre es preferible utilizar consultas almacenadas dentro del motor de base de datos y no dentro de la aplicación, una consulta almacenada en un procedimiento almacenado por ejem , se ejecuta mucho mas rápido y directamente sobre el motor que cualquier consulta externa.

·         Muchas de las aplicaciones sobre todo de reporting permiten unir y realizar los joins y consultas directamente en la herramienta produciendo una baja de performance realmente considerable. Lo correcto y más eficiente seria generar la consulta en un sp con todos los joins y guardar el resultado en una tabla temporal, de donde posteriormente el reporte solo deberá mostrar los datos sin necesidad de trabajarlos primero. Dependiendo los joins que intervengan y los registros involucrados se pude mejorar drásticamente la performance , han habido casos en que reportes  que duraban 3 min en generarse pasaron a 30 seg., usando esta técnica.

Acerca de la formulación de la consultas:

A la hora de ejecutar una consulta SQL la forma en que esta es expresada afecta directamente al motor de BD, pequeños cambios pueden significar la ganancia de muchos segundos o minutos que el usuario debe esperar al momento de ejecutar  la consulta. Algunas recomendaciones son:

·         No utilizar SELECT * por que el motor  debe leer primero la estructura de la tabla antes de ejecutar la sentencia.

·         Seleccionar solo aquellos campos que se necesiten, cada campo extra genera tiempo extra.

·         Utilizar Inner Join , left join , right join, para unir las tablas en lugar del where, esto permite que a medida que se declaran las tablas se vallan uniendo mientras que si utilizamos el where el motor genera primero el producto cartesiano de todos los registros de las tablas para luego filtrar las correctas, un trabajo definitivamente lento.

·         Especificar el alias de la tabla delante de cada campo definido en el select, esto le ahorra tiempo al motor de tener que buscar a que tabla pertenece el campo especificado.

·         Evitar el uso de Cast. Y formulas dentro de las consultas, cada formula y casteo retrasan el motor considerablemente.

El orden de ubicación las tablas en el from deberían ir en lo preferible de menor a mayor según el número de registros , de esta manera reducimos la cantidad de revisiones de registros que realiza el motor al unir las tablas a medida que se agregan.

Generar Proyecto a partir de una BD de Analysis Services 2005

Posted Junio 3, 2007 by roquesalde
Categories: Técnico

Debido a la necesidad de realizar cambios a la estructura de las dimensiones y cubos migrados desde Analysis Services 2000 y encarando la generación de un proyecto nuevo, me di con la sorpresa de que en Visual Studio existe un proyecto de “Crear un nuevo Proyecto de Analysis Services importando una BD existente….” Con lo que me resuelve mi problema de perder el proyecto cuando migro los cubos de Analysis Services 2000. Obviamente esto no lo vi antes por NO leer todas las opciones que me presenta la herramienta…uno nunca quiere leer el Manual de Uso :P La creación del proyecto es bastante sencilla y al mejor estilo Wizard de Microsoft, donde le damos al “Siguiente” y queda todo armado. Lo primero que debemos hacer es seleccionar el proyecto de importación de BD de Analysis Services 2005.

La creación del proyecto es bastante sencilla y al mejor estilo Wizard de Microsoft, donde le damos al “Siguiente” y queda todo armado. Lo primero que debemos hacer es seleccionar el proyecto de importación de BD de Analysis Services 2005.Automáticamente se despliega un asistente el que básicamente nos pide el nombre del servidor de Analysis Services y luego la BD de la que deseamos generar el proyecto.

Hacemos clic en un par de “siguientes “más y listo, tenemos nuestro proyecto generado y listo para poder hacer los cambios que sean requeridos ahorrándonos el trabajo de generar un proyecto de cero.

Espero que le haya sido útil a más de uno, se aceptan sugerencias, críticas y mejores prácticas, lo importante es compartir el conocimiento.

Migrar Cubos de Analysis Services 2000 a SSAS 2005

Posted Junio 2, 2007 by roquesalde
Categories: Técnico

Particularmente en Argentina y el resto de Latinoamérica la mayor cantidad de implementaciones de Business Intelligence se han llevado a cabo con Ms. SQL Server 2000, ya que el motor multidimensional responde bastante bien, existen aplicaciones free para visualizar los cubos, y muy importante para el empresario es el costo de la licencia, el cual es bastante menor respecto a las herramientas TOP de BI, ya sea Cognos, Microstrategy, BO, etc. Lo que nos estamos encontrando en muchos clientes es que están migrando sus bases a SQL Server 2005 y por ende sus cubos también los quieren en SSAS 2005, donde el motor de Analysis Services es mucho más potente, tiene más opciones como los KPI por ejemplo y se acerca mucho más a lo que es una herramienta TOP, Microsoft hoy en día está viendo el nicho del BI como muy interesante, por eso tantos avances en el motor multidimensional y la reciente compra de Proclarity.

No es motivo de este artículo explicar las diferencias entre los entornos de desarrollo de Analysis Services 2000 y SSAS 2005, si mencionaré que en 2005 el entorno está integrado en Microsoft Visual Studio 2005 y cada BD Multidimensional con sus respectivos cubos se crean a partir de Proyectos de Analysis Services.

Para comenzar la migración como requisito debemos tener la BD de Analysis Services 2000 operativa y con el cubo activo, no podemos migrar a partir de un archivo de backup de un cubo, ya que migramos una BD completa. Abrimos la consola de Administración de Analysis Services 2005 y hacemos clic derecho sobre el nombre del servidor y seleccionamos la opción “migrar Base de Datos”.

pantalla1.jpg


Esta pantalla nos abre un asistente, en el cual debemos ingresar en nombre del Servidor de Analysis Services 2000 y el Servidor de destino o un archivo xml. El asistente nos pide que seleccionemos la BD Origen que queremos migrar y el nombre que tendrá la BD destino, pudiendo cambiar el nombre del destino si así lo deseamos.

pantalla2.jpg

Una vez seleccionada la BD Origen y Destino el asistente comienza a validar el origen, si todo está correcto nos informa y nos advierte de posibles cambios que puede sufrir la BD migrada, ya sean cambios en algunos nombres de dimensiones y o métricas.Finalizada la validación clickeamos en Siguiente y comienza la migración, una vez concluida debemos procesar los cubos de la BD para que puedan ser visualizados, y sin más complicaciones hemos migrado la BD Multidimensional de Analysis Services 2000 a nuestro nuevo Analysis Services 2005.

pantalla5.jpg 

Un detalle que debemos saber es que desde la consola de Administración de SSAS no podemos realizar cambios en los cubos, ni de estructura, ni origen de datos, solo podemos agregar usuarios, procesar, realizar backups y restaurar BD. Una desventaja de realizar una migración de este tipo es que perdemos el entorno de desarrollo de los cubos, por lo que si el cliente pide cambios deberemos crear un proyecto y desarrollar todos los cubos desde cero.

Business Intelligence

Posted Mayo 30, 2007 by roquesalde
Categories: General

Business Intelligence (Inteligencia de Negocios), como término, ha crecido a lo largo de los últimos 10 años cada vez tomando un significado más amplio.  Originalmente se ideó como una herramienta para la investigación de mercados, esto es, analizando el comportamiento de los clientes para encontrar tendencias y patrones que releven áreas de oportunidad en ventas y utilidades, pero ahora este concepto ha tomado una identidad más amplia, abarcando cada una de las partes del negocio.Actualmente bajo el nombre de Business Intelligence se cobijan diferentes acrónimos, herramientas y disciplinas que apuntan a dar soporte a la tarea de toma de decisiones, entre ellas encontramos Datawarehouse, Datamart, Datamining, Reporting, Scorecard, Dashboard.

Básicamente, una solución de Business Intelligence integra todos los datos que posee una empresa en sus distintos sistemas transaccionales, hojas de cálculo, archivos de texto plano, etc. realizando una unificación y “limpieza” de los mismos, y los carga en una estructura “especial” de Base de Datos conocida como Datawarehouse, donde un producto cartesiano almacena todas las combinaciones de esos datos para que al ser visualizados por el usuario tenga una rápida respuesta, pueda crear informes de una manera intuitiva y ágil y realice el análisis de la información que le de soporte a las decisiones que deba tomar.

Bienvenidos

Posted Mayo 25, 2007 by mundobi
Categories: Bienvenidos

ctnwms887971967.gifA aquellos que se inician en el mundo de BI se les presenta la realidad de un universo inmensamente amplio, en el cual no se sabe donde hacer pie para comenzar a introducirse en el. Aquellos que ya poseen experiencia en el tema, se encuentra con la “relativamente” poca información sobre las realidades de los mercados locales.

Con la creación de “MundoBi”, deseamos poder compartir información que sirva como base para abordar proyectos de Business Intelligence, así  como para reflejar las realidades de los diferentes mercados. También pretendemos ofrecer un medio con el objetivo de  intercambiar experiencias y diferentes puntos de vista sobre tecnologías y tendencias actuales, fomentando el espíritu crítico.

 Desde ya muchas gracias, y esperamos contar con su apoyo.

“Imita al pensador pensando, no repitiendo sus ideas”