5 Modelado Multidimensional 5.3 Ejemplo de construcción de un Data Warehouse.

[Administrador Grupo]

Busque un ejemplo de como se construye un data warehouse.

Fecha de entrega 8 11 12

[luis.galindo.ortega]

Ejemplo de Como Construir un Data Warehouse

Ejemplo: Cadena de supermercados.

Cadena de supermercados con 300 almacenes en la que se expenden unos 30.000 productos distintos.

Actividad: Ventas.

Paso 1 Elegir un “proceso” de la organización para modelar.

La actividad a modelar son las ventas de productos en los almacenes de la cadena.

Paso 2 Decidir el gránulo (nivel de detalle) de representación.

• Gránulo: “se desea almacenar información sobre las ventas diarias de cada producto en cada almacén de la cadena”.
  
• Gránulo: 
  
• define el significado de las tuplas de la tabla de hechos.
• determina las dimensiones básicas del esquema.
• Gránulo inferior: no se almacena información a nivel de línea de ticket porque no se puede identificar siempre al cliente de la venta lo que permitiría hacer análisis del comportamiento (hábitos de compra) del cliente.
  
• Gránulo superior: no se almacena información a nivel semanal o mensual porque se perderían opciones de análisis interesantes: ventas en días previos a vacaciones, ventas en fin de semana, ventas en fin de mes, ....
  

Paso 3 Identificar las dimensiones que caracterizan el proceso.

Dimensión Tiempo:

• dimensión presente en todo AD porque el AD contiene información histórica sobre la organización.
  
• aunque el lenguaje SQL ofrece funciones de tipo DATE, una dimensión Tiempo permite representar otros atributos temporales no calculables en SQL.
  
• se puede calcular de antemano
  
• atributos frecuentes:
  
• nro. de día, nro. de semana, nro. de año: valores absolutos del calendario juliano que permiten hacer ciertos cálculos aritméticos.
• día de la semana (lunes, martes, miércoles,...): permite hacer análisis sobre días de la semana concretos (ej. ventas en sábado, ventas en lunes,..).
• día del mes (1..31): permite hacer comparaciones sobre el mismo día en meses distintos (ventas el 1º de mes).
• marca de fin de mes, marca de fin de semana : permite hacer comparaciones sobre el último día del mes o días de fin de semana en distintos meses.
• trimestre del año (1..4): permite hacer análisis sobre un trimestre concreto en distintos años.
• marca de día festivo: permite hacer análisis sobre los días contiguos a un día festivo.
• estación (primavera, verano..)
• evento especial: permite marcar días de eventos especiales (final de futbol, elecciones...)
• jerarquía natural: día - mes - trimestre -año
  

 
Dimensión Producto:

• la dimensión Producto se define a partir del fichero maestro de productos del sistema OLTP.
  
• las actualizaciones del fichero maestro de productos deben reflejarse en la dimensión Producto (¿cómo?).
  
• la dimensión Producto debe contener el mayor número posible de atributos descriptivos que permitan un análisis flexible. Un número frecuente es de 50 atributos.
  
• atributos frecuentes: identificador (código estándar), descripción, tamaño del envase, marca, categoría, departamento, tipo de envase, producto dietético, peso, unidades de peso, unidades por envase, fórmula, ...
  
• jerarquías: producto-categoría-departamento
  

 
Dimensión Establecimiento (store) :

• la dimensión Almacén representa la información geográfica básica.
  
• esta dimensión suele ser creada explícitamente recopilando información externa que sólo tiene sentido en el A.D y que no la tiene en un OLTP (número de habitantes de la ciudad del establecimiento, caracterización del tipo de población del distrito, ...)
  
• atributos frecuentes: identificador (código interno), nombre, dirección, distrito, región, ciudad, país, director, teléfono, fax, tipo de almacén, superficie, fecha de apertura, fecha de la última remodelación, superficie para congelados, superficie para productos frescos, datos de la población del distrito, zona de ventas, ...
  
• jerarquías:
  
• establecimiento - distrito - ciudad - región - país (jerarquía geográfica)
• establecimiento - zona_ventas - región_ventas (jerarquía de ventas)

