Data warehouse con Visual Basic Express 2005

Data Warehousing

Cuando Microsoft lanzó SQL Server 7.0, se incluyeron por primera vez herramientas de almacén de datos. Se diseñaron estas herramientas para permitir, incluso a pequeñas compañías, desarrollar grandes almacenes de datos para grandes empresas, mediante el uso de combinación de tecnologías relacionales y multidimensionales. Las herramientas incluidas con SQL Server eran buenas y, cuando se considera que muchos competidores de Microsoft estaban vendiendo herramientas similares por cientos e incluso miles de dólares, Microsoft decide incluir herramientas gratuitamente y eso fue espectacular. Con SQL Server 2000, las herramientas se han hecho incluso más poderosas.

Breve introducción acerca de Data Warehousing

El almacén de datos significa una gran cantidad de cosas diferentes, pero en general, hace referencia a un sistema diseñado para el análisis o ayuda a la toma de decisiones, en lugar de transacciones. La mayor parte de los lectores están familiarizados con el concepto normalización y su papel en los Sistemas de proceso de transacciones en línea (OLTP, online transaction procesing).

OLTP está relacionado con realizar inserciones, actualizaciones y eliminaciones tan rápidas como sea posible. Por consiguiente, no se almacenan datos redundantes o ningún dato que se pueda derivar de otros datos, tales como por ejemplo totales de pedidos. Se separan los datos en tablas diferentes y se unen aquellas tablas que utilizan claves para evitar tener que repetir los datos.
En un sistema OLTP se almacenan transacciones individuales y se espera que el sistema esté en un estado constante de flujo.

El almacén de datos, es todo lo contrario. Algunas veces denominado proceso analítico en línea (OLAP, oline analytical processing), el almacén de datos está relacionado con el almacén de datos agregados. Por ejemplo, ¿Cuántas ruedas se vendieron ayer?, ¿Cuántas se vendieron la semana pasada?, ¿Cuáles fueron las ventas de la semana pasada respecto a la semana anterior?.

Ninguna de estas preguntas es posible responderlas con un sistema OLTP, pero la normalización realmente ralentiza la recuperación de datos; en otras palabras, la instrucción SQL select. Si se optimiza para inserciones, actualizaciones y eliminaciones, se deben realizar una gran cantidad de combinaciones cuando se quieren recuperar datos, y las combinaciones ralentizan las consultas. Para acelerar la recuperación de consultas, los sistemas OLAP desnormalizan los datos. Los datos redundantes se introducen con el único propósito de aumentar la velocidad cuando lleva un cierto tiempo responder a las preguntas.

Además, se pueden almacenar agregaciones en un almacén de forma que el número total de ruedas vendidas ayer, la semana pasada, el mes pasado y el último año ya estén calculadas y se puedan recuperar sin que SQL Server tenga que sumar gran cantidad de registros en una consulta.

La mayor parte de la gente utiliza el termino OLAP para referirse a una estructura (tablas relacionales incorporadas) que se desnormalizan con el fin de aumentar la velocidad. Esta estructura se denomina esquema en estrella, dependiendo de cómo se construyó. Este esquema puede incluir o no números de agregados. Los almacenes de datos por otra parte, se utilizan frecuentemente para referirse a que se están construyendo estructuras multidimensionales, denominadas cubos, las cuales son diferentes de las tablas relacionales estándar.

Por lo tanto este articulo habla acerca de los cubos. Si solamente se tiene un esquema en estrella o en copo de nieve, se deben utilizar instrucciones SQL estándar y ADO para la recuperación. Microsoft y compañías diseñadoras de componentes de terceros han creado constructores de cubos. Una vez que se utiliza un cubo, sin embargo, se tiene que utilizar un enfoque diferente para recuperar los datos.

Cómo visualizar los datos

Normalmente, cuando se desean analizar datos, se expresa una solicitud similar a ésta: Deseo ver cuántas ruedas se han vendido día a día.

