minería de datos en la construcción de vigas de hormigón armado by roger gustavo saravia aramayo

Universidad Mayor de San Andrés Facultad de Ciencias Puras y Naturales Postgrado en Informática Data Mining – Minería de Datos

Aplicación de la Técnica de Agrupamiento de la Minería de Datos a los Resultados Obtenidos en la Construcción de Vigas de Hormigón Armado para el Soporte a la Toma de Decisiones de una Empresa Consultora/Constructora

Presentado a:

Dr. Rogelio Silverio

Presentado por: Roger Saravia, R. A. y M. A.

La Paz, Bolivia – Junio 13 de 2008

Resumen En este trabajo de investigación se diseñará e implementará en la herramienta Business Intelligence Development Studio de MS SQL Server 2005, un modelo de minería de datos a partir de un almacén de datos (Data Warehouse) basado en procesamiento analítico multidimensional (MOLAP) para el soporte a la toma de decisiones en el proceso de diseño/construcción de vigas de hormigón armado por parte de una empresa consultora/constructora. Se llegará a hacer algunas predicciones a partir de la probabilidad reflejada en los atributos de clusters de datos producidos por un algoritmo de agrupamiento de minería de datos. El modelo de minería de datos estará centrado en campos que harán posible la comparación de lo construido versus lo proyectado de vigas de hormigón armado. Primero, se hace una revisión esencial y breve del marco teórico que respalda el Data Warehouse, el Data Mining y el dominio de aplicación. A continuación, se listan las necesidades de información para la toma de decisiones de la empresa; como ser: medidas y dimensiones. Luego, se identifican las fuentes de datos disponibles (OLTPs). Con todo esto, se diseña un modelo de datos multidimensional o Data Mart para el análisis en línea desde cualquier perspectiva. Para poblar dicho Data Mart o cubo, se transforman éstas fuentes de datos mediante un servicio de integración. Luego, se diseñan y procesan las agregaciones para examinar el cubo y aplicarlo al análisis multidimensional. Posteriormente, se diseña e implementa un modelo de minería de datos con los campos involucrados en la materialización de vigas de hormigón armado y en base a la técnica de clustering a partir del cubo OLAP desarrollado en la parte previa. Finalmente, se exploran las características más importantes de los grupos o clusters obtenidos en los resultados de la minería de datos y se hacen algunas predicciones a partir de de la probabilidad de ocurrencia de los atributos de éstos grupos.

Palabras Clave BASES DE DATOS, CONSULTAS SQL, SISTEMAS OPERACIONALES, DSS, SISTEMAS DE INFORMACIÓN, TECNOLOGÍAS DE LA INFORMACIÓN, DATAWARE HOUSE, OLTP, ÁREA DE ESTACIONAMIENTO DE DATOS, CUBO, DATA MART, OLAP, ROLAP, MOLAP, DRILL-DOWN, ROLL-UP, MODELO MULTIDIMENSIONAL, DIMENSIONES, JERARQUÍAS, HECHOS, ESQUEMA STAR, ESQUEMA SNOWFLAKE, CONSTELACIÓN DE HECHOS, METADATA, ODS, OBS, SQL SERVER, BUSINESS INTELLIGENCE, ANALYSIS SERVICES, KPI, INTEGRATION SERVICES, FLUJO DE CONTROL, FLUJO DE DATOS, COLUMNA DERIVADA, DATA MINING, CARACTERIZACIÓN, DISCRIMINACIÓN, ASOCIACIÓN, CLASIFICACIÓN, DESVIACIONES, EVALUACIÓN, REGRESIÓN, SEGMENTACIÓN, CLUSTERING, DIAGRAMA DEL CLUSTER, PERFILES DEL CLUSTER, CARACTERÍSTICAS DEL CLUSTER, DISTINCIÓN DEL CLUSTER, REPORTING SERVICES, HORMIGÓN ARMADO.

Índice 1

INTRODUCCIÓN............................................................................................................................................................... 2 1.1 1.2 1.3

ESCENARIO ................................................................................................................................................................... 2 PROBLEMA IDENTIFICADO ............................................................................................................................................ 2 ABORDAJE DEL PROBLEMA .......................................................................................................................................... 3

OBJETIVOS ESPECÍFICOS ............................................................................................................................................ 3

MARCO TEÓRICO ........................................................................................................................................................... 3 3.1 3.2 3.3 3.4 3.5 3.5.1 3.6 3.7 3.8 3.9 3.9.1 3.9.2 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19

SISTEMAS OPERACIONALES .......................................................................................................................................... 3 SISTEMAS PARA EL SOPORTE DE DECISIONES (DSS) .................................................................................................... 3 SISTEMAS DE INFORMACIÓN ......................................................................................................................................... 4 TECNOLOGÍA DE LA INFORMACIÓN............................................................................................................................... 4 DATA WAREHOUSE - ALMACENES DE DATOS .............................................................................................................. 4 Pasos para el Diseño de un Data Warehouse ......................................................................................................... 5 OLTP (ON-LINE TRANSACTION PROCESSING) ............................................................................................................. 5 ÁREA DE ESTACIONAMIENTO DE DATOS ...................................................................................................................... 5 DATA MART ................................................................................................................................................................. 6 PROCESAMIENTO ANALÍTICO EN LÍNEA (OLAP: ON-LINE ANALYTICAL PROCESSING) ............................................................. 6 Operaciones OLAP ................................................................................................................................................. 6 Las 18 Características de OLAP (Reglas de Codd Ampliadas) .............................................................................. 7 MODELO MULTIDIMENSIONAL ..................................................................................................................................... 8 DISEÑO LÓGICO ........................................................................................................................................................... 8 METADATA .................................................................................................................................................................. 8 ODS (OPERATIONAL DATA STAGE) ............................................................................................................................. 9 MINERÍA DE DATOS (DATA MINING)............................................................................................................................ 9 PROCESO DE DESCUBRIMIENTO DE CONOCIMIENTO ..................................................................................................... 9 TAREAS DE LA MINERÍA DE DATOS .............................................................................................................................. 9 SECUENCIA CONCEPTUAL PARA LA MINERÍA DE DATOS EN SQL SERVER ................................................................. 10 CAMPO DE APLICACIÓN: HORMIGÓN ARMADO - RAMA DE LA INGENIERÍA CIVIL ..................................................... 11 Vigas Simplemente Reforzadas ............................................................................................................................. 11

DESARROLLO PRÁCTICO........................................................................................................................................... 13 4.1 4.1.1 4.1.2 4.2 4.3 4.4 4.5

INFORMACIÓN NECESARIA PARA EL APOYO A LA TOMA DE DECISIONES ................................................................... 13 Medidas................................................................................................................................................................. 13 Dimensiones .......................................................................................................................................................... 13 INFORMACIÓN DISPONIBLE ........................................................................................................................................ 14 MODELO DE DATOS PARA EL DATA MART ................................................................................................................. 17 IMPLEMENTACIÓN DEL CUBO EN MICROSOFT SQL SERVER 2005 .............................................................................. 20 MINERÍA DE DATOS – TÉCNICA DE AGRUPAMIENTO O CLUSTERING .......................................................................... 39

CONCLUSIONES ............................................................................................................................................................. 61

REFERENCIAS.......................................................................................................................................................................... 62 APÉNDICES ............................................................................................................................................................................... 62 A

REPORTING SERVICES ..................................................................................................................................................... 62 A.1 Arquitectura Integrada ......................................................................................................................................... 62 A.2 Soporte Completo para el Ciclo de Vida de los Informes ..................................................................................... 63

Introducción

1.1

Escenario Este proyecto de investigación se extiende en el área del Data Mining (minería de datos) de las bases de datos profesionales de las ciencias de la computación con campo de aplicación en la tecnología del hormigón armado de la ingeniería civil; específicamente, en el diseño y construcción del elemento horizontal denominado viga.

1.2

Problema Identificado Un problema identificado en el proceso de diseño/construcción de elementos de hormigón armado es la carencia de información compilada, precisa y de respaldo que permita soportar la toma de decisiones con relación a dicho proceso. Los elementos de hormigón armado como vigas, columnas, losas y otros, muy pocas veces se construyen exactamente conforme el cálculo proyectado en los planos; más bien, las desviaciones durante la construcción, ocurren frecuentemente y se van acumulando en dependencia de la cantidad de elementos que componen una edificación u otra obra civil. Estas desviaciones en la construcción a la larga ocasionan pérdidas económicas o reflejan una mala administración de fondos; pero sobre todo, podrían lograr atentar contra el factor de seguridad funcional que debería ofrecer una obra de servicio. Es importante aclarar que, las desviaciones en la construcción de un elemento se deben muchas veces a un inadecuado manejo y conocimiento de la precisión que ofrecen los medios de construcción o bien se deben a fallas humanas de dirección y/o ejecución.