Paso 4 Decidir la información a almacenar sobre el proceso.

Gránulo: “se desea almacenar información sobre las ventas diarias de cada producto en cada establecimiento de la cadena”.

• importe total de las ventas del producto en el día
  
• número total de unidades vendidas del producto en el día
  
• número total de clientes distintos que han comprado el producto en el día.
  

Bibliografia

http://carlosproal.com/dw/dw04.html

 

[cipriano.hernadez.alanis]

5.3 Ejemplo de construcción de un Data Warehouse.

En la Figura se muestra un ejemplo hipotético de un data warehouse estructurado para un centro de producción industrial.

Se muestra sólo el detalle actual, no así los niveles de esquematización ni los archivos de detalle más antiguos.

Además, se observa que hay tablas del mismo tipo divididas a través del tiempo. Por ejemplo, para el histórico de la fabricación de las piezas, hay muchas tablas separadas físicamente, representando cada una un trimestre diferente. La estructura de los datos es consistente con la tabla de la elaboración de las piezas, aunque físicamente hay muchas tablas que lógicamente incluyen el histórico.

Para los diferentes tipos de tablas hay diferentes unidades de tiempo que físicamente dividen las unidades de información. El histórico de fabricación está dividido por trimestres, el histórico de la orden de piezas está dividido por años y el histórico de cliente es un archivo único, no dividido por el tiempo.

Así también, las diferentes tablas son vinculadas por medio de un identificador común, piezas u órdenes de piezas (la representación de la interrelación en el ambiente de depósito toma una forma muy diferente al de otros ambientes, tal como el ambiente operacional).

BIBLIOGRAFIA
http://www.ongei.gob.pe/publica/metodologias/Lib5084/1-11.HTM

[francisco.gonzalez.cassio]

Es buen ejemplo de construccion de un DWHa partir de un problema, solo que esta algo extenso para poner aqui asi que les dejo el link y espero les ayude:

 

http://www.econ.uba.ar/www/departamentos/sistemas/plan97/s_datos/waldbott/chinkes/material/Caso%20practico%20DW-BI%20Jurassic_Park_Parte_II.pdf 

[jgerardo.felixo]

Adjunto Archivo por que contiene demasiadas imagenes.

 

 Fuente: http://www.geronet.com.ar/?p=255

[jmanuelgarciaaragon]

Implementando un datawarehouse.

Publicado en 11/12/2008 por Geronimo Manso — 2 Comentarios ↓

Un datawarehouse lo definiría como un sistema de información que reúne datos de diferentes orígenes, los procesa y los entrega al usuario final como información útil para la toma de decisiones o para hacer inferencias de los mismos para aplicarlas según sea necesario.

Hoy en día en las diferentes empresas u organizaciones se dispone de muchos datos, pero es necesario procesarlos para poder obtener información útil de los mismos, entonces muchas veces es necesario diseñar un datawarehouse que se encargue de realizar dichos trabajos.

En el documento que pueden descargar desde http://www.geronet.com.ar/wp-content/uploads/2008/12/ejemplo-de-diseao-de-datawarehouse.doc mostraré un ejemplo de cómo diseñar un datawarehouse  a partir de un caso práctico.

En el archivo pueden ver la descripción del problema, el diseño de los diferentes componentes, y al final unas imágenes capturadas a partir de la implementación del “cubo” en una herramienta llamada O3 que responden algunas de las preguntas que se plantean como requisitos que debe cumplir el sistema final.

La idea no es describir detalladamente los procesos de creación del  mismo, sino proporcionar un ejemplo de cómo quedaría la implementación y la documentación del mismo para quienes tengan la tarea de desarrollar un sistema de este tipo.

http://www.geronet.com.ar/wp-content/uploads/2008/12/ejemplo-de-diseao-de-datawarehouse.doc

[Victor Manuel Niebla Romero]

Como Construir un Datawarehouse

Organización

La planificación es el proceso más importante que determina la clase de tipo de

estrategias data warehousing que una organización iniciará.

Factores en la Planificacion de un Data Warehouse

No existe una fórmula de garantía real para el éxito de la construcción de un data

