especificaciÓn formal de cubos de datos aplicados …

ESTUDIAR P ARA PREVERY PREVER P ARA ACTUAR

P R E M I OINTRAGOB

2006

a la

06

RSGC - 617INICIO: 2012.09.28

TERMINO: 2015.09.28

ISO 9001:2008

PROCESO EDUCATIVO

S G C

S N E S T

IMNC-RSGC-617

IMNC-RSGC-617IMNC-RSGC-617

CERTIFICADO BAJO LANORMA ISO 9001:2008

CERTIFICADO BAJO LANORMA ISO 9001:2008

VILLA DE ÁLVAREZ, COL., NOVIEMBRE DE 2014

ESPECIFICACIÓN FORMAL DE CUBOS DE DATOS APLICADOS A LA ADMINISTRACIÓN DE LAS

ACTIVIDADES DOCENTES

OPCIÓN ITESIS PROFESIONAL

QUE PARA OBTENER EL GRADO DE MAESTRO EN SISTEMAS COMPUTACIONALES

PRESENTA PEDRO FLETES GUDIÑO

ASESOR DR. NICANDRO FARÍAS MENDOZA

COASESORA:M.C. ROSA DE GUADALUPE CANO ANGUIANO

TECNOLÓGICO NACIONAL DE MÉXICO

Instituto Tecnológico de Colima

Especificación Formal de Cubos de Datos Aplicados a la Administración de las Actividades Docentes

Instituto Tecnológico de Colima 2

EPÍGRAFE

“Son nuestras decisiones las que muestran lo que podemos llegar a ser. Mucho

más que nuestras propias habilidades”.

J. K. Rowling



Índice General

Resumen. ................................................................................................................ 7

1. Introducción. ........................................................................................................ 8

1.1 Razones que motivaron la elección del tema. ............................................... 8

1.2 Contexto del problema. ................................................................................. 8

1.3 Revisión de la literatura. ................................................................................ 9

1.4 El problema a investigar. ............................................................................. 13

1.5 Hipótesis del trabajo. ................................................................................... 13

1.6 Objetivo. ...................................................................................................... 14

1.7 Descripción de la organización del trabajo. ................................................. 14

2. Estado del campo de conocimiento. .................................................................. 16

2.1 Introducción. ................................................................................................ 16

2.2 Marco histórico. ........................................................................................... 16

2.3 Marco contextual. ........................................................................................ 17

2.3.1 Bases de datos multidimensionales. .................................................... 17

2.3.2 Cubos OLAP. ....................................................................................... 18

2.3.3 Trabajos relacionados y sus aportaciones. .......................................... 22

2.3.4 Un ejemplo de información de un cubo de datos, obtenida a través de

una herramienta OLAP. ........................................................................ 24

2.4 Marco teórico. ............................................................................................. 27



2.4.1 Sistema de Gestión de Base de datos. ................................................ 27

2.4.2 Bases de datos multidimensionales. .................................................... 27

2.4.3 Cubo de datos. ..................................................................................... 28

2.4.4 Sistemas OLPT (On Line Transactional Processing). .......................... 29

2.4.5 Sistemas OLAP (On Line Analytical Processing). ................................ 29

2.4.6 Data Warehouse. ................................................................................. 29

2.4.7 Datamart. ............................................................................................. 30

2.4.8 Data mining. ......................................................................................... 30

2.4.9 Sistema ETL (Extract, Transform and Load). ....................................... 30

2.4.10 Herramientas OLAP. .......................................................................... 30

2.4.11 Sistemas ROLAP. .............................................................................. 31

2.4.12 Sistemas MOLAP. .............................................................................. 31

2.4.13 Sistemas HOLAP. .............................................................................. 31

2.4.14 Campos ordinales y cuantitativos. ..................................................... 32

2.4.15 Dimensiones y mediciones. ............................................................... 32

2.4.16 Álgebra de tablas. .............................................................................. 32

2.4.17 Operadores del álgebra de tablas. ..................................................... 33

2.4.18 Formas normalizadas......................................................................... 34

2.5 Conclusión. ................................................................................................. 34

3. Desarrollo del cubo de datos aplicado a la administración de las actividades

docentes. ............................................................................................................... 35

3.1 Introducción. ................................................................................................ 35

3.2 Análisis del sistema. .................................................................................... 35

3.2.1 Modelo conceptual. .............................................................................. 38

3.2.2 Requerimientos del sistema. ................................................................ 39



3.3 Modelo para la especificación formal de bases de datos multidimensionales.

.................................................................................................................... 40

3.3.1 Flujo de datos en el modelo MCD. ..................................................... 40

3.4 Diseño. ........................................................................................................ 45

3.4.1 Diseño arquitectónico. ......................................................................... 47

3.4.2 Diseño físico del cubo de datos. .......................................................... 48

3.5 Caso de estudio. ......................................................................................... 49

3.5.1 Flujo de datos en la Big Picture. .......................................................... 56

3.6 Análisis de los resultados obtenidos. .......................................................... 59

3.7 Conclusión. ................................................................................................. 59

4. Conclusiones y recomendaciones. .................................................................... 60

Bibliografía ............................................................................................................ 62

Anexo A Planeación del curso. ......................................................................... 65

Anexo B Instrumentación didáctica. .................................................................. 68

Anexo C Lista de calificaciones parciales. ........................................................ 71

Anexo D Acta de Calificaciones. ....................................................................... 73

Anexo E Descripción de registros de las tablas del Cubo de Datos. ................. 75

Anexo F Descripción de registros de las tablas del esquema relacional de

docencia. .................................................................................................... 81

Índice de Figuras