≠ Ilustración 1. Los elementos de hormigón armado no siempre se construyen estrictamente según el diseño.

1.3

Abordaje del Problema Se pretende abordar el problema mediante el diseño e implementación de una inteligencia de negocio basada en un Data Warehouse soportado por un cubo o Data Mart multidimensional poblado a partir de una base de datos transaccional del proceso diseño/construcción y favorecido por una operación de Data Mining (minería de datos) sustentada por una técnica de descubrimiento del conocimiento por agrupamiento o clustering; todo esto, para lograr un conjunto de clusters o grupos de determinadas características que permitan la posible predicción de información y así poder obtener un sistema de soporte para la toma de decisiones de la empresa. Se empleará la herramienta Microsoft SQL Server 2005 – Business Intelligence Development Studio.

Objetivos Específicos 

Identificar la información e indicadores necesarios para la toma de decisiones de la empresa.



Identificar la información y fuentes OLTP disponibles.



Diseñar e implementar un Data Mart para la recopilación de medidas sobre el diseño/construcción de vigas de hormigón.



Poblar el Data Mart aplicando servicios de transformación e integración a las fuentes de datos.



Definir, configurar e implementar un cubo OLAP con hechos y dimensiones.



Aplicar el método de minería de datos denominado agrupamiento o clustering.



Evaluar, interpretar y transformar los patrones extraídos mediante la minería de datos.

Marco Teórico

3.1

Sistemas Operacionales Son aquellos que tienen como objetivo reflejar el estado y funcionamiento de la empresa registrando las transacciones u operaciones diarias; de aquí, que los mismos se conozcan como sistemas de Procesamiento de Transacciones en Línea (OLTP).

3.2

Sistemas para el Soporte de Decisiones (DSS) Son aquellos que tienen como objetivo medir y controlar el desarrollo de las variables importantes del negocio, buscando identificar, proyectar y predecir tendencias a partir de los datos acumulados.

3.3

Sistemas de Información Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio.

Ilustración 2. Esquema de un sistema de información.

3.4

Tecnología de la Información Es necesario establecer que la tecnología de la información (TI) se entiende como "aquellas herramientas y métodos empleados para recabar, retener, manipular o distribuir información”. La tecnología de la información se encuentra generalmente asociada con las computadoras y las tecnologías afines aplicadas a la toma de decisiones.

3.5

Data WareHouse - Almacenes de Datos “Un almacén de datos es una colección de datos consistente semánticamente que sirve como implementación física de un modelo de datos de apoyo a la toma de decisiones y que almacena la información que la organización necesita para la toma de decisiones estratégicas. Además, en muchas ocasiones, el almacén de datos es visto también como una arquitectura construida para integrar datos de múltiples fuentes heterogéneas y dar soporte a consultas estructuradas y/o ad-hoc, informes analíticos y toma de decisiones”. Un almacén de datos presenta una vista multidimensional de los datos y es por esto que se denominan bases de datos multidimensionales o cubos de datos. Un punto en un cubo de datos almacena una medida consolidada de los valores correspondientes a los valores de las dimensiones (tablas o relaciones) en un espacio multidimensional.

Prod Mon Reg cust cost reve

Produc R n e gi t o

Ventas

Month

Ilustración 3. Un cubo almacena medidas consolidadas.

3.5.1 Pasos para el Diseño de un Data Warehouse Paso 1. Elegir un “proceso” de la organización para modelar. Paso 2. Decidir el gránulo (nivel de detalle) de representación. Paso 3. Identificar las dimensiones que caracterizan el proceso. Paso 4. Decidir la información a almacenar sobre el proceso.

3.6

OLTP (On-Line Transaction Processing) OLTP es un acrónimo de Procesamiento de Transacciones en Línea. Son sistemas de producción computarizados que reúnen y consumen los datos operativos de cada día. Los sistemas OLTP sirven para crear aplicaciones en todo género de actividad. Entre ellas pueden citarse los sistemas de reservaciones, punto de venta, sistemas de rastreo, control de inventarios, estaciones de trabajo de intermediarios bursátiles y sistemas de control para fábricas manufactureras. En los sistemas OLTP lo común es que el cliente interactúe con un servidor de transacciones no con un servidor de base de datos.

3.7

Área de Estacionamiento de Datos El área de estacionamiento de datos es todo lo que está entre el sistema origen y el servidor de presentación. Es un área de almacenamiento y conjunto de procesos que limpian, transforman, combinan, optimizan, archivan y preparan los datos de origen para uso en el Data Warehouse. Aunque sería agradable que el área de estacionamiento de datos fuera un dispositivo centralizado en una pieza de hardware, es común que el área de estacionamiento de datos esté dispersada sobre un número de máquinas.

No es necesario que el área de estacionamiento de datos sea de tecnología relacional. Pero en muchos casos, los datos llegan normalizados desde una base de datos relacional. En otros casos, los administradores del área de estacionamiento de datos se ven ocupados organizando el limpiado, transformado y combinado de datos alrededor de un conjunto de estructuras normalizadas. En estos casos, una estructura normalizada para el área de estacionamiento de datos es aceptable.

3.8

Data Mart Un Data Mart es una versión especial de almacén de datos (Data Warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser, agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades. El Data Mart es un sistema orientado a la consulta en el que se producen procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP (On-Line Analytical Processing) que ofrecen una visión multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la toma de Decisiones). En síntesis, se puede decir que los Data Marts son pequeños Data Warehouse centrados en un tema o un área de negocio especifico dentro de una organización. ¿Qué diferencia existe entonces entre un Data Mart y un Data Warehouse? Su alcance. El Data Mart está pensado para cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro de la organización. Es el almacén natural para los datos departamentales. En cambio, el ámbito del Data Warehouse es la organización en su conjunto. Es el almacén natural para los datos corporativos comunes.

3.9

Procesamiento Analítico en Línea (OLAP: On-Line Analytical Processing) Codd propuso el término procesamiento analítico en línea (OLAP) para reflejar el proceso en que se muestran los datos empresariales en la perspectiva multidimensional, realizándose el análisis en línea de los mismos, utilizando fórmulas matemáticas y de análisis estadístico para consolidar y sumar los datos. En esencia, el procesamiento analítico en línea se puede ver como la síntesis, análisis y consolidación de grandes volúmenes de datos con un enfoque multidimensional.

3.9.1 Operaciones OLAP Las herramientas OLAP permiten realizar análisis en línea de los datos desde una perspectiva multidimensional. Las principales operaciones que pueden realizar sobre un cubo son:



Drill-Down (profundización progresiva)



Roll-Up (generalización progresiva)



Filtering (filtro o selección)



Pivoting (rotación)



Slice (rebanar)



Dice (cortar en cuadritos) Ilustración 4. Perspectiva multidimensional.

3.9.2 Las 18 Características de OLAP (Reglas de Codd Ampliadas) F1:

Vista conceptual multidimensional

F2:

Manipulación intuitiva de los datos

F3:

Accesibilidad

F4:

Extracción en lote versus interpretativa

F5:

Modelo de análisis de OLAP

F6:

Arquitectura cliente/servidor

F7:

Transparencia

F8:

Soporte multiusuario

F9:

Tratamiento de datos no-normalizados

F10:

Almacenamiento de los resultados OLAP manteniéndolos separados de los datos originales

F11:

Extracción de los valores omitidos

F12:

Tratamiento de los valores omitidos

F13:

Flexibilidad de reportes

F14:

Desempeño uniforme de reportes

F15:

Ajuste automático del nivel físico

F16:

Dimensionalidad genérica

F17:

Niveles ilimitados de dimensiones y agregaciones

F18:

Operaciones a través de dimensiones sin restricciones

3.10 Modelo Multidimensional En el modelo multidimensional se utiliza un esquema multidimensional en el que se representa una actividad que es objeto de análisis (hecho) y las dimensiones que caracterizan la actividad (dimensiones). La información relevante sobre el hecho (actividad) se representa por un conjunto de indicadores (medidas o atributos de hecho) La información descriptiva de cada dimensión se representa por un conjunto de atributos (atributos de dimensión).

3.11 Diseño Lógico El diseño lógico de un almacén de datos se basa en la determinación de las dimensiones y medidas; las cuales, desde el punto de vista lógico, pueden organizarse o estructurarse de alguna de las siguientes formas: 