El informe devuelve el número total de ruedas que se han vendido según criterio de consulta.

La mayor parte de las compañías se dividen en regiones, las mismas en territorios y así sucesivamente,con el fin de seguir las ventas. Se puede entonces detallar aún más la pregunta. Deseo ver cuántas ruedas se han vendido por meses y por regiones.

La mayor parte de las compañías tienen más de un producto, por lo que se podría preguntar. Deseo ver las ventas mensuales por producto y por regiones.

Aquí se observa que las peticiones son similares. Se describe qué se desea ver y a continuación cómo se desea ver. Lo que se desea ver son cosas como ventas (denominadas medidas). Para esta breve introducción, las medidas son casi siempre numéricas y aditivas. En otras palabras, se añaden una serie de transacciones individuales para averiguar cuántas ruedas se han vendido. Los totales diarios se suman en totales semanales, y así sucesivamente.

El cómo se desean ver los datos representa lo que se denomina dimensiones. En la última instrucción se mencionaron tres dimensiones: tiempo, geografía y producto. A las ventas mensuales se le denominaría el tiempo, en otras palabras la dimensión temporal. De igual forma, la región es la parte de la dimensión geográfica.

La figura 1.0 muestra un cubo. El eje horizontal representa la dimensión temporal; los datos mensuales son representados por este cubo en un momento concreto. A lo largo del eje vertical se representa la dimensión geográfica, en este caso mostrando varias ciudades. El eje z representa los diversos productos a seguir. Se tiene en este caso un cubo tridimensional, pero un cubo real del almacén de datos puede contener un número mayor de dimensiones.

Si se observa el cubo, se puede ver cómo se ha de utilizar para responder a las preguntas. La intersección de las dimensiones se denomina celda. Es precisamente en este punto en el que nos apartamos de las tablas relacionales: una celda puede tener más de un valor.

Si se piensa en una tabla relacional, se va a un registro particular y sobre un registro se va a un campo particular, y se está en una celda. Hay exactamente un valor de cada celda (aunque los valores pueden ser nulos en algunos casos). Con un cubo, sin embargo, cuando se llega a la intersección de las dimensiones de producto, tiempo y geografía hay una celda, pero puede contener varios valores (medidas), esto quiere decir. Se puede desear ver el número de unidades vendidas o las ventas en dólares, o el beneficio de las ventas. Estos tres valores se denominan medidas, y es lo que se encuentra en las celdas dentro del cubo. La figura 2.0 muestra una celda expandida en un cubo.

Figura 2.0.
Celdas que representan productos vendidos en Denmark en el año 1998. Se pueden ver varios valores o medidas, que pueden realmente estar en una celda cuando se trata con datos multidimensionales o cubo.

Es importante entender una cosa sobre dimensiones: normalmente tienen una estructura jerárquica incorporada. Por ejemplo, la dimensión temporal normalmente comienza en años, luego en trimestres, meses finalmente días individuales. De igual forma, la dimensión geográfica es normalmente una estructura jerárquica. Se puede comenzar por países, estados (o provincias, departamentos, regiones).

Usos de Data Warehousing

• Reportes:
  Generalmente consultas aplicadas a almacenes de datos, con la intención de buscar respuesta a preguntas especificas.
  

• OLAP:
  Utilizado en análisis de negocios con el objetivo de investigar el mercado (altas y bajas en las ventas), y/o el comportamiento de estas.
  

• Data Mining (Minería de datos): Buscando patrones y correlaciones en los datos, con la intención de hacer decisiones de negocios. Aquí el software es diseñado para buscar patrones estadísticos en los datos.
  

• EIS (Sistemas de Información Ejecutiva): Utilizados para buscar claves en información resumida, con el propósito de hacer decisiones de negocios, esto es, son sistemas diseñados para utilizar indicadores económicos, los cuales son utilizados por ejecutivos quienes no tienen tiempo para utilizar herramientas de evaluación las cuales en algunos casos no posee información muy precisa y que por el contrario los EIS proporcionan acceso a reportes específicos y que son de muy fácil uso.
  