Figura 1 La Estructura básica en el Modelo Multidimensional: El Cubo. ............... 10

Figura 2 Esquema de estrella. ............................................................................... 11

Figura 3 Esquema de Copo de nieve ................................................................... 12

Figura 4 Big Picture del esquema multidimensional propuesto. ............................ 38



Figura 5 Modelo Multidimensional. ........................................................................ 45

Figura 6 Modelo Conceptual multidimensional. ..................................................... 46

Figura 7 Diagrama de E-R del Cubo de datos....................................................... 48

Figura 8 Esquema Relacional de docencia. .......................................................... 49

Figura 9 Transición en la generación de las dimensiones del Cubo de datos ....... 56

Índice de Tablas

Tabla 1 Ventas, costos y utilidad por mes ............................................................. 19

Tabla 2 Pantalla típica de tres dimensiones .......................................................... 20

Tabla 3 Rebanada de un cubo .............................................................................. 21

Tabla 4 Comportamiento histórico. ........................................................................ 37

Tabla 5 Código 1 en SQL ...................................................................................... 50

Tabla 6 Código 2 en SQL ...................................................................................... 51

Tabla 7 Descripción del registro de la tabla DEPARTAMENTOS. ........................ 76

Tabla 8 Descripción del registro de la tabla MATERIAS. ...................................... 76

Tabla 9 Descripción del registro de la tabla DOCENTES. ..................................... 77

Tabla 10 Descripción del registro de la tabla TIEMPO. ......................................... 77

Tabla 11 Descripción del registro de la tabla CARRERAS. ................................... 78

Tabla 12 Descripción del registro de la tabla GRUPOS. ....................................... 78

Tabla 13 Descripción del registro de la tabla ALUMNOS. ..................................... 82

Tabla 14 Descripción del registro de la tabla DEPARTAMENTO. ......................... 83

Tabla 15 Descripción del registro de la tabla CARRERAS. ................................... 83

Tabla 16 Descripción del registro de la tabla MATERIAS. .................................... 84

Tabla 17 Descripción del registro de la tabla PERSONAL. ................................... 84

Tabla 18 Descripción del registro de la tabla GRUPOS. ....................................... 85

Tabla 19 Descripción del registro de la tabla DET_GRUPOS. .............................. 86



Resumen.

Durante los últimos años las bases de datos multidimensionales han venido

evolucionando y se han convertido en algo común en las empresas de negocios y

científicas. La necesidad de contar con información cada vez más sistematizada y

tomando en cuenta incluso información histórica, hace que esta necesidad sea

cada día más necesaria e implícita en el mundo de cualquier empresa. En este

trabajo se propone un modelo para la especificación formal de bases de datos

multidimensionales (BDMD) o cubos de datos, que permita a través de un

proceso, clasificar y la filtrar información del área de docencia de la base de datos

del Sistema de Información del Instituto Tecnológico de Colima (SIITEC) y de los

departamentos académicos. La meta que se pretende alcanzar, es un modelo

para la especificación formal de cubos de datos.



1. Introducción.

1.1 Razones que motivaron la elección del tema.

La principal función desempeñada durante los últimos 20 años como docente en

el Instituto Tecnológico de Colima, siempre en el departamento de Sistemas y

Computación, ha sido la impartición de clases, y una de las áreas que desde

siempre como Licenciado en Informática me ha entusiasmado son las bases de

datos y es por esto, que este proyecto de tesis fue elegido para seguir en la

temática actual que son las bases de datos multidimensionales.

Actualmente las bases de datos son una herramienta escencial, en el

almacenamiento y recuperación de datos en cualquier empresa, la evolución de

estas, actualmente es su enorme crecimiento no solo en el volumen de datos

almacenados, sino en la cantidad y diversidad de información, que puede ser

extraída, no solo para el control de las actividades de la organización, sino

además, para marcar estrategias en las tendencias de productos, en las de

mercadotecnia y en las de crecimiento de la empresa.

En el área académica el contar con una base de datos multidimensional, permite

la posibilidad de obtener información por ejemplo: índices de aprobación y

reprobación desde distintos puntos de vista (por docente, materia, horario de la

misma, semestre), además de combinar con otros aspectos del alumno tales

como: si es foráneo, por sexo, si es becado, si trabaja, si ya estudió otra carrera,

por estado civil, etc.

1.2 Contexto del problema.

Actualmente a nivel nacional en el ámbito educativo, y el ITC1 no es la excepción,

se está viviendo una problemática que son los altos índices de reprobación de

alumnos en las materias que cursan, desde siempre se han buscado diversas 1 Instituto Tecnológico de Colima



maneras de disminuir estos índices, pero a nivel institucional no existe una

herramienta computacional para llevar la gestión de estos, y que además

proporcione información histórica desde distintos parámetros. Esto llevó a elaborar

esta propuesta que generará a través de la especificación formal, un esquema

computacional (cubo de datos), capaz de almacenar información relevante de los

índices de reprobación de años anteriores y una vez implementado que permita

obtener información de manera rápida y eficaz de las causas que originan la

reprobación en el Instituto.

La finalidad de esta investigación es que a través del cubo de datos que se

propone, tener la capacidad de guardar información de manera estructurada

haciendo uso de las bases de datos multidimensionales y posteriormente explotar

esta información a través de comandos del lenguaje SQL2 para proporcionar

información estadística que sirva de soporte en la toma de decisiones de los

índices de reprobación.

1.3 Revisión de la literatura.

En una base de datos multidimensional, la información se representa como

matrices multidimensionales, cuadros de múltiples entradas o funciones de varias

variables sobre conjuntos finitos. Cada una de estas matrices se denomina Cubo.

