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 Beta 1
- 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.
Actualmente existe una versión de Dinamic Cube 3.0
para Netframework y puedes descargar la versión de evaluación en http://www.datadynamics.com
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 o
descargarla 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.
Espacios
de nombres usados en el código de este artículo:
Nicasoft.Net.v1.0.2005 (Versión 1.0)
DynamiCubeLib (Versión 2.0)