Modelo para un Data Warehouse

La arquitectura de un almacén de datos se acomoda a diferentes modelos con varios
niveles de escalabilidad. Para construir un modelo fácil de entender, el flujo de datos puede ser cortado dentro de dos funciones básicas:

• Poblar el almacén de datos con información clave.
  
• Recuperar información del almacén vía consultas.

El siguiente diagrama 4.0 muestra un modelo genérico para un almacén de datos:

Poblar el almacén de datos con información clave

Típicamente, un almacén de datos es poblado por información histórica desde dentro de una organización en particular. Esto no es necesariamente estricto, ya que en muchas circunstancias se puede poblar de información tomando una gran variedad de orígenes de datos, a menudo incluyendo datos que provienen con información concerniente a otros competidores.

El mecanismo del DTS (Data Transformation Services) tiene como objetivo importar o exportar datos entre orígenes heterogéneos, utilizando tecnología basada en OLE DB. Por lo tanto, la transformación es usada para poblar el almacén de datos y actualizar los datos en este.

Recuperando datos desde un Data Warehouse

El proceso de recuperación de los datos desde un almacén de datos puede variar dependiendo de los resultados deseados. Por ejemplo si el plan son simples consultas y reportes, entonces se podrían construir sentencias SQL y utilizar Cristal Report, el generador de reportes de VB6 o alguna otra herramienta. Por el contrario si se desea utilizar algo con más expansión entonces se puede requerir aplicaciones basadas en OLAP.

Qué es un Data Marts

Los data marts son utilizados para transformar los almacenes de datos dentro de un grupo lógico de bases de datos. El beneficio de esto, es que los almacenes de datos no se sobrecargan con las tareas de consultas. Únicamente se manejan datos relevantes, por lo tanto cuando las consultas son ejecutadas toman menos tiempo que ser ejecutadas desde el mismo almacén de datos. Otra ventaja muy importante en los data marts es la portabilidad, ya que pueden ser cargados desde una computadora portátil y ser utilizados por personas que requieren acceso a información mientras están de viaje.

La siguiente ilustración 5.0 demuestra el uso de dos data marts. Podría ser que el primero sea utilizado para consultas y reportes, mientras el segundo es usado por una aplicación OLAP o EIS, esto nos lleva a concluir que en el diseño de un modelo para un almacén de datos se podría tener ilimitados data marts, y cada data marts podría tener datos repetidos, si esto fuera necesario.

Cuando se transforman datos desde una base de datos de producción a un data mart, se debería de construir un sistema de replicación a través del almacén de datos, por lo tanto, cuando la replicación se hace directamente desde una base de datos de producción a los data marts, la base de datos de producción podría tener un mal desempeño. Esto es especialmente verdadero cuando los registros de una base de datos de producción son transformados a través de muchos data marts.

Cuando se transforman datos desde una base de datos de producción a un data mart, se debería de construir un sistema de replicación a través del almacén de datos, por lo tanto, cuando la replicación se hace directamente desde una base de datos de producción a los data marts, la base de datos de producción podría tener un mal desempeño. Esto es especialmente verdadero cuando los registros de una base de datos de producción son transformados a través de muchos data marts.

Definición de la estructura de datos

La decisión para normalizar o des-normalizar un almacén de datos puede ser unas de las tareas más difíciles. Ciertamente a la mayoría de los administradores de bases de datos les urge el beneficio de la normalización.

Sin embargo, hay muchas ventajas de la des-normalización para un almacén de datos. A continuación muestro algunas claves puntuales a considerar:

  

• Velocidad de recuperación:
  Cuando se recuperan los datos, es necesario crear complejos enlaces entre más de dos tablas, y como consecuencia cuando los enlaces son entre múltiples tablas ralentizan el proceso de recuperación considerablemente.  Por lo tanto la des-normalización potencialmente aumenta la velocidad de recuperación, pero la llave del éxito para un buen esquema des-normalizado es el seleccionar los campos de interés, desechar los campos innecesarios.
  