El esquema de un cubo queda determinado dando a conocer sus ejes con sus

respectivas estructuras y la estructura de los datos que se presentan en cada

celda de la matriz. Se asume que los datos en todas las celdas son uniformes, es

decir, todas las posiciones de la matriz tienen datos con igual estructura.

Una instancia de un cubo, queda determinada por un conjunto de datos para cada

eje y un conjunto de datos para la matriz (ver Figura 1).

2 (Structured Query Language) por sus siglas en inglés



A los ejes se les llama Dimensiones y al dato que se presenta en la matriz, se le

llama Medida. A los elementos del producto cartesiano de los ejes (dimensiones)

se le llama coordenadas.

Thomsen en el 2002, afirma que la noción de un hipercubo, o un cubo con más de

tres dimensiones, es fundamental para una comprensión de software

multidimensional que utiliza hipercubos de la misma manera que las hojas de

cálculo utilizan hojas de trabajo y las bases de datos utilizan tablas. Toda la

navegación, presentación de informes y el análisis se realiza en términos de

hipercubos.

Utley en el 2011, estabece que los agregados son uno de los principales

beneficios de la creación de cubos, proporcionando al menos, grandes ganancias

en rendimiento. Sin embargo, los agregados están a menudo mal entendidos y a

veces, no son utilizados en absoluto. Así que al comprender lo que son los

agregados y cómo funcionan, ayudará a producir cubos con mejor rendimiento en

las consultas.

Gascueña en el 2011, presenta una metodología para el diseño y desarrollo de

bases de datos multidimensionales o data warehouses, con soporte para datos

espacio-temporales representados en múltiples granularidades. Desde un enfoque

Figura 1 La Estructura básica en el Modelo Multidimensional: El Cubo.



conceptual se presenta un modelo de datos multidimensional, intuitivo e innovador

llamado FactEntity (FE), que permite modelar tanto la semántica multidimensional

como el espacio-temporal.

Ramos en el 2011, señala que a la hora de modelar el data warehouse, hay que

decidir cuál es el esquema más apropiado para obtener los resultados que

queremos conseguir. Habitualmente y salvo excepciones, se suele modelar la

base de datos utilizando el esquema de estrella (star schema), en el que hay una

única tabla central, la tabla de hechos, que contiene todas las medidas y una tabla

adicional por cada una de las perspectivas desde las que queremos analizar dicha

información, es decir las dimensiones (ver Figura 2).

Figura 2 Esquema de estrella.

La otra alternativa de modelado es la utilización del modelado de copo de nieve

(snowflake schema). Esta es una estructura más compleja que el esquema en

estrella. La diferencia es que en algunas de las dimensiones no están

CARRERAS

ID_CARRERA

NOMBRE

DEPARTAMENTOS

CVE_DEPTO

NOMBREDOCENTES

CVE_DOCENTE

NOMBRE

GRUPOSCVE_DEP

CVE_CARRERA

GRUPO

CVE_MATERIA

CVE_DOCENTE

CVE_TIEMPO

NO_ALUMNOS

NO_ALUMNOS_AP

NO_ALUMNOS_REP

MATERIAS

CVE_MATERIA

NOMBRE

TIEMPO

CVE_TIEMPO

PERIODO



relacionadas directamente con la tabla de hechos, sino que se relacionan con ella

a través de otras dimensiones (ver Figura 3).

ALUMNOSNO_CONTROL

NOMBRE

SEXO

LOCAL

BECADO

TRABAJA

CARRERA

EDO_CIVIL

CARRERASId_carrera

nombre

Id_dpto

DEPARTAMENTO

iddepartamento

nombre

DET_GRUPOSNO_GRUPO

PERIODO

NO_CONTROL

CALIFICACION

OPORTUNIDAD

FECHA

GRUPOSNO_GRUPO

ID_CARRERA

ID_MATERIA

HORA_INICIO

HORA_FIN

ID_DOCENTE

FOLIO

PERIODO

FECHA

NO_ALUMNOS

MATERIAS

idmateria

nombre

PERSONAL

idpersonal

NOM_DOC

Figura 3 Esquema de Copo de nieve



1.4 El problema a investigar.

La generación del esquema de un cubo de datos para la explotación de

información en el área de docencia a través de una especificación formal, tomando

como entrada un esquema de base de datos relacional.

1.5 Hipótesis del trabajo.

Las especificaciones formales de los cubos de datos nos permiten conocer las

características y comportamiento de una Base de Datos Multidimensional previo a

su implementación.

Variable independiente. Las especificaciones formales del cubo.

Variable dependiente. EL conocimiento del comportamiento en la construcción

del esquema de la base de datos multidimensional.



1.6 Objetivo.

Desarrollar un modelo formal para la especificación de Bases de Datos

Multidimensionales que pueda ser representado con SQL para un caso de

estudio orientado a la Administración de las actividades Docentes.

Objetivos específicos.

1. Definir el modelo formal.

2. Especificar el caso de estudio.

3. Detallar el flujo de datos para el caso de estudio.

1.7 Descripción de la organización del trabajo.

En el apartado 1 se exponen las razones que se tuvieron para la elección del

tema, se describe el contexto del problema, se establece la hipótesis del trabajo y

se define el objetivo general del proyecto, así como sus objetivos específicos.

En el apartado 2 se presenta el marco histórico donde se especifica el origen de

este proyecto, enseguida el marco contextual muestra los conceptos principales

así como los trabajos relacionados y sus aportaciones.

El apartado 3 incluye el análisis del sistema que abarca el esquema conceptual del

proyecto (Big Picture), los requerimientos del proyecto y el modelo para la