Esquema en estrella (star): Una tabla de hechos en el centro conectada con un conjunto de tablas de dimensiones.



Esquema copo de nieve (snowflake): Un refinamiento del anterior donde algunas tablas se normalizan en tablas más pequeñas.



Constelación de hechos: Múltiples tablas de hechos comparten tablas de dimensión que se visualizan como una colección de hechos.

3.12 Metadata Uno de los componentes más importantes de la arquitectura de un Data Warehouse son los metadatos. Se definen comúnmente como "datos acerca de los datos" en el sentido de que se trata de datos que describen cuál es la estructura de los datos que se van a almacenar y cómo se relacionan. El metadato documenta, entre otras cosas, qué tablas existen en una base de datos, qué columnas posee cada una de las tablas y qué tipo de datos se pueden almacenar. Los datos son de interés para el usuario final, el metadato es de interés para los programas que tienen que manejar estos datos; sin embargo, el rol que cumple el metadato en un entorno de Data Warehouse es diferente al rol que cumple en los ambientes operacionales. En el ámbito de los Data Warehouse el metadato juega un papel fundamental y su función consiste en recoger todas las definiciones de la organización. En el Data Warehouse debe contener toda la información concerniente a:



Tablas



Columnas de tablas



Relaciones entre tablas



Jerarquías y dimensiones de datos



Entidades y relaciones

3.13 ODS (Operational Data Stage) El Almacén de Datos Operacional es un contenedor de datos activos; es decir, operacionales que ayudan al soporte de decisiones y a la operación. Está entre un OLAP y un OLTP. Su función es integrar los datos al igual que en el Data Warehouse pero con una ventana de actualización muy pequeña (del orden de minutos) y con mucho menos detalle. Consíderese también: OBS (Operacional Business Stage)

3.14 Minería de Datos (Data Mining) Se refiere a la extracción de información potencialmente útil dentro de una gran base de datos a través de técnicas que ayuden a identificar patrones dentro de todo el volumen de información. El tipo de conocimiento de reglas que se puede extraer con la minería de datos pueden ser: de caracterización, discriminación, asociación, clasificación, desviaciones, evolución.

3.15 Proceso de Descubrimiento de Conocimiento Los pasos o secuencia de procesos que se deben seguir para la obtención de conocimiento partiendo de que ya se tiene un Almacén de Datos (Data Warehouse) ya desarrollado, son:

1. Selección, limpieza y transformación de los datos a ser estudiados; esto incluye la elección de una estrategia para tener datos consistentes antes de aplicar una técnica. 2. Seleccionar y aplicar una técnica o método de minería de datos apropiado de acuerdo a la información obtenida 3. Evaluación, interpretación, transformación y representación de los patrones extraídos. En muchos casos se puede volver a realizar la minería de datos con otro método o algoritmo según sea la evaluación obtenida de la utilidad de la información. 4. Difusión y uso del nuevo conocimiento. El nuevo conocimiento puede incorporarse al sistema de la empresa o simplemente distribuirlo a las personas que toman decisiones en la empresa.

3.16 Tareas de la Minería de Datos Clasificación.- Los datos son objetos caracterizados por atributos que pertenecen a diferentes clases (etiquetas discretas). La meta es inducir un modelo para poder predecir una clase dados los valores de los atributos. Se usan por ejemplo, árboles de decisión, reglas, análisis de discriminantes.

Regresión.- La meta es inducir un modelo para poder predecir el valor de la clase dados los valores de los atributos. Se usan por ejemplo, árboles de regresión, regresión logística, lineal, redes neuronales, etc. Segmentación.- Se refiere a la separación de los datos en subgrupos o clases interesantes. Las clases pueden ser exhaustivas y mutuamente exclusivas o jerárquicas y con traslapes. Se puede utilizar con otras técnicas de minería de datos: considerar cada subgrupo de datos por separado, etiquetarlos y utilizar un algoritmo de clasificación. Se usan algoritmos de clustering, SOM (self-organization maps), EM (expectation maximization), k-means, etc. Normalmente, el usuario tiene una buena capacidad de formar las clases y se han desarrollado herramientas visuales interactivas para ayudar al usuario. Asociación.- Los modelos de asociación se generan basándose en conjuntos de datos que contienen identificadores para escenarios individuales y para los elementos que contienen los escenarios. Un grupo de elementos de un escenario se denomina un conjunto de elementos. Un modelo de asociación se compone de una serie de conjuntos de elementos y de las reglas que describen cómo estos elementos se agrupan dentro de los escenarios.

3.17 Secuencia Conceptual para la Minería de Datos en SQL Server

Definición del Problema

Consiste en definir claramente el problema empresarial. Este paso incluye analizar los requisitos empresariales, definir el ámbito del problema, definir las métricas por las que se evaluará el modelo y definir el objetivo final del proyecto de minería de datos.

Preparación de Datos

Consiste en consolidar y limpiar los datos identificados en el paso definir el problema. Por lo tanto, se debe utilizar algún método de automatización como el Integration Services, para explorar los datos y encontrar incoherencias.

Validaciones

Consiste en comprobar la eficacia del modelo; es decir, validar la precisión y comparar la habilidad de predicción de los modelos de minería de datos de una estructura de minería de datos. Esto resulta útil cuando intenta elegir el algoritmo correcto que va a utilizar o el modo de ajustar los parámetros de un algoritmo determinado.

Entrenamiento

Antes de generar un modelo, se deben de separar los conjuntos de datos preparados en conjuntos de datos de entrenamiento y de comprobación independiente. El conjunto de datos de entrenamiento se utiliza para poder generar el modelo y el conjunto de comprobación para verificar la precisión del modelo mediante la creación de consultas de predicción.

Implementación

Consiste en implementar los modelos que funcionan mejor en un entorno de producción, para poder realizar trabajos de predicción para la toma de decisiones empresariales; incluir la funcionalidad de minería de datos en una aplicación, crear un informe para realizar consultas en un modelo de minería de datos.

3.18 Campo de Aplicación: Hormigón Armado - Rama de la Ingeniería Civil El hormigón es un material semejante a la piedra obtenido mediante una mezcla de cemento, arena, grava y agua; mezcla que se endurece en encofrados con la forma y dimensiones del elemento deseado. La mayor parte consta de agregado fino y grueso. El refuerzo conformado usualmente por barras circulares de acero con deformaciones superficiales apropiadas para proporcionar anclaje, se coloca en los moldes antes de vaciar la mezcla.

3.19 Vigas Simplemente Reforzadas

Ilustración 5. Una viga de hormigón armado simplemente reforzada.

Las vigas de solo hormigón son ineficientes como elementos sometidos a flexión debido a que la resistencia a flexión es muy limitada. En consecuencia, estas fallan por tensión a cargas bajas. Por esta razón, se colocan barras de acero de refuerzo en el lado sometido a tensión y tan cerca como sea posible de la cara inferior. En una viga de hormigón así reforzada, la tensión causada por los momentos flectores es resistida principalmente por el acero de refuerzo mientras que el solo hormigón es capaz de resistir la compresión correspondiente. Esta acción conjunta de los dos materiales se garantiza si se impide su deslizamiento relativo mediante la utilización de barras corrugadas de acero.

Las vigas de hormigón armado no son homogéneas debido a que están hechas de dos materiales completamente diferentes: hormigón y acero. Los métodos usados en el diseño son distintos a los de vigas elaboradas completamente de acero, madera o cualquier otro material estructural. Cuando en algún momento se alcance la capacidad de carga de la viga, la falla se puede presentar principalmente de dos maneras. Cuando se emplea una cantidad de refuerzo de acero relativamente moderada, el acero alcanza su punto de fluencia para determinada carga y el acero fluye alargándose considerablemente. La falla por fluencia es gradual y está precedida por signos visibles de peligro como presentación de las grietas y notoria deformación. De otra parte, cuando se emplean grandes cantidades de refuerzo, la resistencia del hormigón puede agotarse antes de que el acero empiece a fluir. El hormigón falla por aplastamiento cuando sus deformaciones unitarias son tan grandes que destruyen su integridad. La falla por aplastamiento es repentina, explosiva y sin ningún aviso. Por esta razón, es aconsejable calcular las dimensiones de las vigas de tal manera que en caso de sobrecarga, la falla sea por fluencia del acero en vez del aplastamiento del concreto. Otra modalidad de falla puede ocurrir en vigas ligeramente reforzadas. Si la cantidad de acero es menor que un determinado valor mínimo (conocido como cuantía mínima de acero), la viga va a fallar inmediatamente y sin ningún aviso una vez que se forme la primera grieta de flexión. La tabla de a continuación muestra la configuración simplificada de la sección de una viga rectangular simplemente reforzada de hormigón armado.

