implementación en sql server de un data warehouse

Universidad Mayor de San Andrés Facultad de Ciencias Puras y Naturales Postgrado en Informática Data Warehouse

Implementación en SQL Server 2005 de un Data Warehouse para el Soporte a la Toma de Decisiones en la Consultoría y Construcción de Vigas de Hormigón Armado de una Empresa Consultora Constructora

Presentado a:

Lic. Christian Daza

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

La Paz, Bolivia – Mayo 22 de 2008

Resumen En este trabajo de investigación se diseñará e implementará en MS SQL Server 2005 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 y construcción de vigas de hormigón armado por parte de una empresa consultora constructora.

Se llegará a visualizar de manera gráfica y tabular mediciones acumulativas importantes sobre el diseño y construcción de vigas de hormigón armado. Dichas mediciones podrán consultarse en función de cualquier dimensión y filtro elegido conforme la necesidad de información por parte del ente de toma de decisiones de la empresa.

Primero, se hace una revisión esencial y breve del marco teórico que respalda el Data Warehouse y el dominio de aplicación. A continuación, se listan las necesidades de información y retroalimentación para la toma de decisiones de la empresa; como ser: indicadores clave de rendimiento (KPIs), 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 automatizado. Luego, se diseñan y procesan las agregaciones para examinar el cubo y poder aplicarlo al análisis multidimensional de algunos casos de estudio representativos.

Se incluye también el servicio de reportes además de una graficación tridimensional por medio de la importación del cubo hacia una hoja de cálculo como Excel.

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, 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

2

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

3

MARCO TEÓRICO ........................................................................................................................................................... 3 3.1 SISTEMAS OPERACIONALES .......................................................................................................................................... 3 3.2 SISTEMAS PARA EL SOPORTE DE DECISIONES (DSS) .................................................................................................... 3 3.3 SISTEMAS DE INFORMACIÓN ......................................................................................................................................... 4 3.4 TECNOLOGÍA DE LA INFORMACIÓN............................................................................................................................... 4 3.5 DATA WAREHOUSE - ALMACENES DE DATOS .............................................................................................................. 4 3.5.1 Pasos para el Diseño de un Data Warehouse ......................................................................................................... 5 3.6 OLTP (ON-LINE TRANSACTION PROCESSING) ............................................................................................................. 5 3.7 ÁREA DE ESTACIONAMIENTO DE DATOS ...................................................................................................................... 5 3.8 DATA MART ................................................................................................................................................................. 6 3.9 PROCESAMIENTO ANALÍTICO EN LÍNEA (OLAP: ON-LINE ANALYTICAL PROCESSING) ............................................................. 6 3.9.1 Operaciones OLAP ................................................................................................................................................. 6 3.9.2 Las 18 Características de OLAP (Reglas de Codd Ampliadas) .............................................................................. 7 3.10 MODELO MULTIDIMENSIONAL ..................................................................................................................................... 8 3.11 DISEÑO LÓGICO ........................................................................................................................................................... 8 3.12 METADATA .................................................................................................................................................................. 8 3.13 ODS (OPERATIONAL DATA STAGE) ............................................................................................................................. 9 3.14 CAMPO DE APLICACIÓN: HORMIGÓN ARMADO - RAMA DE LA INGENIERÍA CIVIL ....................................................... 9 3.14.1 Vigas Simplemente Reforzadas .......................................................................................................................... 9

4

DESARROLLO PRÁCTICO........................................................................................................................................... 11 4.1 4.1.1 4.1.2 4.1.3 4.2 4.3 4.4

5

INFORMACIÓN NECESARIA PARA EL APOYO A LA TOMA DE DECISIONES ................................................................... 11 Indicadores de Rendimiento Claves o KPIs .......................................................................................................... 11 Medidas................................................................................................................................................................. 11 Dimensiones .......................................................................................................................................................... 11 INFORMACIÓN DISPONIBLE ........................................................................................................................................ 12 MODELO DE DATOS PARA EL DATA MART ................................................................................................................. 15 IMPLEMENTACIÓN DEL CUBO EN MICROSOFT SQL SERVER 2005 .............................................................................. 18

