Descripción del modelo

El modelo de MD MDM (minería de datos multidimensional) está limitado a ser una solución de capa 3 para la arquitectura OLAM, y supone el planteamiento de un motor de análisis para la minería de de reglas de asociación empleando el Análisis Formal de Conceptos y por tanto,latticesconceptuales. Su interacción se lleva a cabo entre las consultas de minería (entradas) y la presentación del conocimiento al usuario (salidas). Como se puede apreciar en la figura 4.4, los límites del modelo se encuentran en las API’s de GUI y cubo, las cuales son independientes al modelo ya que pertenecen a capas diferentes. Sin embargo, el modelo obviamente no está totalmente aislado y de alguna manera interactúa con ellas para obtener ciertos datos clave para el procesamiento. Resumiendo, se puede afirmar que el modelo de MD MDM aquí planteado se estructura en dos partes: la primera, elmotor OLAM para la extracción de reglas de asociación; y la segunda, un conjunto de interaccionesentre los motores analíticos (OLAP y OLAM) y el API de GUI donde se procesarán las consultas. Cabe señalar que indirectamente se estará trabajando con un cubo multidimensional a través de su API correspondiente (capa 2 de OLAM). Veamos, en primer lugar, qué componentes son los que participan de las interacciones.

API de intefaz gráfica de usuario

Esta interfaz se encarga de manejar las entradas y salidas de un sistema OLAM. El usuario ingresa unaconsulta de minería basada en restricciones[2] de tal manera que se puedan diferenciar las restricciones tanto para el espacio de búsqueda multidimensional como para las reglas de asociación que se prentenden obtener. Estas restricciones son de dos tipos: de

BIBLIOTECA

DE CIENCIAS

FÍSICAS

minería de datos (MD) y de análisis multidimensional (AM). Lasrestricciones AMbuscan delimitar el espacio de búsqueda para la minería y por tanto, brindar al motor OLAM de un conjunto acotado de transacciones. Lasrestricciones MDbuscan delimitar los límites de soporte y confianza para las reglas de asociación resultantes.

Partiendo de una tabla fact, se puede afirmar que existen dos tipos de atributos a tener en cuenta:llaves de dimensiónydata transaccional. Las llaves de dimensión son aquellas que definen para una transacción una instancia de una dimensión; por ejemplo, fecha, producto, empleado, cliente, etc. La data transaccional, a su vez, se divide en medidas (cantidades, montos, saldos, descuentos, impuestos, etc.) y características (número de orden, código de pedido, número tracking, etc.). Los atributos que al final se consideren como parte de un contexto multivaluado de entrada D= (G,M,W,I) pueden ser de cualquiera de los dos tipos. Sin embargo, las columnas que representan características de la data transaccional no suponen información relevante a la búsqueda de conocimiento, sólo son de utilidad para el correcto funcionamiento de los sistemas OLTP. Entonces, losatributos válidos para una consulta son las dimensiones y medidas.

En cuanto a las medidas, nótese que su naturaleza es cuantitativa, lo cual supone que, en caso sea utilizable para conformar el contexto multivaluado de entrada, hay que definires- calas con cierta granularidad(precisión) o considerar simplementeumbrales mínimos o máximos. Para el caso de las dimensiones, en primer lugar, se tiene que estudiar la natu- raleza de las mismas: tipo de dato, existencia de jerarquías, etc. A partir de una consulta multidimensional podemos rescatar dos usos para las dimensiones: como filtro de búsque- da (mediante una sentencia WHERE) y como atributos explícitos (sentencia SELECT). Los atributos explícitos serán aquellos que formen parte del contexto multivaluado de entrada; es decir, elementos del conjunto M, que definirán la estructura de las reglas de asociación resultantes.

El API de interfaz gráfica de usuario se encarga deidentificar los parámetros necesarios para la delimitación del dominio de análisisde un cubo multidimensional. Específicamen- te, tiene la tarea de obtener las columnas que intervendrán en el proceso de delimitación, tanto de tablasfact como dimensión, y de, naturalmente, establecer la conexión con el cu-

BIBLIOTECA

DE CIENCIAS

FÍSICAS