warehouse, pero hay muchos puntos que contribuyen a ese objetivo.

A continuación, se indican algunos puntos claves que deben considerarse en la

planificación de un data warehouse:

Establecer una asociación de usuarios, gestión y grupos

• Es esencial involucrar tanto a los usuarios como a la gestión para asegurar que el data warehouse contenga información que satisfaga los requerimientos de la empresa.
• La gestión puede ayudar a priorizar la fase de la implementación del data warehouse, así como también la selección de herramientas del usuario. Los usuarios y la gestión justifican los costos del data warehouse sobre cómo será "su ambiente" y está basado primero en lo esperado y segundo, en el valor comercial real.

Seleccionar una aplicación piloto con una alta probabilidad de éxito

Una aplicación piloto de alcance limitado, con un reembolso medible para los usuarios y la gestión, establecerá el data warehouse como una tecnología clave para la empresa. Estos mismos criterios (alcance limitado, reembolso medible y

beneficios claros para la empresa) se aplican a cada fase de la implementación de un data warehouse.

Construir prototipos rápida y frecuentemente

La única manera para asegurar que el data warehouse reúna las necesidades de

los usuarios, es hacer el prototipo a lo largo del proceso de implementación y aún

más allá, así como agregar los nuevos datos y/o los modelos en forma permanente.

El trabajo continuo con los usuarios y la gestión es, nuevamente, la clave.

Implementación incremental

La implementación incremental reduce riesgos y asegura que el tamaño del

proyecto permanezca manejable en cada fase.

Reportar activamente y publicar los casos exitosos

La retroalimentación de los usuarios ofrece una excelente oportunidad para publicar

los hechos exitosos dentro de una organización. La publicidad interna sobre cómo el

data warehouse ha ayudado a los usuarios a operar más efectivamente puede

apoyar la construcción del data warehouse a lo largo de una empresa.

La retroalimentación del usuario también ayuda a comprender cómo evoluciona la

implementación del data warehouse a través del tiempo para reunir requerimientos

de usuario nuevamente identificados.

Estrategias para el Desarrollo de un Data Warehouse

Antes de desarrollar un data warehouse, es crítico el desarrollo de una estrategia equilibrada que sea apropiada para sus necesidades y sus usuarios.

Las preguntas que deben tenerse en cuenta son:

• ¿Quién es el auditorio?
• ¿Cuál es el alcance?
• ¿Qué tipo de data warehouse debería construirse?

Existe un número de estrategias mediante las cuales las organizaciones pueden conseguir sus data warehouses.

Primera

Establecer un ambiente "data warehouse virtual", el cual puede ser creado por:

• Instalación de un conjunto de facilidades para acceso a datos, directorio de datos y gestión de proceso.
• Entrenamiento de usuarios finales.
• Control de cómo se usan realmente las instalaciones del data warehouse.
• Basados en el uso actual, crear un data warehouse físico para soportar los pedidos de alta frecuencia.

Segunda

Construir una copia de los datos operacionales desde un sistema operacional único y posibilitar al data warehouse de una serie de herramientas de acceso a la información. 

Esta estrategia tiene la ventaja de ser simple y rápida. Desafortunadamente, si los

datos existentes son de mala calidad y/o el acceso a los datos no ha sido

previamente evaluado, entonces se puede crear una serie de problemas.

Tercera

Finalmente, la estrategia data warehousing óptima es seleccionar el número de

usuarios basados en el valor de la empresa y hacer un análisis de sus puntos,

preguntas y necesidades de acceso a datos.

De acuerdo a estas necesidades, se construyen los prototipos data warehousing y

se prueban para que los usuarios finales puedan experimentar y modificar sus

requerimientos.

Una vez se tenga un consenso general sobre las necesidades, entonces se

consiguen los datos provenientes de los sistemas operacionales existentes a través

de la empresa y/o desde fuentes externas de datos y se cargan al data warehouse.

Si se requieren herramientas de acceso a la información, se puede también permitir

a los usuarios finales tener acceso a los datos requeridos usando sus herramientas

favoritas propias, o facilitar la creación de sistemas de acceso a la información