especificación formal de bases de datos multidimensionales, el diseño del sistema

contiene el modelo del esquema multidimensional, el diseño arquitectónico donde

se visualizan las dimensiones del cubo de datos y la tabla de hechos, el diseño del

cubo de datos es el diseño físico, el caso de estudio es donde se demuestra el



cubo de datos propuesto a través del MCD3 y el flujo de datos de la Big Picture

utilizando el caso de estudio, además el análisis de resultados obtenidos.

En el apartado 4 se detallan las conclusiones que se obtuvieron del trabajo, así

como las recomendaciones para trabajos futuros.

3 Modelo del Cubo de Datos



2. Estado del campo de conocimiento.

2.1 Introducción.

En este apartado se presenta el marco histórico donde se especifica el origen de

este proyecto, enseguida el marco contextual en el que se muestran los conceptos

principales así como los trabajos relacionados y sus aportaciones para este

proyecto y al final el marco teórico donde se expone el sustento teórico que sirve

de soporte para la realización de este trabajo.

2.2 Marco histórico.

Este proyecto tuvo sus inicios en la Jefatura de Proyectos de Docencia

dependiente del Departamento de Sistemas y Computación del Instituto

Tecnológico de Colima, donde cada semestre se lleva un Control de las

planeaciones de las materias que los docentes imparten a los alumnos (Anexo A).

Cada docente al inicio del semestre entrega la planeación de cada una de las

materias que impartirá así como las instrumentaciones didácticas (Anexo B) de

cada una de las unidades de que constan las materias.

Durante el transcurso del semestre el docente entrega avances de calificaciones

(Anexo C) y al final del curso entrega las actas de calificaciones (Anexo D), donde

aparece el índice de aprobación y reprobación del grupo.

El Jefe del Proyectos de docencia en cada entrega de calificaciones parciales

captura el porcentaje de aprobación de cada una de las unidades evaluadas por

cada una de las materias en una hoja de cálculo en Excel, y de manera

automática se calcula el porcentaje de reprobación. Al final del semestre hace el

mismo proceso pero en este caso son los porcentajes de aprobación y

reprobación que hubo en la materia en el semestre. De manera automática se

pueden generar gráficas de reprobación por materia y por maestro. Esta es la

información que se obtiene para el departamento.



Desde hace años y a partir del ingreso al posgrado, el tema de interés siempre ha

sido el área de base de datos y en este caso el interés fue el de diseñar un

esquema en base de datos multidimensional, donde se pueda almacenar

información y posteriormente recuperarla a un bajo costo.

En la materia de bases de datos y bases de conocimiento se estudiaron varios

algoritmos de minería de datos y al final se utilizó un paquete llamado Weka, con

el cual a través de un conjunto de datos almacenados, se pudo obtener

información valiosa. Las áreas donde se pueden aplicar estas técnicas de minería

de datos son extremadamente variadas, siempre que se disponga de un conjunto

de datos. Con los algoritmos anteriormente mencionados y con el esquema

multidimensional se puede obtener información desde diferentes puntos de vista,

que de otra manera sería difícil obtenerla con el esquema actual manejado tanto

en la Jefatura de Docencia, como en el sistema de control escolar del Instituto.

2.3 Marco contextual.

En este apartado, se presenta una breve descripción de otros trabajos en

modelado conceptual y lógico de bases de datos multidimensionales. Para

facilitar la comprensión de dichos trabajos y unificar terminología, previamente se

presentará una introducción a las estructuras y operaciones de los modelos

multidimensionales.

2.3.1 Bases de datos multidimensionales.

Son bases de datos diseñadas para desarrollar aplicaciones muy concretas, como

creación de Cubos OLAP4. Básicamente no se diferencian demasiado de las

bases de datos relacionales (una tabla en una base de datos relacional podría

serlo también en una base de datos multidimensional), la diferencia está más bien

a nivel conceptual; en las bases de datos multidimensionales los campos o

4 (On-Line Analytical Processing) por sus siglas en inglés.



atributos de una tabla pueden ser de dos tipos, pueden representan dimensiones

de la tabla, o bien representan métricas que se desean estudiar.

Santa Cruz Ramos señala que las bases de datos multidimensionales se utilizan

principalmente para crear aplicaciones OLAP y pueden verse como bases de

datos de una sola tabla, su peculiaridad es que por cada dimensión tienen un

campo (o columna), y otro campo por cada métrica o hecho, es decir estas tablas

almacenan registros cuyos campos son de la forma: (d1,d2,d3,...,f1,f2,f3,...) donde

los campos 'di' hacen referencia a las dimensiones de la tabla, y los campos 'f i' a

las métricas o hechos que se quieren almacenar, estudiar o analizar.

2.3.2 Cubos OLAP.

Según Thomsen en el 2002, la noción de un hipercubo o un cubo con más de tres

dimensiones, es fundamental para una comprensión de software multidimensional

que utiliza hipercubos de la misma manera que las hojas de cálculo utilizan hojas

de trabajo y las bases de datos utilizan tablas. Toda la navegación, presentación

de informes y el análisis se realiza en términos de hipercubos.

Los hipercubos se introducen normalmente siguiendo una descripción de

superficies de dimensiones menores tales como líneas, planos y cubos. Es común

que una persona deje de visualizar, por analogía, un cubo de dimensiones

superiores. Sin embargo, este no es el mejor enfoque debido a que el camino

hacia la comprensión de hipercubos no pasa a través de la longitud, el ancho y la

altura de un cubo físico.

Comencemos con un ejemplo típico de los datos de dos dimensiones. Cualquier

cosa que se requiera seguir, si se trata de horas por empleado, los costos por