Notación

Descripción

Rango

Ancho

20-40cm

Altura efectiva

30-50cm

Cantidad de barras de As

1-5

No. de la barra de As.

3-10

Tipo de falla

Inmediata Fluencia Aplastamiento

Sección de una viga rectangular de hormigón armado (As = acero de refuerzo)

Ilustración 6. Vista lateral de una viga de hormigón armado cargada y en estado inicial de falla.

Desarrollo Práctico

4.1

Información Necesaria para el Apoyo a la Toma de Decisiones

4.1.1 Medidas 

Cantidad de vigas construidas.



Cantidad de vigas construidas con algún desvío en su construcción.



Cantidad de vigas con desvíos en su construcción con relación a la resistencia del hormigón.



Cantidad de vigas con desvíos en su construcción con relación a la resistencia del acero.



Cantidad de vigas con desvíos en su construcción con relación al ancho de la sección.



Cantidad de vigas con desvíos en su construcción con relación al alto de la sección.



Cantidad de vigas con desvíos en su construcción con relación a su largo o vano.



Cantidad de vigas con desvíos en el área del acero de refuerzo.



Cantidad de vigas con desvíos en la resistencia (momento) de diseño.



Diferencia de volumen del elemento construido respecto al volumen de diseño.



Diferencia de costo del elemento construido respecto al costo de diseño.

4.1.2 Dimensiones 

Acero de refuerzo: código y diámetro



Asignaciones: obra e ingeniero ejecutor



Familia: tipo de sección de la viga y naturaleza de la falla



Tiempo: gestión y mes

4.2

Información Disponible La empresa cuenta con una fuente OLTP base de datos relacional SQL Server conformada a partir de las siguientes tablas:

En esta tabla denominada INGE se almacenan los nombres de los ingenieros ejecutores o constructores de los elementos de hormigón armado.

En la tabla PROY se almacenan las descripciones de las obras o proyectos encargados a la empresa.

En la tabla ASIGN se relacionan los ingenieros constructores y los proyectos a su cargo mediante llaves foráneas que hacen referencia a las llaves primarias de las dos tablas anteriores.

En la tabla BARRA se almacenan los diámetros de los distintos tamaños de barras de acero usados en la construcción.

En la tabla TIEMPO se almacenan la gestión y el mes para ser usados en el historial de obras proyectadas y ejecutadas por la empresa.

En la tabla FAMILIA se almacenan las posibles familias de vigas de hormigón armado según el tipo de sección y según la naturaleza de la falla (véase más abajo).

En la tabla VIDIS se almacenan las distintas variables involucradas en la etapa de DISEÑO de una viga de hormigón armado.

COAS

Llave foránea; hace referencia a la tabla de asignaciones ingeniero-obra.

RESHOR

Resistencia del hormigón en Kg/cm².

RESACER

Resistencia del acero en Kg/cm².

ANCHO

Ancho de la sección (cm).

ALTO

Alto de la sección (cm).

LONG

Largo del elemento (m).

VOL

Volumen del elemento (m3).

TSECC

Tipo de sección (cuadrada o rectangular).

COBA

Llave foránea; referencia a la tabla de acero.

CANTBA

Cantidad de barras de acero.

AACER

Área del acero de refuerzo (cm²).

CUANTOK

“Sí” cuando la cuantía de acero está dentro de los límites permisibles.

FALLA

Naturaleza de la falla del elemento.

RESMOM

Resistencia a momento del elemento.

COSTO

Costo del elemento (Bs.)

COTM

Llave foránea; a la tabla TIEMPO.

COFM

Llave foránea; a la tabla FAMILIA.

COVI

Llave foránea; a la viga en la tabla de diseño.

COAS_C

Llave foránea; a la tabla asignaciones ingenieroobra.

RESHOR_C

Resistencia del hormigón armado en Kg/cm².

RESACER_C

Resistencia del acero en Kg/cm².

ANCHO_C

Ancho de la sección (cm).

ALTO_C

Alto de la sección (cm).

LONG_C

Largo del elemento (m).

VOL_C

Volumen del elemento (m3).

TSECC_C

Tipo de sección (cuadrada o rectangular)

COBA_C

Llave foránea; a la tabla barras de acero.

CANTBA_C

Cantidad de barras de acero.

AACER_C

Área del acero de refuerzo (cm²).

CUANTOK_C

“Sí” cuando la cuantía de acero está dentro de límites.

FALLA_C

Naturaleza de falla del elemento.

RESMOM_C

Resistencia a momento del elemento.

En la tabla VICONS se almacenan las variables involucradas en la etapa de CONSTRUCCION de una viga de hormigón armado.

COSTO_C

Costo del elemento (Bs.)

COTM_C

Llave foránea; hace referencia a la tabla TIEMPO.

COFM_C

Llave foránea; hace referencia a la tabla FAMILIA.

Todas estas tablas se relacionan según la lógica del proceso diseño/construcción de vigas de hormigón armado. Como puede apreciarse en el diseño lógico de a continuación, las tablas principales son las tablas de diseño VIDIS y de construcción VICONS del elemento viga.

Ilustración 7.

Diseño lógico del OLTP fuente.

4.3

Modelo de Datos para el Data Mart Conforme las exigencias de la empresa con relación a la información requerida para la toma de decisiones, se ha estructurado el Data Mart o cubo de la siguiente manera:

En la tabla DIMASIGN se almacena la dimensión de asignaciones; útil para visualizar el análisis en función de la obra o bien en función del ingeniero ejecutor del elemento viga.

En la tabla DIMBARRA se almacena la dimensión del acero; útil para visualizar el análisis en función de la denominación o bien del diámetro de la barra del acero de refuerzo.

En la tabla DIMFAMILIA se almacena la dimensión de la familia de vigas; útil para visualizar el análisis en función del tipo de la sección o en función de la naturaleza de falla del elemento.

En la tabla DIMTIEMPO se almacena la dimensión del tiempo; útil para visualizar el análisis por gestión o bien por mes.

Aunque la herramienta Business Intelligence de Microsoft SQL Server permite poblar la dimensión tiempo de manera automatizada, en el presente trabajo se ha preferido administrarla manualmente para tener un mejor control sobre la dimensión misma; incluso para poder disponer de una correcta ordenación (cronológica en vez de alfabética).

RES_HOR_ERR

# de vigas con desvíos en la resistencia del hormigón.

RES_ACER_ERR

# de vigas con desvíos en la resistencia del acero.

ANCHO_ERR

# de vigas con desvíos en el ancho de la sección.

ALTO_ERR

# de vigas con desvíos en el alto de la sección.

LARGO_ERR

# de vigas con desvíos en el largo o vano.

VOL_DIF

Diferencia de volumen (m3).

A_ACERO_DIF

Diferencia en el área de acero (cm²).

RES_MOM_ERR

# de vigas con desvíos en la resistencia a momento.

COSTO_DIF Las medidas y las llaves foráneas de las dimensiones se ensamblan en la tabla de hechos ELE_ERR VIGAFACT.

Diferencia en el costo (Bs.) # de vigas con algún desvío en su construcción.

El formulario de expresiones matemáticas que permiten el cálculo de las diversas medidas de la tabla de hechos, se describe a continuación. Es importante adelantar que, todas estas fórmulas han sido implementadas en una vista diseñada sobre el OLTP para efectos de la etapa ETL (EXTRACTION TRANSFER LOADING), como se verá un poco más adelante.

Medida

Fórmula Matemática

RES_HOR_ERR

SIGN(ABS(VICONS.RESHOR_C-VIDIS.RESHOR))

RES_ACER_ERR

SIGN(ABS(VICONS.RESACER_C-VIDIS.RESACER))

ANCHO_ERR

SIGN(ABS(VICONS.ANCHO_C-VIDIS.ANCHO))

ALTO_ERR

SIGN(ABS(VICONS.ALTO_C-VIDIS.ALTO))

LARGO_ERR

SIGN(ABS(VICONS.LONG_C-VIDIS.LONG))

VOL_DIF

(VICONS.VOL_C-VIDIS.VOL)

A_ACERO_DIF

(VICONS.AACER_C-VIDIS.AACER)

RES_MOM_ERR