• Actualización de los datos : Muchos almacenes de datos no están construidos para darle al usuario la habilidad de poder actualizarlos y esto, podría ser una anomalía en un esquema des-normalizado, ya que es un poco complejo mantener actualizado un origen de datos de esta categoría, otra consideración es que se pierde la habilidad de actualizar los datos en cascada, un ejemplo es, si un vendedor cambia su nombre en un sistema donde ya se encuentra des-normalizado, todos los registros que están asociados a esa base de datos podrían ser actualizados pero nunca igual a efectuarlo en una base de datos normalizada y ejecutando actualizaciones en cascada que podría mejorar altamente el rendimiento. 

• Espacio en disco duro:
  Hoy por hoy los discos duros pueden contener grandes volúmenes de información, con capacidades extraordinarias de almacenamiento. La decisión de normalizar o des-normalizar depende del número de campos seleccionados en las tablas y la cantidad de almacenamiento de datos. Por ejemplo, almacenando datos en una sola tabla, típicamente podría requerirse más de un disco duro, esto porque inevitablemente se almacenarían datos duplicados. Pero el espacio en disco duro no es algo primario, ya que si el hardware es eficiente, entonces se puede acomodar a un esquema de des-normalización. Esto es especialmente excelente cuando los precios de los equipos siguen en descenso.
  

Extracción de datos

Antes de ejecutar y construir un DTS, se requiere considerar algunas pocas opciones. La primera consideración es, si los datos serán copiados en tiempo real. Si el almacén de datos es utilizado para reportes, se podría elegir copiar los datos  solo cuando se ejecuten los reportes. Esto podría ser tomado en consideración  en intervalos de enlace y tomando en cuenta el tiempo requerido a copiar los datos. Si se requiere que los datos estén de manera más inmediata, entonces se preferiría copiarlos en tiempo real. Cuando se están copiando datos en tiempo real, considere la cantidad de procesos que toma esto, ya que un tipo de proceso como este, puede causar bajo rendimiento en el sistema.

La siguiente ilustración 6.0 demuestra datos transformados (DTS) en tiempo real. Cuando un nuevo registro es ingresado dentro de una base de datos de producción, los datos son inmediatamente transformados (DTS) al almacén de datos. El DTS evalúa si cualquiera de los data marts reciben los datos. Si un data mart requiere una copia adicional de los datos, entonces, esta es copiada una vez más. Por lo tanto estos procesos pueden ser ejecutados utilizando disparadores o el software de paquete DTS de SQL Server.

Estos procesos son típicamente ejecutados en intervalos de tiempo específicos, probablemente después que todo el mundo se ha marchado a casa o el día ha finalizado. Por lo general este tipo de procedimientos requieren menos tráfico de red, se requiere menos tiempo de ejecución y no hay un decrecimiento en los recursos de sistema.

Implementando una solución OLAP

A continuación para demostrar un sencillo ejemplo de un Cubo Olap, exploraremos una solución para implementarlo utilizando el objeto Activex de Data Dynamic (Dinamic Cube 2.0). El proyecto incluirá los siguientes requerimientos:

  

• Instalación de Dinamic Cube 2.0 (Versión COM)
  
• Creando un cubo multidimensional
  
• Diseño del proyecto en una aplicación para Visual Basic Express
  
• Microsoft SQL Server 2000
  
• La base de datos NorthWind de ejemplo
• Espacio de nombres Nicasoft.Net.v1.0.2005.dll (Solo para la edición Express de
  Visual Basic 2005)
  
• Microsoft Windows XP o superior
  
• Computadora Pentium o superior
  
• Memória RAM 128 o superior
  
• Monitor VGA de ‘’15 o superior
  