multidimensional de alta performance, usando el núcleo del data warehouse como

base.

En conclusión

No se tiene un enfoque único para construir un data warehouse que se adapte a las

necesidades de las empresas, debido a que las necesidades de cada una de ellas

son diferentes, al igual que su contexto.

Además, como la tecnología data warehousing va evolucionando, se aprende cada

vez más y más sobre el desarrollo de data warehouses, que resulta en que el único

enfoque práctico para al almacenamiento de datos es la evolución de uno mismo. [1]

Referencias

http://www.willydev.net/descargas/prev/ElABCDW.PDF [1]

[rodolfo.cabrales.barrios]

Modelo de Datawarehouse para el sector Público (Caso Editora Perú S.A.) 

Angel Hermoza Salas 

Universidad Nacional Mayor de San Marcos 

angelher...@yahoo.es 

Resumen 

En este paper se presenta y describe un modelo general Olap y prototipo de un Sistema DataWareHouse para 

una empresa del sector público en general y se implementa en la empresa pública Editora Perú S.A. Se revisan 

los antecedentes, cómo se consolida la información actualmente de forma manual o con apoyo de otros 

sistemas, se define el problema, se muestra gráficamente la situación actual, se determina la justificación del 

presente trabajo y  los métodos utilizados. Se detallan los objetivos generales y específicos; además se explica el 

concepto de Inteligencia de Negocios y Almacén de Datos. Se muestra el Modelo General OLAP de Editora 

Perú,  así como el prototipo desarrollado para mostrar parte de la solución al problema. Finalmente se expone 

las conclusiones, las recomendaciones y trabajos futuros. 

1. Introducción  

La generación de reportes detallados, resumidos y comparativos son el medio más utilizado para 

explotar la información del Sistema ERP Baan, un sistema ERP (Enterprise Resource Planning), 

según Kwon [Kwon 2001], es “un paquete de software amplio integrado empresarial diseñado 

para mantener los más altos estándares de calidad de los procesos empresariales”. Para analizar la 

información los usuarios mensualmente generan un archivo en formato ASCII con la información 

de los reportes, luego mediante el procedimiento FTP (File Transfer Protocol) se importa el 

archivo del ambiente AIX al ambiente Windows (computador del usuario), luego desde Microsoft 

Office se procede a la importación y formateo del archivo, para finalmente preparar los cuadros y 

gráficos que serán entregados a los ejecutivos de la empresa para la toma de decisiones. 

Definición del problema 

Editora Perú S.A. es una empresa del sector público que ha implementado el sistema ERP Baan 

IV desde el año 2001, donde todo el procesamiento de transacciones en línea (OLTP) es 

soportado por este sistema. Como se cuenta con información histórica en el repositorio o base de 

datos (ORACLE), es necesario procesar, explotar, analizar, para informar a todos los niveles de 

decisión de la empresa. Actualmente este proceso se realiza con un uso intensivo de 

procesamiento en línea, el uso de herramientas diversas, el tiempo de consolidación y finalmente 

los resultados deben ser validados debido a que en el transcurso del proceso pueden haber 

variado. En la Figura 1 se muestra la situación actual: El Sistema ERP Baan se utiliza para 

generar reportes históricos que consume recursos en línea ocasionando lentitud y compitiendo con 

el trabajo diario. Cada fin de mes se solicita la generación de información consolidada,  no se 

atiende a tiempo debido a que el procedimiento para su realización es tedioso y poco confiable. 

Los problemas son los siguientes: 

• El uso intensivo de reportes en línea para la generación de reportes históricos compite con el 

procesamiento de transacciones del día, lo que ocasiona lentitud en el tiempo de respuesta del 

sistema. 

• El procesamiento de la información genera archivos ASCII, los que son formateados en 

Microsoft Office Excel, no garantiza la integridad debido a la manipulación de esta 

información. 

• El ingreso de transacciones que afectan el periodo procesado ocasiona que hayan diferencias entre lo procesado y la información real. 

• Debido al procesamiento manual no se cuenta con la información en la fecha acordada. 

• No hay estandarización de los cuadros y gráficos presentados como parte del análisis. 