SIGN(ABS(VICONS.RESMOM_C-VIDIS.RESMOM))

COSTO_DIF

(VICONS.COSTO_C-VIDIS.COSTO)

ELE_ERR

SIGN(ABS(RES_HOR_ERR + RES_ACER_ERR + ANCHO_ERR + ALTO_ERR + LARGO_ERR + A_ACER_DIF))

El modelo del cubo o Data Mart está centrado en la tabla de hechos VIGAFACT a partir de la cual se “desprenden” todas las dimensiones. Se trata de un modelo tipo estrella (star):

Ilustración 8. Modelo del cubo; un esquema tipo estrella.

4.4

Implementaciรณn del Cubo en Microsoft SQL Server 2005 Primero, el cubo o Data Mart debe ser creado en Microsoft SQL Server 2005 de acuerdo a la siguiente secuencia SQL:

USE MASTER GO CREATE DATABASE VIGASDM01 GO USE VIGASDM01 GO CREATE TABLE DIMASIGN( CO_AS VARCHAR(10) NOT NULL, OBRA VARCHAR(50), EJECUTOR VARCHAR(50) ) CREATE TABLE DIMBARRA( CO_BA VARCHAR(10) NOT NULL, DIAMETRO DECIMAL(20,4) ) CREATE TABLE DIMTIEMPO( CO_TM VARCHAR(10) NOT NULL, GESTION INT, MES VARCHAR(50) ) CREATE TABLE DIMFAMILIA( CO_FM VARCHAR(10) NOT NULL, TSECC VARCHAR(50), FALLA VARCHAR(50) ) CREATE TABLE VIGAFACT( RES_HOR_ERR DECIMAL(20,4),

RES_ACER_ERR DECIMAL(20,4), ANCHO_ERR DECIMAL(20,4), ALTO_ERR DECIMAL(20,4), LARGO_ERR DECIMAL(20,4), VOL_DIF DECIMAL(20,4), A_ACER_DIF DECIMAL(20,4), RES_MOM_ERR DECIMAL(20,4), COSTO_DIF DECIMAL(20,4), ELE_ERR DECIMAL(20,4), COAS VARCHAR(10), COBA VARCHAR(10), COTM VARCHAR(10), COFM VARCHAR(10) ) ALTER TABLE DIMASIGN ADD CONSTRAINT PK_CO_AS PRIMARY KEY (CO_AS) ALTER TABLE DIMBARRA ADD CONSTRAINT PK_CO_BA PRIMARY KEY (CO_BA) ALTER TABLE DIMTIEMPO ADD CONSTRAINT PK_CO_TM PRIMARY KEY (CO_TM) ALTER TABLE DIMFAMILIA ADD CONSTRAINT PK_CO_FM PRIMARY KEY(CO_FM) ALTER TABLE VIGAFACT ADD CONSTRAINT FK_COAS FOREIGN KEY(COAS) REFERENCES DIMASIGN ALTER TABLE VIGAFACT ADD CONSTRAINT FK_COBA FOREIGN KEY(COBA) REFERENCES DIMBARRA ALTER TABLE VIGAFACT ADD CONSTRAINT FK_COTM FOREIGN KEY(COTM) REFERENCES DIMTIEMPO ALTER TABLE VIGAFACT ADD CONSTRAINT FK_COFM FOREIGN KEY(COFM) REFERENCES DIMFAMILIA

Luego, el cubo debe ser implementado mediante un proyecto Analysis Services de Business Intelligence de Microsoft SQL Server 2005. Primero, se crean los orígenes de datos mediante conexiones a la base de datos de la fuente OLTP y al modelo del cubo anteriormente creado; esto, se aprecia en la siguiente captura:

Ilustración 9. Orígenes de datos para la implementación del cubo.

Luego, se crea una vista del origen de datos a partir del modelo ya existente en la base de datos. La captura correspondiente se aprecia en la siguiente página.

Ilustraci贸n 10. Vista del origen de datos.

A continuaci贸n se va implementando el cubo. Durante la implementaci贸n del cubo, se deben identificar las tablas de hechos y las tablas de dimensiones conforme se muestra a continuaci贸n.

Ilustración 11. Identificación de las tablas y de dimensiones.

Cuando el diseño físico del cubo está correctamente realizado, el software hace un reconocimiento automático de las tablas de hechos y dimensiones según se puede apreciar en la ilustración 11.

Enseguida, se muestra el Data Mart implementado conforme el diseño expuesto con anterioridad. Puede distinguirse rápidamente un esquema tipo estrella. Véase la ilustración 12.

IlustraciĂłn 12. El cubo o Data Mart creado y reconocido correctamente.

Una vez realizado el cubo, se configuran las estructuras de las dimensiones del mismo por medio del reconocimiento de jerarquĂas o niveles pero a partir de la vista de datos; esto, conforme se muestra a continuaciĂłn.

Ilustración 13. Debe editarse la estructura de cada dimensión del cubo.

Antes de continuar con las demás etapas de conformación del cubo como el diseño de las agregaciones, se debe poblar el Data Mart a partir de las fuentes OLTP mediante la herramienta Integration Services de Business Intelligence disponible también en la suite Microsoft SQL Server 2005. Entonces, una vez creado un nuevo proyecto del tipo Integration Services, se diseña un paquete de flujo de control para organizar y comandar las diversas tareas de integración de información o flujo de datos. El paquete de flujo de control para éste proyecto incluye tres tareas principales: una tarea para el borrado de los contenidos de las tablas del Data Mart, otra tarea para el poblado de las dimensiones del cubo y una última tarea para el poblado de la tabla de hechos. Nota: El poblado de las dimensiones del cubo debe ir siempre antes que la tabla de hechos porque contiene las llaves primarias.

Ilustración 14. El paquete de flujo de control para éste proyecto.

En este paquete de flujo de control, la primera tarea de borrado de las tablas del cubo ha sido programada según el siguiente conjunto de instrucciones SQL:

Ilustración 15. La secuencia SQL para la primera tarea.

La segunda tarea de flujo de datos contiene una serie de transferencias de información desde las tablas y vistas de la fuente OLTP hacia las tablas de dimensiones del Data Mart. Los orígenes de datos son accesos a la fuente OLTP del tipo OLE (Object Linked Embedded) DB Source. Y los destinos son accesos al Data Mart del tipo OLE DB Target. Esto puede apreciarse a continuación:

Ilustración 16. La segunda tarea de flujo de datos.

Es importante señalar que, para poblar la dimensión de asignaciones o DIMASIGN, se ha diseñado una vista (consulta) específica en la fuente OLTP de acuerdo a la siguiente secuencia SQL:

USE VIGASDB01 GO CREATE VIEW VISTA02 AS SELECT

ASIGN.CO_AS, PROY.OBRA, INGE.EJECUTOR

FROM

ASIGN INNER JOIN INGE ON ASIGN.COIN = INGE.CO_IN INNER JOIN PROY ON ASIGN.COPR = PROY.CO_PR

El mapeo de campos entre los orígenes y destinos de datos prácticamente resulta automático cuando se diseña el Data Mart procurando mantener los nombres de los campos originales.

Ilustración 17. Ejemplo de las asignaciones entre el origen y el destino de datos para el ETL.

Para poblar las dimensiones del cubo no se ha usado la opción de direccionamiento en caso de error por las siguientes razones: porque se han diseñado vistas específicas libres de error, porque se tiene una fuente previamente limpiada y porque se prefiere una excepción en caso de error.

La última tarea del paquete del flujo de control consiste en el poblado de la tabla de hechos del cubo. Además de usar controles tipo OLE para el origen y destino de datos, se ha incluido un control transformador para efectuar algunos cálculos importantes a partir de la fuente OLTP.

Ilustración 18. La tarea de flujo de datos para poblar la tabla de hechos incluye un control transformador.

La VISTA01 mostrada en la ilustración 18 ha sido diseñada sobre la fuente OLTP exclusivamente para éste proceso ETL y según la siguiente secuencia SQL:

USE [VIGASDB01] GO CREATE VIEW [dbo].[VISTA01] AS SELECT VIDIS.CO_VI AS COVI, VICONS.COAS_C AS COAS, SIGN(ABS(VICONS.RESHOR_C-VIDIS.RESHOR)) AS RES_HOR_ERR,