departamento, saldo por cliente o quejas por tienda, se pueden organizar en un

formato de dos dimensiones.

La tabla 1 muestra cinco columnas de datos de ventas y costos organizados por

mes en una rejilla bidimensional. Esta red podría crearse fácilmente con cualquier



programa de hoja de cálculo y desplegarse en cualquier pantalla de computadora.

Los Meses están dispuestos en filas. La red cuenta con cinco columnas: una para

cada venta o variables de costos. El conjunto de datos se puede decir que tiene

dos dimensiones: la dimensión meses organizada por filas y las variables

dimensión representada por las columnas.

Tabla 1 Ventas, costos y utilidad por mes

Meses Ventas Costos

directos

Costos

indirectos

Costos

totales Utilidad

Enero 520 320 110 430 90

Febrero 400 250 130 380 20

Marzo 430 300 120 420 10

Abril 490 320 150 470 20

Mayo 520 310 180 490 30

Junio 390 230 150 380 10

Julio 470 290 160 450 20

Agosto 500 360 150 510 -10

Septiembre 450 290 140 430 20

Octubre 480 290 140 430 50

Noviembre 510 310 150 460 50

Diciembre 550 330 160 490 60

La tabla 2 muestra una pantalla de hoja de cálculo de un conjunto de datos

visualizados tridimensionalmente. La mayor parte de la pantalla visualiza la

misma como pantalla de dos dimensiones presentada en la tabla 1. Se trata

esencialmente de una rejilla de dos dimensiones, excepto, en la parte superior

izquierda de la pantalla, hay un icono llamado página con la etiqueta del producto:

Zapatos. El icono de la página representa la tercera dimensión, llamada página.

El conjunto de datos tridimensionales formado por las variables, tiempo, y

productos se muestra en una pantalla en términos de las tres dimensiones de la

pantalla: fila, columna y página. Las dimensiones de visualización de fila y

columna corresponden a la fila y columna de las dimensiones de la pantalla.



Tabla 2 Pantalla típica de tres dimensiones

Podemos ver tantas filas y columnas de datos como filas de la pantalla y

columnas se permitan. Dada una pantalla lo suficientemente grande, podríamos

ver la totalidad de cualquier conjunto de datos bidimensional. En contraste, la

dimensión de la página no corresponde con nada con la realidad en la pantalla. No

importa qué tan grande es la pantalla, todo lo que se ve es un indicador diciendo

que la página visible es actualmente: zapatos, calcetines, camisas, etc. Sin

embargo, es fácil de visualizar la relación entre los datos que se muestran en la

pantalla y el conjunto de datos almacenados en el ordenador. Todo lo que se tiene

que hacer es imaginar un cubo tridimensional de datos y una visualización de

pantalla que muestra una rebanada de ese cubo, como se ilustra en la Tabla 3.

Meses Ventas Costos

directos

Costos

indirectos

Costos

totales Utilidad

Enero 520 320 110 430 90

Febrero 400 250 130 380 20

Marzo 430 300 120 420 10

Abril 490 320 150 470 20

Mayo 520 310 180 490 30

Junio 390 230 150 380 10

Julio 470 290 160 450 20

Agosto 500 360 150 510 -10

Septiembre 450 290 140 430 20

Octubre 480 290 140 430 50

Noviembre 510 310 150 460 50

Diciembre 550 330 160 490 60

Página

Producto: zapatos

s

Filas

Tiempo: meses

Columnas

Variables: todas

Columnas



mes

es

Tabla 3 Rebanada de un cubo

Meses Ventas Costos

directos

Costos

indirectos

Costos

totales Utilidad

Enero 520 320 110 430 90

Febrero 400 250 130 380 20

Marzo 430 300 120 420 10

Abril 490 320 150 470 20

Mayo 520 310 180 490 30

Junio 390 230 150 380 10

Julio 470 290 160 450 20

Agosto 500 360 150 510 -10

Septiembre 450 290 140 430 20

Octubre 480 290 140 430 50

Noviembre 510 310 150 460 50

Diciembre 550 330 160 490 60

Filas

Tiempo: meses

Página

Producto: zapatos

s

Columnas

Variables: todas



2.3.3 Trabajos relacionados y sus aportaciones.

Un tutorial de un sistema experimental, donde el objetivo fue evaluar las diferentes

modalidades de acceso (voz, gráficas y modo táctil) para acceder y presentar

ciertos tipos de información, para ciertas estrategias de búsqueda y navegación

en una base de datos musical multidimensional, utilizando un dispositivo móvil

simulado es el trabajo propuesto por Esch-Bussenmarkers en el 2004.

El formalismo Polaris, que permite construir una interfaz interactiva para explorar

bases de datos multidimensionales que los analistas pueden utilizar de manera

rápida y de forma incremental en la construcción de una gama expresiva de vistas

de sus datos que ellos involucran en un ciclo de análisis visual fue expuesto por

Stolte en el 2006.

Un enfoque para explorar cubos de datos multidimensionales con técnicas de

visualización jerárquicas fue presentado por Mansmann en el 2007.

Un algoritmo de construcción de elipsoides basado en (ER-Tree), presentado para

demostrar que estos afectan significativamente la velocidad, la indexación y el

rendimiento de las consultas en bases de datos grandes como de multimedia,

medicina y geográficas fue propuesto por Dankoand en el 2009.

Tres herramientas de visualización de datos interactivos que se ejecutan en el

motor de datos en el lado del cliente, permiten combinar recorridos OLAP en las

celdas de las dimensiones y obtener pruebas estadísticas para descubrir

diferencias métricas significativas entre los grupos muy similares fue desarrollado