Figura 1: Situación actual

Limitaciones de la solución del problema 

No se cuenta con partida presupuestal para el desarrollo del sistema, por lo que no se puede 

contratar a terceros, tampoco comprar una solución a medida, ni compra de licencias ni hardware. 

Solamente se cuenta con el recurso humano del Departamento de Desarrollo para solucionar el 

problema. 

Variantes de la solución del problema 

De contar con presupuesto la solución del problema puede encargarse a un tercero para un 

desarrollo a medida o mediante la compra de una solución a una empresa de software. 

Justificación e importancia

• La falta de información consolidada no permite tomar decisiones rápidas, solamente se cuenta 

con información mensual. 

• El tiempo de procesamiento de la información ocasiona que no se cumpla con la entrega 

oportuna. 

• No existe un solo repositorio de información dedicado exclusivamente a explotar la 

información histórica. 

• No existe una herramienta de análisis que permita acceder a la información histórica. 

Objetivos Generales Proponer un Modelo General OLAP para Editora Perú S.A. que sirva como guía para la 

elaboración paulatina de los datamarts, que permitirán atender a futuro los requerimientos de 

información de las diferentes áreas de la empresa. 

Objetivos Específicos

Implementar un datamart de Ventas a partir del Modelo OLAP Sunat que permita solucionar el 

problema actual. 

Utilizar la experiencia y conocimiento adquiridos en la solución del problema para la 

implementación de los demás datamarts definidos en el Modelo General. 

El resto de éste paper está organizado de la siguiente manera. En la sección 2 se muestra como 

realizar la sección de Trabajos Previos. La sección 3 describe el Modelo Olap General. La forma 

de colocar los Experimentos y Resultados se encuentra en la sección 4. La Discusión de los 

Experimentos se muestra en la sección 5 y finalmente, la manera de redactar las conclusiones y 

recomendaciones o trabajos futuros está en la sección 6. 

2. Trabajos Previos  

Business Intelligence (Inteligencia de Negocios) 

Según [Microsoft, 2004] vivimos en una época en que la información es la clave para obtener una 

ventaja competitiva en el mundo de los negocios. Para mantenerse competitiva una empresa, los 

gerentes y tomadores de decisiones requieren de un acceso rápido y fácil a información útil y 

valiosa para la empresa. Una forma de solucionar este problema es por medio del uso de Business 

Intelligence o Inteligencia de Negocios. La Inteligencia de Negocios o Business Intelligence (BI) 

se puede definir como el proceso de analizar los bienes o datos acumulados en la empresa y 

extraer una cierta inteligencia o conocimiento de ellos. Dentro de la categoría de bienes se 

incluyen las bases de datos de clientes, información de la cadena de suministro, ventas personales 

y cualquier actividad de marketing o fuente de información relevante para la empresa. La clave 

para BI es la información y uno de sus mayores beneficios es la posibilidad de utilizarla en la 

toma de decisiones. Tal vez le ayude a comprender mejor el concepto por medio de un ejemplo. 

Una franquicia de hoteles a nivel nacional que utiliza aplicaciones de BI para llevar un registro 

estadístico del porcentaje promedio de ocupación del hotel, así como los días promedio de 

estancia de cada huésped, considerando las diferencias entre temporadas.  

Con esta información se puede: 

• Calcular la rentabilidad de cada hotel en cada temporada del año 

• Determinar quién es su segmento de mercado 

• Calcular la participación de mercado de la franquicia y de cada hotel 

• Identificar oportunidades y amenazas 

Estas son sólo algunas de las formas en que una empresa u organización se puede beneficiar por 

la implementación de software de BI, hay una gran variedad de aplicaciones o software que 

brindan a la empresa la habilidad de analizar  de una forma rápida por qué pasan las cosas y 

enfocarse a patrones y amenazas. 

¿Qué se puede hacer con Business Intelligence (BI)?  

Con Business Intelligence (BI) se puede: 

• Generar reportes globales o por secciones  

• Crear una base de datos de clientes  

• Crear escenarios con respecto a una decisión  

• Hacer pronósticos de ventas y devoluciones  

• Compartir información entre departamentos  