bo multidimensional. A su vez, recoge los requerimientos de soporte y confianza para las reglas de asociación y muestra al usuario, de manera gráfica, la representación de la base de conocimiento resultante (diagrama deliceberg latticey bases de reglas de asociación). A continuación se presentará el procedimiento para la identificación de los requerimientos de las consultas multidimensionales:

1. Identificar las columnas de interés.Los cuales pueden ser de tipo dimensión o medida. Para el primer caso, estos se extraen de sus respectivas tablas dimensión. Por ejemplo, sea la tabla «DimSalesTerritory», tenemos tres atributos candidatos: «SalesTerritory- Region», «SalesTerritoryCountry» y «SalesTerritoryGroup». Obviamente existe una jerarquía y dependencia entre estas columnas; sin embargo, y dependiendo del grado de detalle que el analista requiera, se escogerá la más pertinente. Note que esto no quie- re decir que debamos seleccionar solamente un atributo por dimensión, simplemente hay que procurar que no existan dependencias entre el conjunto elegido.

2. Identificar filtros y atributos.Losfiltrosse encargan de reducir el conjunto de transac- ciones de acuerdo a un parámetro de interés. Por ejemplo, acotando el espacio de bús- queda a transacciones realizadas en cierto territorio comercial, en el último trimestre, de cierta tienda, de una categoría de producto en específico, etc. Losatributosson las columnas que serán parte del contexto multivaluadoD, específicamente, elementos del conjuntoM. Estos atributos constituyen la base para la extracción de conocimiento, su elección está supeditada al criterio del analista, el cual deberá preguntarse qué rela- ciones espera descubrir; por ejemplo, entre productos, entre umbral de ingresos por ventas y territorios comerciales, etc.

3. Identificar la unidad mínima de análisis.Este indicador define la naturaleza de los ob- jetos que se van a obtener. Por ejemplo, para el caso del proceso de negocio «Ventas», cada registro indica las características de la venta de un producto (cantidad, precio uni- tario, descuento, etc.) así como el contexto (fecha de pedido, fecha de despacho, em- pleado, tienda, territorio, etc.); sin embargo, estos registros se agrupan en una unidad

BIBLIOTECA

DE CIENCIAS

FÍSICAS

llamada «pedido», la cual supone un subconjunto de productos individuales. Entonces, el hecho de especificar una unidad mínima de análisis para una tabla fact, dependerá de la consulta realizada, y supone laexistencia de una columna que diferencie cada objeto o transacción(«object_id»).

Formalmente, el usuario a través del API de GUI determina unavista de origen de datos V= (ob ject_id,D,A,F,V,minsupp,mincon f) (data source view) para una tabla fact en un cubo de datos. DondeD es un conjunto de tablas dimensión,A un conjunto de columnas atributoa∈A, F un conjunto de columnas filtro f ∈F,v∈V un conjunto de valores apli- cables a las columnas filtro,minsuppel soporte mínimo para el cálculo deliceberg concept latticeymincon f el umbral de confianza mínimo para el cálculo de reglas de asociaciones aproximadas (base de Luxenburger).

Motor OLAP y API de cubo

El motor OLAP se encarga de delimitar el espacio de búsqueda utilizando la vista de origen de datosVpara generar un contexto multivaluadoD= (G,M,W,I). Con base enVy para una tabla fact «FACT», un modelo primitivo de consulta SQL para obtenerDsería el siguiente:

SELECT {object_id}, {attrib_col} [, {attrib_col} ...] FROM FACT

[JOIN DIM1 ON {join_condition_expr}]

[JOIN DIM2 ON {join_condition_expr}]

...

[WHERE {filter_col_condition_expr}]

Partiendo de la consulta anterior (y con base en V), las columnas attrib_col indican las columnas de tipo atributoa∈Ay las columnasfilter_col_condition_exprse refieren a las expresiones booleanas que involucran a elementos del conjunto de filtrosFrela- cionados con los valoresV. Nótese que es posible considerar columnas atributo provenientes de alguna tabla dimensión, para lo cual habría que indicar la sentencia JOIN respectiva. También, cada fila, transacción u objeto resultante deberá ser inequívocamente identificado mediante un «object_id».

BIBLIOTECA

DE CIENCIAS

FÍSICAS