por Ordonez en el 2009.

Un enfoque jerárquico llamado Diagrama de Dispersión Diferencial que permite

relacionar múltiples niveles de jerarquía relativa y, explícitamente visualiza las

diferencias entre los datos en el contexto de la posición absoluta de los valores

pivotantes, a diferencia de la mayoría de los métodos de visualización que se

limitan a niveles jerárquicos individuales es propuesto por Piringer en el 2009.



Un modelo conceptual para modelar jerarquías personalizadas en bases de datos

multidimensionales plantea Pitarch en el 2009.

Una propuesta de un cubo de visualización para el modelado de la interacción en

el análisis exploratorio de información de tendencias en el espacio y tiempo,

presentó Takama en el 2009.

Un prototipo funcional de un sistema OLAP centrado en el cliente, el cual cuenta

con un middleware personalizado en el lado del servidor y un cliente web que

incorpora un motor ligero de datos OLAP para consultas en memoria, expone

Hsiao en el 2011 en su investigación.

Un trabajo que plantea combinar el recorrido de las celdas de la dimensión y

pruebas estadísticas paramétricas para identificar diferentes métricas significativas

entre celdas de un cubo, propone Ordonez en el 2011.

Un sistema llamado TEXplorer que permite a los usuarios realizar búsquedas de

palabras clave y obtener valores de agregación OLAP, esta exploración se realiza

en un cubo construido sobre una base de datos multidimensional, es presentado

por Zhao en el 2011.

Un planteamiento de la formalización de la trayectoria del esquema relacional, que

se convierte en la base para la obtención de reparaciones dimensionales, donde

se muestra que la estrella común relacional y el esquema de copo de nieve para

bases de datos multidimensionales, no son la mejor opción para este proceso,

propone Yaghmaie en el 2012.

Varias formas de reorganizar un cubo OLAP en función de los cuales se

selecciona un conjunto de miembros de la reorganización: de la totalidad de los

miembros, donde sólo se muestran los miembros, de un determinado nivel, es

presentado por Lafon en el 2013.



La utilización de un mapa de auto organización Kohonen (KSOM)5 para organizar

los datos no estructurados para superficies cerradas, este mapa se utiliza en este

trabajo mediante pruebas para mostrar su capacidad de organizar los datos de

imagen médica porque KSOM es utilizado sobre todo en la construcción de los

datos de campo de la ingeniería, este trabajo fue propuesto por Seng en el 2013.

La lectura de los trabajos anteriores me permitió conocer las diferentes

organizaciones de los datos en los cubos de datos, así como aprender diferentes

propuestas de recorridos de los datos para hacer más óptimas las consultas,

además de entender los esquemas tradicionales para organizar esquemas

multidimensionales y con todo esto poder organizar un cubo de datos y

representarlo en una base de datos multidimensional para la solución de un

problema, que es esta propuesta de trabajo de tesis.

2.3.4 Un ejemplo de información de un cubo de datos, obtenida a

través de una herramienta OLAP.

Vivimos en la sociedad de la información. Gracias a Internet y al desarrollo de los

sistemas de información en las empresas, sus directivos pueden acceder a mucha

más información, de más calidad y con mayor rapidez. El potencial que ello ofrece

para mejorar la toma de decisiones y para guiar a las empresas hacia la

consecución de sus objetivos es enorme. Sin embargo, muchos directivos se

enfrentan a la paradoja de que “cada vez tienen más información y menos tiempo

para analizarla”. La creciente internacionalización de los mercados, y la

consiguiente intensificación de la dinámica competitiva, convierten la paradoja

anterior en un auténtico reto de gestión. La capacidad para tomar decisiones con

rapidez, basadas en un adecuado conocimiento de la realidad de la empresa así

como del mercado y sus tendencias, ha pasado a convertirse en una nueva fuente

de ventaja competitiva.

5 (Kohonen Self-Organizing Map) por sus siglas en inglés



Por ejemplo: “Mostrar los ingresos trimestrales correspondientes a grandes

clientes comerciales en las regiones norte, noroeste y suroeste en 1997 y 1998”

Informe básico para soporte de decisión

1997 1998

1er. Trim. 2do. Trim. 3er. Trim. 4to. Trim. 1er. Trim. 2do. Trim.

Norte 50 35 44 95 45 33

Noroeste 38 43 43 50 38 45

Suroeste 34 23 46 72 30 28

Ingresos contabilizados (en miles)

“Mostar los mismos datos por distrito de la región Noroeste”

Salida utilizando herramientas OLAP

1997 1998


Norte 50 35 44 95 45 33

Noroeste Distrito A 13 15 14 18 11 14

Distrito B 10 12 12 13 8 16

Distrito C 15 16 17 19 19 15

Suroeste 34 23 46 72 30 28




“Mostrar los mismos datos para el distrito B de la región noroeste”

Análisis en profundidad (Drill-Down)

1997 1998


Norte 50 35 44 95 45 33

Noroeste Distrito A 13 15 14 18 11 14

Distrito B 10 12 12 13 8 16

Toledo 6 7 6 6 4 9

Columbus 2 2 2 3 2 3

Cleveland 2 3 4 4 2 4

Distrito C 15 16 17 19 19 15

Suroeste 34 23 46 72 30 28


La operación Drill-Down (herramienta OLAP), es una operación de disgregación

en el ejemplo anterior, de los agregados del distrito B.



2.4 Marco teórico.

A continuación se detallan los conceptos incluidos en este proyecto:

2.4.1 Sistema de Gestión de Base de datos.

Un sistema de gestión de base de datos (DBMS)6 consiste en una “colección de

datos interrelacionados y un conjunto de programas para acceder a esos datos”