• Análisis multidimensionales  

• Generar y procesar datos  • Cambiar la estructura de toma de decisiones  

• Mejorar el servicio al cliente 

La siguiente es una lista de las áreas más comunes en las que las soluciones de inteligencia de 

negocios son utilizadas:  

• Ventas: Análisis de ventas; Detección de clientes importantes; Análisis de productos, líneas, 

mercados; Pronósticos y proyecciones. 

• Marketing: Segmentación y análisis de clientes; Seguimiento a nuevos productos. 

• Finanzas: Análisis de gastos; Rotación de cartera; Razones financieras.  

• Manufactura: Productividad en líneas; Análisis de desperdicios; Análisis de calidad; Rotación 

de inventarios y partes críticas. 

• Embarques: Seguimiento de embarques; Motivos por los cuales se pierden pedidos. 

Componentes de Business Intelligence

Multidimensionalidad: la información multidimensional se puede encontrar en hojas de cálculo, 

bases de datos, etc. Una herramienta de BI debe ser capaz de reunir información dispersa en toda 

la empresa e incluso en diferentes fuentes para así proporcionar a los departamentos la 

accesibilidad, poder y flexibilidad que necesitan para analizar la información. Por ejemplo, un 

pronóstico de ventas de un nuevo producto en varias regiones no está completo si no se toma en 

cuenta también el comportamiento histórico de las ventas de cada región y la forma en que la 

introducción de nuevos productos se ha desarrollado en cada región en cuestión.  

Data Mining (Minería de Datos): Las empresas suelen generar grandes cantidades de información 

sobre sus procesos productivos, desempeño operacional, mercados y clientes. Pero el éxito de los 

negocios depende por lo general de la habilidad para ver nuevas tendencias o cambios en las 

tendencias. Las aplicaciones de data mining pueden identificar tendencias y comportamientos, no 

sólo para extraer información, sino también para descubrir las relaciones en bases de datos que 

pueden identificar comportamientos que no son muy evidentes. 

Agentes: Los agentes son programas que "piensan". Ellos pueden realizar tareas sin necesidad de 

intervención humana. Por ejemplo, un agente pueden realizar tareas complejas, como elaborar 

documentos, establecer diagramas de flujo, etc. 

Data Warehouse (Almacén de Datos): Es la respuesta de la tecnología de información a la 

descentralización en la toma de decisiones. Coloca información de todas las áreas funcionales de 

la organización en manos de quien toma las decisiones. También proporciona herramientas para 

búsqueda y análisis. 

A: Data centralizada desde múltiples fuentes dentro de un datawarehouse 

B: Herramientas BI que analizan la data para entender mejor el negocio 

C: Reportes inteligentes para la toma de decisiones 

Figura 2 : Business intelligence El Futuro

La Figura 2, describe la Inteligencia de Negocios (BI) que ya no puede ser ignorada por ninguna 

organización que reconoce que estamos en la era de la información. En el futuro cercano debemos 

esperar lo siguiente: 

• Proyectos más frecuentes y más largos 

• Barreras de entrada para los primeros 

• La infraestructura será estándar 

• Se establecerán centros de información  

• Convergencia de tecnologías (acceso por internet) 

• Cambiar actividades consideradas periféricas en Core Business 

Soluciones Datawarehouse

Según [Cognos, 2002]  en AFP Nueva Vida las soluciones cognos cambiaron la manera como se  

hacían los negocios. se permitió efectuar seguimiento más a detalle del comportamiento de los 

afiliados y las empresas aportadoras. asimismo, se identificaron segmentos importantes de 

clientes y empresas. 

Según [Nakasone, 2004] las empresas han optado por utilizar la inteligencia de negocios y el 

primer escalón es construyendo un almacén de datos (datawarehouse), para luego avanzar en la 

minería de datos (datamining). 

3. Modelo Olap para una empresa pública  

A fin de alcanzar los objetivos planteados en el presente trabajo se ha planteado el modelamiento 

de una solución general para toda empresa del estado, tomamos como base la empresa pública 

Editora Perú, pero puede extenderse la solución a cualquier otra empresa tal como Sedapal, 