La tabla resultante de esta consulta es un contexto multivaluado D = (G,M,W,I) donde

Ges el conjunto de valores «object_id» de la consulta, M =A es el conjunto de atributos multivaluados,W el conjunto de valores de celdam(g) =w eI es una relación ternaria tal queI⊆G×M×W. El siguiente paso es transformarDa un contexto formal binario.

Motor OLAM

El motor OLAM se encarga de transformar un contextoD= (G,M,W,I) a un conjunto de reglas de asociación. Consta de tres subprocesos, como se pueden oberservar en la figura 4.4. El primero de ellos es el escalado contextual, donde se transforma el contexto multivaluado Da un contexto binarioKcon el cual se generará, posteriormente, unlatticeconceptual. La generación se llevará a cabo con TITANIC a partir de las restricciones MD (utilizando sólo

minsupp) para obtener un conjunto de itemsets frecuentes junto con sus generadores míni- mos. La estructura algebraica de estos conjuntos se representa mediante uniceberglattice. Por último, se extraen las bases de Duquenne-Guigues y de Luxenburger de reglas de aso- ciación eaxctas y aproximadas, respectivamente. Estos resultados suben hacia la capa 4 para ser presentadas al usuario para su posterior análisis.

Escalado contextual.Para generar un contexto formal binarioKse efectúa lo siguiente:

1. Dado un contexto multivaluado D = (G,M,W,I), para cada m∈M hay que definir una escala Sm= (Gm,Mm,Im). En primer lugar, para cada m∈M hay que identificar

su dominio D_m (ver ecuación 3.6), luego hacer que G_m⊆D_m (aunque generalmen- te ambos conjuntos son iguales). El conjunto Mm es el producto de renombrar cada

elemento del dominioD_mde manera que sea explícito el rol de subatributo (por ejem- plo, sim=«Nombre Producto» y «AWC Logo Cap»∈Dm, entoncespawc∈Mmsería

un nombre de atributo binario válido). Finalmente, tener en cuenta la naturaleza del dominioDmes de vital importancia a la hora de determinar el tipo de escalado a efec-

tuar: ordinal, si es posible identificar una relación de orden enD_m (escalado ordinal), u nominal en caso contrario.

2. Obtener un conjuntoG_u⊆Gen caso se haya identificado una unidad mínima de análi-

BIBLIOTECA

DE CIENCIAS

FÍSICAS

sis (Gu=Gen caso contrario). SiGu⊂G, cada elementou∈Gues una agrupación úni-

ca de elementos deG(por ejemplo,ues un «pedido» de productosg∈G). Para tal caso,

Guse obtiene ejecutandoSELECT DISTINCT {object_id} FROM FACT.

3. Construir el contexto formal binarioK= (H,N,J)tal que:

H=G_u N= [ Mm∈Sm M_m, ∀m∈M (h,n)∈J ⇐⇒ m(h) =w∧(w,n)∈I_m (5.1)

Generación deliceberg concept lattice.Un contexto formal binarioK= (H,N,J)es entrada para el algoritmo TITANIC, el cual generará un conjunto deitemsetsfrecuentes, representa- dos por uniceberg lattice, con base en el umbral de soporte mínimo especificado enV. Este

latticees el primer paso para la extracción de reglas de asociación. Finalmente ellatticees presentado al usuario para su interpretación directa a través del API de GUI.

Extracción de bases de reglas de asociación.A partir de uniceberg concept latticese ge- nerarán reglas de asociación exactas (implicaciones) y aproximadas. Debido a que el número reglas resultantes puede llegar a ser excesivo, se consideran solamentebases de reglas de asociación, tanto para implicaciones como para reglas aproximadas. Dichas bases son las deDuquenne-Guigues y deLuxenburger respectivamente. Estas reglas representan conoci- miento inferido de un espacio de búsqueda limitado en base a restricciones, las cuales fueron concebidas en base a consultas multidimensionales planteadas por un analista. Por tanto, con este modelo de MD MDM se pretende acoplar procesos de minería de datos a entornos más dinámicos como OLAP, para que la obtención de conocimiento también sea en línea, tal como se plantea en OLAM.

BIBLIOTECA

DE CIENCIAS

FÍSICAS