CASOS DE ESTUDIO ...................................................................................................................................................... 40 5.1 5.2 5.3 5.4 5.5

6

CASO 1 ....................................................................................................................................................................... 40 CASO 2 ....................................................................................................................................................................... 40 CASO 3 ....................................................................................................................................................................... 41 CASO 4 ....................................................................................................................................................................... 43 CASO 5 ....................................................................................................................................................................... 43

CONCLUSIONES ............................................................................................................................................................. 46

REFERENCIAS.......................................................................................................................................................................... 47 APÉNDICES ............................................................................................................................................................................... 47 A

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

1

1

Introducción

1.1

Escenario Este proyecto de investigación se extiende en el área del Data Warehouse (almacén 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.

2

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; todo esto, para conformar el monitoreo de un conjunto de indicadores de rendimiento clave así como la obtención de información global en función de cualquier dimensión o variable y así 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.

2

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.



Diseñar e implementar un tablero de control con indicadores claves de rendimiento o KPIs.



Diseñar e implementar un servicio de informe basado en la Web.



Exportar el Data Mart a una hoja de cálculo para su tabulación y graficación dinámica.



Analizar algunos casos de estudio representativos.

3

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.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.

4

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.

5

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:

6



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

7

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

8

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 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.14.1

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.

9

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

b

Ancho

20-40cm

d

Altura efectiva

30-50cm

Cantidad de barras de As

1-5

n

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.

10

4

Desarrollo Práctico

4.1

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

4.1.1 Indicadores de Rendimiento Claves o KPIs 

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



Porcentaje de vigas construidas con desvíos o defectos en la resistencia del hormigón.



Porcentaje de vigas construidas con desvíos o defectos en la resistencia del acero.

4.1.2 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.3 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

11

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).

12

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.

13

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.

14

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).

15

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))

16

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.

17

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),

18

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

19

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.

20

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.

21

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.

22

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.

23

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.

24

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.

25

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

26

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.

27

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,

28

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.

29

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.

30

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.

31

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é.

32

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.

33

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.

34

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.

35

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”.

Otra opción muy potente y práctica para el monitoreo de la información “cúbica” es el uso de los indicadores claves de rendimiento o KPIs que proveen una serie de controles gráficos tipo tablero de mando de avión que visualizan el estado de alguna variable elegida del proceso del negocio. Para usar un KPI primero debe configurarse según el cuadro de diálogo de a continuación.

36

Ilustración 28. El formulario para configurar un KPI.

En el campo “Expresión de valor” se coloca una fórmula que permita el cálculo del porcentaje de vigas con desviaciones o defectos en su construcción con relación a su diseño. En el campo “Expresión objetivo” se coloca 0 (cero) porque el objetivo es no tener defectos. Y en el campo “Expresión de estado” se elabora una fórmula que transforma la escala de la expresión de valor en la escala soportada por el indicador gráfico elegido. La escala de un indicador gráfico oscila entre -1 y +1, siendo -1 el valor “pésimo” y +1 el valor más óptimo.

Una vez guardada, generada e implementada ésta configuración del tipo KPI, puede pasarse a la vista explorador que para el presente proyecto nos ofrece de manera inicial lo que se muestra en la ilustración de a continuación.

37

Ilustración 29. La vista explorador de un KPI.

En la ilustración 29, los indicadores de estado están basados en las dimensiones de más arriba. El 25% de las vigas está con defectos constructivos para el 2005 bajo la responsabilidad del “ING. FERNHOLZ J.”

Ilustración 30. Cuadro de diálogo para el diseño de informes.

38

Y para crear un servicio de reporte o informe en la Web debe configurarse la estructura del mismo por medio de la correcta asignación de información de campos exigida por el asistente para informes (ilustración 30).