Essalud, Ministerios, etc.  

Figura 3: Modelo General 

En la Figura 3 se muestra el Modelo General en este caso mostrando a Editora Perú, pero se 

puede generalizar para toda empresa del estado, todas las empresas tienen la obligación legal 

de reportar a las siguiente entidades : 

• Sunat (Superintendencia Nacional de Administración Tributaria) 

• Fonafe (Fondo Nacional de Financiamiento de la Actividad Empresarial del Estado) 

• Produce (Ministerio de la Producción) • INEI (Instituto Nacional de Estadística e Informática) 

• Contaduría General de la República 

• Contraloría General de la República 

• Consucode (Consejo Superior de Contrataciones y Adquisiciones del Estado) 

Además internamente Editora Perú debe generar información interna para sus órganos de 

supervisión y control : Recursos Humanos,  Costos, Presupuesto, Indicadores, Gestión 

Contable, Clientes, Proveedores, Tesorería, Activo Fijo, Manufactura, Distribución. 

En la Figura 4 se muestra el Modelo General Detalle, donde se puede observar que cada 

entidad exige información detallada para fines de control, las que se deben entregar en tiempo 

y plazos establecidos legalmente. 

En la Figura 4 en el extremo superior derecho se muestra el Modelo OLAP Sunat, se resalta el 

Registro de Ventas que será lo que se desarrollará como parte de este trabajo, en este caso se 

tiene la base legal, los formularios, formatos de archivo a informar, archivo de transferencia, 

luego a través del Sistema PDT la información será enviada a la Sunat. 

El presente trabajo permite realizar un “reciclaje” o “reuso” de ésta información para 

alimentar los datamart y conformar el datawarehouse de una empresa pública.  

Figura 4: Modelo General Detalle 

4. Experimentos y Resultados  

Organización e instancias de prueba

Se ha considerado los años del 2002 al 2005. Los componentes de hardware con los que trabajará 

el sistema son: Servidor compatible, Servidor IBM X Series Modelo H70, SAN Storage HP. Mientras que los componentes de software con los que trabajará el sistema son: Sistema 

Operativo: Windows 2000 para el servidor, Explorador de Internet (Internet Explorer), Manejador 

de base de datos MSSQL 2000, Sistema ERP, Sistema Operativo AIX v 4.3, Manejador de Base 

de Datos Oracle v.9, Sistema ERP BAAN IV C2. 

Procesamiento

Se ha desarrollado procedimientos almacenados que permiten transferir los datos del datamart de 

ventas de la base de datos Oracle v9.0 a Ms Sql 2000, luego otro procedimiento almacenado 

genera el cubo o datamart de ventas dentro del Analysis Server, en ese momento el usuario tiene 

disponible la información que se muestra. 

Resultados

El usuario debe acceder a la hoja de cálculo y mediante un procedimiento seleccionar el cubo de 

ventas. 

La Figura 5 nos muestra las ventas totales de los años 2002 al 2005 donde podemos visualizar 

cada mes como se comportan las ventas en Editora Perú.

Figura 5: Ventas Anuales 

Figura 6: Comparativo Mensual de VentasLa Figura 6 nos muestra el cuadro comparativo mensual de ventas, en él se puede comparar la 

venta mensual como anual, de modo que se muestren las tendencias y las expectativas de venta de 

acuerdo al  pronóstico realizado al inicio del año. Esta información está disponible para toda la 

empresa.

5. Discusión de los Experimentos  

En la Figura 7 se muestra  gráficamente la solución al problema, así como las ventajas que se 

obtienen con la implementación de esta solución: 

Ahora se cuenta con un servidor OLAP diferente al servidor OLTP por lo que ya no se compite 

con los recursos diarios, el acceso es más rápido y directamente de la hoja de cálculo Microsoft 

Office. 

El procesamiento es totalmente automatizado, se procesa el periodo deseado, en este caso se ha 

considerado hacerlo quincenal y mensualmente. 

Al existir un solo repositorio OLAP ahora todos los usuarios de la empresa pueden acceder 

simultáneamente a la información sin problemas de lentitud manteniéndose la integridad. 