SIGN(ABS(VICONS.RESACER_C-VIDIS.RESACER)) AS RES_ACER_ERR, SIGN(ABS(VICONS.ANCHO_C-VIDIS.ANCHO)) AS ANCHO_ERR, SIGN(ABS(VICONS.ALTO_C-VIDIS.ALTO)) AS ALTO_ERR, SIGN(ABS(VICONS.LONG_C-VIDIS.LONG)) AS LARGO_ERR, (VICONS.VOL_C-VIDIS.VOL) AS VOL_DIF, VICONS.COBA_C AS COBA, (VICONS.AACER_C-VIDIS.AACER) AS A_ACER_DIF, SIGN(ABS(VICONS.RESMOM_C-VIDIS.RESMOM)) AS RES_MOM_ERR, (VICONS.COSTO_C-VIDIS.COSTO) AS COSTO_DIF, VICONS.COTM_C AS COTM, VICONS.COFM_C AS COFM FROM

ASIGN INNER JOIN INGE ON ASIGN.COIN = INGE.CO_IN INNER JOIN PROY ON ASIGN.COPR = PROY.CO_PR INNER JOIN VICONS ON ASIGN.CO_AS = VICONS.COAS_C INNER JOIN BARRA ON VICONS.COBA_C = BARRA.CO_BA INNER JOIN

VIDIS ON ASIGN.CO_AS = VIDIS.COAS AND VICONS.COVI = VIDIS.CO_VI AND BARRA.CO_BA = VIDIS.COBA

Importante comentar que, la aplicación de la función matemática del signo SIGN al valor absoluto ABS de la diferencia entre un valor final con respecto a uno inicial, da 1 si hay alguna diferencia y 0 si no hay ninguna. Esto para que en el cubo pueda tenerse medidas acumulativas y sumatorias con respecto a la información de análisis. Por otra parte, el control de transformación CALCULOS (ilustración 18) ha sido empleado para obtener la columna derivada ELE_ERR a partir del OLTP fuente. Esta columna ELE_ERR contiene 1 si el elemento viga de hormigón ha sufrido algún defecto durante su construcción, y contiene 0 (cero) si ha sido construido estrictamente según el diseño. Como se vio anteriormente, su fórmula es la siguiente:

SIGN(ABS(RES_HOR_ERR + RES_ACER_ERR + ANCHO_ERR + ALTO_ERR + LARGO_ERR + A_ACER_DIF))

Y el detalle de su implementación se aprecia en el cuadro de diálogo de la ilustración 19.

Ilustración 19. Implementación del control tipo transformador.

Con relación a las asignaciones para la tabla de hechos, éstas resultan casi del todo automáticas cuando se han mantenido en lo posible los nombres de los campos iguales a los de la fuente origen OLTP. Esto se aprecia en la captura de pantalla de a continuación.

Ilustraciรณn 20. Las asignaciones de campos para la tabla de hechos del cubo.

Una vez preparadas todas las tareas descritas anteriormente, se ejecuta el paquete de flujo de control obteniendo resultados satisfactorios (color verde) como se aprecia en la ilustraciรณn 21.

Ilustración 21. Ejecución satisfactoria del paquete de flujo de control.

Finalizada la etapa ETL, se vuelve al servicio de análisis para concluir de implementar el cubo. Se diseñan las agregaciones para el modelo multidimensional MOLAP de actualización manual:

Ilustración 22. Modo de almacenamiento MOLAP sin caché.

Inmediatamente, se ejecuta el diseño de la agregación eligiendo el factor “almacenamiento estimado”:

Ilustración 23. Diseño de la agregación.

Ilustración 24. Procesamiento de las dimensiones del cubo.

Con el diseño de la agregación concluido, se procesan dichas agregaciones para las dimensiones del cubo conforme se muestra en la ilustración 24. Una vez preparadas las agregaciones, ya se puede examinar preliminarmente el cubo:

Ilustración 25. Examinar el cubo.

Conforme se puede apreciar en la ilustración 25, el cubo se ve implementado con éxito.

Ante de manipular el cubo para efectos prácticos y con el fin de obtener una mejor legibilidad de las dimensiones y medidas del mismo, se procede con el completado de las traducciones según lo siguiente:

Ilustración 26. Completado de las traducciones para una mejor legibilidad del cubo.

De ésta manera, puede hacerse un primer uso práctico del cubo como se muestra en la ilustración 27.

Ilustración 27. Un primer uso real del cubo.

En la anterior ilustración se puede apreciar que se está consultando la “diferencia de costo” (construido vs. presupuestado) por obra por gestión por asignación y filtrado por tipo de sección de viga. En este caso de estudio de ejemplo puede apreciarse que, en la gestión 2007, la construcción de todas las vigas involucradas en las obras mostradas, ha costado casi 70 bolivianos menos de lo presupuestado; todo esto, bajo responsabilidad del “ING. POEPSEL”.

4.5

Minería de Datos – Técnica de Agrupamiento o Clustering Se va a aplicar el algoritmo de agrupamiento (clustering). El algoritmo de agrupamiento crea grupos o clusters. El algoritmo de clustering usa técnicas iterativas para agrupar registros en clusters de características similares. Se examinarán los clusters para determinar cuáles de ellos tienen las mayores ocurrencias de los valores de predicción que se están buscando. Posteriormente, se apreciarán los valores de los atributos que diferencian un cluster de otro. Al elegir una nueva estructura de minería de datos del explorador de soluciones, aparece inmediatamente el asistente con un cuadro de diálogo que exige la selección de un método para definir la estructura de la minería de datos. Para el actual proyecto se elige la opción “a partir de un cubo existente” conforme puede apreciarse en la ilustración 28.

Ilustración 28. Cuadro de diálogo de método de definición para la minería de datos.

Nota.

Las estructuras de minería de datos pueden usar datos a partir de una base de datos relacional o bien de cubos OLAP; es decir, las bases de datos relacionales para operaciones transaccionales también pueden ser usadas en vez de un Data Mart.

Inmediatamente, aparece le cuadro de diálogo que exige la selección de la técnica de minería de datos a ser usada y aquella que se aproxime mejor al tipo de análisis que se está realizando. Se elige el algoritmo Microsoft Clustering según se muestra en la ilustración 29.

Ilustración 29. Cuadro de diálogo de selección de la técnica de minería de datos.

Enseguida aparece el cuadro de diálogo que exige la selección de la dimensión origen del cubo para construir la minería de datos. Como la dimensión tiempo es la principal fuente de información para la operación de minería, ésta se elige según se muestra en la ilustración 30.

Ilustraciรณn 30. Cuadro de diรกlogo de selecciรณn de la dimensiรณn origen del cubo.

Aparece el cuadro de diรกlogo de selecciรณn de clave de caso como se muestra en la ilustraciรณn de a continuaciรณn. Dicho atributo sirve como la clave o llave primaria para la operaciรณn de minerรญa de datos. Para este proyecto se elige la clave principal DIMTIEMPO.

Ilustraciรณn 31. Cuadro de diรกlogo para la selecciรณn del atributo llave.

Aparece entonces el cuadro de diálogo de selección de columnas o campo de escenario. Las columnas elegidas en éste cuadro de diálogo sirven como campos de entrada y de predicción en el modelo. Se eligen los siguientes atributos:



COSTO DIF (diferencia de costo construido respecto al costo proyectado)



ELE ERR (cantidad de vigas construidas con algún defecto)



Recuento VIGAFACT (cantidad de vigas construidas)



VOL DIF (diferencia de volumen construido respecto al volumen proyectado)

Ilustración 32. Cuadro de diálogo para la selección de campos de escenario para la minería.

Inmediatamente, aparece el cuadro de diálogo de especificación de tipo de contenido de las columnas a ser usadas en el modelo de minería de datos. Se selecciona el tipo continuo para todos los casos conforme se aprecia en la ilustración de a continuación.

Nota.

Algunos algoritmos de minería de datos pueden predecir valores discretos mientras otros pueden predecir valores continuos. En este caso, el algoritmo usado requiere valores continuos. Afortunadamente, las propiedades que se están empleando tienen valores continuos. De cualquier manera, siempre es posible forzar como valores discretos aquellos que sean continuos si el caso así lo requiere.

Ilustración 33. Cuadro de diálogo de especificación de contenido y tipo de datos.

Enseguida aparece el cuadro de diálogo de segmentación del cubo de origen para la ejecución del modelo. Para el presente modelo se usará todo el historial registrado en la bases de datos correspondientes a todas las gestiones.

Ilustración 34. Cuadro de diálogo de segmentación del cubo de origen.

Una vez completado todo esto, se finaliza el asistente de minería de datos y la estructura de minería de datos es creada conteniendo el nuevo modelo de minería de datos según se muestra en la ilustración 35.