(Silberschatz, Korth, Fundamentos de Bases de datos, 2002). El objetivo

primordial de un DBMS es proporcionar un entorno que sea a la vez conveniente y

eficiente para ser utilizado al extraer información de la base de datos.

“Una colección compartida de datos lógicamente relacionados, junto con una

descripción de estos datos, que están diseñados para satisfacer las necesidades

de información de una organización” (Connolly & Begg, 2005).

Los sistemas de bases de datos están diseñados para gestionar grandes bloques

de información. La gestión de datos implica tanto la definición de estructuras para

el almacenamiento de información como la provisión de mecanismos para la

gestión de la información. Además, los sistemas de bases de datos deben

mantener la seguridad de la información almacenada, pese a caídas del sistema o

intentos de accesos no autorizados. Si los datos van a ser compartidos por varios

usuarios, el sistema debe evitar posibles resultados anómalos.

2.4.2 Bases de datos multidimensionales.

Se le denomina a una base de datos de estructura basada en dimensiones (lados

de un cubo de datos) orientada a consultas complejas y alto rendimiento. Puede

utilizar un SGBDR7 en estrella (Base de datos Multidimensional a nivel lógico) o

6 (Data Base Management System) por sus siglas en inglés. 7 Sistema de Gestión de Base de Datos Relacional.



SGBDM8 (Base de datos Multidimensional a niveles lógico y físico o Base de datos

Multidimensional Pura) (De la Herrán Gascón, 2004)

2.4.3 Cubo de datos.

El Cubo de datos, que acuña su nombre por su característica multidimensional, es

una base de datos que posee diversas dimensiones.

Los cubos de datos se utilizan en los sistemas de procesamiento analítico en línea

(OLAP) para apoyar la toma de decisiones y es construido a partir de las base de

datos de un negocio. Un cubo de datos es una estructura (forma de organizar los

datos) que puede ser aplicada sobre un grupo de valores de base de datos

(conjunto de datos históricos de un negocio) y generar todos los posibles valores

de agregación.

Es un reto organizar de manera eficiente los elementos de datos (valores y grupos

de agregación) y visualizar las relaciones entre los elementos de datos. Se han

propuesto varios enfoques para abordar esta cuestión, incluyendo:

Un sistema de visualización multiescala para ver los cubos de datos;

Un espacio hiperbólico para visualizar los cubos de datos de dimensiones

grandes;

Los métodos visualización wavelet (ondícula) para representar los cubos de

datos multidimensionales;

Los elementos gráficos regulares integrados en la pantalla de cubos de

datos en los diferentes niveles;

Mejora del árbol de descomposición, una estructura de visualización

jerárquica de los cubos de datos multidimensionales;

Análisis estadísticos aplicados en la visualización de cubo de datos para

descubrir las diferencias métricas significativas entre los grupos de

agregación muy similares, y

8 Sistema de Gestión de Base de Datos Multidimensional.



Diagramas de dispersión de diferencias jerárquicas para la visualización de

cubos de datos.

Cada uno de estos enfoques aplica diferentes técnicas y métodos para visualizar

los cubos de datos a diferentes niveles y en diferentes espacios.

La propuesta de este trabajo utiliza una estructura de visualización jerárquica

(utiliza dimensiones) del cubo de datos multidimensional para organizar la

información.

2.4.4 Sistemas OLPT (On Line Transactional Processing)9.

Se trata de los procesos clásicos de tratamiento automático de información, que

incluyen Altas, Bajas, Modificaciones y Consultas.

2.4.5 Sistemas OLAP (On Line Analytical Processing)10.

Consisten en procesos de análisis de información. Estos sistemas están

orientados al acceso en modo consulta.

2.4.6 Data Warehouse.11

Un sistema de almacén de datos reúne la información generada por los distintos

departamentos de una organización. Pretende conseguir que cualquier

departamento pueda acceder a la información de cualquiera de los otros mediante

un único medio, así como obligar a que los mismos términos tengan el mismo

significado para todos. Es un almacén de datos históricos, utilizado por una

herramienta OLAP para procesar información, elaborar informes y vistas. También

se define como un conjunto de datos orientados por tema, integrados, variables en

el tiempo y no volátiles que se emplea como apoyo a la toma de decisiones.

9 Procesamiento Transaccional en línea 10 Procesamiento analítico en línea 11 Almacén de datos



2.4.7 Datamart.12

Sistema que mantiene una copia de un Data Warehouse para un uso

departamental. Almacén de datos históricos relativos a un departamento de una

organización, utilizado por una herramienta OLAP para procesar información,

elaborar informes y vistas.

2.4.8 Data mining.13

Proceso no trivial de análisis de grandes cantidades de datos con el objetivo de

extraer información útil. Por ejemplo, se trata de aplicar algoritmos de clasificación

de datos para realizar predicciones futuras, o estudios de correlación entre

variables aparentemente independientes. Para ello es común la utilización de

Redes Neuronales o Algoritmos Evolutivos.

2.4.9 Sistema ETL (Extract, Transform and Load).

Es el Proceso de extracción de información, transformación de la misma y Carga

de datos en el almacén de datos.

2.4.10 Herramientas OLAP.

Roll, agrupa datos por alguna dimensión determinada, por ej: analizar los

índices de reprobación por materia, a los índices de reprobación por

carrera.

Drill, realiza la operación inversa. Muestra la información detallada de cada

agrupamiento. Por ej: analizar los índices de reprobación por carrera a los

índices de reprobación por materia.

12 Pequeños Data Warehouse centrados en un tema o área de negocio específico 13 Minería de datos