Se ha estandarizado el uso de plantillas para la presentación de la información tanto de los cuadros 

como de los gráficos. 

Figura 7: Solución al problema 

6. Conclusiones  

La implementación del datamart de ventas permitirá que el usuario pueda contar con una 

herramienta en línea totalmente automatizada, de fácil uso, que le permita disminuir el tiempo de 

procesamiento y dedique mayor tiempo a la etapa de análisis de la información. 

Al automatizar la generación de reportes y gráficos: 

• Se eliminan los errores o diferencias por migración de datos y formateo. 

• Se disminuye el tiempo de procesamiento por procedimientos manuales.  • Por decisión del usuario el procesamiento se realiza quincenal y mensualmente, quedando 

abierta la posibilidad de efectuarlo diariamente. 

• El acceso a la información residente ahora en el servidor OLAP es más rápido en 

comparación con el acceso a la base de datos  del servidor OLTP utilizado en el proceso 

manual. 

Según [Microsoft, 2004], los usuarios pueden acceder a un solo repositorio de datos (servidor 

OLAP) directamente desde la hoja de cálculo Microsoft Office, utilizando plantillas estándar. El 

único costo para la implementación de este sistema consiste en la capacitación de la herramienta 

Analysis Server de Microsoft producto que viene como parte de la Base de Datos MS SQL . 

Recomendaciones o trabajos futuros

Como se muestra en la Figura 7 existen las siguientes tareas a futuro: 

Generar información de los datamarts para informar en el Portal de Editora Perú 

(www.editoraperu.com.pe). Implementar todos los cubos faltantes que se muestran en la Figura 4 

Modelo General OLAP Detallado. Que todos los usuarios de la empresa tengan acceso a la 

información de la empresa vía Intranet. 

http://eventos.spc.org.pe/jpc2007/MyReview/FILES/p3.pdf

[José de Jesús Santes Palacios]

Ejemplo de como se construye un data warehouse.

Considere un problema bastante típico en una compañía de fabricación grande en el que se pide una información (un reporte) que no esta disponible.

El informe incluye las finanzas actuales, el inventario y la condición de personal, acompañado de comparaciones del mes actual con el anterior y el mismo mes del año anterior, con una comparación adicional de los 3 años precedentes. Se debe explicar cada desviación de la tendencia que cae fuera de un rango predefinido.

Sin un data warehouse, el informe es preparado de la manera siguiente:

La información financiera actual se obtiene desde una base de datos mediante un programa de extracción de datos, el inventario actual de otro programa de extracción de otra base de datos, la condición actual de personal de un tercer programa de extracción y la información historia desde un backup de cinta magnética o CD-ROM.

Lo mas interesante es que se a pedido otro informe que continué (debido a que las preguntas se originan a partir del anterior). El hecho es, que ninguno de los trabajos realizados hasta aquí (por ejemplo, diversos programas de extracción  se pueden usar para los próximos o para cualquier reporte subsiguiente. Imagine el tiempo y el esfuerzo que se ha desperdiciado por un enfoque anticuado.

Las inconsistencias deben identificarse en cada conjunto de datos extraídos y resolverse, por lo general, manualmente Cuando se completa todo este procesamiento, el reporte puede ser formateado, impreso, revisado y transmitido.

Nuevamente, el punto importante aquí es que todo el trabajo desempeñado para hacer este informe, no afecta a otros reportes que pueden solicitarse es decir todos ellos son independientes y caros, desde el punto de vista de recursos y productividad.

Al crear un data warehouse y combinar todos los datos requeridos, se obtienen los siguientes beneficios:

Las inconsistencias de los datos se resuelven automáticamente cuando los elementos de datos se cargan en el data warehouse, no manualmente, cada vez que se prepara un reporte.

Los errores que ocurrieron durante el proceso complejo de la preparación del informe, se minimizan porque el proceso es ahora mucho mas simple.

Los elementos de datos son fácilmente accesibles para otros usos, no sólo para un reporte particular.

Se crea una sola fuente.

Referencia:

http://www.yoquese.com.ar/resources/external/material_toma_de_decisiones/capitulo4-2.pdf