Hay muchas cosas que aprender acerca de OLAP, sin embargo en este artículo y este ejemplo no se cubre en su totalidad. Pero estoy seguro que este ejemplo ayudara a clarificar algunos conceptos básicos sobre OLAP.

Antes de proceder a explicar un poco el ejemplo utilizando el objeto ActiveX Dinamic Cube 2.0, quiero referirme de forma rápida,  que es esta herramienta y que es lo que permite hacer.

Dinamic Cube 2.0 es un control para construir y manipular cubos dimensionales y fue creado por la compañía Data Dynamic. Dicho control fue construido en la era de COM (Modelo de Objeto Componente), sin embargo he evaluado algunas de sus características potenciales en la versión beta de Visual Basic Express 2005 y su comportamiento es muy estable, por el cual diría que funciona de la misma forma como si fuera Visual Basic 6.0.

A continuación la siguiente ilustración muestra parte del código que fue escrito en VB Express 2005 para el manejo de Dinamic Cube. Aquí se observa la inicialización del control.

Imports ns = Nicasoft

'--Crear las instancias.

Dim ToolTip As New ns.Application

Dim DataSource As New ns.AccessDatabase

Dim datConnection As New ns.fnSQL

Private Sub frmDCInvoice_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

        '--Inicializar las propiedades de la clase que maneja ADO.NET

        With Me.DataSource

            '--Inicializar el nombre del servidor.

            .GetServerName = "GIOVANNI"

            '--Inicializar el nombre de la base de datos.

            .GetDatabaseName = "Northwind"

        End With

        '--Aquí se inicializan propiedades para el enlace de conexión   a la base

        '--de datos utilizando ADO 2.7

        With Me.datConnection

            .GetServerName = Me.DataSource.GetServerName

            .GetDatabaseName = Me.DataSource.GetDatabaseName

        End With

        '--Información de conexión utilizando ADO 2.7

        Dim ADO_Connection As String = Me.datConnection.GetInfoConnection

        '--Inicializar la instrucción SQL

        Dim SQL As String = "SELECT * FROM Invoices"

        '--Se inicializan los Tips de los controles.

        '--El primer parametro es el nombre del control.

        '--El segundo es el objeto ToolTip control.

        '--El tercero es el mensaje al poner el cursor en el control.

        With ToolTip

            .ToolTipControl(Me.btnC_Cube, Me.TtCube, "Haga clic aquí­ para cerrar"

            .ToolTipControl(Me.btnP_DCube, Me.TtCube, "Haga clic aquí­ para mostrar una presentación preliminar  de datos"

            .ToolTipControl(Me.btnB_DCube, Me.TtCube, "Haga clic aquí­ para buscar"

        End With

        Try

            '--Inicializar el DCube 2.0 de tipo COM.

            With Me.DC2_COM

                '--Asignar la información de conexión

                .DCConnect = ADO_Connection

                '--Inicializar el tipo de conexión

                .DCConnectType = DynamiCubeLib.DCConnectTypes.DCCT_ADO

                '--Pasar la consulta.

                .DCRecordSource = SQL

                '--Refrescar y mostrar los datos.

                .RefreshData()

            End With

        Catch ex As Exception

            MsgBox(ex.Message, MsgBoxStyle.Critical, "OLAP Cube 2.0")

        End Try

    End Sub

En el siguiente fragmento de código muestro el uso de salida de datos mediante un reporte preliminar que integra el mismo control.

 Private Sub btnP_DCube_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnP_DCube.Click

        With Me.DC2_COM

            '--Poner título al reporte

            .HeaderCaption = "Analizador de punto de venta 2005 con Visual Basic Express Beta 1"

            '--Orientación del  papel

            .PrinterOrientation = DynamiCubeLib.PrtOrientation.DDPOLandscape

            '--Se mustra el reporte en forma preliminar.

            .PrintPreview()

        End With

End Sub

El siguiente código permite mostrar el formulario de búsqueda, en dicho código se muestra una nueva instrucción solo para la edición VB Express 2005 Beta 1, la cual permite acceder a formularios sin necesidad de crear instancias, por ejemplo como se hace en versiones anteriores de .Net.

Private Sub btnB_DCube_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnB_DCube.Click

        '--Abrir el formulario con My.Forms (Algo nuevo que se presenta   

        '--en la versión 2005 Beta 1

        '--y muestro el formulario de forma modal.

        My.Forms.frmB_DCube.ShowDialog()

End Sub

La siguiente figura en modo de diseño muestra el formulario al cual le pertenece el código anterior.

La siguiente figura muestra el formulario que permite crear filtros al Cubo o control Dinamic Cube.

El siguiente fragmento de código pertenece al formulario anteriormente expuesto. Este tiene como objetivo inicializarlo.

Imports ns = Nicasoft

Dim ToolTip As New ns.Application '--Para utilizar el ToolTp de VB.

Dim SendKey As New ns.Application '--Para enviar pulsaciones de teclas. 

Private Sub frmB_DCube_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

        '--Instancia a la clase ToolTip de VB.

        Dim tt As New ToolTip

        '--Configurar el control.

        With tt

            '--Apariencia del mensaje.

            .IsBalloon = True

            '--Icono o imagen.

            .ToolTipIcon = ToolTipIcon.Info

            '--Efectos de animación

            .UseAnimation = True

            '--Título del control

            .ToolTipTitle = "Ayuda"

        End With

        '--Se inicializan los Tips de los controles.

        '--El primer parámetro es el nombre del control.

        '--El segundo es el objeto ToolTip control.

        '--El tercero es el mensaje al poner el cursor en el control.

        With ToolTip

            .ToolTipControl(Me.txtAño, tt, "Escriba aquí el año y luego haga enter"

            .ToolTipControl(Me.btnC_Buscar, tt, "Haga clic aquí para cerrar"

            .ToolTipControl(Me.btnB_Buscar, tt, "Haga clic aquí para mostrar resultados de la búsqueda"

        End With

        '--Desactivar el boton que permite crear el filtro.

        Me.btnB_Buscar.Enabled = False

  

End Sub

El siguiente código tiene como objetivo crear el filtro.

Private Sub btnB_Buscar_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnB_Buscar.Click

        '--Se almacena el año a evaluar.

        Dim intAño As Integer = Val(Me.txtAño.Text)

        '--Incializar la instrucción de filtro.

        Dim SQL As String = "SELECT * FROM Invoices WHERE YEAR(OrderDate)=" & intAño

        '--Se crea el filtro según el valor del año ingresado.

        With My.Forms.frmDCInvoice.DC2_COM

            .DCRecordSource = SQL

            .RefreshData()

        End With

        '--Cerrar el formulario.

        With Me

            .Dispose()

            .Close()

        End With

End Sub

El siguiente fragmento de código muestra la configuración de los campos en el cubo en tiempo de ejecución. Aquí solo se configuro los campos relacionados al producto y geografía, ya que se presentará como segunda opción de configuración la página de propiedades del control, esto con el objetivo de presentar dos métodos para la utilización del mismo.

''' <summary>

    ''' Este procedmiento se configuran los campos que se utilizaran, tanto como en las filas

    ''' columnas y en la sección de encabezados

    '''

    ''' El procedimiento tiene como objetivo cargar los campos seleccionados desde una consulta

    ''' de Microsoft SQL Server 2000, denominada Invoices.

    ''' </summary>

    ''' <param name="sender"></param>

    ''' <param name="e"></param>

    ''' <remarks></remarks>

    Private Sub DC2_COM_LoadCompleted(ByVal sender As Object, ByVal e As System.EventArgs) Handles DC2_COM.LoadCompleted

        '--Variable de objeto generico.

        Dim X As Object

        '--Crear la instancia a la función de tipo DCFSum

        Dim DCFSUM As New DCube.GroupFooterTypes

        '--Crear la instancia al tipo DCDATA el cual permite definir la orientacion del campo.

        Dim DCDATA As New DCube.OrientationConstants

        '--El Try permite manejar errores en tiempo de ejecución

        Try

            '--Actualizar el control.

            Me.DC2_COM.AutoDataRefresh = True

            '--Configurar el campo UnitPrices.

            X = Me.DC2_COM.Fields.Add("UnitPrice", "Precio unitario C$", DCDATA.DCData)

            X.GroupFooterType = DCFSUM.DCFSum

            X.NumberFormat = "##,##0.00"

            '--Configurar el campo Quantity.

            X = Me.DC2_COM.Fields.Add("Quantity", "Cantidad", DCDATA.DCData)

            X.GroupFooterType = DCFSUM.DCFSum

            X.NumberFormat = "##,##0.00"

            '--Configurar el total vendido con una fórmula de tipo UDF.

            X = Me.DC2_COM.Fields.Add("", "Total venta C$", DCDATA.DCData)

            X.Calculated = True

            X.GroupFooterType = DCFSUM.DCFCalculated

            X.NumberFormat = "##,##0.00"

            X.SummaryExpr = "GroupSum(UnitPrice)*GroupSum(Quantity)"

            '--Configurar el campo Country.

            X = Me.DC2_COM.Fields.Add("Country", "País", DCDATA.DCRow)

            '--Configurar el campo CustomerName.

            X = Me.DC2_COM.Fields.Add("CustomerName", "Cliente", DCDATA.DCRow)

            '--Configurar el ProductName.

            X = Me.DC2_COM.Fields.Add("ProductName", "Producto", DCDATA.DCPage)

            '--Configurar el City.

            X = Me.DC2_COM.Fields.Add("City", "Ciudad", DCDATA.DCPage)

            '--Configurar el Region.

            X = Me.DC2_COM.Fields.Add("Region", "Región", DCDATA.DCPage)

            '--Refrescar los datos en pantalla.

            Me.DC2_COM.RefreshData()

            '--Refrescar el control.

            Me.DC2_COM.AutoDataRefresh = True

        Catch ex As Exception

            MsgBox(ex.Message, MsgBoxStyle.Critical, "OLAP Cube 2.0")

        End Try

  End Sub

A continuación se muestra el uso de la página de propiedades. Como primera ilustración se muestra la opción para crear el tipo de conexión, la tabla o consulta a relacionar dentro del control.

Como se observa, tiene declarado el tipo de conexión, en este caso ADO, ya que el control no esta diseñado para netframework. Luego la cadena de conexión, el cual utiliza el proveedor de SQLOLEDB y posteriormente la consulta.

A continuación muestro la segunda opción que permite seleccionar los campos en el cubo. En este caso solo tomo las variables de tiempo como demostración ya que a nivel de código están declarados el resto de los campos.

El resto de las opciones las puedes verificar o consultar en la ayuda del control. El cual estará disponible la versión de evaluación en el sitio de descarga de archivos de Nicasoft más adelante descrito odescargarla del sitio de Data Dinamic anteriormente expuesto.

A continuación muestro el formulario en tiempo de ejecución.

Conclusiones

El avance tecnológico esta cambiando a cada instante el modo de operar en el mundo actual. El software y el hardware han evolucionado y siguen haciéndolo con  el único objetivo de innovar herramientas que ofrezcan a las empresas de hoy en día y del futuro, elementos con las que satisfagan las necesidades empresariales en continua evolución. Espero que este artículo proporcione ideas elementales que permitan de una u otra forma evolucionar a nuevas plataformas de desarrollo las cuales traen como beneficio único, productividad y éxito en la creación de una amplia gama de soluciones de software.

Quiero despedir este artículo con una frase de Bill Gates que dice así: Invertir en la tecnología del futuro, resulta hoy en día una cuestión más crucial de lo que ha sido jamás.