Slice, al seleccionar algún miembro en particular de una dimensión se

forma una especie de rebanada del cubo original. Por ej: se puede tener los

datos de reprobación de las materias de un docente en particular.

Dice, selecciona varios miembros de varias dimensiones y se forma un

subcubo (cubo más pequeño) o dado. Por ej: los índices de reprobación de

un docente, en una materia en un año.

Pivot, rota el cubo para ver una cara en particular. Por ej: en vez de ver

materias vemos docentes.

2.4.11 Sistemas ROLAP.

Arquitectura de Base de Datos Multidimensional en la que los datos se encuentran

almacenados en una Base de Datos Relacional, normalmente en forma de estrella

o copo de nieve.

2.4.12 Sistemas MOLAP.

Arquitectura de Base de Datos Multidimensional en la que los datos se encuentran

almacenados en una Base de Datos Multidimensional, que mejora los tiempos de

acceso a costa de mayores necesidades de almacenamiento y retardos en las

modificaciones.

2.4.13 Sistemas HOLAP.

Arquitectura que combina las tecnologías ROLAP y MOLAP. En HOLAP, el

soporte de almacenamiento de datos y el motor de generación de vistas contienen

elementos de ambas tecnologías. Pretende combinar las ventajas de cada una sin

sus inconvenientes.



2.4.14 Campos ordinales y cuantitativos.

Campos ordinales: La escala ordinal es representada en forma discreta, como

encabezados o clases diferentes.

Campos cuantitativos: Son conjuntos y son mostrados como ejes o como valores

de una variación continua.

2.4.15 Dimensiones y mediciones.

Esta clasificación corresponde al rol asociado al campo. Las dimensiones y

medidas son similares a las variables independientes y dependientes del análisis

tradicional.

Las bases de datos relacionales son organizadas en tablas en donde los

renglones corresponden a entidades básicas o hechos y cada columna

representa una propiedad de una entidad. Los renglones son considerados como

registros o tuplas y las columnas como campos.

2.4.16 Álgebra de tablas.

Un álgebra es un mecanismo formal para especificar la configuración de las

tablas. Una configuración completa consiste de tres expresiones separadas en el

álgebra de tablas. Dos de las expresiones definen la configuración del eje X y del

eje Y de la tabla particionando la tabla en ejes y columnas. La tercera expresión

define el eje de las Z de la tabla, la cual particiona el desplegado en capas. Las

expresiones X, Y y Z forman las cláusulas en el lenguaje.

Los operandos en el álgebra de tablas son nombres de campos ordinales o

cuantitativos de la base de datos. Se utiliza A, B y C para representar campos

ordinales y P, Q y R para representar campos cuantitativos. Asignamos

secuencias de valores a cada símbolo de campo de la siguiente manera: a los

campos ordinales asignamos los miembros de un dominio ordenado del campo.



A los campos cuantitativos se asignan conjuntos de elementos individuales

conteniendo el nombre del campo.

Los campos ordinales y cuantitativos generan tablas con diferentes estructuras

(1)-(2). Los campos ordinales particionan la tabla en renglones y columnas

utilizando encabezados, mientras que los campos cuantitativos generan ejes.

A = domain (A) = {a1,...,an} (1) P = {P} (2)

Una expresión válida en el álgebra consiste de uno o más símbolos con

operadores entre cada par de operandos adyacentes y con paréntesis utilizados

para alterar la precedencia de los operadores.

2.4.17 Operadores del álgebra de tablas.

Concatenación (+) El operador + (3)-(5) concatena dos secuencias de la

siguiente forma:

A + B = {a1, ..., an} + {b1, ..., bm} (3) = {a1, ..., an, b1, ..., bm} A + P = {a1, ..., an} + {P} (4) = {a1, ..., an, P} P + Q = {P} + {Q} (5) = {P, Q}

Producto: (X) El operador Producto (6)-(7) realiza el producto cartesiano de dos

secuencias.

A × B ={a1, ..., an} × {b1, ..., bm} (6) ={a1b1, ..., a1bm, a2b1, ..., a2bm, ..., anb1, ..., anbm} A × P = {a1, ..., an} × P (7)



= {a1P,..., anP} Proyección (/) El operador Proyección es similar al operador producto, pero solo

crea secuencias para las cuales existen registros.

Por ejemplo dados los campos trimestre y mes, la expresión trimestre/mes podría

interpretarse como aquellos meses dentro de cada trimestre, resultando en tres

entradas para cada trimestre. En contraste trimestre X mes podría resultar con 12

entradas para cada trimestre. Los cubos de datos representan jerarquías

explícitamente y no es necesario calcular la relación de proyección.

2.4.18 Formas normalizadas.

La forma normalizada de una expresión determina un eje de la tabla: El eje de la

tabla es particionado en columnas (o renglones o capas) de tal manera que existe

una correspondencia de uno a uno entre el conjunto de entradas en el conjunto

normalizado y las columnas.

2.5 Conclusión.

En este apartado se pueden ver los orígenes del proyecto, donde empezó a tomar

forma el presente trabajo, el objetivo siempre fue el crear un esquema de base de

datos multidimensional; a través de los diferentes autores mencionados en los

trabajos relacionados, se conocieron las tendencias para almacenar información

en sus diferentes enfoques, así como la extracción de la información utilizando

diferentes estrategias en las consultas, además de comprender la forma de

construir un cubo de datos, y de insertarle información a través del proceso ETL y

extraer información a través de las instrucciones OLAP (Roll, Drill, Slice y Dice),

todo esto dio como resultado el modelo de cubo de datos propuesto que a

continuación se presenta.

especificaciÓn formal de cubos de datos aplicados …

Documents