Una vez generado e implementado un informe, éste puede hacerse disponible en la Web por medio de la tecnología Active Server Pages (ASP) .NET:

Ilustración 31. Informe ya disponible para la Web.

En el informe anterior, se muestra la diferencia de costo construido versus diseñado por ingeniero ejecutor de proyecto para distintas gestiones de la empresa.

39

5

Casos de Estudio

5.1

Caso 1 Para averiguar a cuánto asciende la diferencia de volumen y diferencia de costo (construido versus proyectado) para cada obra ejecutada por sus ejecutores correspondientes durante las gestiones 2006 y 2007 pero para vigas con sección rectangular y tipo de falla fluencia, debe configurarse el cubo según lo siguiente:

Ilustración 32. Cubo del Caso 1.

5.2

Caso 2 Para obtener un resumen de las medidas o hechos más importantes concernientes a todas las gestiones registradas históricamente con la opción de desglosarse por mes, para vigas de sección rectangular cuya falla de diseño sea la fluencia y las cuales pertenezcan a cualquier obra ejecutada por cualquier ejecutor, el cubo debe estructurarse de acuerdo a la ilustración de a continuación.

40

Ilustración 33. Cubo del Caso 2.

5.3

Caso 3 Nota: Para éste caso se ha importado el cubo a la hoja electrónica Excel.

Para averiguar la cantidad de vigas construidas con algún defecto y las cuales corresponden a cada obra registrada en el historial para todas las gestiones y ejecutadas por cualquier ejecutor, debe conformarse la tabla dinámica Excel conforme la ilustración de la siguiente página.

41

42

Ilustraciรณn 34. La tabla dinรกmica del caso 3.

5.4

Caso 4 Para este caso se ha empleado una gráfica dinámica tridimensional de Excel. Para averiguar la cantidad de vigas construidas con algún defecto y correspondientes a los distintos proyectos ejecutados durante las distintas gestiones registradas en el historial además de dirigidas por el “ING. IRIGOYEN”, debe estructurarse dicha gráfica dinámica tridimensional de acuerdo a la ilustración 35.

5.5

Caso 5 Para averiguar la diferencia de costo con relación a lo presupuestado pero de todas las vigas de sección rectangular cuya falla sea por fluencia y correspondientes a sus respectivos proyectos y ejecutadas por sus respectivos ejecutores durante las gestiones 2002 a 2007, la gráfica dinámica tridimensional debe estructurarse conforme a la ilustración 36.

43

44

Ilustraciรณn 35. La grรกfica dinรกmica del caso 4.

45

Ilustraciรณn 36. La grรกfica dinรกmica del caso 5.

6

Conclusiones El Data Warehouse es una filosofía impalpable pero que al hacerse tangible ofrece una utilidad sin igual y 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.

Cuando 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.

La teoría y conceptos que respaldan el Data Warehouse son de suma importancia y tiene que ver con un conocimiento profesional de las bases de datos.

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 poblar con mayor facilidad un Data Mart, es mejor diseñar vistas (consultas) específicas como interfaz de la fuente de datos; esto, cuando se tengan bases de datos como información fuente.

Para una frecuente consulta y manipulación del cubo puede graduarse el procesamiento analítico en línea (OLAP) al extremo relacional (ROLAP) sobre todo cuando se desea consultar por información muy específica; pero para una actualización manual del cubo puede graduarse hasta MOLAP que encaja perfectamente con el modelo multidimensional.

El diseño y cálculo de agregaciones no siempre puede llegar a niveles muy altos; esto, depende del almacenamiento estimado, de la ganancia del rendimiento y en general de la complejidad del modelo de datos.

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.

Para diseñar, implementar y explorar los indicadores claves de rendimiento o KPIs, deben formularse cuidadosamente las expresiones de valores, los valores objetivos así como las escalas mismas de los indicadores gráficos empleados.

Antes de la difusión Internet Web de los informes, deben diseñarse las consultas intrínsecas con la mayor claridad y objetividad posible.

46

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.

47

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.

48