Ilustración 35. La pantalla de estructura de minería de datos.

La ficha de modelos de minería de datos muestra el modelo de minería de datos actual como se muestra en la ilustración 36.

Ilustración 36. La ficha de modelos de minería de datos.

Una vez creado y ejecutado el modelo de minería de datos, puede empezarse a analizar la información mediante la ficha del visor de modelos de minería de datos. Cada algoritmo de minería de datos tiene su propio visor de modelo que permite la exploración de los datos producidos por el algoritmo de minería de datos. Dicho visor de modelo presenta la información de minería de manera gráfica para un fácil entendimiento. Al elegir la ficha del visor de modelo de minería de datos, aparece la pantalla según la ilustración 37 que a su vez muestra inicialmente una ficha con el diagrama de clusters o grupos.

Ilustración 37. Ficha del diagrama de clusters resultante de la minería de datos.

En ésta pantalla se puede apreciar que el algoritmo de clustering ha obtenido 10 clusters o grupos diferentes. Las líneas en el diagrama indican cuán relacionados están estos grupos o clusters. Una línea de color gris oscuro indica que dos clusters o grupos están fuertemente relacionados. Y una línea de color gris claro indica que dos clusters o grupos están “ligeramente” relacionados. En la ilustración 37, el sombreado de los clusters se corresponde con la variable población. Se puede distinguir por ejemplo, que los clusters 1 al 5 tienen una mayor concentración de población en contraste con los grupos 7, 9 y 10.

Para continuar con el análisis de resultados de la minería de datos, se elige ya también la variable COSTO DIF con un estado mayor a 12.7 pesos como se aprecia en la ilustración 38.

Ilustración 38. Diagrama de clusters para la variable COSTO DIF y para un estado mayor a 12.7 pesos.

Este diagrama de clusters indica según el sombreado de los mismos, el contenido con relación a registros que tengan una diferencia en el costo construido con respecto a lo proyectado mayor a 12.7 pesos. Por ejemplo, puede apreciarse que los clusters 6, 8 y 10 contienen casi totalmente elementos que se corresponden con éste caso mientras que los cluster 1, 2, 3 y 7 casi no contienen elementos relacionados a este caso. Luego, al elegir la misma variable COSTO DIF pero para un estado de población menor a 12.7 pesos, se tiene la ilustración 39 que como puede apreciarse muestra el diagrama complementario al anterior.

IlustraciĂłn 39. Diagrama de clusters complementario al diagrama mostrado en la ilustraciĂłn 38.

Continuando con el anĂĄlisis de resultados, se elige ahora la variable ELE ERR para un estado menor a 3 unidades; es decir, el diagrama de cluster asociado con el nĂşmero de elementos construidos con defectos y que no sobrepasan la cantidad de 3.

Ilustración 40. Diagrama de cluster para la variable ELE ERR con un estado menor a 3 unidades.

En éste diagrama puede apreciarse que, casi todos los elementos de los clusters o grupos 1, 2 y 5 se corresponden con elementos (en este caso vigas con defectos en su construcción) que no sobrepasan a 3 en número o cantidad. Por ejemplo, los clusters o grupos 1, 2 o 5 tienen mayor densidad de éste tipo de elementos y están aislados; mientras que, los clusters o grupos 6 y 9 tienen muy baja densidad con relación a este tipo de elementos. También puede confirmarse lo relacionados que resultan los clusters 6, 8 y 10 puesto que comparten una baja densidad de elementos del tipo descrito en éste párrafo; mientras que los clusters 1, 2 y 5 pese a compartir una mayor densidad, no aparecen vinculados; lo cual, se puede dar en el caso de que éste tipo de situación o escenario no sea predominante para su vinculación. En la ilustración 41 se aprecia el diagrama de clusters complementario.

Ilustración 41. Diagrama de clusters complementario al diagrama mostrado en la ilustración 40.

Siguiendo con el análisis, ahora se presentan los resultados de la minería de datos correspondientes a la variable VOL DIF que como se dijo representa la diferencia del volumen construido con respecto a lo proyectado. La ilustración 42 muestra el diagrama de clusters asociado a ésta variable para un estado de valores menores a 0.02 metros cúbicos.

Ilustración 42. Diagrama de clúster asociado a VOL DIF para un estado menor a 0.02 metros cúbicos.

Puede apreciarse en ésta gráfica que, los clusters o grupos 6, 8 y 10 no están sombreados; razón por la cual, están asociados con elementos (en este caso vigas de hormigón armado) cuyo volumen construido NO difiere en 0.02 o menos con relación a lo proyectado. Tales grupos están vinculados. En contraste, los clusters o grupos 3, 4 y 7, por ejemplo, estás casi totalmente sombreados; lo que implica, que se corresponden con elementos o vigas cuyo volumen construido SI difiere en 0.02 o menos con relación al volumen construido. Aunque los clusters o grupos 1 y 2 están igualmente sombreados, ésta situación de diferencia de volumen no es la característica predominante para que estén vinculados. La ilustración 43 muestra el diagrama de clusters complementario; es decir, para elementos o vigas de hormigón cuyo volumen construido es mayor a 0.02 metros cúbicos con respecto a lo proyectado.

Ilustración 43. Diagrama de clusters complementario al diagrama de la ilustración 42.

Es el turno ahora de explorar la ficha de los perfiles de los clusters que se muestra en la ilustración de a continuación. Esta ficha puede usarse entonces para explorar las características de los clusters o grupos que más interesan.

Ilustración 44. Perfiles de los clusters o grupos obtenidos en la minería de datos.

En el diagrama de la ilustración 44 puede apreciarse la distribución de los valores de cada atributo para los clusters o grupos. Por ejemplo, para el caso del cluster o grupo 1, puede apreciarse que tiene un conjunto de 16 miembros, elementos o vigas; entre los cuales, casi no existen elementos que se correspondan con tener alguna diferencia de costo construido con respecto a lo proyectado (COSTO DIF). Del mismo modo, dicho cluster 1 casi no contiene elementos que estén asociados con alguna diferencia en el volumen construido con respecto a lo proyectado; lo cual resulta coherente, puesto que, al no haber diferencia en el volumen construido tampoco se debería tener una diferencia de costo. En lo que respecta al atributo ELE ERR que representa la cantidad de elementos o vigas con algún defecto en su construcción, éste mismo cluster 1 indica que se tiene muy pocos elementos que comparten dicha situación y que a su vez se corresponden o están situados en una escala inferior. De manera similar, el atributo “Recuento VIGAFACT” indica que existe un número menor a la mitad de elementos o vigas construidas que se corresponden con éste cluster o grupo 1. Por otra parte, al apuntar con el ratón el cluster o grupo 2 cruzado con la variable ELE ERR, se aprecia de manera inmediata un cuadro de leyenda según se muestra en la ilustración 45.

Ilustración 45. Leyenda de minería de datos para el cluster 2 cruzado con ELE ERR.

En éste cuadro (45) puede apreciarse ciertos parámetros estadísticos como la desviación estándar hacia ambos lados de la media, el promedio, el mínimo y el máximo. Por ejemplo, indica que, dentro de los 16 elementos que contiene el cluster 2, el elemento 9 representa el último elemento o viga con algún defecto durante su construcción. Para resumir, tanto la ilustración 44 como la 45, representan el detalle completo de información del tipo histograma de los resultados del agrupamiento o clustering de la minería de datos realizada.

Ahora toca seleccionar y explorar la ficha de características de los clusters para el presente modelo como se muestra en una primera ilustración de a continuación. Las características de los clusters forman son una parte muy importante de los resultados obtenidos en la minería de datos.

Ilustración 46. Características del cluster o grupo 1 luego de la minería de datos.

En ésta ilustración 46 puede apreciarse la probabilidad del valor de un atributo en particular. Por ejemplo, puede verse que, hay una altísima probabilidad de que la diferencia de costo (COSTO DIF) construido con relación a lo proyectado caiga en el rango de -13 a 12.7 metros cúbicos; es decir, una altísima probabilidad de que los elementos construidos tengan un “déficit” de 13 pesos o bien un exceso de 12.7 pesos con respecto a su presupuesto de diseño; todo esto, desde luego a partir de la caracterización del cluster o grupo 1. En contraste, se tiene una muy baja probabilidad de que los elementos o vigas construidos con algún defecto (ELE ERR) estén entre 1.7 o 3.1 unidades. Toda ésta información ya nos permite hacer ciertas predicciones en base al análisis acabado de describir.

Siguiendo con el análisis de resultados, es el turno de explorar las características del cluster 2 mostradas en la ilustración 47.

Ilustración 47. Características del cluster o grupo 2 luego de la minería de datos.

Llegado a este punto del análisis, es muy importante señalar que, todos los clusters logrados en la minería de datos han sido agrupados mediante un patrón o curva de probabilidad de comportamiento similar, tal como se muestra en las ilustraciones 46 y 47, y en las de a continuación.

Por ejemplo, gracias a la información reflejada en el cluster o grupo 2, es posible predecir o inferir que hay una baja probabilidad de que el proceso de construcción de vigas de hormigón armado arroje una diferencia de costo (COSTO DIF) que caiga en el rango de 12.7 a 13.84 pesos con relación a lo proyectado. Por otra parte, hay una alta probabilidad de que los elementos construidos puedan resultar conforme el diseño; esto puede apreciarse en la variable VOL DIF de la anterior gráfica. Las ilustraciones 48 a la 55 muestran las características de los cluster 3 al 10 que nos permiten a su vez poder hacer más inferencias o predicciones a partir de las probabilidades reflejadas en sus resultados.

Ilustración 48. Características del cluster o grupo 3 luego de la minería de datos.

Ilustración 49. Características del cluster o grupo 4 luego de la minería de datos.

Ilustración 50. Características del cluster o grupo 5 luego de la minería de datos.

Ilustración 51. Características del cluster o grupo 6 luego de la minería de datos.

Ilustración 52. Características del cluster o grupo 7 luego de la minería de datos.

Ilustración 53. Características del cluster o grupo 8 luego de la minería de datos.

Ilustración 54. Características del cluster o grupo 9 luego de la minería de datos.

Ilustración 55. Características del cluster o grupo 10 luego de la minería de datos.

Ya casi finalizando éste análisis de resultados, es el turno de explorar la ficha de discriminación o distinción de clusters. Este diagrama nos permite determinar qué valores de atributos hacen la diferencia predominante de un cluster seleccionado con relación a otros. Esto se muestra en la ilustración tipo de a continuación.

Ilustración 56. La ficha de distinción de cluster para el cluster 1 comparado con el cluster 2.

Por ejemplo, para la variable ELE ERR que representa la cantidad de vigas de hormigón armado construidas con algún defecto en su construcción, puede apreciarse que cuando los valores de éste atributo oscilan entre 1.2 y 9.0 unidades, el resultado es a favor del cluster 2; es decir, que los elementos se corresponderían más propiamente con el cluster 2 que con el cluster 1. En contraste, si la cantidad de elementos o vigas con algún defecto en su construcción oscila entre 0 y 1.2 unidades, éste tipo de elementos se corresponde más propiamente con el cluster o grupo 1. Todo esto se aprecia en la ilustración 56. La ilustración 57 muestra otra comparativa similar del cluster 1 pero con relación al cluster 3.

Ilustración 57. La ficha de distinción de cluster para el cluster 1 comparado con el cluster 3.

Conclusiones El Data Warehouse puede aplicarse a diversas áreas del conocimiento tales como la toma de decisiones en la consultoría de obras civiles. El desarrollo de un Data Warehouse exige el cumplimiento ordenado de una serie de etapas secuenciales imprescindibles. Cuado el desarrollo de una inteligencia de negocio incluye un solo Data Mart, puede decirse con mayor certeza y propiedad que, dicho Data Mart es a la vez el Data Warehouse. Un Data Warehouse debe estar desde el principio orientado claramente por un objetivo relacionado con la información métrica exigida por el ente decisivo del negocio o de la empresa. Todas las métricas incluidas en un Data Warehouse deben ser de agregación; es decir, sumatorias, promedios y otros cálculos globales. Para el diseño de un Data Mart debe primero tenerse un claro entendimiento de las fuentes de información disponibles así como de las exigencias mismas del proceso de negocio. Antes de poblar un Data Mart, debe depurarse de inconsistencias y ruido la información fuente que se tenga. Luego, primero deberán poblarse las dimensiones del cubo y posteriormente la tabla de hechos. Para la visualización del cubo es mejor hacer traducciones del METADATA porque permite una mejor legibilidad de las dimensiones y de los hechos durante la manipulación del cubo. La operación de minería de datos puede realizarse a partir de un cubo o un OLTP; no obstante, a partir de un cubo OLAP se tiene una mayor flexibilidad. Es importante elegir la técnica de minería de datos que mejor se aproxime al análisis que se quiere realizar. Es importante identificar y seleccionar adecuadamente los campos de nivel de escenario para la minería de datos; estos campos, pueden ser de entrada o de predicción del modelo. Algunos algoritmos pueden trabajar con valores continuos y otros con valores discretos; sin embargo, siempre es posible hacer discretos los valores continuos. Los clusters resultantes de una operación de agrupamiento o clustering pueden estar fuertemente vinculados o no; esto depende de que las características de los atributos tengan alguna similitud como la probabilidad de ocurrencia de los mismos. La densidad de población de los clusters o grupos producidos por la minería de datos, está en directa relación con la naturaleza de la conformación de los clusters o grupos. El diagrama de perfiles de los clusters obtenidos es muy útil para una apreciación global comparativa de los resultados de la minería de datos. En este diagrama se hace uso de la gráfica tipo histograma. Las características de los clusters son muy importantes para el uso de los resultados de la minería de datos porque permiten hacer inferencias u obtener conclusiones a partir de la probabilidad de ocurrencia de los atributos de éstos grupos. En la operación de minería de datos para éste proyecto, se pudo apreciar que todos los clusters resultantes compartían una curva de probabilidad de ocurrencia de comportamiento similar.

Referencias 

CHRISTIAN J. DAZA (2008)

“¿Qué es un Data Warehouse?”. Postgrado en Informática. Universidad Mayor de San Andrés. LP, Bolivia.



ROGELIO S. CASTRO (2008)

“Almacenes de Datos”. Universidad Central “Marta Abreu” de las Villas. Cuba.



BRIAN LARSON (2006)

“Delivering Business Intelligence with Microsoft SQL Server 2005”. McGraw-Hill/Osborne. California, USA.



WIKIPEDIA (2008)

“Cubo OLAP”. [En red]. Disponible en: http://es.wikipedia.org/wiki/Cubo_OLAP



MICROSOFT CORP. (2000)

“SQL Server Books Online“. Disponible en: Microsoft® SQL Server.



JUDITH PAVON M. (2007)

"Bases de Datos". Postgrado en Informática. UMSA. LPBOL.



N. WINTER (1997)

“Diseño de Estructuras de Concreto”. Undécima edición. McGraw-Hill. México.

Apéndices A

Reporting Services SQL Server Reporting Services es una completa solución de servidor que permite crear, administrar y entregar tanto informes tradicionales en papel como informes Web interactivos. Reporting Services se integra en el marco de trabajo de Microsoft Business Intelligence y combina las funciones de administración de datos de SQL Server y Microsoft Windows Server con las conocidas y eficaces aplicaciones de Microsoft Office System para entregar información en tiempo real que permita fundamentar las operaciones diarias y la toma de decisiones.

A.1

Arquitectura Integrada SQL Server Reporting Services admite una amplia gama de orígenes de datos comunes como OLE DB y conectividad abierta de bases de datos (ODBC) así como varios formatos de salida tanto para exploradores Web conocidos como para aplicaciones de Microsoft Office System. Gracias a Microsoft Visual Studio® .NET y Microsoft .NET Framework, los programadores pueden aprovechar las funciones de los sistemas de informes existentes y conectarse a orígenes de datos personalizados, crear otros formatos de salida e incluso realizar entregas en diferentes dispositivos.

Ilustración A1. Arquitectura de Reporting Services.

A.2

Soporte Completo para el Ciclo de Vida de los Informes SQL Server Reporting Services da soporte a todo el ciclo de vida de los informes, incluido lo siguiente:



Creación de informes. Los programadores pueden crear informes para publicarlos en el servidor de informes mediante herramientas de diseño de Microsoft o de otros fabricantes que utilicen el lenguaje RDL (Report Definition Language), un estándar de la industria basado en XML que se usa para definir informes.



Administración de informes. Las definiciones de informe, carpetas y recursos se publican y administran como un servicio Web. Los informes administrados se pueden ejecutar a petición o según una programación especificada y se almacenan en la memoria caché por motivos de coherencia y rendimiento.



Entrega de informes. SQL Server Reporting Services admite la entrega de informes a petición (extracción) y basada en eventos (inserción). Los usuarios pueden ver los informes con formato Web o en el correo electrónico.